Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Windows Server 2008 R2 : Manage the Active Directory Database (part 1) - Maintain FSMO Roles & Transfer FSMO Roles

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
9/10/2011 4:03:42 PM
For all of its fanfare and cool functions, when you take off all the pretty interfaces and controls, Active Directory (AD) is at its core a database named NTDS.DIT. It has a defining schema, a set of partitions, and tables much like any other database. It shares the data contained within the database among a series of authoritative and nonauthoritative servers called domain controllers (DCs) and read-only DCs, respectively. The directory database relies on the physical hardware on which it resides to maintain consistent performance. If the hardware has significant limitations of speed, capacity, or other performance aspects, those limitations will be inherited by the directory database. In a like manner, if the physical hardware suffers failures, those failures will be perpetuated through the directory database. This section covers how to manage the directory database by managing the hardware on which the database resides.

So, how exactly should you do this? Here's how many successful clients have done it:

  1. Install the operating system on a mirrored partition.

  2. Install the NTDS.DIT database on a RAID 5 volume.

  3. Install the log files associated with AD on a separate mirrored partition.

This straightforward implementation provides performance and fault tolerance to the operating system, directory database, and log files by distributing the processor and disk workload across multiple physical platforms. It does take a fair number of disks to implement, but the resulting benefits in performance and fault tolerance are well worth it.

What about other options for installation? Couldn't you install the OS, directory database, and log files on a single local drive? In short, yes, you could install them all on the same physical drive. Please don't do this, though. It just places too much of a workload on a single point of failure. When that drive fails (and it will), you will lose everything. Bite the bullet up front, and set up your directory for performance and fault tolerance. Once your directory database is happily running on its physical hardware, which you will be constantly monitoring to maintain its health and performance, then it's time to start considering some important topics.

1. Maintain FSMO Roles

Active Directory is stored in writable form on multiple DCs. Usually having all these writable copies of the directory database is just fine. On rare occasions, it can be problematic having all of these DCs have write access, such as when you are creating new domain objects, when you are changing the schema of the directory, or when you are changing a user's password.

These are the FSMO (pronounced "fizz-mo") roles:

Schema master The schema master domain controller controls all updates and modifications to the schema. To update the schema of a forest, you must have access to the schema master. This role would be used in conjunction with the adprep or domainprep command. There can be only one schema master in the whole forest.

Domain naming master The domain naming master domain controller controls the addition or removal of domains in the forest. There can be only one domain naming master in the whole forest.

Infrastructure master The infrastructure master is responsible for updating references from objects in its domain to objects in other domains. It is also used in conjunction with adprep or domainprep and to update SID attributes and distinguished name attributes for objects that are referenced across domains. At any one time, there can be only one domain controller acting as the infrastructure master in each domain.

Relative ID (RID) master The RID master is responsible for processing RID pool requests from all domain controllers in a particular domain. These RID pools are used to create new user accounts, computer accounts, or groups. At any one time, there can be only one domain controller acting as the RID master in the domain.

PDC emulator The PDC emulator is a domain controller that advertises itself as the primary domain controller (PDC) to workstations, member servers, and domain controllers that are running earlier versions of Windows. It is also the domain master browser, and it handles password discrepancies and updates to user and computer account passwords. At any one time, there can be only one domain controller acting as the PDC emulator master in each domain.

Please see http://support.microsoft.com/kb/324801 and http://support.microsoft.com/kb/255504 for additional details on the FSMO roles.


The real questions begin when you start to consider that the initial DC that is built in each forest (referred to as the forest root server) will by default hold all five FSMO roles. Should they stay there when you add DCs? If not, how do you move them? What if, heaven forbid, the server that holds your FSMO roles crashes and burns? What do you do then?

On the day it is installed, the forest root server does in fact hold all five FSMO roles, and while you are setting up your other DCs, that forest root server will likely do just fine holding all five roles. Remember that the roles come in two types: forest-wide roles, one per forest, and domain-wide roles, one per domain. Each forest will have a single schema master and domain naming master regardless of the number of domains you create. These roles are just fine to stay on your forest root server. Each domain will have its own PDC emulator, RID master, and infrastructure master. As you create new domains in your directory database and add new domain controllers to manage those domain directory resources, the first DC created in each domain will take on the domain-based roles for that individual domain. This all proceeds quite nicely in an organized fashion as you build the infrastructure of your directory. Assuming that you are allocating sufficient server resources for each DC, you will not have any problems with FSMO roles.

It is possible to relocate the FSMO roles to another domain controller for reasons of personal preference or in the event of a failure by a current role holder. The circumstances surrounding the transfer of roles will determine the process of the role change. If all the DCs are still online and you are making a role change in a nice controlled environment, that's a role transfer. If the server that holds the role is offline for any reason, such as it has failed, you will take the role from it in a process called seizing the role.

Although the absence of an FSMO role holder can have serious consequences, it is much more likely that the failure of a FSMO role holder can be tolerated in most situations for at least a limited amount of time, allowing you to "fix" whatever caused the DC to fail.

