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.

When I was “starting out” in the IT field, I always used to setup shared folders in a certain way - I would set the Share Permissions to Everyone - Full Control, then use the NTFS Permissions to control access to the share - which always seemed like the most simple and secure way to do things.

However, when talking to the Network Administrator at my college, I was informed that setting the “Full Control” item was extremely bad from a security standpoint, as it allowed any user in the specified group (in this case, Everyone) - to change options in regard to the share configuration - like the permissions themselves.

So from this point on, I changed my habits to setting the Share Permissions to Authenticated Users - Change, and then using the NTFS permissions, as before, to control access to the data. Today, however, I decided to do my homework.

A quote from this article states the following:

“The recommended permissions have been tested, and work correctly; but there are alternative approaches. For example, some experienced administrators prefer always to set share permissions to Full Control for Everyone, and to rely entirely on NTFS permissions to restrict access.”

To me, it sounds like Microsoft have no reservations about using this method, and certainly don’t mention any security risks at all. So, hearing anyone else’s opinion would be very useful, but seeing as it works well - for now I will carry on using the Authenticated Users - Change permission object.

Up until yesterday, my Exchange server was my DC - they were one and the same. As anyone will tell you, this isn’t a particularly desirable configuration. For one thing, if you want to demote the DC, you have to uninstall Exchange first, and that means lots of migration and replication and…well it’s not very nice!

So, I finally took the big step, and migrated all the Exchange data off the DC, and uninstalled it. So now I have a seperate Exchange server, which means tons more RAM free on the DC.

This also allowed me to install something I’ve been looking at for quite some time now - WSUS 3. I now realise how useful this piece of software can be. I am only managing about 5 computers, plus a few servers, but this makes keeping the machines up-to-date so much easier. Plus, you get lovely graphs like this:

Also worth mentioning, is that the Exchange server I’ve been telling you about actually runs as a virtual machine under VMware on the DC. It has 2GB of RAM, and seems to be coping fine, but with 1GB assigned to the Exchange VM, and 384mb assigned to another VM I have running on there (a web server), task manager seems to be having problems getting the memory details correct:

So we have 1GB + 384mb + whatever else is running on there (WSUS, DC, DHCP etc), and we end up with 1.0GB (or there abouts). Something’s not right. Alas, the server seems to be handling the load fine, and with a gig of RAM apparently free, I have space to expand in the future. Brilliant.

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!