Active Directory is a proven technology that has been around since Windows 2000 Server. Some Active Directory environments have been around since that time, while some others have even been around ever longer and started their lives as Windows NT 3.x or Windows NT 4.0 domains. With directory environments growing older, some limits of these environments come into sight.

In Active Directory Domain Services and Active Directory Lightweight Domain Services (or Active Directory Application Mode, ADAM, as we knew it in earlier times) one of the typical limits older environments might face is the maximum size of the RID Pool.

About Relative Identifiers (RIDs)

Relative Identifiers (RIDs) are used in Active Directory Domain Services and Active Directory Lightweight Domain Services to create objects within the namespace of the environment. Under the hood every object has a Security Identifier (SID), consisting of the SID Namespace of the domain and the Relative Identifier (RID):

Tip!
You can easily find the SID of a currently logged in user with the whoami.exe /user command.

About RID Pools and RID Pool blocks

Active Directory uses a multi-master model. Compared to NT4, you can write to the database on all Domain Controllers. This model requires certain roles to be unique. In Active Directory five roles, named the Flexible Single Master Operations (FSMO) roles are identified. FSMO roles are added to Domain Controllers.

The RID Pool Master FSMO role is one of them. The scope of the RID Pool Master FSMO role is the domain. Domain Controllers communicate with the RID Pool Master to acquire a RID Pool block so they can accommodate object creation in the multi-master model. Since every object in Active Directory has an unique SID, consisting of the Domain SID Namespace and the Relative Identifier (RID) to the namespace, each object creation requires a RID.

The RID Pool depletion challenge

When an Active Directory environment runs out of Relative Identifies (RIDs) , a situation called RID Pool exhaustion or RID Pool depletion occurs. This is a serious problem, since no new objects can be created after the local RID Pool blocks of the Domain Controllers,  are used up.

In an Active Directory domain, 2³⁰-1 (1,073,741,823 or roughly 1 billion) RIDs are available, resulting in a maximum of 2 billion objects, including users, computers, groups, domain trusts, fine-grained password policies and Managed Service Accounts (MSAs).

The make things worse, a couple of scenarios have been identified, where RID Pool blocks and thus the RID Pool is used up fast. In these scenarios a RID is taken from a RID Pool block, but is not used to create an object. A prime example is user creation, where the user didn’t meet the policies set in the domain. An example of such a policy would be a password policy. Also, when a Domain Controller computer object was deleted and subsequently reanimated or restored, it would ask for a new RID Pool block every 30 seconds because of a missing rIDSetReference attribute and thus depleting the RID Pool in roughly 2 years...

Analyzing remaining RIDs in an environment

To analyze the state of an Active Directory environment, use the following command:

dcdiag /test:ridmanager /v | find /i "Available RID Pool"

The output will show you the used relative identifier compared to the maximum amount of available RIDs in the environment in the following format:

* Available RID Pool for the Domain is 1601 to 1073741823

What’s New

The RID Reuse Pool

Identified scenarios that lead to unusual fast RID Pool depletion have been fixed.

In Windows Server 2012, when RID leaked when object creation fails occurs, the RID is placed in a RID Reuse pool, instead of being leaked. Upon subsequent object creation, a RID is taken from the RID Reuse pool (if any available) instead of from the RID Pool block. Rebooting a Domain Controller clears the RID Reuse Pool.

Periodic RID Pool Consumption Warnings

When an Active Directory environment reaches RID Pool depletion, warnings will appear in the System log of the Domain Controller holding the RID Pool Master FSMO role. These warnings start at 10% depletion and become more frequent as the RID Pool is further depleted. These consumption warnings are found in the form of warnings in the System Log of Domain Controllers with event-id 16658 and source Directory-Services-SAM.

RID Pool Artificial Ceiling Protection

When the Domain Controller holding the RID Pool Master FSMO role has handed out RID Pool blocks corresponding to 90% of the RID Pool, it will stop handing out RIDs and RID Pool blocks. Additionally, at that moment, event-id 16657 with source Directory-Services-SAM is logged. This results in a soft ceiling to prevent full RID Pool depletion. This helps Active Directory admins to avoid further problems, since they will still be able to commission more Windows Server 2012-based Domain Controllers to get rid of Domain Controllers on older versions of Windows Server and/or to create trusts to migrate objects with the Active Directory Migration Tool (ADMT).

Tip!
This is a crucial moment in the life of the Active Directory environment and should trigger a meeting with all Active Directory admins and their managers to decide on the course to follow to keep the Active Directory healthy for a long time. This might be the moment to collapse that multi-resource forest environment or to migrate to a new Active Directory domain.

Domain Admins can override the ceiling by setting the msDS-RIDPoolAllocationEnabled attribute on the RID Manager$ object in the System container of the domain to true. Perform the following steps to achieve this:

1. Run LDP.exe
2. Click the Connection menu and click Connect for the Windows Server 2012-based Domain Controller holding the RID Pool Master FSMO role. Use the default port 389. When connected, go back to the Connection menu and click Bind. Bind as a domain administrator.
3. Click the View menu and click Tree, then for the Base DN select the domain naming context from the drop-down list. Click Ok
4. In the navigation pane, drill down into the CN=System container and click the CN=RID Manager$ object. Right click it and click Modify
5. In Edit Entry Attribute, type:
       
        MsDS-RidPoolAllocationEnabled
       
6. In Values, type (in upper case):
       
        TRUE
       
7. Select Replace in Operation and click Enter. This updates the Entry List.
8. Enable the Synchronous option, then click Run.
9. If successful, the LDP output window shows:

***Call Modify...
ldap_modify_ext_s(ld, 'CN=RID Manager$,CN=System,DC=domain,DC=tld',[1] attrs, SvrCtrls, ClntCtrls);
Modified "CN=RID Manager$,CN=System,DC=<domain>".

Upper bound for RID Pool Block Sizes

As you might know, by default, a RID Pool block consists of 500 RIDs. In previous versions of Windows Server, the RID Pool block size could be configured by editing the registry on each Domain Controller. The RID Block Size (REG_DWORD) registry value located in HKLM\System\CurrentControlSet\Services\NTDS\RID Values could be used to that purpose.

in Windows Server 2012, the maximum permissible admin-configured RID block size is 15,000. This means that the RID Pool block size now has a maximum of 15,000 RIDs, independent of the value entered in the registry.

If a value greater than 15,000 is entered, it will use a RID Pool block size of 15,000. Additionally error 16653 with source Directory-Services-SAM will be logged at every boot to inform only RID Pool blocks of 15,000 RIDs are requested from the Domain Controller holding the RID Pool Master FSMO role.

Double the RID Pool

In Windows Server 2012, the 31st bit of the RID Pool can be enabled, enabling organizations to create a billion more objects, in addition to the original billion RIDs. By unlocking the 2³¹ bit increases the RID Pool to 2,147,483,647.

Unlocking the 31st bit of the RID Pool can be achieved by setting sidCompatibilityVersion to 1 using a RootDSE Modification:

1. Run LDP.exe
2. Click the Connection menu and click Connect for the Windows Server 2012-based Domain Controller holding the RID Pool Master FSMO role. Use the default port 389. When connected, go back to the Connection menu and click Bind. Bind as a domain administrator.
3. Click the Browse menu and click Modify
4. Ensure that DN is blank
5. In Edit Entry Attribute, type:
       
        SidCompatibilityVersion
       
6. In Values, type:
       
        1
       
7. Ensure that Add is selected in Operation and click Enter. This updates the Entry List
8. Select the Synchronous option, then click Run:
       
   
       
9. If successful, the LDP output window shows:
       
        ***Call Modify...
        ldap_modify_ext_s(Id, '(null)',[1] attrs);
        modified "".
       
10. When successful, Information event 16655 from source Directory-Services-SAM will be logged once in the System log of the Domain Controller.

Requirements

For Lifting the RID Pool Artificial Ceiling Protection, the Domain Controller holding the RID Pool Master FSMO Role should be running Windows Server 2012.

Tip!
Since, for Domain Controller Cloning you might have already migrated the Domain Controller holding the PDC Emulator FSMO Role to Windows Server 2012 and KnowledgeBase article 223346 recommends to place the PDCe and RID Pool Master FSMO roles on the same server, this might not be such a harsh requirement.

When you want to enable the 31st bit of the RID Pool to effectively double the available RIDs, all Domain Controllers should be running Windows Server 2012. Previous versions of Windows Server on Domain Controllers should be patched or upgraded.

All the other features are local features to Windows Server 2012 and should be available per Domain Controller when you promote them.

Concluding

Many organizations cherish their Active Directory environment. To make these implementations last longer without running into RID Pool depletion problems, the Active Directory team has incorporated improvements in Active Directory to prevent RID leakage and rapid unmonitored RID Pool Depletion. Also, Windows Server 2012 allows you to host 2 billion objects in an Active Directory domain.

Related KnowledgeBase articles

Description of RID Attributes in Active Directory  
"Domain controller has failed to obtain a new identifier pool" error event       
FSMO placement and optimization on Active Directory domain controllers 

Further reading

Managing RID Issuance in Windows Server 2012  
Managing RID Issuance 
Windows 2012 RID Management   
What are the new features in Windows 2012 Active Directory   
What do I need to watch out for in managing the RID pool used in an AD domain? 
Managing RID Pool Depletion     
Active Directory Maximum Limits – Scalability  
ObjectSID and Active Directory

As already mentioned in the previous blog post on RID Improvements in Windows Server 2012, Active Directory environments are sometimes cathedrals of Microsoft technology; they’re big, they’re old and a lot of effort has been put into them to get them into the shape they’re in today.

In these environments, changes in the indexability of objects and their attributes may sometimes have a big effect on the availability of Domain Controllers to serve clients and replicate changes. In these environments, index creation almost results in a Denial of Service (DoS) of Active Directory, when all Domain Controllers are semi-simultaneously busy (re)creating indices in the database. And isn’t that ironic? These indices were built into Active Directory to speed up the performance in the first place.

So, when do changes in indexability of objects and attributes occur? Basically, three scenarios exist where Domain Controllers will (re)build indices:

• When a Domain Controller is shut down inappropriately, when a Domain Controller is restored from an improper backup or when a Domain Controller has been converted to a virtual machine without bringing it offline.
• When an Active Directory admin makes a change in the schema to make an attribute indexable.
• When an Active Directory admin performs a schema update, for instance to accommodate Domain Controllers running newer versions of Windows Server, or to introduce Exchange Server or Lync Server in the current environment.

In the latter two scenarios, Windows Server 2012 helps out.

What’s New

On Domain Controllers running Windows Server 2012, index creation can be deferred to a time when it’s more convenient. The feature is called Deferred Index Creation.

DSHeuristic

The way the Active Directory team has built this into Windows Server 2012 is by using a bit in the DSHeuristic attribute in the Directory Services object.

Enabling Deferred Index Creation

Deferred Index Creation can be enabled by changing the 18th bit from 0 to 1. Here’s how:

1. Run ldp.exe.
2. Click the Connection menu and click Connect. Use the default port 389. When connected, go back to the Connection menu and click Bind... Bind as an enterprise administrator.
3. Click the View menu and click Tree, then for the Base DN select the domain naming context from the drop-down list. Click Ok.
4. In the navigation pane, drill down into the CN=Configuration container, then CN=Services, CN=Windows NT and there click the CN=Directory Services object.
5. Double-click the CN=Directory Services object.
6. Check the object attribute listing on the right side to determine whether the dsHeuristics attribute is already set. If it is set, copy the existing value to the clipboard.
7. Right-click the Directory Service objects on the left side, and then click Modify.
8. As the attribute name, type dsHeuristics.
9. As a value, type 000000000100000001. Replace the zeros in the first part of the value with what you may already have in dsHeuristics. Make sure that you have the correct count of digits up to the "1"; To enable Deferred Index Creation the 18th bit needs to be set.
   
        Note:
        To verify that the correct characters are being modified, every tenth character
        must be set to the number of characters up to that point divided by ten;
        The tenth character must be 1, the twentieth character must be 2, the
        thirtieth character must be 3, and so on.
       
10. If the attribute already existed, click Replace in the Operation box. Otherwise, click Add.
11. Press ENTER on the right to the Operation group to add it to the LDAP transaction.
12. Click Run to apply the change to the object:
        
        
        
