Log of Events leading to an eventual career as network administrator or as the head of my own private e-business:

There are a number of skills I must possess in order to ensure optimal performance of a network. The most current issue that has been perplexing me is the inability of my test workstation to join my test domain.

Relevant facts and actions are:
The server is configured as a domain controller, a DHCP server, an IIS server, and a DNS Server. This is necessary, although not best practice, because it’s the only server I have in my possession.

The DHCP server has a scope configured in the private IP address range from 192.168.1.100 to 192.168.1.254. Scope options are configured to assign IP addresses within the range and to provide the DNS server address of 192.168.1.102. This is the address of the server, but I can already see a problem in the fact that I’ve configured the server with an IP address within the scope. It would be better to configure the server with a static address that is NOT within the range, i.e. anything between 192.168.1.2 to 192.168.1.99 as this would prevent the computers (even though all I have is the one workstation) from having IP configuration redundancy problems. I have also assigned a default gateway server option of 192.168.1.1. This is the address of the Linksys wireless access point router within the network used to send packets back and forth between computers and to and from the internet via the ISP. At some point I suppose I should install forwarding for internet accessibility, and use the local DNS server for name resolution to network shares in an internal domain. I’ve disabled DHCP and DNS on the router.

Most of the time the culprit of not being able to join a workstation to a domain is simply entering an incorrect domain name. But this most assuredly is NOT THE CASE, because I’ve checked it a dozen times.

I can ping the workstation from the server and vice-versa. The client is configured to obtain its IP address from the DHCP server. It is able to do this successfully, so it doesn’t seem that the problem lies with DHCP.

However, I am unable to ping the FQDN (fully qualified domain name) of the server from the workstation or server itself suggesting there’s either a problem with Active Directory or the DNS server as these two services are inextricably linked. These are the most likely culprits responsible for the failure of the workstation to find the domain server when I try to join it to the domain. The error I get when the workstation fails to find the domain states that it was unable to find the DNS SRV resource record necessary for joining the domain.
So, in order to diagnose DNS I could use debug logging and / or check the error events on the DNS server Event Viewer. It makes sense to verify whether or not it’s the DNS server that’s causing the problem, as its elimination as a possible culprit would mean it was the Active Directory partition that’s malfunctioning. I should research the results of the Event Viewer errors or the ‘Incoming’ results of debug log. I will document the results of this process in the next post.

Also, I should run the dcdiag command-line utility to test the integrity of the Active Directory server. There are a bunch of diagnostic tools available to troubleshoot server malfunctions. The difficult part is knowing what to do with the information that gets returned, or being able to make any sense of it for that matter.

What I have done so far, in my reckless haste, is to just remove the DNS service altogether and reinstall it with the same parameters as before. This has proved inadequate in solving the problem. I also tried restarting the DNS Server Service to no avail.

Then, in feckless reckless haste I removed and reinstalled the Active Directory partition, something of course you would NEVER want to do in the context of a large production network. But, I did learn that removing the Active Directory and replacing it to make it possible for the workstation to join the domain was also ineffectual. And to further complicate matters, I should have realized that doing so would create a new Administer User Profile that would replace my old one. It makes finding necessary files and folders created in the context of my previous User Profile difficult and time consuming. Plus I have to reinstall a lot of programs and tweak a bunch of settings just to get back to the setup I had before uninstalling the AD. Let that be a lesson to you, young man!

So now, I need to organize the files and folders of the various administrator accounts and merge them into the current profile. In fact, I need to start thinking about which files I plan to save once the evaluation copy runs out of time, and backup those files to the external hard-drive. At some point I plan to get another computer to be used as a full time server, so that I can replace with OS of my laptop with XP Professional (I’m finding some devices and programs just don’t work the same on Server 2003). I suppose the rule is Server is Server and Client is Client and never the twain shall meet.

Ideally, I’d like to find a computer that can run Server 2003 from some schmuck on craigslist who also has a copy of the XP Professional CD because I ended up having to install the one copy I have on a borrowed workstation.

The painful lesson I learned from this fiasco is that if you upgrade to XP Professional, you can roll back to 95, 98, ME, or 2000, but you can’t roll back to XP home edition. I put the evaluation copy of XP on the (borrowed) computer and had to install my legitimate copy on it once the 180-day evaluation period ran out. If I hadn’t, there would have been hell to pay because of all of the files on the computer would have been lost, and I might not have been able to borrow the computer again.

Another issue that has caused me some concern was my inability, back in the day when I successfully networked these two computers in a domain, to copy the local profile and save it to the network share of user profiles on the server. The idea was to do this, and then create a user account in Active Directory with the same name as the local account and point the profile location of the user account to the share on the server. I tinkered with nearly everything I could think of in my ill-fated attempts to do this, including changing the local security policies to deny logon rights to the Administrator. That was brilliant! Luckily I still had another administrator account I was able to use to return the security policies to their default settings. So as you can see, it’s been basically a comedy of errors when it comes to smooth network functionality, but I suppose the important thing I’m learning is what NOT to do.

Rule number one: Don’t do anything in haste and frustration. Problem solving requires patience and discipline. You need to approach each problem you come across with the cool analytical reasoning of a machine. You should use the following process as a guide:

• Encounter the problem
• diagnose the circumstances
• eliminate possible culprits
• isolate the cause
• determine a remedy
• fix the problem
• document everything you’ve done
• recreate the problem
• fix the problem again
• smirk like a badass

Nowhere in this process is it written to give up, get pissed off, smash the computer with a golf club (although the thought has occurred to me more than once), or state that the problem is beyond your ability to resolve.
Hopefully the next post will be filled with glowing highlights of how I figured out was wrong, successfully joined the computer to the domain, and created a roaming profiles of all user accounts.