In Part 1, SCCM Prerequisites have been downloaded and the AD schema has been extended.

In Part 2, the dedicated SQL Server (with SSRS) has been installed and configured.

Server: M-SCCM1 

Article Parts:

• Part 1: SCCM 2012 R2 Environment Preparation / Requirements
• Part 2: SCCM 2012 R2 SQL Server Installation-Configuration
• Part 3: SCCM 2012 R2 Primary Site Installation

SCCM Primary Site Server – Installation

Components required

Storage Requirement

Service Accounts

• Create accounts and groups

• Add your account to the SCCMAdmins group
• Add SCCMAdmins group to Local Administrators of M-SCCM1 server

Account: svc-confmgrlocaladm

This account is needed if you deploy SCCM client by using the client push installation method.

The Client Push Installation Account is used to connect to computers and install the Configuration Manager client software. This account must be a member of the local Administrators group on the computers where the Configuration Manager client software is to be installed. This account does not require Domain Admin rights. You can specify one or more Client Push Installation Accounts, which Configuration Manager tries in turn until one succeeds.

Account: svc-sccmnaa

This account (Network access account)is needed during OS deployment in WinPE to access content on the network which is referenced by the task sequence. This account might also be used during operating system deployment when the computer installing the operating system does not yet have a computer account on the domain.

I will configure it later.

Account: svc-sccmjd

This account will be used for join computer to domain during a deployment. To do that, this account required AD permission:

On the “Join to Domain” task, you can specify the OU where you want to add the computer. So you have to Delegate Control on each OU that you want to use.

Right-click on the OU and select “Delegate Control…”

Add the account:

Select “Create a custom task to delegate”:

Select these options:

Select these permissions:

For more information about SCCM accounts, see TechNet article “Technical Reference for Accounts Used in Configuration Manager“: https://technet.microsoft.com/en-us/library/hh427337.aspx

Prerequisites

Windows Features

From PowerShell:

Add-WindowsFeature Web-Windows-Auth,Web-ISAPI-Ext,Web-Metabase,Web-WMI,RDC,NET-Framework-Features,Web-Asp-Net,Web-Asp-Net45,
NET-HTTP-Activation,NET-Non-HTTP-Activ,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,
Web-Http-Redirect,Web-App-Dev,Web-Net-Ext,Web-Net-Ext45,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,
Web-Request-Monitor,Web-HTTP-Tracing,Web-Security,Web-Filtering,Web-Performance,Web-Stat-Compression,Web-Mgmt-Console,
Web-Scripting-Tools,Web-Mgmt-Compat
-Restart –Source V:\sources\sxs

Register ASP.NET with IIS.  Open an elevated command prompt and enter:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319>aspnet_regiis.exe –r

Install ADK 8.1

Mount ISO previously created.

Launch “adksetup” and install these three features:

Note for automated installation: Command to do a silent install

Size Installed: around 1.7 GB

Install SCCM Primary Site

OK, now we can install the Primary Site. On M-SCCM1 VM mount two DVD drives:

• One with the SCCM 2012R2 ISO
• One with the SCCM Prerequisites ISO (create during Preparation)

Launch the Installer and select “Install”

Leave the default option:

Enter your Key (or choose 180 days evaluation):

Accept all Licenses, these components will be installed (except SQL Server 2012 Express, I already installed a SQL Server):

Specify path to files downloaded previously (Prerequisites ISO mounted on DVD):

Select Language:

Enter Information (Site Code, name) and change path:

Select “Install the primary site as stand-alone”

If needed, it’s possible to install later a CAS Server:

Enter SQL information (note that we cannot specify an Instance port, so the SQL Browser service must be enabled):

(*) on remote SQL server, special firewall rules must be created (in addition to standard SQL rules). See “Part 2 – SQL Server Installation” for more information.

Specify Database files path:

SMS Provider:

Configure Communication:

We will configure HTTPS later

Now we specify that the server will host a “Management Point” and a “Distribution Point”:

Start the installation :

Installation Done:

Install Trace Log Tool

SCCM logs are store in: D:\Program Files\Microsoft Configuration Manager\Logs

A Log viewer tool name “Trace Log Tool” is available on the SCCM DVD.

Go to the DVD drive (x:\SMSSETUP\TOOLS) and copy CMTrace.exe to the server.

Now you can open SCCM logs:

Next

The next step is to configure the Primary Site and SCCM roles:

• Part 4: SCCM 2012 R2Primary Site Configuration

In addition, Firewall must be configured to allow clients / other SCCM Servers communication. See the article:

• ANNEX – SCCM 2012 R2 Configure Firewall

The post SCCM 2012 R2 Primary Site Installation appeared first on Tech-Coffee.

SQL server will be installed on a dedicated server. (If SQL server is installed on the same server as the SCCM Primary Site, some steps are not necessary)

Server: M-SQL1

Article Parts:

