Section 1: Introduction

Because window update will impact to server operation, we should handle it carefully. According to the Microsoft paper of “Best Practices for Applying Service Packs, Hotfixes and Security Patches” as appendix in this document, we should apply the patch on needs base, and may not necessary to apply all patches. Moreover, we need to test the patch in testing server before applied to production server. Furthermore, because some application servers may have negative or unforeseen impact after patch update, we advise not to perform window update in application server. Let’s describe the window update procedure in following section for your reference.

Section 2: List of Servers to Window Update

The following servers will be included to perform the window update as below:

 

Server	Name	Install ip	Machine Type & Usage

Exclude list : We did not perform the window update in application servers, because it is difficult to evaluate the impact of patch to the application operation. However, if we decide a window update is critical and is necessary to apply, we have to test it in a testing server; then apply to production application servers after testing okay.

Normally, we will exclude the following servers from window update because we installed business application software in them.

Server	Name	Install ip	Machine Type & Usage

 

Section 3: Schedule to Perform Window Update

We plan to perform window update in servers monthly. In order not to affect the month-end operation, we plan to do it during non-office hours in second or third week of a month.

Section 4: Test-Run the Window Update

1. Backup a virtual testing server in PRC via VM snapshot function

2. Run the “Check for Updates” option as below diagram:

• Generate a list of Window Server Patch Update and review its content as below diagram.

Update Patch List:

Patch List	Plan to Update (yes/No)	Remark
KB4041083	Yes
KB4049016	Yes
KB4054518	Yes
KB4052978	Yes
KB4033342	Yes
KB2823180	Yes
KB890830	Yes

3. Perform the patch update in the testing server, and report the result as below green highlight column:

Patch List	Plan to Update (yes/No)	Testing Result   (Pass/Failure)
KB4041083	Yes
KB4049016	Yes
KB4054518	Yes
KB4052978	Yes
KB4033342	Yes
KB2823180	Yes
KB890830	Yes

4. Resolve any issue if necessary; or not plan to update any issue patch

Section 5: Apply Patch in Production Servers

1. Backup Virtual Servers:

Local-IT team will create VM snapshot for the following virtual servers:

Server	name	Install ip	Machine Type & Usage	Server Backup

2. Patch Update PRC Servers:

Local-IT team will perform Patch Update for virtual servers as below list. We will schedule to patch those servers during non-office hour (e.g. 7:00pm during week-day). If reboot require after patch update, we will also reboot during off-office hour.

Server	Name	Install ip

3. IT team will perform Patch Update for Hardware servers as below list.
We will schedule to patch those servers during non-office hour (e.g. 7:00pm during week-day). If reboot require after patch update, we will also reboot during off-office hour.

Server	Name	Install ip

 4. Trouble-Shoot to solve any issue; maybe roll-back the server image or uninstall patch if necessary.

        5. Update the “Patch ID and Date” in below two log tables as highlight in green columns:

Server Patch Update Log
Server	name	Install ip		Machine Type & Usage	Server Backup	Patch ID & Date

 

Appendix: Best Practices for Applying Service Packs, Hotfixes and Security Patches

Reference information from https://msdn.microsoft.com/en-us/library/cc750077.aspx as below:

Service packs, hotfixes and security patches are updates to products to resolve a known issue or workaround.

Moreover, service packs update systems to the most current code base. Being on the current code base is important because that’s where Microsoft focuses on fixing problems. For example, any work done on Windows 2000 is targeted at the next service pack and hotfixes are built against the existing available base.

Individual hotfixes and security patches on the other hand should be adopted on a case-by-case, “as-needed” basis. The majority of security updates released are for client side (often browser) issues. They may or may not be relevant to a server installation. Evaluate the update, if it’s needed, then apply it. If not, assess the risk of applying or not.

• Apply updates on a needs only basis.

One of the common misconceptions about Microsoft updates is that they are mandatory and/or urgent.

All updates, regardless of their type (whether they are service packs, hotfixes or security patches), are to be applied on an “as-needed” basis. They need to be evaluated individually and treated as important optional updates.

Especially with security patches, the expectation is that it must be an urgent issue and must be deployed quickly. Without trying to detract from the urgency, security patches are very much a relative update; for example, customers using solely Windows NT4 can ignore a patch for a security vulnerability in Windows 2000. However, if the issue is relevant and does plug a security hole, then it should be evaluated urgently.

Only when it addresses or fixes an issue being experienced by the customer should it be considered. Of course, it still needs to be evaluated before being installed.

• Testing.

The prior points really assist in giving you a feel (before installing) for the potential impact, however, testing allows for the “test driving” and eventual signing off of the update.

Service packs and hotfixes must be tested on a representative non-production environment prior to being deployed to production. This will help to gauge the impact of such changes.

-END-