Just when you think you’ve really seen the last of NT4, a new client shows up, they have an NT4 domain, and they want to upgrade it. Crap, you think. You’ve tossed that old workstation that you knew was compatible with NT4 AND with 2003, and wouldn’t crash in the middle of the upgrade due to driver issues.

You generally don’t want to use one of the customer’s NT servers, because:

• The rollback plan is difficult and risky.
• Sometimes they only have one and that’s a big risk of losing everything during the upgrade.
• Most of the time their servers are full of software that makes them run slow and will probably cause errors during setup or not run properly afterward.

So the best thing is to provide a computer for the task, install NT4 on it as a BDC, promote it to PDC, upgrade it to W2K3, and then bring in the shiny new server they just bought as another W2K3 DC and move all of the FSMO roles over.
Maybe you still have that old SMC NIC with the 10bT RJ-45 plug and the coax BNC connector on it, if you can find it, and if it hasn’t been damaged, kicking around in the bottom of a drawer somewhere.

The problem is that hardware which NT4 can detect and load drivers for natively is almost completely extinct now, and searching for NT4 drivers for stuff is time-consuming and often futile.

Leaving your loaner workstation, and maybe your 2-port KVM switch onsite during the upgrade was always kind of a bummer anyway.

Well, my friends, there is a better way. You can skip all of this hardware difficulty by using a virtual machine. You can carry a DVD around with me containing ISO images for NT4, SP6, IE6sp1, Win2003, SP2, and VMware server on it. You can load this on any XP workstation at the client site during the upgrade, or maybe their new server. You can use VMware Server to host an NT4 BDC, promote it to PDC, and then upgrade that to Windows 2003.

I had only previously done this in a lab environment – but last week, I did it for real. The customer was a 10-user geographic data mapping company in a downtown Seattle skyscraper.

There are some tricks that you have to observe to make this work. The first time I tried this, in the lab, I was able to load up NT4 just fine, but when I tried the in-place upgrade to Windows 2003, it failed. I don’t remember the exact failure mode, but it just plain didn’t work – until I used Windows 2003 RTM instead of R2. For some reason R2 had issues with the VM, or the upgrade, or something, but RTM did not. You also want to have NT4 SP6a handy, for bringing your VM (and their server if necessary) up to speed.

 Here is the winning combination - make a VM with the following specs:

• OS: Windows NT
• SCSI Controller: LSI Logic (not really important but you have to choose one, so…) 
• Hard Disk: 8gb IDE (not SCSI!)
• Memory: 512mb or more. 

1. Start the VM and immediately go into the BIOS to set the time and change the boot order to HDD, then CD.
2. Attach an NT4 Server ISO or put an NT4 CD in the drive.
3. Format 4gb of that 8gb disk, and install Windows NT as a BDC. (NT4 picks up the VMware NIC during setup, so you can obtain an IP address and join the domain as a BDC)
4. Install NT4 SP6a_128, and (optionally) IE6 SP1.
5. Attach a Windows Server 2003 RTM (not R2!) ISO or put a CD in the drive and attach it to the VM.
6. Upgrade the OS and install Active Directory.
7. Allocate the remaining 4gb of disk space to another drive letter and move the swapfile over to it to free up some disk space on C.
8. Install SP2 for Windows 2003.
9. If your new 2003 server is R2, you’ll need to update your schema at this point, just like a normal upgrade.

Now you can add your new DC to the network and move your FSMO roles around.

Will this work with Windows 2008? I don’t know, I haven’t tried it yet. I doubt you can do an in-place upgrade from NT4 to 2008, but you can certainly do the in-place upgrade to 2003, extend its schema all of the way to 2008 levels, and then join up your new 2008 server.

 

Tags: Domain Upgrade, Migration, NT4 to 2003, VMware Server

 

