The question is often asked if Shared Mailboxes can be put into a 2 way continuous synchronisation throughout the duration of migration to allow both migrated & non-migrated users access to the same Shared mailbox with the same content and to be able to function from both systems at the same time.
This is not possible using the Quest/Dell Software toolset for mailbox synchronisation and migration. There can only be one ‘live’ instance of a Shared Mailbox, either on the legacy or the target messaging system. Not both, Not ever.
The recommended approach from Quest/Dell Software is to migrate Shared Mailboxes together with the user mailbox migrations. The preferred approach is to switch the Shared Mailbox at the same time as the key users of the shared mailbox, else leave it in legacy until the last user is across to the target platform.
If using the Sync & Switch method for Shared Mailboxes the following will apply:
Shared Mailbox still live on Legacy Platform
Legacy Users continue to have access exactly as today
Target Messaging service users can see the target copy of the Shared Mailbox (Outlook 2010/2013 automatically add in all Shared Mailbox a user has permissions too – whether migrated or not), users can:
- Read items & Reply from the Shared Mailbox
- The Read status & Replies will NOT synchronise back to the live Shared Mailbox in legacy
- New email items will only appear during the next synchronisation pass (which could be a delay of minutes to hours)
In this situation end users already switched to the Target Messaging system often mistakenly think that the Shared Mailbox is fully functional as they can see it and may see new items periodically updating.
Shared Mailbox switched to and now live on Target Platform
Legacy Users will still have access to the legacy Shared Mailbox contents as they were prior to the switch, however no new emails will appear and they will be unable to reply to old email (they will only be able to forward email internally). All new email will have been re-directed to the target Shared Mailbox as part of the mailbox switch
Target Users have access to the migrated target Shared Mailbox exactly as they did in legacy but now with all the full functionality. Users will be able:
- Read and Reply to all emails, both internal and external
- Organise folders as needed
- New emails will appear immediately in the Inbox, bypassing the legacy Shared Mailbox
If using the Remote Collection method for migration any Shared Mailbox content can only be live and valid on either the source or target messaging system, not both, which means the target Shared Mailbox will be empty until the Remote Collection migration is triggered. Once that is triggered the legacy Shared Mailbox is no longer useful as it loses functionality.
Real advice, Real Experience
I often make a judgement call on switching Shared mailboxes, I advise customers to switch them once the key users who need access to it are switched. You can use Quest/Dell Software Reporter or a PowerShell script to list out all Shared Mailboxes and who has rights to them. It is then a case of identifying and contacting Shared Mailbox owners and agreeing a plan of action. Communication is important here, set the expectations clearly and you will have a smoother ride. Don’t second guess when it should be switched.
In an effort to reduce SYSVOL bloat and replication across Domain Controllers (DCs) consider using DFS Replication (DFSR). A bigger reason however is that FRS is no longer supported in Server 2012, so if you plan to upgrade DCs to Server 2012 – then you must do this first. Want a third reason? If you are using Read Only DCs (RODCs) and are still on FRS it is easy for the SYSVOL on the RODC to become out of synch with other DCs; better still in Server 2008 R2 and above DFS-R ensures that the RODC SYSVOL can never be modifed.
DFS-R simply provides better and more efficient synchronisation than the old world File Replication Service (FRS). Prior to proceeding you may want to indeed check and make sure that you are not already using DFS-R. Jump into a command prompt and type in this command:
If the output is shown as “Current DFSR global state: ‘Eliminated’” then you are already using DFS-R and there is no need to go any further. Stop right here.
|Did You Know:||the DFS-R migration process actually uses Robocopy (yes! Robocopy) to copy the SYSVOL data at various stages|
All Domain Controllers need to be online and available. If you have any redundant DCs listed and they have not been cleaned up (meta data an’ all!) then do so before starting this task
Depending on what Server OS and Service Pack Level you are on ALL DCs may need to be located in the default Domain Controllers OU. If they are located in a sub OU or elsewhere (for policy reasons usually) then consider moving them into the default location temporarily during the migration
The PDC Emulator MUST be online during the whole process – that’s the dude with the most up to date Policy and it is the DC that this whole process talks to the most
You need at least a Windows 2008 Functional Level for your Domain, so get rid of those soon to be end of life Server 2003 R2 DCs first
4 Steps to DFS-R
There are 4 steps to migrate from FRS to DFS-R using the Dfsrmig command:
- Health Check: Run the following commands to check the health of current replication
- Ensure there is enough free disk space on each Domain Controller for the migration
- Run repadmin /replsummary to ensure current replication is healthy, resolve any issues
- Run repadmin /showrepl * /csv > replication.txt to ensure current replication is healthy, resolve any issues in the output file
- Migrate to Prepared State: Use the command Dfsrmig /SetGlobalState 1 to begin the migration, use Dfsrmig /GetMigrationState to check the current status of this step. Do NOT proceed until this step is complete
- Migrate to Redirected State: Use the command Dfsrmig /SetGlobalState 2 for this second step, use Dfsrmig /GetMigrationState to check the current status of this step. Do NOT proceed until this step is complete. If you wish to stay with FRS for SYSVOL replication then stop here.
- Migrate to Eliminated State: [NOTE: There is no going back after this step! You have been warned] Use the command Dfsrmig /SetGlobalState 3 for this final step, use Dfsrmig /GetMigrationState to check the current status of this step. Once this step is complete so is the migration.
That’s all there is too it. Honest.
If you did execute Step 4 in error, then as I said there is no going back. Ever. Except of course unless you rebuild the whole domain (a whole lot of fun for you then!).
Clean Up Tasks – get rid of FRS!
Now that you have succesfully migrated to DFS-R you now need to
- Delete the old SYSVOL directory
- Disable and then Remove the NTFRS Service
You really should download and read the full Microsoft guide found here: http://technet.microsoft.com/en-us/library/dd640019(WS.10).aspx
As usual, get in touch if you have any questions.