Handling patch emergencies
By James Michael Stewart, Contributor
05.23.2005
Rating: --- (out of 5)
|
Managing an Active Directory environment means systems administrators must successfully juggle the horde of patches from Microsoft. Even if I avoid discussions of non-OS patches and client-OS patches, there is still too much to say about patch management for Windows 2000 Server and Windows Server 2003 systems. The issue of patch management is even more precarious and essential for domain controllers (DC).
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 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 ...
To continue reading for free, register below or login
To read more you must become a member of SearchEnterpriseDesktop.com
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.
|
|
|
|
|
|