First, let me just say it is excellent that Microsoft has changed their attitude toward SBS migration, and the SMB market is very appreciative of that. This is the first version of SBS that has an in-the-box, MS-supported migration path from a previous version of SBS. Big kudos to the SBS team for this.

 

After installing SBS2008 using the answer file for a migration, the SBS console contains a group of wizards and instructions. Some of the migration tasks are handled for you, and others are links to help files with instructions for performing migration tasks.

 

However, like any of Microsoft’s first efforts in a given direction, the going is a bit rough. Some of the manual migration tasks could have been done in a wizard, and others were omitted entirely.

 

If one were to follow this migration wizard strictly, and do no more than is listed, the customer would be left with a non-functional network (from their point of view). They would come in on Monday morning, log in, and their network drives would not map. Their printers would not function. Their web browser, if it opened to http://companyweb, would display no data. Their desktop shortcuts would not work.

 

While this wizard is certainly helpful, with lots of useful information, it falls short in actually guiding a consultant to a conclusion that would be called successful by any customer’s standards. If I followed this guide, and did nothing more, my customer would not pay the bill for this migration.

 

I have seen (and cleaned up) the aftermath of a project done this way. It is the sort of event that prompts a customer to start looking for a new IT company.

 

</soapbox>

 

Every network is a little different, and MS could not be expected to cover all eventualities – but there were a number of tasks I performed after the wizard that I would reasonably expect to perform during any migration.

 

Click here to skip down to the post-migration-wizard tasks that I performed.

 

What follows below is a list of steps I went through during this migration. First, I did a migration from a freshly built SBS 2003 to SBS 2008 in a test lab, and of course it went perfectly. Then I did a real migration in a production environment, and it was a far more interesting journey.

 

Preparation and Pre-Wizard Migration Steps:

 

A. Checked to ensure that I had a restorable backup.

 

B. Cleaned up unnecessary files taking up space.

 

C. Powered down my SBS2003 VM and resource server VM, took snapshots, and powered them back on.

 

D. Edited Autounattend.xml and inputted the proper settings for my environment (this is not necessary for an SBS 2008 migration, but since I already covered doing a fully unattended SBS 2008 load, I figured I’d include this bit).

 

E. Ran SBSAFG.exe to create an SBS answer file for this migration, and put it into a virtual floppy disk along with the autounattend.xml file.

 

F. Created a VM with 4 CPUs, 8GB RAM, C:60GB, D:125GB, virtual floppy with answer files, ISO file of the SBS DVD.

 

G. Set the SBS2008 VM to boot into BIOS on first boot.

 

H. Booted the SBS2008 VM and adjusted the time (it was 8 hours off) and boot sequence.

 

I. Rebooted the VM and it started setup.

 

Note: I experienced some issues with the disk sizing, either due to geometry issues, conversion math issues, or something. Anyway, the answer file specified that the disk size should be 61440 KiB. This should fit neatly into a 60GB container, but apparently does not. This is undoubtedly due to the difference between SI values and Binary values, and the confusion between them. See this web site for details.

 

Also, here is a handy calculator:

Anyway, I adjusted the answer file to use 60000 instead of 61440 and it’s all good.

 

J. Waited for the unattended installation to finish.

 

K. Received an error about the source server not meeting minimum requirements for migration.

 

Things missing:

· AD Schema needs to be extended to Windows 2008 level.

· Domain and forest functional levels need to be set to Windows 2003.

· Hotfix needs to be installed to extend time limit for multiple SBS servers in one domain.

 

Note: This is the “Point of no return” as it were. Obviously, it is possible to proceed past this point, stop, and still recover – but cleanup will be required, and possibly technical support from Microsoft.

 

L. Ran the Source tool on the source SBS server, which failed because I was running it as an account that did not have the required permissions. I ran it again successfully using the administrator account.

 

The source tool updated the schema, installed the hotfix to extend the multiple SBS server deadline, adjusted Exchange to allow migration, and required a reboot. I rebooted.

 

