-
Title
ADPW known issue when cleaning up SID History in another domain -
Description
QMM 8.5 Release Notes mention this known issue:
Active Directory Processing Wizard: Active Directory Processing Wizard cannot perform the Cleanup SIDHistory operation on computers running Windows Server 2008 or Windows Server 2008 R2, if Active Directory Processing Wizard is running on computer located in other domain and trusts are established between these domains.
What does this mean? -
Cause
This is a rare scenario when console is located e.g. in the source domain and you attempt to clean up sid history in target domain and you use separate credentials (not the credentials of the currently logged in user) and you work over a trust and the target server is a Windows Server 2008 or Windows Server 2008 R2
Symptoms and causes
Administrator runs Clean-up and the wizard connects to a 2008+ DC randomly (accidentally) or because this DC is specified under Preferred DC options.
The wizard tries to open 64-bit Registry remotely but fails with Access denied error. After that the wizard mistakable decides that the host is 32-bit one and sets up an agent for 32-bit Windows. Finally, it fails. All consequent attempts will fail too. Wrong version of agent still persists on the host and should be deleted manually using sc.exe utility shipped with Windows Support Tools. -
Resolution
Workaround
To avoid this problem customer running the ADPW when logged in as user who is not an admin in the target should use runas /netonly command and supply target administrators credentials.
Another option is to create a shortcut to the wizard and then run it using the Run As option. Target administrator, whose credentials are being used, should have administrative rights to the selected DC to be able to connect to the registry of this computer remotely. Usually Domain Administrators permissions suffice unless they were restricted to meet the company's policy.
Note: Launching the wizard under target administrators credentials will also fail if it connects to the same, already dirty, DC. If you already attempted to run the wizard and used incorrect credentials then you should delete the agent manually or consider using another DC, specifying another DC name in the Preferred DC textbox. The name of the (damaged) DC which was accessed by the wizard can be obtained from the log file of the ADPW.Additional Information:
1. Limitations
You will not be able clean up more than one target domain at the same time if you had not started the wizard under credentials which allow you to process all the selected target domains. If you don't have these universal credentials, simply use consequent runs of the wizard changing credentials in the runas command to meet every target domain.
To rephrase: if you don't have an account which has admin rights in all target domains then you need to execute the wizard multiple times, for each separate domain once.2)Clean up will work if the DC is installed on Windows 2008 x86 OS. The issue applies only to 64 bit OS, not to 32 bit OS.
Knowing this there might be customers willing to introduce (temporarily) a new VMWindows 2008 x86, in this case wizard will work if you specify this DC as preferred DC.
3) Instead of removing the agent manually you can use a migration session, but you need to specify the DC as preferred DC.
Then you start a new USER MIGRATION session. Since on the target DC you will have an Aelita Migration Agent (AelAgent) with a 32-bit AelAgentMS.exe instead of a 64-bit? AePAgent64.exe migration will fails and in the DSA log you will see this:
10.12.2009 15:48:31 (GMT+03:00) Common AcAdSwitches XML: Install Agent, type: SidHistory , host: W2K8R2dc200.ex50.local , job id: C6FBF94803BE0E4594B9194B7B6FDD49 , project id: 4B35E7342DB2604BADDCB5B74E361B3D , source: false.
10.12.2009 15:48:44 (GMT+03:00) Common AcAdSwitches Error 0xe1100012. Cannot initialize Migration Agent on host W2K8R2dc200.ex50.local
Error 0x80040154. Class not registered
But at the end of the migration session the agent will be completely removed.