To conclude the SCCM Software Update subject, I will present some SCCM software update best practices to manage Micorosft updates in production environments.

Subscribes to news site about updates and security

It is important to be aware about the last updates (often the second Tuesday of the month) but also the last security issue. Sometime an emergency update is released by Microsoft to fix a vulnerability so it is necessary to patch quickly and to reduce the risk to be attacked. There are many solutions to make a technology watch: RSS (ex: Microsoft bulletin), Twitter (@msftsecresponse: #security #updates) or Microsoft Security Bulletin Notification. A good source for security purpose is the CERT (sorry it is a French link J).

Create standard baselines

All your system should be set on the same way to ease management and find the issue. That means that systems should be based on the same image installation, same Operating System (as much as possible) and application version and so on. Same baseline should be gathered in the same SCCM collection to ease software updates.

Create a pre-production to validate updates

Updates should be tested before the installation on production environment. Make sure to have a pre-production environment reflect the production environment. That means that pre-production environment contains every operating system and applications that you have on production. So when Tuesday patches are released, first update pre-production environment and test that everything is ok for one or two weeks.

Create packages with pre-determined criteria

To ease the management of update packages, create them with pre-determined criteria such as products, languages, classification and release date. This avoids to reconfigure update packages every month.

Create collections for each Operating System version

Organize collections by operating system ease update packages management. In this way make an update package containing every update for the related operating system and apply it to the collection. So every month, update this update package with new updates (view next point).

Reuse update packages when possible

To limit the number of update packages and so ease management, you should reuse deployment packages most of the time. So in a perfect world, you should have one update package per operating system version (including service pack), and one per application (example: SQL Server, System Center DPM etc.).

Create an emergency procedure

Sometime Microsoft releases a security update outside of Tuesday patch process because a 0-day vulnerability has been discovered for example. That happens one or two times per year. A process to make an emergency patching for this case should exist. Usually the emergency update should take a short time such as 10 to 15 days for pre-production and production environment patching.

Enforce a deadline to install updates

I recommend to enforce install updates when the deadline is reached. However I don’t suggest to force servers restart. I recommend that because everyone knows a colleague that will never install updates because he does not give a damn! With enforcing install updates on deadline, this administrator will have to be aware about updates.

The post SCCM Software Update PART 5 – Best practices appeared first on Tech-Coffee.

Now that we have created an Automatic Deployment Rule and so deploy an update package, I will do the same thing manually. In this example I will create a deployment package for System Center Operation Manager 2012R2 with February 2014 updates. Steps to make and deploy an update package are:

1. Filter with some criteria updates
2. Select filtered updates and create a Software Update Group
3. Deploy this Software Update Group (and so on same wizard create deployment package)

Filter updates

On this screen, click on Add Criteria and choose relevant criteria. In my case I select Product and Date Released or Revised.

As below screenshot, I select System Center 2012 R2 – Operation Manager product and updates released last month.

Create software update group

Once your updates are filtered, select and right click on them. Click on Create Software Update Group.

On the next screen, type a name and a description for the Software Update Group.

Open Software Update Groups menu. The previous Software Update Groups is here. Note that those are created by Automatic Deployment Rule are also here.

Create a deployment package to deploy Updates

Right click on your Software Update Group and select deploy.

Once Deploy Software Updates wizard is opened, you can fill in the fields. Note that all settings are the same as those of the Automatic Deployment Rule.

On Deployment Settings screen, choose the type of deployment (Required or Available) and the logs detail level.

On scheduling screen, set the software available time and the deadline. I set my deadline 7 days after that the software is available.

On User Experience screen, set the client behavior about notification and deadline. On the below example, when deadline is reached, updates are installed but the server is not restarted automatically.

On Alerts screen, specify if you want to create Configuration Manager alert. Then if you use Operation Manager on your environment you should Disable Operation Manager alerts while software updates run. You can also generate alerts on Operation Manager when updates failed.

Then configure the behavior about clients on slow network boundary (slow link) and fallback source.

On Deployment Package, you can create a new update package or add updates to an existing deployment package. Choose a package source to store update binaries.

Next set a distribution point.

On Download Location, specify where download update binaries.

On Language Selection screen, select in which language you want download updates.

On Summary screen, you have the resume of the configuration. Note that you can save the deployment settings as a template.

The next screen can take time because SCCM downloads updates.

To finish, the package is created and deployed.

As you can see on below screenshot, the previous selected updates are deployed.

The post SCCM Software Update PART 4 – Create deployment packages manually appeared first on Tech-Coffee.

In this part I will create an Automatic Deployment Rule to update Windows Server 2012 R2. As a reminder, Automatic Deployment rule enables to create update package automatically according to some criteria such as release date, classification or language. The scheduler for creating update package can be fine-grained configured. It is possible for example to create update package automatically every second Tuesday of each month. Once the package is created, it is automatically deployed to deployment point and servers perform updates on their maintenance period. This update method should not be used on complex environment as Hyper-V cluster or Exchange infrastructure. These examples of environment need orchestrator to avoid downtime of services.

Create an automatic deployment rule

To create Automatic Deployment Rule open SCCM console, go to Software Library and right click on Automatic Deployment Rule and click on New:

So I create an Automatic Deployment Rule called « Baseline – W2012R2 » with the Patch Tuesday template. The current configuration can be saved as a template at the end. Each time a package is created, SCCM create automatically a new Software Update group. If the other option is chosen, a unique Software Update Group is created and updates are added to it. That means each time an update package is deployed, it will contain all updates even those that are already deployed. For Tuesday patching, I recommend to create new Software Update Group.

On deployment settings, specify if you want use Wake-on-LAN (useless on servers because at 99% of the time there are always switch on). Next select the desire logs detail level and the behavior about license agreements.

On software updates screen, set the criteria for choosing the updates that will be added to update package. In my example I choose updates that match these criteria:

• Release or revised on last month.
• Updates target Windows Server 2012 R2.
• Updates have to be English language.
• Updates have to be Critical updates or Definition Updates or Security Updates or Rollups or a simple update.

On evaluation schedule, specify when run the rule to make an update package. On my example, I run the rule every second Wednesday of each month (in France updates are available Wednesday because time difference).

On deployment schedule, specify the update package available time and the installation deadline. Mostly these settings should be configured regarding company security policies.

On user experience screen, set the behavior on clients side. Specify notifications level to display on Software Center, the behavior when the deadline is reached and you can suppress restart on specific devices such as server.

Alerts screen is really useful when Operation Manager monitor IT Infrastructure. It is possible to disable monitoring on servers that will be updated and generates alerts if an update fails. Also a report can be generated on Configuration Manager.

Downloads settings screen enables to configure clients’ behavior for downloading when there are on a slow link (slow site boundaries in SCCM language). For this type of clients, you can specify a fallback distribution point

On deployment package screen, you create your update package. It is necessary to specify a package source: this is the path where update binaries are stored. A folder can’t be used for more than one package source. If a deployment package already exists, you can select it.

On distribution points screen, specify SCCM distribution points where the deployment package will be sent.

On download location screen, select the source of downloading updates.

Then select the languages downloaded …

To finish confirm settings. Note that you can Save as Template your Automatic Deployment rule.

Once your Automatic Deployment Rule is created, it appears in the menu. On the same line, you can see the last error. Here the rule has run without error.

After that Automatic Deployment Rule has run, the update package is created and is deployed.

Then Software Center on clients can install updates on maintenance period. Note that you can install manually updates.

The post Software Update with SCCM PART 3 – Automatic Deployment Rules appeared first on Tech-Coffee.

Add Software Update Point in SCCM hierarchy

First, connect to SCCM, open Administration panel and select Site Configuration -> Servers and Sites System Roles. On the below screenshot, VMSMS01.fabrikam.com is my Primary Site with WSUS installed but not configured (I stopped myself just after configuring the WSUS database). This is SCCM that set parameters on WSUS.

Figure 1: Servers and Site System Roles overview

So I right click on the VMSMS01.fabrikam.com server and I select Add Site System Roles. The goal is to add Software Update Point and configure WSUS service.

Figure 2: Choose server on which role will be installed

Figure 3: Set a proxy if necessary

Once you have chosen the server where will be added SUP and after configured proxy, it’s necessary to specify the role to add. I think you have an idea of which role to select … Tadaa: Software Update Point.

Figure 4: Add Software Update Point role

My WSUS installed is set to answer on 443 port because I have a PKI in my lab with auto-enrollment. So I can test the communication between SCCM and WSUS with SSL. If you have not configured WSUS with SSL, don’t select checkbox Require SSL communication to the WSUS server.

Figure 5: Configure how to connect to WSUS service

Next step asks you to configure credentials to connect to WSUS server. This step is needed in a production environment to specify a special account to communicate between WSUS and SCCM.

Figure 6: Set credentials with right on WSUS service

Next, it is the configuration of WSUS. You will retrieve the same step when you are configuring WSUS. First you have to specify the source of synchronizing Microsoft update. My WSUS is the first WSUS on my lab so I select Synchronize from Microsoft Update. If you have an upstream server, please select the other option.

The WSUS report parameter should be configured with the first option in 95% of time because SCCM doesn’t use these reports. These last are created on client computers for Windows Update services and SCCM doesn’t use them.

Figure 7: Set synchronization source settings

Such as classical configuration of WSUS, you have to set how often synchronization occurs. Because I have no requirement on my lab, I leave the default settings.

Figure 8: set how often synchronization occur

To understand next step it is necessary to make a point about superseded update.

Suppose that an update (called U1) fix Internet Explorer 11 on December 2013 and another update (called U2) fix same product released on January 2014. U2 is a cumulative update that contains also U1. In this example, U1 is superseded by U2.

So on supersedence rules, you have to configure the behavior of update that are superseded. Like previous step, I have no requirement on my lab so I leave the default settings.

Figure 9: Configure behavior about superseded update.

For my lab, I download all classifications because I will sort when I will make my updates packages.

Figure 10: Software update classifications

WSUS needs to synchronize once a time to have a more recent product catalog. This is why Windows Server 2012R2 doesn’t appear.

Figure 11: Products to synchronize

Figure 12: language to synchronize

Figure 13: Confirm settings

Figure 14: End of SUP configuration

Verify the good configuration

In this section, I verify that SUP configuration is correct. The first place to be is the monitoring view on Software Update Point Synchronization Status. This status provides information about the last synchronization with WSUS.

Figure 15: WSUS synchronization monitoring

Figure 16: SCCM logs files

To debug an issue, the best way is to open logs files. All these files are in %INSTALLFOLDER%\Microsoft Configuration Manager\Logs

The file WSUSCtrl.log contains information about WSUS synchronization (c.f Figure 17)

Figure 17: WSUSCtrl content

The above screenshot presents a successfully configuration and synchronization with WSUS.

Figure 18: Update catalogs on SCCM

When the synchronization with WSUS is finished, updates appear in the Software update menu.

The post SCCM Software Update PART 2 – Software Update Point configuration appeared first on Tech-Coffee.