2. Transfer FSMO Roles

Ideally, you will be doing a nice planned transfer of roles from one operating DC to another. In this case, you have a couple of options:

  • Use the graphical user interface tools to view role ownership and initiate transfers. The graphical tools can be used only if the server that is the original role holder is still online. If the original role holder is not currently online, then the transfer of roles (seizure) can be performed using the command-line utilities only.

  • Use the command-line utility called NTDSUTIL to script the transfer or seizure of roles.

The GUI tools for viewing and transferring FSMO roles include Active Directory Users And Computers for working with the RID master, PDC emulator, and infrastructure master.

  1. Open the Active Directory Users And Computers tool.

  2. Right-click Active Directory Users And Computers.

  3. Choose All Tasks.

  4. Choose Operations Masters.

You can click Change here to change the role to another server, as illustrated in Figure 1.

Figure 1. The Active Directory Users And Computers tool shows the three domain-based FSMO roles.

You must be connected to the server that you want to change to. The GUI tool for viewing the forest-wide tools is Active Directory Domains And Trusts for changing the domain naming master.

  1. Open the Active Directory Domains And Trusts tool.

  2. Right-click Active Directory Domains And Trusts.

  3. Choose Operations Master.

Figure 2 illustrates how you can view the role holder and change it to another computer.

The GUI tool for viewing the schema master role is a little trickier. By default there is no built-in or enabled GUI tool that you can use to work with the schema master role. You need to both enable and add the Active Directory Schema snap-in to the Microsoft Management Console (MMC) in order to have GUI access to the schema master role. This tool is not enabled by default. To enable the Active Directory Schema snap-in, follow these steps:

  1. Select Start => Run.

  2. Type regsvr32 schmmgmt.dll, and hit Enter.

  3. A message will appear confirming that DLLRegisterServer in schmmgmt.dll succeeded. Click OK.

Figure 2. The Active Directory Domains And Trust tool shows the domain naming master FSMO role holder.

You are not done yet. Now that you have enabled the tool, you will need to add it to the MMC in order to actually use it.

To add the Active Directory Schema snap-in to the Microsoft Management Console, follow these steps:

  1. Select Start => Run.

  2. Type MMC.

  3. Select File Add/Remove Snap-In.

  4. Select Active Directory Schema.

  5. Click Add.

  6. Right-click Active Directory Schema, and select Choose Operations Master.

Figure 3 shows how to view the schema master and change the server that hosts this role.

Figure 3. The Active Directory Schema snap-in shows the schema master FSMO role holder.

It is not always possible to use the GUI tools to work with FSMO role changes. What if the server you want to transfer a role from is offline? Connecting to an offline server is not possible. You will have to take more drastic action. As is often the case when working with Windows Server 2008 R2, you can get significantly more options by using the command-line tool NTDSUTIL. This utility will allow you to transfer FSMO roles and can also be used to seize these roles without the express permission of the original role holder.

NOTE

Once you have seized a role from the original role holder, you will need to make certain that the original role holder is not brought back online in that network.

2.1. Seize FSMO Roles with NTDSUTIL

To seize roles using NTDSUTIL, you can follow these steps:

  1. Select Start => Run.

  2. Type ntdsutil in the Open text box, and then click OK.

  3. Type roles, and then press Enter.

  4. Type connections, and then press Enter.

  5. Type connect to server servername, where servername is the name of the domain controller that you want to assign the FSMO role to, and then press Enter.

  6. At the server connections prompt, type q, and then press Enter.

  7. Type seize role, where role is the role that you want to seize. For a list of roles that you can seize, type ? at the fsmo maintenance prompt, and then press Enter. For example, to seize the RID master role, type seize rid master. The one exception is for the PDC emulator role, whose syntax is seize pdc, not seize pdc emulator.

  8. At the fsmo maintenance prompt, type q, and then press Enter to gain access to the ntdsutil prompt.

  9. Type q, and then press Enter to quit the NTDSUTIL utility.

Other -----------------
- Windows Server 2008 R2 : Troubleshoot Group Policy
- Microsoft Lync Server 2010 Edge : Edge Installation
- Microsoft Lync Server 2010 Edge : Edge Overview
- Updating Objects and Virtualization with Dynamics NAV : Virtualization with Dynamics NAV
- Updating Objects and Virtualization with Dynamics NAV : Objects in NAV
- SQL Server 2005 : SQLCLR Security and Reliability Features (part 3) - Granting Cross-Assembly Privileges
- SQL Server 2005 : SQLCLR Security and Reliability Features (part 2) - Selective Privilege Escalation via Assembly References
- SQL Server 2005 : SQLCLR Security and Reliability Features (part 1) - The Quest for Code Safety
- SQL Server 2005 : Wrapping Code to Promote Cross-Tier Reuse
- SharePoint 2010 Search : Setting Up the Crawler - Crawling Exchange Public Folders & Crawling Line-of-Business Data
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server