Config Manager Blog

So now what we've completed setup for WSUS, now we can move forward with configuring the SUP in CM12.
Note:  This is a lab with a single site server.

In the ConfigMgr console, navigate to Administration, Site Configuration click on Servers and Site Systems Roles.  Right click on the server and choose Add Site System Role.


Just click next to begin to configure the role.


Select the Software Update Point and then Next.


If you are using a proxy, you can enter that information here.  Since I am running this in a lab environment, I'll leave the default and continue.


Next you want to check the box Use this server as the active software update point, obviously ;-)


I took default settings here.


Check the boxes Enable Synchronization on a schedule and Alert when synchronization fails on any site in the hierarchy.  I decided to check these so my lab automatically syncs every week and I don't have to think about it.


Select the proper options for your environment.


I removed selections for older systems as I only use W7 clients in my lab. 


Trust me, I did select English here but I got trigger happy with the print screen.


Green check marks are always good!


To check on the sync progress, you can view the wsyncmgr.log file.

Below are the steps for basic configuration of the WSUS role in Server 2008 R2.

First thing I did was create a share that will hold the updates data.  I set the share permissions to Everyone Read.


Next step is to install the WSUS role on my CM12 site server.
Note:  This is a test lab with a single site server.


Take the default settings here and continue with install.


Now proceed to configure WSUS.


Specify the share that was created for storing updates.


Continue with default settings.















When you see this screen, cancel the wizard.  Why?  Because we will handle all updates with the SUP role in CM12.



That's it you're done, well not really, but done with WSUS at this point.  Next post will cover the configuration of the SUP role on the site server.

Taken from Technet:

The following items are new or have changed for desired configuration management (now compliance settings) since Configuration Manager 2007:

• Configuration Manager 2007 desired configuration management is now called compliance settings in System Center 2012 Configuration Manager.
• Configuration Manager provides a new built-in security role named Compliance Settings Manager. Administrative users who are members of this role can manage and deploy configuration items and configuration baselines and view compliance results.
• An administrative user can create registry and file system settings by browsing to an existing file, folder, or registry setting on the local or a remote reference computer.
• It is now easier to create configuration baselines.
• You can reuse settings for multiple configuration items.
• You can remediate noncompliant settings for WMI, the registry, scripts, and all settings for the mobile devices that are enrolled by Configuration Manager.
• When you deploy a configuration baseline, you can specify a compliance threshold for the deployment. If the compliance is below the specified threshold after a specified date and time, System Center 2012 Configuration Manager generates an alert to notify the administrator.
• You can use the new monitoring features of System Center 2012 Configuration Manager to monitor compliance settings and to view the most common causes of noncompliance, errors, and the number of users and devices that are affected.
• You can deploy configuration baselines to users and devices.
• Configuration baseline deployments and evaluation support Configuration Manager maintenance windows.
• You can use compliance settings to manage the mobile devices that you enroll with Configuration Manager.
• Configuration item versioning lets you view and use previous versions of configuration items. You can restore or delete previous versions of configuration items and see the user names of administrative users who made changes.
• Configuration items can contain user and device settings. User settings are evaluated when the user is logged on. Examples of user settings include registry settings that are stored in HKEY CURRENT USER and user-based script settings that an administrative user configured.
• Improved reports contain rule details, remediation information, and troubleshooting information.
• You can now detect and report conflicting compliance rules.
• Unlike Configuration Manager 2007, System Center 2012 Configuration Manager does not support uninterpreted configuration items. An uninterpreted configuration item is a configuration item that is imported into compliance settings, but the Configuration Manager console cannot interpret it. Consequently you cannot view or edit the configuration item properties in the console. Before you import Configuration Packs or configuration baselines to System Center 2012 Configuration Manager, you must remove uninterpreted configuration items in Configuration Manager 2007.
• You can migrate configuration items and configuration baselines from Configuration Manager 2007 to System Center 2012 Configuration Manager. During migration, configuration data is automatically converted into the new format.
• Settings groups from Configuration Manager 2007 are no longer supported in System Center 2012 Configuration Manager.
• Regular expressions for settings are not supported in System Center 2012 Configuration Manager.
• Using wildcards for registry settings is not supported in System Center 2012 Configuration Manager. If you migrate configuration data from Configuration Manager 2007, you must remove wildcards from registry settings before you migrate otherwise the data will be invalid in the System Center 2012 Configuration Manager configuration item.
• The string operators Matches and Do not Match are not supported in System Center 2012 Configuration Manager.
• You can no longer create configuration items of the type General from the Configuration Manager console. You can now create only application configuration items and operating system configuration items. However, if you create a configuration item for a mobile device, this is created as a general configuration item.

