DFS 2012R2 Step By Step Guide

Hello all,

Long time since my last post, i just finished a large implementation of DFS 2012R2 and iv’e thought this will be informative for you all so hope you will enjoy.

I also recommend using the Technet virtual Labs via Microsoft for trying to configure DFS


DFS 2012R2

Best Regards,

Henry Hazot

Active Directory FSMO roles Explained

Hello all,

I know that the Active Directory FSMO can be a bit tricky and my job is to simplify it.

Today i will explain the meaning of the FSMO and explain each operation role.

Lets start with what is the Active Directory:

The Active Directory is the central repository in which all objects in an enterprise and their respective attributes are stored

in a Database file named NTDS.dit, the NTDS is a database that is divided into partitions i will explain about partitions in my next post.

It is a hierarchical, multi-master enabled database, capable of storing millions of objects. Because it is multi-master, changes to the database can be processed at any given domain controller (DC) in the enterprise regardless of whether the DC is connected or disconnected from the network

Also the Active Directory can be Replicated over to any Domain Controller in the domain over the WAN/LAN

Multi-Master Model

A multi-master enabled database, such as the Active Directory, provides the flexibility of allowing changes to occur at any DC in the enterprise, but it also introduces the possibility of conflicts that can potentially lead to problems once the data is replicated to the rest of the enterprise. One way Windows deals with conflicting updates is by having a conflict resolution algorithm handle discrepancies in values by resolving to the DC to which changes were written last (that is, “the last writer wins”), while discarding the changes in all other DCs. Although this resolution method may be acceptable in some cases, there are times when conflicts are just too difficult to resolve using the “last writer wins” approach. In such cases, it is best to prevent the conflict from occurring rather than to try to resolve it after the fact.

For certain types of changes, Windows incorporates methods to prevent conflicting Active Directory updates from occurring.

Single-Master Model

To prevent conflicting updates in Windows, the Active Directory performs updates to certain objects in a single-master fashion. In a single-master model, only one DC in the entire directory is allowed to process updates. This is similar to the role given to a primary domain controller (PDC) in earlier versions of Windows (such as Microsoft Windows NT 3.51 and 4.0), in which the PDC is responsible for processing all updates in a given domain.

Active Directory extends the single-master model found in earlier versions of Windows to include multiple roles, and the ability to transfer roles to any domain controller (DC) in the enterprise. Because an Active Directory role is not bound to a single DC, it is referred to as a Flexible Single Master Operation (FSMO) role. Currently in Windows there are five FSMO roles:

  • Schema master
  • Domain naming master
  • RID master
  • PDC emulator
  • Infrastructure master

Schema Master FSMO Role

