Saturday, March 20, 2010

Migrating NT 4 to Windows 2000, Sun VirtualBox, and VMware

I just performed my last Windows NT to Windows 2000 domain migration (I certainly hope it's the last time!) I was tasked with moving an NT 4 domain with a single domain controller to Active Directory. Fortunately, the company did not have Exchange (I've done NT 4 + Exchange 6.5 to Win2k3 + Exchange 2003, and it's not a fun migration.)

Here are the steps I followed, more or less:

1. Obtained Windows NT Server media, Windows 2000 server media, and Windows 2003 R2 32bit media

2. I migrated the existing NT 4 server to a VMware server 1 VM (the company only had a single VMware server running on CentOS 5.2. I used VMware converter version 3.x (version 4 does not support NT 4.)

2a. I had some time on my hands, so I simulated the whole thing with a copy of the VM I created in step 3. I did the entire migration on virtual machines before continuing on site.

2b. I created a snapshot of the virtual NT 4 PDC.

2c. I set up an additional DNS server on another box (a windows 2003 server) and made it the primary DNS server. It is possible to use Bind 9, but the client did not have enough unix infrastructure to make that practical.

3. I created a Win NT BDC as a VM on Sun VirtualBox 3.x. I created a single disk of less than 4GB (I made it 3.8GB.) The disk did not need to be huge. I was not intending for this VM to be around long term. This worked fairly well. I originally tried to create it using VMware Workstation 7.x, but had several annoying problems, so I just used VirtualBox. The NIC on the VM was bridged. I gave it a static IP and put it in DNS.

4. I promoted the VM I created in step 3 to be the PDC (using the server manager on the original NT 4 PDC.

5. I created a snapshot of the new NT 4 PDC

6. I upgraded the new PDC to Windows 2000. I ran into some problems with the VM crashing (VirtualBox crashing, to be precise.) I stopped the crashing by disabling all virtualization extensions on the VirtualBox config for the VM. At any rate, this created an Active directory installation. I pointed DNS to the win2003 server I mentioned in step 2c.

8. After the upgrade and Active directory creation, I made the new win2000 box the primary dns server for the zone. Once I had transferred the zone successfully, I changed the zone to be active directory integrated.

9. I applied Windows 2000 Service pack 4 and all relevant updates ( I had to install IE 6 sp1 to get windows update to work correctly.)

10. I ran adprep /forestprep on the new windows 2000 domain controller. Adprep was located on the second disc of Windows 2003 R2 32bit in the directory CMPNENTS\R2\ADPREP.

11. I ran adprep /domainprep and adprep /domainprep gpprep on the Windows 2000 domain

At this point, I had a Windows 2000 domain. I could safely delete the NT 4 BDC and shut it down. I left it around, as there were a few files to grab.

12. I then ran dcpromo on the Windows 2003 box I mentioned earlier, and made it an additional DC.

13. I made the windows 2003 R2 dc a global catalog server.

I haven't had time to go back and finish up (add another Windows 2003 R2 box (or even Windows 2008 R2)) yet. I verified that filesharing and login worked, of course.

Thursday, March 11, 2010

Remote Desktop Clients, 32Bit Applications, and Windows 2008 R2

I recently ran into a problem with Remote Desktop Services on Windows 2008 R2 (formerly known as Terminal Services from Windows NT 4 through Windows 2008). The problem occurs when someone configures an RDP session that automatically launches a 32 bit application on connection. As you may know, Windows 2008 R2 is 64bit only. The problem I was seeing was that there was frequently a delay after exiting the application.

What should happen is that the RD session should drop after the application closes. What often happens is that the user sees a blue screen for up to two or three minutes, then the session completely drops.



I figured out the cause by using the Remote Desktop Services Manager. I launched a client session that launched the 32bit app upon login. I then closed the application, and the session hanged. Looking in the RD Services Manager, I noticed that there was a service from the session called "splwow64.exe." I killed that process, and the session dropped.



The Fix



The fix is pretty simple. It requires a regedit. Perform this regedit at your own risk! You should backup the registry before you start.

Navigate to the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcs

Add the following 32 bit DWORD:
splwow64.exe

and set the value to 0

The fix worked instantly, at least for me. Your results may vary, of course. As far as I understand, you can create other dword values in there to terminate other programs that are stalling the exit of remote desktop sessions.

Apparently, splwow64.exe is used in thunking (in this context, converting memory addresses from 32 bit to 64 bit.)

Friday, March 5, 2010

Bacula 5.0

Bacula 5.0 has been out for a little while. Apparently, the developers decided to skip 4.x to differentiate the community edition from the enterprise edition. The new features list is here. I'll be setting it up soon and will likely post some sample configurations.