I am well aware that not everyone is an update-whore like me, but even those who generally abhor updating their beloved software will have to do it sooner or later; fixing that show-stopping bug or plugging that security hole can’t be avoided for ever. However, when it comes to installing new versions of certain software, I can’t help but feel that the developers have it in for me.

When you release a new version of your software, there are a number of ways you can facilitate upgrading from previous versions in increasing order of annoyance:

  1. Do an “upgrade” – i.e. Replace changed files, delete obsolete ones, remove cached data. For updates without an installer, this is the “unzip over the top” option (e.g. Firefox)
  2. Do an integrated remove/reinstall – i.e. As part of your installer, launch the uninstaller, remove the old files – excluding config files and user data – and then run installer as if it were a clean install. (e.g. VLC)
  3. Do an ugly remove/reinstall – i.e. Tell the user they have to remove the old version before they can install the new one, but don’t actually do it for them or tell them how to remove it or which files they need to keep. (e.g. Apache)
  4. Provide the user with a zip file of random files, some SQL scripts & a WISE installer circa Windows 3.11 and have them run the SQL scripts in a non-specific order, copy the files to some folder somewhere then run the installer to register some DLLs with Windows and randomly change some registry settings. (e.g. Every niche “enterprise” application I’ve ever come across – the healthcare software sector are masters at this)

Why is it so hard to write your updates to do #1? – or at least #2 if you really do need to remove all traces of the previous version of your software (for example, when you’re a substantial number of versions out of date or have made significant changes to your core application).

One of the 3rd party suppliers I’m dealing with at the moment sends out quarterly data updates as well as fairly regular application updates and every one of them requires an hour or so of fucking about with SQL and copying files to apply. I appreciate that many of these are 2 or 3-man shops and they don’t always have the resources to focus on this kind of thing (or, seemingly, making their applications vaguely stable), but seriously, spend a couple of days and make a solid updating framework for your app that you can use for all your future updates and save all of your users a massive headache. Please.



Windows has a centralised logging facility for applications; the Windows Event Log. If you’re writing applications for Windows then for the love of God please use it properly.

DO create your own event message DLL(s) where appropriate to avoid your events looking like this

DO log important errors and warnings. Application failures, communication issues, invalid configuration data and the like. Things that will help administrators to troubleshoot issues that may occur.

DO make your logs intelligible to someone other than you. Not having developed the application myself, I have no way of knowing if “Invalid foo in bar. More cheese needed at 0x8003387” means that someone’s made a typo in a config file somewhere, a firewall rule needs changing or that the application doesn’t support running during the vernal equinox.

DO throttle your logging. Don’t log the same error every second, it’s pointless, generates a lot of “noise” and – much worse – forces other, potentially useful events out of the log’s retention.

DO make your logging level easily configurable by the user and DO set a sensible default.

DON’T log every single informational or debug event that your application generates. Nobody gives a shit that you successfully checked a message queue and found it was empty; either use a Custom Event Log or a log file in the application directory if you want to record that kind of information.



As someone in the middle of a transition between Exchange 2007 SP3 and Exchange 2010 SP1, I have to ask; MS Exchange Team, what were you smoking when you came up with the interoperability options here?

2003 to 2007 was pretty decent, you could deploy your 2007 CAS servers more-or-less directly in place of your 2003 OWA front-end servers and they would happily serve 2003 mailboxes up to people. Management tool interop was lacking a bit, but that was excusable as 2007 was, at least, a totally new set of tools based on .NET/Powershell and they generally wouldn’t let you do anything to a 2003 mailbox that would break it horribly.

With 2007 to 2010 though, you can’t do any of that. You have to keep your 2007 CAS and HT servers around because the 2010 ones won’t play nice with 2007 mailbox servers, but then the 2010 CAS servers can’t connect to 2007 mailboxes. Except they can, if you copy the 2007 binaries onto them. Except that only works if there isn’t a 2007 CAS server in the same AD site as the 2010 CAS server. So, short of creating new AD sites for all your 2010 mailbox servers you have to have at least one AD site with both 2010 & 2007 CAS servers, which works OK internally, but if you’re publishing to the internets (and who isn’t these days?) then you start to run into issues. There are various articles about this (like this one) but basically you have to create a new internet-facing DNS entry for the 2007 CAS, move the 2010 to the old internet-facing DNS name, change the ExternalURL value on the 2007 CAS to match the new DNS name, change the internal DNS so that there’s an entry for the new DNS name (because Exchange treats other AD sites as “External” as well), buy a new trusted SSL Certificate for the new DNS name (or wildcard it) and pray to God that you’re only publishing 2007 CAS servers from a single AD site; otherwise it gets so complicated that your brain will try and kill itself to escape.

If you think that sounds bad, then wait; it gets better! You can’t use the 2010 management tools (which are now 64-bit only – unless you enjoy Powershell Remoting) to manage 2007 mailboxes. Well that’s not entirely true, you can so some things, just not everything and it’s the same with using the 2007 tools on 2010 mailboxes. It’s all documented on The MSExchangeTeam Blog and it’s a huge mess – if your helpdesk staff (or whoever else manages your mailboxes day-to-day) aren’t really on the ball there’s a good chance you’ll run into problems while the 2007->2010 transition is in progress.

All this is in addition to all the subtle syntax changes they’ve made to a lot of the management Cmdlets so that things which were valid commands in 2007 don’t quite work properly in 2010; I’m looking at you, Import-ExchangeCertificate – let’s go from importing a CA-supplied .cer file to importing the binary contents of said file as a Byte Array supplied as a command line argument, because that’s much easier.

I really like Exchange – 2007 SP1 onwards was top-notch – and 2010 has some great new functionality, but they’ve really dropped the ball when it comes to installation, upgrading, migrating and transitioning.



Please note that this issue also applies to Exchange 2010 SP2

Be warned; if you attempt to upgrade an Exchange 2010 RTM install to Exchange 2010 SP1 and you do not have the correct Powershell Execution Policy in place (and I’m not entirely sure what that is, it’s not documented anywhere obvious but it appears that Unrestricted works – although some have said that it doesn’t – and I can assure you that RemoteSigned doesn’t) it will not warn you, it will not avoid it, it will simply break halfway through the install and leave your server in a state whereby the Exchange binaries are all deleted, half your Windows services are disabled and all the Exchange cruft is still in the registry. The error is akin to the following:

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

The only fix I’ve found for this, after sorting the Powershell Execution policy is to delete all the Exchange keys from HKLM\Software\Microsoft\Exchange and HKLM\Software\Microsoft\ExchangeServer, restart all the disabled services (IIS, WMI, Remote Registry, etc) then run the Exchange 2010 RTM “setup.com /M:RecoverServer”, wait for it to complete and then attempting the SP1 install again.

All I can say is thank god I didn’t test this on a server that happened to have the correct Execution Policy and then subsequently deploy it into production onto one that didn’t.

Update: Thanks to Martin in the comments for pointing me to http://support.microsoft.com/kb/981474 – it looks like it’s not so much what the Execution Policy is set to, but how it’s set. Seems like a really stupid oversight to me; surely Microsoft must have expected people to use GPOs to set Powershell Execution Policies – at the very least some detection logic in the installer to warn the user would be nice.