Search the Community

We are upgrading to Current Branch and want to include patching from this and not WSUS as curretly used. what is the best way to patch 3rd party applications through SCCM Current Branch?

Hi Everyone, I wanted to let you know that this month's free report giveaway is Patch Compliance Progression by Collection For each PC within a collection, the Patch Compliance Progression by Collection report will provide you with a count of missing software updates (patches) and the last hardware inventory date. The deployed state report parameter allows you to select the deployed state of the software update. The deployed states are: Yes – The effected software update is deployed within your environment No – The effected software update is NOT deployed within your environment Both The status count parameter allows you to select whether or not expired software updates are included in the status count. In ConfigMgr, software updates that are expired are still listed. When complying with standards such as the Payment Card Industry Data Security Standard (PCI DSS), expired software updates should always be excluded from status counts. Yes – Expired software updates are included within the status count No – Expired software updates are NOT included within status count The classification report parameter enables you to select which software update classification to display within the report. The update classifications, listed in order of severity, are: Critical Updates, Security Updates, Definition Updates, Service Packs, Update Roll-ups, Updates, Tools, and Feature Packs. Click here to read more about update classifications. To learn more about it see our website. http://www.enhansoft.com/resources#current-monthly-report

Hi All, We are going to start to patch our servers using SCCM I have created software update groups for Server 2003, 2008 and 2012 which contains all important and critical updates for the server up until DEC 2014.However I have a problem some servers that require a manual reboot so I advertise my updates like the below: Type of deployment : Required installation deadline : As soon as possible Suppress system restarts : Servers The problem is that after the reboot I check SCCM and the client is compliant the I then go to work the next day check the SCCM console and the client shows as in progress requires reboot because it has installed more updates. I know the problem is that some updates aren't required until a pre-req is install however is there a way to ensure that the client automatically checks SCCM server for updates every 15 minute so that I can confirm that all updates are installed. Also from the SCCM client logs how can I confirm that there is no software updates left to install on the machine if I run the software scan cycle manually 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.

We have a small number of servers in our DMZ all are in their own workgroups so no knowledge of each other. They are also not all internet connected so patches must be pushed from internal to DMZ. I noticed this post https://nikifoster.wordpress.com/2011/01/31/installing-configmgr-clients-on-servers-in-a-dmz/ which states as long as I have firewall rules inplace I can manually install the clients and have them talk directly back to my site server internally no certificates required. I was also looking at https://social.technet.microsoft.com/Forums/en-US/f8b1b51e-515e-41f6-bb1e-cdeeabb11f6f/configmgr-2012-design-for-dmz?forum=configmanagergeneral and their option 3 is to build a DP/MP/SUP box still internal and have that configured with SSL to then talk to the DZ boxes. If I were to build this design and enable SSL what effect will this have on my currently working internal environment. will every machine now have to use the new certifcates to talk to SCCM? or will it only be for boxes talking to the new Distribution Point which I can hopefully administer with boundary points.

Hi. Ran into a weird thing. We're deploying Config Manager updates via SCUP, and a number of our clients (all of them 32-bit so far) were failing to install the SP1 CU 5 patch for the CM client. The error in the event log was a 1706 saying it couldn't find a valid client.msi package. Digging around in the registry, all of these clients that I've seen so far had an installsource value in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{FD794BF1-657D-43B6-B183-603277B8D6C8} of "\\siteServer\Client\i386" - this share was indeed inaccessible Clients that patched successfully (both 32 and 64 bit) had a value of "c:\windows\ccmsetup\{Product Code for 32 or 64-bit client}" in there, instead. Changing the reg key on problem systems to point to the local copy of the .msi did not work, though I didn't try rebooting them, since they're all live systems. Changing the NTFS permissions on the \\siteserver\client share to grant everyone read (share permissions were already everyone=read) allowed these systems to patch. A system I was testing with and had changed the reg key to point at the local copy of the MSI actually changed that key back to \\siteServer\Client\i386 after patching was complete. So what I'm wondering, is: Is the differing InstallSource location normal behavior? Should the client share have had Everyone with Read on it already? If 2. is "yes" then what's the best way to make sure permissions aren't hosed elsewhere as well? Just wait til something breaks? Reset? Other? If 2. is "no" then what are potential repercussions of granting everyone read access? I'm thinking nothing, but...

I have been setting up SCCM 2012 in a lab environment and to be completely honest, I have no idea what I'm doing regarding the patching aspect. I took a beta 4 day in-class class and have my book, so I'm not totally running blind, but I'm still lost. I setup a site server named LAB-WSUS that had WSUS 3.0 SP2 installed and downloaded updates. Why does it appear my SCCM CAS is going directly out to Microsoft.com for updates? Shouldn't it be going to the WSUS server? Isn't that the point of the SUP site server? When I downloaded the patches, it asked me where to put the "package.". It just downloaded all of the patches onto the SCCM CAS server (per my direction). I setup a deployment package and chose to deploy to one of the device collections I have setup. I have no GPOs set to point those servers to the appropriate WSUS server, but why do they have to? It appears that my SCCM server is doing all the work. Thanks in advance!!!! Juice

Good morning everyone, This site has helped me understand and get started with SCCM 2012 like no other however I do have a question. We are starting to want to push out patches to our dev environment. I read about the Automatic Deployment rule from the SCCM 2012 guide but we aren't ready to go full speed just yet. My idea was to make a collection with the 8 dev servers in it and setup a maintenance window to push the updates out at a specific time. Does this sound good or is there any other ways this can be done? I'm willing to try anything. Thanks, Dreday

Hi, we're looking at deploying windows / office updates to our Windows 7 machines via SCCM 2007 R3. We have both x64 and x86 machines in our environment. Most of the x64 machines are remote users and x86 machines are LAN connected in Head Office. Question is would you be better off patching these as seperate entities ie having deployment packages for x86 and x64 or have one set of packages that deploys to both machine types? We're trying to avoid making the packages we push out over VPN to the remote users larger than needed as they're cached locally from DP prior to installation. Any advice would be most helpful.... Cheers