M. After the reboot, I upgraded the domain and forest functional levels to Windows 2003. This did not require a reboot.

 

N. Clicked the “Check Again” button on the SBS2008 server. It found that all of the issues were resolved, and continued forward. Note: During this phase, in addition to the schema changes above, the new SBS server appears in AD users and computers in the domain.

 

 

It should be noted here that during this phase, I ran into a serious road block that took me more than a few hours to resolve. The underlying issue and the solution are detailed in another blog entry.

 

The initial SBS wizard completed with errors. The error was “An update could not be applied”. I won’t lose any sleep over that one.

 

O. Added two partitions, one 12 GiB volume for the pagefile, and one 125 GiB volume for data. (You can choose your own preference here)

 

P. Adjusted the pagefile to be a system managed pagefile on the 12 GiB volume. (Again, your preference)

 

Started the Migration Tasks in the wizard provided by SBS:

 

On the Windows SBS Console, I clicked the Migration task, but it would not let me run it as the built-in administrator. It wants me to create an administrator user for the tasks. This is annoying because many of the tasks will require elevation, which means using the runas command to run them as the built-in administrator.

 

I created an administrative user using the SBS console, and during that process it failed to send a welcome e-mail to the new user using webmail. The error message is: “Service Discovery failed in looking up the CAS Server in the target AD Site.” I guess this has something to do with SSL certificates for the website. This problem solved itself later when I moved my certificate over.

 

A. Change Data Locations:

i) Change Exchange server data locations

(1) (Clicked OK to continue without backing up the server)

(2) Chose the location for the Exchange data and moved the databases.

ii) Change the Sharepoint Data location

(1) (Clicked OK to continue without backing up the server)

(2) Chose the location for the Sharepoint data and moved the database.

iii) Change the User data location

(1) (Clicked OK to continue without backing up the server)

(2) Chose the location for the user data.

iv) Change the users’ Redirected Documents location

(1) (Clicked OK to continue without backing up the server)

(2) Chose the new location for the redirected documents.

v) Change the Windows Update Repository data location

(1) I chose not to move this.

vi) Clicked Task Complete and Next

 

B. Configure the Network:

At this point, I was expecting to have to use netsh to export the DHCP database from the old server and import it to the new, as I did during my test migration. However, when I attempted to do so, I discovered that SBS08 had already disabled the DHCP server service on the source server, and created a new one without regard for any reservations or static IP addresses I may have had on my network (in fact, this created an IP address conflict – way to go, MS!). I was, however, able to stop DHCP on the new server, start it on the old server, retrieve my DHCP database, delete the scope on the new server, and import my previous database to the new server.

 

I used the netsh utility to export the scope from the source server, and import it on the destination server. This turned out to be premature, because the DHCP scope got wiped out again later – so my advice is to export the DHCP database from the source server before you begin the entire process, and then after every step that changes the networking via an SBS 2008 wizard, check the DHCP scope and re-import if necessary. If you’re doing this on a weekend and it doesn’t matter if the machines lose their DHCP leases, then just wait until everything else is done and do this step last.

 

You’ll want to use the NETSH utility with elevated permissions at the CMD promp, as follows:

 

1. On the SBS2003 server, run this at a command prompt:
netsh dhcp server export c:\dhcp.data 192.168.0.0  (substitute your internal network subnet)
This saves your DHCP database to a file o the root of C on your old SBS server.
2. Copy that file to C:\ on your SBS2008 server.
3. Stop and disable DHCP on your old SBS server.
4. On the SBS2008 server, enable and start the DHCP service.
5. On the SBS2008 server, run this at a command prompt:
netsh dhcp server import c:\dhcp.data 192.168.0.0  (substitute your internal network subnet).

 

 

Normally, when doing a migration, I recommend setting the DHCP scope to a low lease duration – but in this case, I think an 8-day lease duration is probably best, especially since the DHCP server address will remain the same if you swap IP addresses at the end, and you will get to keep your DHCP database if you export it with the netsh command.

 

