• Useful Resources
• Changing the Description of a Local User or Group Account with more than 256 Characters
• Renaming local users when changing the language
• Adding an IP address that is not registered in DNS
• Use EUI-64 instead of random IPv6 addresses
• Configuring WSUS with SSL and a Virtual Host Name
  • What to do if you messed up
  • Configuring WSUS to use a virtual IP address only
• WINS reports initialization error
• Active Directory and Disk Write Cache
• Installing an SSL certificate for Remote Desktop
• Enabling LDAP request signing
• Windows Update Error 80072F8F
• WSUS Crash
• Improving domain controller security

Also refer to the Active Directory page.

Useful Resources

• Overview Windows Server 2012 R2 resources in TechNet
• Group Policies:
  • How to configure Internet Explorer site-zone mappings without locking the settings
• DFS and File Sharing:
  • Three ways to design your DFS Namespaces
  • Enabling access-based enumeration in Windows Server 2012
  • Managing file shares with the Server Manager in Windows Server 2012
  • Configure DFS to use FQDNs (important if you want it to work without WINS and NetBIOS)
  • Why using DFS-R for user (profile) data is a bad idea
  • DFS FAQ - Includes information on using DFS Namespaces with Offline Files (however, this information is outdated, because it applies to Windows XP / Windows 7)
  • DFS overview in TechNet
  • DFS Namespaces FAQ
  • DFS and Offline Files:
    • TechNet forum discussion 1
    • TechNet forum discussion 2
    • Blog post
    • Hotfix for Windows 7
    • What's new in Offline Files in Windows Vista (offline status is now handled per Link and not for the whole DFS server / domain)
    • What's new in Offline Files in Windows 7
    • TechNet Magazine: Changes to Offline Files in Windows Vista
• Users, Groups, and Permissions:
  • Recommended permissions for roaming profile shares
  • Default local groups
  • Windows built-in users and default groups
  • Using default group accounts
• Security:
  • Auditing and restricting NTLM usage guide
  • Increase Diffie-Hellman parameter / key size
• WINS:
  • Best practises for WINS servers

Changing the Description of a Local User or Group Account with more than 256 Characters

The Edit Local Users and Groups MMC does not allow to enter a description with more than 256 characters. Funnily, some of the groups that come with the Windows base-installation have such descriptions (e.g. RDS Endpoint Servers, RDS Management Servers, and RDS Remote Access Servers).

Luckily, we can use PowerShell to set longer descriptions. Example:

Obviously, PowerShell has to be started with elevated privileges for this commands to be successful. Otherwise the CommitChanges() action will fail with an Access denied error.

Renaming local users when changing the language

By installing a language pack, we can change the language of nearly everything in the system. However, there is one prominent thing that is not affected by the language pack: the name of the local users and groups. We change those manually of course, but who want to do that? Therefore, I wrote two little scripts that can be used to copy the names of the users and groups created during installation from one system to another one. This way, if you already have a system where the user and group names are in the language you want, you can use the export script to create a text file, copy this file to the target system and run the update script there. For English and German I already created these text files. The update script has to be run in a PowerShell with elevated privileges, so it can potentially mess up your system. Test the script in a test environment before using it on a live system and always make backups before running the script.

Adding an IP address that is not registered in DNS

The netsh command can be used to add an extra IP address to a network interface, without automatically registering this address in DNS. Example:

In this example, the network adapter has the name "Ethernet". More information is available in this blog article from TechNet.

Use EUI-64 instead of random IPv6 addresses

It might be desirable to use an EUI-64-based IPv6 address (an IPv6 address that is generated based on the MAC address of the NIC) instead of a randomly generated address during IPv6 autoconfiguration. This can be achieved by using the following netsh command (from an elevated command prompt):

Configuring WSUS with SSL and a Virtual Host Name

This section describes a solution for the following situation: You want Windows Server Update Services (WSUS) to use SSL (in general, it is a good idea to use encryption, even in a private network). However, you do not want to issue a certificate for the FQDN of the host WSUS is running on, because you want to be able to move WSUS to a different server without having to issue a new certificate and update the client configurations.