• Part 1: SCCM 2012 R2 Environment Preparation / Requirements
• Part 2: SCCM 2012 R2 SQL Server Installation-Configuration
• Part 3: SCCM 2012 R2 Primary Site Installation

Preparation

Components required

Storage Requirement

Note [Production]:

• Disk Sizes are for a Lab environment.
  
• For Production it is recommended to add:
  
  • 1x “BIN” disk for “SQL Server”, “System DB” and “Reporting Service” data.
    
  • 1x “TEMPDB” disk for TempDB Database and Log.
    

Service Accounts

• Create accounts and groups
  

Note [Production]: You can use MSA accounts for Database Engine and Agent Services

• Add your account to the SCCMSQLAdmins group
  
• Add SCCMSQLAdmins group to Local Administrators of M-SQL1 server
  

Prerequisites

Remote Registry:

Check if “Remote Registry” service is set to Automatic startup and started (*):

(*) required by SCCM if SQL is installed on a remote Server.

Install .NET 3.5 features:

Install-WindowsFeature NET-Framework-Core -Source V:\sources\sxs

Download the last Cummulative update for SQL Server: https://support.microsoft.com/kb/2772858/en-us Copy it on the SQL Server (e:\CU)

SQL Server – Installation

Launch a CMD (as Administrator), start setup from DVD drive (with CU included):

Select “SQL Server Feature Installation”:

Select features:

Select “Named instance” and enter a Name:

Note: You can add a “BIN” disk for instance root directory.

Required space:

Enter services account and configure Startup Type:

For security reason, it’s not recommended to enable Browser Service (but it’s required with SCCM if you want to change the instance port, see “SQL Design Note /Requirement” chapter)

Select collation: SQL_Latin1_General_CP1_CI_AS

Configure your Security option (it’s recommended to keep the “sa” account as a lifeboat account, but you have to rename it):

Enter your path:

On the SSRS page, select “Install and configure”:

Start the installation:

Check SSRS configuration

You can check Reporting DB creation:

From « Reporting Configuration Manager », service account:

Web Service Configuration:

Test it:

Report Manager URL Configuration:

Test it:

Status must be “Joined”:

SQL Configuration

Configure Instance Port

Use Script: SQL_Set-Instance-Port.ps1

Start a PowerShell console (as Administrator) and run:

SQL_Set-Instance-Port.ps1 -SQLInstance <instancename> – StaticPort <yourport>

Check Configuration:

Use Script: SQL_Get-Instance-Network.ps1

Note: “TcpDynamicPorts” column must be empty (if there is a 0, you have to remove it)

Restart instance and check services:

Set SPN

To use Kerberos authentication (in place of NTLM), a SPN must be created. Register SPN for the SQL Domain Service Account:

Check:

TIPS: Check Authentication mode from SQL:

SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

-- Example to check SCCM connection:
SELECT session_id, net_transport, auth_scheme,encrypt_option, client_net_address,
client_tcp_port, local_tcp_port
FROM sys.dm_exec_connections
WHERE client_net_address = '10.0.1.10'

Configure Firewall

Use Script: FW_Create-SQLRules.ps1

This script creates incoming rules for SQL Instance, SQL Browser and SQL Broker services.

Edit the script and change the Instance port (1640 in this example).

NOTE for SCCM Installation:

These rules are not sufficient to install SCCM. The setup will fail to join the Remote SQL Server. It is also necessary to open additional Ports:

Use Script: FW_Create-SQLRules-AdditionalSCCM.ps1

Note: These ports are required only for installation, so you have two options:

• Disable SQL Server firewall during SCCM installation
  

• Open ports with the script bellow, install SCCM and disable rules after.
  

Configure rights for SCCM Server on SQL Server

This Step must be done if SQL Server is installed on a Remote Server.

The SCCM server computer account needs “sysadmin” rights on the SQL Server

On SQL Server, it’s impossible to add a computer accounts as logins. So the solution is to create a group with the SCCM computer account and add SQL rights to this group.

On the SQL Server, create a local group “SCCMServers” and add the SCCM Server account:

From Management Studio, create a new login with this group and add “sysadmin” right.

Select the local group created before:

Give the “sysadmin” Server role:

Close Management Studio.

Administrators Right:

Add the SCCM Server computer account to the local “Administrators” group on the SQL Server:

Else there is a failed during install checks:

The post SCCM 2012 R2 SQL Server Installation-Configuration appeared first on Tech-Coffee.

• One server for SQL and Reporting services
  
• One server for SCCM Primary Site
  
• One server for a secondary SCCM Management and Deployment Point (it will be used later for SUP roles and Application Catalog).
  

All servers are installed with Windows Server 2012 R2.

This article not covers a SCCM CAS (Central Administration Site) Server deployment (need if you plan to deploy multiple Primary Sites).

Article Parts:

• Part 1: SCCM 2012 R2 Environment Preparation / Requirements
• Part 2: SCCM 2012 R2 SQL Server Installation-Configuration
• Part 3: SCCM 2012 R2 Primary Site Installation

