Actually we can see a good market response to the new Microsoft Server flagships, Windows Server 2012 and Exchange 2013.
Migration projects are still ahead and probably will not die in 2013.

The following table shows the readiness of the Quest migration tool suite  and answers the question whether the tool can be installed on a Windows Server 2012, whether it can migrate Active Directory to Windows 2012 and mail systems to Exchange 2013.

Microsoft did not release a new version of ADMT yet (the most actual version is still 3.2), that is fully compliant with Windows 2012 functional mode domains, nor can you install ADMT 3.2 on a Windows Server 2012 member server. Actually, a migration from a Windows 2008 R2 domain to a Windows 2012 domain with 2012 functional level can neither be achieved by using the native tool (ADMT) nor Quest Migration Manager for Active Directory.

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.

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.

http://community.office365.com/en-us/wikis/upgrade/what-to-expect-during-the-service-upgrade.aspx

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.

https://support.quest.com/SolutionDetail.aspx?id=SOL105116&pr=Notes+Migrator+for+Exchange

QMM AD stores matching data in ADLDS and in Cache DB

From our experience, the Directory Service Agent component (DSA) from Quest Migration Manager for Active Directory is a reliant and powerful way to synchronize Active Directory objects and attribute data from one domain to another (and vice versa). It also has the ability to synchronize user passwords by installing a single agent on one domain controller. More than this, DSA is also responsible for mailbox creation in the Quest setup and synchronizes mailbox and Active Directory permissons.

The speed of delta synchronization (synchronizing changes of object attributes) is a combination of matching and caching. Quest DSA uses an AD LDS database to create matching objects that describe the synchronization relationship between an object in source domain and its peer in the target domain.

However, the ADLDS matching objects are most important when starting the synchronization and performing a Full Resync. In the ongoing synchronization, DSA takes the matching information from its cache which is a JET database located in “…\DSA\CONFIG\Cache” directory. The cache database file can grow up to a size which exceeds the size of the AD LDS by far. If disk space matters on your DSA machine, have an eye on the cache file size first.

Solving incorrect matching

By default, Quest Active Directory sync knows 3 criteria for object matching (the way, how DSA identifies, whether it has to merge an existing account in target or create a new one) – mail address, sid-sidHistory, samAccountName. Both decisions (merge or create) have consequences since DSA will create or modify the matching object and bind objects together, that should form a unity (or not).

However, we do not live in a perfect world and situations occur where the matching went wrong.

Real word scenario:

1. Group A is created in source domain, mail-enabled and filled with 10 members. It is part of DSA migration scope.
2. DSA picks up the group and looks up the matching criteria. All 3 criteria are activated and mail has highest precedence. DSA does not find a peer and creates a new group A in target domain with e-mail and the link resolver fills the group membership with the target user objects. DSA also creates a matching object and updates the cache file. So good so far.
3. Now somebody decides to create a new group B in source domain and shifts the mail address from group A to group B while the mail address on group A is renamed in the same step.
4. DSA will recognize that group B is existing and looks up for matching criteria. It will find a match for the mail address in group A of the target domain and will set up a matching of group source B to target A. It also will replicate the membership from source B to target A.
5. We have now a lot of uncomfortable issues. Membership in the DLs looks different for users in source and users in target domain. Group A in target has 2 entries in sidHistory, one for source group A and one for source group B. The matching attribute in group A from target domain is now filled with the object GUID from group B in source domain and the proxyAddresses including X.500 are mixed as well. Other attributes depend on your skip list settings
6.  And we still have group A in source. Since the matching criteria of sid-sidHistory is still valid, you can end up with a flip/flop, so that DSA runs over the two accounts and whenever there is a new attribute change on one of the source groups, it can either be group A or group B which is merged to group A in target.

OK, we should try to clean up the confusion.

1. We better remove mail address matching in our setup since it has problems with the domestic way of changing groups in this customer environment. We clean up all wrong values of group A in target. We run a full resync (which is restricted to once per quarter)
2. Same thing again, because the matching attribute was filled with the wrong value and the matching sid-sidHistory was still in place.
3. We clean up again and delete the matching attribute. We modify group B in source to trigger DSA and expect that a new group B in target is created.
4. Do we succeed? No. Of course not. There is a wrong matching object for group B (and group A) in ADLDS. OK. We clean up again and we delete the matching objects in ADLDS.
5. No way. The same thing happens again. No group B in target, but a matching of group A and group B to group A in target.
6. This time we stop DSA, clean up group A in target domain including wrong entries in proxyAddresses, sidHistory and delete the matching attributes. We delete the cache file and start with Full Resync – and we succeed