The first step is to assign an additional IP address to the server. You do not want this address to be registered with the server's FQDN in the DNS, so follow the instructions given above. The next step is to register the alternative host name you want to use for WSUS in your DNS by creating an A (and possibly an AAAA) record pointing to this address. For the rest of the instructions we assume that you are using the FQDN wsus.example.com as the virtual host name for your WSUS server. In general, it is also a good idea to add a PTR record for the IP address (or addresses) pointing back to the FQDN.

Now you have to add the SSL certificate to the trust store of the system and to the list of certificates in IIS. This process depends on how you created the certificate, so please refer to one of the many instruction manuals available on the web.

After having installed the SSL certificate, you can now go to the "WSUS Administration" site in Internet Information Services (IIS) Manager and choose Edit Bindings... from the context menu. You should have to bindings there: One for http://*:8530 and one for https://*:8531. Choose the one for HTTPS and select the certificate for wsus.example.com. Leave the Host name field empty. Otherwise it might mess up your configuration (I learned the hard way). After configuring this setting and restarting the site, you can run wsusutil to tell WSUS about the SSL certificate. I am not sure, whether this step is necessary, however during the troubleshooting process (see below) I ran it so many times that I am not able to say it would work without running it. However, it is very important to not run it at a later stage, otherwise it will mess up your configuration and WSUS will not start at all. So open an elevated command prompt, go to C:\Program Files\Update Services\Tools and run wsusutil configuressl. Now you can go back to the IIS configuration and add two bindings: One for HTTP on the virtual IP address and port 80 and one for HTTPS and the virutal IP address on port 443. For the latter one you should also select the SSL certificate. If you are using IPv6, you also have to add two bindings for the IPv6 address. If you now restart the site in IIS Manager, WSUS should be available using the virtual host-name. You can test this using a browser. The default IIS site should not be affected by these changes.

If you want to force clients to use SSL for some of the services, you should also follow the instructions on TechNet.

This leaves us with only one problem: If you want to connect from the WSUS console on the same host, you have to use the regular host name of the server, not the virtual host name for WSUS. However, you cannot use SSL for the connection, because the name in the certificate will not match (after all it is using the virtual host name). If you force SSL like described in the TechNet article, the connection from the local host will not work. This is the point where the trouble starts and while trouble-shooting this, I messed up the configuration where WSUS would not work at all. If this happened to you as well, see the instructions below on how to fix things.

This problem is caused because by default NTLM authentication does not work if the client is the same host and the request uses a host name that is different from the system's host name (or FQDN). There are two articles in Microsoft's knowledge base and a more detailed blog post describing this problem. The solution is adding your virtual host-name (wsus.example.com in the example) to the list of allowed host names. This list is stored in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 and is a Multi-String Value with the name BackConnectionHostNames and taking one host name per line as a value. You edit the registry using the registry editor or using the PowerShell. After making this change, you should restart the server. Maybe it is sufficient to restart IIS, but I did not test this.

Now you should be able to connect the WSUS console to wsus.example.com on port 443 with SSL being enabled.

If after following this guide WSUS still does not work as expected, you first should clean-up you configuration like described in the following section and repeat the steps from this section. If it still does not work, you might be interested in the section even further below, which tells you how to make sure that WSUS uses the virtual IP address exclusively. This might be needed in some environments where clients cannot access the WSUS server using its regular IP address.

What to do if you messed up

If you messed up (e.g. by running wsusutil configuressl after adding the virtual IP address to the bindings in IIS), WSUS will not start correctly and in the event log you will find one or several of the following messages:

• "The SimpleAuth Web Service is not working."
• "The Client Web Service is not working."
• "The WSUS content directory is not accessible." (with a 400, 401 or 404 error code)
• "The DSS Authentication Web Service is not working."
• "The Reporting Web Service is not working."
• "Self-update is not working."
• "The Server Synchronization Web Service is not working."
• "The API Remoting Web Service is not working."

You should be able to fix this by removing all bindings from the "WSUS Administration" site in IIS manager and just add the two bindings for http://*:8530 and https://*:8531. After this you can restart the WSUS server and it should work again. Subsequently, you can follow the instructions given above for configuring SSL.