C. Connect to the Internet (Clicked to start the CTIW).

The CTIW wizard ran successfully, trashing my DHCP scope again. I restored it again.

D. Configure the Internet address.

i) Start the Internet Address Management Wizard

(1) Selected “I already have a domain name”.

(2) Selected “I want to manage the domain name myself”.

(3) Typed my domain name into the field.

(4) Clicked the Advanced button.

(5) Chose not to use a domain prefix. (My SSL certificate does not have one.)

(6) Clicked OK, Yes on the warning, and Configure.

(7) Viewed the warning about the wizard failing to administer my firewall (good!).

 

The second part of this wizard deals with self-signed certs, which I am not using.

Skipped the self-signed cert bit because I have a real one.

I’ll see about moving the cert later if not prompted to do so.

ii) Task Complete -> Next

 

E. Migrate Network Settings.

i) Migrated DNS forwarders.

ii) Migrated the Mobile Users Group.

iii) Clicked to open the help for migrating SSL certificates.

iv) Followed the instructions for migrating my certificates (2 of them).

v) The “Add a trusted certificate” only allows one at a time.

vi) I have a second one which I will figure out how to add to another SSL website later.

vii) Task Complete -> Next

 

It should be noted at this point that the migration wizard trashed my internal authoritative DNS zone for my external domain name, and replaced it with a single host record for the new domain. How rude. I modified it manually to restore my DNS records.

 

F. Migrate Exchange mailboxes and settings.

i) Migrate Exchange mailboxes and settings. This brings up a help topic telling you how to:

(1) Remove Internet connectors from the Source Server.

(2) Migrate POP3 connectors (optional) from the Source Server.

(3) Move the Offline Address Book

(4) Move mailboxes from the Source Server to the Destination Server

(5) Move Exchange Server public folders.

 

It should be noted here that public folders and mailboxes have default size limits on them that should be adjusted before moving anything.

 

Before I started this, I fixed my FQDN in the SMTP connector so that the two exchange servers could talk to each other properly.

 

My event log had errors about communication between the servers, and I could not move a mailbox. This turned out to be because permission inheritance was blocked on the source server. This is a fairly common practice, because it was required in order to use EXMerge when migrating mailboxes into SBS2003.

 

Setting permission inheritance and restarting all Exchange services was not enough to resolve the issue. It was necessary to restart the source server. Once the source server was rebooted, the test mailbox moved successfully. I then started moving them all.

 

While the mailboxes were moving, I took care of the other tasks as well:

 

ii) Remove internet connectors from the source server

(a) Moved my smart host setting to the Send Connector on the new server first.

iii) Migrate POP3 connectors.

(a) None to migrate. Skipped.

iv) Move the offline address book.

(a) Followed the help file instructions.

v) Move the Public Folders

(a) Followed the instructions.

 

 

Additional notes here: When SBS works itself into the Exchange system, it disables the previous default recipient policy, and adds a new one. This does not cut off access to additional e-mail domains that might be in the old policy, but things in the old policy should be migrated to the new one anyway.

 

vi) Finish migrating Exchange and removed the old server from the organization.

vii) Task Complete -> Next

 

There are some procedures not covered in the migration help files regarding decommissioning the old server. In the page of the migration wizard where it told me that I would need to do so, there may have been a link to an MS article on doing so, but I didn’t see it. I’ll look for this next time around.

 

Basically, removing the old Exchange server entails deleting the routing group connectors (both sides) that were created when SBS2008 joined the organization, modifying the home server for the recipient update services, and uninstalling Exchange from the old server (SBS Disc 2 is required).

 

 

G. Remove legacy group policies and logon settings.

i) Clicked the link for removing legacy login scripts, which was a help file explaining how to remove them.

(1) I was not using SBS_Login_Script.bat. I removed my custom login scripts.

 

