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.



Update: Please note that the up-to-date version of this blocklist is maintained here, this post will not be updated with any future changes to the Nobis ranges.

Just when you think you’ve finally blocked all of the Nobis Technology Group’s (aka Ubiquity Server Solutions) IP ranges they go and take over another range and carry on merrily spamming your comments section.

So, I’ve taken the nuclear option and blacklisted every IP range associated with AS15003 (which is their AS) as per the very helpful http://bgp.he.net/AS15003#_prefixes – yes, they really do have 867 IPv4 netblocks allocated to them.

I’ve collapsed the ranges down to a slightly more manageable 119 (there are a lot of contiguous blocks in there) and added it to my blocklist page, it’s also reproduced below, so help yourselves.

#Nobis/Ubiquity Ranges - http://bgp.he.net/AS15003#_prefixes
Deny from 23.19.0.0/16
Deny from 23.80.0.0/16
Deny from 23.81.0.0/17
Deny from 23.81.128.0/18
Deny from 23.81.192.0/20
Deny from 23.81.216.0/21
Deny from 23.81.224.0/19
Deny from 23.82.0.0/16
Deny from 23.83.0.0/17
Deny from 23.83.128.0/18
Deny from 23.83.192.0/20
Deny from 23.104.0.0/14
Deny from 23.108.0.0/15
Deny from 23.110.0.0/16
Deny from 23.111.251.0/24
Deny from 23.224.0.0/15
Deny from 23.226.48.0/20
Deny from 23.235.128.0/18
Deny from 23.248.192.0/18
Deny from 64.120.1.0/24
Deny from 64.120.2.0/23
Deny from 64.120.4.0/22
Deny from 64.120.8.0/21
Deny from 64.120.16.0/20
Deny from 64.120.32.0/19
Deny from 64.120.64.0/19
Deny from 64.120.96.0/20
Deny from 64.120.112.0/21
Deny from 64.120.122.0/23
Deny from 64.120.124.0/22
Deny from 67.201.0.0/21
Deny from 67.201.48.0/23
Deny from 69.31.107.0/24
Deny from 69.147.224.0/23
Deny from 69.147.227.0/24
Deny from 69.147.228.0/22
Deny from 69.147.232.0/21
Deny from 69.147.240.0/22
Deny from 69.147.244.0/24
Deny from 69.147.246.0/23
Deny from 69.147.248.0/21
Deny from 69.174.60.0/22
Deny from 70.32.32.0/20
Deny from 72.37.204.0/24
Deny from 72.37.221.0/24
Deny from 72.37.222.0/23
Deny from 72.37.224.0/21
Deny from 72.37.237.0/24
Deny from 72.37.242.0/23
Deny from 72.37.246.0/23
Deny from 74.113.144.0/22
Deny from 108.62.0.0/16
Deny from 108.171.33.0/24
Deny from 108.171.34.0/23
Deny from 108.171.36.0/23
Deny from 108.171.38.0/24
Deny from 108.171.43.0/24
Deny from 108.171.44.0/22
Deny from 108.171.53.0/24
Deny from 108.171.54.0/23
Deny from 108.171.56.0/24
Deny from 108.171.59.0/24
Deny from 108.171.60.0/23
Deny from 108.171.63.0/24
Deny from 108.177.128.0/17
Deny from 108.187.0.0/16
Deny from 142.91.0.0/16
Deny from 142.234.0.0/16
Deny from 147.255.0.0/16
Deny from 162.209.128.0/17
Deny from 162.222.68.0/22
Deny from 172.240.0.0/15
Deny from 172.247.0.0/16
Deny from 172.255.0.0/16
Deny from 173.208.0.0/18
Deny from 173.208.64.0/19
Deny from 173.208.96.0/21
Deny from 173.208.104.0/24
Deny from 173.208.106.0/23
Deny from 173.208.108.0/22
Deny from 173.208.112.0/20
Deny from 173.234.0.0/18
Deny from 173.234.64.0/20
Deny from 173.234.80.0/21
Deny from 173.234.88.0/23
Deny from 173.234.90.0/24
Deny from 173.234.92.0/22
Deny from 173.234.96.0/21
Deny from 173.234.105.0/24
Deny from 173.234.109.0/24
Deny from 173.234.110.0/23
Deny from 173.234.112.0/20
Deny from 173.234.128.0/19
Deny from 173.234.160.0/20
Deny from 173.234.176.0/21
Deny from 173.234.184.0/22
Deny from 173.234.188.0/24
Deny from 173.234.190.0/23
Deny from 173.234.192.0/18
Deny from 174.34.128.0/19
Deny from 174.34.160.0/20
Deny from 174.34.176.0/21
Deny from 174.34.184.0/22
Deny from 174.34.188.0/23
Deny from 174.34.190.0/24
Deny from 192.151.224.0/20
Deny from 192.151.248.0/21
Deny from 192.161.80.0/20
Deny from 192.163.160.0/19
Deny from 192.229.64.0/18
Deny from 192.238.128.0/17
Deny from 192.253.240.0/21
Deny from 196.45.112.0/22
Deny from 198.48.96.0/20
Deny from 198.48.112.0/22
Deny from 216.6.224.0/20
Deny from 216.151.31.0/24
Deny from 216.152.224.0/20
Deny from 216.193.237.0/24
#End of Nobis/Ubiquity Ranges

