Forum Discussion

DoctorYdens's avatar
DoctorYdens
Level 2
8 years ago

SynchInMigrationMode

Hi All,

My situation is: we have been running Exch 2007 for some time and had EV all nicely provisioned (NB the initial deployment was before my time with the company).

We have recently deployed Exchange 2013. I added the new Exchange box to EV and provisioned, so far so good. I then started moving mailboxes WITHOUT creating the SynchInMigrationMode key. They all appeared to move ok, no duplicates, and mail seems to be archiving ok.

I am now at the point of decommissioning the old Exchange2007 server and I'm following the procedure at https://www.veritas.com/support/en_US/article.TECH50256. My problem is that I have a number of mailboxes, mostly from test users and training users who are only used infrequently, which are still associated with the old server as far as the database is concerned despite having been moved to the new server. Will adding SynchInMigrationMode at this late stage just magically clear these up? Or am I going to have to do some database wrangling?

  • VirgilDobos's avatar
    VirgilDobos
    Moderator
    8 years ago

    Hey mate,

    SynchInMigration mode key will not help in this scenario. Its purpose is to control whether, when migrating mailboxes from one Exchange to another, EV automatically assigns migrated mailboxes to existing archives. 

    You will have to sort this out at the Exchange level.

  • daveoflave's avatar
    daveoflave
    Level 4
    8 years ago

    Hi DoctorYdens,

        I'm assuming that when you say those are "associated with the old server," you mean the ExchangeMailboxEntry (EME) table rows for those mailboxes show some mention of the old server; maybe the LegacyMbxDN column or something like that.  If not, shed some light on the specific meaning.

         The EME table is the ONE table you can edit/delete from however you like.  EV rebuilds it twice a day if necessary upon running provisioning.  So normally I wouldn't say this, but for the EME table, you can delete the rows in question and run provisioning again to recreate them; they will likely show the way they're expected.

    • DoctorYdens's avatar
      DoctorYdens
      Level 2
      8 years ago

      Hi,

      I'm following through the procedure which i linked to in my first post, and as part of that it gets you to run the following SQL:

      USE EnterpriseVaultDirectory
SELECT *
FROM ExchangeMailboxEntry EME
INNER JOIN ExchangeMailboxStore EMS ON EME.MbxStoreIdentity = EMS.MbxStoreIdentity
INNER JOIN ExchangeServerEntry ESE ON ESE.ExchangeServerIdentity = EMS.ExchangeServerIdentity
WHERE ESE.ExchangeServerIdentity = '1'

      This returns mailboxes which are still associated with the old exchange server '1' rather than the new one '3'. Now I get lots of entries because there are a lot of archives for people who have left the business and whose original mailbox has been deleted but we need to keep the mailbox. I read during my research that all you have to do is delete these entries from the database and they EV will let you remove the Exchange server from AD. (If you need to retreive mail at a later date you can associate the archive with a user).

      BUT as well as archives with no associated mailbox there are about 20 mailboxes where the mailbox has been moved to the new exchange server but the ExchangeServerIdentity is still 1. If I'm reading you correctly then I should be able to delete those entries from ExchangeMailboxEntry and when the provisioning task runs it SHOULD put them back in with the ExchangeServerIdentity column populated correctly?

      DrY

      • daveoflave's avatar
        daveoflave
        Level 4
        8 years ago

        Right - that's exactly what provisioning should do, and if it doesn't, there's got to be something in Exchange or the GC pointing them to the old one.  However, those things going wrong is exceptionally unlikely, and it's more likely the rows in EME that we're talking about. 

          So the mailboxes that are now gone completely makes sense - our provisioning task would have nothing telling it to update those rows, as it never "discovers" those mailboxes in the trawl.

           The ones that never updated though, and still exist (as you mentioned at the end) really should have.  Though here in support we've seen a bevy of environmental factors that can prevent that from happening. 

           To answer your question - absolutely delete those too.  In fact, make it simple and get a clean slate; just delete all rows from the table (but don't delete the table!). Like this:

        Use EnterpriseVaultDirectory

        Delete From ExchangeMailboxEntry

         

         Provisioning will be forced to use all new data because it will be forced to create new entries in the table.  If they still show incorrectly, you've either got some mailboxes that weren't actually moved the way you thought they were, or your GC is telling us otherwise for whatever reason. Hope this helps!