SCCM – Using Powershell to effectively set maintenance windows for Patch Tuesday

In this post, I will show you an example of how you can use to PowerShell to automatically set your maintenance windows for Patch Tuesday and overcome the limitations of the recurrence schedule… well in other term, make them work every months. This script is based on the one from Octavian Cordos that you can also found on Technet; Original Script

Ok so now let’s have a look the script. First it will look for all collections where the name match the following pattern, *SU_Server_Montlhy_Autoreboot_Day_*. Then it will take the last character as to set the Maintenance Window X  number of days after the patch Tuesday. i.e  (SCCM-SU_Server_Monthly_AutoReboot_Day_6 will have a MW set 6 days after). If needed you can change this pattern to match you need, and here is a example of what I have in place:

PS_MW_1

By default the script will create a maintenance window from 1:00 AM to 5:00 AM with no recurrence and it will also clean previous Maintenance Window. Note that you can change the time of the MW in the script by modifying those 2 variables and this to match your needs;

$StartTime=$PatchDay.AddDays($OffSetDays).Addhours(1)
$EndTime=$StartTime.Addhours(0).Addhours(4)  

PS_MW_2

So here’s a quick recap:

  1.  The script will scan your collections based on their name
  2. All Previous Maintenance Windows that apply to the collections who match this pattern will be deleted
  3. A Maintenance Window (who apply to Software Updates deployment) will be created for all your collections (that match the pattern) X number of day after the Patch Tuesday based on the last character in the name of the collection.

Download the script : here

Advertisements

SCCM – Software Update Groups Compliance Dashboard Revisited, Part 2

In this second part, I will share with you some of the sub reports that I have created for the main SUG dashboard (Software Update Groups Compliance Dashboard Revisited). This will give you the ability to get the details for some of the tables in the dashboard and of course they can also be run independently, as they also bring a lot of useful information.

Let’s start with the first report, which is one of my preferred ones. It’s link to the Top Vulnerable Assets table and can be very useful as it gives you all the details about the health of a specific client as well as the level of compliance for Software Updates. The report contains 3 parameters, which are:

  • Computer Name
  • Vendor – List of vendor from the update catalog
  • Category – Update classification

and also contains multiple tables such as Operating System, CM Client/AD, System Info and Software updates information. Here are some screenshot of the reports:SysInfoDetailed_1

SysInfoDetailed_2

*** It may requires that you add some AD attributes (ManagedBy, DesktopProfile) to your CM system discovery as well as adding the service status to your client policy settings ***  

And now let’s have a look to the second one, which is link to the Assets Information table. Well this part is the only one in the Dashboard that contains the information for all clients, so not only the one with the agent. There are three filters available for this reports, which are:

  • Client – All, Unmanaged and Managed
  • Operating System – filter per OS
  • Collection – filter per Collection

and it contains a table with some information about clients, which can be useful to troubleshoot your client.

SysHealth_1

I will stop here for now, as you have the reports required to drill from the first two table of the Dashboard:SubReport_1So here’s the link to get these reports:

System health for a specific computer

System Health Overall

SCCM – Software Update Groups Compliance Dashboard Revisited

So first, it’s been a long time since my last post. So I hope it will be an interesting one for you guys… and yes, it is about custom software update report again.

In this blog post, I will share with you a Dashboard for Software Updates Group and it’s based on the ones created by Gary Simmons, which are just incredible. So for those who aren’t using it yet, here’s a link that I recommended to read first, as it explains in detail most of the feature include in this Dashboard;  SUG Dashboard from Gary Simmons

First, let’s talk about the parameters, in this Dashboard I’ve change the parameters to match our needs, so for that I’ve create a filter on the software update group parameter to only show the SUG that contains compliance in the name (This is use as a template containing all the updates that are required in our company).   Other fields like Company and Entity match our Folder Structure in SCCM and Scope is the collections that are within the second level folder SCCM. Here’s an example of what we use:

SCCMHierarchy_1

And finally the OS Type parameters allows to scope this report by OS Type, Servers, Workstations, etc. it the case that you have different OS in the Collection.

Dashboard_Parameters

Ok, so in the first part of the Dashboard I’ve change the Asset table to include all devices and the ability to drill down to get the detailed information. Also, in this part I added 2 tables to first get the top 10 vulnerable systems and them the top 10 missing updates.

Dashboard_1

In the second part, I’ve added a custom Overall Systems Compliance part (again from a report from Gary Simmons) which contains all the OS Versions.

 

Dashboard_2

And lastly in the third part, I’ve added a chart to show the Compliance level per update severity, a chart about the updates scan status (% of success) and Errors details, a chart with the top 5 Windows Updates version and a table with the Software updates point status (last sync time, sync status).

Dashboard_3

here’s a link from where you can download this dashboard, in the case you are interested to try it;

