Manually Deploying Windows 2003 SP2 – Approach

We recently worked on a project with a customer to help deploy Windows 2003 SP2 to their server environment which consisted of approximately 180 servers. Some of their servers were at SP1 but the majority of the servers were sitting at SP0. The purpose of our involvement was to outline best practices in tackling such a task and to try and help put a process in place that would enable them initially get to their whole Server Infrastructure to SP2. The plan after deploying SP2 to all servers is to then look at automating this process for future Service Packs and updates.

The approach we took was as follows:

1. Prepared a document which described in detail the approach that should be adopted to deploying the Service Pack while focusing on the following areas – I have also outlined some o f the sub sections within:

Once this document had been agreed and signed off – we then kicked off the first important piece of work - Risk Analysis

2. Risk Analysis

The purpose of this was to help identify risks on a per server basis and outline how we mitigate these risks. The real value here was that within a few workshops with key personnel we could identify which servers could be patched first based on the level of risk associated with each. Here is a sample screenshot of what our risk analysis resembled;

Once this phase was complete it then enabled the server environment to be documented to highlight the servers that would be patched first of all (the low risk servers) to the last servers to be patched for example the clusters and servers that were considered high risk etc. This also took into consideration servers that could be patched during normal working hours and others that had to be done out of hours during the week or indeed during predefined times at the weekends.

3. Project Plan detailing dates and resources/personnel

Once the servers to be patched had been identified, it was time to schedule in resources and put into practice the processes that were agreed and documented in the document prepared at the start of the project.

Summary:

As the project progressed we found that at each phase we improved the process of applying the service pack and some of the steps we took to mitigate risk when doing so. Simple steps like rebooting the server before changing or modifying anything, backing up and clearing the event logs, disabling Anti-Virus scanners and installing the Service Pack binaries to an agreed drive other than the C drive also helped. It is also very important to read the service pack documentation.

Also, check forums on the web and see if there are any issues. If you have a support contract, check with your support personnel or department and see if there are any known issues with the service pack and you r applications etc and test as much as you can before deploying.

It is also important to identify application owners and have defined sign-off at each of the deployment.

Below is one of the early step by step task lists we devised for a file server. It should be noted that the approach to deploying a service pack can differ based on hardware and the service/application that the particular server hosts. For example the steps to deploying the service pack to an ISA Server can differ greatly to that of a file server, particularly around the pre and post steps and especially around the roll back plan. So, you will probably end up with service pack deployment processes per server type or function.

Upgrade Process (File & Print Server)

Make sure that downtime has been agreed and relevant persons informed

Ensure you have a Bootable Copy of Windows 2003 Server (Correct Version for OS you are updating – this is need to get access to the Recovery Console)

Check for available Disk Space based on Service Pack Requirements and ASR backup.

1

Clear and save the event logs to C: or D: \Sp2 Logs the Drive location is dependant on available disk space

2

Reboot the server to confirm there are no issue and view Server Event Logs

3

Run Client Tests (Verify File & Print functionality).

File & Print – users can access their drives and print documents

4

Complete and verify backups produced by normal backup procedures.

5

Take a System State backup to D: \SP2-Backup – the backup file will be named ‘SystemState.bfk’ (create this folder if it does not exist)

6

Create an ASR backup for critical servers to D: \SP2-Backup – the backup file will be named ‘asr.bkf’

7

Disable antivirus scanners, quota manager, UPS devices / services and scheduling programs.

8

Facilitate Recovery of Print Functions if required

Use Print Migrator 3.1 for Windows 2003 ‘printmig.exe’ to backup the printer configuration on the server

As the backup executes, a progress report is displayed in the lower pane of the Print Migrator window. The contents of the report are saved in the pm.log file in %systemroot%system32\spool\pm – copy the log file to the USB device.

Open Regedit and browse to the following key

HKLM\System\CurrentControlSet\Services\LanManServer\Shares – export this key and save to a USB device

Open a cmd prompt and type ipconfig / all > c:\servername.ip.txt – copy the file to a USB device

9

Install Windows 2003 SP2, point the uninstall directory to the D drive otherwise C if disk space is limited.

Reboot the server

10

Copy the Event Logs, SETUPAPI.LOG and SVCPACK.LOG to C: or D: \SP2 Logs for later analysis.

11

Insert Hardware vendors driver cd (The process and timing of this install will be based on recommendations from your Hardware Supplier)

Take a screen shot and save to D:\HW Vendors (create this folder if it does not exist)

Apply the selected updates

Reboot the server

12

After the updates have been successfully applied-enable anti-virus scanners, quota managers, UPS Devices / Services and scheduling programs and verify they start successfully.

13

Check the server event logs to see if any issues are displayed.

14

Run client tests to verify File and Print access

Verify access to user’s home drive

Verify users are able to print

Complete a ‘Windows 2003 SP2 Sign Off Certificate’ for the patched server – format of the document ‘Site – Name of server – date upgraded’. All relevant parties must update the form, make sure the form is saved to the central file location for this project, once the form has been completed it must be marked as final.

It should also be noted that it is as important to have a roll back plan should problems occur as it is to do all the testing etc up front. Here is a screenshot of a roll back plan for the Domain Controller patch process.

Comments

• Anonymous
  January 01, 2003
  Great article, thanks for sharing.