Migration Manager for Active Directory (QMM/AD) – version 8.10 is available with Windows 2012 Domain Controller support

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)

Quest Migration Manager for Active Directory – password error when synchronizing user objects – part 1

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.

QMM AD – Incorrect Directory Synchronization Agent Matching, Caching and Repairing

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.

DSA cache files

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.

Dell Quest Migration Tools: Readiness for Windows Server 2012 and Exchange 2013

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.

Active Directory Product Version Tool installation on Windows Server 2012? Can backup/restore AD data on Windows Server 2012 DCs? OR Can migrate data to Windows 2012 DCs?
Recovery Manager for Active Directory Forest Edition 8.2.1 yes yes
Recovery Manager for Active Directory 8.2.1 yes yes
Migration Manager for Active Directory 8.9 No no
Migration Product Version Tool installation on Windows Server 2012? Can migrate data to Exchange 2013? Office 365?
Migration Manager for Exchange 8.9 no no/yes
Migration Manager for Exchange IntraOrg Edition 1.0.1 no yes
Notes Migrator for Exchange 4.6.1 no (no Windows 8 admin workstation) yes/yes
Coexistence Manager for Notes 3.4 no yes/yes
Groupwise Migrator for Exchange 4.2 no (no Windows 8 admin workstation) yes/yes


Quest Migration Manager for Active Directory®: QMM vmover’s registry access blocked by security software

In our Exchange and Active Directory migration project we recently deployed a vmover package on a large number of client computers where QMM vmover.exe performs all resource updating locally without stressing the network. The results were quite positive, but after a while the Client protection team of the customer, who is actually running McAffee® security software on all client computers, was complaining about vmover activities. The security software identified vmover as intruder and blocked actions.
They said, that vmover.exe would try to add new keys in the McAffee® agent part of the registry. We could not believe that, but the AccessProtectionLog.txt of McAffee® exactly provided evidence:

14.01.2013 14:49:37
Blocked by Access Protection rule          NT AUTHORITY\SYSTEM
C:\Program Files\Quest\vmover\Vmover.exe
Common Standard Protection:
Prevent modification of McAfee Common Management Agent files and settings
Action blocked :

Our settings in vmover.ini did allow vmover to update registry keys, which means Re-ACLing of permissions on registry keys, but we did not have an explanation why vmover would create something outside the user hive when updating user profiles.
Using the ProcessMonitor it was even more obvious that vmover.exe tries to create keys in the registry.


The response from Quest Development came after short time:

What we saw in Process Monitor did not necessarily mean that vmover actually tries to create anything in there, but it’s rather the fact that RegCreateKeyEx function is used to enumerate the registry. There are two functions, one is RegOpenKeyEx and second is RegCreateKeyEx, both can be used to read information from a key, but the later will create a key if it does not exist depending on parameters passed. RegCreateKeyEx is used by Vmover for performance reasons. Also the entire registry is processed when process registry option is selected and all services are enumerated this way in registry when service processing is enabled.

With those arguments we got back to the Client protection team and after spending a beer or two, they agreed to put McAffee® on the Whitelist which solved the access block problem.
Good to know how things work.