In the project I’m currently involved in, we have several virtual machines installed with Windows 7 as the operating system. These workstations are used as administration workstations to manage the server infrastructure. Every once and a while someone would get disconnected from their terminal server session. By simply reopening the session they could continue their work. We stumbled upon the following KB article: KB2083411 The article states:

When the policy is refreshed (by default, every 90 minutes, or manually through GPUPDATE), the policy settings are deleted and then reset. During this period, the configuration on the server is temporarily valid. Therefore, all sessions may be disconnected

Because we were enabling remote desktop through GPO, this was the exact issue we were having.  We could reproduce it by executing gpupdate in a remote desktop session. The disconnection would not occur every time, but every once in a while. To be more precise when enabling remote desktop through group policies (Allow users to connect remotely using Terminal Services ), the following registry key is set:

The workaround suggested in the KB article is to set the registry key fDenyTSConnections below HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server to a value of 0. Basically this is just enabling remote desktop through the registry instead of through the GUI.

If you have to do this on a lot of workstations there are a few options. We first thought to just deploy this using our desktop deployment solution (SCCM). However a colleague of mine had the great idea to just try setting it using group policy preferences. Whenever group policies are being refreshed, everything below HKLM\SOFTWARE\Policies is erased and reset, but group policy preferences operate in an other way. Whenever you set something with group policy preferences, it’s set forever, unless you check the option “remove this item when it is no longer applied”. For some additional information on the differences between GP policy setting and GP preference settings.

Here are also some related topics on the TechNet forums: http://social.technet.microsoft.com/Forums/en/winserverGP/thread/10fb967c-c6c8-480b-8d30-70f0da15cdba and http://social.technet.microsoft.com/Forums/en/winserverGP/thread/cd94ea99-a843-4781-bbcf-7538182511c9

A colleague of mine was trying to configure the NPS (Network Policy Server) role on two Windows 2008 R2 servers (domain controllers) in order to allow the wireless clients to be authenticated. One of the requirements for Protected EAP is a certificate on the server hosting the NPS role. He told me has was seeing a certificate in the personal store of the computer, but he kept receiving the following error: Cannot configure EAP: A certificate could not be found that can be used with this Extensible Authentication Protocol. when trying to select a certificate.

We found out that the NPS role doesn’t like the new Domain Controller Authentication certificate which is supposed to be more or less equivalent to the domain controller certificate from the past.

I’ve configured this a few times in the past, and whenever we were combining the NPS role with a DC I always used the “domain controller” certificate present on the DC. This works just fine. If nobody changed the default auto-enrollment settings in the domain, they should look like this:

A Windows 2008 R2, Enterprise Certificate Authority will have the following templates published by default, I highlighted the relevant ones for Active Directory: Domain Controller, Domain Controller Authentication and Directory Email Replication.

This was different for Standard SKU Windows 2008/2003 Enterprise CA’s, they only had the “domain controller” certificate listed. This was because standard SKU’s couldn’t use V2/V3 templates. You can see the difference in versioning between these templates in the template management mmc. Smaller than 100 means it’s a V1 template:

Here is how the local certificate store of a domain controllers looks like when no auto-enrollment options are configured:

As you can see there’s only one certificate available based on the Domain Controller template. Even without autoenrollment configured a domain controller will try to enroll for such a certificate. This is hardcoded in the domain controller. Just like an EFS client will try to retrieve an EFS certificate. My colleague wasn’t having one certificate though, he was seeing two:

The reason these were enrolled is because auto-enrollment was configured like this:

The checkbox “Update certificates that use certificate templates” enables autoenrollment for issuance of certificates that supersede issued certificates (TechNet: Configure Certificate Autoenrollment). Because both the Domain Controller Authentication and Directory Email Replication templates are configured to supersede the domain controller certificate, a domain controller will no longer have a certificate based on the domain controller template.

The requirements for an EAP certificate are specified in KB814394: Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS. The reason the NPS console doesn’t seems to accept it, is because the Subject is left empty in the Domain Controller Authentication certificate:

I have no idea why they did this, my guess is that they duplicated the domain controller template and forgot to set it. It can be easily set to the domain controller name in a duplicated template:

My advise would be to create a custom template for the NPS servers. This way you can ensure your NPS configuration never becomes invalid because the domain controller certificate is replaced.

P.S. When testing auto enrollment, make sure to execute a gpupdate /force, a gpupdate without the /force doesn’t seem to trigger the auto enrollment process.

Thomas

As explained in FIM 2010 SSPR Enforces Password History FIM 2010 can now be configured to enforce the password policies configured in the domain. After implementing this, the first thing you want to do is grab a test account and start testing. You’ll be happy to see the following message after trying to perform a reset with a password which was used before:

It says: “The password you entered does not comply with the security policy. Please choose a new password or check with your system administrator for details on the password policy requirements”.  So you go on and try a different password. One which hasn’t been used in the past of course. Still the above message appears. Now I’ll be damned, my SSPR is broken! But is it?

There seems to be a simple explanation: as stated in KB2386717 (The "Enforce password history" and "Minimum password age" Group Policy settings do not work when you reset the password for a Windows Server 2008 R2-based computer) not only the Password History is enforced, also the Minimum Password Age is enforced. Meaning you can only reset a password once a day for example. In the screenshot I altered this (temporarily) to 0 days so I could reset a password multiple times. But in our actually policy the Minimum Password Age is 1 day, in the screenshot below I temporarily disabled it by setting it to 0.

