Monday 22 February 2010

Complete server restore to different hardware using BackupExec 11d SP5 and Windows 2003 R2 SP2

I haven't mentioned it earlier, but I work for a relatively small IT company and so alot of things are done on a finite budget with a finite amount of time. This means that things are not always documented and servers are not always specced as well as they should be. It also means things like disaster recovery are just well, overlooked. The powers that be don't see £'s from disaster recovery planning, therefore it just never really happens.

When a Terminal Server, Mail Server, Database Server and Print Server failed to boot recently it was up to me to try and pick up the pieces. It was pretty clear from the off that things were not in a good state. Allthough the server was RAID 5 there was no MBR and after booting into the Windows Recovery and running fixmbr there was still no joy. I knew the previous nights backup was good and decided to take the plunge and perform a complete server restore.

The server was a Fujitsu Econel 200 and we had a spare Fujitsu TX150 S5, clearly not the same hardware. The restore was pretty tedious so I decided to blog about it here.

Here is what I did. Please note, I do not take responsibility for anything that goes wrong after following these steps.

  • Partition the HDD the same and install the same version of Windows (R2 etc) and update to the same service pack. Also give the server the same name because when you restore with BackupExec later it looks at the name of the server. Also if possible write protect the backup tape/cartridge, just in case!
  • Install BackupExec (11d in this case) but make sure you CHANGE the install path. Choose something like C:\Program Files\SymantecTemp
  • I updated BackupExec to the latest version (SP5 at time of writing), just in case there were any restore bugs that may have bitten me.
  • The backup device was a Tandberg RDX and in BackupExec you have to create a Backup to Disk device. I recreated this and pointed it at my B2D folder.
  • Once you have added the B2D folder, perform an inventory so BackupExec queries the backups.
  • By default BackupExec splits the "Media" into 1GB files and so after the inventory I was left with lots of "Media" in my B2D media set.
  • This part was very tedious. I couldn't find a way to associate these individual "Media" with a specific backup so I had to select them all, right click and select Catalog Media. I had to wait quite a while for BackupExec to go through each one and work its magic. Don't be too alarmed if alot of them fail, they did for me.
  • I then selected New restore job using wizard, click Next and looked through each Media Label until I found the backup that I wanted to restore. Be aware that different drive letters and the System State may appear in Media with different labels.
  • Click Next and if you are not sure of the logon credentials for restoring the data you can test them on this page. If you're confident click Next, give the restore job a name, select the relevant device, select Overwrite the file on disk and click finish to run the job now.
  • Allow the restore job to run (restore time varies greatly depending on the amount of data and type of backup device). When the job is complete BackupExec will prompt to restart the machine.
  • If you're lucky the server will boot. For me it didn't. I was greeted with :-
Windows could not start because the following file is missing or corrupt:
<Windows root>\system32\ntoskrnl.exe
Please reinstall a copy of the above file
  • My first thoughts were bugger, the hardware must be too different. Then I thought, no, a too bigger hardware difference is likely to manifest as a BSOD. A little bit of research led me to believe the boot.ini file must be different between the servers. To get around this, you will need your Windows 2003 installation media. Boot from the CD and after the drivers have loaded press R to enter the recovery console.
  • If the server is relatively recent it is likely that Windows has not got the correct drivers for your RAID/SATA controller. If this is the case download and install nLite. This app is superb and amongst other things allows you to slipstream service packs and drivers into a windows install. Copy your Windows Installation CD to a directory on your machine, open nLite, point it to your Windows installation. Follow the wizard and point nLite to the drivers for your RAID controller etc and then either create a new ISO or burn the modified OS directly. It is so straight forward that I'm not going to bother describing the process here.
  • Logon to your Windows installation using the admin password from the original server. Then run bootcfg /rebuild. This command took a few minutes to finish but when complete it should find your Windows installation (probably C:\WINDOWS) and ask if you want to add this installation to the boot list. Press Y and enter. For the load identifier enter something like "Windows 2003 Standard Edition R2" and for OS Load Options enter the default "/fastdetect"
  • Type exit, the server should reboot and hopefully load into Windows. How windows acts now is highly dependent on how different the hardware is from the original installation. I was lucky because the server booted up albeit very slowly. I disabled some hardware specific services, installed a Chipset driver, checked the Event Viewer and everything seemed OK. After another reboot the server was as good as the original!
  • If you want to free up some hard disk space you are free to delete C:\Program Files\SymantecTemp that we created earlier. The restored OS knows nothing about this install because we have restored the System State.
Hopefully, if you are reading this I have helped you restore a stricken server. If not maybe you have learnt something new.

I am aware this is not an exhaustive step by step guide to restoring a server and I'm sure this procedure could fall down in lots of other places. If and when I experience these different scenarios it is likely that I will update this post. Sometime in the future this may become a very useful resource.

Regards

Monday 15 February 2010

Enable local relay on a Microsoft Exchange 2007 Server

We have an application that sends email by relaying through an SMTP server and unfortunately its quite basic and so you cannot specify any logon credentials. Therefore I needed to allow the application to relay through a locally running Microsoft Exchange Server. This was the first time I've used Microsoft Exchange 2007, but I thought this should be easy as I knew how to do it on Microsoft Exchange 2003. How wrong was I! This is when working in IT becomes really frustrating, when things appear to be changed just for the sake of it with no apparent improvement in functionality. An hour or so later I had the solution, which was alot more long winded than I was expecting.

First open the Exchange Management Console, expand server configuration and click on hub transport. On the right hand side click New Receive Connector and a New SMTP Receive Connector wizard will open. Give the connector a name and leave Select the intended use for this Receive Connector set to Custom. If the server is multi-homed set the next page so the connector is only listening on the LAN adapter. The next part is important because you want to restrict relaying as much as possible. In this case it is a single IP address so the Start and End IP address will be the same. 127.0.0.1 didn't appear to work for me, so I used the LAN IP address of the server. Click Next and then New to create the new connector.

We now need to configure authentication parameters for this connector. Highlight the newly created connector and click on properties. Leave the Authentication Tab at defaults (Transport Layer Security Ticked) and the click on the permission group tab and ensure only Anonymous users is ticked.

Anonymous users are not granted the relay permission by default. Run the following command in the Exchange Shell but replace *NAME* with the name of the Receive Connector created earlier.

Get-ReceiveConnector "*NAME*" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

Thats it, you should now be able to relay locally, which you can test using telnet. When Server applications are supposed to be moving forward I find it absolutely incomprehensible that an Admin needs to go through this process to configure relaying.

Regards

Tuesday 9 February 2010

After install of Acronis Backup and Recovery 10 System Event Log is full of Distributed COM errors from user Acronis Agent User.

I had a problem after installing Acronis Backup and Recovery 10 whereby the System Event Log was filling with Distributed COM errors.

This is caused by the Acronis Agent User not having Local Activation permission for the relevant component service. To resolve this issue click on Start, Run, dcomcnfg and press enter.

Expand Component Services, Computers, My Computer, DCOM Config and scroll down until you find the entry {9730B9A2-1CDF-11D2-950E-0000E817385C}

Right click on this entry and click properties, click on the security tab. In the Launch and Activation Permissions area click the radio button on customize and click Edit. Click Add and then select the Acronis Agent User and click on OK.

Tick Allow for Local Launch and Local Activation. Ok through the windows and the error should now stop being logged in the system event log.

This was on a Domain Controller so not sure if running dcpromo after installing Acronis is causing this.