No doubt they’ll buy up more IP space as needed so they can continue to sell their services to spammers, malware distributors and other disgusting excuses for human beings.



You may remember my post a while back about issues with applying Exchange 2010 SP1 in situations where you were using Group Policy to control Powershell Execution policies. Specifically, this issue occurs because the Group Policy setting uses the WMI service to enforce the Execution Policy and as part of the Exchange install/upgrade process, the WMI service is stopped, causing the Execution Policy to revert to Restricted and the following error to pop up and the install to fail:

The following error was generated when "$error.Clear();
& $RoleBinPath\ServiceControl.ps1 EnableServices Critical
" was run: "AuthorizationManager check failed.".

Well it turns out that this still applies with Exchange 2010 SP2 in exactly the same fashion.

The (well, A) relevant KB article is here but the “workaround” is a bit half-assed to be honest and you’re much better off just disabling the associated Group Policy setting and configuring the Execution Policy locally (with set-executionpolicy) to either AllSigned,RemoteSigned or Unrestricted for the duration of the upgrade.

Why Microsoft cannot add installer logic to check for this possibility, especially given how long it’s been a potential problem, is beyond me but then I’m not an Exchange developer.



My spam Blocklist has been slowly growing since I created it in order to stem the tide of comment spam coming from Nobis/Ubiquity Server-owned address blocks. Ultimately I made the choice to block all the netblocks that they had allocated from ARIN and that seemed to have worked, up until today when I started getting comment spam from some brand new Nobis/Ubiquity addresses.

It would seem that they’ve got themselves a netblock from RIPE and started using that for spamming as well; the range in question is 176.31.50.64/27 but given their apparent dedication to illegal activity, it wouldn’t surprise me if others start popping up here and there as well. Thankfully, the relative scarcity of available IPv4 blocks is making it much tougher for these spamming fuckers to evade blocking mechanisms without resorting to botnets.

That said, when you’re getting more than 10 times as many spam comments as legitimate ones, it doesn’t exactly fill you with confidence that we’ll ever get a real handle on the problem.



OK, so Adobe’s Flash Player downloads have always been crappy; half the time you can’t find the download for non-IE browsers and the other half of the time you’re forced to use the Adobe Download Manager to get it, but I think they’ve managed to outdo themselves now.