The schema master FSMO role holder is the DC responsible for performing updates to the directory schema (that is, the schema naming context or LDAP://cn=schema,cn=configuration,dc=<domain>). This DC is the only one that can process updates to the directory schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. There is only one schema master per directory.

Domain Naming Master FSMO Role

The domain naming master FSMO role holder is the DC responsible for making changes to the forest-wide domain name space of the directory (that is, the Partitions\Configuration naming context or LDAP://CN=Partitions, CN=Configuration, DC=<domain>). This DC is the only one that can add or remove a domain from the directory. It can also add or remove cross references to domains in external directories.

RID Master FSMO Role

The RID master FSMO role holder is the single DC responsible for processing RID Pool requests from all DCs within a given domain. It is also responsible for removing an object from its domain and putting it in another domain during an object move.

When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain.

Each Windows DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC’s allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain’s RID master. The domain RID master responds to the request by retrieving RIDs from the domain’s unallocated RID pool and assigns them to the pool of the requesting DC. There is one RID master per domain in a directory.

PDC Emulator FSMO Role

The PDC emulator is necessary to synchronize time in an enterprise. Windows includes the W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows-based computers within an enterprise use a common time. The purpose of the time service is to ensure that the Windows Time service uses a hierarchical relationship that controls authority and does not permit loops to ensure appropriate common time usage.

The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source. All PDC FSMO role holders follow the hierarchy of domains in the selection of their in-bound time partner.

In a Windows domain, the PDC emulator role holder retains the following functions:

  • Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.
  • Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password failure message is reported to the user.
  • Account lockout is processed on the PDC emulator.
  • The PDC emulator performs all of the functionality that a Microsoft Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows NT 4.0-based or earlier clients.

This part of the PDC emulator role becomes unnecessary when all workstations, member servers, and domain controllers that are running Windows NT 4.0 or earlier are all upgraded to Windows 2000. The PDC emulator still performs the other functions as described in a Windows 2000 environment.

The following information describes the changes that occur during the upgrade process:

  • Windows clients (workstations and member servers) and down-level clients that have installed the distributed services client package do not perform directory writes (such as password changes) preferentially at the DC that has advertised itself as the PDC; they use any DC for the domain.
  • Once backup domain controllers (BDCs) in down-level domains are upgraded to Windows 2000, the PDC emulator receives no down-level replica requests.
  • Windows clients (workstations and member servers) and down-level clients that have installed the distributed services client package use the Active Directory to locate network resources. They do not require the Windows NT Browser service.

Infrastructure FSMO Role

When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object’s SID and distinguished name in a cross-domain object reference.

NOTE: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server(GC). If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not be updated and a warning to that effect will be logged on that DC’s event log.

If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which domain controller holds the infrastructure master role.

When the Recycle Bin optional feature is enabled, every DC is responsible to update its cross-domain object references when the referenced object is moved, renamed, or deleted. In this case, there are no tasks associated with the Infrastructure FSMO role, and it is not important which domain controller owns the Infrastructure Master role. For more information, see Infrastructure

Removeing the Last Exchange 2003….

If you try to Remove the Exchange 2003 after you migrated all of your mailboxes to 2010 and replicated your Public Folder.

You try to Uninstall the Exchange 2003 and receive an error basically saying that you still have a few active mailboxes which you clearly don’t have.


Removing The First Exchange 2003 Server

Re-Homing The Recipient Update Service

The Recipient Update Service, or RUS to give it the acronym that it’s well known by, is an important component of Exchange 2000 and Exchange 2003 that can easily be missed during the server decommissioning process. The RUS is largely responsible for stamping user accounts with the correct addresses and failing to re-home this component to the new Exchange server will result in the loss of this functionality when the old server is decommissioned. This is because the RUS is configured with the names of both an Exchange server and a domain controller, so naturally it’ll be configured with the name of the first Exchange server that you installed unless you’ve changed it at some point. Regardless, it’s worth checking this configuration before you decommission the old server. To change this configuration to the new Exchange server, follow these steps:

  1. Run the Exchange System Manager snap-in.
  2. Navigate to the Recipients object and expand it. Underneath this object, you will see the Recipient Update Services object. Highlight this object.
  3. Now in the right-hand pane you’ll see a list of the Recipient Update Services objects that you have configured. You’ll see a minimum of two of these as shown in Figure 1. The important thing to note from Figure 1 is that any RUS that has the Exchange Server column showing as DCEX1, the server to be removed, needs to be altered.

Figure 1: Recipient Update Services

  1. Right-click each RUS to be re-homed and choose Properties. You will now be presented with a screen similar to that shown in Figure 2.

Figure 2: RUS Properties

  1. On the General tab of the properties of the RUS, you’ll see the Exchange server field containing the name of an Exchange server. You need to make sure this is not the old server being decommissioned, in this case DCEX1. If it is set to the old server, you need to change it and you can do this via the Browse button which is used to start the process to choose a new Exchange server. Click the Browse button and in the Select Exchange Server window, type in the new server name and click the Check Names button.
  2. Assuming the new server name is underlined, click OK to get back to the properties of the RUS and make sure the new server name is now shown in the Exchange server field. If it is, click OK to exit out of the RUS property pages. You’ve now removed the dependency of the RUS on the old Exchange server. Make sure you repeat this process for any RUS that is configured to use the old Exchange server.

Routing Group Masters

This next section really comes into play if you have multiple routing groups and routing group connectors. It’s important to ensure that the server being decommissioned is not the routing group master. For more information on exactly what the routing group master does, see this article here. To change the routing group master, follow these steps:

  1. Run the Exchange System Manager snap-in.
  2. Navigate to the relevant routing group and expand it. Under the routing group, select the Members object. In the right-hand pane, the servers within this routing group will be displayed. One of them will be listed as the Master. If this is the server being decommissioned, ensure that the new server is selected as the Master.
  3. To select the new server as the master, simply right-click that server and choose the Set As Master option. This is shown below in Figure 3 where I’m setting server EX2 as the new Routing Group Master.

Figure 3: Setting The Routing Group Master

  1. Once you’ve done this, the screen should automatically refresh and the new server should now be displayed as the master. It’s as simple as that.

Additional Connectors

If you have any connectors homed onto the old server, these will have to be re-homed onto the new server. One interesting example would be an X.400 Connector, since the ‘other end’ of the connector would typically point to an IP address, which could well be the IP address of the server ready to be decommissioned. Having said this, X.400 Connectors have become a lot less common over the last few years, but nevertheless it’s one to watch out for.

I won’t dwell any more on this area but you get the general idea. Check your connectors to determine if any of them are dependent on the old Exchange server.

Shut Down For A While

No, this doesn’t mean that after all these steps you can take a break. What I mean here is that it’s now time to decommission the old server by removing the Exchange server software from it. But wait! It’s good practice to shut down the Exchange services for a period of time, at least a few days but preferably a week, to make sure that there are no issues. The last thing you need to be doing is restoring a server because someone or something is still dependant on the presence of the old server. Shutting down the old server for a week should give you plenty of time to see if any issues will arise or not.

Removing Exchange

The last thing that I want to discuss seems to come up quite often within the public newsgroups, mailing lists and web forums. Assuming that you’ve replicated all your public folders, moved all user mailboxes across and followed the steps within this article, you’re now ready to remove the Exchange server software from the old server.

However, after setting the ‘Action’ field to ‘Remove’ against the Microsoft Exchange component within the Exchange Installation Wizard, you are presented with the error shown in Figure 4.

Figure 4: Existing Mailboxes Error

How can this be when you’ve already moved the user mailboxes across? Well, it’s likely that you still have some objects within Active Directory that have Exchange attributes configured for this server. To find these objects, perform the following steps:

  1. Run Active Directory Users and Computers.
  2. Right-click your domain towards the top of the left-hand pane and choose Find from the context menu.
  3. In the Find Users, Contacts, and Groups window, click the Advanced tab.
  4. Click the Field button and then choose User. From the list of attributes displayed, choose Exchange Home Server.
  5. Set the Condition field to Ends With and then type the name of the old Exchange server into the Value field.
  6. Click Add to add this condition to the Condition List. An example of what this should look like is shown in Figure 5.
  7. Click the Find Now button and you should be presented with a list of objects that still have Exchange attributes. You will need to clear these before you can remove the server. Note that you don’t need to worry about system mailboxes.

Figure 5: Finding Exchange Attributes

Once you’ve done all of this, you can insert the Exchange server software CD into the server to be decommissioned, run setup and proceed to remove the server.


When you’ve got an old Exchange server to decommission, you shouldn’t just reach for the power button as there are procedures to follow. This is even more important if you’re decommissioning the first Exchange server that was installed into an administrative group. Hopefully within this article I’ve given you the information you need to successfully and correctly do this.

vCenter Server 5.5 displays a yellow warning in the Summary tab of hosts and reports the error: Quick stats on hostname is not up-to-date


This is not the first time i see this annoying warning message

  • When connecting to VMware vCenter Server 5.5 using the VMware vSphere Client or VMware vSphere Web Client, the Summary tab of the ESXi 5.5 host shows a yellow warning.
  • You see the error:
    Configuration issues. “Quick stats on hostname is not up-to-date”
  • This issue does not occur if you connect directly to the ESXi host.

Why does this happen ?

It’s basically a VMware vCenter 5.5 BUG and has been fixed in the next update VMware vCenter Server 5.5.0b


First Option: Upgrade your vCenter 5.5 to the latest update and that message will disappear (Recommended)

Second Option:

To work around this issue when you do not want to upgrade, add these quickStats parameters to the Advanced Settings of vCenter Server:
  • vpxd.quickStats.HostStatsCheck
  • vpxd.quickStats.ConfigIssues
Note: Adding these parameters to vCenter Server does not affect future upgrades.
To add the quickStats parameters to the Advanced Settings of vCenter Server:
  1. In the vSphere Web Client, navigate to the vCenter Server instance.
  2. Select the Manage tab.
  3. Select Settings > Advanced Settings.
  4. Click Edit.
  5. In the Key field, enter this key:
  6. In the Value field, enter:
  7. Click Add.
  8. In the Key field, enter this key:
  9. In the Value field, enter:
  10. Click Add.
  11. Click OK.
  12. Restart the vCenter Server services.


Henry Hazot

VCP 5.5, MCT 2014

VMware View 6.0 Installation Guide and Features

Hello all,

This time i’m presenting The new Horizon  View 6.0 by VMware.

I uploaded a Video of a full installation process about 18 Min.


Video :




New support for RDS:


For any questions or requests please let me know…

Henry Hazot

New Features in 2012R2

Virtualization-Safe Technology

  • Solution
    • Windows Server 2012 virtual DCs able to detect when:
      • snapshots are applied
      • a VM is copied
    • built on a generation identifier (VM-generation ID) that is changed when virtualization-features such as VM-snapshot are used
    • Windows Server 2012 virtual DCs track the VM-generation ID to detect changes and protect Active Directory
      • protection achieved by:
        • discarding RID pool
        • resetting invocationID
        • re-asserting INITSYNC requirement for FSMOs

Group Managed Service Accounts


  • Solution
    • introduce new security principal type known as a gMSA
    • services running on multiple hosts can run under the same gMSA account
    • 1 or more Windows Server 2012 DCs required
      • gMSAs can authenticate against any OS-version DC
      • passwords computed by Group Key Distribution Service (GKDS) running on all Windows Server 2012 DCs
    • Windows Server 2012 hosts using gMSAs obtain password and password-updates from GKDS
      • password retrieval limited to authorized computers
    • password-change interval defined at gMSA account creation (30 days by default)
    • like MSAs, gMSAs are supported only by the Windows Service Control Manager (SCM) and IIS application pools
      • support for scheduled tasks is being investigated

Off-Premises Domain Join


  • Extends offline domain-join by allowing the blob to accommodate Direct Access prerequisites
    • Certs
    • Group Policies
  • What does this mean?
    • a computer can now be domain-joined over the Internet if the domain is Direct Access enabled
    • getting the blob to the non-domain-joined machine is an offline process and the responsibility of the admin

Recycle Bin User Interface

  • Solution
    • simplify object recovery through the inclusion of a Deleted Objects node in the Active Directory Administrative Center
      • deleted objects can now be recovered within the graphical user interface
    • greatly reduces recovery-time by providing a discoverable, consistent view of deleted objects

Fine-Grained Password Policy


  • Solution
    • creating, editing and assigning PSOs now managed through the Active Directory Administrative Center
    • greatly simplifies management of password-settings objects


Dynamic Access Control (DAC) my favorite


  • Solution
    • new central access policies (CAP) model
    • new claims-based authorization platform enhances, not replaces, existing model
      • user-claims and device-claims
      • user+device claims = compound identity
        • includes traditional group memberships too
    • use of file-classification information in authorization decisions
    • modern authorization expressions, e.g.
      • evaluation of ANDed authorization conditions
      • leveraging classification and resource properties in ACLs
    • easier Access-Denied  remediation experience
    • access- and audit-policies can be defined flexibly and simply, e.g.
      • IF resource.Confidentiality = high THEN audit.Success WHEN user.EmployeeType = vendor


Active Directory SnapShots


Windows DC’s detect when snapshots are applied or VM is copied

VM-generationID is the key here http://technet.microsoft.com/en-us/library/hh831734.aspx


Virtualization on VMware

VMware has implemented the VM-GenerationID functionality

VMware ESXi 5.0 Update 2 (Build 914586) and subsequent updates to ESXi 5.0

VMware ESXi 5.1 (Build 799733) and subsequent updates to ESXi 5.1

VMware ESXi 5.5 (Build 1331820) and subsequent updates to ESXi 5.5

You’ll need VMware Tools


Rapid Deployment: Domain Controller Cloning


  • Solution
    • create replicas of virtualized DCs by cloning existing ones
      • i.e. copy the VHD through hypervisor-specific export + import operations
    • simplify interaction & deployment-dependencies between Hypervisor and Active Directory admins
      • note that the authorization of clones remains under Enterprise/Domain Admins’ control
    • a game-changer for disaster-recovery
      • requires ONLY a single Windows Server 2012 virtual DC per domain to quickly recover an entire forest
      • subsequent DCs can be rapidly deployed drastically reducing time to steady-state
    • enables elastic provisioning capabilities to support private-cloud deployments, etc