K1000 Aggressive Patching schedule, how aggressive can you get?
Hello,
I'm trying to do something similar to this: https://support.software.dell.com/k1000-systems-management-appliance/kb/147524
I do a scripted install on my K2000, during which the machine gets domained and put in to a New Installs OU. I set up a patching schedule on the K1000 to patch any machine in this OU. There are never any machines in here but newly built ones, so I can be as aggressive as I want. I set my schedule to detect and deploy every 10 minutes, but nothing happens. I set it to 2 hours, and my machine is still patching when I came in this morning sitting on update 158 of 196 on a please don't power off your machine screen.
I'm running about 200-250 patches, as these are from a Windows 7 SP1 build right off the Microsoft ISO with Office
My question is, if I set my detect and deploy time to 10 minutes, will the next detect and deploy interrupt the first, causing the machine to sit there interrupting itself over and over? If so, how fast can I set my schedule? The article I linked mentions 30 minutes to an hour, but if these detect and deploys can interrupt themselves I may have to make it 2-3 hours, or longer. The longer I make it however, the longer my machine initially sits in the New Installs OU not getting patched.
I'm not interested in slipstreaming patches, using imaging, or using WSUS offline. I'm having no problems seeing the machines I want to patch so I don't need help with smart labels or ldap labels. Thank you for your time.
2 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
getElementById
9 years ago
My solution is similar to what jcaine suggests in the comment. I have a 'one-time' full detect and deploy that I launch manually. It runs on machines in a smart label that determines if the machine is new. Every now and then I do have to kick it off a second time if there was an error. I don't often have more than 6-10 new PC's at a time so it works out well.
Our process is the same, we deploy from the K2000 a fresh Win7 Sp1 install and detect and deploy patches from the K1000. We do not slipstream, image or use WSUS. So each deployment requires a detect and deploy of anywhere from 400-500 patches (IE, .NET, Adobe, Java, Office 2013, and Win7).
As you can well imagine this takes a good amount of time. The thing to remember is it takes a long time to patch/update Windows and even running directly from Windows Update takes a long time. I have found that if I do one run of the detect and deploy it will not finish everything and 'usually' errors out about halfway.
So the best practice for us has been to schedule a second detect and deploy about 4-5 hours later and this seems to work ok. Not sure if that is of any help but at least you can get an idea of how it works for us. - jcaine 9 years ago
What I've had to do is limit my "aggressive" patch schedule to once every 24 hours. I have it go off at night, so if the deskside guys start a build they know it will be done come morning. Once every 24 hours also eliminates any chance the detect and deploy will interrupt itself.
If they need one patched right away I can kick off the detect and deploy whenever they ask. Since the detect and deploy is for the entire new installs OU however, once I kick one off I can't kick off another until the first once completely finishes (so it doesn't interrupt). I could get around this by making a new detect and install schedule for every machine, but that would be really annoying. (A run now option like what is under scripting would be nice to fire off machine specific detect and deploys quickly.)
I don't think I've had any issues with needing to run a second detect and deploy or update errors, but the deskside guys are still testing. I'm doing Windows 7 Sp1 and Office 2010 Professional. I install Office SP2 and IE 10 as a post install task on the K2000, so maybe those prevent the need for a second update run? I think that some updates are not being listed under Windows Update, view update history like we are used to looking at. I guess this is expected behavior however.
My other alternative is to use our WSUS server. The fastest you can make a WSUS server install schedule is once every 24 hours. A manual wuauclt /detectnow, wuauclt /updatenow can be run, but this seems to require multiple reboots, and there is no easy way to make it do this, auto reboot, run it again in a unattended script. The deskside guys would have to manually click the button to update over and over if they wanted it done fast using this. - edwimb 9 years ago