In this tip, I've provided a handful of suggestions to follow when managing patches for your AD domain controllers.
- Always deploy the same patches on all DCs. DCs should be kept as close to mirror images of each other as possible, at least in terms of the OS configuration. This will help eliminate incompatibilities, lost or corrupted data and replication errors.
- Don't patch just because Microsoft offers a patch. Every patch needs to be tested in your environment for relevance and reliability. If you don't need it, don't install it. Patches can damage your environment if the install fails to perform perfectly. You don't want to place your DCs at risk if you can avoid it.
- Test, test, test. You need a lab environment that mimics your production environment as closely as possible. Every patch should be thoroughly tested before deployment on production systems. Make it a rule: If you don't test, don't deploy.
- Avoid patch emergency response. Establish a time once a week or once a month when you evaluate new patches and queue
Requires Free Membership to View
When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by IT professionals today working with desktop management and security technologies.
Cathleen A. Gagne, Senior Editorial Director
- them for deployment. You could schedule them to coincide with Microsoft's "Patch Tuesday" -- the second Tuesday of every month when new patches are to be rolled out. Even with critical patches, you need to stick to a schedule. Always download, verify, test, test, test, and then deploy. Never skip or skimp on your patch procedures, processes or protocols.
- Seriously consider using the newly updated Windows Update Services (WUS). It enables you to master your own privately controlled Windows Update site within your own private network. Many of the weaknesses of Software Update Services (SUS) -- the original product -- have been resolved.
- Document, document, document. Every patch deployed should be researched, so you fully understand it. Then retain that documentation for future reference. Don't assume you'll be able to access it again or even be able to find it again, especially if it is an Internet source. Make your own local copy. Keep records of every patch ever deployed to any system.
- Never assume a patch rollout was successful -- always test and verify. Every patch deployed onto a DC should be verified immediately. Member servers can be fully checked weekly or bi-monthly; and clients can be checked using a random sample.
- Keep in mind that your domains are only as reliable and available as you make them. Take advantage of the improvements offered by Microsoft, but don't be ruled by them. Make informed decisions based on your environment and infrastructure. Don't just follow the leader, since the leader is not always in the know about everything!
James Michael Stewart has co-authored numerous books on Microsoft, security certification and administration and is a regular speaker at NetWorld+Interop. Stewart holds the following certifications: MCSE, MCT, CTT+, CISSP, TICSA, CIW SA, CCNA, MCSE NT & W2K and iNet+. He can be reached at michael@impactonline.com.
This was first published in August 2006