SSWUGtv – Deployment Projects
With Stephen Wynkoop
What is the process of a typical deployment project, and how do you make it successful? Today Steve interviews Patrick Townsend sharing some great ideas.
Watch the Show
Server Techniques for Applying Windows Updates
Many have written in regarding policies for Continuous Release (Automatic Windows Updates) for server environments. All have consistently stated that automatically applying Windows Updates is a risky proposition in a production environment.
Robert:
We have a defined policy for updates.
Firstly we NEVER leave on auto update. I cannot believe anyone would do that , as losing control of when a server may or may not reboot is irresponsible in my eyes. We have one laptop which is on this and we know when it reboots and use this as a guide things are happening.
Secondly we have to take a pragmatic approach. We often have no idea what these patches are for and have to rely on Microsoft and the community at large for confidence we can patch ok. Certainly things are no way as bad as they were in the past and we are confident that there should be no problems.
- We apply the updates immediately to a non-critical Windows 2008 R2 server with SQL 2005 Dev setup. We review the event logs before and after.
- We keep an eye open for a couple of days for any issues on the web
- We upgrade a low risk Windows server and check the event log for any issues which are new
- We then upgrade our servers in a defined order the coming or following weekend normally on Sat evening which gives us Sunday to resolve any major issues. This includes taking down as many background apps and suspending the SQL tasks where appropriate
- The last servers we upgrade are our SQL servers as we know these have the most risk. We do the one with the least databases on to ensure that we have the least problems to clear up. We also make sure we reboot after a DIFF or FULL backup has taken place and sure that we stop the SQL Agent first when nothing is happening. We always stop IIS and SQL Server plus other tasks Dependant on which server type it is to ensure that we minimize the chance of a reboot stopping a process too quickly. SSIS has been a recent issue on restarting for example.
- Finally we upgrade our internal servers mainly as we can leave these a bit longer if needed
Paul:
I have an SQL server that still must have the service restarted manually when the server is restarted, because of a failed and painful-to-recover-from automatic update failure.
We do not use automatic update for some of our critical servers because of this type of possible problem.
Prabhu:
I wouldn’t want automatic updates applied on any windows server especially if it is hosting an ERP or CRM solution. Batch processes or live transactions cannot afford to get interrupted. It should be the system administrator’s job to schedule for updates during off hours or at planned intervals during business hours.
I have been considering other factors driving the process for applying updates when your systems fall under regulatory requirements. United States requirements for -SOx, PCI, SAS, etc. as well as polices in the EU and elsewhere, generally do not allow for updates of any kind to be applied to a server without some form of Change Control and release process.
Do you find that complying with regulatory restrictions have changed your updates processes? Drop us a note at btaylor@sswug.org and share your experience.
Cheers,
Ben
Featured White Paper(s)
How to Use SQL Server’s Extended Events and Notifications to Proactively Resolve Performance Issues
read more)
Featured Script
dba3_DisplayDefaultInformationForDatabase
Display (Table Column) Defaults (Constraints) in a Database… (read more)