Category Archives: ADMT

an Exchange mailbox was mistakenly migrated over another user’s object used by another user

The Story

If you ever used Prepare moverequest command to migrate a user and forgot to use ADMT to rewrite user’s properties with the old attributes. You might have used ADMT again to rewrite the properties.

If you use ADMT you will need to exclude all Exchange Attributes from the source since its already copied using Prepare-move request script however, in some cases some people do make mistakes and you might have came through the same mistake my colleague  have done during one of these extremely complicated Cross forest Migrations where you’d prepare a CSV files through PowerShell and names wouldn’t match Sam accounts.

Don’t Panic

If however, you forgot again to exclude the Exchange attributes while using ADMT then you most likely wont see the user in the Target forest which will cause to panic thinking the user is gone .. But no the user is not gone don’t panic.

When you look for the user’s mailbox on the target forest after the move request is completed you’ll get an error reporting the user can’t be found



To fix the problem you’ll need to change to attributes only for this migrated user. (In the target forest after user mailbox move is completed).

The attributes are

msExchRecipientDisplayType    1073741824
msExchRecipientTypeDetails    128

The wrong Attributes are as following.


You will need to fix them to look like the following


Once you apply the change you’ll need to wait for a minute or few depending on your AD replication speed.
The problem will be then solved


Migration Computer with ADMT gives an error Logon Failure: The target account name is incorrect

If you’re doing a Cross Forest migration project then you most likely have had a big experience but the more you do those kind of projects the more you’ll see different types of errors and issues rising up.

One of the issues I had in one of the cross forest projects that I have done before was the following error


To start troubleshooting, we’ll start by ruling out the following main causes.

  1. Checked DNS.
  2. Checked relative services (Netbios, RPC, Computer browser ..etc)
  3. Checked firewall (Kaspersky and windows) and closed them both.
  4. Checked connected DC and changed it to a different one.
  5. Checking DCs / Frs (File repliation service) replication and health.

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server smart0188$. The target name used was RPCSS/Smart0248.smartmoss.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (SMARTMOSS.LOCAL) is different from the client domain (SMARTMOSS.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Suppose you have a domain member named DOMAINMEMBER. You can reset the member secure channel by using the following command:


From <>

You can run the command above on the member DOMAINMEMBER or on any other member or domain controller of the domain, provided that you are logged on with an account that has administrator access to DOMAINMEMBER.

The output received from the command should be similar to the following:

Searching PDC for domain DOMAIN …
Querying domain information on PDC \\DOMAINPDC
Querying domain information on computer \\DOMAINMEMBER
Computer \\DOMAINMEMBER is already a member of domain DOMAIN.
Verifying secure channel on \\DOMAINMEMBER
Verifying the computer account on the PDC \\DOMAINPDC
Resetting secure channel …
Changing computer account on PDC \\DOMAINPDC
Stopping service NETLOGON on \\DOMAINMEMBER …. stopped.
Starting service NETLOGON on \\DOMAINMEMBER …. started.
Querying user groups of \\DOMAINMEMBER
Adding DOMAIN domain groups on \\DOMAINMEMBER

The computer \\DOMAINMEMBER joined the domain DOMAIN successfully.

Logoff/Logon \\DOMAINMEMBER to take modifications into effect.

From <>

Solution 1-

nltest.exe can be used to check the channel and attempt to reset it.

nltest.exe /sc_verify:smartmoss.local

If that does not do it, you can restart the netlogon service (I mainly use PowerShell, so I’ll give an example of that).

Get-Service netlogon | restart-service
nltest.exe /sc_verify:<>

I ran the nltest command after restarting the service to validate that the secure channel was back in operation.

If you’ve made some network changes (IP Addresses, changing hardware, virtualizing, etc..) you might want to flush your dns cache and clear your arp table before running the above commands.

ipconfig /flushdns
arp -d *
Get-Service netlogon | restart-service
nltest.exe /sc_verify:<>

Let’s try to find out which DC the client is connected to

nltest /dsgetdc: Dc.local

Point the client to a different DC

nltest /Server:client0 /SC_RESET: DC.Local\DC02

Testing tool

Checked the following tool

Checked the services RPC, computer browser,

Solution 2-

There is a bug in MS after 400 days of uptime that they don’t tear down their time_wait connections so the server runs out of sockets and can’t make connections to the DC – a reboot should fix this issue temporarily.

From <>

net stats srv



Domain Controller Cross Forest migration Part 3 (ADMT Installation)

ADMT 3.2 installation



  1. SQL express/full 2008 sp2
  2. Windows 2012/R2 / Windows 2008 R2 for ADMT
  3. Install PES on Source DC for Migrating Passwords

  • The server where you install ADMT can run any supported version of Windows Server, including Windows Server 2012 R2 and Windows Server 2012.
  • The source and destination domain controllers must be writeable, but they can run any supported version of Windows Server with a user interface (not Server Core), including Windows Server 2012 R2 and Windows Server 2012.
  • The source and destination domains must be at Windows Server 2003 domain functional level or higher.
  • The computers that can be migrated can run any supported version of Windows, including Windows 8.1.
  • You can use any version of SQL Server for the ADMT database.

From <>


ADMT user permissions:


From <>


ADMT Migration Account

The account you run ADMT under will need to have administrative rights in both the source and destination domain. You may decide to create a user specifically for the ADMT Migration, or you may use an existing user e.g. the default administrator account. I will create a user called ADMT and assign this user the correct permissions. This is the account we will use for the entire migration.

It is recommended that you make the user account in the destination domain and make it a member of the domain administrators group.

destination Domain:



In the source domain add the same user to the builtin administrators group (you will be unable to add it to the domain administrators group).

Source Domain:




Installing ADMT

You should install ADMT and SQL onto a member server in the destination forest. Use the ADMT service account explained in the previous post to install SQL and ADMT.

ADMT requires a preconfigured instance of SQL Server for its underlying data store, so we’ll go ahead and install SQL 2008 SP1 Express on


Installing SQL Express 2008 SP2

SQL Express download here:






This error is purely within SQL Express 2008 and is not really to do with ADMT 3.2. The issue is fixed in “Cumulative update package 4 for SQL Server 2008”.

Unhelpfully, this error is identified in KB975055 as being only for Windows 7 and that it was fixed by SP1 – both incorrect. The issue does affect Win2008 R2 and is only fixed by the cumulative update.


Before installing SQL Server Express 2008 with SP1 (which will fail), first install:

Cumulative update package 4 for SQL Server 2008









Set an account for the SQL service to run under (use your ADMT Service Account).


Set a SQL administrator, choose the user account you plan to run ADMT under- be aware that this user account will need to have local administrative rights in the source domain (this will be discussed further in the series).



Download ADMT 3.2!33497&authkey=!AF3kLtU8fl2_B0I&ithint=file{308b10a016e19a1cd6a208cbc3961927e16fc6766a4020d3c4ef54ea17925f0f}2cexe

Installing ADMT

For this series I will be using ADMT 3.2, which is the supported version for Server 2008 R2. Use ADMT 3.1 for installation on a Server 2008 non-R2 server, or ADMT 3.0 for Server 2003. If you need to migration a Server 2000 Domain, you will need to use ADMT version 3.1 or earlier.

Update Junes 2014 – ADMT 3.2 now supports Windows Server 2012 / 2012 R2.











Hope this helps, please stay tuned for the next part. Winking smile