It’s all about cache. All the cleanup and repair actions can fail as long as the cache file still contains the wrong linking. Since a selective cleaning of the wrong object matching of the cache is not possible (anyone to try?), we always will need a full resync (of thousand objects) to repair a single object pair with wrong matching.

An alternative would have been to delete all 3 groups and create fresh objects. I would call it the “brute force method”. Not acceptable in many cases though.

Version 3.4.1 corrects minor problems and contains all existing hotfixes

Dell/Quest Software released a new version of Coexistence Manager for Notes. Actual Version is now 3.4.1.
The 3.4.1 is mainly focussed on correcting bugs and improving product Quality.
Coexistence Manager for Notes provides coexistence between Exchange and Notes E-Mail Systems and eases migration activities in large scale infrastructures.

The release 3.4.1 is compatible with Exchange 2013, Exchange 2010 SP3 and Outlook 2013 and provides enhanced iOS Support.

Improved Features sinceversion 3.4.0:

• a Directory Connector Engine for more granular control
• Simplified customization of object naming, Attribute mapping and filtering
• Exchange resource scheduling by Notes users during coexistence period.

One of the most useful features of QMM Active Directory synchronization is the ability to synchronize the password of user objects between Active Directory Domains. While Microsoft’s Forefront Identity Manager (FIM) first needs to capture the user password on the Domain Controller when the user actual changes the password, QMM can transport the password hash directly at any time. While FIM needs to install an agent on every Domain Controller to capture the password changes, QMM places an agent “on the fly” on only one dedicated Domain Controller. This can make a big difference in large Active Directory infrastructures.
However, running a long term “ongoing continous” Active Directory synchronization often shows one or many errors like this (snippet from Migration Manager GUI) and fails to update the password to the actual value:

The error is a  bit misleading here. QMM is purely transporting the password hash and therefore cannot measure the length of the user password nor can QMM prove the complexity. That means, we have to deal with a password history problem. Assuming we have the same password policies in source domain and target domain and an ongoing password synchronization, this error may never come up, because the password history policy of the source domain would prevent the user to change the password to a value that is still in the password history store.
But there is a second method of changing passwords: The admin reset of passwords. When an admimistrator changes (resets) the password on behalf of a user, he can set the password to a value that is in the password history store. An administrative reset can bypass the password policy. Our investigations showed that several users bypassed the password history policy by calling the help line …
After the administrative reset of the password in source domain, QMM directory synchronization agent (DSA) recognizes a change of the password of the user object and tries to replicate the password hash to the target domain user object. But the DSA has to go “through” the password policy check like a standard user password change which finally results in the password error message above.

You also can find specific error codes in the DSA log file:
05/07/13 08:32:45 (GMT+01:00)     Common AcAdSwitches Error 0xe100004f. Cannot synchronize passwords, source user: “<user name>”, target user: “<user name>” Error 0x8007052d. Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.

In part 2 of this post, we will show ways to work around the password sync error.

Migration Manager for Exchange 8.10 is available for download via the Dell/Quest support website along with CPUU 5.2. Remarkable is the support for single-hop Exchange 2003 to Exchange 2013 migration scenarios and public folder migration coexistence to Exchange 2013 public folder mailbox technology.
Together with Exchange 2013 as target mailbox system, wave 15 of Office 365 is also officially supported.

According to the release notes, QMM Exchange 8.10 provides the following features:

• Migrate Microsoft Exchange 2000–2010 mailboxes to Microsoft Exchange 2013 without locking users out of their mailboxes.
• Benefit from direct one-step migration from legacy Microsoft Exchange 2000–2010 servers to Microsoft Exchange 2013.
• Migrate your public folders from Microsoft Exchange 2000–2010 to Microsoft Exchange 2013 with co-existence enabled.
• Benefit from full two-way calendar (free/busy) synchronization between Microsoft Exchange 2000-2010 and Microsoft Exchange 2013 organizations during the migration.
• Migrate Microsoft Exchange 2000–2010 mailboxes to Microsoft Office 365 Wave 15 without locking users out of their mailboxes and without extra pre-migration steps. Set up full two-way calendar (free/busy) synchronization during the migration process.
• Consolidate your multiple source forests into the single Office 365 cloud.
• Migrate your Microsoft Exchange organization to an existing hybrid environment with single sign-on enabled.
• Use Migration Manager for Active Directory to create mail-enabled user accounts, and benefit from using the native move job for your Microsoft Exchange 2003–2010 to Microsoft Exchange 2003–2010 migrations (an Exchange 2010 CAS server in the source or target organization is required).

Client Profile Updating Utility 5.2 (aka EMWProf):

• Client Profile Updating Utility (CPUU): Support switching Microsoft Outlook 2013 user profiles from source to target Exchange server
• Client Profile Updating Utility (CPUU): Support for Windows 8 as an end-user platform
• Client Profile Updating Utility (CPUU): Support for Microsoft Exchange Server 2013 as a target.

(Source: “Release Notes for Quest Migration Manager for Exchange, April 30th”)

Dell published the version 8.10 of the migration software Quest Migration Manager for Active Directory. The new release 8.10 will allow using Windows 2012 domains and domain controllers in Inter-Forest migration projects as migration target infrastructure.

• Migrate objects to Windows 2012 Active Directory
• Synchronize objects with Windows 2012 Active Directory in both directions
• Synchronize passwords with Windows 2012 Active Directory
• Migrate SID-History to Windows 2012 Active Directory
• Migrate computers to Windows 2012 Active Directory

However, there is one limitation to mention at this point: Windows 2012′s breaking feature Dynamic Access Control (DAC) is not supported when trying to migrate from a non DAC to DAC permission model or from DAC to DAC.

(Source: Quest Migration Manager 8.10 Release Notes, last revised 5/7/2013)

Notes Migrator for Exchange Version 4.7 introduces a lot of new features and product enhancements

Dell published the Version 4.7.0.82 of the Notes Migrator for Exchange. One of the new features  is the BlackBerry migration support:

NME now supports migration of BlackBerry accounts and devices as part of a migration from Notes to Exchange. Specifically, NME supports migration from Domino BES 4.1 to Exchange BES 5.0

(Source: Quest Notes Migrator for Exchange 4.7.0.82 Release Notes, last revised 5/14/2013)

In part 1 of this post we explained why QMM Directory Sync Agent (DSA) might run into problems when sychronizing user passwords that have been resetted by using administrative credentials to a value which is present in the password history. In this post we will show how we can identify affected user accounts and how we can work around the issue.
As we have learned in the first part, there are 3 good methods to identify the password synchronization errors:

• QMM AD GUI – failed objects link in the Status page of the Active Directory synchronization
• QMM Error Reporter Utility - Quest Utility you can download from support site
• DSA Log File Parsing – you can parse the log files with any good Parser/Scripting engine

Methods of resolving the password synchronization Problem:

1. User changes password
The simplest approach to solve the problem is the user himself – maybe after contacting the user. When the user changes the password of his Acive Directory account the default way (e.g. via CTR+ALT+DEL). Changing the password this way will ensure that the password policy of the domain is enforced (instead of bypassed via admin reset). Assumed that password policies between source and target domain are aligned, Quest Active Directory Synchronization Agent (DSA) will successfully set the new password on the target user account.

2. User is forced to change password
Another method similiar to 1. is to force the user to change the password by setting the “User must change password at next logon” flag. This can be achieved by using ADUC for single users.

However, when it comes to mass operations, you can achieve the same goal by setting the attribute “pwdLastSet” to “0″ programmatically by using Powershell, VB etc.
Approach 1. and 2. have in common that you have to make sure that users do not call the help line and ask for an admin reset to their “usual” password again.

3. Temporary Fine Grained Password Policy controlled by DSA Parser script
Our customers often complain that they do not like to inform users to change their passwords with messages like “your actual password is not compliant with corporate policies – please change”. Educated users will ask: “How come that you know my password. We have been told, admins do not know users’ passwords …
Well, to workaround this situation, a new approach is possible if your target Active Directory domain is Windows 2008 or higher.
The plan:

