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.



It would appear that the Exchange 2010 EMC isn’t particularly bright; when you launch it, it picks a CAS to connect to from AD. This is fine.

However, should that server cease to exist, by which I mean Exchange is uninstalled and it is properly decommissioned, then the EMC will continue to try and connect to it. Even after the connection fails, it’ll keep on merrily plugging away at the non-existent server, never considering that there are probably other servers it could try.

This is very annoying and seemingly very stupid behaviour. To work around it, close the EMC, fire up your registry editor of choice, locate the following key: HKCU\Software\Microsoft\Exchangeserver\v14\AdminTools\ and delete the NodeStructureSettings value. This will reset the EMC and cause it to pick a new CAS to connect to; it may also affect other settings that you’ve changed in the console.

Another option is to close the EMC, navigate to C:\users\<username>\AppData\Roaming\Microsoft\MMC\ and delete the Exchange Management Console file. This will also reset the EMC and will definitely reset any customisations you’ve made to the console.

Why you should ever have to do this is something of a mystery to me, perhaps Microsoft just never expected anyone to decommission an Exchange server once it was built.