Active Directory Basics

There are very few hard and fast rules when it comes to Active Directory (AD), the whole purpose of it is to be as flexible as possible.  However, when designing an AD structure there are a few things that you should bear in mind:

1. Keep it as simple as possible
2. Create multiple AD sites if required
3. Use multiple domain controllers and DNS servers
4. Ensure there are enough Global Catalogue servers
5. FSMO Roles
6. Restrict who can administer the structure and schema

So, what do these headings mean?  Below they are explained in a little more detail:

Keep it as simple as possible

Don't overcomplicate matters!  Keep your AD structure simple, and design it in such a way that it aids administration of the system.  Do not let "management" get involved in its structure, they nearly always want it to mimic the organisational structure of a company, and this is often the least useful way or organising things.

Design your AD structure based on the following two main uses of an Organisational Unit (OU):

• Configuring objects within an Organisational Unit
• Delegating control of objects within an Organisational Unit

In my experience, the latter is an often underutilised aspect of AD planning and design.

Create Multiple AD sites if required

Whilst attempting to not overcomplicate matters, do not sacrifice functionality for simplicity.  If a more complicated Active Directory structure is required, then by all means create one.  If your network has WAN links, then these should be separate sites.

Use multiple domain controllers and DNS servers

Whether your Domain Controllers and DNS Servers are physical or virtual, ensure that they are dedicated to their role.  Do not be tempted to use a file server as a Domain Controller for example.
Using servers that have multiple roles tend to cause problems if (or more likely when) a restore of one of the components is required.  It is possible to place DHCP and DNS on the Domain Controllers, and whilst such a set up works quite well, I would always advocate having multiple separate DNS Servers, since Active Directory depends on this service so heavily.

A further consideration for the virtual world: If you have multiple virtual Domain Controllers and DNS Servers, do NOT host them on the same physical server if this can avoided.  At the very least, spread them across multiple hosts, and if possible, place them in different locations.

Ensure there are enough Global Catalogue servers

Assuming you have multiple Domain Controllers (and why wouldn't you?), make multiple servers a Global Catalogue server.  More importantly, if you have multiple sites, ensure that there is a Global Catalogue server at EACH site, otherwise clients will have to go over the WAN link to look up information from the Global Catalogue.

FSMO Roles

As the saying goes: "In Active Directory, all domain controllers are equal, but some are more equal than others".  Domain Controllers that host "Flexible Single Master Operations" (FSMO) roles are vital to the running of Active Directory.  If you have multiple domain controllers, spread the FMSO roles out amongst them, and ensure that any domain controller that hosts a FSMO role is backed up regularly - but you were doing that already right?!

Restrict who can administer the Structure and Schema

Determining whether the whole Active Directory structure can be managed by a single person, a team of people, or deciding to break the structure down into components/areas that people manage, is the first step.  Decide who will manage what, and assign permissions that ONLY allows them to do what is required (Delegating control of objects within an Organisational Unit).

Whilst not something that appears overly common in organisations, it is possible to edit the Active Directory Schema itself (usually this is for the additional of fields).  This should absolutely be restricted to one or two people.

Flexible Single Master Operation (FSMO) Role Placement

It is not the goal of this article to explain the FSMO roles, rather just to provide information on where they should be located.

In Windows Server Active Directory, there are 5 FSMO roles which can be hosted on any Domain Controller.  Each role sits on just one DC, and theoretically you can have all five roles on one DC, or one role on five DCs, however neither of these scenarios is considered best practice.

In small organisations, where cost is an issue, it is common to find only a single domain controller.
There is nothing wrong with this, except from a redundancy point of view.  If the DC fails, there is no standby DC to take over, therefore all domain tasks stop (possibly even the ability to log on depending on how the security is configured) until the DC is recovered from a backup.  Note: In this scenario, it is imperative that the DC is backed up.

Microsoft Best Practice is to split the roles as follows:

Forest Wide Roles:
Schema Master
Domain Naming Master

Domain Wide Roles:
Relative ID (RID) Master
PDC Emulator
Infrastructure Master*

The PDC emulator and the RID master should be on the same DC, if possible.
The Schema Master and Domain Naming Master should also be on the same DC.

*Infrastructure Master

The Infrastructure Master (IM) role is an interesting one, since depending on the complexity of the set-up, it may not be needed at all. General guidance (for legacy NT 4.0 related reasons) is to place the IM role on a non-global catalog server.  However, there are two things to consider before choosing the location of this role:

1. Single Domain Forest:
   If a Forest has a single Active Directory domain, there are no phantoms.  As such, the Infrastructure Master has nothing to do, and can therefore be placed on any DC, regardless of whether or not it hosts the Global Catalog.
   
   
2. Multi-Domain Forest:
   a) If a Forest has multiple domains, but EVERY DC hosts the Global Catalog, there are no phantoms, and again the Infrastructure Master has nothing to do.
   
   b) If a Forest has multiple domains, and only SOME Of the DCs host the Global Catalog, then the Infrastructure Master MUST reside on a DC that does NOT host the Global Catalogue. 

In my experience, the vast majority of set-ups fall into category 1 or 2a, and therefore the Infrastructure Master can sit wherever you want.

If you are not sure on which DC each of the 5 FSMO roles currently reside, run the following command on any Domain Controller: NetDOM /query FSMO

Changing the Product Key on Windows Server

Occasionally, it may be necessary to change the product key on a server.  For example, if you have built the server using a development product key and now want to licence it properly with a customers licence.

Once you have licenced the server however, the option to enter a product key goes away, and there is no obvious way to get it back.  You could rebuild the server from scratch, but this seems overkill.

Alternatively:

• Open a command prompt and change working directory to system32 directory (or ensure the system32 directory is in the path)
• Type slmgr.vbs -ckms (this will remove any KMS entry)
• Type slmgr.vbs -upk (this will remove the current product key)
• Type slmgr.vbs -ipk <product key> (where <product-key> is the new product key you want to use, and is in the following format: xxxxx-xxxxx-xxxxx-xxxxx-xxxxx)
• Type slmgr.vbs -ato (for CORE servers.  This activates server, an Internet connection is required)
  Alternatively type slui which will open the usual activation GUI.

This process has been tested on Windows Server 2008, 2008 R2 and 2012 R2.