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.

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.

Updating of computer equipment is an aspect often overlooked by companies because there are too many constraints. It is necessary to manage downtime, while patches provide sometime malfunctions. However, updates computer equipment is a necessity for security. In this article series I will introduce you how to update your computers limiting constraints with SCCM Software update.

WSUS

WSUS (Windows Server Update Service) is a role that provides a central management point for Microsoft Update. Thanks to WSUS, all servers no longer need to connect to Microsoft Update to download patches and hotfix. WSUS is in charge of downloading updates and distribute them on different machines.

Because there are a lot of updates for several products, downloading updates is performed according to some rules such as classification, languages or products.

However WSUS can’t be used alone in a big IT infrastructure requiring automation. This product doesn’t have a granular scheduler to deploy update. This is why SCCM is used with WSUS.

 SCCM and WSUS

SCCM has a system role called Software Update Point (SUP). This role has to be installed on WSUS server. When it is set, SCCM can manage updates catalog and binaries to make updates packages. Such as WSUS, packages can be created regarding to classification, products, languages of the update (this is not an exhaustive list). Once these updates packages is created, it can be deployed with SCCM and use its powerful scheduler:

1. WSUS downloads updates catalog and update binaries when SCCM requests them.
2. Primary site configures himself WSUS role. When it is done, Primary site synchronizes updates catalog and requests binaries when the update package is creating.
3. Once an update package is created, it is deployed on Deployment Point
4. Managed servers download this package and install it regarding to maintenance period and scheduling configured on Primary Site.
5. Before installing updates, managed servers download update catalog from WSUS to validate them.

Below the network flow according to above schema:

Regarding the storage part, when WSUS is added to SCCM, it no longer stores the binary files on its own store. Binaries are on SCCM content store. However WSUS still needs a database to store update catalog.

 On the next part, I will present the configuration of an SUP point. WSUS and SCCM are installed on the same machine. But it is the same process when WSUS is installed on another server. After integration of WSUS in SCCM hierarchy, I will deploy updates by two different methods:

• Create packages and deploy it manually
• Automatic Deployment rules

Once SUP is configured correctly, the catalog of updates appears in SCCM console. A filter can be created regarding some criteria (classification, updates id, products etc.). Then updates can be added to a package and can be deployed. The deployment scheduling is configured manually. Then managed servers install updates in their maintenance period. This method is very useful on complex environment such as Exchange or Hyper-V cluster where patching should be orchestrated (move Virtual Machines or databases before patching etc.). The package can be used with System Center Orchestrator to be deployed and orchestrate patching.

Moreover the Cluster-Aware Updating is not compatible with software update from SCCM. An Orchestrator runbook should be created for this task. This is why it is possible to create a package manually and then deploy this last.

Automatic Deployment rules feature provides automatic creation and deployment of updates packages. The package creation can be scheduled (such as every second Tuesday of each month) and the choice of updates is made in function of some criteria (classification, updates id, products etc.). Once the package is created, it is automatically deployed in function of scheduling configuration. Then managed servers install updates in their maintenance period. This method should be used on mockup or simple environment.

The post SCCM Software Update PART 1 – Introduction to SCCM and WSUS appeared first on Tech-Coffee.