A steady bidirectional AD sync with QMM worked for 6 months.
Now, the directory synchronization does not start anymore.
After a lot of try and error I found a solution and want to share it with you.
Problem: Active Directory synchronization does not start anymore
A bidirectional synchronization among two Active Directory domains with app. 180,000 objects had run steady for about 6 month with Quest Migration Manager. Then suddenly I got error messages about insufficient synchronization. Changes to the source domain were not transferred anymore.
The error messages were triggered by a self-developed supervision of the synchronization via PowerShell.
An analysis of the logfile DSA.log under C:\Program Files\Quest Software\Migration Manager\DSA\CONFIGS\dsa.log showed that the same 78 objects were stuck in the processing queue for hours.
Restart and ‘full resync’ did not solve the problem
A restart of the synchronization and a reboot of the DSA server did not solve anything.
The service immediately started with the above mentioned objects in the queue.
I hoped to solve the problem and initiated a ‘full resync’ after having consulted with the responsible team.
According to my experiences with QMM I did not think of that as being a big thing:
‘Sync Stop – Start full re-sync – done’.
After the Incident management agreed to the action I ran the ‘stop / full re-sync’ and went to a meeting.
Logfile shows ‘Counting ADAM statistics‘ and ‘ADAM statistics counted‘
Later I checked the logfile and saw that the sync did not work as it should. In regular intervals the DSA agent produces statistics which are displayed i.e. on the console. This action is recorded in the logfile and is usually forgotten among all the other entries. The present logfile showed something else, though. The entries ‘Counting ADAM statistics‘ and ‘ADAM statistics counted‘ followed each other in a high frequency and were the only ones in the logfile.
6:04:23 PM (GMT+01:00) Configurator Statistics: Counting ADAM statistics for job
6:04:24 PM (GMT+01:00) Configurator Statistics: ADAM statistics counted for job, time: 1.07102.
6:05:34 PM (GMT+01:00) Configurator Statistics: Counting ADAM statistics for job
6:05:39 PM (GMT+01:00) Configurator Statistics: ADAM statistics counted for job, time: 5.52799.
6:28:42 PM (GMT+01:00) Configurator Statistics: ADAM statistics counted for job, time: 5.74495.
6:29:00 PM (GMT+01:00) Configurator Statistics: Counting ADAM statistics for job
6:29:01 PM (GMT+01:00) Configurator Statistics: ADAM statistics counted for job, time: 1.23316.
6:30:42 PM (GMT+01:00) Configurator Statistics: Counting ADAM statistics for job
According to my experiences that behavior was not normal. I expected an ‘initial synchronization time’ of 36 hours – to me it as an error.
Step-by-step solution: QMM – Fix Directory synchronization
- A new ‘stop’ + ‘full resync’ after app. 15 seconds led to the same erroneous result.
- Deleting the cache (C:\Program Files\Quest Software\Migrationmanager\DSA\CONFIGS\Cache) + ‘full resync’ – brought no improvement
- Emptying the Microsoft Message Queues + ‘full resync’ – did not help
- A repair-installation of the agent + ‘full resync’ – didn’t help either
- Moving the sync jobs to another server, uninstalling the agent, deleting all directories, reinstalling the agent, moving the sync job back to the DSA server + ‘full resync’ – no solution
I just had one last idea:
- Stopping the synchronization
- Moving the sync jobs to another server
- Uninstalling the agent
- Deleting the directories
- Uninstalling the message
- Rebooting the server
- Reinstalling the message queuing components
- Reinstalling the agent
- Moving the sync jobs back to the DSA server
- Starting ‘full-resync’
And finally the sync job ran again!!!
Tip: For a reinstallation of the message queuing components the DSA agent has to be reinstalled as well as the message queuing components are registered during the agent setup. Without that the connection to the message queues is erroneous.
The second good message –of course- is that the synchronisation runs smoothly again after a re-sync. The problem with the same 78 objects stuck in the queue is solved.