Login scripts stored in the netlogon share are being replaced with GPOs. This is due to the fact that UAC events are being triggered by conventional scripts. However, the SBS migration wizard does not specifically tell you to put your scripts into GPOs.

 

ii) Went on to the help section for removing legacy GPOs.

(1) I had already removed the default SBS GPOs long ago.

iii) Removed the WMI filter GPOs they referred to in the help.

iv) Task Complete -> Next

 

H. Migrate Users’ Shared Data.

i) Clicked the link for “How do I migrate…”, and it brought up a help topic.

(1) I used Robocopy with the /COPY:DATSO switch to migrate data.

(2) Recreated shares as appropriate.

 

I. Migrate SharePoint Web site

i) This opened a help topic with instructions to follow on both servers.

 

I started working through these instructions, and got to the part where it was going to have me create a new website called “Old Companyweb”.

 

At first, I thought that that this was not truly a migration and integration of the old SharePoint with the new – this was adding the old one so people could still access it, while someone manually moves things over to the new one.

 

I read further, and found where it says that it will, actually, upgrade the old site to SharePoint 3.0 as part of this process. I recommend, therefore, that you do NOT name the site “OldCompanyWeb” as they suggest, and instead name it something that the customer will be happy to keep using as you move forward – like for example, CompanyWebSite, or put their company name in it, or something. Further, when you detach the database files and move them over, you may want to take the time to rename the database files to something that does not include the old server name, for cleanliness – although this is behind the scenes.

 

J. Migrate Fax Data.

i) This was an automated process, which ailed for me because there is no fax service installed on the source server.

ii) Task Complete -> Next

 

K. Migrate Users and Groups.

 

Users and groups have already been migrated, but require some tweaking to show up in the new SBS console.

Note: This section is ripe for automation. Why didn’t MS make a wizard for this?

Note: I found out later that the Change User Role wizard removed all of my users from their previously assigned groups. Thanks, MS, that’s very helpful for a seamless migration!

 

i) Clicked the link for “Display the security group migration instructions.”

(1) Followed the instructions.

ii) Clicked Next to get to the Migrate User Accounts section.

(1) Clicked the link for Run the Change User Role Wizard.

(2) Ran the Roles wizard a couple of times for my user base.

 

L. Demote the Source Server

i) Clicked the link for “How do I demote the Source Server?”

(1) This help topic simply tells you to dcpromo down the old server.

 

Note: The help topic regarding demoting the source server is sadly lacking. It does not mention that you will need to update any static DNS or WINS pointers that you have on your other servers, workstations, or network appliances.

 

It also fails to mention that after you demote the old server, it might be helpful to remove its computer account from the Active Directory and run the netdom command to add an alias with the old server’s name, to help with any static shortcuts or registry entries on the workstations that might be pointing to the old server name.

 

M. Checked the box for “My source server is no longer a domain controller” and finished the wizard.

 

 

 

 

Things I did after the wizard:

 

1. Changed the server name and IP address of the source server so that it is still available on the network, but the old name and ip is available.

2. Exported the DHCP database in anticipation of the CTIW wizard trashing it for me again when I changed the server IP to match the previous source server’s IP.

3. Took a screen shot of my internal DNS zone for my external namespace in anticipation of the CTIW wizard trashing it for me (not worth the extra effort of exporting the DNS file, there are only a few records in there, I can fix them afterward.)

4. Ran the Connect to the Internet Wizard and adjusted the server IP address to be the IP the source server used to have. This is a helpful step because it avoids the necessity of changing static DNS settings and other settings that point to the IP address of the old server in network appliances, other servers, statically assigned workstations, firewalls, etc.

 

Note: The CTIW said it did not properly configure e-mail. It told me to run it again, and it failed again. I had to go into the Exchange Console and manually adjust the IP address bindings on the Receive Connectors.

 

5. Imported my DHCP database, made necessary adjustments, and fixed my DNS zone.

