In a rare follow up to a previous post on the subject of multi-domain Exchange 2010 configurations, I have just come across the following information, which would have saved me an awful lot of time and effort if I’d known about it when I started (or, you know, it was clearly documented anywhere):

When using the Exchange 2010 Management Shell, the default recipient scope is set to domain-level. This means only local mailboxes will be listed when running something like the Get-Mailbox cmdlet. In order to change the recipient scope to forest-wide, you must run the following command: Set-ADServerSettings -ViewEntireForest:$true

Looks like you have to run it per session, however.

Easy when you know how…

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.

As per; if you’re getting an “Error Upgrading VMware Tools” when trying to do an automated upgrade of VMware Tools from vCenter, or by clicking the “Upgrade” button on the VMware Tools GUI, you need to either:

  • Delete C:\WINDOWS\Temp\VMwareToolsUpgrader.exe for Windows guests, or
  • mkdir /tmp/vmware-root for Linux guests

Seems like yet another case where a bit of installer detection/handling logic would avoid these problems every occurring.