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.

Scenario: During an AD migration I needed to remove all of the certificates from a migrated user’s local store which had been issued by the old domain’s CA. Not simply for housekeeping reasons but because the new domain makes use of credential roaming and we didn’t want a load of old certificates taking up space in AD for no reason.

The following code will remove all certificates issued by from the Personal (My) store of the currently logged in user. If you wanted to narrow the criteria you can also filter on any of: Subject, Issuer, Thumbprint, FriendlyName, NotBefore, NotAfter or Extensions. You can also target different containers and switch between User (CurrentUser) and Machine (LocalMachine) certificate stores. As far as I’m aware there’s no way to do this for a user that isn’t currently logged in.

$Store = New-Object System.Security.Cryptography.X509Certificates.X509Store("My","Currentuser")
$certs = $store.certificates | ?{$_.Issuer -eq "CN=My Issuing CA 1, DC=my, DC=domain"}
$certs | %{$store.remove($_)}

See also https://www.angryadmin.co.uk/?p=600

Because it’s about time I did it. Sorry people with browsers that still don’t support SNI (not that they can read this), but it’s time to move forward.

If you’re running Server 2012 R2 in a vSphere 5.5 environment with version 10 hardware then you may have been greeted by this sight after a reboot (typically after installing Windows Updates):
Server 2012 R2 Boot Screen

Well you’re not alone, it’s a known issue with v10 hardware and multi-vCPU Windows 8/8.1 and Server 2012/2012 R2 VMs as documented here: http://kb.vmware.com/kb/2092807 – in essence if your VMs have been more than 2 or 3 months without a power cycle (either full Power Off or hard Reset) then there’s a very good chance it’ll hang on start-up after a soft reset.

The fix is fairly straightforward but you have to apply it to every affected machine as there doesn’t seem to be a way to set it globally – hopefully this will be fixed in vSphere 6 when it arrives.

If you’re using certificate-based authentication for your wired or wireless network and have the Lync 2013 client installed then you may find that your users start getting prompted to select a certificate when connecting to the network for the first time. This is because the Lync client issues users certificates with blank Subject fields and Windows can’t work out which certificate to use.

There’s a hotfix available from Microsoft here: http://support.microsoft.com/kb/2710995/en-us but unfortunately it’s not available via WSUS so you’ll have to push it to your clients “manually”. Personally I would have thought that certificate-based wireless authentication in environments running Lync were relatively common, enough to justify a proper patch, but apparently not.

I spent a while recently wondering if it was possible to have certificates follow users between machines, in this case certificates used for 802.1x authentication, because I didn’t want our CA issuing a new certificate every time a user logged onto a new machine. It seemed logical that such a facility must exist but I couldn’t find anything useful until I stumbled upon it almost by accident while looking for something else certificate-related.

What I was after is Credential Roaming, which is basically a roaming profile system for certificates (and saved user credentials but that wasn’t really a consideration). Once enabled, credential roaming will store user credentials attached to their AD account object and download them to the local machine on logon, then on log off sync everything back up to the AD object again. Obviously there are things to consider here, especially if you have a lot of users and they have a lot of certificates, but you can set limits on the maximum store size (the default is 64k) and certificates are pretty small anyway – plus most of the features only work with Vista and later, but frankly if you’re still running XP then you’ve got to expect things not to work properly.

As per http://support.microsoft.com/kb/2921141, you cannot install the Exchange 2013 management tools onto a machine running Terminal Services. It’s unclear why.

Sure, it’s not as important as it used to be, what with the EAC now being a web interface, but it does mean you can’t easily install the Powershell modules and have to rely on Powershell Remoting which works fine but is much more of a pain in the arse to set up.

I’m amazed that I haven’t previously had a need for something like this, but I was looking for some way to visualise AD group memberships, specifically to take into account fairly deeply nested groups. After a fair bit of searching, a lot of dead-ends and some products that seriously over-sold themselves, I came across this little beauty:


It’s a Powershell module which extracts group memberships for a User, Group or OU (well, everything in that OU anyway) and creates a Graphviz file that gives a functional, if not very pretty, visualisation of the group membership hierarchy. The output looks something like this:

Sample output

Extremely handy if you’re trying to get a better idea of how your group nesting shakes out or where you may have circular memberships or redundant groups.

Quick and easy; Exchange creates an environment variable called “ExchangeInstallPath” which holds the install path for Exchange on a given server, this can be accessed via Powershell using $env:ExchangeInstallPath.

This can be useful if you need to call elements such as RemoteExchange.ps1 but aren’t sure if Exchange has been installed to the default location.

Update: Fixed it for a while, then it broke again. Come to the conclusion that the Windows 7 Task Scheduler is just irreparably broken as I’ve had this happen time and time again. Some 3rd party application is interacting with it in a way that reliably breaks it and I’ve never been able to narrow it down.

Yes, this one again.

When you open up the Task Scheduler, you get a message that says:
“The selected task “{0}” no longer exists. To see the current tasks, click Refresh.”

And you can’t view half your tasks any more, though if you run a SCHTASKS /Query /FO LIST you’ll see that they’re all still there and seem to be working.

I’ve toyed around with a lot of different solutions for this, but I’ve finally found one that fixed it for me:

Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Tracing\SCM\Regular and set or add REG_DWORD TracingDisabled to 0 and then reboot.

My only concern is that this may be generating a trace log somewhere, but I’ve been unable to find anything that suggests this is the case so far.