6. Ran the netdom command to add the computer name alias, and adjusted the registry setting to allow the netdom fix to work.

7. Added my login script into a new GPO called Login Scripts and applied it.

8. Installed printer objects with the exact same printer name and share name as on the source server, and tested network printers on workstations.

 

 

 

Some additional things that came up:

 

1. IE’s phishing filter was enabled via GPO. Some users don’t like that. I modified the GPO to allow the user to decide.

2. IE’s homepage was set to http://companyweb. Some users don’t like that, etc.

3. The anti-spam software requires MAPI and CDO. I had to install them. Here’s a blog entry about that.

4. The antivirus software wants to use .Net Framework 1.1, which is 32-bit only. Fortunately, it knows that this would kill OWA and other 64-bit application pools in SBS 2008, and warned me about it in time to cancel the installation.

 

After much Googling, it seems that this may be something that can be worked around, but the app installer does not know this, so it doesn’t really help. I will need to install the application console on another server, and push the Exchange and File System Antivirus components to the SBS server over the network.

 

 

So that’s it, in a nutshell. Your mileage may vary, of course. This is my first SBS 2008 migration from SBS 2003, so I’m sure I missed some things. Perhaps later, some other tips/tricks will come up that make some of the above unnecessary, or even incorrect. We can only hope.

 

Tags: answer file, deployment, Exchange, from boot to welcome, lua, Migration, replication, SBS 2008, SBSAFG, unattended

Scenario: You are doing an SBS 2008 Migration from an SBS 2003 domain. You’ve created your answer file, you’ve gotten partway through setup, but it seems to sit forever at this screen:

 

Eventually, you get this pop-up dialog telling you at it is taking longer than expected, and asking if you want to keep waiting.

What now? Maybe you’ve clicked the yes button once or twice already and waited another 20 minutes with no positive results.

Well, this is what happened to me, and I’ll tell you what I found out about it. Your situation may be different, but check out what I found out, and look for it in yours. If it matches, you might want to give it a try. Hopefully you have a good backup.

After sitting at this screen for way too long, I decided to do some digging. I sent a ctrl-alt-del to the SBS 2008 server and brought up the Task Manager. From there, I opened a CMD prompt, and found my way to C:\Program Files\Windows Small Business Server\Logs. I copied the file to a UNC share on the source SBS server to read it (but you can just use the “type” command in the CMD window and read the last few lines if you want).

The last few lines looked like this:

[3212] 081225.202335.1592:
Task: There are 0 pending replication operations.
[3212] 081225.202335.2530:
Setup: Attempting LDAP bind.
[3212] 081225.202335.2530:
Setup: Bind failed with: A local error occurred.
[3212] 081225.202335.2530:
Task: Waiting for replication to finish

That sequence repeated a few times. Definitely the choking point. I googled the hell out of that, and only found one item that looked remotely relevant. That guy was having the same symptom. He solved his problem by throwing away his SBS2003 domain and starting from scratch.

After MUCH digging, rebooting, retrying, and other things that I will spare you the pain of, I typed “eventvwr” at the CMD prompt, and looked through the event logs. I found, among other things, this event:

Source; GroupPolicy
Event ID: 1006
The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller (LDAP Bind function call failed).

Now we’re getting somewhere. I found numerous search results for that one, including a forum where some guys had this error, received a hotfix from Microsoft, and the problem went away. Apparently the problem is caused if you have ever done an authoritative restore on your 2003 domain. When that happens, the msDS-KeyVersionNumber property from the user object “krbtgt” is increased. Windows Server 2008 is not expecting this. Any 2008 DCs that are added to this domain have trouble binding to LDAP and authenticating to AD because of this.

There is a Microsoft KB article about a seemingly completely unrelated topic, with a hotfix link available for download. Microsoft PSS sent these guys this hotfix, and it made that problem go away. It needs to be installed on all Windows 2003 DCs.

