[Windows Server 2012] Issues with Active Directory in a Lab environment - Part 4

Active Directory is a great feature in Windows Server. However, imagine that you stop your lab environment for several days, weeks and perhaps months. You will certainly encounter some troubles when you'll try to turn on again your DCs.

In that series, I will share my own experience and show how to solve that troubles.

1. The DNS is waiting for Active Directory - KB 2001093
2. DFSR JET database is not shut down cleanly
3. This server has been disconnected from other partners for 60 days
4. The DFS Replication service failed to register the WMI providers

4. The DFS Replication service failed to register the WMI providers

Symptoms
You note that replication of the SYSVOL folder between your DCs doesn't work: For example, if you add manually a file in that folder, that file is not replicated on the other DC. That problem can also create some troubles on computers if they can't download the right version of their GPO.
Of course, all DCs are online and can be joined normally.

In Event logs,you find the following Event:

Event ID:      6104
Log Name:      DFS Replication
Source:        DFSR
Level:         Error
The DFS Replication service failed to register the WMI providers. Replication is disabled until the problem is resolved.

Resolution

Unfortunately, I have not found any KB about that trouble on Microsoft web site. With several blogs and forums, I found command lines that solve my problem :

CD %windir%\system32\wbem
mofcomp dfsrprov.mof
mofcomp dfsrprov.mfl
wmiprvse /regserver
net stop dfsr
net start dfsr

I hope that feedback will be helpful if you encounter the same issue.

See you soon
Julien

[Windows Server 2012] Issues with Active Directory in a Lab environment - Part 3

Active Directory is a great feature in Windows Server. However, imagine that you stop your lab environment for several days, weeks and perhaps months. You will certainly encounter some troubles when you'll try to turn on again your DCs.

In that series, I will share my own experience and show how to solve that troubles.

1. The DNS is waiting for Active Directory - KB 2001093
2. DFSR JET database is not shut down cleanly
3. This server has been disconnected from other partners for 60 days
4. The DFS Replication service failed to register the WMI providers

3. This server has been disconnected from other partners for 60 days

Symptoms

You note that replication of the SYSVOL folder between your DCs doesn't work: For example, if you add manually a file in that folder, that file is not replicated on the other DC. That problem can also create some troubles on computers if they can't download the right version of their GPO.

Of course, all DCs are online and can be joined normally.

In Event logs,you find the Event ID 4012 with the following description:

The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL\domain. This server has been disconnected from other partners for 60 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected.

Error: 9061 (The replicated folder has been offline for too long.)
Replicated Folder Name: SYSVOL Share

Cause and Resolution

In the rest of the description you get the following resolution proposal:

To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group. This causes the server to perform an initial synchronization task, which replaces the stale data with fresh data from other members of the replication group.

However, even if you add the DFS Management snap-in on your DCs (not installed by default), you can't accomplish the actions. Indeed, the SYSVOL replication group settings are protected and provided in read-only mode.

To solve that issue, you need to perform an authoritative synchronization of DFSR-replicated SYSVOL:

That operation is described for Windows Server 2008 R2 in  KB 2218556 How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS):

For each DC:

 - In ADSIEDIT console, open the CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain> object

 - Modify the following attribute:
   msDFSR-Enabled=FALSE
 
 - For the domain controller you want to make authoritative (preferably the PDC Emulator, which is usually the most up to date for SYSVOL contents) ONLY, modify also the following attribute:
   msDFSR-options=1

  - Force Active Directory replication throughout the domain and validate its success on all DCs (open ADSIEDIT and check attributes values)

 - Restart the DFSR service of the DC set as authoritative.
You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated

 - Open the CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain> object of the DC you set as authoritative

 - Modify the following attribute:

   msDFSR-Enabled=TRUE

 - Force Active Directory replication throughout the domain and validate its success on all DCs

 - On the DC you set as authoritative, type the command line DFSRDIAG POLLAD

Note: Microsoft indicates that on Windows Server 2008 R2 you will see Event ID 4602 in the DFSR event log indicating SYSVOL has been initialized. On a Windows Server 2012, I never saw Event ID 4602 but Event ID 46014:
The DFS Replication service initialized SYSVOL at local path C:\Windows\SYSVOL\domain and is waiting to perform initial replication...

Perform the previous commands on all the other DCs:
 - Restart the DFSR service. You will see Event ID 4114 in the DFSR event log.

 - Open the CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain> object
 - Modify the following attribute:
   msDFSR-Enabled=TRUE

 - Type the command line DFSRDIAG POLLAD

To monitor the replication queue, you can use the following command line:
Dfsrdiag backlog /sendingMember:DC2012 /RGName:"Domain System Volume" /RFName:"SYSVOL Share"

To ensure SYSVOL replication works correctly, just create a file in the SYSVOL folder and ensure that file is replicated on all the other DCs.

See you soon
Julien

[Windows Server 2012] Issues with Active Directory in a Lab environment - Part 2

Active Directory is a great feature in Windows Server. However, imagine you lose or crash your DC's during tests...

In that series, I will share my own experience and show how to solve that troubles.

