Figure 7.1 Adding the Active Directory role to your server
Active Directory, what a great concept. The word Active implies a kind of dynamic behavior, and the word Directory implies some sort of storing and searching tasks of a component. The phrase also describes what Active Directory is all about: a central place where you store and manage all your users and computers and the behavior of your Windows infrastructure. Active Directory has been around since Windows Server 2000 and has been extended through Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2. In today’s businesses, Active Directory plays a major role as a centralized identity and access solution.
Although Active Directory has been a very robust solution for some time, Microsoft has tuned and added some more features to make Windows Server 2012 Active Directory a more reliable, scalable, secure, and easier-to-manage solution.
However, just because Active Directory is very easy to set up and install, it does not mean you just can run DCPROMO and click Next, Next, and Finish. This will not work anymore, and there are considerations you need to make before, while, and after installing Active Directory. Otherwise, sooner or later you will end up with a misconfigured and malfunctioning system. In this chapter I would like to shed some light not only on the different aspects of installing and configuring Active Directory but also on managing and maintaining your Active Directory systems.
What probably interests most of you is what’s new in Active Directory 2012; in the following chapters you will learn how to install, configure, and maintain Active Directory 2012.
In this chapter, you will learn to:
In this chapter we are going to refer to Windows Server 2012 and Windows Server 2012 R2 just as Windows Server 2012. If there are any features available only in Windows Server 2012 R2, we will point them out specifically.
A good way to get started is to define the terms and definitions. Because Active Directory uses many specific words, we are going to explain the vocabulary that administrators need to know.
As you learned, a single-domain forest is the simplest Active Directory topology you can build. The general recommendation is to create an Active Directory domain if you have 10 or more users. You could also create a domain if you have fewer users because there is no limit in place; it’s just a matter of complexity and cost. The advantages are obvious:
You might wonder if you should stick with one domain or why you might want to add more than one domain to your infrastructure. Whenever possible, you should create just a single-domain forest because it is easier to set up and manage. There are a few situations where you might consider more than one domain. Since Windows Server 2012 Active Directory did not change in terms of design and is as it was in Windows Server 2008 R2, the following rules are still valid. You should use multiple domains in the following situations:
It is important to understand that the reasons for creating multiple domains are not that one domain is reaching its technical limits; the problem lies in the replication, which could lead to several problems in your infrastructure. We previously discussed that a single domain is the smallest forest you can create. Just as you can install multiple domains in one forest, you can also create multiple forests. Here are some reasons for creating multiple forests:
Keep in mind that the more Active Directory forests you build, the degree of complexity and the management effort increase rapidly to a level you might not expect.
The benefits of a single domain are obvious:
Windows Server 2008 introduced fine-grained password policies. This solved a long-term problem that forced you also to create a separate domain. Fine-grained password policies allow you create multiple password policies. In earlier versions of Active Directory there could be only one password policy. In Windows Server 2012 fine-grained password policies are the same they were as in Windows Server 2008, but it offers a user-friendly interface to easily manage and control them.
You might have realized that there were no changes in the Active Directory basics. Since we have now covered most of the terms and definitions, we are now going to build a single-domain forest. But before we start to build a new domain, there are several points to be aware of and clarify:
In the next few pages we will discuss each of these considerations.
Once you’ve installed Windows Server 2012 Standard edition, you need to configure the server name and IP address. Just to clarify, we are using Windows Server 2012 Standard edition because the functionality is identical to the Windows Server 2012 Datacenter edition. The only difference is the licensing.
Before promoting a domain controller you need to assign the final computer name. What are good server names? I could write almost a separate book about naming servers, but there are few main things you should consider:
A common naming scheme for domain controllers is DC01, DC02, and so on. You can rename a domain controller using the GUI or Netdom tool.
Because clients and servers locate the domain controller using DNS and your domain controller has mainly the DNS role installed, you must always assign a static IP address. Otherwise, your domain controller becomes a moving target for other systems if they are trying to locate it. If you are configuring an IPv4 address only, it is best practice to leave IPv6 enabled.
Now you might think you’re ready to run DCPromo. Good idea, but what you will experience is a friendly message box letting you know that this does not work anymore.
If you need to install the domain controller server role, you need to start Server Manager, choose Manage, and then select Add Roles and Features (see Figure 7.1).
Figure 7.1 Adding the Active Directory role to your server
A wizard will start and let you choose which role or feature to install. In Windows Server 2008 R2, there were two separate wizards to install a role or a feature. The Add Roles and Features Wizard will install all binaries needed to run the Active Directory Domain Services Configuration Wizard (ADDSCW) afterward.
When the wizard has finished, you will need go back to Server Manager and click the yellow exclamation mark (see Figure 7.2).
Figure 7.2 Starting the installation wizard
This will give you the opportunity to promote the server to a domain controller (see Figure 7.3). The next steps are very similar to the DCPromo utility you were used to in Windows Server 2008 R2.
Figure 7.3 Promoting the server
The wizard will give you several options; you need to either select or type in the appropriate information. Depending on the options you select, the wizard changes the dialog accordingly.
The deployment configuration option allows you to identify whether you’re creating a new domain in a new forest or adding it to an existing forest. If you’re adding it to an existing forest, you can add another domain controller to an existing domain (which is covered later in this chapter) or create a new domain.
For the first DC, your choice is simple. You’ll be creating a new domain in a new forest.
In Windows Server 2012 Microsoft introduces the Resilient File System (ReFS). This file system is, as its name says, more resilient than NTFS. It provides higher integrity and scalability, and it also has proactive error identification built in. You may be tempted to choose this file system for all your upcoming server projects because of its qualities, but sadly there are limitations you need to be aware of:
As an Active Directory administrator, you need to know these best practices:
If you try to select an ReFS formatted disk for the SYSVOL, the Active Directory database, or a log file, you will receive an error saying that you need to select an NTFS-formatted drive.
Because this is the first domain controller, you will choose to add a new forest. Thus, you will also need to install DNS and the global catalog. Both DNS and GC are required for the first domain controller in your new forest. It is not possible to install a read-only domain controller (RODC) as the first domain controller; you cannot select this option.
Giving a name to a new root domain is probably the most difficult part. If you’re setting up a lab domain controller, you needn’t care about the name. But the situation is different if you have to build a domain or forest in a productive environment. Because the NetBIOS name of the domain will appear somewhere on the client side, management may not like seeing that name on their desktop when they log in. We highly recommend discussing and getting a commitment from the responsible manager when choosing the domain name.
What should a domain name look like? As you know, a valid Active Directory root domain name looks like a fully qualified domain name (FQDN). There are two parts: the actual name and a suffix, such as bigfirm.com, mydomain.local, or forest.com. These are all valid domain names. In Windows Server 2003 you could choose a single-label domain name like bigfirm, mydomain, or forest, and it would be supported by Microsoft. But as applications, such as Exchange evolved and depended on Active Directory and DNS, you were no longer allowed to create single-label domains. If you try to create a single-label domain in Windows Server 2012, you will get an error.
For the second part of a top-level domain you could use a suffix such as .com, .gov, .ch, or .net, or perhaps you might prefer some other suffix, such as .local or .domain.
The advantages of having the same name for Active Directory and the public DNS name, such as bigfirm.com, are these:
One big disadvantage is that it isn’t easy to distinguish from a firewall perspective between internal and external zones. Many administrators specifically try to avoid using Internet top-level domain names to avoid confusion with their internal networks.
As you can see, there are advantages and disadvantages to each of these options. We cannot recommend one naming convention in general. In the end the name has to fit your technical requirements and also meet your company’s security policy.
It is essential to know that Active Directory heavily depends on DNS. No DNS, no Active Directory. Why? Active Directory registers all kinds of service (SRV) records in DNS to locate specific services that are needed for Active Directory to function correctly. I guess that 80 percent of problems of a nonfunctioning Active Directory are related to DNS.
When you installed your domain controller, a warning appeared that a delegation for the DNS could not be created. This is because the Active Directory wizard configures DNS for you; it also tries to create a delegation for the DNS server, but there is no DNS installed. Confirm the dialog and continue.
During the Active Directory setup wizard you are prompted to select the domain functional level. The domain functional level depends on the operating system you are using for your domain controller. You cannot select a higher domain functional level than the one your oldest version of the operating system has.
The following domain functional levels are available in Windows Server 2012.
The minimum level required to join a Windows Server 2012 domain controller to another domain is forest functional level 2003. That means no operating system older than Windows Server 2003 is valid. There is no way to install a domain controller into a forest with forest functional level 2000.
If you install a domain controller, you can choose any domain functional level including up to Windows Server 2012. Be aware that if you choose domain functional level Windows Server 2012, you will not be able to add domain controllers other than Windows Server 2012 domain controllers. Therefore, if you are joining a Windows Server 2012 domain controller to a Windows Server 2008 R2 domain functional level, you cannot raise the functional level to Windows Server 2012 if you have a Windows Server 2008 R2 domain controller.
Here are two important things to remember:
This is like adding salt to soup. You can always add more salt, but if you put too much in, you can’t take it back out. If you are unsure, it is better to first choose a lower functional level like Windows Server 2008.
When you run the Active Directory Domain Services Configuration Wizard, you can select the domain functional level (see Figure 7.4).
Figure 7.4 Active Directory Domain Services Configuration Wizard
In earlier versions of Windows Server, the features available in your domain forest depended on your Active Directory functional levels.
Windows Server 2003 domain functional level
Windows Server 2008 domain functional level
Windows Server 2008 R2 domain functional level
In Windows Server 2012 domain functional level
For a detailed list of the features available in each functional level, see this URL:
The forest functional level identifies the capabilities within the forest. The domain functional level depends on the operating system of the domain controllers. The forest functional level depends on the domain functional level of the domain. You cannot raise a forest functional level higher than the lowest domain functional level in the forest.
You can also select the forest functional level during the Active Directory installation. The following forest functional levels are supported:
As with the domain functional level, you can raise the forest functional level after the DC has been promoted. You first raise the domain functional level of each domain in the forest to the same functional level, and then you raise the forest functional level to the same level. Remember that all domain functional levels must be on the same level before you can raise the forest functional level (see Figure 7.5).
Figure 7.5 Selecting the forest functional level in the Active Directory wizard
Just as the different domain functional levels add features to your domain, the different forest functional levels also provide various features.
The Active Directory Domain Services Configuration Wizard prompts you for the location of various Active Directory files and the location of the SYSVOL shared folder.
The SYSVOL shared folder is used to share information, such as scripts and elements of Group Policy objects between domain controllers. SYSVOL and the Active Directory database and log files must be placed on an NTFS formatted drive. The database and log files can be located on different drives, but those also must be formatted as NTFS (see Figure 7.6).
Figure 7.6 File paths
Windows Server 2012 introduces the new Resilient File System. ReFS offers higher integrity and scalability, and it has proactive error identification built in. You might think that it would be a perfect place for an Active Directory component, but as discussed earlier, this is not supported. Nor can you place the Active Directory database, Active Directory log file, or SYSVOL directory on ReFS.
At its core, Active Directory is a large database, and databases have a primary data file and a transaction log file. Changes to the database are first written to the transaction log file, and then periodically the transaction log file is check-pointed—that’s just a fancy way of saying that changes in the transaction log are committed to the database.
The transaction log provides significant fault tolerance and recovery capabilities to the Active Directory database. If the server loses power in the middle of any change, Active Directory can use the log to ensure that the database is in a consistent state when the server is rebooted. Any changes recorded in the log are committed to the database, and any unfinished changes recorded in the log are ignored.
From a performance perspective, it is possible to increase the performance of your DC by moving the database and transaction log files to different drives. For optimal disk performance of Active Directory, you may use a configuration similar to this:
In this configuration, each of the drives needs to be a separate spindle (a separate physical disk). A single drive with three partitions wouldn’t provide any performance gain. Additionally, if your disk drives have different speeds, you should put the operating system on the fastest disk, the transaction log on the next fastest, and the Active Directory database file and SYSVOL on the slowest disk. The operating system and the transaction log file will receive the heaviest usage.
To optimize your domain controller just a bit more, you can distinguish between heavy read and heavy write operations. If you have heavy read operations, you should add sufficient memory to the domain controller so that it can cache the database in memory. For heavy write operations, you can improve performance by adding the following:
This sounds good and makes sense, but what will happen if you virtualize your domain controller? In this case it’s a good idea to add sufficient memory for your domain controller so that it can cache the database. If you are going to place the transaction log, database, and SYSVOL on different virtual disks, the performance improvement will probably be minimal. The problem is that all the virtual disks are on the same LUN, and this LUN is spread over an array of disks. That means that all virtual disks share the same physical disks in the storage. From a theoretical standpoint, it would be best to place each file on a separate array or LUN. In any case, you should use the fastest storage you have.
For a good starting point to figure out if you have a disk performance problem, you can use these performance counters. Each of these counters should have a low value:
Let’s look at an example. If your domain includes 100 users, you can store the database and log files on the C drive with the operating system and not notice any performance problems. On the other hand, if you are supporting 50,000 users, you may want to squeeze every ounce of performance out of the server, so you will locate the database and log files on different drives. If you are building a test system, there is nothing wrong with leaving everything on C.
If you ever need to perform maintenance or restoration of Active Directory, you would use Directory Services Restore Mode. You can access DSRM by pressing F8 to access the Advanced Options menu. You can also access the different Safe Mode options from this menu.
After selecting Directory Services Restore Mode, you will be prompted to log on. However, Active Directory will not be running, so you can’t use an Active Directory account. Instead, you will use a special administrator account with a different password. The Active Directory Domain Services Configuration Wizard prompts you to set the password for the DSRM account, as shown in Figure 7.7.
Figure 7.7 Setting the Directory Services Restore Mode password
Make sure you document the password you set here. Many organizations document critical passwords by writing them down and storing them in a safe. You won’t be able to access DSRM without this password. The DSRM administrator account password is sometimes confused with the regular administrator password you set for the Domain Admins account, but it is different. From a security standpoint, this DSRM password is critical in that you can locally log onto a domain controller and use it to gain access to the Active Directory database. If you realize that all passwords are stored in this database, you will think twice about where you store the DSRM password.
http://technet.microsoft.com/en-us/library/cc753343.aspx.NTDSUtil
Set dsrm password
SYNC FROM DOMAIN ACCOUNT DSRMAccount
Q
Q
"SET DSRM PASSWORD" "SYNC FROM DOMAIN ACCOUNT DSRMAccount" Q QNow that you know what you will encounter, the next step is to add the Active Directory role and then run the Active Directory Domain Services Configuration Wizard. In Windows Server 2012 adding the Active Directory role basically adds all the necessary binaries and then you can configure Active Directory.
The following steps assume you have a clean installation of Windows Server 2012 without any additional roles installed. If you have installed additional roles, you may have some minor differences.
Add Roles and Features.Figure 7.8 Selecting the server
Figure 7.9 Add a new forest
Figure 7.10 “View script” option
Figure 7.11 PowerShell commands generated by the wizard
-SafeModeAdministratorPassword (ConvertTo-SecureString "P@ssw0rd" –AsPlainText –Force)`That’s it. You have created a single-domain forest. Your next logical step is to create a second DC.
Figure 7.12 shows the screen when you promote a Windows Server 2012 domain controller using PowerShell, as described in step 17.
Figure 7.12 Installing a domain controller using PowerShell
Whenever possible, you should have a second DC in place. A second DC will make routine and disaster recovery much simpler. A single domain controller is at significant risk of being a single point of failure. If it goes down, your entire network can go down, and you will find yourself in crisis mode. In Windows Server 2012 nothing has changed in this respect.
If you have a second DC and either the first or second DC fails, the network will continue to hum along. User will still be able to log onto the domain, and they won’t experience any interruption in their work, group policies will still be applied, and normal administration of the domain can still be done. You will still have work to do, but it won’t be a crisis. Additionally, restoring a failed DC is much simpler if another DC is still running in the domain. You can even create a new DC from scratch without a backup if it comes to that. If your last DC in the domain fails, you will need a recent backup of Active Directory, and you will have a significant amount of work to do to restore the domain. Besides that, you will have several nervous managers hovering over your shoulder frequently asking things like, “How much longer?” or, “Do you need any help?”
Just as you ran the Active Directory Domain Services Configuration Wizard to create the first DC, you will run this wizard to create the second. An account with Domain Admins permission is required to add a domain controller. You will also need to consider the following choices:
Install the Active Directory Domain Services role onto a fresh Windows Server 2012 by running the Add Roles and Features Wizard. Next, you need to have a static IP address assigned to your second DC. The DNS IP address points to the first DC so the server can locate the domain.
You will need to access the TCP/IP properties for the NIC. The easiest way to access the network adapters is to follow these steps:
Figure 7.13 Configuring network settings
You don’t need to join the server to the domain prior to promoting it to a domain controller. The configuration wizard will automatically take the necessary steps and move the computer object into the Domain Controller container in Active Directory.
Since you already have a domain, you will have different choices to make with the deployment configuration. If you want to add a second DC, you will select “Add a domain controller to an existing domain,” as shown in Figure 7.14.
Figure 7.14 Adding a second domain controller
This would be the same selection for every new domain controller you wanted to add to the domain. If you needed to create a child domain, you would select “Add a new domain to an existing forest.”
Should you add DNS to the second DC? Yes!
If your first DC is running DNS (as recommended), then your second DC should also be running DNS. If you followed the steps for promoting the first DC, then it is running an Active Directory integrated (ADI) zone. By adding DNS to the second DC, you will add redundancy with very little overhead. You can also use the second DNS server for load balancing.
Remember, Active Directory depends on DNS. If there is no DNS available for your DC to locate SRV records to find domain controllers and necessary services, Active Directory will not function. It is essential for Active Directory to have a working DNS in place.
With two DNS servers you can configure servers and clients to use both DNS servers. It is recommended to add one preferred and one alternate server for the computers in your network. These computers will only query the alternate DNS server if the preferred DNS server does not respond to queries.
One-half of your computers should use DNS server 1 as the preferred DNS server, and the other half of the computers should be configured to use DNS server 2 as preferred DNS server.
If you have dynamically assigned IP addresses and options, you can configure half of the DHCP client scopes to deploy DNS server 1 as the preferred DNS server and the other half of the DHCP client scopes to deploy DNS server 2 as preferred DNS server.
One very important step to remember is that after you promote your domain controller, you need to reconfigure the DNS network settings. Make sure you set the domain controller’s primary DNS to its own IP address. It is best practice that domain controllers always point to themselves first if DNS is installed on the server.
Should the second DC be a global catalog server? Yes!
In this chapter, you are creating only a single-domain forest. In a single-domain forest, you should always make all of your domain controllers global catalog servers. There is no additional cost involved and doing so ensures that the DC provides full functionality if the other DC fails.
You can follow these steps to promote a second server to a domain controller. In these steps, the server is not a member of the domain. If you have joined your server to the domain, you might see minor differences.
Add-WindowsFeature AD-Domain-Services,RSAT-AD-AdminCenter,RSAT-ADDS-Tools,GPMCFigure 7.15 Adding DNS and GC to the second DC
Once you have created your domain, you will want to create your OUs, user accounts, computer accounts, groups, and so on. There are two tools to choose from: either you stay with the legacy Active Directory Users and Computers (ADUC) tool or you choose to work with the Active Directory Administrative Center (ADAC). Microsoft will push upcoming new features and management tasks to the ADAC, so it makes sense to start using this new console.
Both tools allow you to create everything with point-and-click ease. However, you can also run the tasks from the command line, preferably with PowerShell. This is very handy in a couple of situations:
Organizational units are used to organize objects within Active Directory. Any object (such as users, computers, groups, and so on) can be placed within an OU to make them easier to administer. The two primary technical reasons why you will create an OU are these:
Group Policy objects (GPOs) can be created and linked to sites, domains, and OUs. If you want some users to have a specific group policy assigned to them, you can create an OU, place the accounts within the OU, and link the GPO to the OUs.
However, if you haven’t created any OUs, one way GPOs can be assigned to regular accounts is through the Default Domain Policy that is applied to all users and computers equally. Imagine that you wanted to deploy an application to all users in the sales department using Group Policy. If you link your GPO to the domain, all users in the entire company would get the application, not just the users in the sales department.
Instead, you would create an OU (let’s call it Sales), move the sales department user and computer accounts into this OU, and then link the GPO to the Sales OU. If you had other groups or users that you wanted to apply specific Group Policy objects to, you would create an OU for them and place their user and computer objects within that OU.
Another way of applying GPOs to some users or computer objects is to create an Active Directory security group and add into the group all your users who need to get the policy settings applied. After you have your group created and provisioned, you could add this group to the GPO’s Security Filtering section and remove the default Authenticated Users group from the Security Filtering settings. For detailed steps read Chapter 9, “Group Policy: AD’s Gauntlet and Active Directory Delegation.” It will show you how to accomplish this and more.
Windows Server 2008 R2 already had an Active Directory Administrative Center built-in, but it was a challenge to create objects if you were used to the Active Directory Users and Computers console. In Windows Server 2012, Microsoft brings a more evolved Active Directory Administrative Center. It is redesigned and fully based on PowerShell. Because of that you can always copy the latest commands from the Windows PowerShell History windows, modify the commands, and build your own script to accomplish the task faster.
However, the Active Directory Users and Computers MMC is still available and works with Windows Server 2012, and it has the same functionality as Windows Server 2008 R2.
To create an OU using Active Directory Administrative Center, follow these steps:
Organizational Unit.Figure 7.16 Creating an OU named Sales
Organizational Unit.Figure 7.17 OUs in Active Directory Administrative Center
You may notice that you have two Users objects within Active Directory, but they are very different. The Users OU within the Sales OU is an OU and can have GPOs linked to it. The Users container under the domain is only a container (not an OU) and cannot have GPOs linked to it. OUs have slightly different icons to identify them—it is not just a folder but instead a folder with an icon embedded on the front of the folder reminding you that it is something more.
Active Directory uses the Lightweight Directory Access Protocol (LDAP) for communication. LDAP uses a distinguished name (DN) to uniquely identify each object within the directory. Before looking at how to create objects from the command line or scripts, you should understand the components of a DN.
The format of a DN uses objectType=objectName with several object types separated by commas. For example, a domain named bigfirm.com has two domain components (bigfirm and com) that are identified this way:
dc=bigfirm, dc=com.Organizational units have an object type of OU, and the Users and Computers containers are identified with cn (for “common name”). The Sales OU would have this DN:
ou=Sales,dc=bigfirm,dc=comThe Users container would have this DN:
cn=Users,dc=bigfirm,dc=comA container is an Active Directory object that is created within Active Directory when you promote a server to a domain controller. This object contains default users and groups for Active Directory and also entirely different attributes than an OU. One other big difference is that you cannot apply group policies to this container.
An account with a name of Sally.Smith located in the Sales OU would have this DN:
cn=Sally.Smith,ou=Sales,dc=bigfirm,dc=comAn account with a name of Joe.Johnson located in the Users container would have this DN:
cn=Joe.Johnson,cn=Users,dc=bigfirm,dc=comIf OUs are nested, or have OUs within them, the lowest level OU comes first in the DN name. For example, if the Sales OU had a child OU named Users and then had a user named Maria within it, the DN would be as follows:
cn=Maria,ou=Users,ou=Sales,dc=bigfirm,dc=comIf the DN includes any spaces, it needs to be enclosed with quotes to ensure it is interpreted correctly. For example, this doesn’t require quotes because there are no spaces:
cn=Maria,ou=Users,ou=Sales,dc=bigfirm,dc=comHowever, the same DN with spaces must include quotes:
"cn=Maria,ou=Users,ou=Sales,dc=bigfirm,dc=com"LDAP DNs are not case sensitive. The following two DNs will be interpreted as the same object:
cn=Maria,ou=Users,ou=Sales,dc=bigfirm,dc=com
CN=Maria,OU=Users,OU=Sales,DC=bigfirm,DC=comPowerShell has been around for a few years, and it is becoming more important to know what PowerShell is all about. In Windows Server 2008 R2, PowerShell 2.0 was built in and already had good support for several features and roles. Because PowerShell is object oriented it has a solid, well-designed architecture. Microsoft pushes PowerShell extensively so you can use it to control almost anything in Windows Server 2012.
In Windows Server 2012, PowerShell 3.0—or in Windows Server 2012 R2, PowerShell 4.0—is built in with tons of new commands for more easily controlling your server. Exploring all these new features would require several books on the subject. Here we’ll just continue with our example to give you a feel for what it’s all about. If you don’t know which command-line tool to use, such as DSAdd, Windows Script Host (WSH), or PowerShell, then learn PowerShell—it is the present and future technology.
If you installed your second domain controller according to our step-by-step guide, you should have already the Active Directory PowerShell commands available. Verify that you have the AD DS Snap-Ins and Command-Line Tools installed. You can find out if you start the Add Roles and Features Wizard and click Next until you reach the page where you select the features. It should look similar to the one shown in Figure 7.18.
Figure 7.18 Adding a PowerShell cmdlet
In Windows Server 2012 click the PowerShell icon on the taskbar; this will launch the PowerShell command window showing the prompt PS C:\Users\administrator>. In the next section you will learn how to use PowerShell to create an OU named PS_OU.
PowerShell has a large set of commands available that basically need only some additional parameters to do their work. These commands are referred to as cmdlets and are the work horses in PowerShell. If you have certain roles installed in Active Directory, new cmdlets are available, but in order to get them to work you need first to import these cmdlets into your PowerShell session. Most of the time new cmdlets come in a type of module, and you need to load these modules to have the new functionalities available.
You do this by typing:
Import-Module ActiveDirectoryThis will take a moment and you will be prompted again. Next, type the command to create an OU named PS_OU.
New-ADOrganizationalUnit –Name PS_OU –Server DC02.bigfirm.com –Path "DC=bigfirm,DC=com"You may need to modify the server name DC02.bigfirm.com and the domain component "DC=bigfirm,DC=com" to match your domain controller and your domain name. If it doesn’t work and you get an error, check first to see if you have any typos. PowerShell is in general case insensitive. This means it doesn’t matter whether you write the command in uppercase or lowercase; it will work either way.
In PowerShell 3.0 it’s no longer necessary to import the module first by typing Import-Module ActiveDirectory as we did in the example. PowerShell 3.0 will recognize the New-ADOrganizationalUnit cmdlet and import the appropriate module. If the module has already been imported, PowerShell will skip this step and not import the module again.
The first New-ADOrganizationalUnit cmdlet consists of a verb and a noun separated by a dash (-). This is a basic design principal in PowerShell to make cmdlets easy to remember. For example, if you want to get an OU, you could type Get-ADOrganizationalUnit, or to remove an OU you could type Remove-ADOrganizationalUnit.
We provided several parameters for the New-ADOrganizationalUnit cmdlet, so let’s have a brief look at these. The -Name parameter specifies the name of the OU; notice that there is a space between Name and the PS_OU name. –Server specifies the domain controller where you want to create the OU, and –Path specifies the placement of the new OU. There are many more parameters you could provide. To see all the options type Get-Help New-ADOrganzationalUnit or just help New-ADOrganzationalUnit.
You might be wondering if there is a way to create a script to speed things up. It might not make much sense in our example to create a script, because it’s just one line of code. But we’ve not even touched on the tip of the iceberg; what if you wanted to create 10 OUs at a time, for example, PS_OU1, PS_OU2, and so on, and delete those OUs and re-create them? I think it’s worth creating a script for that.
In Windows Server 2012 you get an integrated scripting environment for developing and running PowerShell scripts right out of the box. This tool is called Windows PowerShell ISE. ISE stands for Integrated Scripting Environment. It is a script editor that helps you build scripts faster and also allows you to run the scripts right from your console. Windows PowerShell ISE has some great features like Intellisense, which helps you find the right cmdlet and provides a command section with detailed information about the cmdlets. There is much more to explore; here we will just briefly touch on the experience of writing a script in the Windows PowerShell ISE. You can create and execute a PowerShell script by following these steps:
Figure 7.19 Running PowerShell in PowerShell ISE
Import-Module ActiveDirectory
ForEach ($i in 1..10) {
New-ADOrganizationalUnit –Name "PS_OU$i" –Server DC01.bigfirm.com `
–Path "DC=bigfirm,DC=com"
}Set-ExecutionPolicy RemoteSignedIf all goes well, you can launch Active Directory Administrative Center and view your new OUs. If there are errors, review the script. It is common for errors to occur the first time you type the script, especially if they are several lines long.
Once you have created some OUs, you will want to create some accounts. Both users and computers need accounts in order to access the domain. Just as with OUs, you can use either Active Directory Users and Computers, Active Directory Administrative Center, DSAdd, or PowerShell to create the accounts.
The creation of computer accounts is often automated. When a computer joins the domain, a computer account is automatically created. By default, the account is created in the Computers container, but you can modify this using the redircmp command-line tool. The syntax is as follows:
Redircmp DNFor example, if a user joined a computer to a domain and you wanted the computer account to be created in the Sales OU, you would enter the following command:
Redircmp "OU=Sales,DC=bigfirm,DC=com"If you need to set it back to the default setting, type:
Redircmp "CN=Computers,DC=bigfirm,DC=com"Don’t forget to adjust the domain controller (DC=xxx) settings according to your environment.
To create a user account using Active Directory Administrative Center, follow these steps:
User.Figure 7.20 Creating a user in ADAC
Before PowerShell was born, we used a tool called DSAdd to create users and other Active Directory objects. It was a great tool back then, but today it’s considered it a legacy tool that’s still around and works great. It might be a step into batch scripting and offers a first touch into the automated command-line world. But the only way to get serious about automating and making life easier is to use PowerShell.
Just as you used PowerShell to create OUs, you can also create user accounts. You will be surprised to learn that the basic cmdlet doesn’t differ much from the DSAdd command. The cmdlet you need is the following:
New-ADUser -Path "OU=Sales,DC=bigfirm,DC=com" -AccountPassword (ConvertTo-SecureString P@ssword -AsPlainText -force) -Name "Maria Smith" -Givenname Maria -Surname Smith `-DisplayName "Maria Smith" -SamAccountName "Maria.Smith" `-UserPrincipalName "Maria.Smith@bigfirm.com" -ChangePasswordAtLogon 1 -Enabled 1This PowerShell example and DSAdd both create a user named Maria Smith with the exact same parameters. You might think that, the PowerShell command has more code than the DSAdd command in the previous example. Now you are probably wondering what the advantage is if you have to type more to achieve the same thing. The strength of PowerShell lies in its fully object-oriented approach with all its bells and whistles.
Notice in the example that we could not just specify a password in string format; we needed to convert this string into a SecureString first and then submit this to the –AccountPassword parameter. The -ChangePasswordAtLogon and -Enabled parameters need an input value of type Boolean. Boolean means either 0 (= false) or 1 (= true). Review the rest of the command and you will see that it is self-explanatory.
You may also want to create some groups. The most common reason to create groups is to organize users. More specifically, global security groups are created to organize users and then assign permissions to the groups. Whenever possible, you should assign permissions to groups rather than users. You may have heard the old saying “Users come and go, but groups stay forever.” Well, maybe you haven’t heard it before since we just made it up, but it makes sense, and it is a good way to remember that you always assign permissions to groups instead of users.
As an example, you could have several users in the sales department. Instead of assigning permissions to each individual in the sales department, you could create a single global security group name G_Sales. Place all the users in the sales department into this group and assign permissions to the G_Sales group. If a user leaves, take him out of the G_Sales group and he will no longer have the permissions of the group. If a user joins the sales team, put her into the G_Sales group, and she will have the same permissions as everyone else in the group.
That sounds pretty easy, but there is not just one type of group; there are several types and each of them has its own purpose. The two types of groups are distribution and security. Distribution groups are used for email, and security groups are used to assign permissions. Security groups can also be used for email.
There are three group scopes:
The most common way to create these groups is with Active Directory Users and Computers or with Active Directory Administrative Center. You can use the following steps to create a global security group:
Group.Figure 7.21 Creating a group using Active Directory Administrative Center
Group. Then enter G_SalesAdmins in the “Group name” box. Click OK.Your G_SalesAdmins group is created, and now you could use this group to assign permissions, for example, delegating control to an OU as described in the upcoming section.
In the previous examples you created OUs and users using PowerShell. We showed you the command you needed to create the object. But what if you don’t know the command or you could use some help? If you followed the steps for creating the groups using the Active Directory Administrative Center, then you already have everything in front of you:
Figure 7.22 Viewing PowerShell History
New-ADGroup –GroupCategory:"Security" –GroupScope:"Global" –Name:"G_SalesPowerUsers" ` –Path:"OU=Sales,DC=bigfirm,DC=com" –SamAccountName:"G_SalesPowerUsers" `–Server:"DC02.bigfirm.com"If you don’t receive any errors, you will have just created another global group.
You just saw in Figure 7.22 how tasks previously executed in Active Directory Administrative Center are translated into PowerShell and displayed in Windows PowerShell History. Because ADAC is on top of PowerShell, everything will be shown in the PowerShell History as commands. Windows Server 2012 Active Directory has now more than 140 PowerShell cmdlets, and it would take a lot of time to learn the commands and the specific syntax. Therefore we recommend that you keep an eye on this window because it will help you in learning these commands.
At the top of the PowerShell History window are several fields:
Earlier in this chapter, I mentioned that one of the reasons for creating an OU was to delegate control, and certainly one of AD’s strengths is that it can let you grant partial or complete administrative powers to a group of users. This means that it would be possible for a one-domain network to be subdivided into, say, Uptown and Downtown, or Marketing, Engineering, and Management, or whatever. Probably the most common requirement or reason to delegate control to an OU is to give helpdesk people permission to reset user passwords. Another quite often requested permission is to be able to modify only certain attributes of users or group objects. Of course there are many other requirements you will be facing during your Active Directory administration career. Even if you’re not terribly interested in delegation, Chapter 9 gives you a very good head start on delegating control in Active Directory.
After you have established your domain, you will need to do some domain maintenance. Although this section doesn’t cover everything you will need to do, it does cover some basic tasks:
Follow these steps to join a Windows Server 2012 to a domain. Once the server is joined to a domain, it is referred to as a member server.
Figure 7.23 System currently in a workgroup
Figure 7.24 System joining a domain
After the server has rebooted, it will be a member of the domain—a member server.
If it’s ever necessary to take one of the domain controllers out of service, it is imperative that you properly decommission it. When you decommission it, you remove all Active Directory components and return the domain controller to a member server role.
Properly decommissioning the DC is especially important if you need to take the first DC out of service. The first DC in the domain includes several Operations Master roles, sometimes called FSMO roles, that are integral to the proper operation of the domain. If this server simply fails and you are never able to bring it back up, you are going to have some problems until you properly decommission it.
The easiest method of decommissioning a DC is to simply run the PowerShell cmdlet Uninstall-ADDSDomainController. In Windows Server 2008 R2, you were able to run DCPromo to demote a domain controller, but at this Windows Server 2012 version DCPromo is gone. The tasks this cmdlet will perform are very similar to the DCPromo in the past Windows versions. If the domain controller you are running this cmdlet on is still operational and holds all the FMSO roles, it will transfer the roles to a new domain controller, demote the domain controller, move the computer object from the Domain Controllers OU into the Computers container, and take care of several other details. The DNS server role will be still installed and running, but if your DNS zones were Active Directory integrated (ADI), they are no longer available.
If this server just fails and you are not able to run Uninstall-ADDSDomainController, you will need to remove all the dependencies from the domain, like DNS SRV records that pointed to this domain controller and other deeply hidden traces in Active Directory from this domain controller. In previous Windows versions, it was a rather lengthy and tedious process using NTDSUtil and some manual work. However, if you are using the Active Directory Users and Computers snap-in available in Windows Server 2012, you can simply delete the domain controller object in the Domain Controllers OU, and you are finished.
For anyone who has gone through the lengthy metadata process using NTDSUtil and other tools, this is a great addition:
Figure 7.25 Deleting a domain controller
If the failed DC is later recovered, you won’t be able to remove Active Directory using Uninstall-ADDSDomainController. However, there is a work-around. Instead of just entering Uninstall-ADDSDomainController alone, enter Uninstall-ADDSDomainController –ForceRemoval. The –ForceRemoval switch will allow Active Directory to be removed without accessing another DC in the domain. There are other options available with this cmdlet that you can explore by typing Get-Help Uninstall-ADDSDomainController. For example, the –Force switch will suppress any upcoming warnings, which can be useful if you want to use it in a script, or –DemoteOperationMasterRole, which will force a demotion of the Active Directory even an Operations Master role is discovered. Of course, you can combine all these parameters to remove Active Directory from your orphaned domain controller.
A common problem that occurs with DNS is that SRV records aren’t created when the server is rebooted. The netlogon service is responsible for creating these records, and sometimes it just seems to hiccup after rebooting the server.
As a reminder, the SRV records are used to locate domain controllers in a domain running specific services or holding specific roles within a domain. As a few examples, services within the domain often need to locate a global catalog server, a PDC emulator, a domain controller within a specific site, or simply a domain controller in the domain. Services query DNS for the appropriate SRV records, and as long as they exist, the server can be located. However, occasionally these records aren’t created after a reboot. Figure 7.26 shows the DNS Manager console open to show that the records have been correctly created. Notice that there are several folders starting with an underscore (_msdcs, _sites, _tcp, and _udp). Each of these folders includes SRV records.
Figure 7.26 DNS service records (SRV)
If you are experiencing connectivity problems and you notice that DNS is missing these records, there is a simple fix. Go to command prompt and issue the following two commands:
Net stop netlogon
Net start netlogonThe netlogon service will re-create the records, and you will be back in business.
You may want to raise your domain and/or forest functional levels after you have initially created your forest or after upgrading from a Windows Server 2008 environment. The primary reason why you would want to do so is to take advantage of additional features available at the higher levels. Although Window Server 2012 forest functional levels don’t offer any new features, you might still want to raise the domain functional level to Windows Server 2012. Anyhow, the big-picture steps you would take are as follows:
It is important to remember that once you raise the level, there is no turning back. If your current domain functional level is Windows Server 2008 R2 and you raise it to Windows Server 2012, you will no longer be able to promote anything less than a Windows Server 2012 server to a domain controller. If that fits in your plans, raise the levels.
Set-ADForestMode –Identity "bigfirm.com" –ForestMode Windows2008R2ForestSet-ADDomainMode –Identity "bigfirm.com" –DomainMode Windows2008R2DomainThere are four tools you could use to raise the domain forest levels:
Depending on your version, choose whichever method is appropriate for you. Because the Active Directory Administrative Center is new, we will now have a look at this console and how to raise the domain forest level there.
You can raise the domain functional level by following these steps:
Figure 7.27 Raising functional levels in Active Directory Administrative Center
You can raise the forest functional level the same way you raised the domain functional level:
Many of the additional features of the higher functional levels will be available automatically. Only a few (such as the Active Directory Recycle Bin) require additional steps to enable them.
Set-ADDomainMode –Identity "bigfirm.com" –DomainMode Windows2012DomainSet-ADForestMode –Identity "bigfirm.com" –ForestMode Windows2012ForestA valuable command-line tool is Netdom (short for “domain manager”). It is available at the command prompt on any server that has been promoted to a domain controller. Although Netdom is primarily used to manage trusts in environments with more than one domain, it also has several other uses.
You can use the netdom computername command to safely rename domain controllers and member servers. In early versions of Windows, renaming a domain controller wasn’t possible unless you first demoted it. Be aware that even if you use Netdom to rename a domain controller, it may take a couple of reboots before everything settles—especially in DNS. More important, you should not rename servers that are certificate servers (those running Active Directory Certificate Services). A certificate server needs to keep the same name. The name embedded in a certificate identifies the server it is issued to and the server that issued the certificate. Certificates are validated by querying the original server, but if the name is changed, none of the certificates can be validated.
Renaming a DC involves giving it an alternate name and changing the alternate name to the DC’s primary name. For example, if you have a domain controller named DC01 in the domain bigfirm.com but you want to rename it to DC03, you first give it an alternate name of DC03 with the following command:
Netdom computername DC01 /add:DC03.bigfirm.comAt this point, the server has two names: its primary name and an alternate name. Next, rename the computer to the alternate name with this command:
Netdom computername DC01 /makeprimary:DC03.bigfirm.comNetdom will indicate success and prompt you to reboot the server. With the reboot, your domain controller will change the alternate name to its primary name.
As a last step you need to remove the old name DC01 from the domain controller computer object with this command:
Netdom computername DC03 /remove:DC01.bigfirm.comNow your domain controller has a new name.
If you want to join a computer to a domain from the command prompt or via a script, you can use Netdom. The simplest implementation is as follows:
Netdom join server01 /d:bigfirm.com /rebootThis command will join the computer named server01 to the domain bigfirm.com and force a reboot. Normally, the computer account for a computer that just joined the domain is placed into the Computers container. As mentioned previously, you can use the redircmp command to have computer accounts created somewhere else.
It is also possible to get fancier with Netdom, but it tends to be more difficult than using the directory service command-line tools (such as DSMove). For example, if you want to move the computer account from the Computers container to the Sales OU, you could follow the NetDom Join command with the DSMove command.
Dsmove "CN=Server01,CN=Computers,DC=bigfirm,DC=com" –newparent "OU=Sales,DC=bigfirm,DC=com"Netdom is a very good tool to use to manage your domain, and there are certain tasks that only Netdom can fulfill. In terms of joining computers to the domain, PowerShell can help you if you need to add multiple computers to a domain or even if you need to remotely add workgroup computers to the domain. The basic command to add a Windows 2012 server named Server01 to the bigfirm.com domain is:
Add-Computer -ComputerName Server01 -LocalCredential Server01\Administrator -DomainName "bigfirm.com" –OUPath "OU=Sales,DC=bigfirm,DC=com"-Credential bigfirm\administrator -Restart –ForceYou can run this command from a Windows Server 2012 domain controller and remotely join Server01 to the domain. If you run this command, you will be prompted twice for a password; the first prompt is to set the local administrator password (-LocalCredential parameter) and the second prompt is the account that needs permission in the domain to create the computer account (-Credential parameter).
Netdom includes many other commands that can be used to manage your domain. Check out the full online reference for Netdom at http://technet.microsoft.com/en-us/library/cc772217.aspx.
These are some other commands that may be of interest to you:
The Kerberos authentication protocol used by Active Directory requires that all computers in the domain be synced with each other. If any computer becomes more than five minutes off from a domain controller, you will be able to connect to the network but all services might not work properly until the time is corrected.
Because of this, time synchronization is very important in a domain. Time synchronization is achieved through a hierarchy. It starts with the server holding the role of the PDC Operations Master (normally the first domain controller created in the domain) and extends to each system in a domain. You can check which server holds this role by following these steps:
Ideally, the domain controller hosting the PDC role is configured to synchronize with a valid Network Time Protocol (NTP) source. The rest of the computers in the domain will get their time from this server.
As long as the PDC has the correct time and users don’t change the time on their systems, everything works well.
You will use the Windows Time Service (w32tm) to check and synchronize the time. W32tm is executed from the command-line.
You can use the following command to check five samples of current time against Microsoft’s time server (at time.windows.com) and verify how accurate they are. The output will indicate whether the time on your server is ahead (indicated with a +) or behind (indicated with a -):
W32tm /stripchart /computer:time.windows.com /samples:5 /dataonlyYou can synchronize the time on the PDC Operations Master using an internal time source if you have one or an external time source if not. If you synchronize with an external NTP server using the w32tm service, you will need to ensure that UDP port 123 is open.
Use the following command to have your system synchronize its time with an external time server. Several time servers are available, but this example is using Microsoft’s time server (time.windows.com) and the NIST time server (time.nist.gov):
W32tm /config "/manualpeerlist:time.nist.gov,time.windows.com"/syncfromflags:manual /reliable:yes /updateThe syncfromflags parameter specifies that the server will synchronize with one of the servers in the manualpeerlist group. You can add just a single time server (and omit the quotes) or add multiple time servers separated by a comma, as shown.
It is also a good idea to restart the time service using the following commands:
Net start w32time
Net stop w32timeAfter you restart the service, you can use the earlier w32tm command to verify that the time is now accurate. If you change the time, it may take as long as five minutes before w32tm synchronizes again and resets the time to the proper time.
This section covered several maintenance tasks and techniques you will likely find useful to keep your network running. It is certainly not an all-encompassing list, but it should help you master some of the basics. A neat newer feature that can help you reduce the amount of maintenance you will need to do is fine-grained password policies. This feature allows you to set multiple password account lockout policies without creating a new domain.
Active Directory holds the Flexible Single Master Operations roles (FSMO), which are used for different tasks within the forest and domain. There are two forest-wide roles and three domain-wide roles. Table 7.1 lists the role name, the scope, and its purpose.
Table 7.1: FSMO roles
| FSMO Role | Scope | Purpose |
| Schema Master | Forest | Hold the forest’s schema |
| Domain Naming Master | Forest | Manage the domain names |
| Infrastructure Master | Domain | Ensure cross-domain object references |
| PDC Emulator | Domain | Responsible for the time in the forest |
| Handle password changes | ||
| Connection point for managing GPOs | ||
| Account lockouts | ||
| RID Master | Domain | Manage and replenish the RID pools |
In certain situations, for example, decommissioning a domain controller, upgrading the domain, or even for performance issues, you will need to move these roles to a new domain controller. Active Directory must have each of these roles available all the time. One way to migrate or move these roles to a new domain controller is using the NTDSUtil command.
To move the domain FSMO roles, follow these steps:
Of course, you would need to repeat these steps for each domain.
If you decide to move the forest-wide FSMO roles, follow these steps:
After you have moved all your FSMO roles to the new domain controller(s), you might want to check to see if everything is the way you expect. We suggest that you run the netdom query fsmo role command in the command prompt, which will show you which domain controller holds which FSMO role.
Before you can implement fine-grained password policies, you need to ensure that your environment meets the minimum requirements.
Only members of the Domain Admins group can create password-settings objects (PSOs).
In Windows Server 2012 you have a perfect GUI for creating the Password Settings objects. Under the hood nothing changed from Windows Server 2008 R2; the features are the same. However, it will be a great advantage to be able to manage the PSOs using the GUI, especially when it comes to typing time values as duration entries, because this was a big pain before.
You will create a PSO for the G_ITAdmins groups with the following steps:
Figure 7.29 ADAC Password Settings Container
Figure 7.30 Password Settings
You should see now in your Password Settings container in Active Directory Administrative Center a PSO called PSO_G_ITAdmins.
Now you need some kind of proof that this PSO works and what settings you have. In our previous examples we created a user named Sally Smith. Let’s assume that this user is an IT administrator, and therefore we are going to add Sally Smith into the G_ITAdmins group. Sally should now receive the new password settings; you can easily prove it by logging onto a server using the sally.smith account. Another way to see what kind of PSO rules are applied to a user is as follows:
Figure 7.31 View resultant password settings
It is important to know that you can link PSOs to other groups in addition to global security groups. However, when the Resultant Set of Policy (RSOP) for the user object is determined, only those PSOs are considered that are directly linked to the user object or the global security group that the user is member of. PSOs linked to distribution groups or other security groups are ignored.
In the previous example you configured several password settings that are set up similarly to those in the Default Domain Policy in your domain. There is one more setting to look at. In the PSO configuration dialog shown in Figure 7.30, you can configure the Precedence parameter. This identifies which PSO will take precedence, if multiple PSOs apply to a user.
Let’s take the G_ITAdmins group and apply two PSOs, one with precedence of 10 and one with precedence of 5. The PSO with precedence of 5 will win, because a lower precedence value is a higher precedence.
This makes sense if you are just using groups and apply the PSO to the group level. But what happens if you apply a PSO to the group G_ITAdmins (Sally Smith is still a member) and you apply a PSO directly to Sally Smith?
Let’s take the G_ITAdmins group again, where Sally Smith is a member, and apply a PSO with a precedence of 10. Create another PSO with a precedence of 15 and apply this PSO directly to the user Sally Smith. The PSO directly applied to Sally will win, although the precedence value is higher.
The way that the PSO applied is determined is as follows:
A PSO that is linked directly to the user object is the resultant PSO. If no PSO is linked to the user object, the global security group memberships of the user—and all PSOs that are applicable to the user based on those global group memberships—are compared. The PSO with the lowest precedence value is the resultant PSO.
The really cool thing about Active Directory back in the year 2000, and still cool today, is that Active Directory is a distributed database. It can have more than one domain controller that houses a writable copy of the directory database, thus eliminating the need for primary (writable) and secondary (nonwritable) servers. Inside each Active Directory domain controller were a couple of folders, which were public-facing shares, used to provide access and replication capabilities for the various domain controllers throughout the domain. The directory that stored and made these shares available was titled SYSVOL. It contains netlogon shares (logon scripts and Group Policy objects for client computers in the domain), user logon scripts, Windows Group Policy, File Replication Service staging, folders and files for synchronization, and file system junctions.
This section addresses the following topics:
Often when we consider something in the world of technology as old, there is a negative connotation associated with it. In this case, the old stuff simply makes reference to the way that something has been done in the past. In this particular case, the changes made to SYSVOL, in Windows Server 2008 R2 and also in Windows Server 2012, are encompassed in a new methodology for conducting replication of SYSVOL materials between replication partners throughout the domain.
The new way of using Distributed File System Replication (DFS-R) has some significant improvements over the old File Replication Service (FRS) method, but that doesn’t necessarily mean the old way is bad. In fact, all versions of Active Directory with the exception of Windows Server 2008 R2 and Windows Server 2012 use the “old” method. It is worth exploring and gaining an understanding of FRS because it is so prevalent on the networks to which you will add Windows Server 2012.
Before you start using the cool new features of DFS Replication, it is important that you understand FRS and its functionality so that you can easily migrate from FRS to DFS-R. But when do you need to upgrade? If you’re upgrading from Windows 2003 to a Windows Server 2012 domain or if you are upgrading a Windows 2008 (R2) domain that has not yet implemented DFS-R and you are going to upgrade to Windows Server 2012 domain. FRS replication uses something called file system junctions to maintain the integrity of the SYSVOL folder. You will want to understand the operation of FRS and some of the operations associated with FRS replication. Each domain controller that runs FRS contains the following shares and components of SYSVOL:
File system junctions are used extensively throughout the SYSVOL structure. They are a feature of the NTFS version 3.0 file system. That’s the same file system that was released with Windows Server 2000. Junction points work to eliminate data loss or corruption that can occur when you modify the SYSVOL structure.
SYSVOL uses junction points to manage a single-instance store. A single-instance store is place where a single copy of the content is used by multiple consumers for example computers. Junction points are also referred to as reparse points. A junction point is a physical location on a hard disk that points to a piece of data that is located somewhere else on your hard drive or on some other physical storage device. In a single-instance store, the physical files exist only one time on the file system; however, in SYSVOL, the file exists in SYSVOL\staging\domain or in SYSVOL\enterprise and SYSVOL\staging\enterprise. These additional directory structures are the reparse points that redirect file input and or output to the original locations.
This configuration of junction points/reparse points maintains the data consistency by making sure that a single instance of the data exists. This configuration also permits more than one access point for a given piece of data. The idea is that you get data redundancy without data duplication. Junction points graft the namespace of the destination file system to the local NTFS volume. An underlying reparse point permits NTFS to transparently remap an operation to the destination object. The result is that if you modify the data in the SYSVOL structure, the changes will occur directly on these physical files. If you were to perform a cut-and-paste operation, for example, in the SYSVOL structure that contains the junction points, then the operation would occur in the junction point.
FRS was released with Windows 2000 Server to replicate Distributed File System (DFS) folders and the SYSVOL folder. It replicates files and folders stored in SYSVOL on domain controllers and DFS shared folders. When FRS sees that a change has been made to a file or folder within a replicated share, then FRS will automatically replicate the updated folder to the other servers. FRS is a multimaster replication service, meaning any of the servers that participate in the replication can trigger updates and subsequent replications and can also resolve conflicts among both files and folders to maintain data consistency among the servers participating as replication partners. FRS keeps data synchronized across multiple servers and enables networks to increase the availability of data to their clients. If a single server becomes unavailable, the files and folders are still available because they exist on another server. FRS is good at replication in geographically dispersed wide area network environments because data can be synchronized to each physical location, which can eliminate the need for clients to use the WAN for access to information from SYSVOL or DFS. FRS is probably most commonly known for its role in replicating SYSVOL data between domain controllers in a domain. Each domain controller has a SYSVOL folder structure containing files and folders that must be available and synchronized between domain controllers in a domain. The netlogon share, system policies, and Group Policy settings all are part of the SYSVOL structure and need to be replicated to each of the domain controllers for the domain.
When you make additions, modifications, or deletions to SYSVOL, the FRS will take over and replicate those changes to the other domain controllers in the domain. FRS has some benefits that it implements when replicating data between servers, including the following:
In pre-Windows 2008 environments, FRS is used primarily in two network situations, DFS and SYSVOL replication. FRS can be used to keep data in DFS hierarchies synchronized among replica members in the replication topology. FRS and DFS are independent technologies and DFS does not require FRS. You could use other replication methods to ensure the DFS members were kept up to date.