Configuring WSUS to use a virtual IP address only

In order to understand what we are going to do here, it makes sense to first understand what we did in the sections above:

When we run wsusutil configuressl, WSUS checks the IIS configuration for its site to determine the SSL address and port it is available. WSUS has to do this, because HTTPS is used for transferring meta-data only. The actual update files are always transferred via regular HTTP without SSL. Therefore WSUS needs to know the address for HTTP so that it can tell the clients where to download the updates. By convention the port for HTTP is 80 when HTTPS is running on port 443 or one below the HTTPS port when HTTPS is using any other port than 443. WSUS will also use this information internally, in order to know how to contact its own services.

Now, if the IIS configuration does not specify a host name for the binding, WSUS will just assume it is using the servers regular host name. If you are using a virtual IP address, this is not true and so WSUS will use a wrong host name. If IIS does not listen on all addresses for the given port, WSUS will not be able to communicate correctly.

This is why we ran wsusutil configuressl before we configured the bindings for the virtual IP address. This way, WSUS still think it is running on port 8530 and using the regular host name and IP address of the server. This setup has the drawback that WSUS will also tell clients to contact it using the regular hostname and port 8530. If clients can resolve the host name and connect to the regular address on port 8530, this is not a problem. However, if we have a firewall that prevents clients from connecting on this address or port, or our clients are in a different network and the server is only visible by its alias IP address and host name, we have a problem. In this case we have to tell WSUS the virtual host name, so that clients will connect on the right address and port for update downloads.

We do this by removing the bindings we defined for port 8530 and 8531 and setting the host-name property of the bindings with the virtual IP address to the virtual host name (wsus.example.com in our example). Now we run wsusutil configuressl again. The results from wsusutil should indicate that WSUS is now using the right host name. Now we remove the host name from the bindings, because otherwise IIS will not answer requests without a host name in the header.

However, this solution has a major drawback, which is the reason why we did not use it in the first place: WSUS will not be able to run its health checks, because the server now thinks that the health-check pings are coming from a different host. You will see this in form of the following symptoms: The WSUS log file will be full of messages like "Ping method is only available from local machine" and the event log will contain the following messages:

• "The SimpleAuth Web Service is not working."
• "The Client Web Service is not working."
• "The DSS Authentication Web Service is not working."
• "The Reporting Web Service is not working."
• "The Server Synchronization Web Service is not working."
• "The API Remoting Web Service is not working."

WSUS should still work correctly though. If you have to choose this configuration mode, you might want to deactivate the health check in order to get rid of this error messages. You can run the following commands to switch the corresponding health checks off:

WINS reports initialization error

The WINS server might log a message on each startup: "The WINS Server could not initialize security to allow the read-only operations."

This happens if it cannot find the "WINS Users" group. As suggested here, this can be fixed by just creating a group with that name.

Active Directory and Disk Write Cache

The Active Directory Domain Services might log a warning message in the event log:

• Active Directory Domain Services could not disable the software-based disk write cache on the following hard disk.
  Hard disk: c:
  Data might be lost during system failures.

This might happen if the server runs in a virtual machine: As explained by this article about running a domain controller in Hyper-V, the hard-disk cache cannot be (reliably) deactivated on a virtual hard-disk. However, if this situation is detected, critical write operations can still be performed in write-through mode. If running on a Windows Server 2008 R2 or Windows Server 2012 Hyper-V host, an update needs to be installed because otherwise Active Directory Domain Services might incorrectly assume that the write cache has been disabled, which can lead to the catastrophe described in the article.

This issue has also been discussed in the TechNet forum.

I got the warning message mentioned earlier on a DC running in as a guest under Linux KVM on Ubuntu 12.04 LTS. So it seems that Linux KVM is correctly reporting that the write-cache cannot be disabled, at least when using up-to-date virtio drivers. In fact current versions of Linux KVM will also handle the write-through flag on write operations correctly and tell the disk controller or hard disk to commit the changes to disk before reporting success, irrespective of the cache settings.

Installing an SSL certificate for Remote Desktop

