I’ve just completed my first ADFS 4.0 implementation and I’m quite astonished at just how many stupid, petty and easily resolved bugs it suffers from.

Case in point, if you change the service certificate it doesn’t change the https certificate bindings. This means that even though your ADFS server is using your new certificate for its communications, the web service is still using the old one. It’s not IIS any more so you have to manually recreate the bindings via netsh.

There also seems to be a bizzare issue that only affects IE whereby if your ADFS farm name DNS record is a CNAME rather than an A record, any authentication attempts will fail with a 400 BAD REQUEST error. This doesn’t affect other browsers because why would it, it’s a fucking mental thing to do.

If you’ve configured the Server Authentication Certificate Template GPO option, which determines the certificate that the machine uses for Remote Desktop connections, and applied it to 2008 R2 or older servers then you may find that you’re getting a lot of duplicate certificates being issued. It’s a problem with an easy solution but it’s not an obvious one.

You see, if you read the documentation for the setting (something which is helpfully not included in the GPO explanation text in the GPMC) you’ll soon discover that:

You must set the certificate template’s attributes Template display name and Template name to the same value.

Due to a disparity in the way the API checks to see if a certificate already exists on the machine for this purpose if the Template Name is not the same as the Template Display name it fails to identify that it already has a matching certificate and so requests a new one.

This problem is resolved in Server 2012 R2. It’s possibly resolved in Server 2012 as well but I don’t have a box to hand I can test with.

As far as I can tell the “Do not automatically reenroll if a duplicate certificate exists in Active Directory” option has no impact on this issue.

I’m doing a lot of Group Policy work at the moment (who’d have guessed) and I’ve run into an old friend of mine: The 2008R2/Win7 Group Policy Management Console keyboard bug. As Microsoft put it:

  • You have a computer that is running Windows 7 or Windows Server 2008 R2.
  • You customize a Microsoft Management Console (MMC) that has the Group Policy Management Console (GPMC) snap-in. (As far as I can tell it happens just as often with the provided gpmc.msc)
  • You select any Group Policy object (GPO), and then you click the Settings tab in the details pane.
  • You select another node in the console tree, and then you use the BACKSPACE or arrow keys to perform some operations.
  • In this scenario, the BACKSPACE or arrow keys do not work. You have to use the mouse to perform operations.

Which is extremely annoying, as you might imagine. As with many of their Known Issues, Microsoft have opted not to make a generally available patch for this, probably because it affects such a small proportion of their users. Nonetheless, there is a Hotfix available for it, which can be acquired here: http://support.microsoft.com/kb/2466373

If you do any serious amount of GPO work on a Windows 7 or 2008 R2 box, you will want to install it.

Update: As of today (25/01/2012), my Nexus One has been updated with 2.3.6, which has fixed autocomplete. Hooray!

If you have a Nexus One and update it from 2.2 to 2.3.4 then you’ll probably have found that auto-complete no longer works for anything other than contacts. Apparently this is a known issue and HTC are working on a fix (see discussion here: http://www.google.co.uk/support/forum/p/Google+Mobile/thread?tid=6bda468f71a58bfd&hl=en) but until then the only workaround is to install a 3rd party app thus:

How about a little more testing next time, eh?

Update: There is a hotfix now available to address this issue, though you have to ring MS support directly to get hold of it at the moment. The plan is to roll it into an IE9 update in the near future. More details can be found here

There is a known issue with the Exchange 2007 and Exchange 2010 Management Consoles on machines with Internet Explorer 9 installed. This issue causes you to recieve the error: “You must close all dialog boxes before you can close Exchange Management Console.” when trying to close the EMC even though there aren’t any dialog boxes open.

As it stands, there are several workarounds: You can uninstall IE9, you can kill the MMC process from task manager every time and a few people have reported success with turning off “Internet Explorer Enhanced Security Configuration” for Administrators and Users (Servers only) and then adding https://localhost to the “trusted sites” in IE.

According to the Senior Program Manager for Internet Explorer Product Quality, Mark Feetham:

[…]we do now understand what’s occuring between the EMC, MMC and MSHTML. We have enough information to complete the investigation and have moved to looking at ways to improve this situation.

Rumoured ETA for a fix is Q4 2011.