Whenever I re-deploy Win2k3 I always install Active Directory first, DNS during the process and DHCP last. There’s no method to my madness; it’s just the way I roll.
Installing Active Directory is simple enough, but one lesson I’ve learned that makes administration a lot more straightforward is not naming the domain according to typical internet suffixes; i.e. rather than have the DNS domain name be “dopefish.com,” name it “dopefish.local” or “dopefish.internal.” I’ve heard that DNS can have a hard time distinguishing between internal and external sites if both are named as “dopefish.com,” but it also helps me determine which side of the gateway I’m dealing with if I see “dopefish.local” versus “dopefish.com.”
So I got AD up and running and moved on to configuring DNS. By its nature DNS takes a name (“server01.dopefish.local”) and looks through its tables to see what IP address corresponds to this name; Active Directory setup automatically configures this much, but for whatever reason it does not configure the reverse lookup, where DNS takes an IP address and tries to determine the name. Adding a reverse lookup pointer is a simple enough affair though; follow the steps in the wizard to create a reverse lookup zone, then right-click and select “Add Pointer.” Enter the DNS name of the domain controller (in my case, “server01.dopefish.local”) and hit Resolve. The IP address should populate in the bottom window. Exit out of there.
DNS is one of the more critical pieces of the infrastructure since if it does not work, logging in to the domain will take forever and a lot of things (like Group Policy) will not work in turn. To make sure DNS is working properly, in the leftmost DNS window right-click on the server name and click “NSLookup.” If DNS works, you’ll see some information about the DNS server– namely the server name and IP address. If DNS is not working, you’ll see some pretty obvious error messages. Every time I’ve had issues with DNS not passing the NSLookup test, I overlooked setting up that reverse pointer.
Next step was DHCP. DHCP is another simple affair; I set up a scope of 192.168.1.1 – 192.168.1.254 and reserved 192.168.1.1 for the DC. I made a huge mistake that took me a while to figure out in that in the advanced scope options, I set the Name Server to 192.168.1.1 and could not figure out why clients took forever to log in to the domain and Group Policy was not working. Furthermore, my server had passed the NSLookup test but my clients could not resolve the server name. Eventually I realized that Name Server was the incorrect parameter; right under it was a parameter to specify the DNS server. Duh.
So at this point I finally had Active Directory up and running, DNS was resolving correctly both ways and DHCP was correctly issuing IP leases. Next I moved on to Group Policy.
I downloaded Microsoft’s GPMC tool which (stupidly enough) was not included with SP2; it’s a separate download altogether. It’s pretty much essential for non-destructive GP editing. While you can edit general Group Policy for both the domain and the domain controllers, the GPMC tool allows you to tailor Group Policies to individual Organizational Units. The other benefit to GPMC is that you don’t have to mess up the default domain/domain controller policies; you can create new ones that supplement or replace the defaults. I spent a bit of time tooling around with GP.
The last task I tackled today was setting up a public file share. Creating a shared folder in Windows is easy, but I found setting up a script to automatically map the drive at logon was a little trickier. I set up a batch file that contained only the line “net use Z: server01pub$” and used GP to run this script at user logon. The permissions on the script were read/execute for Domain Users. I did run into a problem where this script was not being run at logon but found that yet another tweak of GP fixed it. In this case I modified User Config > Administrative Templates > System > Group Policy and changed Group Policy Slow Link Detection to 0. I was using VMWare Server to run my instance of Win2k3 and apparently Windows thought my virtual network was too slow. Once I modified that the logon scripts ran without a problem.
So, as a recap, here are the problems I experienced today and their solutions:
Problem: DNS was correctly resolving addresses on the server but clients were not properly resolving addresses.
Problem: Group policy was not being applied due to failure of DNS.
Problem: Logging in to the domain took forever.
Solution: The DHCP server was not sending the correct address to the clients; checking the scope options revealed that I was sending a Name Server address rather than a DNS server address.
Problem: Group Policy-enforced logon scripts were not executing.
Solution: Windows thought the connection was too slow and aborted execution of the scripts; changing Group Policy Slow Link Detection to 0 disabled this checking mechanism and allowed scripts to run regardless of perceived link speed.
That’s all for today; not sure what I will tackle tomorrow.