Deliberations from Dave

Thoughts on Deployment

The server deployment needs to be straightforward. No-one likes disaster recovery plans that include "Dance naked around a maypole embedded in sand of the purest white while offering prayers to the great gods".

So realistically the question is, what needs to be recreated during a "DR" install?

In an ideal world, nothing. Everything should be configured in such a way that just restoring the files will recreate all configuration required - the obvious and only exception is services.

Now realistically, if someone is backing up "System State" on their servers, and they darn well should be, then when they go ahead and restore, the service configuration will be retained. This gives us complete recovery with the following steps:

• Build a new Windows Server with the same name as the old server. Don't join the domain.
• Restore the System State and all files.
• Reboot.
• ???
• Profit!

Ahem. So we've got a restored server with all the configuration we had before the fatal crash.

Replacing the Server

Slightly different - we need to run setup and reinstall all the configuration we had before. Ideally the plan here should be to establish a data file during initial setup that we can follow through for the reinstall. If SQL was local, then reinstall it. Prompt for the database backup so we can get the data across. Install services. We will go ahead and fix the group policy we created that deploys the client application too - remove the old source and add the new source for the app. Auto repair here we come!

Reinstalling the Client

This is easy. Uninstall the application from Add/Remove Programs on the client and re-apply Group Policy to that machine (XP hint: gpupdate /force) then reboot. Voila!

Enterprise Deployment

Here's a thought - how do you get the client software for your new application deployed to your 200 (or 2000, or 20000!) client PCs?

Well, if you're me, you don't want to walk around to each PC and run setup. You don't even want to let your users run Setup, because they'll ask stupid questions like "Do I really want to install this?" and "Why can't I be an administrator?"

Heck, you can't even add this to your PC image because that means rebuilding each PC and answering all the "Where did my spyware go?" questions, and nobody wants that. The paperwork alone will send you to an early grave.

So let's start with some basic assumptions.

• System Administrators would like to be less overworked.
• Organisations of more than about 10 Windows PCs are likely to have a Windows domain.
• Most of these organisations will have a Windows 2000 domain, or later, or will want to upgrade because Microsoft won't provide support any more.

Now we're supporting Empire on Windows 2000, XP, Vista and Windows 2003. Frankly if you're running Windows 95 still, you need to get with the program. All the supported platforms support something called "Group Policy".

Group Policy is one of those things organisations don't make best use of. One of the coolest things it can do is install programs on your users' workstations before they even log on. And it can therefore install Empire on each PC in your organisation without you visiting any client PCs.

Sound good?

It gets better - if you have users who think it's great fun to go randomly deleting critical files because they need more space for their MP3 collection, you can get your own back. Applications deployed through Group Policy will automatically try to fix themselves next time they run. I've seen this save more than one admin a fate worse than death.

How many apps support this? Heaps. Anything that comes with an MSI package should be able to be deployed this way. Nobody seems to publish information on how to deploy THEIR application by Group Policy - we will, but if you tick the box during installation, we'll even create and configure the Group Policy for you. That's right - you install the server, we roll out the clients that night when everyone reboots.