The adventure of sidHistory
I spent quite some hours during the last weeks to create a Powershell script routine that is able to “migrate sidHistory”. Migrate sidHistory in this context means to read the objectSID of a given user or group source object in Active Directory Forest A and write this value into the sidHistory attribute of a selected user or group object in Forest B.
Assuming there is a trust relationship between Forest A and Forest B and sidFiltering is disabled, user B from Forest B who has the sidHistory attribute filled with the SID of the user A from Forest A will have access to the same resources in Forest A like user A himself. The reason for this behavioris found in the fact that the security token of User B after successful logon will contain the SID of user A. From Windows’ token based access strategy, user B is now a user AB as long as we are talking about SID releated resource access.
From those few lines everyone agrees on the statememt that sidHistory functionality can be abused to get access to resources which are restricted for a user by default. In principle, you can add the SID of a given user from Forest A to any user in Forest B. There does not have to be a dedicated relationship like identical samaccountname of the two users (groups) etc. While exactly his functionality helps to ease Inter-Forest Active Directory migrations (and Intra Forest Migrations as well when you take care), it can also be a dangerous thread against your Active Directory security.
However, this not a new finding and Microsoft did well in treating sidHistory as a special attribute. It needs special treatment when you try to clear the values and it needs special treatment when you want to write values into it. I already published 2 posts about deleting sidHistory, see [Link], so we will concentrate here on writing sidHistory.
The most common way in today’s Active Directory migration scenarios is writing sidHistory by using a migration software. Microsoft ships its own migration software called Active Directory Migration Tool (ADMT) which is capable of writing sidHistory. Other vendors like Dell Software’s Migration Manager for Active Directory (formerly known as Quest Migration Manager for Active Directory) provide a similiar functionality with a lot more options and the possibility to write sidHistory in an ongoing Active Directory Synchronization. Up to now Microsoft Forefront Identity Manager cannot help us here out of the box to fill this attribute as part of an Active Directory synchronization.
When you try to put a SID into the sidHistory attribute by using the standard Microsoft administrative tools like the attribute editor from ADUC, you will fail for sure.
You will also fail by using Powershell integrated LDAP based write operations for this attribute like set-aduser or set-qaduser.
We have to dig deeper here to reach our goal of Powershell based writing of sidHistory, which we will do in Part 2 of this blog post.
Exchange Product Group announced and recommended the Ignite Summit events, which are held in 4 location around the globe:
Hong Kong, 7-10, 2013
Prague, Oct 21-24, 2013
Washington DC, Nov 4-7, 2013
Dubai, Nov 18-21, 2013
The 3 days track of session is designed and delivered by product experts from across Microsoft (Engineers, Technical Writers, Product Managers & Consultants). The over 70 session cover topics from Office, Office 365, SharePoint, Exchange, Project, Yammer and developer content.
The Ingnite Exchange Track comes with this agenda actual:
Day 1 Ignite Keynotes
Exchange Deployment & Coexistence
Storage, High Availability & Site Resilience
Day 2 Exchange Managed Availability
Exchange Server Sizing & Performance
Exchange Server 2013 Virtualization Best Practices
Collaboration with Exchange
Exchange Online Hybrid Migration
Day 3 Archiving, eDiscovery & DLP
Exchange Online Protection Overview
Implementing Exchange Online Protection
Exchange Tips, Tricks and Troubleshooting
Microsoft Partners register here.
Not Microsoft Partners register here.
Following the communities in the Web we found surprising news from Microsoft. In a letter to the achievers of the Microsoft Certified Master Program, Microsoft announced the decision to cancel (“pause”) the Master certification track while leaving the title valid for now. Find more Information on Devin Ganger’s Blog.
The arguments of Microsoft to stop the program include costs of the track, poor contribution of the MCP community and the obvious existence of “non-technical” barriers for many candidates like the extensive costs and the English-only approach.
Microsoft’s Tim Sneath:
“We want it to be an elite community, certainly. But some of the non-technical barriers to entry run the risk of making it elitist for non-technical reasons. Having a program that costs candidates nearly $20,000 creates a non-technical barrier to entry. Having a program that is English-only and only offered in the USA creates a non-technical barrier to entry. Across all products, the Masters program certifies just a couple of hundred people each year, and yet the costs of running this program make it impossible to scale out any further.”
Find the full text here.
In these days Microsoft is moving from wave 14 to wave 15 for Office 365 cloud installations. This means a service transition from Exchange 2010 Server backend to Exchange 2013 Server backend, Lync 2010 to Lync 2013 and other cool updates.
However, if you have travelled a long way to get a smooth migration setup (with all the back and forth of finding the right strategy and technical conditions) Microsoft can make you a big surprise by changing your Exchange target infrastructure. You started your migration project with Exchange 2010 in the cloud as target system and you end up with Exchange 2013.
This is “by design” when moving services to the cloud – as MVP Sean McNeill stated in his post [http://office365evangelist.com/?p=938]:
“This is an important questions because with a move to the cloud, the company give up some control on when, and even if, you will go through an upgrade of the service. The company now relies on the Service Provider, Microsoft in this case, to handle the upgrade and the cadence of the upgrades. This needs to be fully understood and accepted by a company moving to the Cloud.”
To mitigate the risk of forcing the customers to update in times where it is just neither “comfortable” nor “amusable” – as it might be in the middle of an Exchange migration project – Microsoft offers to postpone the update one time. The Office 365 admins receive a notification e-mail which announces the update schedule. From that information the customer has 3 weeks to decide that he better postpone or let Microsoft execute. When he decides to postpone, Microsoft will not start the update for the next 2 months. The timespan to complete the wave 15 upgrade is end of 2013 latest, which means your upgrade cannot be later than this deadline.
For more information check the Office 365 Upgrade Center: http://community.office365.com/en-us/wikis/upgrade/office-365-service-upgrade-center-for-enterprise.aspx
Dell/Quest Software seems to recognize first problems in running migration projects and recommends to postpone the Office 365 tenant upgrade by contacting Microsoft.
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.