As we all know, there are certain published standards for things like Windows Security and Group Policy that companies can use as baselines for their systems; standards such as the CIS Security Configuration Benchmarks. These standards often mandate the configuration of certain GPO settings that fall under the “MSS” category which do not appear in the Security Configuration Editor or Group Policy Management Editor by default.

In order to add these settings so that you can easily configure them without screwing around in the registry or writing your own ADMX templates, you can download and import them as part of the Microsoft Security Compliance Management Toolkit. Unfortunately, getting access to this toolkit requires the installation of the Management software with its associated requirement of a SQL Express instance, which is ludicrous.

So, I am including below, the WSF script that is required to import these settings into the Group Policy Editor on a given 7/2K8R2 machine (and probably Vista/2K8 as well, but I haven’t tried it). Use cscript LocalGPO.wsf /ConfigSCE to import the settings, which will then appear under “Computer Configuration->Policies->Windows Settings->Security Settings->Local Policies->Security Options” in the Group Policy Editor (Or the appropriately reduced path in the Security Configuration Editor).

Download LocalGPO.wsf

If you’re dumb enough to download and run a VBScript from an untrusted source without doing the usual safety checks then you probably shouldn’t be using this kind of “hack” in a production environment (in fact, you probably shouldn’t be allowed near a production environment in the first place…).



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.



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.