Recommended Blog Post: The good, the bad and sIDHistory

Posted on by rkmigblog

Based on various experiences with Exchange 2010 behavior after an Exchange and Active Directory Inter Forest Migration, Exchange PRO Ingo Gegenwarth published this interesting Post:

The clueless guy

This post is about my personal journey with a cross-forest migration.

When it comes to account migration there is no way to do so without sIDHistory. It would be really hard to have a smooth migration without.

By using this attribute a end-user most likely won’t experience any impact…..unless you start doing a cleanup of this attribute.

In terms of Exchange users might see something like this

Calendar_Error

or this

Inbox_Error

But what’s behind those issues and how could you mitigate this? I was part of a migration, where those issues popped up and I’m going to describe how you could determine possible impact for end-users before it happens.

View original post 3,675 more words

Exchange Migration first & Mailbox Folder Permissions

Posted on by slshareadex

In many inter forest migration projects, the mailbox migration to the new Exchange Organization into the new forest is performed first and the user migration is performed in a separate step at a later time. After the mailbox migration and before migrating the user objects, you have a classic Resource Forest scenario. Users are created as disabled user accounts in the target forest, receiving a linked mailbox, connected to the source Active Directory user. Important AD attribute in this scenario is msExchMasterAccountSID. This attribute of the disabled target user object holds the objectSID of the source user account. This allows to connect to the own mailbox and shared mailbox resources (Delegate permissions etc.) with the active source user object.

ExMigirst01

Did you ever thought about mailbox folder permissions in this scenario? 

For every migrated folder permission (e.g. with QMM for Exchange) and also every time a user manually adds mailbox folder permissions for another (not Active Directory migrated) user in the target mailbox, the SID of the source user object is added to the mailbox folder permissions. In this example, we’ve selected the not migrated user UserA from the Global Address list and added him as delegate for the Inbox and the calendar for the Info MBX:  ExMigirst02

At some point, the Active Directory migration will start. During this process, the user account in the target domain will be activated and the Linked Mailbox is converted to a User Mailbox. This action will clear the attribute msExchMasterAccountSID. This is necessary because the target account will now be used to access the own mailbox and resources of other mailboxes. If a migrated user is now added to the mailbox folder permissions, the target SID will be added and no longer the source SID. Let’s use the mailbox example above and add the migrated user UserB as additional delegate for the Calendar of the Info MBX:ExMigirst03

In this example, UserB will of course not have any problems accessing the Info MBX. But what happens if UserA will be migrated and the user starts accessing the Info MBX with TARGETDOMAIN\UserA? The SID of the target account has no permissions on the Inbox and the Calendar folder. Will UserA loose access to these folders now? Generally, the answer is YES, UserA will lose access! But…

In Active Directory Migration projects, it is best practice to migrate the SIDHistory to the target user account. In this case, the objectSID of the source user is copied to the attribute SIDHistory of the target account. For our example, it means that UserA will not lose access to the Info MBX because his Access Token contains the Source SID which has permissions on the Inbox and Calendar folder in the Info MBX.

SIDHistory CleanUp & mailbox folder permissions?

Clearing SIDHistory is part of most of the migration projects. Before clearing the SIDHistory attribute of the target accounts, it is required to replace the source SIDs with the corresponding target SIDs inside the mailbox folder permissions. This process is called ReACLn. Without this action, many users will lose access to shared mailbox resources when the SIDHistory attribute is cleared.

Exchange Processing Wizard (Part of Dell Migration Manager for Active Directory)

Dell migration Manager for Active Directory contains the Exchange Processing Wizard. This wizard is able to replace existing source SIDs with the matching target SIDs for permissions inside the exchange environment. The wizard is using the matching information in the QMM AD LDS database, created during the directory synchronization.

To ReACL permissions inside the mailboxes, we have to select the option “Update client permissions”:

ExMigirst04

Now we can choose to process all Public Folders and Mailboxes or select individual Mailboxes or Public Folder or even skip Public Folders or Mailboxes completely:

ExMigirst05

The wizard provides the possibility to only process one server or process multiple servers in parallel.

Known limitation of the Exchange Processing Wizard:

The wizard is unable to set the Free/Busy permissions Free/Busy time, subject, location. After processing, the permission is changed to Free/Busy time only:

ExMigirst06

Good to know – Check real SID behind folder permissions

Get-MailboxfolderPermission: Unfortunately, as long as the SIDHistory is set for a user, Exchange will always resolve the permissions to the target account. So Exchange will always show the TARGETDOMAIN\User although in fact the source SID has permissions on the mailbox folder. You will also see the same result if you query folder permissions via EWS (e.g. with EWSEditor).

MFCMAPI:

To check which SID is really behind the permission, you can use MFCMAPI to access the mailbox.

  1. Create a new profile for mailbox and disable Exchange Cached Mode.
  2. Start MFCMAPI
  3. Click Session->Logon and choose the profile you’ve created in step 1.
  4. Double Click the Mailbox entry and now navigate to the folder for which you want to display the permissions.
  5. On the right side, now double click PR_NT_SECURITY_DESCRIPTOR

In the Smart View, you can see which SID is really behind the Access Control Entry.

Quest Migration Manager for Exchange®: 10 commendments for EMWProf usage

Posted on by rkmigblog

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)

 

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.

Quest Migration Manager for Exchange(R): Do we need a Free/Busy sync agent when we are migrating from Exchange 2003?

Posted on by rkmigblog

A customer was recently wondering how he should use the Quest Migration Manager for Exchange Free/Busy synchronization when migrating from Exchange 2003 to Exchange 2010 in an Inter-Org Exchange Migration.
The customer Exchange 2010 Environment was in native mode and did not contain System Public Folders to Keep the Free/Busy system messages.
Does that mean, updated Free/Busy data will not be available during the mailbox migration period where we have to maintain mailboxes in 2003 and 2010 in coexistence?
The answer is no.
Free/Busy data is maintained by running the Quest Calendar Synchronization (either uni-directional or bi-directional) between the corresponding mailboxes in source and target Exchange Systems.
Even when we have a target Exchange System with Free/Busy System Folders, we do not have to configure a Job for the Free/Busy Synchronization Agent. The Calendar Sync Agent takes over the Free/Busy publishing. You can find this action reported in the Calendar Sync Agent log (EMWCSA.log). The Free/Busy publishing period can be configured in the config.ini file of the Calendar Sync Agent, a smaller time period speeds up the Calendar Sync performance.

Recommendation: Make sure that you’ve deployed a sufficient number of Calendar Sync Agents to ensure a quick sync cycle. You do not need a dedicated Free/Busy synchronization job then.

Recommendation: If your target Exchange System does not contain Free/Busy System Public Folders, set your Free/Busy Publishing Period in the config.ini file of the Calendar Sync Agent to 0.