• Increase DSA log file size to make sure you have a full DSA cycle in the log (optional). A full cycle will always work once through the failed objects queue and list the password sync Errors.
• Create a group in target domain that will contain user objects with password sync error.
• Create a Fine Grained Password Policy (FGPP) in target domain that contains the same password settings as the default domain policy with the exception of password history which is set to Zero
• Assign the FGPP to the domain group
• Create a script that parses the DSA log and fills the group. Empty the group before filling to remove already processed accounts

As you can see, the idea is to allow DSA temporarily and only once for the users with password sync problems to bypass the password history setting. This way the password transfer is possible and a further user migration will not end up in a logon error for these users.

From a security standpoint one can argue that bypassing the password history setting is not advisable. We share this opinion, but we have to recognize that the bypassing already started in the source domain. We neither improve the situation during migration, nor do we make it more worse. But we will prevent user logon errors to target domain later.

A scripting example (example, not more ) can be found here:

Powershell Script INPUT PWDUSER

Background
Migrating computers as part of an Active Directory migration has 2 aspects. There is an Active Directory object migration as it is with user and group objects. And in addition you have to disjoin the Windows computer from the old domain and join it to the new domain which requires to modify the workstation or server OS.
The most simple way to move a computer between domains is of course to use the GUI and change the domain or workgroup association of the computer in the system property settings manually.
However, this is not a solution for migration projects where you want to move many computers at the same time remotely logging on to the machines interactively.

Requirements
In our actual large scale migration project we have to deal with multiple thousands servers that have to be migrated to the new domain. While the client computers run through an SCCM controlled imaging process, the server domain move is the task of the server admins. Some of the server admins are responsible for large scale test and development environments with hundreds of servers.
To ease the one time task of domain migration for those administrators, our idea was to implement a remote service utility which can migrate servers to the new domain in bulk mode.
While we would operate and maintain the service centrally, the server admins should decide which servers to migrate and when to migrate them. Another requirement was to leave the servers as is without installing QMM agents that could interfere with running applications.

Solution
To be as most flexible as can be, we chose the add-computer Powershell commandlet for our scripting solution. (We ended up with a 320 line script to combine multiple modifications during server move). Server owners would place a config file on a share. The script server periodically scans the share for new config files and processes the server names.
While the final script contains multiple functions, the core function with the add-computer commandlet to disjoin/join the Computer can be found here:

function domain_move($compacc,$fqdn) {
$username_joinTarget=”TARGETDOMAIN\SERVICEACCOUNT”
$password_joinTarget=cat“d:\scripts\server_move\JoinTarget.txt”|convertto-securestring
$cred_JoinTarget=new-object -typename System.Management.Automation.PSCredential -argumentlist $username_joinTarget,$password_joinTarget
$username_unjoinSource=”SOURCEDOMAIN\SERVICEACCOUNT”
$password_unjoinSource=cat“d:\scripts\server_move\UnjoinSource.txt”|convertto-securestring
$cred_UnjoinSource=new-object -typename System.Management.Automation.PSCredential -argumentlist $username_unjoinSource,$password_unjoinSource
$Error.clear
Try {Add-Computer -ComputerName $compacc -DomainName $TARGETDOMAIN -Credential $cred_JoinTarget -UnjoinDomainCredential $cred_UnJoinSource -Server $TargetDC -PassThru -Verbose}
Catch {return $false}
Start-Sleep -Seconds 10
Restart-Computer -ComputerName $fqdn
return $true}

The variables $compacc and $fqdn come from the main part of the script as parameters when calling the function.
$compacc=”samaccountname of computer to migrate”
$fqdn=”full qualified domain name of computer to migrate”
The text files with the encrypted passwords are located in the same directory as the executable or ps1 script.

