Search the Community
Showing results for tags 'scheduled updates'.
Found 3 results
Hi Everyone, I have a strange issue that I'd like some help on please. I've used the build and capture task sequence to capture a wim image. I add this wim to my Operating System Images and then run through the Scheduled Updates wizard. This all looks to work fine and I can see in my image's directory a .bak of my image alongside the slightly larger originally named, now with updates included wim file. The properties of the imported image list all of the updates that I requested to be installed - so all looks good to me(?) It's at this point that I deploy the image to the distribution point. And here's the problem, the size of the image on the distribution point is the same as the .bak image version and when I use this in a deployment task sequence the updates are of course missing. Is there a step that I am missing somewhere? I have deleted the .bak image from the directory and re-uploaded the image to the DP but that hasn't made a difference. I can delete the image from the SCCM console and re-import it and that will be fine, although as SCCM will not list the installed updates under the 'installed updates' tab in the image properties - and this seems like extra work. Has anyone else had this issue? Many thanks
Config mgr 2012 sp1 All, just trying to figure out if anyone else runs into this problem. My company deploys patches quarterly, I read all the kbs, verify which patches I need, and also which patches need to be deployed by themselves. Set up deployments that runs overnight. I break up the deployments based on prereq’s and if a kb says is has to be installed solo, of if a reboot is necessary etc. Offices are on a 12am to 6am maintenance window. Patches are deployed during this time. Option to install outside maintenance window is unchecked. Deadlines are set to 15 ~ 30 minutes after available time. 90 restart time if user is logged in. Each deployment is given a lot of thought, deployment + install + reboot timer ( if logged in ) Brief overview of a recent patch deployment 12:00 am critical updates first round 12:30 am critical updates second round (patch restart if necessary) 2:30 am powershell script to force policy retrieval, software update scan, software update deployment. 3:00 am Security Updates Once the patches reach 90~100% compliance for my offices I start to patch my wim a few days later This time I patched the wim using the sccm gui on a copy of the current patch. I carefully selected only the patches I have pushed out in the recent update I did the gui patching in the same method I did the deployment, so start with the critical updates first round let it patch the wim, the once successful I start the process again with the next set. End result wim grows in size. Imagex is used to update the wim description and version # The wim was not distributed to my test dp’s until all of this is completed. I made a copy of my existing task sequence, then updated the install operating system step with the newly updated wim. Install updates step is disabled in task sequence. ( should be in the wim ) The imaged test machine is placed into a collection that sets the maintenance window to 24 hours I keep an eye on the wuahandler.log and updates deployment log to see if patches are triggered. Sadly all of the patches I updated in the gui redeploy to the test workstation. My question is, why are the patches not detected as installed and skipped. I compared the logs with the installed updates from the server and see the same kb numbers in both. Not sure why it is patching an already “patched” wim. My other option is to copy the wim, extract the patches to a folder and use dism /add-package switch to install the patches. ( I did this on the last version of the wim) really didn’t want to do this since not all patches are cab files that can be installed this way ( like .net updated) Any information would be greatly appreciated.
Where is this time being computed from? 5/3/2013 at 6:04am? My maintenance windows are set from 11:15pm to 5:00am. The ADR was originally set for 2 weeks out, but after making some changes it is now set to "as soon as possible" the change does not seem to take effect to either machines that just received the update information or after the updates were downloaded.