« Posts tagged Server 2003

ADMT: What I Learned

March 29, 2011 / posted in howto, Microsoft, Networking, Servers, Troubleshooting, Windows / No Comments

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.

Installing a Font via GPO (Server 2003/2008)

February 23, 2009 / posted in howto, Microsoft / 16 Comments

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.