Discussion
The add-computer commandlet was introduced with Powershell 2, but had the restriction that you could only migrate the local computer and needed to run Powershell Remoting to make it useful for other computers.
With Powershell version 3 the parameter –computer was added which allows you to address remote computers for domain move.
Note: This parameter does not rely on Powershell Remoting
Another important parameter for us is –server which defines the target DC that will control the domain join operation. Since we are creating the computer object in the target domain in a specific OU in advance in the same script, it is important not to run into replication delays (trying to join while the computer object was not replicated). The –server parameter which never worked properly in Powershell version 2, did its job for us as long as we used the FQDN of the Domain Controller as syntax.
Note: If you cannot succeed with the domain\DC value for the –server parameter as listed in the Tech Net article, try out the FQDN instead.
A remarkable caveat of the add-computer commandlet for server domain move is the explicit input of domain credentials for disjoin and join actions. Even when the account that is running the script or scheduled task keeps all necessary permissions, you still have to pass account and credentials to make the domain join working. We suppose that this is a WMI restriction and that WMI is underlying code here. Check out the WMI commands below. To overcome this limitation we captured the encrypted passwords in 2 separate text files and only listed the service account in the script code. In the final version the script code was transformed into an exe file by using Powershell Admin Studio by Sapien Technlogies.
The add-computer commandlet also provides a parameter –restart. We cannot recommend to use this parameter, because it might trigger the reboot too fast, which can lead to RPC connection errors after reboot. We recommend to set a sleep time of multiple seconds and trigger a separate restart-computer commandlet which provides you with multiple options and restart dependencies.
We do not use the –path parameter but create the computer account in a separate function.
For a full amount of Parameters please check Tech Net.

Alternatives to the Add-Computer commandlet

Quest Resource Updating Manager
If you have deployed Migration Manager for Active Directory in your migration project, you can create collections for computers that should undergo a domain move. The collections can be filled by import scripts, so that you can achieve a semi-automatic solution.

While the main purpose of QMM Resource Updating Manager is to prepare the resources (file shares, local groups, registry etc) for the domain move (which either requires to install agents or to deploy vmover scripts), it also has an option to move computers remotely without installing agents.

NETDOM
Another option is the NETDOM JOIN legacy command which is around since Windows NT 4.
http://technet.microsoft.com/de-de/library/cc772217(v=ws.10).aspx
(To use netdom, you must run the netdom command from an elevated command prompt.)

WMI
Another way is to go WMI native and use the commands that might be underlying of the add-computer commandlet. However, we find WMI a bit “clumsy” for this purpose (we like it easy).
Example:
$currentserver= (gwmi -computername $Computer -class “Win32_ComputerSystem” -Authentication 6)
$currentserver.JoinDomainorWorkGroup($newdomain,$password,$username,$Null,33)

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.

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 Architecture
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.

Dell Software released a new version of Coexistence Manager for Notes(R). Coexistence Manager for Notes version 3.5.1 provides coexistence between Exchange and Notes E-Mail Systems and eases migration activities in large scale infrastructures.
New features include:
• Expanded Free/Busy support to include Lotus Domino 8.5.3 FP2
• Improved message conversion provides more robust coexistence with Exchange 2003
• More granular control of object names when Directory Connector performs an update
• Improved HTML fidelity for Outlook 2003 users

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.

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.

