{"id":625,"date":"2019-06-18T00:18:55","date_gmt":"2019-06-18T05:18:55","guid":{"rendered":"http:\/\/zewwy.ca\/?p=625"},"modified":"2019-10-03T10:49:07","modified_gmt":"2019-10-03T15:49:07","slug":"migrating-users-and-passwordssame-netbios-name","status":"publish","type":"post","link":"https:\/\/zewwy.ca\/index.php\/2019\/06\/18\/migrating-users-and-passwordssame-netbios-name\/","title":{"rendered":"Migrating Users and Passwords
Same NetBIOS Name"},"content":{"rendered":"

<\/span>Story<\/span><\/h1>\n

*NOTE* All information here is provided as is for educational purposes only, whatever you do in your own environment is on you.<\/p>\n

I want to give a bit of a background here, the goal was to migrate users to a new child domain, that was previously a 2 way forest wide trust. In this case scenario, there was no need for a 2 way trust as both domains were owned and operated by the same corporation. A simplified AD structure was conceived, new workflow servers, new clean permissions throughout.<\/p>\n

Everything was coming along swimming until, after some extensive research, how to migrate users and their passwords without service interruptions…<\/p>\n

With Windows Authentication in the back end there was only one choice, ADMT v3.2<\/a> and it’s associated documentation<\/a> … yeah that’s not a content based website, it’s a download to a doc, that was last updated 2014 with support with Windows Server 2012 R2.<\/p>\n

It states the following:<\/p>\n

Any DB works (I used SQL 2016 Express)
\nOther things, read it if you wish to be over\/under whelmed
\nNeeds a Trust<\/p>\n

<\/span>Simple Overview<\/span><\/h2>\n

\"\"<\/a><\/p>\n

Here’s a simple of an idea of how the Forests are laid out, and you can see where the users are planned to be migrated… just one major problem<\/a>… You can’t create a trust between forests where the NetBIOS match. And Yes, that is a thread from 2011 unanswered, which I will answer for you tonight. Which you can see from my design, is exactly the problem I was facing. I was initially hoping this could be done without a trust<\/a> which turned out was the answer which lead me to the answer..<\/p>\n

”<\/p>\n

You can do this via trust but not how you might normally think about it.<\/p>\n

Build out a new dc in your source domain and allow it to replicate properly, be sure that it is a dc\/gc and dns server. Disconnect this dc from the current domain and expect to NEVER connect to this domain again.<\/p>\n

Do a metadata cleanup of this dc….<\/p>\n

”<\/p>\n

Along with this, How to rename the NetBIOS name<\/a>, now mix everything into one huge sch-melting pot and what do we get…. this blog post.<\/p>\n

<\/span>Setup<\/strong><\/span><\/h1>\n

<\/span>ADMT<\/span><\/h2>\n

*Note don\u2019t bother installing SQL + ADMT until the member server is domain joined to the target domain. In this example Windows Server 2016 is used to host ADMT services. So this server is domain joined to Special.NewDomain.com<\/p>\n

First Download ADMT from here<\/a><\/p>\n

Based on the size of the installer I\u2019m assuming this is an online installer and instead of dicking around trying to find an offline version.. simply connect this server to the internet. However before we begin ADMT requires an SQL instance to utilize, to keep life easy we will install SQL Express on this server and run it locally for the migration.<\/p>\n

<\/span>Installing SQL Express 2016<\/span><\/h2>\n

Now looking at where to find specific version to download and use<\/a>\u2026 I wasn\u2019t sure which version was best<\/a>\u2026
\nI decided to start with Express Core \u2026
\nNext, next, next, Mixed Auth (just in case) sa password.<\/p>\n

<\/span>Installing ADMT<\/span><\/h2>\n

Now with SQL Express on the target domain joined server, double click the ADMT v3.2 installer exe.<\/p>\n

\"\"<\/a><\/p>\n

Accept the EULA. Accept\/Decline the CEIP<\/p>\n

Use local SQL and….<\/p>\n

\"\"<\/a><\/p>\n

DB Import… NO, next<\/p>\n

\"\"<\/a><\/p>\n

Now we should be good to run ADMT (as a Domain admin on Special.NewDomain.com), IF you installed SQL + ADMT before joining to the target domain and did not choose to use mixed auth and have no sa account, follow my previous blog pos<\/a>t to recover access to the SQL Express instance, granting your domain admin account access.<\/p>\n

<\/span>Preparing the Source Domain<\/span><\/h2>\n

Now how you choose to accomplish this is entirely up to you. If you wish to go the route suggested by the TechNet Post to create a new DC thats a GC and rip it out of the Forest\/Domain via a MetaData Cleanup… be my guest but that’s a lot of work.<\/p>\n

Instead I choose to simply create a secondary version of the Special.local DC via a backup, but I could have easily made a clone since it’s all virtualized. So for me it started out like this…<\/p>\n

\"\"<\/a><\/p>\n

Clearly at this point a trust still can’t be established as NetBIOS names are still the same, however now we have no fear of mucking up the source domain as it’s simply a clone will all users and their passwords still encrypted within AD. So this migration will require 2 things:<\/p>\n

1 – A domain rename<\/p>\n

2- Password Export Server (Covered later in this post)<\/p>\n

<\/span>Renaming the Source Domain<\/span><\/h2>\n

<\/span>Changing the IP Address<\/span><\/h3>\n

Since this is a clone, and I was not interested in alternative firewalls outside the windows firewalls I connected the source domain to the same subnet as the target domain to ease life. This requires the IP address to change.<\/p>\n

\"\"<\/a><\/p>\n

So open Network and Sharing Center and edit the adapter settings accordingly, this will however break the DC’s DNS service. So lets fix that.<\/p>\n

<\/span>Deleting the DC A host Record<\/span><\/h3>\n

On the DC open DNS snap-in, and navigate to the top where the SOA and NS records are, and below that search for the A host record for the DC itself, and delete that record (remember this should be a clone or copy of a DC from the original source DC so no risk should be had here).<\/p>\n

<\/span>Reset DNS settings<\/span><\/h3>\n
ipconfig \/flushdns\r\nnet stop dns\r\nnet stop netlogon\r\nnet start dns\r\nnet start netlogon<\/pre>\n
\"\"<\/a><\/p>\n
<\/span>Create a new DNS zone<\/span><\/h3>\n
Open DNS snap-in again on cloned source DC, and create a new DNS Zone for the new domain name.<\/p>\n
\"\"<\/a><\/p>\n
\"\"<\/a><\/p>\n
\"\"<\/a><\/p>\n
\"\"<\/a><\/p>\n
\"\"<\/a><\/p>\n
Complete the wizard.<\/p>\n
<\/span>Configure Domain to Accept new DNS Suffix<\/span><\/h3>\n
– Open ADSI Edit
\n– Right Click ADSI Edit -> Connect to\u2026
\n– Leave defaults -> ok
\n– Expand \u201cDefault Naming Context\u201d
\n– Right Click Domain Parent Object -> Properties<\/p>\n
\"\"<\/a><\/p>\n
– Enter the new domain name into the msDS-AllowedDNSSuffixes<\/p>\n
\"\"<\/a><\/p>\n
<\/span>Enable update DNS Suffix option<\/span><\/h3>\n
\"\"<\/a><\/p>\n
Server will reboot after this step, again since it is a clone and not actually hosting AD services for any production need this is no problem, right?<\/p>\n
<\/span>Get the required XML to edit:<\/span><\/h3>\n
Everything I was reading online stated that you need to do all this from a member server, and you need to copy rendom and another application from the System32 from a DC, etc, etc, all a bunch of rubbish… everytime I attempted to follow such guides the rendom command would spit out some lines that seems was supposed to be parsed by something else to provide useful return output. People stated running from System32 directly fixed that issue for them, but not for me. Instead I decided to run all the commands directly from the DC since it was the lowest risk for me. as stated serveral times why above. Sooo…..<\/p>\n
– Open CMD as admin on DC
\n– Run \u201crendom \/list\u201d<\/p>\n
\"\"<\/a><\/p>\n
<\/span>Edit the XML file (open via elevated cmd prompt)<\/span><\/h3>\n
\"\"<\/a><\/p>\n
save and check by running “rendom \/showforest”<\/p>\n
It should report the changes you made to the XML file.<\/p>\n
<\/span>Upload the XML to the DC<\/span><\/h3>\n
\"\"<\/a><\/p>\n
<\/span>Prepare DC<\/span><\/h3>\n
\"\"<\/a><\/p>\n
<\/span>Execute Domain Rename<\/span><\/h3>\n
\"\"<\/a><\/p>\n
Let DC reboot and then complete the rename.<\/p>\n
<\/span>End the Domain Rename process<\/span><\/h3>\n
\"\"<\/a><\/p>\n
So now the setup should look like this…<\/p>\n
\"\"<\/a><\/p>\n
Now as you can see we no longer have the same NetBIOS name and thus we can create a trust here to migrate users using ADMT and PES yay!<\/p>\n
<\/span>The Trust<\/span><\/h2>\n
<\/span>Conditional Forwarders<\/span><\/h3>\n
For the trust to work each domain must be reachable by the other domains DC via FQDN. This obviously requires conditional forwarders to be configured for each DC accordingly.<\/p>\n
So opening a MMC.exe application, from a member system with RSAT installed, or directly on Special.NewDomain.com if it has the desktop experience. Then Add the DNS snap-in. Add a conditional forwarder, in my case I added NotSpecial.com pointing to the IP address of the cloned and renamed DC.<\/p>\n
Then doing the same thing on NotSpecial.com DC, opening the DNS application (or remotely with RSAT), and creating a conditional forwarder that says special.newdomain.com pointed to the IP address of the actual child DC, in the same subnet as in the diagram.<\/p>\n
At this point ensure that Target DC (Special.NewDoamin.com) can ping NotSpecial.com, and that Source DC (Special.com) can ping Special.NewDomain.com. If yes, we can now go ahead and build the trust.<\/p>\n
<\/span>Building the Trust<\/span><\/h3>\n
Open domain and trusts. Right click domain and properties:<\/p>\n
\"\"<\/a><\/p>\n
Click the Trusts Tab, New Trust:<\/p>\n
\"\"<\/a><\/p>\n
Complete the wizard for both sides of the trust. I had a domain admin account in each source and target domain.<\/p>\n
With admin account on each domain and already logged in as domain admin on the NotSpecial domain, wizard completes successfully:<\/p>\n
\"\"<\/a><\/p>\n
Now with a trust in place, we could start just migrating users, but we need those passwords migrated as well, else we will have a bunch of angry users.<\/p>\n
<\/span>ADMT & PES<\/span><\/h2>\n
<\/span>Permissions<\/span><\/h3>\n
Nest Special\\DomainAdmin into NotSpecial\\BuiltIn\\Administrators group, as well as into Special\\BuiltIn\\Administrators group. You might be wondering why? Well I hit this error when attempting to migrate users passwords:<\/p>\n
\"\"<\/a><\/p>\n
After reading this<\/a>, I made the changes above and it finally got past this error when attempting to migrate users passwords.<\/p>\n
Logged on to ADMT as Special\\DomainAdmin<\/p>\n
<\/span>Password Export Server Setup<\/span><\/h3>\n
Step 1) Create the encryption key for the migration:<\/p>\n
admt key \/option:create \/sourcedomain:notspecial.com \/keyfile:\"C:\\path\\to\\file.pes\" \/keypassword:*<\/pre>\n
<\/p>\n
Step 2) Copy the Key to the NotSpecial.com DC (I used RDP)<\/p>\n
Step 3) Grab PES installer from here<\/a>, and get it on NotSpecial.com DC<\/p>\n
You should now have this on NotSpecial.com DC:<\/p>\n
\"\"<\/a><\/p>\n
Step 4) Install PES running the MSI from an elevated cmd prompt:
\nIf you’re wondering why, I was about to smash a monitor when the installer kept telling me the password was wrong for the encryption file, when I knew for certain I wasn’t putting it in wrong, and someone else blogged about it<\/a>.<\/p>\n
\"\"<\/a><\/p>\n
\"\"<\/a><\/p>\n
\"\"<\/a><\/p>\n
I used a installed using local system account cause again this DC will be shutdown after the migration.<\/p>\n
\"\"<\/a><\/p>\n
Step 5) Complete the Install and after reboot start the service<\/p>\n
\"\"<\/a><\/p>\n
<\/span>ADMT and Migrating Users<\/span><\/h1>\n
At this point we should be officially ready to migrate users, on ADMT open ADMT:<\/p>\n
\"\"<\/a><\/p>\n
Right click the folder and select the user migration wizard
\nPopulate the domain names and tree source domain controllers should pick up automatically.<\/p>\n
\"\"<\/a><\/p>\n
Select your users, Pick a target OU, then select to migrate password:<\/p>\n
<\/p>\n
Given you followed the permissions section, this should work:<\/p>\n
\"\"<\/a><\/p>\n
Keep target state same as source and don\u2019t copy SID as we have no intention of using SID filtering.<\/p>\n
\"\"<\/a><\/p>\n
These settings worked great for me, change based on your needs.<\/p>\n
\"\"<\/a><\/p>\n
again these settings worked for me.<\/p>\n
After the process…<\/p>\n
\"\"<\/a><\/p>\n
It worked! However i was amazed even in my first test run, there was one noticeable message in the log:<\/p>\n
Rename UPN name user@NewDomain.com to user@NewDomain.com. Cannot create accounts with the same UPN name as another UPN in the enterprise.<\/p>\n
Well cause there already exists a user with that UPN at the parent, but why is it picking the parent for setting the UPN? Who knows…<\/a> but much like that reference you can bulk select users in ADUAC Snap-in, and select the child domain from the drop down text-box.<\/p>\n
<\/span>Summary<\/span><\/h1>\n
    \n
  1. Create a Copy of the Source Domain Controller<\/li>\n
  2. Rename its Domain<\/li>\n
  3. Connect to target domain subnet<\/li>\n
  4. create conditional forwarders<\/li>\n
  5. create two way trust<\/li>\n
  6. Setup ADMT<\/li>\n
  7. Setup PES<\/li>\n
  8. Migrate Users<\/li>\n
  9. Remove Trust, and Shutdown NotSpecial.com DC<\/li>\n
  10. Happy Dance<\/li>\n<\/ol>\n
    Hope everyone enjoyed this post, and hopefully someone finds it useful.<\/p>\n
    *Update* Here’s a really good blog on SID FIltering between forest trusts<\/a>!<\/p>\n","protected":false},"excerpt":{"rendered":"
    Story *NOTE* All information here is provided as is for educational purposes only, whatever you do in your own environment is on you. I want to give a bit of a background here, the goal was to migrate users to a new child domain, that was previously a 2 way forest wide trust. In this … <\/p>\n
    Continue reading “Migrating Users and Passwords
    Same NetBIOS Name”<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"sfsi_plus_gutenberg_text_before_share":"","sfsi_plus_gutenberg_show_text_before_share":"","sfsi_plus_gutenberg_icon_type":"","sfsi_plus_gutenberg_icon_alignemt":"","sfsi_plus_gutenburg_max_per_row":"","footnotes":""},"categories":[8,197],"tags":[207,206,208,209],"class_list":["post-625","post","type-post","status-publish","format-standard","hentry","category-server-administration","category-windows","tag-admt","tag-migrating-users","tag-pes","tag-same-netbios"],"_links":{"self":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/625","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/comments?post=625"}],"version-history":[{"count":11,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/625\/revisions"}],"predecessor-version":[{"id":629,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/posts\/625\/revisions\/629"}],"wp:attachment":[{"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/media?parent=625"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/categories?post=625"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zewwy.ca\/index.php\/wp-json\/wp\/v2\/tags?post=625"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}