13. When successful, the output will be:
         
         ***Call Modify...
         ldap_modify_s(ld, 'CN=Directory Service,CN=Windows NT,CN=Services,
         CN=Configuration,DC=domain,DC=local',[1] attrs);
         Modified "CN=Directory Service,CN=Windows NT,CN=Services,
         CN=Configuration,DC=domain,DC=local".
    

After this change is replicated to all Domain Controllers, they will defer Index Creation by default. This will result in the following behavior:

• Windows Server 2012-based Domain Controllers will defer building indices until they receive the UpdateSchemaNow rootDSE mod. . This triggers the rebuilding of the schema cache.
• Windows Server 2012-based Domain Controllers will defer building indices until they are rebooted.  This requires that the schema cache be rebuilt and, in turn, the deferred indices.

In addition, any attribute that is in a deferred index state will be logged in the event Log every 24 hours on each of the Domain Controllers with Deferred Index Creation enabled. The following event-ids are used:

• event-id 2944: index deferred – logged once
• event-id 2945: index still pending – logged every 24 hours
      

Performing a UpdateSchemaNow rootDSE mod

Having Deferred Index Creation enabled allows for greater control over which Domain Controller will build indices at what moment in time. However, rebooting Domain Controllers as a means seams worse than the initial problem, since without Deferred Index Creation, Domain Controllers would be unavailable, but wouldn’t need to be rebooted.

With Deferred Index Creation enabled, Domain Controllers don’t need to be rebooted, although in some scenarios it might be the easiest way. For instance when Schema Updates are part of a service window that also includes applying Windows Updates and thus rebooting servers.

Domain Controllers with Deferred Index Creation enabled can be set to build the indices with the UpdateSchemaNow rootDSE mod. Perform the following steps to do so:

1. Run adsiedit.msc.
2. Right-click the ADSI Edit text in the top of the left most pane and select Connect to... from the context menu.
3. Leave the Default Naming Context as name, but select the Select a well known Naming Context: option and change it to RootDSE from the pull down list.
4. Right-click the RootDSE and choose Update Schema Now from the context menu:
       
       
       

When the Domain Controller has built the index event-id 1137 is logged in the event log. It will indicate the index has been created. But you might already be familiar with this event-id, since it’s not a new event-id.

Concluding

Deferred Index Creation can help in large Active Directory environments to prevent unavailable Domain Controllers due to the building of indices after schema updates.

Deferred Index Creation allows for greater control over which Domain Controller will build indices at what moment in time, but as an Active Directory admin, you will need to signal each Domain Controller to create indices or reboot them before they will.

Related DirTeam posts

Active Directory in Hyper-V environments, Part 6

Related KnowledgeBase articles

307323 AD replication delayed when indexed attributes rebuilt during schema upgrade   
307219 Replication Stops After Active Directory Schema Update    

Further reading

How to Index an Attribute in Active Directory  
Default Active Directory Attributes in the Windows 2000 Schema 
Indexing in Active Directory 
attributeSchema Objects    
rootDSE Modify Operations  
ADSI Edit (adsiedit.msc)

Windows Genuine Advantage and Windows Activation has been hunting admins trying to make their legally purchased volume licenses seamlessly work for them for years.

About volume activation

While Windows XP volume activation was straightforward, Microsoft felt its volume license product keys were misused in less legal situations; according to the Volume Activation 2.0 FAQ available here, "Volume License keys represent the majority of keys involved in Windows piracy". Back then, Windows XP volume license keys did not require activation by Microsoft-owned servers.

With Windows Vista, Microsoft introduced Volume Activation 2.0. Within this program, Microsoft made every customer either check every product key with Microsoft’s hosted activation services (Multiple Activation Keys) or make a KMS host report on product key usage for an entire organization.

About KMS

Key Management Services (KMS) is an on-premises server-client model for volume activation. KMS clients use DNS to find KMS hosts and communicate with them using TCP port 1688 (by default). The choice of KMS host Operating System and the (in)availability of KMS host Windows Updates determines the Windows, Windows Server and/or Office activation possibilities.

In some environments end users were faced with warnings of unlicensed software usage due to inactivity (a KMS client needs to connect to the KMS every 180 days). In other environments the initial activation count to use KMS was not reached or hosts in perimeter networks (DMZs) and/or isolated networks were not allowed to contact the KMS host(s). In both these environments admins had to resort to using MAKs.

About MAK

Multiple Activation Keys (MAKs) are used for one-time activations with Microsoft. Each Multiple Activation Key an admin can punch in has a predetermined number of allowed activations. This number is based on the volume licensing agreement. Each activation using a MAK with Microsoft’s hosted activation service counts towards the activation limit.

There are two ways to activate computers using MAK: MAK Independent and MAK Proxy activation. MAK Independent activation requires that each computer independently connect and activate with Microsoft, either over the Internet or by telephone. MAK Proxy activation enables a centralized activation request on behalf of multiple computers with one connection to Microsoft. MAK Proxies are useful for environments that do not maintain a (transparent) connection to the Internet. MAK Proxy activation is configured using the Volume Activation Management Tool (VAMT).

About VAMT

The Volume Activation Management Tool (VAMT) is a free tool that admins can download and use to centrally alter the volume activation method and product key for clients.

What’s New

Windows Server 2012 introduces the concept of Active Directory-based Activation does.

Automatic activation with domain membership

In environments with Active Directory-based Activation configured, when you join a Windows computer to an Active Directory domain, the Windows and/or Office installations on that computer will automatically activate. Activation is valid for 180 days. During this time the client should communicate with a Domain Controller at least once to renew the activation period.

When you remove a computer from the domain, the Windows and/or Office installations immediately get deactivated.

No activation threshold

Where KMS requires 25 (physical) Windows installations or 5 Windows Server installations to begin centrally activating, Active Directory-based Activation does not have a minimum amount of clients or servers to activate.

No host maintenance needed anymore

Although KMS is the preferred volume activation method in environments with more than 25 (physical) clients or five servers, one of the downsides of KMS is the necessity for a KMS host. While the KMS host can coexist with any other Server Role, it adds extra management tasks.

With Active Directory-based Activation no single physical computer is required to act as the activation object, because the activation information is stored in the ms-SPP-Activation object in Active Directory.

Automatic high availability and failover

Since Active Directory-based Activation uses Active Directory Domain Controllers for client-server activation communications, each (R/W) Domain Controller is an available activation host. As an admin you no longer need to manually configure secondary KMS Host DNS records (only the first KMS Host registers the DNS records).

No more dedicated KMS Port

Where KMS used TCP port 1688 (by default) for client-server communication, Active Directory-based Activation uses commonly used Active Directory client-server communication ports.

Works together with KMS

Environments with Active Directory-based Activation are not limited to using only Active Directory-based Activation to activate Windows, Windows Server and/or Office installations. On the same network, also KMS can still be used. This is useful to activate previous versions of Windows, Windows Server and/or Office that do not support Active Directory-based Activation.

Windows 8 and Windows Server 2012 installations will first try to activate through Active Directory-based Activation (act-type 1). When unsuccessful, these installations will try to activate through Key Management Services (act-type 2) and when unsuccessful again will try token-based activation (act-type 3)

Enabling AD-based Activation

Installing AD-based Activation

Installing Active Directory-based Activation requires installing the Volume Activation Services Server role. This can be done in two ways:

Using Server Manager

To install the Volume Activation Services role using Server Manager perform the following steps:

1. In Server Manager click on Manage in the top right.
       
2. Click Add Roles and Features.
       
   
       
3. Select Role-based or Feature-based installation in the Select installation type screen. Click Next >.
       
4. Select a server to install the Volume Activation Services on from the server pool in the Select destination server screen. Click Next >.
        
   
       
5. In the Select server roles screen, select Volume Activation Services.
       
   
       
6. A pop-up appears with a selection of features that are required to manage the Windows Activation Services role. Click Add Features.
       
7. In the Select server roles screen click Next >.
       
8. In the Select features screen click Next >.
       
   
       
9. Read the notes in the Volume Activation Services screen and click Next > when done.
       
10. On the Confirm installation selections page, confirm that the information is correct, then click Install.
      

Using PowerShell

To install the Volume Activation Services, run the following PowerShell one-liner:

Install-WindowsFeature VolumeActivation –IncludeManagementTools
      

Configuring AD-based Activation

To configure Volume Activation Services, log on as an enterprise admin to the server on which you installed the Volume Activation Services Role. Then perform the following steps:

1. Open Server Manager.
       
2. Click on Tools in the upper right corner and then click Volume Activation Tools.
       
   
       
3. In the Introduction to Volume Activation Services screen, click Next >.
       
   
       
4. In the Select Volume Activation Method screen, select Active Directory-based Activation. Click Next >.
       
   
       
5. Enter the KMS Host product key in the Manage Activation Objects screen. Optionally, specify a name for the Active Directory activation object. Click Next > when done. 
        
   
       
6. Choose to activate the key online or by phone in the Activate Product screen, and then click Commit.
       
   
       
7. A pop-up appears, mentioning an Active Directory-based Activation object will be created. Click Yes.
             
   
       
8. In the Activation Succeeded screen click Close.

This will create an activation object underneath CN=Activation Objects,CN=Microsoft SPP,CN=Services,CN=Configuration,DC=domain,DC=tld as shown below using ldp.exe:

After replication of the object and its attributes, Windows client installation, Office installations and Windows servers installations, covered by the KMS Host product key and configured with their corresponding setup keys, will activate automatically.

Tip!
Volume License (VL) downloads for Windows and Windows Server are automatically configured with their corresponding setup keys and thus require no changes for automatic activation by KMS or Active Directory-based Activation.

Reporting on activated licenses

To report on activated licenses and thus present proof of license compliance, Volume Activation Management Tool (VAMT) version 3 can be used.

Note:
VAMT 3.0 can only be installed on Windows 7, Windows 8, Windows Server 2008 R2 and Windows Server 2012 installations. PowerShell 3.0

Installing VAMT 3

To install Volume Activation Management Tool (VAMT) 3.0 begin by downloading the Windows Assessment and Deployment Kit (ADK) for Windows 8. When this 700KB download finishes, run it:

1. In the Specify Location screen, click Next.
        
2. Make the choice to participate or not in the Join the Customer Experience Improvement Program (CEIP) screen and click Next.
       
3. Click on the Accept button in the License Agreement screen.
       
   
       
4. Select to install the Volume Activation Management Tool (VAMT) and Microsoft SQL Server 2012 Express in the Select the features you want to install screen. 
             
        Tip!
        Existing SQL installations can be used by the Volume Activation Management
        Tool. When your environment already features a SQL Server and you want to
        use this installation to host the VAMT database, you don’t have to select the
        Microsoft SQL Server 2012 Express option. (In this case specify the
        hostname of the SQL Server during step 2 of configuring VAMT 3.)
       
   Click Install when done.
   
5. The selected features will now be installed. After installation the Welcome to the Assessment and Deployment Kit! screen will appear. Click Close.

Configuring clients for reporting

By default, the Volume Activation Management Tool (VAMT) will not be able to communicate with activation clients. It uses WMI. By default, this type of traffic is blocked by the Windows Firewall. To enable it, follow these steps:

1. Log on to a Domain Controller, or a management workstation with the Remote Server Administration Tools (RSAT) installed, with sufficient permissions to create and/or modify group policies.
     
2. Start the Group Policy Management Console (GPMC) by either typing its name in the Start Menu or Start Screen, or by running gpmc.msc.
     
3. Either create a new Group Policy object and target it at the hosts you want to report on, or select an existing Group Policy object that already targets them. Right-click the Group Policy object and select Edit… from the context menu. This will launch the Group Policy Editor.
      
4. Navigate to Computer Configuration, Policies, Windows Settings, Security Settings and then expand the Windows Firewall with Advanced Security node twice.
       
5. Right-click Inbound Rules and select New Rule… from the context menu.
       
   
       
6. In the Rule Type screen, select Predefined as the rule type and select Windows Management Instrumentation (WMI) from the pull-down list. Click Next >.
       
7. In the Predefined Rules screen, select only the rule ending on (WMI-in) and click Next > to enable the three predefined WMI rules.
      
8. In the Action screen, select Allow the connection and click Finish. 
      
9. Now the rule will be present in the Inbound Rules node of Windows Firewall with Advanced Security. Modify the rule when you want these rules only to apply when the machine with VAMT on it connects, or when you only want this rule to apply to particular profiles (domain, private and/or public)
     
10. Close the Group Policy Editor when done.

Wait for the Group Policy Background Refresh Interval to update the Group Policies on each of the targeted domain members (by default this may take up to 120 minutes) or use the central Group Policy Update… command to trigger updating of Group Policy objects by right-clicking the targeted Organizational Units (OUs) and selecting this option from the context menu.

Configuring VAMT 3

With the Volume Activation Management Tool (VAMT) installed, it’s time to start it up for the first time and configure its basic settings:

1. Start the Volume Activation Management Tool by pressing Start and typing VAMT. Then, click the shortcut to the Volume Activation Management Tool in the results pane.
        
   
       
2. Since this is the first time the Volume Activation Management Tool (VAMT) is started it displays the Database Connection Settings screen. Specify database settings and then click Connect. If unsure what to specify as settings, simply specify .\ADK as Server:, <Create new database> as Database: and give the new database a meaningful name. (in the example above I named the database VAMT30.)
      
3. In the left pane of the Volume Activation Management Tool interface, right-click Products and select Discover products… from the context menu.
       
   
       
4. In the Discover Products screen, Search for computers in Active Directory is selected by default.
      
        Tip!
        The Volume Activation Management Tool does not offer an option to filter on
        Organizational Units. To make the computer name filter in the Volume Activation
        Management Tool work, implement a useful naming convention.
       
   Click Search when done.
       
5. When discovery completes, the Volume Activation Management Tool will display the number of machines it found. Click OK.
       
6. Select Products in the left pane of the Volume Activation Management Tool interface. In the list of products in the middle of the screen (multi)select the products you want to see the license status of. Right-click the selection and select Update license status and Current credential from the context menu.
        
   
       
7. Click Close when done.
     
8. In the Volume Activation Management Tool interface, now click the root node in the left pane. In the middle pane a license summary is shown:
      
     
   You can drill down in this summary.
       
   Exporting the summary is available in the right action pane.In the Volume Licensing Reports folder in the left pane, more advanced reports are available.    

Requirements

To use Active Directory-based Activation the following requirements need to be met:

• Active Directory-based Activation requires the Windows Server 2012 schema extensions. This means adprep.exe needs to have been run.
      
• Active Directory-based Activation requires a domain-joined Windows 8-based management workstation with the Windows Volume Activation Remote Server Administration Tools (RSAT) installed, or a domain-joined Windows Server
  2012-based management server.
  • When volume license reporting is needed, the management workstation/server needs to be installed with the Volume Activation Management Tool (VAMT) version 3.0 installed. VAMT should be run with credentials that have administrative permissions to the Active Directory domain and the KMS host Key should be added to VAMT in the Product Keys node.
  • When proxy activation is needed for isolated environments, the management workstation/server needs to be installed with the Volume Activation Management Tool (VAMT) version 3.0 installed. VAMT 3.0 is part of the Windows Assessment and Deployment Kit (ADK) for Windows 8. The management workstation/server will be the only machine that will need an Internet connection. Click here for instructions on setting up Proxy Activation for Active Directory-based activation.
        
         Note:
         VAMT 3.0 can be installed on Windows 7, Windows 8, Windows Server
         2008 R2 and Windows Server 2012, but requires PowerShell 3.0 and a
         connection to a SQL Server (Express) database.
         
• Active Directory-based Activation will not work for operating systems earlier than Windows Server 2012 or Windows 8. It also will not work with Microsoft Office 2010. Use KMS volume activation to activate Windows clients and applications that do not support Active Directory-based Activation.
     
• Supported clients will only communicate to (R/W) Domain Controllers. Activation through Read-only Domain Controllers is not possible. Make sure sufficient (R/W) Domain Controllers are available to clients in remote locations.

Concluding

Active Directory-based Activation offers a way to activate Windows, Windows Server and Office installation, integrated with the highly available infrastructure of Active Directory.

Many of the downsides of using Key Management Services have been eliminated, except for the requirement to connect to the Microsoft-hosted activation services and the requirement for clients to connect to the activation infrastructure at least every 180 days.

Active Directory-based Activation offers faster reporting on licensing, by making the most of the built-in filters of the Volume Activation Management Tool (VAMT).

Further reading

Active Directory-Based Activation Overview  
Test Lab Guide: Demonstrate Volume Activation Services 
Review Available Activation Models 
Volume Activation Overview  
Windows 8 Active Directory based volume activation 
Active Directory-based activation   
Windows 8 Active Directory based volume activation 
Introduction to VAMT 3.0 
Plan for Volume Activation, Step 1: Review and Select Activation Methods  

Related downloads

Volume Activation Management Tool (VAMT) 2.0   
Windows Assessment and Deployment Kit (ADK) for Windows 8

Ranging from multi-server management to over 2400 PowerShell Cmdlets, Windows Server 2012 delivers on the promise of standards-based management and automation capabilities.

Part of the new Domain Controller Promotion process is installing the Active Directory Domain Services role onto a stand-alone or member server. This activity needs to be completed before the new Active Directory Domain Services Configuration Wizard can be launched.

As part of the installation of a Server Role and/or Feature, on the Confirm installation selections screen of the Add Roles and Features Wizard an option is provided to Export configuration settings. The screenshot below shows this option as part of installing the Active Directory Domain Services role and its management features:

When you click this option, an XML-formatted file is generated, that contains all the choices made in the previous screens of the Add Roles and Features Wizard. This file is presented to you as DeploymentConfigTemplate.xml to save at a convenient file location.

Below is the DeploymentConfigTemplate.xml, containing the choices made when installing the Active Directory Domain Services role and its management features:

So, what can we do with this file?

The file can be used in two ways:

1. Install the same Server Role(s) and/or Feature(s) on another Windows Server by copying the file over to a (shared) file location and executing the following PowerShell one-liner on the console of the server:
       
        Install-WindowsFeature –ConfigurationFilePath
        D:\ConfigurationFiles\DeploymentConfigTemplate.xml
       
2. Install the same Server Role(s) and/or Feature(s) on (a group of) remote server(s) with the DeploymentConfigTemplate.xml in a local file location , using the following PowerShell one-liner:
       
        Install-WindowsFeature –ConfigurationFilePath 
        D:\ConfigurationFiles\ADCSConfigFile.xml -ComputerName $servername

Since installing the Active Directory Domain Services role and its management features does not require a restart, you could then start the New-ADDSForest, New-ADDSDomain or New-ADDSDomainController Cmdlets to promote the server to a Domain Controller for either a new forest, a Domain Controller for a new domain in an existing forest or as a new replica Domain Controller, respectively.

This way you can quickly configure new Domain Controllers.

Note:
While installing Server Role(s) and/or Feature(s) this way offers great flexibility and granularity, for simpler environments the following PowerShell one-liner might be of more use:
    
Install-WindowsFeature AD-Domain-Services 
-IncludeManagementTools

By the way: If you don’t want the management tools, simply leave the 
-IncludeManagementTools switch out.

Further reading

Install or Uninstall Roles, Role Services, or Features 
Install-WindowsFeature

If you want to remotely manage a Windows Server-based infrastructure  from a Windows-based workstation, you will need the Remote Server Administration Tools (RSAT). If you want to use Windows 8 to manage all the new Windows Server 2012 stuff remotely, you will need the Remote Server Administration Tools for Windows 8.

The Remote Server Administration Tools (RSAT) for both x86- and x64-based editions of Windows 8 include Server Manager, Microsoft Management Console (MMC) snap-ins, consoles, Windows PowerShell Cmdlets and providers, and command-line tools for managing roles and features that run on Windows Server 2012.

Note:
Although you will need the RSAT for Windows 8 to use this platform as a remote management solutions, there are some caveats in remotely managing server roles and features on Windows Server 2003 (R2) and Windows Server 2008 (R2) from Windows 8. These caveats are described in Microsoft KnowledgeBase article 2693643.

This blogpost describes enabling the Remote Tools you’d like to use, including the Hyper-V Tools, that are not part of the Remote Server Administration Tools (RSAT) package.

Installing RSAT

To install the Remote Server Administration Tools (RSAT) on Windows 8, follow these steps:

1. Download the Remote Server Administration Tools (RSAT) for Windows 8 package from the Microsoft Download Center. Choose the 96MB x86 package if you’re running the x86 (32bit) version of Windows 8. Choose the 102MB x64 package when you’re running the x64 (64bit) version of Windows 8.
       
        Tip!
        You can either run the installer from the Download Center website, or save
        the download package to a local computer or share.
       

2. If you save the download package to a local computer or share, double-click the installer program, Windows6.2-KB2693643-x64.msu or Windows6.2-KB2693643-x86.msu, depending on the architecture you chose in step 1.
         
   
       

3. When you are prompted by the Windows Update Standalone Installer dialog box to install the update, click Yes.
       
   
        

4. Read and accept the license terms. Click I Accept. The update will now begin installing.
          
   
       

5. Installation requires a few minutes to finish. Click Close when done.

Removing unused Remote Tools

In contrast to the Remote Server Administration Tools (RSAT) for previous versions of Windows, the Remote Server Administration Tools (RSAT) for Windows 8, by default, enable all the Remote Tools. So, where in previous versions you would install the Remote Tools you’d like to use, in Windows 8 you would get them all.

However, if you want to remove Remote Tools you’re unlikely to use since they don’t apply to your environment or your job description, you can remove them, in the following steps:
       

1. Press Win+W and start searching for Turn Window Features on or off. It should show up as a search result. Click it or press Enter when it’s the only search result left.

2. In the list of available Windows Features, scroll down to Remote Server Administration Tools. 
       
       

3. As you can see in the screenshot above, all the Remote Tools have been turned on. By deselecting Remote Tools you don’t want to use, you disable them. Click OK when done.  

4. In the Windows completed the requested changes screen press Close.

Installing the Hyper-V Tools

As you scroll through the Remote Tools in the Remote Server Administration Tools (RSAT) package you might begin to wonder what happened to the Hyper-V Remote Management Tools.

Hyper-V Remote Management Tools are not part of the Remote Server Administration Tools (RSAT) for Windows 8. The justification is really simple: Hyper-V Management Tools are already part of the Operating System, since Hyper-V is now also available in the Operating System.

Perform these steps to install the Hyper-V Tools:

1. Press Win+W and start searching for Turn Window Features on or off. It should show up as a search result. Click it or press Enter when it’s the only search result left.

2. In the list of available Windows Features, scroll down to Hyper-V.

3. Expand Hyper-V and select the Hyper-V Management Tools (both the MMC Snap-In and the hyper- PowerShell module):
       
       

4. Click OK when done.

5. In the Windows completed the requested changes screen press Close.

Concluding

Enabling the Remote Server Administration Tools in Windows 8 has become easier and faster than it was in earlier versions of Windows. If you’re simply looking for the Hyper-V Tools, don’t bother downloading and installing the Remote Server Administration Tools; the Hyper-V Tools are already part of Windows 8.

Download

Remote Server Administration Tools for Windows 8   

Further reading

Description of Remote Server Administration Tools for Windows 8  
Remote Server Administration Tools for Vista, 7, 8, Server 2008, 2008 R2, and 2012   
Remote Server Admin Tools (RSAT) for Windows 8 are out NOW!!! 
Remote Server Administration Tools (RSAT) for Windows 8 - now available for download   
Manage Windows Server 2012 Remotely with RSAT tools for Windows 8 RTM   
Ars Technica: RTM RSAT for Windows 8 download. 
Remote Server Administration Tools (RSAT) available for Windows 8! 
Die RSAT für Windows 8 sind da 
RSAT für Windows 8 verfügbar 
Remoteserver-Verwaltungstools (RSAT) für Windows 8 verfügbar 
Remote Server Administration Tools for Windows 8  
Remote Server Admin Tools for Windows 8 
Microsoft's RSAT 2012 is out   
Microsoft Releases Remote Server Admin Tools for Windows 8 Preview

With all the fancy features in Active Directory, I almost tend to forget it was originally an x.500 directory services, offering LDAP connectivity. Although today this is less evident, LDAP is intensively used under the hood for directory connectivity. Alongside the older RPC-based protocols it is used for over 90% of the communication to the Active Directory database. (Notable exceptions are password resets)

Below is an architectural view of Active Directory client/server communication, showing LDAP as the linking pin:

What’s New

Microsoft has enhanced the LDAP implementation in Active Directory Domain Services for Windows Server 2012.

Enhanced LDAP Logging

Logging is useful for troubleshooting. Active Directory admins can enable logging on Active Directory in the registry through Active Directory Diagnostic Event Logging. This is strong stuff, but it is also exactly what you’re craving for in these kinds of situations.

As Microsoft KnowledgeBase article 314980 explains, you can turn on any of the Active Directory Diagnostic Logging categories, available in the registry in the following location:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Specifically, Microsoft has worked to enhance the LDAP logging of level 5 of the 16 LDAP Interface Events registry DWORD value.

Enabling LDAP logging

To enable LDAP logging, perform the following steps:

1. Start the Registry Editor by running regedit.exe.
2. Locate and click the following registry key:
       
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
       
3. In the right pane of the Registry Editor, double-click the 16 LDAP Interface Events.
       
   
       
4. Type 5 as the logging level in the Value data box, and then click OK.
5. Close the Registry Editor

This will record all events, including debug strings and configuration changes to the Directory Services log of Event Viewer.

Enhancements

Many admins have given Microsoft precise feedback on scenarios where LDAP logging was getting them nowhere, since they were unable to isolate and/or diagnose root causes of many behaviors/failures with the existing logging capabilities.

In Windows Server 2012, Active Directory Diagnostic Event Logging has been enhanced with additional logging that logs entry and exit stats for a given API. The entries themselves now log the operation name, the SID of the caller’s context, the client IP, entry tick and client ID.

New LDAP Controls

The LDAP standard was designed with extensibility in mind. The standard allows the behavior of any operation to be modified through the use of controls. In addition to the repertoire of predefined operations, such as "search" and "modify," the LDAP v3 defines an extended operation. The pair of extended operation request/response is called an extension.

Microsoft has introduced seven new controls in LDAP for Active Directory Domain Services in Windows Server 2012:

Batched extended-LDAP operations
(1.2.840.113556.1.4.2212)

This new LDAP Control modifies the default behavior to treat all operations within a given batch as a single transaction. When using this control, all operations in the batch will fail or all will succeed. This new control is particularly useful for programmatic schema extensions since the entire list of updates could be treated as a batch.

Require server-sorted search use index on sort attribute (1.2.840.113556.1.4.2207)

This LDAP control eliminates the need for tempTable when performing sorted search, thereby increasing scale possibilities. It is particularly good for large result sets because, in the past, sorted searches would have simply failed.

DirSync_EX_Control (1.2.840.113556.1.4.2090)

This LDAP control alters the traditional DirSync behavior and forces the return of specified unchanged attributes.

TreeDelete control with batch size (1.2.840.113556.1.4.2204)

In Windows Server 2008 R2 and earlier, the LDAP batch size is hard-coded with a limit of 16K. This new LDAP control, exposes a mechanism to lower this hard-coded default allowing the delete operation to declare its own batch size. This ensures deletions do not slow convergence beyond system tolerance.

Include ties in server-sorted search results (1.2.840.113556.1.4.2210)

This LDAP Control, also referred to as the “soft size limit”, returns additional data on ties when performing sorted searches. Within the context of a sorted search, two objects are considered “tied” if their attribute values for the sorted attribute are the same, i.e. the objects are tied by virtue of the common value in the sort attribute (same place in the index).

Using this LDAP control admins can page between sorted search results with large results sets, with a soft size limit, to limit the page-size and ensuring requests are distributed across Domain Controllers, instead of being targeted at one single Domain Controller, because it is the only Domain Controller that knows where pages begin and end.

Return highest change stamp applied as part of an update (1.2.840.113556.1.4.2205)

This LDAP control is similar to searchStats control in that when checked in, it causes the result to contain additional data. This data is the invocationID and highest USN allocated during the transaction (in BER encoded format).

This LDAP control is useful for programmatically determining convergence between any two instances, immediately following an update.

Expected entry count (1.2.840.113556.1.4.2211)

This LDAP control requires a minimum and maximum value. This control is useful for uniqueness, in-use and/or absence checking. Of course, this new LDAP Control is very powerful when combined with the new Batched extended-LDAP operations LDAP Control.

Concluding

Microsoft has made several improvements in an essential protocol: LDAP.

When you’re having trouble and need adequate logging capabilities, Windows Server 2012 has got your back. Also, if you’re involved with Active Directory Domain Services from a software developer or ISV point of view, the new LDAP controls might make your work a lot easier. No doubt, Microsoft will try and use the new LDAP controls when they develop new Active Directory solutions and new ways to perform management tasks in the next version of Windows Server.

Further reading

A list of LDAP Extended Controls 
LDAP_SERVER_DIRSYNC_EX_OID  
LDAP_SERVER_UPDATE_STATS_OID 
LDAP_SERVER_TREE_DELETE_EX_OID 
LDAP_SERVER_SEARCH_HINTS_OID 
LDAP_SERVER_EXPECTED_ENTRY_COUNT_OID 
LDAP_SERVER_POLICY_HINTS_OID

Previously in this series we covered the challenges surrounding RID Depletion in Active Directory. This time around, let’s talk about DNTs.

About DNTs

Distinguished Name Tags (DNTs) are integer columns, maintained by the Extensible Storage Engine (ESE) within the Active Directory Database (ntds.dit). Domain Controllers use DNTs when they create objects, either locally or through replication. Each Domain Controller creates and maintains its own unique DNTs within its database when it creates objects. DNTs don’t get re-used. DNTs are not shared or replicated between Domain Controllers. Instead, what gets replicated are the computed values known by Domain Controllers, such as SIDS, GUIDs and DNs.

The DNT Challenge

In its lifetime a Domain Controller is limited to creating a maximum of approximately 2 billion DNTs over its lifespan. To be exact, a maximum of 2³¹-255 DNTs can be created. This amounts to 2,147,483,393 DNTs. Since DNTs don’t get re-used, re-claimed  or re-serialized, a Domain Controller faces its end when it reaches this limit. Since Windows Server 2012, this limit is suddenly in sight, since the maximum amount of RIDs can now also grow to this limit.

When a Domain Controller hits the limit of maximum DNTs, the Domain Controller needs to be demoted and re-promoted “over the wire”. 

Note:
Domain Controllers that are installed with the Install from Media (IfM) option inherit the DNT values from the domain controller that was used to create the IFM backup.

Note:
Domain Controller Cloning under the hood uses Install from Media (IfM)

To expand the DNT Challenge, it is hard in Windows Server to see the amount of DNTs created. IT’s do-able, but it requires dumping the database or programmatically interrogate the database. These options are time consuming and impact performance and disk space.

What’s New

In Windows Server 2012, Active Directory admins can more easily see the amount of DNTs created and face the DNT Challenge.

Investigating used DNTs

In Windows Server 2012, you can investigate the amount of DNTs created through the built-in Performance Monitor. Follow these steps:

1. Open Performance Monitor by running perfmon.exe.
     
2. In the left pane expand Data Collector Sets.
       
3. Right-click User Defined and select New… and Data Collector Set from the context menu.
     
4. Give the data collector set a useful name and then select Create manually (Advanced) before clicking Next.
       
5. Select to Create data logs and also select Performance counter. Click Next.
     
6. Press the Add… button.
   
7. In the left pane select NTDS and then select only the Approximate Highest DNT. Then click Add >> and OK.
      
        Tip!
        By default the <localhost> is selected in Performance Monitor. Of course, you
        could use one Data Collector Set to get the amounts of DNTs created on all
        Domain Controllers in the environment.
     
8. Select an interval (for instance: every 24 hours) and click Finish.
     
9. In the left pane of Performance Monitor, right-click your newly created Data Collector Set and choose Start from the context menu.
      
10. Now, every time you want to know the amount of DNTs created on the Domain Controller, open Performance Monitor, in the left pane expand Reports, then expand User Defined and click on the name of the Data Collector Set. In the right pane, now select a report to view.

Concluding

Having an easy way to query and monitor the number of DNTs created per Domain Controller is useful, since we can now have more RIDs than DNTs in Windows Server 2012.

Further reading

How can I determine my current DNT?  
Active Directory Maximum Limits – Scalability   
ExpertGlossary: Distinguished Name Tag (DNT) 
[ActiveDir] DNTs and Replication

With Windows 7 and Windows Server 2008 R2 Microsoft introduced a new Active Directory feature called Offline Domain Join (ODJ). This feature allows for clients to be joined to an Active Directory domain, without the need of having a direct connection to any of the Domain Controllers for the Active Directory domain.

Scenarios

Offline Domain Joins use useful when you want to join a computer to an Active Directory infrastructure without the need for direct communication between the client and a Domain Controller. These include:

• Deploying vast amounts of computers, without straining Domain Controllers in terms of bandwidth and processing, which might affect existing domain-joined computers. Also, in this scenario Offline Domain Join saves time.
• Deploying domain-joined computers to a branch office site where only Read-only Domain Controllers reside. (Read-only Domain Controllers are not suitable for clients joining the domain)
• Deploying domain-joined computers to users in remote locations (like homes) that from time to time require access to resources in an Active Directory environment and may not have a high enough quality connection to the Domain Controllers.

Although Offline Domain Join can be used to join computers to a domain without a direct connection to an Active Directory infrastructure, at one point a domain-joined computer needs to connect to a Domain Controller on a regular basis to stay a part of the Active Directory infrastructure. (unless you want to spend the rest of the lifetime of the domain-joined computer feeding it offline domain join information…)

What’s New

Offline Domain Join has been extended by allowing the blob to accommodate Direct Access prerequisites:

• Root Certificates
• Certificates
• Group Policies

This means the number of scenarios increase. One of the main scenarios that now gets included is deploying domain-joined computers to DirectAccess users. The clients now have everything they need to successfully connect to the DirectAccess server(s).

Note:
A Graphical User Interface to perform Offline Domain Joins is not part of the improvements to Offline Domain Join in Windows 8 or Windows Server 2012.

Performing Offline Domain Joins

Let’s look at the individual steps of the process:

Step 1

To kick off the Offline Domain Join an administrator would logon to the Windows Server 2012-based Domain Controller. When logged on with an account with sufficient permission and quota to create Computer Accounts, the administrator would provision the client on the Domain Controller itself with the following command:

djoin.exe /PROVISION /DOMAIN DomainName /MACHINE MachineName /SAVEFILE FileLocation

Here’s an example:

djoin.exe /PROVISION /DOMAIN domain.local /MACHINE Win8-2
/SAVEFILE C:\ODJBlobs\Win8-2.b64

Now, In situations where you’d want to include Root Certificates, Certificates or Group Policies in the blob, extend the command above with the following extra switches:

Include root certificates	/RootCACerts
Include certificate templates (includes their root certificates)	/CertTemplate
Include Group Policies	/PolicyNames

An example of such a command would be:

djoin.exe /PROVISION /DOMAIN domain.local /MACHINE Win8-3
/POLICYNAMES CompanyLookAndFeel
/SAVEFILE C:\ODJBlobs\Win8-3.b64

Step 2

This command, when successful, creates the in the location specified. This file, which can be given any file extension is a Base64-encoded file, containing all the necessary information for a Windows 7 client to join the Active Directory domain.

When you open the file and pull it through a base64-decoder (like this one) the contents of the file become clear.

Inside the blob

Let’s take a look at the Offline Domain Join blob we created in step 1 for Win803 in the domain.local domain:

This file doesn’t really provide any insight into how Offline Domain Join works its magic, but as mentioned earlier, the Offline Domain Join (ODJ) blob is a base64 encoded file. This means we can put it through a Base64 decoder like this one, or convert it using one of the many online base64 decoders. This will result in outcome similar to the text file below:

As you can clearly see, the decoded file contains the information you’d suspect a client needs to join the domain. The decoded file contains the DNS domain name (domain.local), the workstation NetBIOS name (Win8-02), the computer password, the NetBIOS domain name (DOMAIN), the name of the Domain Controller (DC01.domain.local), it’s IPv4 address (10.8.255.1) and the Active Directory site. (Default-First-Site-Name). Also, it includes the policy settings in the CompanyLookAndFeel Group Policy.

The nature of the decoded file, also warrants the security note placed in the Offline Domain Join (Djoin.exe) Step-by-Step Guide:

The base64-encoded metadata blob that is created by the provisioning command contains very sensitive data. It should be treated just as securely as a plaintext password. The blob contains the machine account password and other information about the domain, including the domain name, the name of a domain controller, the security ID (SID) of the domain, and so on. If the blob is being transported physically or over the network, care must be taken to transport it securely.

  

Step 3

After the Offline Domain Join blob gets transferred to the would-be client, a local administrator can join the computer to the domain in an offline fashion by typing the following command in an (elevated) command prompt:

djoin.exe /REQUESTODJ /LOADFILE FileLocation /WINDOWSPATH WindowsPath /LOCALOS

As an example, here’s the command for Win8-03:

djoin.exe /REQUESTODJ /LOADFILE C:\Win8-03.b64
/WINDOWSPATH C:\Windows /LOCALOS

Note:
Alternatively, you can include the Offline Domain Join blob in an unattend.xml file.

After the client successfully works through the command, the would-be client reboots as a member of the Active Directory domain. On first contact between the client and the Active Directory domain, the client would reset its Computer Account password.

Requirements

Operating system requirements

Offline Domain Join requires Djoin.exe. This command is available on domain-joinable editions of Windows 7 (Professional, Ultimate, Enterprise), domain-joinable editions of Windows 8 (Professional, Enterprise), Windows Server 2008 R2 and Windows Server 2012.

Note:
When you want to include root certificates, certificate templates and group policies, you will need to run djoin.exe on Windows 8 or Windows Server 2012.

If you want to use djoin.exe with Windows Server 2008-based Domain Controllers, use the /downlevel switch when you provisioning.

credential requirements

The djoin.exe command needs to be run by a user account with sufficient permissions to create computer accounts. By default, members of the Domain Admins group can create computer accounts. The user right to Add workstations to the domain can be set using Group Policy, or can be granularly delegated using Active Directory Delegation of Control.

Concluding

Offline Domain Join (ODJ) already was a nice feature in Windows 7 and Windows Server 2008 R2, but in Windows 8 and Windows Server 2012 this feature really proves its worth with the ability to offline provision DirectAccess clients with certificates and group policies.

Further reading

Offline Domain Join (Djoin.exe) Step-by-Step Guide (Online version)
What's New in AD DS: Offline Domain Join
Windows 2008R2 features part I: Offline domain join
Windows 2008R2 features part I: Offline domain join
How do I perform an offline domain join in Windows Server 2008 R2 ?
Windows Server 2008 R2: Offline Domain Join Step-by-Step Guide
Requirements when Joining a Domain
Domain Users Cannot Join Workstation or Server to a Domain
Will Windows 7’s “offline domain join” finally rid us of all the third party “fast sysprep” functions? No :(

Windows 8 and Windows Server 2012 offer a lot of new functionality. Of course, a lot of this functionality can be centrally managed with Active Directory through Group Policy.

But how do you find the Group Policy settings that are new to these two Operating Systems? How do you find that specific Group Policy setting you need to accomplish your task in the big pile of 4500+ available Group Policies? And how do you know which admx file you need to troubleshoot those pesky "”Display names for some settings cannot be found." errors?

In this blog post I’ll provide you with three ways to get started with the new Group Policy settings in Windows 8 and Windows Server 2012 and along the way provide you some tips and tricks on the above three challenges.

Note:
None of these ways are new to Windows 8 or Windows Server 2012.

1. Use Group Policy Settings Filtering

With the Group Policy Management Console (GPMC) in Windows Server 2012 or in the Remote Server Administration Tools (RSAT) in Windows 8, functionality exists to filter the Group Policy settings under Administrative Templates. Since this is where the bulk of the settings you’d use are located, this is useful functionality.

To use the Group Policy Settings Filtering, follow these steps:

1. Open the Group Policy Management Console (GPMC)
       
2. Edit a Group Policy by right-clicking one and selecting Edit… from the context menu.
     
3. Expand either the Policies node under Computer Configuration or the Policies node under User Configuration. Right-click the Administrative Templates node or any node underneath it. Select Filter Options….
       
   
       
4. In the Filter Options compose the filter you’d want to use. You may include the state of a Group Policy setting (Managed, Configured and/or Commented), you can enable keyword filters to search for specific strings of text in either the Policy Setting Title, the Help Text and/or the Comment and you can filter on requirements to filter out Windows 8, as an example. When done, click OK.
     
5. To apply the filter, again, right-click on any node under the Administrative Templates, or the Administrative Templates node itself, and select Filter On.
   

In any node underneath the Administrative Templates node it will now only show the policies within the filter.     

Tip!
Viewing the contents of the All Settings node with the Filter On is particularly useful, if you’re looking for that one setting.

2. Use the Group Policy Reference

Microsoft shares thorough documentation of its built-in Group Policy settings. This documentation is available as a free download from Microsoft and comes in the form of Excel documents. The documents can be found here. One of the documents is called WindowsServer2012andWindows8GroupPolicySettings.xlsx. That’s the Excel document describing the Group Policy Settings for Windows Server 2012 and Windows 8.

Using the functionality of Microsoft Office Excel, certain Group Policy settings can be filtered out, by using the filter options of the columns of the document. Particularly useful columns to filter on, are:

• Reboot Required
  A "Yes" in this column means that the Windows operating systems requires a restart before it applies the described policy setting. This way, the impact of a settings change can be determined in an early stage.
  
• Logoff Required
  A "Yes" in this column means that the Windows operating system requires the user to log off and log on again before it applies the described policy setting.
      
• Active Directory Schema or Domain Requirements
  A "Yes" in this column means that you must extend the Active Directory schema before you can deploy this policy setting.
  
• Status
  A "New" in this column means that the setting did not exist prior to Windows Server 2012 and Windows 8. It does not mean that the setting applies only to Windows Server 2012 and Windows 8. Refer to the column entitled "supported on" to determine to which operating system the policy setting applies.

Also, using Ctrl+F allows you to quickly search the entire document for a certain text.

The main difference between using the Group Policy Reference and the Group Policy Settings Filtering functionality, is that the Reference will give you far more information and will even tell you which *.admx file contains a particular setting. On the other hand, using Ctrl+F will return you every occurrence of the text, whether it is in the Registry Value, *.admx name or in the setting title. Also, the Reference contains the Group Policy settings under the Security Options node, not just the settings from Administrative Templates.

However, when you’re using *.admx files to manage settings in other Microsoft products (like Office) or third party products (like FireFox or Chrome), you’d be better off using the Group Policy Settings Filtering functionality.

3. Use the Group Policy Search website

If your main problem with Group Policy settings is with the hierarchy of Group Policy Settings, then a third solution would be helpful to you. Also, when you don’t want to fiddle around with Microsoft Office, this is good solution.

This solution is the Group Policy Search (GPS) website at gps.cloudapp.net. This website features a more intuitive Policy Tree in the left navigation pane, including the many Group Policy settings from the Microsoft Office Administrative Templates. Alternatively you can use the Registry Tree, to find the Group Policy settings controlling a certain Registry value.

Within the website, just like the previous two solutions, you can filter. Available filters are for supported browsers and Operating Systems (OSs), but also on Machine Policy Settings Only and User Policy Settings Only.

When your job is to communicate and document the Group Policy settings in use in your organization, then you’d also love the Copy menu in the website. It allows for easy copying and sharing of information on a particular Group Policy setting (although it doesn’t come with keyboard shortcuts at the moment). 

Concluding

While Group Policy, at first, may seem overwhelming, using the combination of the above three tools will make it easy to accomplish the tasks you’d want to achieve with Group Policy.

Downloads

Group Policy Settings Reference for Windows and Windows Server

Further Reading

Group Policy Settings Reference for Windows 8 and Windows Server 2012 
Windows 8 Group Policy Reference 
Download Group Policy Settings Reference 
Out Now: Windows 8 and 2012 Group Policy Reference Spread sheet 
Updated Group Policy Settings Reference for Windows Server 2012 and Windows 8 
Group Policy Settings Reference for Windows and Windows Server Excel Spreadsheets 
Updated Group Policy Settings Reference for Windows Server 2012 and Windows 8  
Server 2012 and Windows 8 Group Policy Reference released  
Group Policy Settings Reference for Windows 8 and Windows Server 2012 
Group Policy Settings Reference for Windows 8 (RTM) and Windows Server 2012 (RTM) 
Group Policy Settings Reference for Windows 8 and Windows Server 2012 
New Group Policy Settings Reference for Windows and Windows Server 
Microsoft released group policy settings reference for Windows 8 and Windows Server 
Windows Server 2012 and Windows 8 Group Policy Settings doc 
Server 2012 and Windows 8 Group Policy Reference released 
Gruppenrichlinien Referenzen als Download nun auch für Windows 8 vefügbar

For the last years, we’ve been modeling the business into group memberships and their associated access control lists. For some organizations this has even led to changing the way they performed business from before they automated their business processes. For other organizations, this has resulted in token bloat. It’s time someone changed that and introduced business logic for file and folder access.

What’s New

Microsoft did exactly that by introducing Dynamic Access Control (DAC).

Dynamic Access Control can best be described as a Claims-based Access Control (CBAC) solution, where claims are placed in tokens. In contrast, Active Directory Federation Services (AD FS), also uses claims, but uses SAML as its protocol for markup and transport. Dynamic Access Control claims are stored in the Ticket Granting Ticket (TGT).

Note:
To use Dynamic Access Control you don’t need to install or configure Active Directory Federation Services.

Claims within Dynamic Access Control can be based on any attribute of a user account, Claims can also be based on attributes for computer accounts, but this requires Kerberos Armoring (FAST). When user claims and device claims are combined, this forms the Compound Identity (Compound ID).

Dynamic Access Control information is stored in Active Directory in CN=Claims Configuration,CN=Services,CN=Configuration,DC=domain,DC=tld and is replicated throughout the Active Directory forest.

To use Dynamic Access Control claims to authorize access to files, two methods can be used:

1. You can define authorization rules and authorization policies within Active Directory, where you can define the proposed and/or enforced rights on files and folders and the scope of the rules. Authorization rules also extend to file classification infrastructure (FCI) this way, so you can even base access rights on user-picked tags for files and folders on a scoped number of File Servers.
2. The second method is to incorporate claims within access control entries (ACEs) straight into access control lists (ACLs). This is useful for file storage locations that are based on the Resilient File System (ReFS), since this new file system does not support authorization policies (yet).

Arguably, using claims adds complexity when added to an access strategy based on group memberships. Another new feature in Windows Server 2012 helps keep track of access denied. The feature, called Access-denied remediation, enables users, when faced with an Access Denied error, to specify why they think they should be allowed access. This fully customizable message, together with the reason why access was denied is then sent to the Admin responsible for the file server (as defined in File Server Resource Manager). Access Denied Remediation is only available when using SMB 3.0, so, this feature is only available when Windows 8 clients and Windows Server 2012 member servers access Windows Server 2012 File Servers.

Configuring DAC

Example case

In this example we’ll use File Classification with Dynamic Access Control to authorize the Engineering department to read files and folders of their department. Their managers can modify these files, but only when they try this from computers, designated as computers in the Engineering department.

Step 1

First, we start by creating File Classifications. We perform this action in the Active Directory Administrative Center (ADAC), since these classifications are stored in Active Directory. In the Active Directory Administrative Center, file classifications can be found in the Dynamic Access Control node on the left pane. The screenshot below shows the Dynamic Access Control (DAC) node in Folder View in the Active Directory Administrative Center:

Define Resource Properties

Our first step is to define Resource Properties. For this, open the Resource Properties node underneath the Dynamic Access Control node. You’ll notice Microsoft has equipped us with a lot of pre-defined resource properties, so let’s use the Department one. Right-click it and select Enable from the context menu:

Tip!
You can enable multiple pre-defined resource properties and even create your own. A perfect example would be Country, which is not pre-defined.

Add Resource Properties to the Property List

When you’ve enabled the resource properties you’d want to use, add them to a Resource Property list. In the left pane of the Active Directory Administrative Center right-click Resource Property Lists underneath the Dynamic Access Control node and select New and then Resource Property List from the context menu.

For our example environment we will name this Resource Property List Engineering and we add the Department resource property to it by using the Add… button. OK saves our settings.

Update the Resource Property Lists on the file servers

On the Windows Server 2012-based File Servers, run the Update-FSRMClassificationPropertyDefinition PowerShell command.

Classify files and folders

Now, in the File Explorer on the File Servers classify folders and files. Use the Classification tab to specify Classification. In our example we’ll classify the Engineering folder as Engineering data. Navigate towards the folder you’d want to classify, right-click it and then select Properties from the context menu. Go to the Classification tab:

Since the Department Resource Property is the only enabled Resource Property it will be the only Resource Property available to the File Server(s). To use it, click it. Then, in the Value box, select Engineering. Press OK when done.

Step 2

Now that we’ve put the built-in File Classification Infrastructure (FCI) to good use, it’s time to define our authorization decisions based on the classifications.

Define Central Access Rules

Back into the Active Directory Administrative Center (ADAC), we now open the Central Access Rules node underneath the Dynamic Access Control node in the left pane. By default, this node is empty, so we’re making our own Central Access Rule.

Right-click Central Access Rules, select New and then select Central Access Rule from the context-menu:

We’ll call the Access Rule Engineering Access. As targets we’ll target all files classified with the Engineering department through the Edit… button in the Target Resources area. As Permissions we choose to Use following permissions as current permissions. We then add Permissions with the Edit… button in the Permissions area. While in the Advanced Security Settings for Permissions screen, click Add.

In the Permission Entry for Permissions screen, at the top, we select the Authenticated Users as the Security Principal filter. Then, we create a condition with the business logic behind the access for Engineers. Members of the Engineers group get read access to Files and Folders (resources), classified as Engineering. The above screenshot shows these choices.

Of course, for the members of the Engineering Managers group, we build a second Central Access Rule, where we grant them Modify rights, based on their Engineering Managers group membership and based on the department of their device.

Note:
Since we’re basing authorization decisions on computer objects with the Engineering department attribute, make sure the right computers have this attribute configured.

Add Rules to a Central Access Policy

With the rule set in place, we can now create the Central Access Policy (CAP) that will utilize the rule set to make authorization decisions with a defined scope.

In the Active Directory Administrative Center (ADAC), we now open the Central Access Policies node underneath the Dynamic Access Control node in the left pane. By default, this node is empty, so we’re making our own Central Access Policy. Right-click the Central Access Policies node, select New and then Central Access Policy from the context menu.

In our example environment, we’ll name the Central Access Policy Engineering AuthZ and with the Add… button in the Member Central Access Rules area we add the Engineering Access Central Access Rule.

Deploy the CAP to File Servers using Group Policy

Using Group Policy we will now be scoping the Central Access Policy. Open the Group Policy Management Console (GPMC) and navigate to the Organization Unit (OU) containing the File Servers with Engineering data on them. Right-click the Organizational Unit and choose Create a GPO in this domain and Link it here…. In our example environment, we’ll name the new Group Policy Engineering Access. Now, right-click the newly created Group Policy and select Edit… from the context menu.

In the Group Policy Management Editor, in the left pane, navigate to Computer Configuration, Policies, Windows Settings, Security Settings, File System and then right-click Central Access Policy to select Manage Central Access Policies… from the context menu.

Select the Engineering AuthZ Central Access Policy from the list on the left and click the Add > button to make it appear in the list on the right. When done, click OK.

Now you can close the Group Policy Management Editor. To update the Group Policies on the File Server, either wait for the Group Policy Background Refresh Interval, run gpupdate.exe on the console of the File Server, or force a Group Policy Refresh from the Group Policy Management Console.

Tip!
Remote Group Policy Refresh is a new feature in the Group Policy Management Console (GPMC) that is part of Windows Server 2012 and part of the Remote Server Administration Tools (RSAT) for Windows 8.

Select the CAP to apply

When the Group Policy has applied, you can apply the Central Access Policy to the Engineering folder. Right-click the Engineering folder and select Properties. Click on the Security tab and then click on Advanced. In the Advanced Security Settings for Engineering screen, navigate to the Central Policy tab. On this tab, select the Engineering AuthZ as the Central Access Policy to apply. Click OK three times.

Requirements

Windows Server 2012-based Domain Controllers

Dynamic Access Control requires at least one Windows Server 2012-based Domain Controller. File Servers, where you want to use claims-based access control, also need to be running Windows Server 2012.

Tip! 
Certain Storage Area Network (SAN) manufacturers are working closely with Microsoft to enable their equipment for claims-based access control and Dynamic Access Control.

Make sure sufficient Windows Server 2012-based Domain Controllers are present to process client requests.

Note:
When Compound ID is used, Windows 8-based clients will only communicate with Windows Server 2012-based Domain Controllers. Compound ID is only available in Windows 8, not in previous versions of Windows.
    

Forest Functional Level

The Forest Functional Level needs to be Windows Server 2003.

Windows Server 2012-based File Servers

File Servers, where you want to use claims-based access control, also need to be running Windows Server 2012. On these servers the File Server Resource Manager Server Role needs to be installed. The following PowerShell one-liner can be used for this purpose:

Install-WindowsFeature FS-Resource-Manager
-IncludeManagementTools

Since Dynamic Access Control uses Group Policies to manage File Servers it’s a good idea to create a separate Organization Unit (OU) for File Servers as part of your Windows Server 2012 Active Directory design.

Backward compatibility

Dynamic Access Control works with previous versions of Windows as DAC clients. Windows 7 and Windows Server 2008 R2 have been thoroughly tested.

Concluding

Dynamic Access Control allows for rich authorization stories, based on not just group membership, but also attributes of the user account and computer account, applied to files and folders, but also applicable through classification. This way, even when a file is copied to an inappropriate location, it will still only be available for the right users within the environment.

With Dynamic Access Control, Active Directory Admins can work together with File Server admins to, finally, make authorization work as part of the business (instead of the other way around).

Related Posts

Active Directory and the Resilient File System (ReFS)   
New features in ADDS in Windows Server 2012, Part 11: Kerberos Armoring (FAST) 

Videos

An Overview of Dynamic Access Control   
Dynamic Access Control Deep Dive  
Dynamic Access control Best Practices and Microsoft IT Case Studies 
Keeping your Data Safe, and Introduction to Information Protection Technology  
Using classification for access control and compliance

Further reading

The Dynamic Access Control Knowledge Base  
Introduction to Windows Server 2012 Dynamic Access Control 
First Look at Dynamic Access Control in Windows Server 2012 
Windows Server 2012 Dynamic Access Control – The power of “And…”    
Dynamic Access Control: Scenario Overview 
Dynamic Access Control intro on Windows Server blog 
New in Windows Server 2012 – Part 3: Security 
Dynamic Access Control in Windows Server 2012 demo 
Diving deeper into Windows Server 2012 Dynamic Access Control

The new Domain Controller Promotion process in Windows Server 2012 with the Active Directory Domain Services Configuration Wizard, is a nice new way to promote Windows Server 2012-based hosts to Domain Controllers, since it enables:

• Remote promotion of Windows Server 2012-based hosts to Domain Controllers
• Promotion of a group of Windows Server 2012-based hosts to Domain Controllers at once from a single wizard

Alongside the Active Directory Domain Services Configuration Wizard, Microsoft introduced three new Active Directory PowerShell Cmdlets to promote Windows Server 2012-based hosts to Domain Controllers:

• New-ADDSForest
• New-ADDSDomain
• New-ADDSDomainController

These PowerShell Cmdlets each cover one of three Promotion scenarios. They offer a couple of options, not available in the Active Directory Domain Services Configuration Wizard. You might want to use these options, though. This blogpost lists them.

No automatic reboot on completion

There is no option in the Graphical User Interface (GUI) of the Active Directory Domain Services Configuration Wizard to delay rebooting when the promotion was completed.

In the Active Directory PowerShell Cmdlets, it’s easy to turn of the automatic reboot upon completion of the promotion.

Simply add the -NoRebootOnCompletion:$true switch to your Domain Controller promotion one-liner.

Windows Server 2012 DFL for new Tree

A bug exists that prevents Active Directory admins from choosing a Domain Functional Level (DFL) different than Windows Server 2012 when they add a new domain tree to an existing forest.

Of course, with PowerShell, you can select any Domain Functional Level you want as long as it’s a supported level.

As an example, here is a PowerShell one-liner that will create an Active Directory domain tree, called domain2.local with the Windows Server 2008 R2 Domain Functional Level in the Location1 site of the domain.local forest, equipped with both the DNS Server and the Global Catalog role:

Install-ADDSDomain -NoGlobalCatalog:$false
-CreateDnsDelegation:$false -Credential (Get-Credential)
-DatabasePath "E:\Windows\NTDS" -DomainMode "Win2008R2"
-DomainType "TreeDomain" -InstallDns:$true
-LogPath "F:\Windows\NTDS" -NewDomainName "domain2.local"
-NewDomainNetbiosName "DOMAIN" -ParentDomainName "domain.local" -NoRebootOnCompletion:$false -SiteName "Default-First-Site-Name"
-SysvolPath "F:\Windows\SYSVOL" -Force:$true

I’m sure you can modify this PowerShell one-liner to your needs.

Related posts

New features in ADDS in Windows Server 2012, Part 2: New Promotion Process    
You can only set the DFL to Windows Server 2012 when you create a new domain tree on a Windows Server 2012-based computer

Recently, Microsoft released KnowledgeBase article 2743367 with the ominous title Adprep "not a valid Win32 application" error on Windows Server 2003, 64-bit version.

When you’ve been reading this blog, you might have already guessed what might be causing this issue, even though adprep.exe on the Windows Server 2012 DVD is a perfectly fine Windows 64bit application.

In Windows Server 2012, Active Directory Domain Services features a new upgrade process. I’ve detailed this new process in detail in the blog post titled New features in Active Directory Domain Services in Windows Server 2012, Part 3: New Upgrade Process last month.

Basically, this upgrade process introduces four new features:

1. Automatic Active Directory domain and forest preparation when you promote the first Windows Server 2012-based server to a Domain Controller.
2. Automatic targeting of the Domain Controllers holding the appropriate Flexible Single Master operations (FSMO) roles for preparation steps.
3. Although adprep.exe is still available for large deployments with security and process concerns surrounding schema extensions and the like, it’s only available as a 64bit executable. There is no 32bit version of adprep.exe available.
4. Adprep.exe is now multilingual.

Apparently, you are looking to prepare the Active Directory domain and/or forest of your organization(s), featuring Windows Server 2003 x64-based Domain Controllers, for Windows Server 2012-based Domain Controllers and features. You are running into the error mentioned above:

To resolve this issue, follow these steps:

1. Install a physical box or virtual machine with Windows Server 2012 or the 64bit version of Windows 8.
   
   Note:
   You can use the evaluation version of any of these two Windows versions, when you don’t plan to keep the installation around after you’ve prepared the domain. 
     
   Note:
   Although Windows Server 2012 is only available as 64bit, Windows 8 is still available as both a 32bit and 64bit. Be sure to install a 64bit version of either Windows 8 Professional or Windows 8 Enterprise.
     
2. Make sure the new installation has appropriate DNS name resolution settings for the Active Directory domain and forest. These settings may include DNS Server IP addresses, and DNS search suffixes.
    
3. On this installation copy the entire contents of the \support\adprep folder from the Windows Server 2012 DVD.
    
4. Run adprep.exe from this folder.

From the list below, run the commands associated with the task(s) you’d like to perform:  

Preparation steps

Preparing the forest

To prepare the Active Directory forest, run the following command:

adprep.exe /forestprep /forest domain.tld /user EntAdm /userdomain domain.tld /password P@ssw0rd

Where you should replace domain.tld with the DNS name for the Active Directory forest root domain and both EntAdm and P@ssw0rd with valid credentials within the forest root domain to prepare the Active Directory forest for Windows Server 2012.

Note:
By default, members of the Enterprise Admins group and the Domain Admins group in the forest root domain have the required permissions to prepare the forest root domain.

After you issue the command type c followed by [Enter].   

The following line at the end of the output will indicate preparation of the domain was successful:

Adprep successfully updated the domain-wide information

Preparing the forest for Read-only Domain Controllers (optional)

To prepare the Active Directory forest, run the following command:

adprep.exe /rodcprep /forest domain.tld /user EntAdm /userdomain domain.tld /password P@ssw0rd

Where you should replace domain.tld with the DNS name for the Active Directory forest root domain and both EntAdm and P@ssw0rd with valid credentials within the forest root domain to prepare the Active Directory forest for Windows Server 2012.

The following line at the end of the output will indicate preparation of the domain was successful:

Rodcprep completed without errors. All partitions are updated. See the ADPrep.log in directory C:\Windows\debug\adprep\logs\ <date> for more information.

Preparing the domain

To prepare the Active Directory forest, run the following command:

adprep.exe /domainprep /domain domain.tld /user DomAdm /userdomain domain.tld /password P@ssw0rd

Where you should replace domain.tld with the DNS name for the Active Directory forest root domain and both EntAdm and P@ssw0rd with valid credentials within the forest root domain to prepare the Active Directory forest for Windows Server 2012.

Note:
By default, members of the Domain Admins groups have the required permissions to prepare the domain.

Note:
The Active Directory domain needs to run at least the Windows 2000 Server Native Domain Functional Level (DFL) for this command to execute correctly.

After executing, the output from this command mentions Microsoft KnowledgeBase article 324392 for more information on fixing up Group Policy permissions. Look in the paragraph above that for the following line:

Adprep successfully updated the domain-wide information

When you see this line, preparation of the domain was successful.

Fixing up Group Policy permissions

To fix up Group Policy permissions, run the following command:

adprep.exe /domainprep /gpprep /domain domain.tld /user DomAdm /userdomain domain.tld /password P@ssw0rd

The following line at the end of the output will indicate preparation of the domain was successful:

Adprep successfully updated the Group Policy Object (GPO) information.

Checking Preparation replication

When done with the preparation steps, the Active Directory Schema would be at 56. You can manually check the schema version per Domain Controller with the following command-line one-liner from any of your Windows Server 2003 x64-based Domain Controllers:

repadmin /showattr * "cn=schema,cn=configuration,dc=domain,dc=tld" /atts:objectVersion

Note:
Repadmin.exe is not built into Windows Server 2003, as it is in newer versions of Windows Server. To use repadmin.exe in Windows Server 2003, install the Windows Server 2003 Support Tools.

When all your Domain Controllers report Schema version 56, the Active Directory preparation has replicated to all Domain Controllers.

On September 20, the Dutch Networking User Group (NGN) organized an event on Windows 8 and Windows Server 2012.

During this day, several speakers provides inspiration, information and guidance on implementing and managing Windows 8 and Windows Server 2012. Speakers at this event includes Ruben Spruijt, Raymond Comvalius, Alex de Jong, Roel van Bueren, Jeff Wouters and Erwin Derksen and me.

My session focused on the new Group Policy features that administrators can use to streamline their Windows 8 and Windows Server 2012 environments. Topics included updating the Central Store, Group Policy remote updating and four real-world scenarios targeted by new Group Policy settings in Windows 8 and Windows Server 2012.

My presentation can now be viewed online:

Note:
This video is in Dutch.

If you don’t want to spend 40 minutes on watching this video, you can alternatively read the following blogposts:

Three useful ways to get started with Group Policy in Windows 8 and Windows Server 2012 
Five must-have Group Policy settings to make people productive with Windows 8 on day 1    
Five must-have Group Policy settings when your colleagues use 3G / 4G connections   
Five must-have Group Policy settings to protect peoples privacy in Windows 8   
Five must-have Group Policy settings to create an uniform look for your Windows 8 clients

Microsoft introduced KnowledgeBase article 2738697 with the title "The server is not operational" domain controller configuration error when you configure a server by using Server Manager.

Alternatively, they could’ve named this KnowledgeBase article Why you need to domain join proposed Replica Domain Controllers first in Active Directory in Windows Server 2012. Another good candidate would’ve been: NTLM authentication is disabled by default on Windows Server 2012-based Domain Controllers.

Note:
While the title of Microsoft KnowledgeBase article 2738697 suggests this problem only occurs when using Server Manager, you’ll experience similar behavior when using the Install-ADDSDomainController PowerShell Cmdlet to create a new replica Domain Controller.

In this blogpost I’ll explain why.

The challenge

The Active Directory Domain Services Configuration Wizard, that is part of the new Domain Controller Promotion process in Windows Server 2012, has two modes:

1. Non-domain joined mode
   In this mode, the Active Directory Domain Services Configuration Wizard uses NTLM v2 authentication to browse the Active Directory forest. This mode is in use, when the server you have envisioned as a replica Domain Controller is not joined to the domain for which you want it to become a replica Domain Controller.
    
2. Domain joined mode
   In this mode, the Active Directory Domain Services Configuration Wizard uses Kerberos authentication to browse the Active Directory forest. This mode is in use, when the proposed replica Domain Controller is joined to the domain.

This makes sense, since for Kerberos, you need a Kerberos realm. In Active Directory words, you need to know about the forest, before you can use Kerberos authentication.

But, a Windows Server 2012-based Active Directory environment has NTLM authentication disabled by default. Therefore, a proposed replica Domain Controller cannot browse the Active Directory forest, and can therefore not become a replica Domain Controller.

Note:
The Active Directory Domain Services Configuration Wizard does not provide any clue which authentication method is used.

“You’ll want to use Kerberos”

While NTLM authentication sounds like a great idea, you will want to use Kerberos authentication in your Active Directory environment and especially when you promote a server to a Domain Controller. When comparing Kerberos to NTLM authentication, the following advantages for Kerberos show up for the domain controller promotion scenario:

• Mutual authentication.
  When a member server uses the Kerberos protocol for authentication, Kerberos provides the server with an assurance that the service is not being impersonated by malicious code on the network.
    
• Performance.
  Kerberos authentication offers improved performance over NTLM authentication.

The solution

The solution given in Microsoft KnowledgeBase article 2738697 is to domain join the proposed replica Domain Controller, before promoting it to a replica Domain Controller.

Note:
The instructions below assume you have LDAP, RPC, and DNS connectivity and can contact all existing domain controllers without issue for other operations.

Full installations

For a Full installation of Windows Server 2012, log on with administrative privileges. Press Win+X, then select System from the Power User Menu. Now, click on the Change settings link in the Computer name, domain and workgroup settings area. Click the Change… button and in the Member of area select Domain: and type either the NetBIOS or (Fully Qualified) DNS name of the Active Directory domain and press OK. Supply domain credentials. When welcomed to the domain, press OK again and then click OK to reboot.

After the reboot, from Server Manager, run the Active Directory Domain Services Configuration Wizard again and promote the member server to a replica Domain Controller.

Server Core instalations

On a Server Core installation of Windows Server 2012, things are a little bit different, but not necessarily more difficult. Log on with administrative privileges and on the command prompt type sconfig. This will display the Server Configuration screen. Choose option 1 to change Domain/Workgroup membership. Press D to join a domain. Type the DNS name of the domain to join and supply domain credentials. If you want to rename the server, you could specify that, otherwise let the server reboot as a member server.

Alternatively you can use the following commandline one-liner:

netdom /join localhost /domain domain.tld /userd DOMAIN\Administrator /passwordd * /reboot

Related KnowledgeBase article

"The server is not operational" domain controller configuration error when you configure a server by using Server Manager

Related posts

New features in AD DS in Windows Server 2012, Part 2: New Promotion Process 
New features in AD DS in Windows Server 2012, Part 4: New PowerShell Cmdlets

Yesterday was a special day. For the first time, my employer organized a customer event for over 300 people at the Van Nelle Factory in Rotterdam on a piece of technology not even available mainstream. We dubbed the event “Samen Slimmer met Windows 8 en Windows Server 2012”, an event title that roughly translates to “Better Together with Windows 8 and Windows Server 2012”.

I was the technical content owner for this event.

This meant I designed the program, chartered colleagues as speakers, asked external speakers Daniel van Soest and Raymond Comvalius to help out, took care of an on-site Hyper-V-based demo environment, designed the demos and slides for the technical track, and communicated about the technical requirements with the venue.

Roel Nikkessen, our CEO, started the event with a short introduction.

Afterwards, Daniel van Soest and Marcel Nieuwpoort presented an awesome keynote on the integration advantages between the different members of the Windows family  and how to manage Windows 8 in the enterprise:

After a short break I presented three sessions for approximately 2 hours. The first 45 minutes I interviewed six colleagues on their favorite “Better Together” features in Windows 8 and Windows Server 2012:

• Adnan Hendricks on Dynamic Access Control
• Roland Zenhorst on Access-denied Remediation
• Chris Petit on BitLocker Network Unlock
• Jelmer Siljee on IP Address Management
• Robin Gilijamse on Software Defined Networking
• Maarten de Vreeze on Active Directory-based Activation

Each one, presented a small demo on their topic, which was a lot of fun.

The second 45 minutes session started with a 15-minute demo/comparison between System Center Configuration Manager 2012 (with Service Pack 1 Beta) and the Microsoft Deployment Toolkit 2012 with Update 1 by Rik van Berendonk and Rinko Rijnhout:

Then, I discussed the new Group Policies for Windows 8 with Roland Zenhorst. We specifically zoomed in on the Prohibit connection to roaming Mobile Broadband networks policy as part of a strategy avoid high bills for 3G/4G connected Windows 8 devices.

Together with Joost Koelman, we looked at App-V, which is part of the Microsoft Desktop Optimization Pack for Software Assurance (MDOP). This technology is used intensely in our cloud solution, called Officium. So I invited Maarten Jongepier, the manager of this offering and the first suit, on stage to pitch his platform as the ultimate platform to host legacy applications and bring the new Windows 8 interface to iPads and other android devices through Remote Desktop Services (RDS) and Citrix XenApp. Marien de Gelder, our software development manager and also wearing a suit for the occasion, came on stage next to show off our Windows 8-style Service Delivery Dashboard app, the first Windows 8 app we produced for customers:

To conclude the second session, Raymond Comvalius and I introduced the audience to the framework we developed in the last year, that helps people perform successful Windows migrations.

The third session was designed as a server virtualization platform battle between VMware’s vSphere 5.1 platform and the combination of Hyper-V in Windows Server 2012 and System Center 2012 (with Service Pack 1).

This highly energized session was the last session of the day. A good day.

Further reading

Windows 8 krijgt de handen nog niet op elkaar Dutch

In KnowledgeBase article 2737129, titled Group Policy preparation is not performed when you automatically prepare an existing domain for Windows Server 2012, Microsoft describes the preparation steps in the new automatic Active Directory Domain Services Upgrade process in more detail.

About the new automatic preparation process

In Windows Server 2012, the whole Active Directory preparation process is automated. When you promote a Windows Server 2012-based member server to an additional Domain Controller for a domain or upgrade a Windows Server 2008 x64 or Windows Server 2008 R2-based Domain Controller to Windows Server 2012, the Active Directory Domain Services Configuration Wizard will determine whether the environment needs to be prepared as part of the promotion process:

Note:
If you’re creating a replica Domain Controller in a Windows Server 2003-based Active Directory environment, you will need to perform these steps manually, as described in the blogpost Adprep "not a valid Win32 application" error on Windows Server 2003, 64-bit version.

The situation

What’s interesting is, that the KnowledgeBase article shows the automatic upgrade process does not perform Group Policy Preparation, the equivalent of:

adprep.exe /domainprep /gpprep

To make things worse, when you use the Active Directory Domain Services Configuration Wizard (the ‘new’ dcpromo) you don’t get notified of this. Only when you use the
Install-ADDSDomainController PowerShell Cmdlets, you might notice the piece of text describing additional actions need to be performed:

The new cross domain planning functionality for Group Policy, RSOP Planning Mode, requires file system and Active Directory Domain Services permissions to be updated for existing Group Policy Objects (GPOs).

This is by design.

What Group Policy Preparation does

Group Policy preparation adds cross-domain planning functionality for Group Policy and Resultant Set of Policy (RSoP) planning mode. This requires updating the file system in SYSVOL and Active Directory permissions for existing group policies. If the environment already contains custom or delegated permissions that were put in place manually by administrators, Group Policy preparation triggers replication of all Group Policy files in SYSVOL and may deny RSOP functionality to delegated users until their permissions are re-created by administrators.

The solution, but whether you need it?

Microsoft has decided not to automatically perform Group Policy preparation as part of the automatic upgrade process, to prevent needless resets of administrator-set specific delegation permissions on SYSVOL.

Furthermore, Administrators only need to run Group Policy preparation only one time in the history of a domain. Group Policy preparation does not need be run with every upgrade and has been available since Windows Server 2003.

Also, If your Active Directory domain has never run on Windows 2000 Server-based Domain Controllers, there has never been a need to perform Group Policy preparation.

Odds are your Active Directory has already been prepared.

Performing Group Policy preparation

If you’re in doubt whether Group Policy Preparation has already been performedin the domain, you can always perform Group Policy Preparation again. To do so, perform one of the following actions:

1. Run adprep.exe /domainprep /gpprep from the \support\adprep folder on the Windows Server installation media of the Windows Server version running on your original Domain Controllers. Perform this command on the Domain Controller holding the Infrastructure Master Flexible Single Master Operations (FSMO) role as a member of the Domain Admins group.
       
2. Run adprep.exe /domainprep /gpprep from from the \support\adprep folder on the Windows Server 2012 installation media on a Windows 8 x64 installation or Windows Server 2012 installation. See the blogpost Adprep "not a valid Win32 application" error on Windows Server 2003, 64-bit version for more detailed instructions on how to perform these actions.

When the response from either one of these commands contains the following output, Group Policy Preparation has already been performed:

Domain-wide information has already been updated.
[Status/Consequence]
Adprep did not attempt to rerun this operation.

Adprep successfully updated the Group Policy Object (GPO) information.

Concluding

With Windows 2000 Server now no longer supported, Microsoft has decided to make the Group Policy preparation an optional action you can perform on the command line.

Related blogposts

New features in ADDS in Windows Server 2012, Part 3: New Upgrade Process 
Adprep "not a valid Win32 application" error on Windows Server 2003, 64-bit version   

Further reading

Operations that are performed by the Adprep.exe utility when you add a Windows Server 2003 domain controller to a Windows 2000 domain or forest  
Enhancements to Adprep.exe in Windows Server 2003 Service Pack 1 and in hotfix 324392

Microsoft Knowledgebase article 2743345 with title "The system cannot find the file specified" Adprep /gpprep error, or tool crashes" describes an issue where the Group Policy Preparation fails or crashes.

The main reason for this behavior is the Domain Controller holding the Infrastructure Master Flexible Single Master Operations (FSMO) role in this domain implements a disjoint namespace. Adprep.exe assumes that computer names will match their domain names because this match is the default behavior in all versions of Windows.

About Disjoint Namespaces

A disjoint namespace scenario is one in which the primary DNS suffix of a computer does not match the DNS domain name where that computer resides. The computer with the primary DNS suffix that does not match is said to be disjoint. Another disjoint namespace scenario occurs if the NetBIOS domain name of a domain controller does not match the DNS domain name.

Disjoint namespaces are not a Microsoft best practice.

About manual Group Policy Preparation

As written before, a couple of scenarios exist where you need to perform Group Policy Preparation separately on the commandline, despite the new automatic Active Directory Upgrade process in Windows Server 2012’s Active Directory Domain Services Configuration Wizard and Install-ADDSDomainController Cmdlet:

• The automatic Active Directory preparation functionality in Windows Server 2012 does not perform Group Policy Preparation, to avoid situations where specific rights on SYSVOL have been delegated get reset to the defaults. More details can be found in the blogpost Group Policy preparation is not performed when you automatically prepare an existing domain for Windows Server 2012.
      
• When you upgrade an Active Directory environment with Windows Server 2003 x64-based Domain Controllers to Windows Server 2012, the adprep.exe from the Windows Server 2012 installation media cannot be used on these Domain Controllers, despite it being a 64bit application. You will need to setup a Windows Server 2012 or Windows 8 box to prepare Active Directory for Windows Server 2012-based Domain Controllers. More details can be found in the blogpost Adprep "not a valid Win32 application" error on Windows Server 2003, 64-bit version.

The situation

You run adprep.exe /domainprep /gpprep from the \support\adprep folder of the Windows Server 2012 Installation Media in an Active Directory domain where the Domain Controller holding the Infrastructure Master Flexible Single Master Operations (FSMO) role implements a disjoint namespace.

You encounter error code 0x2.

The resolution

Perform the following steps to successfully prepare Group Policy in this situation:

Note:
Perform these steps with an account that is a member of the Domain Admins group. Also, run commands at an elevated command prompt.

1. Locate the infrastructure master role holder in the domain. To do this, run the following command:
       
        netdom.exe query fsmo
       
2. Log on to the console of the Domain Controller holding the Infrastructure Master Flexible Single Master Operations (FSMO) with an account that is a member of the Domain Admins group.
          
3. Disable incoming and outgoing (also known as "inbound and outbound") replication. To do this, run the following command:
       
        repadmin.exe /options localhost
        +DISABLE_OUTBOUND_REPL +DISABLE_INBOUND_REPL
         
4. Then modify its Domain Name System (DNS) suffix. To do this, follow these steps:
   1. Start sysdm.cpl, click OK, click Change, and then click More
   2. Set the suffix in the Primary DNS suffix of this computer box to match the Active Directory Domain Services domain name instead of the current disjointed name.
        
5. Restart and log on to the server again to run the following command:
       
        adprep.exe /domainprep /gpprep
          
6. Use sysdm.cpl, and then follow the steps in step 3, except this time in step 3.2, you must set the suffix in the Primary DNS suffix of this computer box to match the original disjoint name on the infrastructure master server.
        
7. Restart and then log on to the infrastructure master server, and re-enable inbound and outbound replication. To do this, use the following command:
       
        repadmin.exe /options localhost
        -DISABLE_OUTBOUND_REPL -DISABLE_INBOUND_REPL

Concluding

While this KnowledgeBase article implements a quick fix to resolve the specific Group Policy Preparation problem, the real problem lies in a DNS configuration, that is not a best practice. In the future, the disjoint namespace will contribute to numerous other problems, so if you can eliminate this situation on the longer term, this will help you avoid more errors.

Related KnowledgeBase articles

2743345 The system cannot find the file specified" Adprep /gpprep error, or tool crashes 

Related blogposts

New features in ADDS in Windows Server 2012, Part 3: New Upgrade Process     
Adprep "not a valid Win32 application" error on Windows Server 2003, 64-bit version 
Group Policy preparation is not performed when you automatically prepare an existing domain for Windows Server 2012 

Further reading

Understanding Disjoint Namespace Scenarios  
Disjoint Namespace  
Kerberos and the Disjoint Namespace

About two months ago, I wrote a blog post on determining your Windows 8 and Windows Server 2012 pre-release version. With that information you could then determine the (possible) in-place upgrade paths.

In this blog post I’ll show you the expiration dates of the Windows Server 2012 and Windows 8 pre-release versions, so you’ll know when your pre-release version is roughly going to expire:

Build 8102 (Developer Preview)

When your pre-release Windows 8 or Windows Server "8" installation reports build 8200, you’re running the Developer Preview. This pre-release version was made available on September 14, 2011 after it was announced at //Build/.

Windows 8 Developer Preview has expired on March 11, 2012. If you installed the hotfix in Microsoft KnowledgeBase article 2671501 before this date, the Developer Preview will continue to work until January 15, 2013.

Windows Server "8" Developer Preview expired on April 8, 2012, unless you installed the hotfix in Microsoft KnowledgeBase article 2671501 before this date. In that case, Windows Server "8" Developer Preview will continue to work until January 15, 2013.

Build 8250 (Consumer Preview / Beta)

On February 29, Microsoft released both the Consumer Preview for Windows 8 and the Beta for Windows Server "8". Only, two weeks later, during MMS 2012, Microsoft renamed Windows Server "8" to Windows Server 2012.

Windows 8 Consumer Preview expires on January 15, 2013. This expiration data is identical to the expiration date of the Windows 8 Developer Preview with the hotfix in Microsoft KnowledgeBase article 2671501 installed.

Windows Server "8" Beta expires on January 15, 2012

Build 8400 (Release Candidate / RC)

Both the Windows 8 Release Preview and Windows Server 2012 Release Candidate, introduced on the last day of Microsoft’s 2012 fiscal year (May 31, 2012), expire on January 15, 2013.

Build 9200

Build 9200 is the Release to Manufacturers (RTM) build of Windows 8 and Windows Server 2012. This build has no expiration, except in the following scenarios:

• You are using an Evaluation version of Windows 8 or Windows Server 2012. Evaluation versions can only be used for a limited number of days. Also, you need to reinstall Windows 8 and/or Windows Server 2012 if you want to use it in a production environment. (Supplying the license key is not enough)
    
• The support on the Release to Manufacturers (RTM) build of Windows 8 and Windows Server 2012 stops six months after the first service pack. Although this will not hinder you in using the products, you will need be able to get help via Microsoft for your installation, until you upgrade/update to a supported service pack level.

Finding your exact Expiration date

The above dates are rough estimations on the expiration dates of Windows 8 and Windows Server 2012 pre-release versions. However, you can simple find the exact expiration date and time for your specific installation, by typing the following command:

winver.exe

This command will show the exact expiration date in the About Windows screen as shown below for the Windows 8 Consumer Preview (build 8250):

Concluding

Microsoft has made it very easy for everyone to understand that January 15, 2013 is the expiration date for all pre-release versions of Windows 8 and Windows Server 2012.

Related blogposts

Determining your Windows 8 and Windows Server 2012 version 
How To Install Windows Server 8 (build 8102) 
Windows Server “8” Beta available (build 8250)   
Windows 8 Release Preview (Build 8400) ready 
Windows Server 2012 Release Candidate (Build 8400) is now available 

Related KnowledgeBase articles

An update that postpones the expiration date of Windows Developer Preview and of Windows Server Developer Preview is available

It’s never been easier to install pre-release versions of Windows and Windows Server, then with Windows 8 and Windows Server 2012. Downloadable ISO files were abundant and could be used for virtual machines on all major virtualization platforms, ISO files could be burned with a built-in tool in the previous version of Windows (Windows 7) and the same ISO files could be transformed into bootable USB media through both an automatic tool and a manual process.

However, these installation media also present a challenge. When a suitable marker pen wasn’t available, a non-suitable marker pen was used to write the contents on the disc or USB install media was not or improperly marked, you can lose track of your installation media pretty fast.

This blogpost shows you how to find the product, architecture, language and build of Windows 8 and Windows Server 2012 installation media.

Windows 8 or Windows Server 2012

To detect whether the installation media is Windows 8 or Windows Server 2012, you can use (one of) the following tricks:

If \sources\background_cli.bmp exists, it’s installation media to install Windows 8. If \sources\background_svr.bmp exists, it’s installation media to install Windows Server 2012 or one of it’s Windows Server "8" pre-release versions.

If the \sources\adprep folder is missing, it’s Windows 8.

Alternatively, in the [BuildInfo] and [sku] sections of \sources\product.ini you can see the edition(s) of Windows 8 or Windows Server 2012 available through the installation media.

Note:
On the Release to Manufacturers (RTM) and later installation media, product.ini may not be available.

Architecture

Windows installation media can be 32bit (x86) and 64bit (x86-64 or x64 for short).
The file \sources\idwbinfo.txt contains the architecture of the installation media in the [BUILDINFO] section, following BuildArch=. If it reads BuildArch=amd64, it’s 64bit installation media. If it reads BuildArchx86, it’s 32bit installation media.

Alternatively, to determine the architecture of the installation media check autorun.inf in the root of the installation media. If, on the first line, it reads [AutoRun.Amd64] it’s 64bit installation media. If the first line reads [Autorun] and consists of only three lines, it’s the 32bit version of Windows 8.

Note:
There is no 32bit version of Windows Server 2012.

Language

To determine the language(s) of the installation media, check \sources\lang.ini, as this file contains a list of the available languages for the User Interface (UI). A fallback language is also specified.

Build

The file \sources\idwbinfo.txt contains the name of the build branch the installation media belongs to in the [BUILDINFO] section, following BuildBranch=.

Note
The BuildBranch value designates the development branch the installation media belongs to. Build Branches span multiple build numbers, so the BuildBranch value does not specify the version very specifically.

Alternatively, to determine the exact pre-release build of the installation media, locate setup.exe in the root of the installation media or \sources\setup.exe. Right-click it, then on the Details tab check either File version of Product version.

With the table listed in the blogpost titled Determining your Windows 8 and Windows Server 2012 version, you can now find the major pre-release version of your installation media.

Concluding

It’s fairly easy to determine the Windows version on a disc or on USB installation media, when you know where to look for clues.

Further reading

Determining your Windows 8 and Windows Server 2012 version 
Expiration dates on Windows 8 and Windows Server 2012 Pre-release versions 
Creating your own Windows 8 and Windows Server 2012 USB install device

Microsoft has issued a new KnowledgeBase article that addresses an issue when you use the Install-ADDSDomain PowerShell Cmdlet from the ADDSDeployment PowerShell module remotely to create a child domain.

This issue is related to PowerShell remoting and the fact that the Install-ADDSDomain PowerShell Cmdlet doesn’t perform a pre-check on the password to create the DNS delegation.

The situation

You want to promote an installation of Windows Server 2012 that is a member of a domain to a Domain Controller for a new child domain in the existing Active Directory forest. You perform this action remotely from another domain-joined Windows Server 2012 installation or a domain-joined Windows 8 installation with the Remote Server Administration Tools (RSAT) installed.

The command you use looks like:

Invoke-command -computer HostNameDCtoBe -credential (get-credential) -scriptblock {Install-addsdomain -newdomainname child 
-parentdomain domain.tld -domaintype child -credential (get-credential) -dnsdelegationcredential (get-credential)}

When you execute this command, you will be prompted for credentials.

After a while, the command outputs the following information:

          Message             : The operation failed because:

                                        Failed to create a trust with domain 
                                        child.contoso.com on the parent domain controller
                                       dc1.domain.tld

                                       "Access is denied."

                                       This server has been disjoined from domain "DOMAIN".

          Context               : DCPromo.General.54
          RebootRequired  : False
          Status                 : Error

Subsequently, the child is not created.

Note:
This issue does not occur when you run the Install-ADDSDomain PowerShell Cmdlet locally, or when you perform a child domain creation through the Active Directory Domain Services Configuration Wizard.

The cause

This issue occurs because credentials that were given to -dnsdelegationcredential contained a bad password.

Unlike the password for the other two credentials that are provided in this scenario, the password for the DNS delegation credential is not tested until it is actually used. However, at that point in the domain deployment, many other changes have been made, and the bad credentials cause a fatal error when they are used later.

This issue occurs only when you provide a bad password through remote Windows PowerShell invocation. If the DNS delegation is run locally, the delegation will still fail but will provide a warning that delegation was not configured and will let promotion otherwise succeed.

The solution

To resolve this issue, follow these steps:

1. Rejoin the server to the parent domain to enable remote Windows PowerShell connectivity through the Invoke-Command Cmdlet.
       
        Note:
        By default, this Cmdlet requires the Kerberos protocol.
       
2. Try to create the domain again. When you do this, make sure that you provide the DNS Delegation credentials by using a valid username and password.

Related KnowledgeBase articles

"Access is denied" error message when you create a child domain remotely by using Install-AddsDomain 

Related Posts

Remote Server Administration Tools for Windows 8 
New features in AD DS in Windows Server 2012, Part 2: New Promotion Process 
You can only set the DFL to Windows Server 2012 when you create a new domain tree on a Windows Server 2012-based computer  

Further reading

Install-ADDSDomain 
Add Windows Server 2012 as a Domain Controller