Keeping your software up to date is the number one way to prevent security issues.
Patching a large number of computers is a painful process. When it comes to servers, there are two automatic methods, WSUS or simply turning on automatic updates. These methods are great but it makes change control and testing difficult. The success rate for these can be low which usually turns this back into a manual process. You should have some form of alerting when these fail or you may go months or a year without getting the patches you need. Or even worse, an update/reboot could take an application offline and you don’t find out about it until the users are calling.
RDPing into the server and check for updates is the way I have been doing it for a while. When it comes to SQL server this is usually pretty easy as long as you stay on top of the updates. Microsoft patches generally don’t break microsoft products, its the 3rd party vendor apps that you have to watch out for. Once a month, no more no less, is a good rule of thumb to apply updates. No more because then your database is coming offline too frequently. No less because microsoft highly recommends critical security patches be installed within 7 days and you will get severely dinged on scans if you are 8 days old on a critical.
If you have a strict testing policy you have to be careful about not applying untested updates to production. This gets tricky because during the week or two that it takes to test more patches could come out and be available to install in production. If you have 100 servers its simply unrealistic to go around with a list of KB’s get everyone installed on the correct dates.
That said its unrealistic for one person to keep 100 servers patched manually unless that is all they do… and work overtime. The most time consuming part is when patches fail. I’ve started to get in the habit of migrating databases off these server because its faster than troubleshooting windows patches.
To further increase my ability to keep servers patched I’ve started using some .NET code and other auditing mechanisms so I can target the worst offenders first. Using WMI you can query the last reboot time, service pack level and build number of a windows machine. In addition to that, I get the free space on the C: drive to make sure my updates will go smoothly. I also pull data from network vulnerability scans and merge this information together to create neatly ordered a list.
Remember, a network is only as secure as its weakest link.
If you have problems installing an update there are a few things you can try.
1. download the redistributable: search for the specific KB and make sure you download the correct one for your bitness, always try to run as administrator
2. verify you have the .net framework prereqs: i’ve had some success downloading an earlier framework versions and retrying patches
3. download the system readiness tool: this will spin through various system checks and give you a report
4. check the update history: maybe the current update is failing because a previous one partially completed
5. check the event log after a failure: you might get tipped off, also googling event log errors usually comes up with some good info
6. update windows update agent: in 2003 there was “windows update” that should be updated to “microsoft update” to pickup SQL or other MS product updates. In 2008 there is an OS shortcut to this agent that should update itself, but sometimes does not do that successfully.
7. packup and move to a new server…