SIDCloner.dll
When you look in WWW to find a way to write sidHistory attribute, you probably will stop at the marvelous SID Cloner website created by Jiri Formacek, MSFT (http://code.msdn.microsoft.com/windowsdesktop/SIDCloner-add-sIDHistory-831ae24b). Jiri provides a managed class library that implements the SIDCloner class, which we can use in Powershell and any .NET programming code.
The SID Cloner class is built upon native API to migrate sidHistory and therefore uses the DsAddSidHistory function under the hood (http://msdn.microsoft.com/en-us/library/windows/desktop/ms675918(v=vs.85).aspx).
Although we do not need to install ADMT on any machine to run the SID Cloner code, we still have to consider to meet the same requirements for the migration setup as ADMT does. SID Cloner and ADMT come from the same “mothership” DsAddSidHistory.

SidHistory requirements
In brief we need the following prerequisites to be in place before we can start writing sidHistory (http://msdn.microsoft.com/en-us/library/windows/desktop/ms677982(v=vs.85).aspx):

+ a trust relationship must exist between source and target domain
+ source and target domain must not be in the same Active Directory forest
+ for source domain all actions will have the PDC Emulator as target; you cannot bind to another DC than the one with the PDC Emulator role
+ Auditing must be enabled in source domain
+ a domain-local group “domain$$$” must be created in source domain
+ a special registry key must be created on PDC Emulator DC in source domain: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\TcpipClientSupport
+ Audit Mode must be turned on in each domain and also Account Management auditing of Success/Failure events must turned to on.
+ the Security Identifier we want to transfer must not already exist in any sidHstory attributes of objects in target domain

Permissions:
For running Powershell code based on SID Cloner you do not necessarily need domain admin credentials in target domain. While read permissions on objects in source domain are sufficient (you are reading the “standard” attribute objectSID there), the permissions to modify the object in target domain by writing the sidHistory value requires more:
+ full access permissions to the object (better OU)
+ special permission “migrateSIDHistory” on the Active Directory domain object in target domain

With all the requirements settled, you are able to migrate sidHistory by using the sample script, that Jiri published on the SID Cloner Website.

However, the most easy way to use the 4 fold overload with SIDCloner did never work in our tests.
Overload with 4 arguments means, you simply define source and target domain, source account from which you want to take the objectSID and target account where you want to write sidHistory.
This approach will probably never succeed because
a) the strict PDC Emulator access is not guaranteed when using a domain call
b) the credentials of the interactively logged user are obviously not passed to the DsAddSidHistory function inside the SID Cloner dll

Let’s have more findings around this Topics in Part 3 of this blog post.

Dell Software released Version 8.5.1 of Recovery Manager for Active Directory Forest Edition.

The new release ships with multiple new features which were requested by many customers for a Long time:

Building virtual test environments
In the past the clone wizard provided only limited capabilities to build a test lab on base of our production Active Directory. Now the built-in logic of the Forest Recovery is used to create virtual lab to mirror an existing Active Directory.
The program component Active Directory Virtualization Lab works with MS System Center Virtual Machine Manager, VMWare ESX and VMWare vCenter.

Active Directory management capabilities
The tool now helps to manage Global catalog functionality and FSMO roles throughout your Forest’s domain controller infrastructure

Web Interface
The new Web Interface for Recovery Manager for Active Directory allows you to distribute the tool’s frontend much more easily

Support for BitLocker Drive Encryption when recovering Domain Controllers
If BitLocker is enabled on the domain controllers to be recovered, the tool will take care to disable BitLocker before starting recovery and to enable afterwards.

Enhanced Management Shell
Release 8.5.1 also ships with new Powershell commandlets to manage RMAD activities by script:
Expand-RMADBackup extracts the content of a backup file to a location you can select (same functionality as Extract Wizard from GUI)
Remove-RMADUnpackedComponent cleans up unpacked data from former restore operations
Remove-RMADCollectionItem removes items from a specific computer collection.

With Recovery Manager for Active Directory Forest Edition (RMAD FE) 8.5.1 you can restore Domain Controllers running the following OS Versions:

• Microsoft Windows Server 2012 (including Server Core installation)
• Microsoft Windows Server 2008 R2 without Service Pack or with Service Pack 1 (including Server Core installation)
• Microsoft Windows Server 2008 with Service Pack 1 or Service Pack 2 (including Server Core installation)
• Microsoft Windows Server 2003 R2 without Service Pack or with Service Pack 2
• Microsoft Windows Server 2003 without Service Pack or with Service Pack 1 or Service Pack 2

You can install Recovery Manager for Active Directory Forest Edition 8.5.1 on the following platforms:

• Microsoft Windows Server 2012
• Microsoft Windows 8
• Microsoft Windows Server 2008 R2 without Service Pack or with Service Pack 1
• Microsoft Windows Server 2008 with Service Pack 1 or Service Pack 2
• Microsoft Windows 7 without Service Pack or with Service Pack 1
• possible but not recommended:
  Microsoft Windows Vista with Service Pack 2
  Microsoft Windows Server 2003 R2 with Service Pack 2
  Microsoft Windows Server 2003 with Service Pack 2
  Microsoft Windows XP with Service Pack 3

You can view all additional Information on the DELL Website here.

If you need assistance in deploying the Software and set up an Active Directory Forest Recovery plan with this tool, please get in contact here.

In our large scale Active Directory Cross Forest migration project, we now have migrated already 40.000 user accounts globally. Our self made scripting routine to migrate/write sidHistory into the target accounts turned out to be a robust, reliable part of the process and I feel safe now to share some experiences. We are running it on multiple migration servers around the globe as scheduled task – which you can easily call a “service” as it is running every 5 minutes.
I will write about the whole mechanism of how we automated our large scale Active Directory migration in another blog post, but will concentrate here to share our way of managing the sidHistory part.
As you know already from part 2 of this blog post, we were buidling our code on the examples that MSFT Jiri Formacek published here.

However, 2 main restrictions prevented us from using this code as is:

1. We wanted to make sure that we really used the Domain Controller with the PDC Emulator role from source domain. Our source environment has 100+ domain controllers and the PDC role is siwtched from one DC to another DC under certain conditions. Therefore to use a fixed name for the PDC role Domain Controller was not acceptable.
2. Our Active Directory account migration process was fully automated and it was the user who starts his/her migration not us. Therefore the requirement was given, that we only can run sidHistory migration (together with the account activation in target domain) as a continuous background service. Every session based approach would not have helped like we can find it in ADMT or Dell Migration Manager for Active Directory.
   Prepopulating sidHistory on the previously created disabled accounts in target domain was not an option, since Exchange 2010 was giving errors for disabled users with sidHistory of source active users under certain circumstances.

Solutions:
1) This was not a big thing. A small function could do the trick.