SCCM 2012 R2 – Design Guide

This part is not cover in this article. For more information see TechNet:

• Fundamentals of Configuration Manager
  https://technet.microsoft.com/en-us/library/gg682106.aspx
  

• Planning for Configuration Manager Sites and Hierarchy
  https://technet.microsoft.com/en-us/library/gg682075.aspx
  

• Site and Site System Role Scalability
  https://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SiteAndRoleScale
  

SQL – Design Guide

There are a lot of constraints for SQL on a SCCM environment.

High Availability:

• Configuration not supported:
  

• Configuration supported:

SQL Database Engine:

For Secondary Site:

Configuration:

TCP Port (Instance):

I’m currently testing to force the TCP port in the “SQL Server Native client” configuration, SCCM server can connect to the database but I have not tested whether there were other impacts (in addition, if it works, I’m not sure it is supported by Microsoft..). The solution of the alias is not working.

TCP Port (Broker):

SQL Server Memory:

SCCM Reporting Service Point (SSRS Instance):

Components Requirements

Notes: Internet Information Services (IIS)

SCCM Site Systems roles which require IIS:

• Application Catalog web service point
• Application Catalog website point
• Distribution point
• Enrollment point
• Enrollment proxy point
• Fallback status point
• Management point
• Software update point

Note: IIS must be enabled before SCCM Components installation

Components

(*) On a Deployment Point, WDS feature is automatically installed when PXE option is enabled. But if you want to specify a custom path for “RemoteInstall” folder you have to install and configure feature before enabling PXE.

Preparation

Sources needed:

• ISO – WS2012 R2 Standard or Enterprise
  
• ISO – SQL Server 2012 Enterprise with SP1
  
• ISO – SCCM 2012 R2
  
• FILES – SQL Server 2012 SP1 Update(s) (Actually CU7)
  
• FILES – ADK 8.1 (download offline files)
  
• FILES – SCCM Prerequisite files (see below)
  

Download SCCM Prerequisites

From a computer (x64) with Internet Connection:

• Navigate to SCCM 2012 R2 ISO source: .\smssetup\bin\X64
• Run SetupDL.exe <targetdir> (Example SetupDL.exe E:\CM2012PR)
  

This download .Net 4.0, SQL Express (not needed but you can skip this step), etc…

Build an ISO with this source and copy it on Hyper-V/SCVMM.

Download ADK Prerequisites

Download “adksetup.exe” file:

Windows Assessment and Deployment Kit (Windows ADK) for Windows 8.1 Update – https://www.microsoft.com/en-us/download/details.aspx?id=39982

For more information about ADK tools, see TechNet article – “Windows Deployment Tools Technical Reference“: https://technet.microsoft.com/en-us/library/hh825039.aspx

Select “Download the Windows Assessment….” and specify a path

Build an ISO with the sources:

Extend Active Directory Schema for SCCM

Extend the AD schema is not mandatory for SCCM. However it facilitates client administration, especially for the following points (TechNet extract):

For more information, see TechNet article “Determine Whether to Extend the Active Directory Schema for Configuration Manager” – https://technet.microsoft.com/en-us/library/gg712272.aspx

Four actions are required to successfully enable Configuration Manager Clients to query AD DS to locate site resources:

• Extend the Active Directory schema.
• Create the System Management container.
• Set security permissions on the System Management container.
• Enable Active Directory publishing for the Configuration Manager site

For more information, see TechNet article “Prepare the Windows Environment for Configuration Manager” – https://technet.microsoft.com/en-us/library/gg712264.aspx#BKMK_PrepAD

Note about previous versions:

The SCCM 2012 R2 AD Schema Extensions are the same as SCCM 2007, 2012 or 2012 SP1. So if you have already extended the schema for a previous mentioned above, you do not have to extend it again to install SCCM 2012 R2.

Extend the Active Directory schema

Create a checkpoint of your Domain Controller (I have only one DC):

Logon a server with an account that is a member of “Schema Admins” security group.

From SCCM ISO run .\SMSSETUP\BIN\X64\extadsch.exe

Check schema extension result, open extadsch.log located in the root of the system drive.

Create the System Management Container

Configuration Manager does not automatically create the System Management container in Active Directory Domain Services when the schema is extended. The container must be created one time for each domain that includes a Configuration Manager primary site server or secondary site server that publishes site information to Active Directory Domain Services

Start ADSI Edit, go to the “System” containter and create a new Object:

Select “container”:

Enter “System Management”:

Set Security Permissions on the System Management Container

Open properties of the container “System Management” created previously.

In the “Security” tab, add the site server computer account and Grant the “Full Control” permissions.

Click Advanced, select the site server’s computer account, and then click Edit.

In the “Applies to” list, select “This object and all descendant objects“.

Click OK and close the ADSIEdit console.

The post SCCM 2012 R2 Environment Preparation Requirements appeared first on Tech-Coffee.

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.

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.