Posts Tagged Software Updates
An added feature to ConfigMgr 2012 is the ability to directly deploy software updates without them being a deployment group. This can result in a “gotcha” moment when update are incidentally deployed to systems. This situation occurred to me recently when IE9 was deployed to a collection (fortunately non-mandatory!) but I could not find that update in any deployment group. If it has been deployed as part of many updates, then this would have never occurred and I could have easily removed the update.
The way to get yourself into this predicament is by doing the following. Note: this is just a lesson, don’t actually do this in production!
- In the console, navigate to Software Library > Software Updates > All Software Updates
- Select a single updates to install
- Select “Deploy” on the wunderbar
- Note that in the first page of the wizard, it LOOKS like you’re adding updates into a software update group.
- Finish the wizard with whatever settings (please don’t make this a Required install, lest you screw yourself)
Now go into node Software Update Groups. Where is the deployment group that was supposed just created? It isn’t there!! To then delete the deployment, find an individual update, go to the Deployment “tab” and delete the deployment. Note how the update group says “Individual”
To prevent this from accidentally occurring to you, a general rule of thumb is to add the update(s) to be installed into a new or existing Software Update Group and then deploy that group to a collection.
The key to protecting an environment from incidental patching during a transition from using WSUS to using SCCM with Software Updates is to reconfigure three group policies which have an impact on SCCM software updates.
- Specify intranet Microsoft update service location: the SCCM client sets this as a local GPO pointing to the SCCM\WSUS server. (Note: It could be possible to set these values as domain GPO, but the trouble is that there are two SCCM servers acting as WSUS for their clients, so managing multiple GPOs would be more pain than value.)
- Configure Automatic Updates: this will set the automatic update settings. I’ve seen that once this was turned off in GPO, it kept the default to automatically download and install updates. It is possible to set this to Disabled without impacting SCCM’s delivery of security updates, but it will impact delivery of FEP definition updates. With SCCM 2007 and FEP 2010, in order for definition updates to automatically install, auto approval actually gets set in WSUS itself, so therefore disabling AU would mean no delivery of those updates and need to be re-enable in the future.
- The final GPO is just configuration of the Automatic Updates windows service. If the GPO disables the service, then no updates will work. A forced enable of the service through GPO would be a good thing.
A route for the WSUS to SUP migration could look like this:
- Configure Automatic Updates set to Disabled
- Enable the AU windows service
- Optional: continue to disable user’s ability to get updates themselves from Windows Update
- Set all other WSUS related GPOs to not configured
- Deploy the SCCM client upgrade/changeover
- Later, as part of a FEP migration, use GPO to configure automatic updates to be enabled (since that will be needed for automating the definition update releases)
You may be asking, what does IIS bindings have to do with SCCM software updates. Well, let me tell you lol.
I’ve stood up a new SCCM infrastructure including site configuration/roles and deployed a few clients. When testing software updates on a client, software update scan/deployment cycles kept failing. Upon investigation of logs, the scan were failing with “Scan failed with error = 0x80072efd”. Furthermore, reporting showed scan error failure code -2147012867. These errors indicate that the Windows Update Agent could not communicate with the defined source location.
The troubleshooting difficulty is that there are many possibilities of causing this.
- Local GPO “Specify intranet Microsoft update service location”. When using SCCM software updates, the client sets this local GPO on the client pointing to the WSUS location. In my case this wasn’t it.
- Windows Firewall blocking the ports used by WSUS, on either the client or server. In my case this wasn’t it.
- A proxy or bad winhttp settings redirecting the traffic incorrectly from client to server. In my case this wasn’t it.
- Various other things.
I believed that I had reached the end of the Internet at this point when finally I came across a posting on WindowsNoob that steered me in the right direction. To fix a different technical problem with WSUS conflicting with Symantec Endpoint Protection, I swapped the Software Updates Component from using ports 80/443 to using ports 8530/8531. I guess with this change, SCCM didn’t automagically configure the default website in IIS bindings to listen for requests on the newly defined port.
So to resolve the issue, I did the following:
- Open IIS Manager
- Right-click on the default website and select “Edit Bindings”
- Add port 8530 as an IIS binding….and voila it works.
A challenge with installing software updates during a task sequence is that it may occur where not all updates are applied on the first pass. The workaround is run software updates, run a VB Script or PowerShell script to force another scan, then run a software updates task again. Others have posted their scripts on this before, so it’s nothing new. However, I failed trying to quickly locate those scripts. So I’m just posting my own of what I use….
'========================================================================== ' AUTHOR: Nick Moseley , http://t3chn1ck.wordpress.com ' DATE : 7/30/2010 ' COMMENT: Initiates an SCCM client scan ' Script from http://msdn.microsoft.com/en-us/library/cc144313.aspx ' Updated 7/15/11 to include a sleep before exiting script '========================================================================== ' Set the required variables. actionNameToRun = "Updates Source Scan Cycle" ' Create a CPAppletMgr instance. Dim oCPAppletMgr Set oCPAppletMgr = CreateObject("CPApplet.CPAppletMgr") ' Get the available ClientActions object. Dim oClientActions Set oClientActions = oCPAppletMgr.GetClientActions() ' Loop through the available client actions. Run the matching client action when it is found. Dim oClientAction For Each oClientAction In oClientActions If oClientAction.Name = actionNameToRun Then oClientAction.PerformAction End If Next ' Wait for 3 minutes for scan completion before exiting script wscript.sleep(180000)
Ran into an interesting situation with an image build. I created a custom Office 2010 SP1 install using the OCT. During execution of my image build task sequence, Software Updates was not detecting any of the updates for Office. Further diagnosis revealed that the OCT-built install did not put its “hooks” into the Windows Update Agent, therefore neither the SUP or Microsoft Updates could detect for Office updates. (Side note: once the image was sysprepped, captured, and added into a deployment task sequence, the updates were suddenly available and installed.)
While the cause as to why an OCT-built Office 2010 SP1 install prohibits installation of updates has not been found yet, there is a workaround to run a script that forces Microsoft Update (e.g. WUA) to receive updates for “other products”. By executing the following VBScript after installing Office, SCCM Software Updates will then be able to install the updates during the image build task sequence. The original code is from a TechNet blog post, I just added some extra logging for troubleshooting. Also, if your TS advertisement is configured to “run from server”, then the script will cause the TS to fail. To get past this, simply copy the script locally first then execute it from that location.
Const ForAppending = 8 Set oFSO = CreateObject ("Scripting.FileSystemObject") Set oLogFile = oFSO.OpenTextFile ("C:\ConfigOfficeUpdates.txt", ForAppending, True) oLogFile.WriteLine "Starting execution of VBScript to configure Office to use Microsoft Updates" Set ServiceManager = CreateObject("Microsoft.Update.ServiceManager") ServiceManager.ClientApplicationID = "My App" ' add the Microsoft Update Service by GUID Set NewUpdateService = ServiceManager.AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"") oLogFile.WriteLine "Script completed successfully" wscript.Quit(oLogFile.Close)
This is the search folder that I use to identify any and all security updates possibly available to Windows workstation OS computers. It includes other products too, not just Windows.
- Expression Media\Web
- MS Lync 2010
- MS StreamInsight
- MS Works
- Network Monitor
- Office 2003/2007/2010
- Report Viewer
- SQL Server
- Visual Studio
- Windows 7 Client
- Windows Defender
- Windows Vista
- Windows XP
- Works 6-9 Converter
- Writer Installation and Upgrades
- Update Classification:
- Critical Updates
- Security Updates
- Update Rollups
- Expired: No
- Superseded: No
- Malicious software removal tool
- Visual C++
Finally, select the option “Search all folders under this feature”
SCCM doesn’t have a precreated report (that I can find) that quickly shows the patch compliance for a group of systems. So I created one for myself, that I thought I’d share with every one. To implement this, create a web report as you normally would; use the following SQL statement and remember to create a prompt with the information below that!
select distinct sys.Name0, ui.BulletinID as BulletinID, ui.ArticleID as ArticleID, ui.Title as Title from v_UpdateComplianceStatus css join v_UpdateInfo ui on ui.CI_ID=css.CI_ID join v_R_System sys on css.ResourceID=sys.ResourceID join v_ClientCollectionMembers ccm on ccm.ResourceID=sys.ResourceID where css.Status=2 and ccm.CollectionID=@CollID order by sys.Name0, ui.ArticleID
Prompt text: Collection ID
Provide a SQL statement:
begin if (@__filterwildcard = '') select CollectionID as CollectionID, Name as CollectionName from v_Collection order by Name else select CollectionID as CollectionID, Name as CollectionName from v_Collection WHERE CollectionID like @__filterwildcard or Name like @__filterwildcard order by Name end