ADMT: What I Learned

29. March 2011 · Write a comment · Categories: howto, Microsoft, Networking, Servers, Troubleshooting, Windows · Tags: , , ,

Years ago, long before I started working at my current job, management launched a new contract in a office building just across the street. At the time, wireless network connections were still in their infancy and not to be trusted, so the new office was set up with a pair of servers, a nice new Active Directory Forest and Domain (DomainB), and a VPN to access resources on the primary network, DomainA.

Fast forward to three years ago, just before I was hired. The then-sysadmin was getting flak for the VPN being slow, so he installed a pair of wireless routers on the roofs of the buildings and linked the two networks. However, instead of getting rid of DomainB, he simply left it in place.

Fast forward to now. Due to cost issues, the contact in the remote office was physically moved to our main building. As such, their network equipment and servers came with them, which created cramped quarters in an already cramped space. As such, I set about doing what should have been done years ago – migrating users from DomainB to DomainA.

There was a group of client computers that needed to go through a round of updates anyways, so those were simply re-imaged and joined to a separate, restricted network (DomainC) used for our clients only (this had been another pet peeve of mine – due to costs, the clients in that office were put on the same network and although they had their permissions restricted, it was still a concern in my mind). The main problem, though, was the staff workstations. Not only were they setup on DomainB, put PrimaryDC.DomainB was also an Exchange 2003 server, and TertiaryDC.DomainA was our primary mail server running Exchange 2007. The first step was to manually export the mail for the twelve staff members and create their DomainA accounts, and then get them setup on the DomainA Exchange server. Once that was up and running, the Exchange 2003 install was shutdown. Although it took a while to manually transfer the mail by exporting to .PST files and then importing it again, it was the cleanest way to do the move (and also encouraged users to clean out their mailboxes).

The last step was to actually get the users logging in to DomainA rather than DomainB. That’s where ADMT (Active Directory Migration Tool) comes in.

ADMT comes in a few ‘current’ versions. 3.0 if the server it’s running on is Server 2003, 3.1 if it’s Server 2008, and 3.2 if it’s Server 2008 R2. The source domain (B) was running on Server 2003 boxes, but the target domain (A) was running mostly on Server 2008 boxes, so I installed ADMT 3.1 on one of those.