I am doing this upgrade on a virtual server, I have a snapshot, so I figured “What the heck, let’s try it!” and downloaded the hotfix. I ran it on my SBS 2003 server, and said No to the reboot. Lo and Behold, my SBS 2008 migration is proceeding past the error point! It’s looking good!

Use this fix with caution. Your mileage may vary. Make sure you have backups and/or a snapshot before you do it. Best of luck!

Tags: Group Policy, Hotfix, LDAP, Migration, SBS 2008

Moving Exchange Public Folders from one server to another used to entail a fairly time-consuming process of opening the property sheet for EACH public folder, setting its replication properties, waiting for replication, and then removing the source replica. This was mitigated somewhat by the ability to propagate settings to subfolders. If you were really savvy, you moved all subfolders underneath one top-level folder, made the adjustment, and then moved them back. Even so, it was a labor-intensive, time-consuming process.

So we all cheered mightily when Exchange 2003 SP2 brought us the capability to right-click the Public Folder Store and Move All Replicas. However, this euphoria was short-lived for me. I found that this process often did not move all of the data.

Well, I was missing one important piece of information: Do not dismount the database! If the source database is dismounted before all its contents are moved, you have to tell it to move the replicas again. A dismount of the database creates the system folders again and blocks removal of Public Folder instances in the database.

I suspect that in my impatience to get on with the migration, I most likely made some other changes that required a reboot (which dismounts the database), and my public folder migration was interrupted. I just assumed that, like any other Exchange replication process, it would pick up where it left off when the store came back up.

That being said, I still highly recommend that you take a good backup of the Public Folders to PST before you use this method, just in case. Getting at the Public Folders to restore/verify data after an Exchange migration can be very time consuming if you didn’t export them to PST. It’s time well spent.

 

One additional tidbit: Make sure you set the public folder replication interval in the Public Folder Store properties. By default, the replication values are empty in the UI. I’m not sure if they are really not set in the software, but I always go in there and click the “defaults” button, or set the values I want.

Tags: Exchange, Migration, Public Folder Replication, Replicas

Special thanks to Lynn Johnson for the assist with verifying this method for me. I read it on the Internet, so it MUST have been true – but I wanted some verification anyway.

The Scenario:

For one reason or another, you need to do something to a computer that is going to trash the user profile. Maybe you’re migrating from a workgroup to a domain. Maybe you’re migrating from one domain to another, non-trusting domain. Maybe you’re migrating to a trusted domain, but there is a duplicate account in the new domain that you want to keep. Whatever the reason, you know that when the user logs into the new setup, the user profile is going on holiday.

The old-school way of dealing with this, which has its drawbacks, is to log on as an admin, rename the old profile, log on as the new user once, reboot to unlock the ntuser.dat file, log on as admin again, and copy the contents of the old profile to the new profile folder. This had issues with NTFS permissions on the profile folders, and in many cases the new path was different from the old path, which led to broken shortcuts, registry links (like the wallpaper), file paths in applications (AutoCAD, for example), etc. It was a mess.

Fortunately, there is a better way. I’ve only recently learned of it, and I wish I’d known it sooner. Much sooner.

The Solution:

1. Take note of the existing (old) user profile path.
2. Log into the PC using the new domain account.
3. Take note of the new user profile path.
4. If the user doesn’t have admin rights on the PC, log off and log on as someone who does.
5. Run Regedit and go to HLKM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
6. Expand the above key and you will see a list of SIDs.
7. Look through them, watching the “ProfileImagePath” value until you find the new one that was just created (the new domain user profile).
8. Change the path in the new domain profile to the path of the old profile folder.
9. Adjust the NTFS permissions so that the new user account has FULL CONTROL over the profile path.
10. Reboot and log in as the new domain user. The user profile should be intact.

Happy profiling!

Tags: migrating, Migration, ntuser.dat, path, registry, user profile