This is actually a pretty nasty setting when testing SSPR. Well if the error would say “you can only reset your password once a day, please contact an administrator” that would be a lot better. Of course FIM is not to blame here, this is Active Directory. Whenever you try to change your password at the ctrl-alt-del screen, you’ll get the same message popping up. I can imagine you don’t want to give to much information in your errors as to avoid malicious people being pointed in the good directions…

To be completely honest this subject has been blogged a lot in the past. However just this Friday I helped a colleague which was having issues setting up DNS aliases for SQL. He seemed to have troubles connecting his Management Studio to SQL. And today I could use the information again when working at a customer which was having issues authenticating to his webserver. So I believe this is still solid information to spread.

So if you hit google with "disableloopbackcheck windows 2008 R2” you get quit some results. And if you search the official KB articles, this registry setting is referenced a lot when dealing with Access Denied errors locally on a machine. All these scenario’s have one thing in common: someone or some service is trying to access a service under an alias and this from on the machine itself.

Simple example scenario: you set up Active Directory Certifcate Services and you choose “pki.contoso.com” as an alias for your Certificate Authority server. After configuring this record in DNS, you try to access this website http://pki.contoso.com/certsrv on the CA itself in vain. After trying to provide correct credentials multiple times it just fails. You are getting that nasty “HTTP Error 401.1 – Unathorized You do not have permission to view this directory or page using the credentials that you supplied”.  Accessing this from a remote workstation using the same credentials works just fine.

If this is your problem, are it sounds similar, then this is your solution:

• kb926642: You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version
• kb926642: Error message when you try to access a server locally by using its FQDN or its CNAME alias after you install Windows Server 2003 Service Pack 1: "Access denied" or "No network provider accepted the given network path"
• kb887993: Users experience authentication issues when they access a Web page in IIS 6.0 or query Microsoft SQL Server 2000 after you install Windows Server 2003 Service Pack 1
• kb914060: A logon window appears in Windows Server 2003 Service Pack 1 NLB when you try to browse the virtual NLB cluster name
• kb971382: Errors when crawling content sources in SharePoint Server 2007: "Event ID 2436" and "Access is denied"

And the list goes on. The workaround is very easy and active immediately: just create a REG_DWORD called DisableLoopbackCheck below HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and give it a value of 1

One of the articles actually references the DisableStrictNameChecking registry key. I remember setting this one when accessing a share didn’t worked when using an alias. Must but it’s older brother. Here’s an explanation: kb281308: Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name The reason we’re probably hearing this one a lot less is because since SMB 2.0 (Windows 2008 and up)  this is no longer required.

At my company (RealDolmen) we use Microsoft OCS for internal communication. I’ve been using Office 2010 for a while now, and one of the things that bugged me is that the OCS client kept complaining about a required update (KB936864). This is a bit odd as this hotfix is for Outlook 2007 and is not applicable to Outlook 2010. After using my google skils I found the following TechNet thread:
http://social.technet.microsoft.com/Forums/en/ocsinterop/thread/1476cca6-5d30-4600-8ef7-80dca443d3ea

The above notification can be easily fixed with uninstalling the “Microsoft Office Access database engine 2007” software.

Update [27/06/2013]: new information regarding the topic: Windows 7 & Reverse Lookup DNS Registration [Update]

In my current project we have an Active Directory domain where we use Windows DNS servers with domain integrated DNS zones. For the reverse lookup zones we configured secure only updates. As the DHCP servers in this environment are Linux based we would like the clients to update their PTR records themselves. Updating the PTR records means a client registers his name and IP in the reverse lookup zone.

As we noticed that only Windows 7 workstations with a static IP were being registered we started troubleshooting. As an AD guy I was 100% confident we could get this done using GPO’s. However in the past I have seen strange behavior with the GPO settings below Administrative Templates\Network\DNS client section, and today was just the same. Getting this done is not that obvious.

Below Computer Configuration > Policies > Administrative Templates > Network > DNS Client there is a setting called “Register PTR Records”. One could think that this is pretty easy to configure, enable, throw a gpupdate in and off we go. The setting with some additional info:

Although the policy came through just fine, even after a reboot, my client was not registering his PTR record… So I used my 24/7 available free of charge consultant-helpline called google. I stumbled upon the following topic (http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/3a1c9334-54ba-4845-b7c0-ef8ce5454276) where L Ravie Kumar [MSFT] states:

The behavior of Client not registering PTR record by default is modified prior to Windows7 (mostly during Vista time) and is the intended behavior. The Dhcp Server is responsible for performing PTR record registration on behalf of client. Incase if dynamic DNS registration is not enabled on Server (because of which Server doesnot do PTR registration), Client can trigger registration,if "Use this connection's DNS suffix in DNS registration" is selected in adapter properties.

After checking “Use this connection’s DNS suffix in DNS registration” in the advanced TCP/IP settings all went fine. The record appeared in the reverse DNS zone as expected. Even without the above GPO setting configured. I do think you can use the GPO if you want to fine-tune the registration behavior as it contains 3 options.

So all we have to do is implement this in bulk. I haven’t found a way to do this by GPO, I might have missed it though. I thought GPO preferences would be the easiest way, but this setting is located below HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\{GUID}\RegisterAdapterName and the GUID is different for each system… So no luck there.

The following command can be executed in order the check the required option:

netsh interface ipv4 set dnsservers name="Local Area Connection" source=dhcp register=both

In our environment we deploy all workstations using SCCM so the above is definitely a reasonable solution.