Not an option in CM12.  Instead, MS states in their documentation that you can copy to the windows clipboard as a workaround.  I haven't personally tried this but figured I'd post it as an FYI.

Many people including myself, have historically used SCCM as the name for Configuration Manager, or ConfigMgr.  In my opinion, Microsoft is partly to blame.  In any case, just wanted to make the point that SCCM is not a Microsoft product.  I've included the link to what SCCM is, see for yourself.

the real SCCM

With the release of System Center 2012 Configuration Manager, I know that's a mouthful, I've stopped calling it SCCM but using CM12 or ConfigMgr instead.

If you're coming from CM07 and CM12 is new to you, you'll notice that certain site roles have been removed.  No need to panic, doesn't mean that functionality was removed.  Below is what has been removed for CM12:

• PXE service point.  This is now part of a distribution point.
• Reporting point.  Reporting services point is used with SRS.
• Server locator point.  This is now part of the management point.  That means no more "SMSSLP=" in the client install properties.
• Branch distribution point.  A standard distribution point supports workstations or servers that are members of a domain.  The functionality of the branch distribution point is now a BranchCache setting for an application deployment type and the package deployment.

New site roles in CM12:

• Application Catalog website point and Application Catalog web services point.  Both of these roles require IIS and support Software Center which is a new app on the client side.
• Enrollment proxy point.  Manages enrollment requests for mobile devices.  This role also requires IIS.

You can no longer use NLB for management points, not supported.  CM12 will perform this functionality automatically when multiple management points exist in the site.

The idea of a "default" management  point at a primary site is no more.  You can now install multiple management points and clients will automatically select one.  This functionality allows CM12 to scale and support more clients in a single site and also provides redundancy.  Prior to CM12, you'd need to use a NLB cluster for the MPs to obtain redundancy.  Again, this is no longer supported in CM12.

There are more changes but this is what I was able to note down at MMS.  I will update this post as needed.

Site	Purpose	Change from Configuration Manager 2007
Central administration site	The central administration site coordinates intersite data replication across the hierarchy by using Configuration Manager database replication. It also enables the administration of hierarchy-wide configurations for client agents, discovery, and other operations. Use this site for all administration and reporting for the hierarchy.	Although this is the site at the top of the hierarchy in System Center 2012 Configuration Manager, it has the following differences from a central site in Configuration Manager 2007: Does not process data submitted by clients, except for the Heartbeat Discovery discovery data record. Does not accept client assignments. Does not support all site system roles. Participates in database replication
Primary site	Manages clients in well-connected networks.	Primary sites in System Center 2012 Configuration Manager have the following differences from primary sites in Configuration Manager 2007: Additional primary sites allow the hierarchy to support more clients. Cannot be tiered below other primary sites. No longer used as a boundary for client agent settings or security. Participates in database replication.
Secondary site	Controls content distribution for clients in remote locations across links that have limited network bandwidth.	Secondary sites in System Center 2012 Configuration Manager have the following differences from secondary sites in Configuration Manager 2007: SQL Server is required and SQL Server Express will be installed during site installation if required. A management point and distribution point are automatically deployed during the site installation. Secondary sites can send content distribution to other secondary sites. Participates in database replication.