My network’s keeper

Overall, I found Sitekeeper an easy-to-use program. The shared interface with Diskeeper Administrator means instant familiarity with the product layout, but it is so simple to use that I found myself reaching for the Help file only on one occasion. It is certainly worth testing if you are looking for a solution that combines licence compliance with multiple scans, patch updating and the ability to deploy software across your network.

Sick Server

Recently, I was called to investigate a rather sick and ailing Exchange Server. You know things aren’t good when the Event Log is full of red warning errors telling the system administrator that the nightly backup had failed. Naturally, no-one had taken any notice of this, because the hapless systems administrator had left the company some three months previously. The reason that they would finally got round to asking for help was that the server was running out of disk space, and they wanted to know if it was okay for them to delete all those pesky log files. When I receive phone calls of such a nature, it is always best to be forewarned, which allows me to put down my large cup of coffee to avoid an embarrassing spillage and also to click shut the seatbelt on my Recaro office chair. I suggested gently that deleting all the log files was probably a bad idea, and that a little hands-on emergency fettling was needed.

When arriving at the scene of a server death, the most important thing is to remove the data before proceeding. This is performed with the first-choice device in my fettling toolbox, an external mains-powered hard disk of huge capacity, which has both USB 2 and FireWire 400 connectors (a couple of cables will not go amiss either). Stop the database engine for Exchange Server, then manually copy all the EDB and STM files out, but for goodness sake do not forget the log files too. You might be surprised at just how many of these 5MB log files there are, and that’s because they do not get erased until you have run a successful backup when the transactions all get rolled up into the main database. Treat them as the crown jewels and never, ever delete them to save space, as doing that will wring howls of pain from the person attempting to fix the underlying problem.

Having taken a copy of everything, it is worth taking another copy, but this time doing it with the Exchange store running. To do this, you use a little utility called ExMerge, which goes through the databases and creates a set of PST files; there is one file for each mailbox on the server. Remember that PST files can be directly attached to a copy of Microsoft Outlook, so the creation of PSTs is a quick-and-dirty way to let the users get access to their mailboxes (we will come back to this in a minute). ExMerge also allows you to take a bunch of PST files and load them back into the Exchange Server store, so it can be used to repopulate a server with the data if everything had to be flattened and scrubbed clean, and the backup hadn’t worked as was the case here.

But if you run ExMerge, even when logged in as an Administrator on the server, you will discover that it just creates a whole pile of error log information, except for one mailbox, which curiously works. This is the clue: you need to have the access to each mailbox. There is a Microsoft Knowledge Base article (support.microsoft.com/ default.aspx?scid= kb%3BEN-US%3B292509) that spells this out: ‘The account that is used to run the ExMerge utility must have the Send As permission and the Receive As permission on the mailbox store that the ExMerge utility will be used on.’ Well, that seems pretty clear, now read on: ‘By default, the following permissions are assigned when you install Exchange: In Exchange 2000, built-in administrator accounts and built-in administrative groups inherit the Deny permission for both the Send As and the Receive As permissions. In Exchange 2003, built-in administrator accounts and built-in administrative groups inherit the Allow permission together with the Deny permission for the Send As permission and for the Receive As permission. Note that some permissions take precedence over others. Typically, the Deny permission overrides the Allow permission. However, inherited Deny permissions do not prevent access to an object if the object has an explicit Allow permission entry. Explicit permissions take precedence over inherited permissions, even inherited Deny permissions.’ Sounds like it was written by Sir Humphrey Appleby, does not it?