When using Remote Desktop for remote administration, it is nicer if the certificate used by the server is signed by a certificate authority trusted by the client. As long as Remote Desktop is used over trusted connections only, it is not so important, however, if you have your own PKI already, it makes quite some sense to still do it.

Installing the certificate into the computer's trust store is pretty straight-forward. However, how can we tell the Remote Desktop server to actually use the certificate? Unlike Active Directory Domain Services, is does not automatically pick up the certificate, but continues to use its self-signed certificate.

I found the answer on Server Fault:

The SHA1 finger-print of the certificate needs to be set in the Remote Desktop configuration through WMI. From the command prompt, this can be done with the following command:

THUMBPRINT has to be replaced by the SHA1 finger-print of the actual certificate (with all spaces removed).

The answer on Server Fault also mentions a PowerShell command:

However, in contrast to the command-prompt version, the PowerShell variant did not work for me.

If neither of the two work for you, there is a third variant (Remote Desktop Services Blog - look for the comment by Sergey Kuzin): The finger print can be directly set in the registry: By adding HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SSLCertificateSHA1Hash of type binary and putting the finger print in (in the editor you can use the hex number as they are displayed in the certificate details). In this case, you also have to manually grant access to the certificates private key by right-clicking it in the certificate store and choosing All Tasks → Manage Private Keys.... You should add the read privilege for the NETWORK SERVICE user.

Enabling LDAP request signing

A knowledge-base article explains how to enable request signing. However, if non-Microsoft clients (e.g. Apache Directory Studio) are used, this can cause problems. However, request signing can still be enabled, if these clients are configured to connect using SSL.

In order for this to work, a valid SSL certificate has to be installed to the certificate store of each domain controller. This will turn on SSL on the server side. The clients have to be configured to use SSL (ldaps) and connect to the server on port 636. In this case they will continue working without request signing, even so the corresponding options is turned on for the servers.

Windows Update Error 80072F8F

After installing the update from KB2919355 Windows Update might present an error code of "80072F8F" when trying to check for new updates. Typically, this only happens if using WSUS and if SSL/TLS (HTTPS) is enabled for the WSUS connection. Actually this can have different causes and it took me nearly a day to figure out why I got this error.

First the most common reasons:

• WSUS is running on an old (before Windows Server 2012) server and TLS 1.2 is not enabled on this server. This is the problem described in KB2959977. It should have been fixed with a new revision of KB2919355.
• There is a problem with the SSL certificate of the WSUS site (e.g. the certificate is not trusted).

In my case however, all the possible solutions I found on the Internet did not apply. In fact I had a different problem:

• The CRL distribution point listed in the WSUS's site certificate is not valid or the CRL cannot be downloaded from this URL. In my case the webserver that should serve the CRL would sent an 302 redirect instead because of a misconfiguration. Most clients do not care because they do not try to download the CRL and at least will not fail if it cannot be downloaded. It seems like the Windows Update service has changed this behavior with KB2919355, which can now cause problems that were not discovered earlier.

WSUS Crash

After installing KB3148812, WSUS might not start or crash after some time. In the event log, there is a message like:

This might be caused by a problem with the KB3148812 update. This problem is fixed by the KB3159706 update. However, even after this update is installed, there might still be problems. For example, the event log might contain a message like:

This happens because the KB3159706 update requires some manual intervention after being installed. The steps needed are described in the knowledge-base article for this update.

Improving domain controller security

There are several steps that can be done to improve the security of domain controllers. One can:

• Disabling the print spooler service on domain controllers. Usually, there is no need to print from domain controllers, and domain contollers should not act as print servers either. This can be done locally on the domain controllers or through a group policy that is linked to the organization unit containing the domain controllers.
• Removing users from the “Pre-Windows 2000 Compatible Access” group. By default, the group “Authentiated Users” is a member of this group. Plese note that this might have undesired side-effects and in some environments, it might indeed be necessary for all authentiated users to be in this group. However, in environment where it is not necessary, making sure that this group has no members (or only a few specific members) can improve security because it significantly limits what authentiated users can do (e.g. browsing the Active Directory).