If you go to download Flash Player from the Adobe website (http://get.adobe.com/flashplayer) and you’re not running IE, you’re presented with some drop-down boxes asking you to pick your OS and Browser (IE or Other). If you pick “Windows 7 (64-bit)” – as well you might if that’s the OS you’re running – then you get given the 64-bit version of Flash Player, which won’t work for 95% of users and won’t be clear why, so you have to pick “Windows 7 (32-bit)”, obviously.

You then download the installer and run it, at the end of which, the installer deletes itself, presumably because they realise that it’s such an insecure piece of crap that by the time you come to install it on a 2nd machine 3 minutes later, there’s already a new version out.

To make matters worse, the MSI distribution points (such as http://www.adobe.com/go/full_flashplayer_win_msi) are still Flash 10.x instead of 11 and the old http://fpdownload.adobe.com/get/flashplayer/current/ links now 404.

I’m already trying to get rid of Flash Player, I’m using Youtube’s HTML5 trial and making use of alternative options where ever possible, but it’s like Adobe is actively trying to help me stop using it.

Fuck You Adobe.



As you probably know, Outlook 2003 and older use Exchange Public Folders for their Free/Busy data and Offline Address Book. You may also know that Exchange 2007 and Exchange 2010 have deprecated Public Folders in favour of an HTTP-based distribution method for the data, which Outlook 2007 & 2010 fully support.

One could then reasonably conclude that removing public folders in an Exchange 2007 or Exchange 2010 environment might negatively affect Outlook 2003 and older clients. This is technically correct, though the reality is slightly more dramatic; it completely blocks Pre-Outlook 2007 clients from connecting to your Exchange servers and presents the users with a handy “Your administrator has blocked this version of Outlook from connecting” message.

What this all means is that if your support team have spent the last year lying to you every time you’ve asked them how they’re progressing on upgrading all the remaining Outlook 2003 installs to 2007/2010 then when you remove the last public folder store from your Exchange environment you’ll suddenly have hundreds of people whose can no longer access their emails. This, for some reason, upsets them.

The moral of this story is that you should never trust what people tell you, because they’re almost always lying bastards, and make sure you verify the information for yourself before making any changes. Yes, it’s a lot of work and no, you shouldn’t have to do it, but it’s always you that gets the flak when it all hits the fan.



Given that my blog is relatively low traffic, it’s remarkable just how many spam comments and hacking attempts I log daily. A good 50% or more of all the spam comments I get originate from the same place: Ubiquity Server Solutions/Nobis Technology Group, who share a couple of overlapping IP ranges and are somewhat notorious if my brief Googling is anything to go by. I’m a big fan of Hanlon’s Razor, but in this case I’m really not sure either way.

So, as of today, their entire ranges are blacklisted:

Deny from 173.208.100.0/22 #Ubiquity Server Solutions
Deny from 108.62.0.0/16 #Nobis Technology Group

I don’t like having to block entire /16 ranges because I know there are bound to be false positives in there somewhere, but frankly it’s the only way to make things manageable right now.

I expect to see my error.log grow exponentially over the next few days.

Update: And another range of theirs that was still spamming me…

Deny from 173.234.0.0/16 #Nobis Technology Group

Update: And yet another…

Deny from 23.19.0.0/16 #Nobis Technology Group

Update: Guess who…

Deny from 64.120.0.0/17 #Nobis Technology Group

Update: Right, let’s make this simple; courtesy of ARIN’s WHOIS Database

#All Nobis/Ubiquity ARIN Netblocks
Deny from 70.32.32.0/20
Deny from 67.201.48.0/23
Deny from 72.37.145.0/24
Deny from 173.208.0.0/17
Deny from 69.174.60.0/22
Deny from 174.34.128.0/18
Deny from 173.234.0.0/16
Deny from 108.62.0.0/16
Deny from 72.37.224.0/21
Deny from 23.19.0.0/16
Deny from 72.37.237.0/24
Deny from 72.37.218.0/23
Deny from 72.37.222.0/23
Deny from 72.37.221.0/24
Deny from 67.201.0.0/21
Deny from 72.37.242.0/23
Deny from 67.201.40.0/24
Deny from 72.37.246.0/23
Deny from 216.6.224.0/20
Deny from 72.37.204.0/24
Deny from 69.147.224.0/23
Deny from 64.120.0.0/17

Update: My complete comment spam blocklist is now available here.



  • Who has 1,450 login scripts (For 3,500 users at that)?
  • Who puts account passwords in the account’s description field? (for anyone who doesn’t know why this is appallingly bad, try this PowerShell as a regular domain user from a box with the Win7/2008R2 RSAT tools installed: ipmo activedirectory;get-aduser -filter * -Properties description, other scripting languages are available)
  • Who doesn’t use Domain Admins for their domain administrators and instead uses Account Operators, Administrators, Network Configuration Operators, Remote Desktop Users & Server Operators? (Not for granular permissions, all of them as a replacement for Domain Admins membership)
  • Who leaves 5,500 computer accounts, including servers, in the Computers container in AD? (ProTip: You can’t link GPOs to the “Computers” container in AD)
  • Who doesn’t have any actual DHCP servers in their Authorised DHCP Servers list? (Not even sure how you manage this one)

This isn’t just bad practice, this is years of dedicated training and substantial investment in bad practice…

I’m going to go curl up in a corner and cry for a while now.



I have previously completed some work for a mid-sized organization and some of the things I’ve come across in the few shorts weeks I’ve had access to their systems are, frankly, astonishing. I’ve barely even scratched the surface and we’re already well into “so bad it’s not even wrong” territory here; a few examples:

  • Critical Servers not under warranty
  • Critical Servers not backed up
  • Servers backed up to disks on the same disk array as the live data
  • Backups taken to tape and then left in the tape loader indefinitely
  • Servers not patched, ever
  • Antivirus not installed on servers, or installed but disabled “for performance reasons”
  • Server hardware/software not monitored
  • Speed/Duplex on all network interfaces set manually
  • Public address ranges for internal network addressing
  • A single broadcast domain for all devices on the network
  • 120m+ Ethernet cable runs
  • Cat3 cable runs within the core infrastructure (undocumented)
  • New user credentials sent by email, via an externally hosted mail system, to user’s line manager
  • All IT Staff granted unaudited access to the entirety of the file servers
  • All IT Staff local admins on all servers

And that’s just the stuff I’ve found so far and haven’t already repressed. I honestly have no idea where to begin, if there were such a thing as a Worst Practice Guide they’d have not only followed it to the letter, but added their own extensive appendices as well.