If you’ve ever looked at configuring the Exchange Availability Service to allow cross-forest free/busy lookups you’ve probably realised that the documentation surrounding it is awful.

Get-MailboxServer | Add-ADPermission -Accessrights Extendedright -Extendedrights "ms-Exch-EPI-Token-Serialization" -User "<Remote Forest Domain>\Exchange servers"

From here, doesn’t even work for a start, because Get-MailboxServer doesn’t return the correct identity objects for Add-ADPermission. Once you’ve worked out how to get that sorted and done your

Add-AvailabilityAddressSpace -Forestname ContosoForest.com -AccessMethod PerUserFB -UseServiceAccount:$true

You’re probably thinking that you’re done, but it usually isn’t that simple. For a start if the namespaces in either forest are even a little bit complicated or you’re using a custom target address space then you’re in for some autodiscover fun – just because autodiscover works in its home forest doesn’t mean it will from your trusted partner. Before you even start, make sure your Exchange certificates are trusted by the target servers; don’t assume that just because they’re from a public CA that they will be, you never know what weird stuff has been done to the servers if you didn’t build them and they’re not under your control. Obviously if you can you should export the SCP to the partner forest with

Export-AutodiscoverConfig -TargetForestDomainController "dc.contoso.com" -TargetForestCredential (Get-Credential) -MultipleExchangeDeployments $true

But even then there are a few things that aren’t clearly documented and might trip you up; for example, you need Outlook Anywhere enabled for the Availability Service to function, which isn’t a given if you’re still running Exchange 2010 or 2007 in one or both forests. Furthermore, if one or both parties are running Exchange 2013 or 2016 and you’re not using the SCP for autodiscover then you’ll probably find the free/busy lookups fail because:

the availability service sends an Autodiscover request by using an automatically generated SMTP address for the anchor mailbox. This SMTP address that is used is 01B62C6D-4324-448f-9884-5FEC6D18A7E2@Availability_Address_Space_domain.

However, the Exchange Server 2013 Client Access server in the attendee forest cannot locate a mailbox for this email address and responds with a 404 status.

That’s right, Exchange uses an essentially random (and as far as I can tell only documented in that KB article) SMTP address for it’s autodiscover query which is rejected by the target server because, obviously, it doesn’t exist. The “fix”? Slap that SMTP address onto any old mailbox so the server returns a valid autodiscover response.

Hopefully this post will be of some help to anyone struggling to get the availability service working in their environment, I spent 2 weeks dicking about with Microsoft support trying to understand how it operates so that with any luck you won’t have to.



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:

Important
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.



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.



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.



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.



Bit of an esoteric one this, but might be helpful to someone anyway. If you’ve worked with Out-Gridview before you may have also made use of the NoteProperty property to collate your results prior to output; today I ran into an issue where I knew some of my output objects had 2 NoteProperties and some had 2+x NoteProperties where x was more than 0. When output to Out-Gridview or Export-CSV it was only showing the number of properties that the first object had, irrespective of how many subsequent objects had.

For example:

User Property1 Property2 Property3
Dave 43
Steve 25 62 23
John 23 263

In this scenario, all results would be output with just the User & Property1 NoteProperty displayed because Dave’s Property2 and Property3 don’t exist. You could work around this by sorting on “Property 3” so that it’s the first object in the output and thus includes all columns like so:

User Property1 Property2 Property3
Steve 25 62 23
Dave 43
John 23 263

However, this obviously only works if you know how many properties there are and I didn’t. So, I had to find a further workaround and came up with this:

$count = @()
foreach($output in $useroutput){$count += $(($output | gm).count)-5}
$max = $($count | measure -maximum).maximum
$useroutput | Sort-Object "Property$max" | Out-GridView

This iterates through your array of objects ($useroutput), counts the properties on each (minus the 4 base methods on a System.Object and the known “User” property) and then finds the highest count and sorts the output based on that highest value, ensuring that it always outputs every column even when it’s empty for most of the results.

Obviously, even this method is only useful if your properties are titled numerically, if you’re just pulling an unknown list of properties with arbitrary names, you’re probably going to have to dig a bit deeper.



In light of today’s news that OpenSSL has been pretty broken for the best part of a year (see: here, amongst others), I decided to revisit the SSL configuration on my Forefront TMG servers with regard to their published websites. Digging around the internet I came across several useful pieces of information that I thought I’d share.

First up is Qualys’ SSL Server Test tool @ https://www.ssllabs.com/ssltest/index.html, which will give you a report on the state of your SSL setup, mine had some issues mostly due to oversights on my part.

Next, is this article on ISAServer.org which runs you through some non-obvious-but-crucial security tweaks you can make to your TMG server to improve its protocol support and avoid a couple of renegotiation issues.

Finally, I was directed to the IIS Crypto tool from Nartac Software, which doesn’t do anything you couldn’t do by hand (and does go back over a couple of protocol tweaks from the previous link), but does make it one hell of a lot easier. Don’t be fooled by the name, the windows crypto settings it changes are server-wide and don’t just affect IIS.

So, with a couple of hours of work I went from an F (Oops, that’ll teach me to forget about disabling SSLv2) to an A and now properly implement PFS for clients that support it.



The ever-helpful joeware has just released a little tool for testing RDP connectivity to servers, which you can find here http://www.joeware.net/freetools/tools/rdp-sec-check/

If you don’t know about joeware, I strongly recommend checking out the various free tools he’s published, available here http://www.joeware.net/freetools/index.htm – while many of them have been superseded by the Powershell modules now available to Windows admins, if you’re not comfortable with Powershell or are working with older systems, they’re still extremely useful.