function getPDCE($domain) {
$context = new-object System.DirectoryServices.ActiveDirectory.DirectoryContext("domain",$domain)
$PDC=[System.DirectoryServices.ActiveDirectory.Domain]::GetDomain($context).PdcRoleOwner.Name
return $PDC
} 

2) This was not that easy (for us). Running our account migration script as usual – means as scheduled task with admin credentials – did not work for the sidHistory part in it since the credentials of the logged user account were not handed over to the SIDCloner routine.
All the code we could find on Jiri’s page asked for credential information interactively or would need explicit credentials in the script in another way.
Although we are packaging our Powershell Scripts into an .exe file by using Sapien Powershell Studio and could hide the password from simple file editing, putting user name and password into the script was not an acceptable way for us to go.
After testing back and forth, someone cam up with the idea of using the Windows credential manager to work around our deadlock situation.
The script would access the credential manager interface, get the credential information from there and would then pass them to the DsAddSidHistory function.
We created a function to retrieve credentials from Credential Manager store based on a very good script example to be found on Technet here.
While this seemed to be a clever way of achieving our target of having a scheduled user account activation script with sidHistory functionality, we ran into errors again. Retrieving credentials from Credential Manager by script obviously fails, when the script runs with exactly the credentials that you want to retrieve. This was true in our case, because the user account migration script was scheduled with that “big admin” account.

The solution finally was:
The user account migration script was running as a scheduled task with full admin credentials. When it came to migrate (in our project setup: activate) a user account in the target domain, it did not (could not) write sidHistory, but created an input file with username and target DC (the DC closest to the site where the user was had logged in from – remember that the user triggers his/her migration in our project).
On the same migration server a second script was scheduled with a server-local admin account. This script consists of 3 parts. First part is to check if there are new input files. Second part is to retrieve the full admin credentials from Credential manager and passing them to second part. Third part is to migrate sidHistory which succeeds because you have put all parts together for the SIDCloner routine:
PDC Emulator DC for source you have found by query.
Target DC was in file (but you can take every writable you want if replication delay does not matter).
Explicit credentials you get from Credential Manager.
Nowhere in both scripts password information is saved in clear text.

Further information:
The SIDCloner routine is an “add” not a “replace” operation. If you have already an existing sidHistory value from other migrations, the script will add the value to the array of the existing ones.
Caution: Mulitple sidHistory values will again increase your token size!
Caution: Scripts based on the SIDCloner code will make it possible to add the objectSID from user A from source domain to user B in target domain. This is a potential security issue. To avoid it is in the admin’s responsibility and in terms of the script, that the matching from source domain user to target domain user is 100% bulletproofed.
If somebody is now disappointed in the end of this blog post that I am not going to provide our code to the public, my answer is that I am sure that an admin who is able to produce the scripting code now, will also be able to understand the pros and cons of such a “homemade” sidHistory solution.

I gave you all the ingredients and most of the recipe – but now you have to cook yourself!

