Windows Server 2003 Installation and Domain Consolidation

As you know, you need to run the Adprep utility from the Windows 2003 CD-ROM to prepare the Win2K domain before you can add the first Windows 2003 DC. Unfortunately, the New York domain had some problems that I had to clean up before I could introduce the Windows 2003 DC on the network. The New York domain had a DC that existed in Active Directory (AD) but was no longer active. Because the DC was no longer active, I couldn’t run DCPromo to demote this computer from a DC to a member server. I had to follow the steps in the Microsoft article "How to remove data in Active Directory after an unsuccessful domain controller demotion" (http://support.microsoft.com/?kbid=216498) to manually remove the DC entries from AD. After I removed the DC, I was able to run Adprep on the New York Win2K DC. Because I was in Los Angeles and the DC was in New York, I decided to share the \i386 directory on the Windows 2003 CD-ROM so that it was accessible to the New York DC. I used Win2K Terminal Services to connect to the New York DC, then ran Adprep. I was then able to run Dcpromo on the Windows 2003 server to make it a DC.

I installed Exchange 2003 on the new Windows 2003 server into the New York Exchange Site (New York was already running Exchange 2000), but into a separate Los Angeles Administrative group. That means the New York and Los Angeles locations can be managed by separate workgroup administrators. The Los Angeles office was running a UNIX-based email system with Eudora as the email client. Because the Los Angeles site had only 20 users, I manually created new accounts for them in the New York domain. I took the following steps to complete the migration:

1. I installed Microsoft Office Outlook 2003 on each Los Angeles workstation.
2. I transferred the existing Eudora mail to the Los Angeles Exchange server.
3. I transferred file server share information from the old Win2K server to the new Windows 2003 server.
4. During the transfer of the file server information, the workstations left the old Los Angeles domain and joined the consolidated New York domain.

We copied the Outlook 2003 setup files to a Windows 2003 share to make installation easier. Unfortunately, no one from the Win2K domain was able to access the share on the Windows 2003 server. Windows 2003 by default has Server Message Block (SMB) signing enabled. I still needed the Los Angeles workstations to belong to the Win2K domain, and I wasn’t ready to have them join the consolidated New York domain until I was comfortable that the email was working properly. To allow users from the Los Angeles domain to access the new Windows 2003 server in the New York domain, I temporarily disabled SMB signing on the Windows 2003 server. To do so, I set the following registry subkeys to the specified values:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\enablesecuritysignature to 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\requiresecuritysignature to 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters\enablesecuritysignature to 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters\requiresecuritysignature to 0

These settings permit the computers in the remote domain to access shares on the Windows 2003 server. Of course, when the Los Angeles workstations join the New York domain, I'll change the servers to require SMB signing.

Outlook 2003 has a great import utility to import Eudora mailboxes into Outlook, so users didn't lose any email messages. I installed Outlook on each workstation, verified that each workstation had the most recent service packs and patches, then moved the user's mail to Outlook. After importing the mail, I tested the system for a week, then moved the file shares to the new server and configured each workstation to join the consolidated New York domain.

After the workstations joined the New York domain, I noticed that the workstations behaved differently. I installed Group Policy Management Console (GPMC) on the Windows 2003 server and looked at the Group Policy settings. Unfortunately, the Default Domain Policy was modified to point the workstations to a Software Update Services (SUS) server in New York and to synchronize off-line files with the New York Server. This setup would cause serious stress on the WAN link between Los Angeles and New York, so I removed these Group Policy settings from the Default Domain Policy, created separate policies, and linked them at the site level. In general, I suggest that you don't modify the Default Domain Policy and instead create separate Group Policy Objects (GPOs). This approach gives you more flexibility when linking GPOs. After I made the Group Policy changes, I transferred the users' data to the new server. Finally, I installed SUS on the Los Angeles server so that the workstations will automatically receive the latest patches.

Tip
Microsoft recently updated its to Knowledgebase search engine. I think the changes make it more difficult to search for articles because the search engine by default only searches Knowledgebase articles related to a specific product. Depending on the nature of the problem, you might not know what product to specify when performing a search. This update is probably in preparation for Microsoft’s new search engine, which will compete with Google. You can still access the Knowledgebase through the link http://support.microsoft.com/search/?adv=1. Then search for all products by clicking Specify a product or version, then clicking All products. However, I still find the new search engine difficult to use. The next time you need to find something on the Microsoft site, go to www.google.com/microsoft and just type in the relevant keywords. In addition to articles, you’ll find other relevant sources to help you solve your specific problem.

End of Article