After getting it installed and playing around with it on a test VM, I learned a few things that helped me get all of the staff workstations migrated with minimal issues:

  • Setup a Two-Way Trust between the domains first, but be aware that if users are already authenticating on both domains by using store credentials, that may break unless you also setup permissions for users of both domains on effected shares.
  • Double-check your DNS configuration. If both domains have separate Forward Lookup Zones (which they probably do), make sure that the DNS servers in both domains are setup to perform Zone Transfers between each other, and then check to make sure that all A and PTR records are actually correct and current.
  • Make sure that the user you are logged in to on the server running ADMT is in the Domain Admins group on the target domain, and the Administrators group in primary DC on the source domain.
  • Change the DNS servers that the computers to be migrated are using to the servers on the target domain. This is important, or after the computer migrations are complete you may run in to issues when logging in (for me, Active Directory decided to continually lock out user accounts of migrated users because of a missing A record in the source domain’s DNS zone).
  • If you have any local firewall software running on the workstations that are to be migrated, either temporarily disable it or add exceptions for the Netlogon Service, File and Printer Sharing, and Windows Management Instrumentation (although the last may not strictly be needed – it was hit-or-miss for me).
  • Run the following command on the workstations that you’re migrating: net localgroup “Administrators” “DomainAdomain admins” /ADD (changing DomainA to your target domain). This is important, as local admin rights are needed for the computer migration steps.
  • If users from your source domain are using resources on your target domain and using stored credentials to authenticate, delete those stored usernames/passwords from the workstation (in most cases, open Control Panel, then User Accounts, and click ‘Manage Network Passwords’ on left). Then, once you have migrated the user accounts, give those accounts permission to access the required resources.
  • During the migration, if you are trying to migrate a computer account and you continually receive an error like ERR2:7666 Unable to access server service on the machine ‘computer.domain’.  Make sure netlogon and workstation services are running and you can authenticate yourself to the machine.  hr=0×80070005. Access is denied., and you’ve run the command above on the machine to give Domain Admins from the target domain local admin rights, you may need to remove the computer from the source domain, rejoin it to the source domain to re-establish the trust relationship, and then try the migration again.
  • After the migrations are done, make sure to go back to the DNS servers on your target domain and verify that the migrated computers’ PTR records reflect the new domain suffix (eg, changed from ‘workstation1.domainB.’ to ‘workstation1.domainA.’ (and leave the trailing . in, or you’ll have trouble!).

And that’s it! ADMT worked like a charm, and after using it to migrate and merge user accounts, and then migrate the computer accounts, everyone was off DomainB with out the hassle of needing to manually join DomainA and reconfigure the user accounts. By performing both the user account and computer account migrations, once the process was done users just had to login to their computers using ‘DomainAUsername’ instead of ‘DomainBUsername’ and everything was left exactly like it had been, right down to the desktop wallpaper.

And now I’m free to decommission two old servers.

Server 2008 x64 “Please wait for the Windows Modules Installer” and Boot Looping

29. December 2010 · 4 comments · Categories: "It's a Feature", Microsoft, Servers, Software, Troubleshooting, Virtualization, Windows · Tags: , , ,

Yesterday, while running a large lump of Windows Updates, one of my Windows Server 2008 x64 boxen decided to start boot-looping in the most annoying way. After applying a group of around ten updates and restarting, the server rebooted to the Welcome Screen and hung on the message “Please wait for the Windows Modules Installer” before eventually giving up and rebooting. After that, it booted back to the Welcome Screen and this time displayed the “Configuring Updates Stage 3 of 3 0%” message. All was well, I thought, until two minutes later when the screen went black and the server (gracefully) rebooted again, and then proceeded to loop under the same conditions, regardless of which startup mode is selected (Safe Mode, Last Known Good Configuration Mode, etc… will all produce the same results).

The news, unfortunately, isn’t good. Google was little help in the case, as most of the suggestions didn’t work. The only one that did was the suggestion to rename pending.xml in C:Windowswinsxs, however this comes with a

VERY BIG,
ALL-CAPS,
RED-LETTER WARNING:

By renaming said .xml file, your server will boot. It will still briefly display the Configuring Updates message, however the login screen will appear very shortly after. The problem is that, because there are updates that have been partially installed and aborted, Windows Update is now borked (attempts to run it will only result in a 0x8000FFFF error code, which is a generic code for “Something is broken, but we don’t know what”). Based on my own experience, and that of others, there is really no way to fix it. Sorry. Microsoft KB article 946414 that suggests that this error state can be fixed by deleting the PendingXmlIdentifier value from HKEY_LOCAL_MACHINECOMPONENTS, however it doesn’t work in this case, as the entire Windows Update backend is full of half-completed operations that can’t be cleared or rolled back.

In short, if this has happened to you, I regret to inform you that your server is basically FUBAR – the only upshot of this is that as the server will now boot entirely to the desktop, and (unless something is really broken) all services should be working (note: I did have to reboot any Hyper-V virtual machines that were suspended during the reboot in order to regain network access to them). As such, you should be able to do whatever is needed to backup the server before reformatting it. Even in the event you could get Windows Update working again, I wouldn’t trust the server in a production environment.

TL;DR Version: If this happens to you, rename c:windowswinsxspending.xml using a Windows DVD to boot from, and then backup the server in prep for a reinstall.

More Exchange Madness!

29. September 2009 · Write a comment · Categories: howto, Microsoft, Servers, Software, Troubleshooting · Tags: , , ,

I’ll just sum this one up, as it’s pretty boring, but there are some important details.

1) Computer account for a Domain Controller/Global Catalogue/Exchange server (virtualized in Hyper-V) becomes corrupt, including the underlying metadata.

2) That server cannot ‘see’ the domain, with numerous errors from both Exchange and the Event Viewer stating that it cannot replicate due to DNS problems.

3) Rolling the .vhd back to a previous week results in the same issue.

4) When attempting to demote/dejoin/join/promote the server from/to the domain, the computer account is deleted, but not the metadata, and the server cannot be joined to the domain again.

Solution? Backup the Mailbox Databases from the First and Second Storage Groups, as well as their transaction logs, then create a new .vhd, reinstall the OS, join it to the domain, add the newly created computer account to the ‘Exchange Server’ and ‘Exchange Install Domain Servers’ groups, install Exchange using “setup.com /m:recoverserver” (make sure that you’ve manually installed the prerequisites, such as IIS+IIS 6 Management Console, etc… before doing this), then copy the Mailbox databases back to the default install location. After that, correct the permissions on the Mailbox folder if needed (simply inherit the permissions from the parent object) and reboot the server. When it finishes booting, open the Exchange Management Console and mount the Storage Groups (note: you may have to open the properties on both groups and uncheck the option that prevents Exchange from automatically mounting the databases on boot).

Simple, right?

Server Complete

06. April 2009 · Write a comment · Categories: Hardware, Servers, Software · Tags: , , ,

So my idea of live blogging the setup and configuration of the new server fizzled. Too much to do and not enough time to do it. Between recovering critical user data from a failed hard drive, writing batch scripts to grab PST files and replace Word templates, and importing a whole mess of other stuff there just wasn’t enough weekend.

All in all, it went well. The physical server was setup with Hyper-V and the Symantec Endpoint management apps. The Terminal Server VM was given 8GB RAM and a 125GB VHD, while the Exchange Server (which, until our ISP gives us the go-ahead to actually run a mail server, currently only deals with Mailboxes and Public Folders) was given 6GB of RAM and a 125GB VHD of it’s own. That leaves 2GB of RAM for the physical server.

