Who are you?
Just another sysadmin fed-up with manually patching systems or asking users to WindowsUpdate. Most users will give you "The Blank Look" when you ask them anything about OS patching or AV definitions. They cannot be trusted to take care of security matters for you.
Can I modify these scripts to work for my environment?
By all means. You'll probably have to since every environment has its specifics. If you modify the script and re-publish it on the Internet, just throw some credit lines with my name and the website in the script somewhere.
Do you have another script which will allow me to auto-detect which version of Windows is in use (NT, 2000, XP, 2003) and run the appropriate patch script accordingly?
I've been using it for a while, and I'm just now getting around to sharing it with you. Sorry for the delay, folks. My boss loves to keep my list of projects stacked up pretty high.
Have you tried other automated patch methods?
I've tried Software Update Services (SUS) and UpdateEXPERT. The latter requires that you update with the vendor's database, and the former requires a machine with IIS running on it and some administrative overhead to approve which patches should be distributed to your end users. I hear SMS can work, but that's also more overhead to work with in a large environment. Or you can just use free scripts if your IT shop is on a shoe string budget and your CIO / CFO / IT Director refuses yet another costly IT purchase. Choose your poison.
What if a new patch comes out and I don't have time to modify and re-deploy the update script?
If you're one the many companies who can't afford more management or systems automation software, use a free utility like psexec.exe to distribute patches manually onto machines you have admin rights to (requires a TCP 139 connection). For example:
psexec \\machinename -c -f Windows2000-KB828035-x86-ENU.exe /u /q /z
Or you can do this automatically to multiple machines such as your production servers:
for /f %i in (servers.txt) do psexec \\%i -c -f Windows2000-KB828035-x86-ENU.exe /u /q /z
Don't forget to use %%i instead if you're using batch scripts. Keep in mind any commands used will be sent in cleartext across the network. So if you send credentials as part of the command string (not shown above), be mindful about potential users with sniffers and ettercap.
Do you test your scripts and how?
I used to use Ghost images of all the platform variants (NT 4.0 Workstation SP6a, NT 4.0 Server SP6a, Windows 2000 Pro SP3, etc.), but I eventually decided to use virtual machines (VMware) instead. This allows me to run patch checks on an unpatched machine, run the scripts against it, verify patch levels to see if anything was missing, then "rebuild" the entire OS by copying a file to do it all over again. It's my life story.
The Windows 2000 SP4 script doesn't seem to work.
Here's the kicker - when I installed the test OS, it was installed from a CD that had Service Pack 4 slipstreamed into it. It might be that the registry key that the script uses to verify current SP level might in fact be different or not exist at all when the OS installed and SP4 applied afterwards. I'll look into it. One can always comment out that line using REM to bypass that portion.
The NT 4.0 scripts don't seem to work against NT domain controllers - why?
There's a slight difference in the registry key value which determines the "ProductType" - this was pointed out to me by someone who used my scripts and the NT 4.0 script has since been corrected. Once I dig through my old e-mail, I'd be glad to give him the credit he deserves.
How do you perform patch level checks on a machine without using WindowsUpdate?
I use the command line utility hfnetchk (or MBSA in hfnetchk mode for Windows 2003 machines). As an example.
hfnetchk -h machinename -s 2 or maybe hfnetchk -d domainname -s 2
If you must have a GUI, use the Baseline Security Analyzer.
Does using these scripts make my machines resistant to further attacks?
Good luck. Keeping your systems up-to-date with the latest patches definitely helps against currently known exploits, but with the world the way it is and with companies such as Microsoft trying to reactively release patch codes for software that was designed to be easy-to-use and backwards compatible with legacy systems (think NetBIOS and SMB), the next published exploit is just around the corner. So, no, not completely. I recommend reading Hacking Exposed Windows 2000 as a starting point.
You sound like a Microsoft skeptic.
Anyone who's had to work on Windows long enough to become jaded with the whole "secure NT computing platform" knows well enough. Not that various Linux distributions as well as Solaris and BSD don't have issues, but take a look at OpenBSD's errata, for example. At least their patch count is low. And a lot of their patches apply to applications, not the OS itself. And there's no "convenient" browser deeply embedded into the OS to wreak havok.
I used to patch Windows NT and 2000 systems manually. Often. After Code Red and Nimda, I had enough.
Any further advice?
Before you run new patches to live production systems, whether they be servers or workstations, patch on a test machine first to make sure it doesn't break anything (assuming resources are available for this). Microsoft has a history of releasing faulty patches, and subsequently releasing a patch to fix a patch. It's easy to get caught up in the hype of "get it patched now!" when you see a major security bulletin released indicating virtually every Windows platform is vulnerable. It's easy to place trust in the vendor's ability to create non-problematic patches, but it's become an obvious blind faith.
You sound like a security nutcase. Do you really know what you're talking about?
I've worked with NT+ products long enough. Long enough to not trust their default security state. Even Windows 2003 Server's default local policies aren't that tight IMHO. That being said, a little paranoia doesn't hurt. Especially if your job's on the line when all those end-user machines in your corporate LAN decides to suddenly send large-scale ICMP floods to the subnet's broadcast address with spoofed source IPs. Hasn't happened to me yet, but...
Why all the command-line work? Why not make a GUI front-end?
1) I'm not a developer. I have no idea how to make a front-end application.
2) Command line rocks. Things can happen faster that way. And it's easier to automate at a basic level.
3) End-users can marvel at your typing skills as you work your magic in the mystical "DOS Prompt."
Can I contact you for further questions?
By all means. If you click on my e-mail link, be sure to remove the portion left for the spam engines.
You are so cool for providing this information.
You're welcome.
Actually, I wrote this question in advance just so I can feed my ego in the event no one thanks me. I lucked out though - some people did write in with appreciation letters, as well as further advice and pointers to other utilities which I might post on the next update. If I helped save your company some money in network management costs, I can open a tip jar. Feel free to support the starving and neglected sysadmin.