Microsoft released a Preview of the Windows Management Framework V5. As in the past, this package ships with the according version of Powershell. Powershell V5 will bring interesting new Features.

Among those are:

1. OneGet module with a set of comandlets to manage Software packages
2. Commandlets to manage L2 Layer Network Switches

Find the introduction article for Windows Managagement Framework V5 by Jeffrey Snover here on TechNet.

You can dowload the Preview here.

However, the mixture of Powershell Versions we find at customer Environments will get wider and wider. Same is valid for modules like ActiveDirectory or SnapIns for Exchange. One will need to start with a lot of checks in the beginning of the code when a script is planned to be used universally.

We used Quest Migration Manager 8.10 recently in a project at a customer for a combined Active Directory and Exchange migration. Overall target was to integrate a Windows 2003 domain cross forest and cross org into the central AD Forest with several child domains. Since from mail perspective our migration source was Exchange 2007 and our migration target Exchange 2013, we decided to use the Native Move Job option along with the Migration Manager for Exchange Agent (MAgE) services.

Situation:

The customer environment look like the following:
Source Domain in Single Domain Forest with Domain Controllers on Windows 2003 and Exchange 2007 as mail system.
Target Domain was one of several child domains in the central Forest. All domain controllers running Windows 2012 R2 and mail system was Exchange 2013 SP1.
All Exchange 2013 servers had been deployed to root domain which also kept all important system and admin accounts.
To limit complexity in the setup of Quest Migration Manager 8.10, we decided to use a single administrative account from target Forest’s root domain and granted all necessary permissions in the domains to run both, Active Directory and Exchange migration. Only for access to source Exchange 2007 when running the move request, we used an account from source domain with Org Admin permissions.

Setup for Native Move Job

Installation of Migration Manager 8.10. on a member server in target domain (best practice recommendation) including all cumulative hotfixes went smoothly. After successful Directory Synchronization, we connected to the Exchange source and target Organization and finally deployed 2 Instances of the MAgE agent for native mailbox move jobs on our agent host and console server. Note: For agent hosts Windows 2012 R2 is currently (May 2014) not supported. You have to stay with Windows 2008 R2 here.

Problem:

However, after starting the agent services running with our administrative account , we recognized, that we could not open the log file of the agent in the Log Panel inside the Migration Manager for Exchange GUI. We searched for the log file and found it in “c:\progamdata\quest software\Migration Agent for Exchange\NativeMove directory”.

Log snippet from MAgE agent

The log file showed that the agent was not starting to process the migration collection due to missing settings and then went to sleep. The lines of error:

Waiting for agent settings: Not found: (&(objectClass=serviceConnectionPoint) …..

Agent is not ready to start. Agent going to sleep at 1 minute.

repeated over and over.

Obviously the agent tried to execute an LDAP query to find a connection point in Active Directory.
Note: Currently QMM 8.10 uses 3 different systems to store configuration data: An ADLDS server, a SQL Server Instance and the Active Directory (ADDS).

Service Connection Point (SCP):

We ran the query which was shown in the log file against the target domain and we could find the Service Connection Point (SCP) immediately in the System container of the domain naming context.

The Service Connection Point consists primarily of the keywords array attribute and the serviceBindingInformation attribute. The QMM MAgE looks for the serviceBindingInformation attribute to get its SQL connection properties. In SQL it will finally find all information to process the collection.

We do not know why Developers at Dell Software made this process so complex. However, in our setup the agent could not find the Service Connection Point, because the agent was looking in the domain, where its service account was located and this was the root domain of the forest while the agent host had installed the SCP during installation in the child domain where the computer account was member of.

Solution:

Switching the agent host and agent service account to an account from child domain would have been a solution, but was not in compliance with customer policy to host all system accounts in root domain.
Moving agent host and console to root domain would not have meet best practices and would have interfered running directory synchronization.

So we ended up in giving the agent just what it requested:
We manually created a Service Connection Point in the root domain and copied all serviceBindingInformation values over.

The agent started immediately and worked without errors.

For future design we can only recommend to store Service Connection Point in the Configuration Partition as Exchange and lots of other software. Using the domain naming context will always lead to problems in a big Enterprise environment with Active Directory consisting of multiple domains in a  forest.