Introduction to Series
![]()
Install ADMT PW Migration DLL. Requires a reboot. 11.) Mimic the same OUs as the Source DC. 12.) Start Migration in ADMT tool. Launch Computer Migration Wizard. Find Computer in source domain. In DNS you can add zones for other Domains using the Add Zone wizard.
After recently using ADMT for an Active Directory migration I thought I’d write a series to document its use and to share any useful tips I found along the way. This first post will explain how to prepare the Active Directory for the migration process.
If you’ve found this blog post you’re probably already aware of what ADMT is and what it can be used for, and I’d suggest (as always) to read the documentation provided by Microsoft. The user guide for ADMT can be found here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=19188
Series Test bed
In this Series I’m going to be using 3 servers and an XP client.
Server 1 AD1 – Target Domain Server 2008 R2 Domain controller in the target.local domain
Server 2 ADMT – Target Domain Server 2008 R2 Member Server running ADMT in the target.local domain Server 3 DC1 – Source Domain Server 2003 Domain controller in the source.local domain Client 1 XP – Source Domain Windows XP client in the source.local domain
The goal of this series will be to migrate from the 2003 source.local Domain to the 2008 R2 target.local domain.
Preparing Active Directory
In this post we’ll look at preparing Active Directory for the migration process. There are two main things to prepare, DNS and a domain trust.
Before the domain trust can be created both domains will need to be able to resolve each other via DNS. To achieve this you can use stub zones, secondary zones or forwarders. I’ll show you how to setup forwarders below on Server 2003 and 2008 R2. When using forwarders you need to manually populate the IP(s) of the name servers you’ll be using for resolution, if for whatever reason these change you will have to manually go back and change the forwarder. This probably isn’t an issue for most scenarios.
Setting up a Server 2008 R2 DNS Forwarder
1. Open the DNS MMC console, expand the server tree and select Conditional Forwarders. Right click and select new conditional Forwarder.
2. Enter the other DNS domain name (the source domain in this case), then click below where it says “Click here to add” and enter the IP address of on the DNS servers in the other domain. Press enter. If you have multiple DNS servers in your Active Directory it’s a good idea to store the conditional forwarder in AD, and replicate it accordingly.
Before the forwarder:
After the forwarder:
Setting up a Server 2003 DNS Forwarder
1. Open the DNS MMC console, right click on the server and select properties.
2. Select the 2nd tab along titled ‘Forwarders’, new, enter the other DNS Domain (the target domain in this case) and click OK. With the Domain selected enter the IP address of one of the DNS servers in the other Domain and select Add.
Setting up the Domain Trust
The trust will be created completely on AD1 in the Target.local domain.
1. Open the Active Directory Domains and Trusts, right click on the domain and click properties.
2. Head over to the Trusts tab and select new trust.
3. Enter the DNS domain name of the other Domain.
4. Choose External or Forest trust, to setup a forest trust both domains will need to be at a 2003 Forest Functional level or higher. As we’re dealing with two single domains an external trust is fine.
5. We’ll use a two-way trust.
6. To setup both sides of the trust from the target domain you will need domain administrator credentials for the source/other domain.
7. Domain-wide authentication.
8. Confirm both the incoming and outgoing trusts.
I will cover SIDHistory in the next blog post, so we can ignore this for now.
Here we can see the trust in place.
Suffix Search List
Now that we have the forwarders in place in the source and target domains, clients from either domain should be able to resolve FQDNs from the other. However you will want to add the source/target domains suffix to the suffix search list, allowing simple, single-label names resolution.
On the Server 2008 R2 server, open Group Policy Management in Server manager, right click on the level you want to apply the policy to and select Create a GPO in this domain, and link it here… We’ll call our GPO Trust – Suffix.
Dig down to Policies -> Administrative templates -> Network -> DNS Client. Set the Primary DNS Suffix to the current domain, so in the Target.local domain we’d put this was Target.local. Then enable the DNS Suffix Search List policy, add the current domain first, then add the other domain- seperated with a comma.
In the Server 2003 domain you can either add the policy via ADUC or via GPMC (http://www.microsoft.com/download/en/details.aspx?id=21895). The settings are in the same place.
We can see the policy applied when we run an ipconfig /all. The clients will now append the primary suffix first, then try the additional suffixes found in the suffix search list.
ADMT Migration Account
The account you run ADMT under will need to have administrative rights in both the source and target 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 ADMTUser 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 target domain and make it a member of the domain administrators group.
Target 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:
ADMT Series – 1. Preparing Active Directory
ADMT Series – 2. Preparing the ADMT Machine ADMT Series – 3. SID History ADMT Series – 4. Password Export Server ADMT Series – 5. Machine Preparation ADMT Series – 6. Service Account Migration Wizard ADMT Series – 7. Group Account Migration Wizard ADMT Series – 8. User Account Migration Wizard ADMT Series – 9. Merging Users with a Different sAMAccountName ADMT Series – 10. Security Translation Wizard – Local Profiles ADMT Series – 11. Computer Migration Wizard
Active Directory / ADMT / DNS / Microsoft August 27, 2019
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.
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:
NETDOM MEMBER DOMAINMEMBER /JOINDOMAIN
From <https://support.microsoft.com/en-us/kb/175024/>
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 …
Found PDC DOMAINPDC 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 <https://support.microsoft.com/en-us/kb/175024/>
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:<fully.qualified.domain.name.here>
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:<fully.qualified.domain.name.here>
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.LocalDC02
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 <http://community.spiceworks.com/topic/218426-there-are-currently-no-logon-servers-available-to-service-the-logon-request>
net stats srv
![]() Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
December 2022
Categories |