1. The DNS is waiting for Active Directory - KB 2001093
2. DFSR JET database is not shut down cleanly
3. This server has been disconnected from other partners for 60 days
4. The DFS Replication service failed to register the WMI providers

2. DFSR JET database is not shut down cleanly

Symptoms

You note that replications between your DCs don't work: For example, when you create an account on one DC, the account doesn't appear on the other DCs. All DCs are online and can be joined normally.

In Event logs,you find the Event ID 2213 with the following description:

The DFS Replication service stopped replication on volume C:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication.

Recovery Steps
1. Back up the files in all replicated folders on the volume. Failure to do so may result in data loss due to unexpected conflict resolution during the recovery of the replicated folders.
2. To resume the replication for this volume, use the WMI method ResumeReplication of the DfsrVolumeConfig class. For example, from an elevated command prompt, type the following command:
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" call ResumeReplication

Cause and Resolution

By design on Windows Server 2012, after an unexpected shutdown, the DFS Replication service no longer automatically recovers databases. This behavior enables you to back up the replicated files before you start the recovery process.

To start replication again, execute the command line provided in the Event description:

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" call ResumeReplication

To prevent that behavior in a lab environment, you may want to automatically recover databases. You can set the HKLM\System\CurrentControlSet\Services\DFSR\Parameters\StopReplicationOnAutoRecovery registry value to 0.



To get more information, read the KB 2663685 Changes that are not replicated to a downstream server are lost on the upstream server after an automatic recovery process occurs in a DFS Replication environment in Windows Server 2008 R2.



See you soon
Julien

[Windows Server 2012] Issues with Active Directory in a Lab environment - Part 1

Active Directory is a great feature in Windows Server. However, imagine you lose or crash your DC's during tests..

In that series, I will share my own experience and show how to solve that troubles.

1. The DNS is waiting for Active Directory - KB 2001093
2. DFSR JET database is not shut down cleanly
3. This server has been disconnected from other partners for 60 days
4. The DFS Replication service failed to register the WMI providers

1. The DNS server is waiting for Active Directory

Symptoms

At first, the DNS server located on your Domain Controller doesn't want to start.
You can also notice it takes a lot of time to start computer and to logon.

In Event logs, you get the Event ID 4013:
The DNS server is waiting for Active Directory Domain Services (AD DS) to signal that the initial synchronization of the directory has been completed. The DNS server service cannot start until the initial synchronization is complete because critical DNS data might not yet be replicated onto this domain controller...

Cause and Resolution

The domain controller try to get inbound replicate. In an attempt to boot with the latest DNS zone contents, DNS servers hosting AD-integrated copies of DNS zones delay DNS service.

If you have several domain controllers, Microsoft recommends to set as first DNS another DNS server and to set the DC itself as an additional alternate DNS server.

In a lab environment, you can bypass the initial synchronization requirements in Active Directory by disabling the HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations (=0 REG_DWORD) registry value. However, that configuration is not recommended in a production environment.

To get more information, read KB 2001093 Troubleshooting DNS Event ID 4013: The DNS server was unable to load AD integrated DNS zones.

In particular, note the following best practices:

Domain controllers hosting AD-integrated DNS zones should not point to a single domain controller and especially only to themselves as preferred DNS for name resolution.

Configuring domain controllers to point to a single DNS server's IP address, including the 127.0.0.1 loopback address, represents a single point of failure. This is somewhat tolerable in a forest with only one domain controller but not in forests with multiple domain controllers. 
Hub-site domain controllers should point to DNS servers in the same site as them for preferred and alternate DNS server and then finally to itself as an additional alternate DNS server. 
Branch site domain controllers should configure the preferred DNS server IP address to point to a hub-site DNS server, the alternate DNS server IP  address to point to an in-site DNS server or one in the closest available site, and finally to itself using the 127.0.0.1 loopback address or current static IP address.

See you soon
Julien

[Windows Server 2012 R2] Test Lab Guides - Updates

You probably know the Test Lab Guides (alias "TLG"). That labs help you to build your own lab to test a lot of products and features.

You've got TLGs for DirectAccess with Windows Server 2012, TLGs for System Center 2012 SP1...

TLGs series has been recently updated with the first lab for Windows Server 2012 R2: http://www.microsoft.com/en-us/download/details.aspx?id=39638

All the TLGs: http://social.technet.microsoft.com/wiki/contents/articles/1262.test-lab-guides.aspx

Windows Server 2012 TLGs: http://social.technet.microsoft.com/wiki/contents/articles/7807.windows-server-2012-test-lab-guides.aspx


Enjoy !
Julien

[DirectAccess] Part 6: Configuring DirectAccess for Windows 7

In previous parts of this series, we configured DirectAccess on Windows Server 2012 for Windows 8 client computers.

• Part 1: Implementing a Basic DirectAccess configuration with IP-HTTPS on Windows Server 2012 Core
• Part 2: Reporting and Optimizing IP-HTTPS connections
• Part 3: Authenticating IP-HTTPS connections with a PKI certificate
• Part 4: Authenticating DirectAccess clients with certificates
• Part 5: Troubleshooting guide for DirectAccess
• Part 6: Configuring DirectAccess for Windows 7

