windows update

[darkstar]

I'm the new techie and this is my first time working at a school. Unfortunately I have inherited an unstable network with extremely precarious servers - no documentation and no handover, security is noticable by its complete and utter absence - no patch management - antivirus 13 months out of date and only installed on a small handfull of clients, etc etc. phewwww.
Running hfnetchk on the servers revealed that many patches are missing. My query is - what is the best policy on patching servers. We can't test anything - and servers typically are multirole machines (SQL, Exchange and whatnot). I'd like to deploy WSUS across the network but as far as the servers are concerned it's not unheard of for patches to break exchange or SQL. The last place I worked everything was tested, but this really isn't viable in a school is it?

[tosca925]

I use WSUS all across our domain and that includes the servers. I configure WSUS to install automatically all Critical Updates and all Security Updates at the time i specify.

As for the stuff f like Service Packs and major updtaes to say SQL and Exchange I manually cofigure thees. I wait till i have had chance to test these updates and then install them as and when i am ready. In you case if you have no where to do any testing i suggest you keep your eye on newsgroups and forums to see the sort of feedback other users give and then deploy when you feel confident, maybe eventually come to bite the bullet and see.

[darkstar]

How on earth do you get the time to test updates LOL.

Actually, it sounds like its just a case of common sense. Anyway - cheers for that

[Geoff]

If you can't afford the physical hardware to test you might want to consider using VMWare or VirtualPC to create some emulated computer systems to test patches on.

[GrumbleDook]

Or you could operate the 3 day rule.
Subscribe to a number of microsoft.public newsgroups, mainly those central to roles you have on servers (windows.general, windows.server.*, etc) and then watch for potential issues for three days.

I tend to look at applying patches on a friday after school ... that way if anything goes wrong there is the weekend to either fix it or search for one.

[kingswood]

I agree with Tony. When I started at our school the patch management went something like this: "a patch is out. Install it." I changed that. First, I installed SUS on our 2000 Server and started getting updates out that way (never had a problem there). But what I do is wait to authorise the patches for download to client machines until one week after the update is released. I also subscribe to the MS email lists for security and watch various forums on the internet for signs of trouble, and it works.

Early this year I installed a new Dell Poweredge server (2003) for our admin network. It handles other things like internal email, intranet, and is a GC. After installing it though I momentarily forgot myself and nearly installed SP1. That would have been very bad, since an issue with SP1 on PE servers would have meant that my BIOS would have gone south and the server would have been unbootable. Luckily I checked myself and looked at the Dell support forums- voila! News of an issue with SP1. Don't install yet. So I didn't, and I therefore didn't encounter a CLM (Career Limiting Move).

Moral- check those sites out and don't be too hasty to install those patches if you can't test them first. On the other hand, don't wait so long as to be too paranoid and then leave your systems unpatched!

Paul

[darkstar]

I'm the cautious type only too aware how those CLM can leap out at one.
However,
I've actually found an old server that I may be able to press into use and set up as a lab, now I think I may be straying into another topic and there might be a thread somewhere hereabouts, but when you guys test do you DCPROMO a test DC into the production environment and then disconnect it? I'd really like to replicate as much as I can so that I can test anti-virus, patches etc but I understand I'd probaly have to run ntdsutil to clean up the metadata on the production AD. Is this hazardous - it looks pretty straightforward - but these as we are only too well aware are the quintessential famous last words.


If you are interested in a snapshot of your current AD, you can:
- dcpromo a new DC in production
- make the new DC a GC
- install DNS on the new DC
- disconnect the new DC from production network
- clean up the DC's metadata in production environment

- put the disconnected DC in a seperate VLAN
- seize the FSMO roles
- in the test environment perform metadata cleanup to remove the production DCs from test environment.
- update the sites&subnets info to reflect the new test subnet layout

[DMcCoy]

I've not put it into practice yet, but I'm hoping my new esx servers are going to do well here, at least to test patching and checking for error free boot. I can take a copy of the machine while its running (crash consistent state) and test the patch on a seperate vlan and then do the real one all going well.