SUG Compliance Dashboard

And in the next part, I will publish all the sub reports that I’ve create to drill down and get all the details information.

Part 2: Software Update Groups Compliance Dashboard Revisited, Part 2

 

 

SCCM – Software Updates Compliance Reports

Here’s a report that I’ve created to obtain the compliance status for the software updates. The first report will allow you to get the information for selected update classifications and for a specific collection. Then the second report, give you the ability to drill down for a specific computer and get the detail by computer as well as the % of compliance based on the selected classification(s).

Here are some screenshots of this reports;

Software Updates – Collection Status

img141

Software Updates – Computer Status

142

You can also expand the result by classification to get the detail.

143

Also note that the targeted count don’t include the updates which are already installed.

So if you’d like to use them, the only thing you need it’s to download those .RDL files, import it and changed the datasource for the appropriate one.

– Software update – Compliance Status By Collection

https://docs.google.com/file/d/0ByVMhVXdDQn4ak1URDE0NnhwWTg/edit?usp=sharing

– Software update – Compliance Status By Computer

https://docs.google.com/file/d/0ByVMhVXdDQn4MkNOSlhGR3pvRFU/edit?usp=sharing

SCCM – Custom Report To Get Compliance State For a Specific Computer

 

100

 

Here’s a report I’ve create, which will allow you to check the compliance state for a specific computer. Also, it allow you to select the update classification, status of the deployment (installed or required) and filter the state based on unassigned/assigned or all updates.

Moreover, if you use some folder to group your software update clients, you can limit the collection name parameter  to it. And this way, only list the appropriated clients.

RDL File;

https://docs.google.com/open?id=0ByVMhVXdDQn4M1FtV1QtbFh6MW8

SCCM – Software updates recommendation for CM 2012

Recommendation;
  • When you configure your Software Update Point, it is recommended to only select the appropriate product in the list… otherwise you will blow off your DB.
  • When you install WSUS, it is recommended to install only the wsus sdk rather then Wsus through server manager.
  • Microsoft recommended as a Best pratice to not select any product and classification when you configure the initial synch from SUP, because Wsus as it own catalog and it is not up to date. So configure the product and classification later in the properties.
  • Client settings are now collection vs site wide in configmgr in 2007, so you can have multiple Software updates policies settings within the same site based on collections.
  • No more template wizard, you must configure software update group and save settings has a template (note that you can cancel the wizard, so this only create a template).
  • Default value for software update max run time is now set to 5 minutes.
  • Deadline settings override non business hours define by the users (define in software center).
  • In Sccm 2012 Internet-based users now point to a MP into the DMZ to get the policies for the updates (mandatory and deadline) but now download content from windows update, so there are no requirement for a DP in the DMZ.
  • Software update Automatic deployment Rule (ADR), give us the ability to schedule the download of the update, update our DP, configure our deployment settings, and push the updates to the client based on filtering.
  • Wsus has nothing to do with the content, is only use for scan source.
  • Software updates groups (which is replacing the updates list) has now a limit of 1000 vs 500 in configmgr 2007.
  • Large Software updates deployment are not recommended, it’s better to use multiple smaller deployment, because largest deployment impact client side(during the evaluation, which happen in the memory) and on the server side (which have to summarize every cross-deployment between client to get the client state (compliant, non compliance, unknow, etc).
  • Updates list can be migrated to updates groups.
  • Softwre update group can be use for compliance and for deployment . Also, try to not modified the software update group, because each single change force all client to check again for compliance.
  •  If you are using ADR for patch thuesday, you must configure the properties to check the updates released or revised in the last DAY ONLY.
  • you can use search criteria title to eliminate some of the product you dont care about, ex; -“titanium”
  • when you are deploying definition (no reboot are required) updates you can set the level of state message at low, so this will eliminate all the msg for the troubleshooting about the state, like progression.
  • it is recommended to set your synchronisation 2 hours before the evalutation of the rule.
  • Let the process happen every month, so when the updates will be expipred, the will clean up automatically and also if a client his offline for 10 month. He will received all the deployment and only required 1 reboot.
  • no reason to merge multiple monthly groups in the same group.
  • expired updates are automatically removed (content + metadata) from the DP except for the updates in a active deployment, but superseeded updates not. We can choose.
Best Practice Recap;
  • Create Update groups of all required release updates for compliance report (do not exceed 1000)
  • Use migration from confmgr 2007 or create new update groups for require release updates
  • Delegated admins can create deployments of any approved update group
  • Create new group for each patch tuesday (manualy or with ADR)
  • Update groups can be used to measure compliance not deployed
  • add monthly updates tp the compliance update group each month for overall compliance
  • client optimized to evaluate multiple updates deployments with applicable updates
  • cleanup expired updates acroos your group through search
Reference;