Indeed, the current environment accepts only connections from Windows 8 computers. You certainly saw the option "Enable Windows 7 client computers to connect via DirectAccess". Is that all ? Obviously not.

In that article, I propose to configure our DirectAccess environment for Windows 7 clients. We will also discover the impacts on the architecture and how to troubleshoot DirectAccess for a Windows 7 clients.

PART 6: CONFIGURING DIRECTACCESS FOR WINDOWS 7

First thing first :
1. Enable Windows 7 client computers to connect via DirectAccess

Open the DirectAccess Console

In the Step 2 - Remote Access Server Box, click on Edit

 - On the Authentication page, select the option Enable Windows 7 client computers to connect via DirectAccess
 - Click on Finish and apply the configuration on the DirectAccess Server

2.Install the DirectAccess Connectivity Assistant

Download the DirectAccess Connectivity Assistant 2.0 on http://www.microsoft.com/en-us/download/details.aspx?id=29039.

Note that this version apply only on computers running Windows 7 when connecting to internal corporate networks with DirectAccess in Windows Server 2012 (only).

The package contains documentation, admx files for GPO and MSI files.

 - Intall the Microsoft_DirectAccess_Connectivity_Assistant_x64.msi or the Microsoft_DirectAccess_Connectivity_Assistant_x86.msi MSI file depending on your plateform.

The installation is really easy : I Accept, Install and Finish...

3. Set DirectAccess Connectivity Assistant settings

Indeed, parameters for DirectAccess Connectivity Assistant are provided by GPO:

 - Copy the ADMX file and ADML in your environment. In my own lab, I use a CentralStore.
(for more information http://www.microsoft.com/en-us/download/details.aspx?id=23947 and http://support.microsoft.com/kb/929841/en-us)

You can modify directly the DirectAccess Client Settings GPO but the Best Pratice is rather to leave DirectAccess manage that GPO and to configure the DirectAccess Connectivity Assistant with a dedicated GPO.

- Open the report of the DirectAccess Client Settings GPO

- In Computer Configuration > Policies > Administrative Templates > Network > DirectAccess Client Experience Settings, read the properties: Corporate Resources, IPsec Tunnel Endpoints (DTEs) and Support email Address.

- Create and link a new GPO to your Windows 7 computers

- In Computer Configuration > Policies > Administrative Templates > DirectAccess Connectivity Assistant, define the properties: Corporate Resources, DTEs and Support email Address.

 - Force GPO refresh on your Windows 7 computer client and connect it to the Internet.



4. Troubleshooting

In general, if DirectAccess works with Windows 8 computer client, It'll be good for Windows7.
However, if you have problems...

 - Click right on the DirectAccess Connectivity Assistant icon and Select Advanced Diagnostics

 - Logs are automatically generated. Click on the link.

 - Open the text file.

The assistant provides a first analysis and a lot of configuration dumps

Note that Powershell commands provided in Part 5: Troubleshooting guide for DirectAccess are not available in Windows 7. It's nice to have a full automatic tool that can make automatically all tests for you !

In that screenshot, we see the NRPT policy applied on the client.

5. DirectAccess works fine

Congratulation !

6. What are the impacts ?

In that chapter, I propose to show you the impact of adding certificates and enabling Windows 7 support.

Here, is a screenshot of the DirectAccess Client Settings GPO with default DirectAccess configuration (no certificates for clients authentitication).

Computer and User authentications rely only on Kerberos.

Now, a screenshot of the DirectAccess Client Settings GPO, when adding computer client authentication with certificates. User authentication always relies on Kerberos, but computer authentication relies now on Certificate too.

To get more information, read  Part 4: Authenticating DirectAccess clients with certificates §5. Logs and Authentication.

Finally, the DirectAccess Client Settings GPO, when Windows 7 computer clients are allowed.

Kerberos authentication is no longer supported for computer. Only certificate authentication is allowed.

Concerning User authentication, NTLM authentication is available too.

7. Logs and Authentication with Windows 7 computer clients allowed

 Windows 8 computer:
There are 2 tunnels :
 - The first for computer only. That tunnel is opened even if no user has opened a session.
 - The second for user. That tunnel is based on 2 connections:
    * User authentication relies on NTLM when contacting Domain Controller.
    * User authentication relies on Kerberos for all other services.
Computer is always authenticated with its certificate.

Details of the connections for a Windows 8 computer:

User authentication relies on NTLM when contacting Domain Controller.

User authentication relies on Kerberos for all other services.

 Windows 7 computer:
There is only one tunnel containing 4 connections:
 - The first 2 connections for computer only. That 2 connections are opened even if no user has opened a session.
 - The last 2 connections for user.

Computer is always authenticated with its certificate.
User authentication relies on NTLM when contacting Domain Controller.
User authentication relies on Kerberos for all other services.

Details of the connections for a Windows 7 computer:

I hope you enjoy that series concerning DirectAccess.

See you soon !
Julien