Thursday, August 22, 2013

Video: SCCM 2012 SP1 Software Updates explained

After my post two days ago about structuring software updates in SCCM I thought I should share another item I came across recently regarding the subject. There is a fantastic video on TechNet by Kenny Buntinx that can show you the best way to structure your updates in SCCM 2012 SP1. Along the way he provides a lot of additional tips that are all really useful. This video was instrumental in helping me "unlearn" a lot of what I *thought* was the right approach to software updates in SCCM 2012 (based on the books I bought and the online guides I found). Check it out:

SCCM 201 SP1 Software Updates Explained

Tuesday, August 20, 2013

SCCM: How to structure Software Updates

I've had some real struggles with coming up with a good system for managing software updates in SCCM since we went live back in mid-2012. Its taken over a year with much hair pulling and gnashing of teeth but I think we finally have a pretty decent system in place. The worst part is all the books you buy are very confusing and (quite frankly) they tend to make recommendations that are flat wrong. Maybe they are focusing on theory rather than practicality but I'm just amazed at how badly so many books written by so-called "experts" managed to steer me off course with regards to this key feature in SCCM. I had a real eye opener at a conference recently that made me sort of "un-learn" a lot of notions that had been drilled into my brain based on three separate SCCM 2012 books. I thought I'd share some of that here so (hopefully) others won't have to struggle with repeated "trial and error" attempts to roll out a solid SCCM 2012-based software updates strategy:

Don't split updates up by product name! It’s a waste of time. The client agent on the local machine will determines product categories automatically and only downloads the updates that are needed! Instead separate and name your software update groups by periods of time. Start with 2003-2010 as updates only go back to year 2003 and all the updates up to 2010 should fit in a single package. Subsequent groups should be broken up by individual year 2011, 2012, etc. Keep update groups under 1000 updates or you will have problems. Make updates REQUIRED for Workstations. Make updates AVAILABLE for Servers. Tell application owners it’s their responsibility to install and reboot their servers. Clarify that “No Reboot = Not patched” in most cases! Reboots must be planned when installing updates! At the same time try to identify those servers that can be patched and rebooted automatically without having an impact on your user base.

Every time a software update group changes the agent has to rescan all the content of that group. For this reason you want to keep automatic update groups to a minimum! This is both in terms of the number of automatic update groups you create and the amount of updates they are allowed to contain. Create static (or non-automatic) software update groups to store your updates from previous years while limiting automatic updates to a timeframe of the last month, week or day. Not only does this make updates easier to manage it also reduces the load on both the SCCM server and the SCCM clients as update agents won’t have to constantly parse a bunch of old updates every time new updates are released! To reiterate: Use static groups for older updates and organize by year! Use automatic update groups for monthly and daily updates only!

When you create the packages for your update groups make sure to name them by year as well. You want to use a year-based package name for your automatic monthly updates as well as they will eventually be moved to a year-based group anyway. So automatic monthly updates that take place in year 2013 should target your "All Updates for 2013" package. You should plan to do yearly maintenance where you move all the automatic updates for the previous year into a static group (almost like archiving) while creating a new automatic group and year-based package for the incoming year. Also using one yearly package for all updates means you only have one package to monitor during deployments. This is done in the SCCM console under “Monitoring -> Overview -> Deployments”. The compliance column there is your exact compliance figure for the collection you are targeting (as opposed to the compliance column in the software update groups view which is for ALL SYSTEMS).

Additional tips and items to consider:

  • Microsoft best practice is to patch per month, forget quarterly it’s too complicated.
  • Enable delta updates for Distribution Points to get updates out faster and reduce server load.
  • Create alerts for updates, start with 75% compliance at first. Then move up to 80, 90, etc.
  • Updates need to go out to Pre-Production be 7-14 days out from Patch Tuesday, then wait another 7-14 days before deploying to Production.
  • Create Deployment Templates! These will allow you perform manual software update-related actions very quickly. For example: Have a template to push out day 0 critical updates immediately.


Good luck!

SCCM: Logs to check when troubleshooting software updates.

According to my page view rankings the "SCCM 2012 Log File reference" post that I did back in May of 2012 continues to be the most popular post on my blog. I suppose that means another log file related post might be in order and as luck would have it I have just the thing. I've been working pretty hard the last couple of weeks to make some rather sweeping changes to the SCCM-based software updates process at my company. During the course of testing and developing these changes I found myself constantly having to reference two specific sets of log files. One set was on the Server side and the other was on the Client side set. I thought it might be really valuable to list them here for posterity. If you are doing anything with SCCM software updates these are the logs you need to be keeping an eye on:

Server Side Software Update Logs:
SUPsetup.log - Installation of SUP Site Role.
WCM.log, WSUSCtrl.log - Configuration of WSUS Server/SUP.
WSyncMgr.log - SMS/WSUS Updates Synchronization Issues.
Objreplmgr.log - Policy Issues for Update Assignments/CI Version Info policies.
RuleEngine.log - Auto Deployment Rules.

Client Side Software Update Logs:
UpdatesDeployment.log - Deployments, SDK, UX.
UpdatesHandler.log - Updates, Download.
ScanAgent.log - Online/Offline scans, WSUS location requests.
WUAHandler.log - Update status (missing/installed - verbose logging), WU interaction.
UpdatesStore.log - Update status (missing/installed).
%windir%\WindowsUpdate.log - Scanning/Installation of updates.

Hope somebody finds this useful!

Thursday, August 1, 2013

SQL Query to report SCCM client version and install status (extended)

I needed to extend the SQL query to report SCCM client version and install status that I wrote on July 22 to include systems where the client was Null. This is what I came up with:


select distinct SYS.Name0 as 'Machine Name', ISNULL(SYS.User_Name0, 'None') as 'Login ID', ISNULL(SYS.User_Domain0, 'None') as 'Domain', ISNULL(USR.Full_User_Name0, 'None') as 'Full Name', case when SYS.Client0 = 1 then 'Yes' when SYS.Client0 = 0 then 'No (or Inactive)' when SYS.Client0 is null then 'None' else convert(varchar(2), SYS.Client0) end as 'Client Installed', ISNULL(SYS.Client_Version0, 'None') as 'Client Version' from v_R_System SYS join v_FullCollectionMembership FCM on SYS.ResourceID = FCM.ResourceID join v_Collection CN on FCM.CollectionID = CN.CollectionID left outer join v_R_User USR on SYS.User_Name0 = USR.User_Name0 where CN.Name = 'All Systems' and ( SYS.Client0 = 0 or SYS.Client0 is null )

This is useful for tracking down those stale AD records.