Overview of System Center 2012 R2 / Current Branch – Configuration Manager
SCCM Sites
A site contains a Site Server, a database and site systems running various site system roles. A primary site also contains clients that have been assigned to the site.
There are three types of SCCM site:
- Central Administration Site: Optional. Only needed if there is more than one primary site. It has no clients, and always sits at the top of the SCCM hierarchy, with primary sites below it.
- Primary Site: Required. Clients can only be assigned to primary sites.
- Secondary Site: Optional. Clients can’t be assigned to secondary sites, but they can be physically located in it and use its site systems. A secondary site would be created at a remote location containing between a few hundred and 5000 clients, usually because it enables administrators to control the traffic between the main location and the remote location. Secondary sites are always below primary sites in the hierarchy.
An SCCM hierarchy of sites might consist of:
- a single stand-alone primary site,
- a stand-alone primary site with some secondary sites below it
- a central administration site with several primary sites below it, each of which might have secondary sites below it.
Site Systems
A site system is a computer (usually running Windows Server) that is running one or more site system roles. Roles include:
- Site Server: runs the site (required in all sites)
- Site Database Server: holds the site database (required in all sites)
- Reporting Services Point: allows reports to be run showing data in the database, eg about clients or deployments of software etc
- Management Point: required in primary and secondary sites containing clients – it’s a client’s main point of contact with SCCM.
- Distribution Point: used in primary and secondary sites to hold content (eg software, software updates and operating system images)
Other roles are added as needed, depending on which SCCM features are being used.
Administration
The Administration Console is connected to the database of a Central admin or primary site, but it shows the entire hierarchy. It has four workspaces:
- Assets and Compliance: shows users, devices, collections, Asset Intelligence, Software Metering, Compliance Settings, Endpoint Protection,
- Software Library: to deploy software, software updates and operating systems
- Monitoring: monitor SCCM using alerts, queries and reports, view the results of deployments of software, software updates and operating systems
- Administration: used mainly to set up the sites and site systems in the early stages of the rollout of SCCM
Searches in the console can be:
Local – done on objects in the selected node, or
Global – done on objects throughout the console
Global – done on objects throughout the console
…and can be:
Free text search – type in some text to search for, and/or
Criteria search – choose criteria and compare them with values you type in
Free text search – type in some text to search for, and/or
Criteria search – choose criteria and compare them with values you type in
Powershell commands can be used to do most things that can be done in the Admin Console
Troubleshooting
On site systems, a number of SCCM components run. Most of them are threads within the SMS Executive service. Each has its own function, is woken up when it has work to do (eg data to process) and wakes up from time to time to check if there’s anything it needs to do. The SCCM client components also have their own jobs to do.
Resources for troubleshooting SCCM components include:
- Status messages, generated by each component when it’s done something or has a problem. They can be Informational, Warning or Error messages. They’re stored in the site database and can be viewed in the SCCM Admin console
- Log files – each component writes detailed information about what it’s doing into its own log file. View the log files using the Configuration Manager Trace Log Tool (CMtrace.exe)
- Reports, which extract data from the database and display it. They can show data reported by the clients, or the progress of processes like deploying software.
Discovering and Organizing Resources
Boundaries and boundary groups
A boundary is a set of IP addresses that are well-connected. It can be expressed as:
- an IP subnet
- a range of IP addresses
- an Active Directory site
- an IPv6 network prefix
Boundaries must be put into boundary groups to be used. A boundary group can be used:
- For site assignment: if you associate a boundary group with one SCCM site, a client set to auto-assign itself to a site will join the site if its IP address is currently within the boundaries in the boundary group.
- For content location: if you associate a distribution point with a boundary group, and when a client in the boundaries of the boundary group is looking for content on distribution points, it will prefer the associated DP. The DP may itself be within the boundary group, or it may be the closest DP to it.
Discovery
Discovery is the process of finding computers, users, AD sites or subnets, collecting some basic information about them, and creating objects to represent them in the SCCM database.
Active Directory Forest Discovery can search the AD forest for AD sites and subnets. Optionally, it will create AD site boundaries and IP address range boundaries in the SCCM database to represent them.
Other discovery methods look for computers, users or user groups.
Active Directory System Discovery contacts an AD domain controller, looking for enabled computer accounts. It can search the domains or organisational units specified by the administrator, on a specified schedule. It collects certain attributes (configurable) about each computer account and creates a new System Resource object in the SCCM database for each computer.
Active Directory User Discovery does the same, creating User Resource objects in the SCCM database for each user account found in AD.
Active Directory User Group Discovery looks in AD for security groups, creating User Group Resource objects in the SCCM database for each one found.
Network Discovery searches the network for computers that are online.
Heartbeat Discovery runs on installed SCCM clients every week by default to refresh their discovery information in the SCCM database.
Collections
A collection is a set of either computers (device collection) or users and/or user groups (user collection). It can be used for:
- targeting deployments of software, software updates, and task sequences (which can install operating systems)
- targeting Configuration Baselines (in Compliance Settings)
- applying power plans
- scoping role-based administration
- setting maintenance windows on computers
A collection’s membership is defined by one or more membership rules. There are four types of rule:
Direct: to put users or computers manually into a collection
Query: a query is run regularly against the database to select suitable users or computers to put in the collection
Include Collection: include the members of another collection in this one
Exclude Collection: exclude the members of another collection from this one
Query: a query is run regularly against the database to select suitable users or computers to put in the collection
Include Collection: include the members of another collection in this one
Exclude Collection: exclude the members of another collection from this one
Two new features of collections in SCCM 2012 & R2:
- A collection must be based on a limiting collection. Only members of the limiting collection can belong to the collection, but they’re not actually made members of the collection – the membership rules control which objects belong to the collection.
- Sub collections no longer exist (use the include and exclude collection rules instead)
A maintenance window is a property of a collection, and is a period of time. Required deployments of software, software updates and task sequences (to install operating systems) may only run on computers in the collection during those hours. Other processes (eg inventory, policy download) continue outside the maintenance windows. For an urgent required deployment, the client can be told to ignore its maintenance windows.
Role-based security
This controls what SCCM administrators are allowed to administer, ie which tasks they can do, and on which objects in the SCCM database. (For example, an administrator could be allowed to deploy applications, but only certain specified desktop applications and only to the Windows 8.1 computers.)
A security role is a set of permissions on various types of objects in the SCCM database that define what tasks someone with that role can perform. Several roles have been predefined. To make new ones, copy one of the existing roles and edit it.
One or more security roles is assigned to a user or group – the user is then described as an Administrative User.
When assigning a role to a user, you can control which objects s/he can use the role on by specifying:
- one or more collections – this limits the use of the role to the users or computers in the collection(s)
- one or more security scopes – this limits the use of the role to the objects in the security scope(s) eg packages, applications, queries, boundary groups etc
Client installation
To manage a computer, the SCCM client software must be installed on it. This consists of core components and a set of agents, each of which handles a particular SCCM feature (eg the hardware inventory agent)
The installation is started by running CCMsetup.exe (or CCMsetup.msi). This downloads loads the client software and installs it using Client.msi.
Methods for installing the client software include:
- Client push installation – the site server connects to a newly-discovered computer and starts CCMsetup.exe (‘pushes’ the client software).
- Group policy installation – a GPO is configured to deploy CCMsetup.msi to the computers
- Software Update Point installation – the client software is deployed as a software update, to computers with or without the client software already installed
- Manual installation – an administrator at the computer connects to the server and runs CCMsetup.exe
- Logon script installation – a call to CCMsetup.exe is included in users’ login scripts (administrators only)
- Software deployment – deploying a new version of the client software to existing clients, using standard SCCM software deployment.
- Operating system deployment – the task sequence that installs an operating system image on a computer then installs the SCCM client software
- Computer imaging – install the client software on the reference computer that you take an image of, and then deploy to new computers.
Client Assignment
The client must be assigned to a primary site before it can start working properly. The methods for doing this are:
- Manual site assignment – give the new client the site code of the site it must join as the client software installs
- Automatic site assignment – let the client choose the correct site to join, based on which site’s boundary its current IP address is in.
Client settings
Client settings tell the client which SCCM features it should use, and how they are configured (eg “Do Hardware Inventory, every 7 days”)
Default client settings apply to all clients.
Sets of Custom client settings can also be created and deployed to one or more collections. These do not have to include all of the possible settings.
Sets of Custom client settings can also be created and deployed to one or more collections. These do not have to include all of the possible settings.
Each set of client settings has a priority (low numbers equal highest priority). If more than one set of client settings has been deployed to a client, it uses them in order, starting with the lowest priority. Settings from a high priority set of settings could then override settings from lower priority set of settings.
Client status
Client status can report two things:
- Clients that are inactive, i.e. that haven’t reported data to SCCM recently. You can configure how many days count as “recently”.
- Clients whose client software isn’t working properly. Some problems can corrected automatically. The client runs the Client Health evaluator every night to check if everything is working correctly, and fix any problems if it can (e.g. starting a service that isn’t running)
Inventory and Software Metering
Hardware Inventory
Clients report information about their hardware and many other things to SCCM according to a configurable schedule. After each scan, the client reports the results to the management point. The management point sends the inventory to the site server, which loads it into the database.
The client does inventory in two ways:
- Full inventory: the first time a client inventories itself, it sends the entire inventory to the management point
- Delta inventory: for subsequent inventories, it compares the new inventory with the previous one and only sends the changes.
You can control how much information hardware inventory collects by:
- Modifying Configuration.mof (on the site server). For example, you can tell the Hardware Inventory Agent to look at specified parts of the registry
- Editing the hardware inventory classes in the client settings
Software Inventory
Software inventory consists of two parts:
- Software Inventory – clients report which software applications are installed
- File Collection – clients can collect copies of certain files to be sent to the management point, which sends them to the site server.
Software inventory reports that a product (eg Excel) is present if it finds one or more files that claim in their file headers that they are from that product. It’s not as reliable as Asset Intelligence, and so isn’t much used for Software Inventory now.
Both hardware and software inventory:
- can be forced to run at any time using the Control Panel Configuration Manager applet on the client.
- can be viewed using the Resource Explorer in the Admin Console (to see the results for a single client) or using queries or reports.
- can be monitored by viewing the InventoryAgent.log file on the client.
Asset Intelligence
Asset Intelligence gathers information from a number of sources. It allows reports to be run showing:
- more detailed hardware information than hardware inventory alone
- detailed information about the software installed on clients (this is a more reliable method of inventorying software than using the Software Inventory feature)
- information about licences on the clients for various products
Configuring Asset Intelligence includes:
- enabling hardware inventory, with special AI inventory classes enabled
- enabling software metering
- enabling the auditing of Logon Success events
- importing information into the database about licenses that have been purchased
- setting up an Asset Intelligence Synchronisation Point, to download the Asset Intelligence Catalog regularly
The Asset Intelligence Catalog can be downloaded from Microsoft, and contains information about thousands of commercial software applications, including their hardware requirements.
Software metering
Used to find out what has been executed on the clients.
Software metering rules define which executables the clients should monitor the use of.
According to a configurable schedule, the clients upload their software metering data to the management point, which sends it to the site server, which puts it into the database. The data is then summarized during the night (but only if the data has been in the database for at least 12 hours). The summarised data can then be viewed in reports.
Queries
A query allows you to search the database for objects meeting certain criteria. For example, “Show me all the computers that are running Windows 7” or “Show me all the computers that are running Windows 7 and have less than 4GB RAM”
Queries are saved as objects in the database, so they can be re-run. They are written in WQL, not SQL, but an administrator can create a query from the Console and it will construct the WQL statement.
There are two types of query:
Status message queries – search for status messages, and are run from the Monitoring/System Status/Status message queries node.
Data queries – search for other types of objects and are run from the Monitoring/Queries node. Nb Each data query can only search for objects of one type, e.g. computers or users, but not both.
Data queries – search for other types of objects and are run from the Monitoring/Queries node. Nb Each data query can only search for objects of one type, e.g. computers or users, but not both.
The property pages of a data query include:
General – defines which attributes you want included in the results set (i.e. the column headings)
Criteria – defines the criteria (conditions) that the query will use to select objects from the database.
General – defines which attributes you want included in the results set (i.e. the column headings)
Criteria – defines the criteria (conditions) that the query will use to select objects from the database.
A criterion can be one of several types:
Simple – compare the value of an attribute with a specified value
Prompted – compare the value of an attribute with a value that you supply when prompted as you run the query
Null value – test whether the attribute is null (has no value) or not null (has a value)
List of values – compare the value of an attribute with any one of a list of values
Attribute reference – compare the values of two attributes of each object
Sub-selected values – find objects that meet the conditions of another query that you paste into this criterion (or that don’t meet the conditions of the other query)
Simple – compare the value of an attribute with a specified value
Prompted – compare the value of an attribute with a value that you supply when prompted as you run the query
Null value – test whether the attribute is null (has no value) or not null (has a value)
List of values – compare the value of an attribute with any one of a list of values
Attribute reference – compare the values of two attributes of each object
Sub-selected values – find objects that meet the conditions of another query that you paste into this criterion (or that don’t meet the conditions of the other query)
If a query has more than one criterion, they can be combined using AND or OR operators. Criteria can be bracketed together. A criterion can have a NOT placed in front of it. The order in which criteria are evaluated is:
( )
AND
OR
NOT
( )
AND
OR
NOT
To create a query which is the opposite of another query, either:
1. Put a NOT in front of the existing criterion. For example, NOT [Physical memory > 4GB]. This only works if the attribute being tested can have only one value
2. Create a sub-selected values criterion, using the “Not in” operator and pasting in the existing query. For example, Find computers whose Name attribute is not in [Computers with office 2013 installed] query results. This method works if the attribute being tested can be multi-valued.
2. Create a sub-selected values criterion, using the “Not in” operator and pasting in the existing query. For example, Find computers whose Name attribute is not in [Computers with office 2013 installed] query results. This method works if the attribute being tested can be multi-valued.
When creating a query, instead of defining it from scratch you can import a query statement, i.e. import the definition of another query on which to base the new one. There will be no link between the new query and the one whose statement you originally imported, so editing the new query doesn’t affect the existing one.
A data query’s definition can be exported to a MOF file and imported into another hierarchy.
Reports
The reporting feature is based on SQL Server Reporting Services, a component of SQL Server.
A Reporting Services Point site system role must be created. This will need SQL Server Reporting Services installed on it. The Reporting Services Point can be on the site server, the site database server, or another server.
Several hundred reports are preconfigured, but new ones can be created. A report selects objects from the database using a SQL statement. Creating a Model-based report constructs the SQL statement automatically. Creating a SQL-based report requires the user to write the SQL statement.
Reports can be run from the console (Monitoring/Reports) or directly from a browser, by connecting to the URL of the reporting application on the RSP.
Several Reporting Services security roles can be used to control what a user can do with reports. Two roles are added by SCCM:
ConfigMgr Report Users can run reports and subscribe to them (users who have any of the SCCM security roles, except Remote Tools Operator, are given this permission on all reports by default).
ConfigMgr Report Administrators can create delete and modify reports.
ConfigMgr Report Users can run reports and subscribe to them (users who have any of the SCCM security roles, except Remote Tools Operator, are given this permission on all reports by default).
ConfigMgr Report Administrators can create delete and modify reports.
The results of a report can be exported into files of various formats, e.g XML, PDF, CSV, Word and Excel.
Users can subscribe to a report. The subscription can be set to run the report regularly, and either email the results to the user, or save them in a shared folder.
Software Distribution and Deployment by Using Packages and Programs
This is the old method for deploying software. It’s been retained in SCCM 2012, because it’s still useful for:
- deploying simple software
- deploying scripts that need to run on the clients, eg to change registry values
There are two phases to rolling out software to clients (and software updates, and operating systems)
- Distribution. The content (e.g. packages, applications, software updates, OS images) is copied to specified distribution points.
- Deployment. The software (either applications or programs), software updates or task sequence is deployed to a collection of computers or users.
The site’s software distribution component can be configured to control how software is distributed to DPs in the site. It’s also where you can configure a Network Access Account. Normally clients use their own computer account to connect to the distribution point to fetch content, but if they don’t have a computer account, they connect using one of the Network Access Accounts.
Software Deployment Objects
To deploy software using packages and programs, software deployment objects need to be created. These are:
- Package – the thing you’re going to deploy (e.g. a piece of software, or a script). The package will usually contain source files (e.g. of the software you’re deploying).
- Program – the executable that will run on the clients. It might be a setup program that will install the software in the package, or a script, or anything that will execute. A package must contain at least one program. It may contain several programs, each of which installs the software in a different way.
- Collection – a program is deployed to a collection (of users, or of computers).
- Deployment – the deployment of a program to a collection is itself an object in the database, and its properties define how the deployment should be handled by the client, e.g. whether it’s required (mandatory) or available (optional).
A package definition file might be provided with the software – this can be used to create a package in SCCM, and it automatically creates one or more programs.
Once the package and programs are created, you must distribute the content (the package) onto one or more distribution points in the site or its child sites.
Then deploy the program in the package to a collection. The deployment can be:
- Required – the client must run the deployed program, either as soon as possible, or at the time that you schedule.
- Available – the user is notified that the deployment is available, and can then choose to run it.
The deployment will be added to the machine policy of each computer in the target collection (or to the user policy of each user if it’s a user collection). The client downloads the machine policy of the computer and the user policy of the user who’s logged on, and either runs the deployed program as specified or waits for the user to choose to run it.
Managing content on distribution points
This applies to software, both packages and applications, and also to software updates and operating system images.
A distribution point can be running any operating system from Windows Vista or Windows Server 2003 onwards.
Content is stored on the distribution points in the Content Library (under the SCCMContentLib folder).
For distribution points at small branch offices with limited network bandwidth from the main office, the following features may be useful:
- Scheduling and bandwidth throttling – a DP at the branch office can be configured so that content is only sent to it at certain times, and doesn’t use all of the available network bandwidth.
- Pre-staging – a DP at the branch office can be configured for pre-staging. Certain content can then be configured so that it isn’t sent over the network to the DP, leaving the administrator to copy it from the site server and send it to the office where the DP is located (e.g. by courier). The package is then copied to the DP and imported into the content library.
- BranchCache – clients at a remote office with no DP can be configured to use BranchCache. When one of them fetches content from a DP in the main office, it caches it, and when other clients on the same subnet request the same content, the first client sends it to them from its cache. BranchCache must be configured on the clients for distributed mode (SCCM doesn’t support hosted mode).
Creating and Deploying Applications
Applications and deployment types
Applications are a more powerful and flexible way of deploying software than packages and programs.
An application contains one or more deployment types.
A deployment type is a ‘version’ of the software.
(For example, an Office application might contain a deployment type to install the Windows Installer version on a client, and another deployment type to ‘install’ the App-V (virtual) version of Office on the client.)
The entire application is deployed to a collection of clients. Each client decides which deployment type in the application to install, depending on whether it satisfies the requirements set on the deployment types.
(For example, the requirement on the Windows Installer deployment type might be that this must be the user’s primary computer. If so, the Windows Installer deployment type is installed. If this isn’t the user’s primary computer, the App-V deployment type would be installed.)
Only one of the deployment types in the application is installed – the one with the highest priority whose requirements the client meets.
A deployment type can be configured with:
- Requirements – the client must meet the requirements to be allowed to install the deployment type (e.g.”Is there more than 4GB physical memory?”)
- Detection Methods – to detect whether this deployment type is already installed on the client. A detection method could look for the presence or absence of certain files or folders, the presence or absence of certain registry keys or values, or check if the product code is listed in the client’s Windows Installer database.
- Dependencies – other deployment types (perhaps in other applications) that must be present on the client for this deployment to install. If they aren’t, they can be installed before this deployment type is installed.
Global conditions vs Requirements
A requirement is a property of a deployment type. It’s based on a global condition. A global condition names something that a requirement will then test.
For example:
- Global Condition = “Total physical memory”
- Requirement = “Is Total physical memory > 4GB?”
New global conditions can be created in the Admin Console in Software Library / Application Management / Global Conditions. They can then be used by requirements on any deployment type in any application.
User device affinity
If an affinity is set up between a user and a computer, it means that:
- the user is the primary user of that computer
- the computer is the user’s primary computer
A user can have affinity with several devices. A device can have affinity with several users.
User device affinity can be used in the requirements of a deployment type.
(For example, an application could be set up so that the Windows Installer deployment type installs if the user is at their primary computer, but the App-V deployment type ‘installs’ if the user is not at their primary computer.)
User device affinity can be set up as follows:
- Manually by the administrator in the Admin Console (right click a device or a user, and choose ‘Edit primary users’ or ‘Edit primary devices’)
- By importing a list of computers and users from a .CSV file
- Based on usage data, e.g. if a user is logged on at a computer for more than 200 minutes in 7 days, an affinity can be set up, either automatically or with the approval of an administrator
- By the user, in the Application Catalog Website
Deployments
The entire application is deployed to a user collection or a device collection.
The deployment action can be:
- Install – the client will run the install program configured on the deployment type
- Uninstall – the client will run the uninstall program configured on the deployment type.
The deployment purpose can be:
- Required – the relevant deployment type is installed at the configured deadline
- Available – the user chooses if/when to install it
The Application Catalog website
Optional. If set up, it allows users to view software that’s been deployed to them as available and install it.
Two new site system roles must be installed:
- Application Catalog website point – the client connects to this
- Application Catalog web service point – the Application Catalog website point connects to this
Software Center vs Application Catalog website
The user can see and install software that’s been deployed to the client using either the Software Center (a program installed on all clients), or the Application Catalog (a website that must be installed by the administrator).
Not all deployments are visible in these two tools.
The Software Center shows:
- Deployments to the computer that are Available.
- Deployments to the user that are Required, but where the deadline is still in the future.
The Application Catalog shows:
- Deployments to the user that are Available.
Requesting software
When an administrator deploys an application as available to a user collection, s/he can require the user to request permission to install it. The user does this in the Application Catalog website, and the administrator approves it in the Admin Console.
Retiring an application
This means:
- The application’s properties can’t be modified
- The application can’t be deployed (although existing deployments will still work – to stop this, delete the deployments)
An application can be reinstated (unretired).
Supersedence
An application can be configured to supersede another application. The deployment types in the new application are configured to update equivalent deployment types in the old application. The old deployment type could be uninstalled, or upgraded.
Windows Store Apps
These can be deployed in two ways:
1. Deploying a link to the app in the Windows Store
The app is installed from the Windows Store onto a Windows 8 reference device. A ConfigMgr application is then created which extracts from the reference device a link to the app in the Store. It is the link that is deployed to the client devices. Requirements include:
- The reference device must be set to allow the console remote access to it
- The user creating the application must have administrative rights on the reference device
2. Sideloading
This involves deploying an app (possibly developed in-house and packaged using Visual Studio) as a Windows App (.appx) deployment type in a ConfigMgr application. Requirements include:
- The app must be digitally signed
- The app must meet certain technical standards
- The windows 8 devices must be enabled for sideloading – this can be done with a GPO
Virtual applications
Virtual applications based on Microsoft’s App-V environment can be deployed to ConfigMgr clients.
A virtual application does not install on the client. When it’s deployed to the client, the client merely registers it with the App-V client (which must be installed on the ConfigMgr client) and sets up a shortcut to it. When the user runs it, the application’s files are downloaded and it runs in an isolated environment, although it has access to system resources.
A deployment of a virtual application can set the application to run in one of two ways:
- Streaming delivery – when the user runs the application, the App-V client streams its files from a distribution point into its cache and runs it from there.
- Local delivery (or Download and execute) – when the client receives the deployment of the application, the ConfigMgr client downloads the files from a distribution point into its own cache. When the user runs it, the files are streamed from the ConfigMgr client’s cache into the App-V client’s cache and then executed.
To deploy a virtual application:
- Sequence the application, i.e. prepare it for virtualisation using Microsoft’s App-V sequencer tool. This produces a manifest file (.XML for App-V v4 applications, or .APPV for App-V v5 applications)
- Create an application with a deployment type of the correct type (App-V v4 or App-V v5)
- Optionally, create virtual environments, which allow specified applications to run together in a shared virtual environment.
- Distribute the application
- Deploy the application
On the client, the Virtual Application Management Console allows the user to manage various aspects of virtual applications, including updating and repairing them.
Overview
This feature uses a server with WSUS installed, but SCCM controls it – the SCCM administrator doesn’t configure WSUS directly. SCCM controls the WSUS server.
There are three phases in the process of managing software updates for SCCM clients.
- On a schedule set in the SCCM Admin Console, the site server connects to the Software Update Point and tells it to download the list of available updates from the Microsoft Update site (the “software updates metadata”). WSUS on the SUP fetches the list and sends it to the site server, which puts it into the SCCM database.
- On a schedule set in Client Settings, each client fetches the list of available updates from the SUP, scans itself against the list, and then reports to the management point which updates it needs. The SCCM administrator can see the results of these scans in the console, or by running reports.
- The SCCM administrator decides which updates to deploy. The source files for the chosen updates are downloaded from Microsoft Update, put into a package and distributed onto the DPs. The updates are then deployed to a collection of clients.
Prerequisites
- WSUS must be installed on a server that is then given the Software Update Point role. WSUS will fetch the list of available updates from Microsoft, but won’t download the updates themselves. The updates will not be approved by the administrator using WSUS – they will be chosen and deployed through the SCCM Admin Console.
- The clients must have Windows Update Agent installed. This will fetch the list of available updates from the SUP/WSUS server. Don’t configure the clients with the name of the WSUS server using group policy – SCCM will tell them where it is via their machine policy.
Software update groups
A set of software updates can be put into a software update group. These groups are optional, but are useful for three reasons:
- Reporting – many reports report on all the updates in a group.
- Distributing and deploying – to distribute and deploy a set of software updates, it’s easier to put them into a group and then distribute and deploy the entire group.
- Delegation – an administrator can choose which updates need to be deployed, put them into a group, and then delegate the job of deploying them to someone else.
Creating and distributing software update packages
The Download Software Updates wizard is run against one or more software updates. It fetches the source files for the updates, puts them into a package, and copies the package to the specified distribution points.
It can either fetch the updates from Microsoft Update, or if you’ve already downloaded the updates (e.g. for testing), you can put them in a shared folder and let the wizard get them from there.
Deploying software updates
The Deploy Software Updates wizard deploys the chosen updates to a collection as either Required or Available.
On the last page of the wizard, you can choose to save some or all of the settings you entered as a deployment template. The next time you deploy updates to the same collection, you can choose the deployment template as you start the wizard – it’ll save you having enter the same details all over again.
Automatic deployment rules
To automate the process of choosing, distributing and deploying updates, create and schedule an automatic deployment rule.
Each time the rule runs, it will look for new updates that meet conditions that you specify, e.g. all critical updates. It will fetch the updates, put them into a package, and distribute the package to specified DPs. Optionally, it can also deploy the updates to a specified collection.
No comments:
Post a Comment