Updating Outlook profiles after completing the back end mailbox switch is required to connect the user to the target mailbox.
Quest Migration Manager for Exchange ships with the CPUU (Client Profile Updating Utility), aka EMWProf, to streamline and automate this task. Although the configuration of a starter script is easy, we usually end up with an educated script that does a lot around the EMWProf procedure to avoid issues and to prepare for other services like Lync and Exchange UM.
Based on the experience of several long time projects we recommend to have a look into the following aspects.
10 things to know about Outlook profile updating with EMWProf (CPUU)
- Check if Outlook 2010 is configured with multiple accounts. Since there is a restriction with CPUU, users with multiple Exchange accounts in a single Outlook 2010 profile have to reconfigure Outlook or need to be supported after migration.
- Running EMWProf with administrative credentials can save a lot of access problems when switching profiles. Passwords are encrypted as a feature of the CPUU and this works fine.
- Running into the EMWProf script each time when a user logs on, creates too much impact. You can create a group, where membership is given after backend mailbox switch. You can create a check in the EMWProf script that checks whether EMWProf did run before on the client and prevents additional starting of the EMWProf procedure.
- Disable Windows Search. In many cases, Windows Search locked the ost file because of indexing and EMWProf could not rename it, what EMWProf caused to fail. You cannot stop the Windows Search service because it restarts by itself. Disable and enable afterwards. With Lync client installed and integrated with Exchange/Outlook, several Lync processes are active and block EMWProf from working properly.
- If the user has multiple profiles configured in Outlook 2010, EMWProf tries to process all of them and will create a return code that is not unique. You should first scan the registry for Outlook profiles in CPUU script and then run dedicated EMWProf for each profile, to get the return code. EMWProf will also send a message for each profile separately, which makes it easy to differ between good and bad, important and unimportant.
- Deployment of EMWProf via logon script is not enough in nowadays. Many laptops stay in Hibernate only and are unlocked w/o domain logon. As a fallback, a link in the Goodbye message should point to the EMWProf script and can be executed by the user. More advanced solutions distribute the EMWProf binaries via software distribution and the EMWProf script checks first, whether the binaries exist locally and if not, it pulls them from a remote share before executing. This helps a lot in small bandwidth scenarios. Even more educated solutions use a migration database where the EMWProf script can upload the results of the client side part of the mailbox migration.
- For terminal server use you should configure a specific EMWProf script. Processing of offline profiles is not necessary there as an example. Make the script as slim as possible and it will work fast and with less issues.
- Sometimes localized Goodbye/Welcome messages sent by QMM switch procedure are important. You can change the message text per Mail Source Agent. If you have regional based setup, you can send localized language mails easily by feeding the MSAs with a specific message text.
- Do you need a Welcome message sent by QMM? It has advantages and disadvantages. If mailbox switch and Outlook switch was successful, why confusing the user with more technical explanations and notifications.
- Heaven and hell of transferring read/unread status of items. QMM mail agents sync read/unread status and CPUU does as well to fill the last gap. This is very helpful to make the target mailbox experience for the user close to the “zero impact” (Quest language!) idea. However, this feature can turn into black, when the user starts to work for weeks with his Laptop and his new mailbox, then goes back to his Desktop Computer, is still connected to his old mailbox and executes EMWProf again. It does what it should and will make the items in target look like in the source mailbox. Be careful, we have seen assistants being very set up when realizing that they have 120 unread messages in the inbox from past weeks [again]. For the very same reason we do not use the SwitchRESMBX utility in situations where people work with passive (not yet switched) mailboxes in target.
Cloudy Migration Life 
Hi, quick question. We are migrating an environment where the source users will stay on their domain after switch; there will be no workstation migration, only mailboxes. It’s expected that users will have to have their target accounts enabled and use this to logon to the mailbox correct? If users change their source password you would need to remigrate to keep passwords synced?
Thanks for any help
Hello John,
the most common Scenario here is an Exchange Resource Forest Scenario, where one Domain keeps the user accounts and another Domain in a different forest keeps the mailboxes. The forests have a trust relationship, so that the Exchange Resoource Forest trusts the account forest (resp. Domain). In this Scenario, the mailboxes are configured as “linked mailboxes”. Linked mailboxes are associated to a disabled user object in the Resource Forest, but have an account from the account Domain configured as msExchMasterAccountSID. The msExchMasterAccountSID acts like an access redirection. Logging on to the account Domain, the user has full Access to his Mailbox in the Exchange Resource Forest. Therefore a Password sync is not needed in this Scenario nor a sidHistory Migration. The whole Scenario only works when accounts in Exchange Resource Forest are disabled.
Hope that helps
Robert
Great, thanks for the response and your site is very helpful; keep up the good work.