Rob Golding

Okay, so if you’re anything like me - and like things to be done properly first time (and also to look neat), then you’ll know what I mean when I talk about the separate _msdcs zone in DNS on a Windows AD DNS Server. Of course, you have to be a nerd, like me, to know what I’m talking about here also - but that’s assumed seeing as you’re reading this blog. I digress…

If you have ever reconfigured said DNS server, and recreated the DNS zones from scratch, you’ll know that the neat zone that keeps all the SRV records separate from the oh-so-important A records, disappears - and gets put in a folder under the usual domain root.

Well, I have a solution to the ever so pressing issue. Obviously the only way anyone is going to risk breaking their whole Active Directory network will be if, like me, they are so _totally_ OCD about this kind of thing.

So, if you’re interested, I’ve written a short article on how to restore this behaviour, and published it as always on maxms.net. If you think it might help you out, then here’s the link:

http://maxms.net/article/Restoring-the-Separate-_msdcs-Zone-in-DNS

But remember, follow that article at your own risk!

As a matter of curiosity more than anything, I often wonder whether other people’s methods and practices for setting up AD are similar to my own. I will explain as best I can my own procedure, in an attempt to see how it compares to the rest of the IT community.

Firstly, I install DNS on the Domain Controller to-be. I don’t do any configuration on the service, just install it. Then, running DCPromo, I allow the wizard to configure the DNS Service for me. This makes sure that the two separate zones will be present - _msdcs.domain.name, and domain.name. This seems much neater to me, and I like to see this result - so I allow the wizard to take care of it.

When the domain is installed, the first thing I usually do is open up the default domain policy and remove all the password complexity options. These are usually just an annoyance - and unless the network has any particular security needs, I disable them all. Maybe leaving the length value at 6 if it’s inappropriate to turn it off completely. I like managing GPO’s from the Group Policy Management Console (GPMC), so that usually gets installed straight away.

In regard to the structure of the domain, I make an OU with the domain’s Netbios name in the root, and under that I create some OU’s as follows:

• Computers
• Distribution Groups (If Exchange will be installed)
• Security Groups
• Servers
  • Exchange Servers (for a special shutdown script)
• System Users
• Users

As for an explanation for that Exchange Servers OU, I make a shutdown script to stop all the exchange servers when it shuts down, to make the process a hundred times faster. I am so impressed by this technique, it works flawlessly every time. This OU allows me to assign the shutdown script via GPO to all Exchange Servers in the domain. Note that the DC stays in its own Domain Controllers OU that is created by the system automatically.

I guess at this point I’m feeling like I should do a backup of the DC. DHCP servers need authorizing, and Remote Desktop needs configuring. When that’s done, we’re basically there. Get the clients joined to the domain and we’re off!

I have no idea whether my procedure is similar to anyone elses, or in any way superior (or indeed inferior) to others. Give me some opinions anyway, it will be interesting to hear from the rest of the community.

Okay, so the network that I have been managing for some time now has just undergone a pretty big redesign. It’s actually a home network, but it spans 2 sites – my house and my friend’s house. They are “joined” by a site-to-site VPN connection, which gives us a load of benefits like easily sharing photos, programs, and an AD/Exchange forest.

Up until recently, the network was running with just one physical server at each site, we shall call them Site A and Site B, each with VMware Server installed. Both servers were configured almost identically, with the host machine running AD (Active Directory) and Exchange 2003, and a VM running ISA Server 2006 for the firewall/VPN. Another VM was used for hosting some websites in the Perimeter network.

The redesign saw one new server in at Site A and two new servers at Site B – although the main server at Site A has been upgraded significantly. The new servers were installed to take the firewall away from the Virtual Machine to a physical one – as this is much more secure. Also, the second new server at Site B hosts Exchange, while this is now on a VM at Site A.

This network doesn’t support many clients or users, but it used mostly for educational purposes. For that it is perfect. We have a multi-tree forest AD configuration, with one domain for each site (or each house!), and one Exchange organisation spans the entire forest, with one Exchange server at each site. This also helps if one server/network is down, as the other will pick up the email for both sites – so we have a failsafe if one network is having problems.

I have published a “public” version of the network diagram, with external IP addresses/names removed, just in case anyone might find it interesting. Just click the thumbnail for a fullsize version.

As you may have noticed, I’ve used the names of gods from Greek and Roman mythology for the servers. The web servers are the oldest ones there so they haven’t been renamed yet. Maybe an exiting project for the future!

Both networks now have a 20mb/784kb internet connection (up/down), so the VPN link is essentialy 784kb/sec both ways. That’s pretty good for things like AD replication, but not brilliant for sharing files and photos.

The active directory is the aspect of the network I am most proud of. Since the rebuild it has been working flawlessly, although I am forever looking at ways to expand the directory. The DC at each site hosts a DNS zone for both domains, which provides redundancy for DNS if one DC is down, and both servers hold a copy of the Global Catalog. This allows for fast directory searches from both sites, and gives each Exchange server a GC to look to.

The forest is split logically, as well as physically, into sites. This allowed me to easily alter the replication schedule for the Domain Controllers, although I decided to leave this at hourly intervals, as I saw no reason to alter this value.

Hopefully the AD forest and network infrastructure will provide a solid base to expand on, and I will post about any major additions to the network. At present the clients consist of XP and Vista machines, but we are soon to aquire a new desktop, which will be running Vista, that will make a nice addition to AD.

One word, or at least one acronym: GUID.

Background: I manage a multi-tree forest, with two trees, one in each of two sites. They are connected by a slow site-to-site VPN link, over which all AD replication takes place.

The domain controller at the forest-root-domain needed rebuilding, as the operating system was installed on a flaky single disk, and was due to be moved to a RAID1 array. So I thought it best to promote another DC, transfer all FSMO roles, rebuild the first, and transfer the roles back. This process went swimmingly, and the first DC was back online in no time.

However, when it came to the second site, it seemed that no replication whatsoever was taking place. After delving into AD with tools such as adsiedit and replmon, I discovered that the second DC had not “heard” about the rebuild of the first. This meant that the GUID had not been updated to hold the value of the newly installed server. The fact that I had used the same name as before didn’t help the situation at all.

In the end, it was clear that I would have to either restore the original DC from a System State backup, or rebuild the second domain from scratch. I chose the latter, as it was a small domain, and wouldn’t take very long. Now the process is complete, and we have a fully functioning forest again (after lots of metadata cleanup and /forceremoval’s!).

I won’t forget this one in a hurry - allow time for big changes to replicate before making more big changes!