Hi Cary,
You point is dead-on. The key difference is "new builds"
vs. "existing builds". While I have spent some time
getting my "new builds" procedure finalized, I knew that
this was but a small part of the total picture. Once
that "new build" hits the floor, it becomes an "existing
build".
This is where the fun begins....
Yes, I've outlined my own findings above, if you get further with this
post back in the coming weeks. My current strategy allows for choosing
target workstations and times for update. Some of the automatic tools
give me cause for concern, for example if you tell GPO to apply SP4 at
midnight tomorrow to your OU, and if there's a conflict with (say) your
NICs, you could find yourself with waking up to a whole company of blue
screens, and no easy way to roll them all back!
I don't have GPO yet or SUS, so this is something I'll test in the
future, but I'm certainly surprised at the lack of docs and discussion
on service pack roll-out strategies.
I asked a couple of friends that do big companies in the UK, and they
said it's basically junior techs going round at night doing them
manually! In my job, I have to be there during office hours, and don't
get paid for evenings or week-ends so this kind of thing is always tricky.
One problem with schedules too, is how do you get the password in there;
you certainly don't want it in a BAT file. There's probably a way round
this with task scheduler and getting it to call a script or BAT file in
the context of a domain account - need to check this. Even if you do
this, you've still got the problem of how to deal with errors. It's no
good if the update.exe process has hung for some reason in the middle of
the night.