This morning was go-live, and by mid morning all 25 employees were logged in and active without any serious issues. Best of all, even with all of them in Outlook and running a myriad of apps, everything ran smooth as silk.

Once I’ve made sure everything is working fine, I’ll post a tutorial for backing up VHDs with Windows Server Backup and VSS.

Upcoming Event: Server Unpacking – Updated

26. March 2009 · Write a comment · Categories: Hardware · Tags: , , , , ,

It’s been a little while since I’ve posted, hence this post.

Within the next week I’ll be receiving a custom built Dell PowerEdge 2900 III server, and I’ll be posting unpacking pictures and a setup tutorial post. Some of the specs:

  • Two Intel Quad-Core Xeon Processors (E5420) @ 2.5Ghz (2x6MB L2 Cache)
  • 16GB DDR2 667Mhz RAM
  • 4x 250GB SATA2 HDDs (hot swappable) in a RAID 10 Array
  • Redundant Power Supply

This setup will be running Windows Server 2008 Enterprise with Hyper-V, hosting two virtual environments (a Server 2008 Terminal Server and an Exchange 2007 Server). More details to follow!

Update (02-April-09): The hardware and software are in! Tomorrow I’ll live blog the setup process!

Installing a Font via GPO (Server 2003/2008)

23. February 2009 · 20 comments · Categories: howto, Microsoft · Tags: , , , , , ,

I was approached today by a manager requesting that I install the Eco Font on our 60+ workstations. Not being big on manual installations, and definately not wanting to take the ‘email the font as an attachment with installation instructions’, I opt’ed for the only route that made sense – installation via Group Policy Object!

This process is fairly straight forward, with the only potentially annoying portion being the creation of the actual .msi file to install the font. Sure, you can create batch startup scripts that copy the file to the fonts folder and update the registry, but this is a lot cleaner.

To create the .msi package used to install the font, I grabbed a free copy of WinInstall LE. Unfortunately registration with a non-free (read: Hotmail, Gmail, etc… accounts not accepted) email address is required. I tend to create throw-away accounts (eg, a9s6dfa9@my_domain.com) that I promptly delete afterwords. I get enough spam as it is.

Once downloaded and installed, there isn’t that much to do: launch the app, then create a new package by right-clicking on Windows Installer Packages in the top middle and click on New Package. Give it a name and description and you’re ready to start. Expand the package you just created, and you’ll see a new line item called New Feature. Select it, then change the name and description in the right-hand pane. No other changes required.

Next, expand the feature line that you just renamed, and you’ll get another line itm with a GUID (eg, {82B7A2B4-45E8-497A-AFB5-D182960CABF1}) – go ahead and delete it by right-clicking and choosing Delete. Now right-click on your feature and choose Add Files to Feature. Leave the Source line at it’s default value, but change the Target line by pressing the browse button (“…”).  From the list, select [WindowsFolder], then in both the Long folder path and Short folder path boxes add Fonts, so they read “[WindowsFolder]\Fonts” (without the quotes, of course). Now click OK. All we need to do now is add the file, which can be done by clicking the Add File button directly under the Target box. Browse to find your font and click Open. Now click OK, and you’ll see two new GUIDs under your feature.

The last thing we need to do is make this .msi package install without prompting the user. Simply click on the package line (not the feature), and click on the Install Modes tab on the right. Select Install only per machine and check the Show basic user interface only (simple progress and error handling) box.

Now all you need to do is compress the package – this will physically include the font inside the .msi package so that you only need the .msi file itself, rather than the .msi and the font files. To do this, simply select the Windows Installer Package inside WinINSTALL LE (not the feature or the components) and choose ‘Compress’ from the ‘Action’ (or right-click) menu. In the new window, simply press ‘Compress’, and you’re done!

By default, the .msi packages you create with WinInstall LE are located at \<Computer Name>\WinInstallPackages\<Package Name> on the computer you created them. Although the permissions on their share are very relaxed, we want the installer package to be in a high-availability location so that we can be sure the GPO we’ll create in just a short while will always be able to access it. I suggest copying it to \<Domain Controller>\SYSVOL\<Domain Name>\scripts. The guarentees that all of the clients will be able to access it.

Now login in to one of your Domain Controllers and fire up Group Policy Management. Create a new GPO and link it to whatever computer groups you may have, then right-click it and choose Edit. We’ll be working under the Computer Configuration header – if you’re using Server 2008, select Policies, then Software Settings – Server 2003 users just select Software Settings. Now right-click on Software Installation and choose New -> Package. Browse for your .msi package, select it, and choose OK. Selected Assigned, then OK.

You’re done! Just allow time for the GPO to propagate through your domain, and the next time your domain-joined systems reboot the font will be installed.