Mastering System Center 2012 R2 Configuration Manager (2014)
Chapter 4. Installation and Site Role Configuration
Previous chapters have already begun pulling back the covers on the changes in Configuration Manager 2012 R2. This chapter is focused on discussing Configuration Manager 2012 R2 sites, hierarchies, and site system roles and provides a walkthrough of building a sample hierarchy.
A major design pillar for Configuration Manager 2012 R2 was hierarchy simplification. In previous versions of Configuration Manager it was not uncommon to find hierarchies with dozens of sites and, in some cases, thousands of sites, and often hierarchies would be built four to five or more layers deep. Both the number of sites in a hierarchy and the depth of the hierarchy bring with them configuration complexity, potential delays, and sometimes errors when transmitting data from the top level of the hierarchy to the bottom tier sites.
Configuration Manager 2012 R2 changes potential hierarchy design significantly in a few ways. Because of the numerous changes and efficiencies—not the least of which is enhancements in the security model—in many cases, organizations with fewer than 100,000 client systems won’t need to implement a hierarchy at all. A single site server and its associated “helper” servers will be all that is necessary to provide a robust Configuration Manager 2012 R2 experience.
A hierarchy will be required by organizations that manage more than 100,000 clients or have other nontechnical reasons that require a hierarchy to be implemented, such as legal or political requirements. In those cases, the efficiencies gained in Configuration Manager 2012 R2 should often result in far fewer numbers of installed sites and, as a result, a simpler hierarchy.
A couple of interesting facts about hierarchy changes in Configuration Manager 2012 R2 will serve to whet your appetite for what is to come. A Configuration Manager 2012 R2 hierarchy supports only a single tier of primary sites. A tier of secondary sites may be added if absolutely necessary, but in most cases, as detailed in the chapter, there is no reason for secondary sites any longer.
In this chapter, you will learn to
· Understand Configuration Manager 2012 R2 sites and the new approach to hierarchy design
· Construct a Configuration Manager 2012 R2 hierarchy
· Determine when to expand a hierarchy and when to simply add a site system role for additional service
· Deploy and configure the various site system roles available per site
Understanding Configuration Manager 2012 R2 Site Types
It doesn’t take long when working with any of the versions of Systems Management Server or Configuration Manager to be introduced to the concept of a site server. Site servers exist to provide service to Configuration Manager clients. Site servers understand which clients they should serve by defining management boundaries, which may be AD sites, IP subnets, or IP address ranges. Depending on the size and organization of the Configuration Manager environment, there may be a need to have more than a single site to manage all of the clients in the enterprise. When more than one site is needed, it is common to establish a site hierarchy, which will facilitate centralized management of all Configuration Manager clients.
A specific design goal of Configuration Manager 2012 R2 is to reduce the number of sites that are needed in a hierarchy and also to reduce complexity. Further discussion of this will come shortly.
Site servers historically have fallen into one of two categories, either a primary site server or a secondary site server, and now a third type is part of Configuration Manager 2012 R2, the Central Administration Site (CAS).
1. Primary Site Server A primary site server has historically been identified as having a few characteristics:
· It has its own database hosted on SQL Server to maintain configurations.
· It is the only site type where clients can be directly assigned.
· It has the ability to host child sites—either other primary sites or secondary sites.
2. Both the first and last characteristics are no longer items that distinguish a primary site. In Configuration Manager 2012 R2 primary site servers do still have their own copy of SQL running, but secondary sites do as well. Further, a primary site can have child sites, but those child sites can only be secondary sites. Introduced in Configuration Manager 2012 R2 is the fact that only primary sites can be assigned to the Central Administration Site—secondaries need not apply!
3. Secondary Site Server A secondary site server has historically been identified by a few characteristics:
· It does not make use of a SQL database.
· There is no way to directly administer a secondary site; all administration would have to come from an administration console connected to a primary site somewhere above the secondary.
4. The former condition is no longer true—secondary sites now do have a database. When installing a secondary site, you have a choice of either using an existing instance of SQL or, if SQL is not present on the target server, installing and using SQL Express. The latter observation remains true—secondary sites cannot be administered directly through the console.
5. Also, the historical justification for secondary sites has primarily been to provide local content access for clients residing in or roaming into its defined boundaries and to help control network traffic for content moving between the secondary site and its assigned parent primary site. Secondary sites are still used for that purpose today (although the argument is far less compelling).
6. So, secondary sites still are available in Configuration Manager 2012 R2, but before you plan to install one, check out the various bandwidth-control features of Configuration Manager 2012 R2. One key addition is that it is now possible to control, or throttle, network bandwidth between a site and its remote distribution points within the site. This one addition in Configuration Manager 2012 R2 makes it at least worth considering whether secondary sites really are necessary. If secondary sites were in use in an environment for the sole purpose of controlling network bandwidth for content distribution (some content is huge), then the ability to throttle content delivery between a site and a remote distribution point introduced in Configuration Manager 2012 R2 will be of interest. We’ll cover this shortly.
7. Other reasons for having a secondary site include the ability to throttle non-content site-to-site communications. This is a much reduced data size compared to content, but if throttling is still of concern to you, then a secondary site may be justified. (In previous versions of Configuration Manager this content would be files that contained status information, site configuration information, client information, and so on. In Configuration Manager 2012 R2 this content is still transferred between sites but is split between traditional file-based transfer and SQL replication.)
8. When it comes to secondary sites—or any other site type for that matter—think before following the same old pattern for a hierarchy. Configuration Manager 2012 R2 is about hierarchy simplification after all and really does a nice job of increasing site efficiency!
9. Central Administration Site Another type of site that has been around in previous versions of ConfigMgr is the central site server. A central site server is the one at the top of a hierarchy and is used to centrally administer the entire Configuration Manager implementation. Because of its role in hierarchy-wide management, a central site typically should not have clients directly assigned (although it is possible). Further, because all information in the hierarchy resides at the central site, this is typically the key site in the hierarchy where reporting is configured.
10.The central site server is no longer present in Configuration Manager 2012 R2. It has been replaced by a new type of site server known as a Central Administration Site (CAS). The CAS is much like the central site server except that it cannot have any clients assigned (not even an option), some site functions are not available at the CAS (such as most of the discovery options), and the CAS must be installed as the first site of the hierarchy. However, if you decide not to install the CAS until your organization has reached a desired limit of clients, you can expand your stand-alone primary site into a CAS only one time.
As we mentioned, sites manage clients. To facilitate client management and depending on the services being delivered, several different functional roles must be in place at the site. These functional roles are either added to the site server itself or configured on external servers. Either way, the servers that host these support roles are known as site systems. The option for distributed site servers to fulfill various functions allows for very flexible and scalable designs. Ultimately, the decision on where to place these site systems or whether to use external site systems at all is up to the administrator. And, if these roles need to be moved to other servers after installation, or other servers need to be added, that is easy to do. This work is performed in the Administration workspace, under Site Configuration of the Configuration Manager console, as shown in Figure 4.1.
Figure 4.1 The Administration workspace within the Configuration Manager 2012 R2 console
Hierarchy Design and Implementation
Now that we’ve discussed the types of sites available in Configuration Manager 2012 R2, it’s natural to begin thinking about implementation details. Hopefully it is clear that Configuration Manager 2012 R2 introduces significant changes in terms of site and hierarchy design. Administrators who have experience with previous versions of Configuration Manager might be tempted to set up Configuration Manager 2012 R2 in the same design that is currently being used. That approach might work, but it would be a mistake and would likely mask many of the features for simplified management that are available in Configuration Manager 2012 R2.
One of the major design pillars for Configuration Manager 2012 R2 was hierarchy simplification. With that in mind, during the design phase remember that each primary site is capable of supporting 100,000 client systems, and the hierarchy as a whole is able to support 400,000 clients. This means that for many organizations the total Configuration Manager 2012 R2 design might be handled with only a single primary site along with additional servers to support various roles in the environment. It’s interesting to note that even in Configuration Manager 2007 a primary site was also able to support 100,000 clients. That type of scale often was not realized because of the need for additional sites for political or load reasons. The design of Configuration Manager 2012 R2 removes virtually all technical reasons for adding additional site servers unless the addition is driven by scale.
Implementing Site Servers
The terms site and site server are often used interchangeably. In reality this shouldn’t be the case. A Configuration Manager 2012 R2 site encompasses all servers that are used to deliver the services offered by the site. Said another way, a Configuration Manager 2012 R2 site can consist of one to several servers. The size of the site will dictate how many servers are needed to deliver service to clients. In smaller environments it may be that only a single server is needed to host all components needed to deliver the site’s services. In larger environments multiple servers may be needed. With the new design of Configuration Manager 2012 R2 the expectation is that the number of total sites needed for an environment will decrease, but the number of supporting servers for a site might increase.
A site server is the one server in a site that orchestrates delivery of service to clients. This server will interact with any other servers that are in place supporting the site’s ability to deliver services. These additional servers are known as site systems. (A site server is also a site system.)
As services are added to a site and assigned to a server, the list of site system roles will increase. A quick glance at the Configuration Manager console will reveal the site systems that are in use to support a site and also what services those site systems are delivering on behalf of the site. An example is shown in Figure 4.2. Note that two systems are shown related to site code PRI. One is the site server itself and the other is a site system server providing service for the site.
Figure 4.2 Site systems and roles
Software Requirements
Before further discussing Configuration Manager 2012 R2 it is beneficial to install the software. There are a few prerequisites for installing a site server. For a full list of these prerequisites, go to
http://technet.microsoft.com/en-us/library/gg682077.aspx
These prerequisites may also apply to site systems that may be installed, depending on the services, those servers will offer:
· All site servers must be members of a Windows Active Directory domain (Windows Server 2003 functional level or above if using the discovery filter for stale computer records).
· The site servers must be deployed on 64-bit hardware. Configuration Manager 2012 R2 is a native 64-bit application, and there is no version that can be installed on 32-bit systems. (32-bit systems are supported as Configuration Manager clients and some site systems.)
· .NET Framework 3.5 SP1 and 4.0 must be installed.
· Microsoft XML Core Services 6.0 or greater must be installed.
· Microsoft Remote Differential Compression must be installed.
· SQL Server 2008, 2008 R2, or 2012 is required to host the ConfigMgr database.
And don’t worry; if a required configuration happens to be missed along the way, the Configuration Manager 2012 R2 prerequisite checker, which runs as part of the install wizard, will let you know. The details of the checks that are performed during prerequisite validation are recorded in the ConfigMgrPrereq.log, located in the root of the C: drive of the server where Configuration Manager 2012 R2 is being installed. If it would be helpful to run the prerequisite checker outside of the Configuration Manager 2012 R2 setup wizard, it is available as a separate executable located in the \SMSSETUP\BIN\X64 folder of the installation media. The filename is PREREQCHK.EXE. The following list documents the prerequisite checks that are done as part of the install or as part of independently running the Prerequisite Wizard. The list of prerequisite checks is detailed for the Central Administration Site. Any additional checks performed are detailed for other site types.
Central Administration Site
· Confirm targeted server is a Windows server.
· Confirm operating system is a supported version.
· Verify targeted server is a domain member.
· Check to ensure schema extension has been completed and is correct.
· Confirm disk space is sufficient for installation.
· Confirm disk size for installation.
· Verify MSXML 6.0 is installed.
· Verify Remote Differential Compression is installed.
· Confirm the correct version of MSI is installed.
· Confirm .NET Framework Version 3.5 is installed.
· Verify SQL SysAdmin rights are configured.
· Verify site server computer account has administrative rights.
· Confirm SQL Server security mode.
· Verify SQL Agent logon.
· Confirm version of SQL Server is as required.
· Verify firewall settings for SQL Server access.
· Confirm SQL Server is configured as not case sensitive.
· Verify connectivity to SQL Server.
· Confirm WIM filter driver is installed.
· Verify sufficient disk space for installing the Windows Automated Installation Kit.
· Confirm ConfigMgr is not already installed.
· Verify sufficient disk space for SDK server.
Primary Site
· Confirm the user installing the primary site has administrative rights on site system and CAS (if applicable).
· Verify connectivity to CAS (if applicable).
· Confirm disk is not formatted with FAT partition.
· Check to see if WSUS is installed on the site server and, if so, whether it is of the proper version.
· Verify Windows Server 2003 SChannel hotfix is installed.
· Verify Windows Remote Management 1.1 is installed.
· Confirm MMC updates are installed.
· Confirm .NET update for Configuration Manager is installed.
· Verify PowerShell 2.0 is installed on the site server.
Some prerequisite checks may trigger a warning, but if they aren’t critical for a successful site installation, the installation process is allowed to proceed.
Implementing a Central Administration Site
Installing Configuration Manager 2012 R2 begins by installing the first site. A very important question should be answered before launching the Setup Wizard: Is it expected that more than a single primary site will need to be included in the deployment? If the answer is yes, then the very first site that needs to be installed is the Central Administration Site. The CAS is the top site in the hierarchy and is used solely for administration of the entire hierarchy. No clients or client-related functions are possible at the CAS. This is critical to understand. If there is any expectation of joining multiple primary sites in a hierarchy relationship, then the CAS must be the first server installed. If it’s not installed, then you should plan to expand the stand-alone site to a CAS at a later time.
For those of you who have worked with previous versions of Configuration Manager, your initial reaction may be that multiple sites are needed because they were needed in the current implementation (whatever version that is) of Configuration Manager. Not so fast! Remember that one of the design goals of Configuration Manager 2012 R2 is hierarchy simplification. A Configuration Manager 2012 R2 site is more efficient in many ways, not the least of which is the ability to throttle traffic to remote distribution points (thus often eliminating the need for secondary sites). This one tweak by itself will go a long way to reducing the number of sites. Further, a single site has been able to scale to support 100,000 clients for some time now. Often, this kind of scale for a single site was not realized because of the need for additional sites due to network conditions, security considerations, and the like. With Configuration Manager 2012 R2 and hierarchy simplification along with other improvements, expect to see primaries carrying much more of a client load than might have been seen in previous versions.
For the examples given here, installation will proceed assuming a three-site hierarchy is to be built. The hierarchy will consist of a single CAS, a single primary site, and a single secondary site.
With the decision made as to how many sites are needed for the hierarchy, the first site to be installed is the CAS. Before starting the Setup Wizard, make sure SQL is installed and available. Also, install the Windows Assessment and Deployment Kit for Windows 8.1 first (it’s required).
Choosing Local or Remote Installation
A SQL Server installation can be either local or remote. Arguments rage about the best approach. This argument is helped in Configuration Manager 2012 R2 by some support boundaries. A single primary site server on appropriate hardware is able to support 100,000 clients, but if SQL is collocated with the ConfigMgr application, that same primary site server is supported for only up to 50,000 clients. This is mostly due to the load that SQL replication introduces. Still, while the performance differences between a remote versus local SQL server when properly configured are slight, if a site will host fewer than 50,000 clients, using collocated SQL is still preferred and is considered most efficient. One reason for this is that when SQL is running on the same system, it is possible to take advantage of the shared memory protocol. One consideration for local SQL, however, is the default memory settings. SQL by default is configured to consume all available RAM. This is a good configuration for standalone SQL because RAM is more efficient than disk memory.
When sharing a server, setting a maximum amount of RAM for SQL consumption and thereby reserving the rest for Configuration Manager, the operating system, and other applications such as virus scanners is an optimal configuration. SQL does a very good job of managing RAM and not over-consuming and starving other applications, but there is a cost, however slight, because SQL pages information out of RAM to make room for the needs of other applications. Setting a maximum from the beginning avoids this problem, and with the amount of RAM available on servers today, there really shouldn’t be an issue with specifying a maximum RAM value for SQL.
Finally, it’s time for installation! The installation process is wizard driven and does a good job of keeping you on track. The most difficult part of the installation is knowing what options to choose. The example will explain how to configure the various options and what they mean. Let’s get started:
1. Insert the installation media, and autorun should cause the initial installation screen to be displayed.
If this is not the case, or if you’re running from a location other than the supplied media, simply double-click the splash.hta file, which will display the initial installation screen.
The splash screen provides options for accessing various documentation and assistance, even links to the Configuration Manager community. There are also links to access server readiness components and links to download Configuration Manager updates that are required during the installation process. These latter links are really nice additions to Configuration Manager 2012 R2, providing a very easy way to download updates and move them to a server that is being installed that may not have Internet access to download the updates during setup. Other links include options to just install the Configuration Manager 2012 R2 console and to download System Center Updates Publisher—a tool that anyone using software updates should take a look at! Clicking the Install link at the top left of the screen launches the Setup Wizard and opens the Setup Wizard Welcome page.
2. Review the information on the Before You Begin page, and click Next to continue to the Getting Started page.
On the Getting Started page the various install options are presented. The options available here will be based on the state of the system where the install is being run. If a system already has Configuration Manager 2012 R2 installed, only the options to uninstall or perform a site reset may be available. If you’re running the wizard on a system without Configuration Manager 2012 R2, the options will be as shown in Figure 4.3.
Figure 4.3 Setup Wizard: Getting Started page, when installing on a system without ConfigMgr
This is the point in the wizard where the decision you made earlier is configured—whether to install a stand-alone primary site or to install a Central Administration Site. This installation will be for a Central Administration Site.
3. With that option selected, click Next to continue to the Product Key page. Decide whether to install as an evaluation or to supply a product key. Once you’ve entered the key, click Next to continue to the Microsoft Software License Terms page.
4. On the Microsoft Software License Terms page, review the information. If you agree, select I Accept These License Terms and click Next to proceed to the Prerequisite Licenses page.
5. On the Prerequisite Licenses page, review the information. This page requires you to accept the license terms for SQL Server 2012 Express, SQL Server 2012 Native Client, and Microsoft Silverlight 5. If you agree, select the appropriate box to accept the terms for each, and click Next to proceed to the Prerequisite Downloads page, shown in Figure 4.4.
Figure 4.4 Setup Wizard: Prerequisite Downloads page
6. On the Prerequisite Downloads page, decide whether to download the updates or, if the updates have been previously downloaded—either from another site installation or using the link on the initial splash page—select the second option.
In both cases, a path for the updates should be specified. For the example, the updates have been previously downloaded and will be installed from the path shown.
7. Once you’ve completed this screen, click Next, which, depending on the selection made, will initiate the update download process or update evaluation. Once this step is complete, the wizard moves on to the Server Language Selection page.
When migrating from a previous version of Configuration Manager to Configuration Manager 2012 R2, it might be useful to have both consoles installed on a system. Doing so is fully supported.
8. Choose the languages you want to support. The default is English. Once you’ve completed this screen, click Next to go to the Client Language Selection page. On the Client Language Selection page configure additional languages that should be supported from a client perspective. The default here is English. Once you’ve done this, click Next to proceed to the Site and Installation Settings page, shown in Figure 4.5.
Figure 4.5 Setup Wizard: Site and Installation Settings page
On the Site and Installation Settings page several options are available. The first required option is the Site Code field. The site code can be any three-character alphanumeric code but cannot contain any special character such as a dash or ampersand. In fact, to ensure no mistake is made here, the wizard won’t even accept special characters for the site code. Next is the Site Name field. Choose a descriptive name and enter it into this box. Finally, input the installation path where ConfigMgr should be installed.
Setting the correct path is a critical part of installing Configuration Manager 2012 R2. The default path is on the C: drive, and for the example, we will use the E: drive for best practice.
Selecting a Disk for Installation
In production environments it is not recommended to install Configuration Manager on a disk shared by other disk-intensive applications, including the operating system, SQL databases, or the page file. Doing so may degrade Configuration Manager performance.
The last option is a choice of whether to include the Configuration Manager 2012 R2 console as part of the installation. This option is commonly used and is checked by default. If you don’t want this option, remove the check mark. If you need the administrative console at a later time, you can easily add it.
9. Click Next to proceed to the Database Information page, as shown in Figure 4.6.
Figure 4.6 Setup Wizard: Database Information page
10.On the Database Information page configure the SQL Server information.
For the example, SQL is installed on the same server where the Setup Wizard is being run, so the default location that shows up for SQL Server is the local server. If you’re installing SQL on a remote server, enter the name of that remote server in the SQL Server Name box.
An option to name the database is also provided. If a different database name is preferred, modify the default entry as needed.
11.Click Next to proceed to the SMS Provider Settings page, where an option is given to specify where the SMS Provider should be installed.
You may ask, what is the SMS Provider? Detailed information on the SMS Provider can be found at
http://technet.microsoft.com/en-us/library/bb680613.aspx
But in short, the SMS Provider is the resource the Configuration Manager 2012 R2 console uses for most of its access to data residing in the Configuration Manager 2012 R2 database.
In the example, the Central Administration Site and SQL are installed on the same server, so it only makes sense that the SMS Provider be collocated on that same server. If the SQL Server being used for the Central Administration Site were remote, then you’d need to choose whether to place the SMS Provider on the Central Administration Site or on the SQL Server. Typically the provider would be placed on the SQL Server in that configuration for best performance. It is also possible that the SMS Provider could be placed on a totally separate server. In practice, it is an uncommon condition where using a separate server to host the SMS Provider is warranted. More information regarding SMS Provider placement is available in the “About SMS Provider Locations” section of the “Planning for Site Systems in Configuration Manager” document available at
http://technet.microsoft.com/en-us/library/gg712282.aspx
12.Configure the location, and then click Next to proceed to the Customer Experience Improvement Program page. Review the information and decide whether to participate in the program.
13.With the selection made, click Next to proceed to the Settings Summary page, as shown in Figure 4.7.
Figure 4.7 Setup Wizard: Settings Summary page
14.On the Setting Summary page, review the configured settings, and if corrections are needed, use the Previous button to move backward in the wizard and correct any mistakes.
15.Once all settings are as desired, click Next to proceed to the Prerequisite Check page, shown in Figure 4.8.
Figure 4.8 Setup Wizard: Prerequisite Check page
On the Prerequisite Check page, the wizard immediately starts the Prerequisite Wizard to verify that all components required for a successful installation are present. Note that in the figure one item is flagged with a Warning status. Missing prerequisites that are not vital to successful installation will be listed with a warning to raise awareness of their absence. Common warning conditions listed are as follows:
1. Schema Extensions This warning alerts administrators to the possibility that Active Directory schema extensions may not be installed. In most cases, extending the Active Directory schema is advantageous, but in some corner cases it can cause confusion.
2. WSUS SDK On Site Server This warning alerts administrators to the fact that there is no installation of Windows Server Update Services (WSUS) on the CAS. In most environments ConfigMgr is used to deploy software updates. Software update functionality requires WSUS components to be installed. When they aren’t, the warning results.
3. AD Permissions In order to publish to Active Directory the site server must have permissions. This warning is an alert to administrators that required permissions may not be in place.
4. SQL Memory Usage By default SQL server is configured to consume all available memory and to manage the memory so that other applications have what they need and SQL has the rest. While good in theory, and where a server is dedicated to SQL, when other enterprise applications share a system, which is the case when ConfigMgr is collocated with SQL server, there can be some performance degradation due to memory management. It is recommended in such cases to place a maximum on the amount of memory available to SQL. This is done directly in the SQL interface.
5. SQL Server Process Memory Allocation This warning alerts administrators that on the CAS it is recommended that SQL Server be allocated no less than 8 GB of memory.
Having the listed components installed may or may not be appropriate for a specific scenario depending on the ultimate configuration of the server. If only warning messages are listed, then it is OK to proceed with the install. These warning scenarios can be fixed later if need be. If any critical prerequisites are missing, then setup cannot proceed.
16.Fix anything that shows a Critical status, and run the prerequisite check again by clicking Run Check. If more information is needed about a particular prerequisite, click any specific item to see more detail.
17.Once all prerequisite issues are resolved, click Begin Install to proceed to the Install page and begin installation. Figure 4.9 shows the page after installation is finished.
Figure 4.9 Setup Wizard: Install page: installation complete
The wizard will remain on the same page, and each phase of the installation will be listed, along with its status, as the installation proceeds. Depending on hardware the installation will take several minutes or longer. One of the longest steps is installing the boot image package used for operating system deployment.
18.Once the install completes, scroll through the list of installed components, verifying that each has completed successfully.
19.Also, review the details of the installation procedure by clicking View Log.
The setup process is recorded in two logs, the ConfigMgrSetup.log and the ConfigMgrPrereq.log. If you’re installing the administrative console, that portion will be recorded in the ConfigMgr AdminUISetup.log. Lastly, the wizard progress is recorded in theConfigMgrSetupWizard.log. All of these logs are located in the root of the C: drive where ConfigMgr was installed.
20.When you’re ready, click Close to exit the wizard.
And that’s it; the Central Administration Site is now installed. Feel free to explore the console at this stage if you like. The next step is to install a primary child site and attach it to the Central Administration Site. Proceed to the next section when ready.
Implementing a Primary Site
The next step in building out a hierarchy is to install a primary site. Remember that primary sites can exist either stand-alone or in association with other sites in a structure known as the site hierarchy. As a reminder, if you’re installing a primary site in a stand-alone configuration, it can never be joined to a CAS without a reinstall. If you’re planning a primary site as part of a hierarchy, which is the case for our example, that primary site must be installed and joined to the Central Administration Site. Said another way, a primary site in Configuration Manager 2012 R2 must be a child site of the Central Administration Site. This implies that there can be only a single tier of primary sites in the hierarchy. That implication is correct. Unlike previous versions of Configuration Manager, where it was possible to build hierarchies multiple layers deep with primary sites, Configuration Manager 2012 R2 allows only a single tier of primary sites. This change was made specifically to help simplify hierarchies and increase the efficiency and speed of data moving from one site to another. With Configuration Manager 2012 R2, it is possible to have up to four tiers of hierarchy if secondary sites are used. More on that soon, but for now, let’s install the primary child.
The Setup Wizard is very similar when installing a primary child site. There really are only a few differences. Since we’ve already discussed the setup process for a Central Administration Site, we’ll examine only the specific steps that are different for installing a primary site.
1. As before, ensure that the server where the primary site will be installed meets all prerequisites and is ready to receive the installation.
2. When you’re ready, launch the splash page, choose to install, and move through the wizard using the information we’ve already discussed until arriving at the Getting Started page, accept the license agreement and continue until it show available setup options as shown in Figure 4.10.
Figure 4.10 Setup Wizard: Getting Started page for a primary site
Installing Stand-alone vs. Inclusion in a Hierarchy
If you’re installing a stand-alone primary site and if the option Use Typical Installation Options For A Single Server Installation is selected, then certain pages of the Setup Wizard will be skipped, including the ability to change the directory in which Configuration Manager is installed. This option would be similar to the simple install option available with Configuration Manager 2007. While this option exists, my experience is that most Configuration Manager administrators prefer to see each option as the wizard proceeds to ensure nothing is configured in error.
It is possible to select the option Use Typical Installation Options For A Single Server Installation even when the intent is to join the new primary site to a hierarchy. At this stage of the installation process, setup doesn’t have sufficient information to know the intent. If the option is selected, there will be no option to join to a Central Administration server.
This is the first place where the setup process will differ from what has already been described.
3. On this page, ensure that the option Install A Configuration Manager Primary Site is selected, but do not choose Use Typical Installation Options For A Single Server Installation because this installation isn’t for a stand-alone primary site. Click Next, and proceed through the wizard as before until arriving at the Prerequisite Components page.
4. On the Updated Prerequisite Components page, select the option Use Previously Downloaded Updates From The Following Location, and specify the update folder used when installing the Central Administration Site.
Since the updates are already downloaded and local, this setting should prevent any download delays. Click Next to continue.
5. Continue through the wizard until arriving at the Primary Site Installation page. There, you can choose to install the primary site in a stand-alone configuration or join it to the Central Administration Site.
6. The example installation is to be part of a hierarchy, so do the following:
a. Select the Primary Site Will Be Joined To An Existing Hierarchy option.
b. Specify the name of the Central Administration Site server.
c. Click Next to proceed to the Database Information page, shown in Figure 4.11.
Figure 4.11 Setup Wizard: Database Information page for a primary site
If you had selected the Use Typical Installation Options For A Single Server Installation option on the Getting Started page, this screen of the wizard would have been suppressed.
7. Configure the settings on Database Server page as before.
8. Continue through the wizard as before until you arrive at the Client Computer Communication Settings page, shown in Figure 4.12.
Figure 4.12 Setup Wizard: Client Computer Communication Settings page for a primary site
9. On the Client Computer Communication Settings page, decide whether clients will require secure HTTP communications or whether they can use either secure or non-secure HTTP communication.
For the example, choose the latter option, and ensure that the box for Clients Will Use HTTPS When They Have A Valid PKI Certificate And HTTPS-Enabled Site Roles Are Available is selected. Setting this option ensures that when secure communications are possible, they are used.
10.Click Next to proceed to the Site System Roles page, shown in Figure 4.13.
Figure 4.13 Setup Wizard: Site System Roles page for a primary site
11.On the Site System Roles page, configure whether or not setup should attempt to install a management point and/or a distribution point and, if so, on what server they should be installed and what communication protocol they should be using—either HTTP or HTTPS.
Remember, site system roles do not have to be configured on the site server itself. Often the management point role is configured on the site server and the distribution point role is configured on both the site server and remote servers. For our example the management point and distribution point will be configured on the site server to use HTTP communication.
Further Indication of Central Administration Site Uniqueness
Notice that the option to specify a management point and a distribution point was not a part of the Central Administration Site Setup Wizard. This is another aspect of the fact that the Central Administration Site is different from a standard primary site. As already mentioned, the Central Administration Site cannot host clients, and therefore there is no need for a management point or distribution point.
12.Once this is configured, click Next, and complete the wizard as previously described and allow the primary site server to complete installation. Be sure to fix any relevant prerequisite failures!
If all goes well, the site should be installed. It’s time to move to our next type of site: the secondary site.
Implementing a Secondary Site
Secondary sites historically have been used to allow local access to distribution points across slower WAN links. The secondary site installation allowed communication of content from its primary parent site to be compressed and the sender to throttle communication across sensitive or slow WAN links. Such a configuration was the most compelling reason for a secondary site installation in the past.
There are other reasons to maintain secondary sites in a hierarchy. One such reason would be if WAN links are too fragile to tolerate client traffic as policy data is retrieved from the management point and discovery and inventory data is uploaded to the management point. An example of such a condition would be a facility, such as a cruise ship, relying on unstable satellite connections for communications. In such a case a secondary site may still be needed.
The procedure for installing a secondary site in previous versions has been to either push the secondary site installation across the network or install the secondary site from installation media. You may have noticed that the Setup Wizard has no option to allow for installing a secondary site from media, which leaves only the first option—remote install of the secondary site—available in Configuration Manager 2012 R2. A remote install does not mean that media will need to be pushed to the target server. If media is available locally, then it can be used, or if not available locally, the needed content can be pushed. For our example, a secondary site will be installed as a child of the primary site just completed.
Initiate the secondary site from the Configuration Manager 2012 R2 administrative console. The installation can be initiated from either the Central Administration Server or the primary server. For the example, and since central administration is most commonly used, you’ll start the installation from the Central Administration Site.
1. If the administrative console is not open on the Central Administration Site, open it by selecting Start ⇒ All Programs ⇒ Microsoft System Center 2012 R2 ⇒ Configuration Manager ⇒ Configuration Manager Console.
2. Once it is open, select the Administration workspace, and then expand Site Configuration ⇒ Sites.
3. Select the primary site you just installed, and from the Home tab of the ribbon, choose Create Secondary Site, as shown in Figure 4.14. This action launches the Create Secondary Site Wizard.
Figure 4.14 Secondary site installation
Note in the wizard that a management point and a distribution point will be installed on the secondary site. This is an important distinction because with previous versions administrators had a choice of whether to install a management point, known as a proxy management point, at a secondary site, or not. In Configuration Manager 2012 R2 there is no choice. As already mentioned, if you choose a secondary site configuration, it is assumed the WAN is too fragile to tolerate any unthrottled traffic and that local access to policy is required.
4. Review the remaining information on this page, and click Next to proceed to the General page, shown in Figure 4.15.
Figure 4.15 Create Secondary Site Wizard: General page
5. On the General page, provide information for the site code and the site name as well as the name of the site server where the secondary site will be installed and a path for the installation.
6. Click Next to proceed to the Installation Source Files page. Select whether to transfer the source Files over the network, to use source files at a given network location, or to use source files already staged on or near to the remote system being selected for the secondary site installation.
The latter option allows for scenarios where the network link is insufficient or too unstable to reliably transfer data. For our example, data will be transferred across the network.
7. With the Copy Installation Source Files Over The Network From The Parent Site Server option selected, click Next to proceed to the SQL Server Settings page, shown in Figure 4.16.
Figure 4.16 Create Secondary Site Wizard: SQL Server Settings page
8. On the SQL Server Settings page, either choose to install and configure SQL Express for the secondary server or, if an instance of SQL Server already exists on the destination server, choose the second option and enter details to configure the secondary site accordingly.
SQL and Secondary Site Servers
SQL may already be installed on the secondary site to support other applications, or it may be installed to support components needed by Configuration Manager, such as Windows Server Update Services. If it is, you may choose to install the secondary site database to the existing instance of SQL or choose to install SQL Express instead. If a full version of SQL is already installed, choosing to install SQL Express will result in another instance of SQL running.
Administrators with experience using previous versions of Configuration Manager may see the option to provide a database name and wonder whether they need to take manual action on the destination secondary site server to create the database. There’s no need for concern. The installer will take the supplied database name and create the required database automatically.
For our example, SQL is already installed on the destination server, so follow these steps:
a. Select Use An Existing SQL Server Instance.
b. Supply SQL connection details.
c. Click Next to proceed to the Distribution Point page, shown in Figure 4.17.
Figure 4.17 Create Secondary Site Wizard: Distribution Point page
9. On the Distribution Point page, choose the security options for how clients will communicate and also whether the distribution point will be enabled for prestaged content.
10.Click Next to proceed to the Drive Settings page, shown in Figure 4.18.
Figure 4.18 Create Secondary Site Wizard: Drive Settings page
On the Drive Settings page, configure how you would like your disk drives to be configured for use by the distribution point.
Click Next to proceed to the Content Validation page, shown in Figure 4.19.
Figure 4.19 Create Secondary Site Wizard: Content Validation page
On the Content Validation page, configure whether validation should take place and on what schedule and with what priority. Content validation is discussed in more detail in the Distribution Point site system role section later in this chapter.
11.Click Next to proceed to the Boundary Groups page. This page provides an opportunity to choose which boundary group the secondary site distribution point should join. There is no requirement to join a boundary group at this stage, and since none have yet been created during the install and further discussion of boundary groups is beyond our focus at the moment, we’ll bypass configuring any options on this page.
12.Click Next to proceed to the Summary page, shown in Figure 4.20. This page displays the choices made in the Create Secondary Site Wizard.
Figure 4.20 Create Secondary Site Wizard: Summary page
13.Review the summary, and click Previous if you need to make any corrections. When finished, click Next to begin the secondary site installation.
A progress page will come up while the secondary site installation job is being submitted, followed by the Completion page, which shows the installation details in roughly the same way as they appeared on the Summary page.
Installing a secondary site requires checking for prerequisites. This is done behind the scenes as a part of the installation. It is possible to review the prerequisite checks during secondary site installation in the console. Simply right-click the pending secondary site and select Show Install Status. The Secondary Site Installation Status screen is shown in Figure 4.21.
Figure 4.21 Right-click the secondary site and choose Show Install Status to see this screen.
Finally, a hierarchy is born! All that’s left is to double-check the installations.
Verifying Proper Site Installation
It seems that all sites in our example installed successfully. The Administration console for the Central Administration Site shows all sites listed as expected and in an active state, as shown in Figure 4.22.
Figure 4.22 Administration console showing the Sites node
Based on this view alone, everything appears healthy. To make sure that this is truly the case, it’s worth taking a look at a few key locations to verify. The locations to check may differ depending on the type of site being installed and the associated services chosen. We’ll use the primary site as an example, but the topics generally apply to all types of sites. The areas discussed next are being presented to help with site installation validation. Providing the information in no way infers that it is OK to modify the described settings. In many cases Microsoft doesn’t support modifying the settings, and doing so can result in a damaged site.
Registry Validation
A couple of registry locations are important for validating proper site installation. The locations that we discuss are not exhaustive of all registry keys that are added as part of site installation but rather are intended for use in spot-checking installation success.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS
It may be obvious but the SMS registry key is created as a result of site installation and should appear similar to Figure 4.23. The Identification key is selected to show some of the details about the site.
Figure 4.23 Post-installation Identification key
The CCM registry key is a shared key and will be present when either the management point component of a site server is installed or when a Configuration Manager 2012 R2 client is present on the system. If both are present, then the registry key is shared. The CCM key in this case is present because the installed site is a primary site, and the management point was installed as part of installing the site. If the management point is remote, the key won’t necessarily be present on the site server. Note also that the client elements are missing from the registry key since the client is not yet installed at the site. This is shown in Figure 4.24.
Figure 4.24 Post-installation CCM key
The Central Administration server will not have the CCM key unless a client is installed on the system. The Central Administration server cannot host any clients and therefore cannot have a management point installed.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM
The ConfigMgr10 registry key results from the console installation. Installing the console as part of the installation is optional, so this key may not be present. The key is shown in Figure 4.25.
Figure 4.25 Post-installation ConfigMgr10 key
HKEY_CURRENT_USER\Software\Microsoft\ConfigMgr10
The Services registry key is host to an abundance of keys for the various services running on the system. There will be a number of keys beginning with SMS_ after a successful install. The number and type will depend on the type of site in question. This key is shown inFigure 4.26.
Figure 4.26 Post-installation Services key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
File System Validation
Site installation files are located in a couple of different file locations. Pick the disk where Configuration Manager 2012 R2 was installed and navigate to ..\Program Files\Microsoft Configuration Manager. The folder will look similar to Figure 4.27. In addition, for sites with management points navigate to Program Files\SMS_CCM. The folder will look similar to Figure 4.28.
Figure 4.27 Microsoft Configuration Manager installation folder
Figure 4.28 Management point SMS_CCM installation folder
Group Validation
The idea of a site hierarchy has been mentioned several times. In order to have a site hierarchy, the individual sites must be able to communicate. Detailed discussion about how this is done is beyond the scope of this chapter except to mention one thing: Communication between sites requires a security context. In Configuration Manager 2012 R2 such configuration is facilitated using groups configured on the site servers during installation. Several groups are created during site installation, but only a single group, the SMS_SitetoSiteConnection_<site code> group, is used to configure the security context for site-to-site communication. When sites attempt communication, the default option is to do so with computer accounts. In the example hierarchy this would mean that when the Central Administration Site attempts to communicate with the primary site, it will attempt a connection using the computer account of the Central Administration account. This communication will fail unless the Central Administration Site’s computer account is part of the SMS_SiteToSiteConnection_MI6 group. Said another way, any site that needs to communicate with the primary site must have its computer account as a part of the SMS_SiteToSiteConnection_MI6 group. This group is shown in Figure 4.29.
Figure 4.29 SMS_ groups added as part of installation
Adding Computer Accounts as Administrators
OK, it’s not really true to say that the computer accounts must be members of the SMS_SiteToSiteConnection_<site code> group. Simply adding the computer accounts as administrators of the various servers would achieve the same purpose and is not recommended. Taking this approach grants more rights than are necessary to the computer accounts and is not a recommended method.
If you prefer not to use the computer accounts as administrators, then it is possible to configure specific credentials to facilitate site-to-site communication. Simply substitute those credentials for the computer account in the same group.
Windows Management Instrumentation Validation
We’ve already mentioned the idea of the SMS Provider. The SMS Provider is used to interact with the site server database, so ensuring that the installation created information in Windows Management Instrumentation (WMI) as required is important. The current discussion is not intended to be a detailed WMI discussion; simply ensuring that the namespaces were created as required is enough. To verify, follow these steps:
1. Open Computer Management.
2. Select Configuration and then WMI Control.
3. Right-click WMI Control and select Properties.
4. Select the Security tab and expand Root.
A successful installation will result in the SMS namespace being created along with the child namespace site_<site code>, as shown in Figure 4.30.
Figure 4.30 WMI namespace validation
Services Validation
The services have already been validated in the registry, but it’s also a good idea to take a look at them in the Services list to ensure all are present and in the proper state of operation. This is shown in Figure 4.31.
Figure 4.31 Services validation
Database Validation
A site can’t work without its database, so it stands to reason that the site couldn’t be installed successfully without the database being installed successfully. Very true, but it’s still worth a look for familiarity if nothing else. To view the database, launch SQL Management Studio and follow the steps listed. In our example, SQL is located on the same server as the site.
1. Connect to the database.
2. Open the server.
3. Expand Databases, and the CM_MI6 example database should be present. This is shown in Figure 4.32.
Figure 4.32 Database validation
Troubleshooting a Configuration Manager 2012 R2 Site Installation
We’ve validated the hierarchy installation, but that doesn’t guarantee the site is working properly. Configuration Manager has many moving parts, and at times problems will surface. Understanding how to troubleshoot those problems is important to maintaining a healthy Configuration Manager hierarchy. So where should you look to troubleshoot issues with a site? Let me first say that this chapter is not an exhaustive troubleshooting chapter. Troubleshooting is covered in some depth in Chapter 19, “Troubleshooting.” Still, it’s helpful to know how things have progressed for a site installation. Fortunately, Configuration Manager is not lacking in information to help administrators check for problems and ascertain the nature of the problems. As with validation, this brief troubleshooting discussion will focus on the primary site that was installed.
The key component in place at a site, whether that site is the Central Administration Site, a primary site, or a secondary site, is the SMS_Executive component. This one service orchestrates most every activity at a site, and the list of SMS_Executive threads is extensive.Figure 4.33 is a screenshot of the various threads that run as part of the SMS_Executive component.
Figure 4.33 SMS_Executive threads
Since this is such a key service for all sites, it’s a good idea to check the status of the Executive service in general to make sure all is well. Details on the various threads of the SMS_Executive component will mostly be left for later.
There are several ways to view details on the status of SMS_Executive. First, Configuration Manager provides a robust status message system so administrators can tell at a glance if all is good with a particular component. Take a look at the Monitoring ⇒ System Status ⇒ Component Status node of the administrative console; the SMS_Executive component, along with all of the other threads, is visible. A quick look shows that the status of this thread is OK, as shown in Figure 4.34. Note that the SMS_Executive component from all three sites is displayed here.
Figure 4.34 SMS_Executive component status
Status messages are not shown in real time, and there may be some short lag in reporting an error condition or reverting to an OK condition if a component is again running healthy.
If the status is not OK or you need more details about this component, you can see them by right-clicking, selecting Show Messages, and selecting what kind of messages are of interest. On the context menu is also the Reset Counts option, which will reset to 0 any error counts being held for the various types of messages, errors, and warnings. You can take this action after resolving an issue and to restart tracking of a component.
Another way to view the status of a component, and the method preferred by many administrators, is to take advantage of the extensive logging system provided in Configuration Manager. The logs are located in the Microsoft Configuration Manager ⇒ Logs directory on the site server. Just as the status system showed the various components, there are logs representing them as well. The names aren’t identical to the component names, but they are very similar and generally easy to correlate. In the case of the SMS_Executivecomponent, the corresponding log is smsexec.log, as shown in Figure 4.35.
Figure 4.35 smsexec.log file
These log files can be viewed directly in Notepad, but the native CMTrace log viewer utility is preferred because it formats the logs nicely and also allows monitoring logs in real time as they are written.
Good Old Trace32
Configuration Manager 2012 introduces an updated version of Trace32. The new name is CMTrace. Previous versions of the Trace32 utility may have problems if used in Configuration Manager 2012 R2. The updated utility is available in the Tools folder on the Configuration Manager 2012 R2 media.
Like Trace32, the CMTrace utility is very flexible, and administrators will find it to be useful for examining logs other than those from Configuration Manager.
Another critical component of the site is the site server database. Without the database, the site fails to function. To that end, you must understand how to at least begin an investigation of the database should problems arise. The database status can be seen in the Monitoring node of the Configuration Manager console as well. In terms of the database, isolating specific components to troubleshoot is difficult because it really does depend on the problem at hand. However, two components are fairly important for interaction with the database: the SMS Database Monitor and the SMS Provider.
1. SMS Database Monitor The SMS Database Monitor, represented in the Monitoring node as SMS_Database_Notification_Monitor and in the logs as smsdbmon.log, is responsible for monitoring actions that are taken by the administrator in the console and for taking steps to implement those changes by notifying the various components of the SMS_Executive component that work is waiting to be done.
2. SMS Provider The SMS Provider is important because it is the conduit between most console actions and making those actions effective in the database. As an example, when an administrator selects a site to view in the console or makes changes to a console setting, the SMS Provider interacts with the SMS database via WMI to retrieve needed data or make changes to data. Without the SMS Provider the site cannot function.
Another useful location for quickly checking the status of the database and more is again in the Monitoring node but this time under Site Status. In this node it’s quick to see the amount of disk space available for various components that make up a site. This node is shown in Figure 4.36.
Figure 4.36 Site Status Monitoring node
Unattended Installation
In some cases it may be of interest to perform a scripted install of Configuration Manager. This chapter won’t go into depth about how this process works, but suffice it to say that the most difficult part of installing a site often is the answer file used during installation. Configuration Manager 2012 R2 makes this easier by the fact that when a site is installed through the UI, an unattended installation file is created as part of the process. This unattended file is called ConfigMgrAutoSave.ini and is located in the tempdirectory for the user installing the product. The file is easily modified to perform scripted installs of other sites.
The unattended files generated in the example are shown to give an idea of how these are constructed based on different site types. When you’re using the unattended file to initiate a site installation, a command line similar to the following should be used:
Setupwpf.exe /script <path to script>\ConfigMgrAutoSave.ini
This command line should be initiated from within this directory:
<Configuration Manager Source>\SMSSetup\BIN\x64
The content of the unattended files is shown in Listing 4.1 and Listing 4.2. Note, single lines may wrap for readability.
Listing 4.1: Central administration site unattended file
[Identification]
Action=InstallCAS
[Options]
ProductID=
SiteCode=CAS
SiteName=Demo Hierarchy - Central Administration Site
SMSInstallDir=C:\Program Files\Microsoft Configuration Manager
SDKServer=cmcas.contoso.com
PrerequisiteComp=0
PrerequisitePath=C:\SCCM2012Updates
MobileDeviceLanguage=0
AdminConsole=1
JoinCEIP=0
[SQLConfigOptions]
SQLServerName=cmcas.contoso.COM
DatabaseName=CM_CAS
SQLSSBPort=4022
SQLDataFilePath=C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\
MSSQL\DATA
SQLLogFilePath=C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\
MSSQL\DATA
[HierarchyExpansionOption]
Listing 4.2: Primary site unattended file
[Identification]
Action=InstallPrimarySite
[Options]
ProductID=
SiteCode=PS1
SiteName=Test Hierarchy - PS1
SMSInstallDir=C:\Program Files\Microsoft Configuration Manager
SDKServer=cmps1.contoso.com
RoleCommunicationProtocol=HTTPorHTTPS
ClientsUsePKICertificate=1
PrerequisiteComp=1
PrerequisitePath=\cmcas\c$\sccm2012updates
MobileDeviceLanguage=0
ManagementPoint=cmps1.contoso.com
ManagementPointProtocol=HTTP
DistributionPoint=cmps1.contoso.com
DistributionPointProtocol=HTTP
DistributionPointInstallIIS=0
AdminConsole=1
JoinCEIP=0
[SQLConfigOptions]
SQLServerName=cmps1.contoso.com
DatabaseName=CM_PS1
SQLSSBPort=4022
SQLDataFilePath=C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\
MSSQL\DATA
SQLLogFilePath=C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\
MSSQL\DATA
[HeirarchyExpansionOption]
CCARSiteServer=cmcas.contoso.com
Installing Site System Roles
The process just discussed results in a hierarchy with three sites: a Central Administration Site, a primary site, and a secondary site. But just installing the sites doesn’t mean that installation is complete. In order to provide service to clients that will be interactingwith these sites, you must first decide what services will be provided and then configure the additional site components that facilitate providing the needed services. These site components are also known as site system roles. The ones available for a given site will depend on the site type:
Central Administration Site
· Asset Intelligence synchronization point
· Certificate registration point
· Endpoint protection point
· Reporting Services point
· Software update point
· System Health Validator point
· Windows Intune Connector
Primary site
· Application Catalog web service point
· Application Catalog website point
· Certificate registration point
· Enrollment point
· Enrollment proxy point
· Fallback status point
· Out of band service point
· Reporting Services point
· State migration point
· System Health Validator point
Secondary site
· Software update point
· State migration point
Notice that the term interacting was used in regard to clients and site servers. Administrators familiar with Configuration Manager may have expected the term assigned to be used instead. This term was used on purpose because in Configuration Manager clients can only be assigned to primary sites but are able to interact with any site their boundaries match. This concept is known as roaming and describes how clients are able to interact with secondary sites and other primary sites if they’re within defined boundaries for those sites. Roaming is beyond the scope of discussion for this section.
A common element in installing all site system roles is the Add Site System Roles Wizard. Before launching the wizard to add the role, you must first decide whether the role will be added to an existing server or a new server. In the example hierarchy just built, that means a choice of adding the new role to a site server itself or creating a new server on which to add the role (both are shown in Figure 4.37).
Figure 4.37 Use the Create Site System Server button on the ribbon to create a new server; use the context menu to assign a new role on an existing server.
· If you’re adding to an existing server, simply right-click that server under the Servers and Site System Roles node of the console, and choose Add Site System Roles.
· If you’re adding a new server to host a site system role, that process is initiated by selecting the Create Site System Server action from the Home tab of the ribbon.
A single remote site system server cannot host roles from multiple sites!
Both methods will result in the Create Site System Server Wizard being launched. The only difference is whether the server name field will be populated and grayed out, and there is no option to specify the site code that the new server should support since it is already part of a site. For the example, site system roles are being added to the primary site, which already exists. The first page of the wizard is shown in Figure 4.38.
Figure 4.38 Add Site System Roles Wizard: General page
On this page of the wizard you have the opportunity to provide a server name. This option will be available only if you’re creating a new site system server. In addition, options are available to supply the FQDN of the server if it will be addressable from the Web. This option was also available in Configuration Manager 2007, but this brings up an interesting point of discussion. Configuration Manager 2007 supported two security modes: standard security and native mode security. Native mode security was required when specific functions were to be used, such as Internet-based client management and mobile device management. Native mode as a security option in Configuration Manager 2012 is gone and has been replaced by the ability to designate site system servers as those that will participate on the Internet or serve other functions that require certificate-based security. In this way the additional security afforded by certificates can be applied just where it’s needed—to the site system itself.
The option Require The Site Server To Initiate Connections To This Site System appears to be new but is actually just a relabeling of the Configuration Manager 2007 option that was on this page: Allow Only Site Server Initiated Data Transfers From This Site System. The goal of this option, as the wizard states in Configuration Manager 2012, is to designate that communication to site systems should be initiated from the site server itself rather than the site system pushing data back to the site server. This adds additional security and also accommodates scenarios where trusts aren’t in place to accommodate cross-forest authentication.
Administrators accustomed to previous versions of Configuration Manager may note that the option to set the site system as a protected site system is no longer available on the first page of the Create Site System Server Wizard. Site system protection only ever applied to distribution points and state migration points. Based on the new design of Configuration Manager 2012 R2, meaning distribution points and state migration points are protected by default (more on that shortly), the option to do so was not needed on the Create Site System Server Wizard.
Clicking Next on the wizard will move you to the node to allow you to select which site system roles should be added to the target server. Once you select the roles and continue moving through the wizard, you must configure the various options for the role-specific pages that will be displayed. Those pages will be discussed shortly for each type of site system.
As previously stated, the available site system roles for a given server depend on the type of server being configured. Each available site system role is described next.
Understanding Configuration Manager 2012 R2 Site System Roles
The various site system roles available for each site type can be seen using the administrative console and focusing on the site in question. The list of available site systems that might be installed at the Central Administration Site, for example, can be obtained by doing this:
1. Open the console and navigate to Administration ⇒ Overview ⇒ Site Configuration ⇒ Servers And Site System Roles.
2. Select the site type of interest, right-click, and choose Add Site System Roles.
3. In the wizard, move to the System Role Selection page.
4. Compare the roles available on this page to the roles already installed for the site, as shown in the console.
5. Then, generate a full list of available roles for a given site.
You can use the same approach for obtaining lists of available site systems for a primary site and a secondary site. Table 4.1 shows the available sites for each site type.
Table 4.1: Available site system roles by site type
Notably missing from the list of roles at the Central Administration Site is the management point role and the distribution point role. This might seem strange at first until you again factor in that a Central Administration Site is not intended to support any clients; it is solely for the purpose of administration.
Also notably missing are the PXE service point role for operating system deployment and the Server Locator Point role used to help clients during site assignment and management point lookup. Don’t worry, neither role is gone. The PXE service point is now available as a component of the distribution point role and the Server Locator Point has been merged into the management point role.
Another interesting aspect is that one of the site system roles listed for each site is the site server itself. That may seem odd, but in truth the site server function is but one role, albeit the key one, for a site. Note also that these roles can be placed on the same server or they can be placed on dedicated servers. The decision is driven by client count and load on a given role. For some site systems types such as distribution points (discussed shortly), it’s quite possible that the same role will be needed on multiple servers to support a single site.
Now, let’s discuss what each site system role does, the services it delivers, how it can be used, and some tips on troubleshooting each role.
Component Server
A component server is a unique site system role in Configuration Manager. This role cannot be manually added, nor can it be manually removed. This role is managed by the site server itself and will exist on any server that is running the SMS_Executive service within the hierarchy. This service runs specified threads that support other roles such as a management point.
Troubleshooting a Configuration Manager Component Server
This role manages the threads of the SMS_Executive service. It maintains which roles are local and remote for a given site. The overall health of the site server role can be reviewed in the Monitoring node. You can review the following logs to gain insight into the component server health:
1. sitecomp.log This log shows all the site roles and where they’re configured to be running.
2. compmon.log This log records the status of all the threads of the SMS_Executive service and writes that status to the system registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Operations Management. This information is used to keep track of component status and is also used as a resource for System Center Operations Manager in monitoring the status of Configuration Manager.
Distribution Point
The distribution point role has been expanded in Configuration Manager 2012 R2. In previous versions this site system was nothing more than a glorified file server, storing files for access by clients requiring content.
The role of the distribution point is still to store file content and make it available to clients, but the way in which it does this has been updated. The first thing that we should mention is that the distribution point is designed to support both classic package distribution and the new application distribution mechanism introduced in Configuration Manager 2012 R2. The legacy style distribution point, which is noted by a file folder named SMSPKG<driveletter>$, remains but is used only for packages set to Run from Distribution Point, and this is the only deployment mechanism that bypasses the requirement to use Background Intelligent Transfer Service (BITS). Beyond that, the updated distribution point structure is used universally. While the function of the distribution point in Configuration Manager 2012 R2 remains the same, making content available to clients, the structure and function of the distribution point to provide its service have been substantially updated.
· There is no option to use the distribution point without making use of BITS.
· The distribution point structure is no longer just a file store. Now, files are stored in a cache that takes advantage of single-instance storage, supports automated integrity checks, and more.
· The branch distribution points are gone and replaced with the fact that a standard distribution point is now fully supported on a supported Windows 7 workstation system, no client required. The workstation system is still subject to the connection limitation for a given operating system. In Windows XP administrators were accustomed to a connection limit of 10. In Windows 7 the connection limit increased to 20.
Bottom line, this isn’t your grandpa’s distribution point anymore! First things first—the distribution point must be installed.
It may be that the distribution point role is already installed. One of the default settings when installing a primary or secondary site is to also add the distribution point and management point roles. If the role has not yet been added or if an additional distribution point is needed, then this component won’t yet be present on the server and will need to be added.
1. In the Create Site System Server Wizard, and as shown in Figure 4.39, select the distribution point role, and click Next to proceed to the Distribution Point page of the wizard, as shown in Figure 4.40.
Figure 4.39 Create Site System Server Wizard: distribution point selected
Figure 4.40 Create Site System Server Wizard: Distribution Point page
2. On the Distribution Point page of the wizard, configure a few options:
· The first option, Install And Configure IIS If Required By Configuration Manager, is not selected by default, but you must select this option prior to proceeding. This option highlights the fact that with Configuration Manager 2012 R2 it is not possible to create a non-BITS-enabled distribution point. This fact may influence distribution point placement but is a welcome modification for sure. Also in this section you can select Enable And Configure BranchCache For This Distribution Point. BranchCache is a feature introduced with Windows Server 2008 R2 that allows systems within the same subnet and separate from a content source to share downloaded content locally rather than each system having to download them. You can also enter any information as a description of this distribution point; it’s a good idea to configure this to verify what this distribution point is for.
· Next on the page is the choice of whether clients should communicate with the distribution point using HTTP or HTTPS traffic. When clients use BITS to pull information from the distribution point, as is required by Configuration Manager 2012 R2, the clients do not directly connect to the distribution point structure but rather initiate a BITS session through IIS.
· Other options on this page allow the administrator to decide whether the distribution point will use self-signed certificates or certificates imported from a different source, such as a certificate authority. If the installation supports Internet scenarios, a certificate would be imported at this step.
· The last option on the page allows configuration of a distribution point to support prestaged media. Prestaged media is a new feature of Configuration Manager 2012 and addresses scenarios where administrators would prefer to deliver content in bulk to a distribution point rather than having it copied over the network. In previous versions of Configuration Manager this was not supported natively, although there were tools available to help at least partially address this need, such as PreLoadPkgOnSite.
3. Once you’ve configured all options on this page as needed, click Next to proceed to the Drive Settings page, shown in Figure 4.41.
Figure 4.41 Create Site System Server Wizard: Drive Settings page
Also new to Configuration Manager 2012 R2 is the ability to control distribution point drive selection and allocate reserved storage when configuring the distribution point. Mechanisms did exist in previous versions of Configuration Manager to make similar configurations effective, notably the use of the no_sms_on_drive.sms flag file, but having these options in the console allows more effective and granular administrator control. A couple of options are presented here:
· First is the ability to preconfigure the amount of drive space that should be reserved for the distribution point.
· The next set of options, which are perhaps more important, let you choose which drives should be used for the content libraries and package share locations. In our example, there is only a single drive on the site server, so leaving the options set to Automatic makes sense.
Also, since there is only a single drive on the server, it doesn’t make sense to set a secondary content location, so that option is grayed out. If multiple drives are available and the setting is left at Automatic, then the system will pick the drives to use the same way it has done historically—using the NTFS drive with the most available space as a first choice and so on.
4. Select the Pull Distribution Point page of the wizard if you need this option for your distribution point. The use of pull distribution points can help reduce the processing load on the site server when you deploy content to a large number of distribution points at one site.
Configure the distribution point to be a pull distribution point by selecting Enable This Distribution Point To Pull Content From Other Distribution Points, as shown in Figure 4.42.
Figure 4.42 Create Site System Server Wizard: Pull Distribution Point
· Click Add, and then select one or more of the available distribution points to be source distribution points.
· Click Remove to remove the selected distribution point as a source distribution point.
5. Once the settings are configured as needed, click Next to proceed to the PXE Settings page of the wizard, shown in Figure 4.43.
Figure 4.43 Create Site System Server Wizard: PXE page
The PXE Settings page of the wizard lets you choose whether the distribution point being configured should also act as a PXE server for operating system deployment. Because of the dependency the PXE server has on the distribution point to deliver boot images, having this setting as part of the distribution point makes sense. For the example we won’t install a PXE point; it can be added later as needed.
6. Review the settings on this page and click Next to proceed to the Multicast page of the wizard, shown in Figure 4.44.
Figure 4.44 Create Site System Server Wizard: Multicast page
The Multicast page of the wizard allows administrators to specify whether the distribution point being configured should support multicast or not. Multicast is used with operating system deployment and is a very efficient protocol for delivering images to multiple systems simultaneously. The example distribution point will not be used for multicast support for now, so this option will not be selected. It can be added later as needed.
7. Review the settings on this page, and click Next to proceed to the Content Validation page, shown in Figure 4.45.
Figure 4.45 Create Site System Server Wizard: Content Validation page
The Content Validation page of the wizard allows administrators to specify whether content should be periodically validated on the distribution point and, if so, on what schedule and at what priority. When Validate Content On A Schedule is selected, the default evaluation period is once per week and at a low priority, to ensure other activities on the server are not disrupted.
This is a significant feature update for Configuration Manager! Most readers who have used distribution points in previous versions of Configuration Manager will have encountered a scenario where content will be distributed to distribution points, work fine for a period of time, and then start to show errors, typically a hash mismatch problem. This might happen for several reasons, often due to on-demand virus scanning of the distribution points, but when encountered, the problem is disruptive until fixed. The ability to do content validation and proactively identify problems is a welcome change indeed! Further, the updated structure of the distribution point should help keep content in a good state as well. More on the distribution point structure shortly.
8. Once you’ve configured these settings, click Next to proceed to the Boundary Groups page of the wizard, which allows the administrator to choose the boundary group(s) of which the distribution point should be a member. While it is not a strict requirement that a distribution point be a member of any boundary group in order to be created, the distribution point may not be accessible by any client until it is added to the appropriate boundary group(s). Detailed discussion of boundary groups is beyond the focus of this chapter, but based on the tight dependency between distribution point function and boundary groups, a bit of discussion is appropriate here.
Boundary groups are new in Configuration Manager 2012 R2 and serve two purposes: client assignment and content access. The latter item is the one of concern for distribution point access. We mentioned earlier that on the Create Site System Server Wizard’s General page, the option to specify a site system as protected was removed. In Configuration Manager 2012 R2, when a distribution point (or state migration point in operating system deployment) is added to a boundary group, by definition the distribution point is protected and only those clients that are within the boundaries defined by the boundary group are able to retrieve content from the distribution points that have membership in the boundary group. Further, a distribution point can have membership in multiple boundary groups. By taking this new approach, administrators are afforded additional control to easily specify which distribution points are available to service clients depending on which subnets the clients happen to be located near.
But what if a client requires access to content but is not within boundaries defined by any boundary group, such as a laptop in a hotel room? That scenario is also addressed. Boundary groups can be flagged as accessible to systems when the system is in a location where no other distribution point can be resolved. This is known as fallback and is enabled by default for the boundary group, as noted at the bottom of the Boundary Groups page. For the example, the distribution point has been added to a boundary group that was previously created for the example primary site.
9. Once the boundary group configuration is complete, click Next to review the Summary page of the wizard.
10.After confirming all settings, click Next to finish the wizard and implement the distribution point deployment. The successful completion is shown in Figure 4.46.
Figure 4.46 Create Site System Server Wizard: Completion page
As mentioned earlier, the Configuration Manager 2012 R2 distribution point structure has changed. After installation is complete and after a couple of applications have been deployed, open the drive hosting the distribution point and check for a few folders, as shown in Figure 4.47.
Figure 4.47 Distribution point structure
The same folders you might expect from previous versions are still present to support distribution of classic software packages configured to Run From Distribution Point: SMSPKG, SMSPKG<driveletter>$, SMSSIG$, and SMSPKGSIG. In addition to these folders another is present called SCCMContentLib. This folder contains the new structure for the distribution point and is worth further discussion.
Historically, opening the distribution point folder will reveal a list of folders named with package IDs and, within the folder, the contents of the package. That still is the case, but the structure is far different. Remember that the new distribution point structure in Configuration Manager 2012 R2 is designed to take advantage of single-instance storage and also to be a bit more stable. Looking inside the SCCMContentLib folder reveals three additional folders, DataLib, FileLib, and PkgLib, shown in Figure 4.48.
Figure 4.48 SCCMContentLib structure
The PkgLib folder is the starting place to examine the new structure, and it contains files with names that match the package ID from the site, shown in Figure 4.49.
Figure 4.49 PkgLib folder structure and INI files
Note that these files are INI files. Looking inside reveals the packages that are associated with the package ID. From here, copy and paste the two Content_ GUIDs and navigate to the DataLib folder, shown in Figure 4.50. For the example, use Content_3b898e35-9ecc-45e2-9231-ee3f30b2a3aa.1.
Figure 4.50 DataLib folder structure, GUID folder, and configuration file
In the DataLib folder there are two entries that match; the first is a folder and the second is a configuration file. Looking at the GUID folder first, it looks like the location of the package content. But not so fast! The filenames here will match the filenames from the source file folder, but a quick glance at the file sizes and file extension will show that these are just configuration files. Taking a look at the client.msi file reveals details about the actual file, including file size, in this case 30625792 bytes, and the hash value for the file. The first four characters of the hash value here are key to finding the actual file. In the example, the hash value of interest is 709E. More on this shortly.
In addition to the source file structure there is another configuration file matching the GUID in question; it is at the root of DataLib. Opening it shows a hash value for the folder itself.
Armed with information gained from this folder, it’s time to visit the FileLib folder, shown in Figure 4.51.
Figure 4.51 FileLib folder structure
Within the FileLib folder is a series of other folders with names that at first appear cryptic—only four characters. Aha! Remember that we just mentioned that the first four characters of the hash value for the client.msi file were important. In this folder there is a subfolder named 709E. A quick look inside that folder reveals a file with the exact size of the client.msi file—30,626,792 bytes. Bingo! This is the location of the actual client.msi file, simply renamed and placed into this single-instance storage format.
Software Requirements
Configuration Manager 2012 R2 distribution points require the following:
· All site servers must be members of a Windows 2003 or higher Active Directory domain.
· Distribution points require Background Intelligent Transfer Service (BITS) version 2.0 or higher and cannot be installed or used without it.
· Distribution points may be installed on any supported server or client operating system.
· All Configuration Manager distribution point systems using BITS bandwidth throttling require BITS 2.0 or higher.
Troubleshooting a Configuration Manager 2012 Distribution Point
Without the packages being staged on the distribution points, content deployment (packages, applications, operating systems, and software updates) in the environment cannot be completed. Providing insight into the process and health of the hierarchy distribution points, status messages and log files can be an administrator’s best friend.
The Monitoring node of the administrative console, shown in Figure 4.52, will give insight into the health of the distribution points.
Figure 4.52 Monitoring node, distribution point focus
There is a specific folder for the distribution points, called Distribution Status, that provides insight into the status of content, distribution groups, and distribution point configuration. There is also the Component Status folder, where you can review the health ofSMS_DISTRIBUTION_MANAGER, the key component for deploying content to distribution points.
In addition to status messages, distmgr.log provides insight into the distribution points for troubleshooting purposes. It tracks the different packages by package ID, size, and location where they are to be stored.
Management Point
A management point is the primary point of contact between the Configuration Manager 2012 R2 clients and the site server. All site servers that host clients must have at least one management point installed; this includes primary site servers and secondary site servers. A management point installed at a secondary site server is known as a proxy management point. Clients use the management point to retrieve and send all data to and from their assigned site server; this includes retrieving settings and configuration via the policy and forwarding operational data such as inventory, state messages, status messages, discovery information, and more. In addition, clients will send requests to the management point requesting help locating content they may need, such as finding which distribution points are available to the client and contain needed software update or software package content or even the location of a software update point used in software update scanning.
Once a management point receives data from the client, it will be further analyzed and converted into a form acceptable by the site server and then forwarded to the site server for further processing. This also includes content location requests, but in these cases there is no data to forward to the site server. Instead, the management point will execute queries against the site database and return that information to requesting clients.
Here are a few things to remember about management points:
· Every primary and secondary site must have a management point specified.
· The Central Administration Site cannot host a management point.
· Management points require access to the site database for certain operations.
· Management points require a local installation of IIS to be installed.
· Management points make use of BITS when moving content, depending on size, to help avoid impacting network utilization.
Also of interest for management points is that they no longer have a dependency on WebDAV. Add to this that management points are now treated similarly to distribution points in that they can be placed where needed to support clients. In previous releases of Configuration Manager, the only way to host multiple active management points at a site was by using a network load balancer as a front end. Now management points are simply looked up by clients—similar to distribution points—and the best choice at a site is returned to the client. This statement may cause you to ask how exactly clients learn about possible management points. There are a couple of ways. It’s possible to specify a single or multiple management points on the command line when installing the client using the SMSMP switch. If Active Directory publishing is enabled, then clients will be able to look up the management point list from there as well. During client installation, and during ongoing client operation, they will learn which management point is optimum for their use through boundary groups—again, much the same as distribution points.
Another big shift for management points is that now the server locator point functionality is included in this role.
It may be that the management point role is already installed. One of the default settings when installing a primary or secondary site is to also add the management point role. If the role was not yet added as part of setup, then you will need to add it.
1. In the Add Site System Roles Wizard, select to add the management point role, and click Next to proceed to the Management Point page, as shown in Figure 4.53.
Figure 4.53 Add Site System Roles Wizard: Management Point page
· The first choice on this page allows administrators to choose how clients should communicate with this management point, either by HTTP or by HTTPS.
· Administrators are also able to specify whether they want to receive an alert in the console indicating when the management point is unhealthy.
This is a new option for Configuration Manager 2012 R2, and it points to the basic monitoring capability that has been added. If this option is selected, administrators can find alerts generated in the Monitoring workspace of the console.
2. Click Next to continue to the Management Point Database page shown in Figure 4.54.
Figure 4.54 Add Site System Roles Wizard: Management Point Database page
Proxy Management Points
Proxy management points are the same as standard management points except that they are located at a secondary site. In previous versions of Configuration Manager it was the administrator’s choice whether to include a proxy management point at secondary sites. In Configuration Manager 2012 R2 there is no choice; proxy management points are automatically installed on every secondary site server.
Proxy management points exist to help reduce the impact on the WAN when clients are operating outside the boundaries of their assigned primary site but within the boundaries of a secondary site that is a child of their assigned primary site. A client in this configuration will consider the proxy management point to be its local management point but will always consider the management point from its assigned primary site to be the assigned management point. The difference between the two is that the client is able to use the local management point to find local distribution points via content location requests and also as a point for offloading data, such as inventory and state messages, on its way to the parent site’s database. The client will still use its assigned management point to retrieve all policy changes.
Proxy management points can significantly reduce the load on WAN traffic by processing data from and providing client policy to those clients that fall within their roaming boundaries. Data flow between Configuration Manager clients and the Configuration Manager 2012 R2 hierarchy is as follows:
1. Clients send discovery data, inventory data, status data, and software-metering data to the proxy management point in XML format.
2. The proxy management point processes the submitted XML file and converts it into the appropriate file type, and the file is placed in the associated Inbox directory on the secondary site server.
3. The secondary site server processes the data as it would under normal circumstances and forwards it up the hierarchy to its parent site.
Proxy management points also retrieve policy information from the database of the primary site and forward the data to Configuration Manager clients. Proxy management points allow the client to function locally when roaming to a secondary site, while further allowing administrators to control the replication of client data from the secondary site to the primary parent by means of standard sender throttling.
How Clients Find Management Points
During installation and general operation, Configuration Manager 2012 clients obtain management point locations in much the same way as they look up distribution points. Configuration Manager 2012 R2 allows for multiple active management points per site. Periodically, clients will poll for which management point they should be using. The determination is made by evaluating boundary groups in relation to the client, very similar to the mechanism used to find distribution points. If a client roams outside of its assigned sites boundaries, then the lookup is a bit more complex but is needed to allow clients to access local management point servers where possible. There is also a lookup mechanism for management points in Active Directory.
Locating Management Points in AD
In an environment that provides Active Directory services, Configuration Manager 2012 R2 clients locate management points as follows:
1. The client searches the Active Directory global catalog for a local site code with a matching Active Directory site name, IP network, or IP address range that has been previously registered by a site server.
2. If a match is not found or if required content is not available at the local site, then the client uses the site code of its assigned site.
3. The client then queries Active Directory again to find the appropriate management point for the site code identified in the previous steps.
For this reason, management points should be installed prior to Configuration Manager client deployment, but the client will be able to access the management point once it becomes available.
4. If there is only one management point for the site, the client gets the name of that management point from Active Directory and then connects to it.
Overlapping Boundaries and Management Point Location
The fact that the client will always query Active Directory first when attempting to locate management points is one of many reasons why overlapping site boundaries is unsupported and will wreak havoc on an environment. When sites publish their information to Active Directory and that information is inconsistent, as in the case of overlaps, the client may not choose the correct management points for use when looking up content locations. The result may be failed software deployment in the environment, not to mention the implications for proper client assignment if installing clients.
Automatic MP Query
When installing the Configuration Manager client, you must either set it to determine the SMS site automatically or specify site assignment as part of the command line for the installation. During installation and after being assigned to a site, the client will look up the appropriate management point it should be using. The client gets this list either by command line during installation, querying active directory, or learning about additional management points and adjusting after installation.
In addition, a new option has been added to Configuration Manager 2012 R2 to specify a default site a client should be assigned to if it is unable to find a site by normal lookup mechanisms. This fallback ability helps ensure clients do not get installed and immediately orphaned because they cannot find a site.
You can see this in the LocationServices.Log file of the Configuration Manager client, located at %Windir%\CCM\Logs.
Server Locator Point functionality
As mentioned, the server locator point functionality has been merged into the management point role. But what is a server locator point used for? Server locator points are used within a Configuration Manager 2012 hierarchy to provide services for client site assignment, location of client installation files, and location of management points when clients cannot access that information within Active Directory. Thus, merging this role with the management point role is a natural fit.
Logging
Logs of management point activity can exist in one of two locations, depending on which was installed first: the Configuration Manager client or the management point. The management point and the client share a common framework and thus both run under the SMS Agent Host service or the short name of CCMExec. This is potentially confusing at first because it is possible to have just a management point installed without the client component, but the service name will still be SMS Agent Host.
If the management point is installed on a server first, the logs will be located in the .\SMS_CCM\Logs directory. When the Configuration Manager client has already been installed on the server, the logs are located in the %Windir%\CCM\Logs directory along with the client-side logs.
Default logging is good for both the client and the management point, but there are some log details that won’t be seen unless verbose and debug logging are enabled. Some of the information that is accessible with this extra level of logging is so useful that it is common practice to configure verbose and debug logging as a standard across the environment. There is additional overhead because more data is written to the logs, but it is minimal and should cause no impact to the operation of the system.
Enabling verbose and debug logging requires two registry changes. First, you enable verbose logging by navigating to
[HKEY_LOCAL_MACHINE\software\microsoft\ccm\logging@global]
and changing the value LogLevel to 0 (which will require a permissions change on the @GLOBAL key). To enable debug logging, create a registry key called DebugLogging directly under
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\Logging]
Inside this registry key create a string value named Enabled and set its value to True.
Software Requirements
Configuration Manager 2012 R2 management points require the following:
· All site servers must be members of a Windows 2003 or higher Active Directory domain.
· IIS 6.0 or higher must be installed.
Troubleshooting a Configuration Manager 2012 R2 Management Point
The Configuration Manager management point is the entry point into a Configuration Manager hierarchy from a client perspective. The client receives its Configuration Manager policies and advertisements from the MP and places its inventories and status there. As with all components, administrators have a choice of using status messages and/or log files to verify management point function.
You can view management point status in the Monitoring node of the console by checking components such as SMS_MP_CONTROL_MANAGER or SMS_MP_FILE_DISPATCH_MANAGER. If you prefer using logs, then the following logs are key to verifying proper management point installation and function:
1. mpMSI.log This is the Microsoft Installer (MSI) log for the management point installation.
2. mpSetup.log This is the site-specific management point log, which shows which site and server the management point is configured to use.
3. mpcontrol.log This log maintains the management point by reviewing and checking the management point availability and status.
Site Database Server
Every Configuration Manager 2012 R2 implementation will have at least one server running the site database server role. The simplest implementation will have a single server running all the Configuration Manager 2012 R2 roles as well as Microsoft SQL Server 2008 Service Pack 1 or higher. As noted earlier, at least one database repository is required to store all the client information and site configurations.
A Configuration Manager 2012 R2 site database server requires the following:
· All site servers must be members of a Windows 2003 or higher Active Directory domain.
· Microsoft SQL Server 2008 Service Pack 1 or higher is the only version of SQL Server supported for hosting the Configuration Manager 2012 R2 database. (There may also be Cumulative Update requirements; for the latest list, check the TechNet documentation.)
· The SQL database service is the only SQL Server component required to be installed to host the site database.
Troubleshooting a Configuration Manager Site Database Server
This is the database server that hosts the Microsoft SQL Server 2008 Service Pack 1 database. There is one database that holds all information about inventory, packages, status, and all the other pertinent data of System Center Configuration Manager 2012 R2. The following logs provide insight into the health of the database server:
1. smsdbmon.log This log shows all activities such as inserts, updates, drops, and deletes from the Configuration Manager 2012 R2 database.
2. smsprov.log This log shows the SQL transaction calls made from the Configuration Manager console or automation scripts via the SDK.
Site Server
A site server is a unique site system role in Configuration Manager. This role cannot be manually added, nor can it be manually removed. This role is managed by the site server itself and will exist on any server that is serving as a site server in the hierarchy. When a site is installed, whether a Central Administration Site, primary site, or secondary site, it will be shown as having the site server role.
This role manages all functions of the site and interacts with all remote systems hosting site system roles for the site. The overall health of the site server role can be reviewed in the Monitoring node of the console and also by examining the site server logs generated.
Site System
A site system is a unique site system role in Configuration Manager. This role cannot be manually added nor can it be manually removed. This role is managed by the site server itself and will exist on any server that is serving as a site system in the hierarchy. The site server itself will always be a site system as will any remote servers that are deployed to host various roles to provide services needed by the site.
The overall health of the site system server can be reviewed in the Monitoring node of the console. The specific nodes to review as well as the specific log files will be dictated by the specific functions being performed by the site system server.
System Health Validator Point
The system health validator point is the Configuration Manager 2012 R2 site system role that runs on Windows Server 2008 and Windows 2008 R2 servers with the Network Policy Server role enabled. Network Policy Servers evaluate clients as they attempt to come on the network and either grant access or deny access depending on whether clients comply with configured policy. The system health validator point is the Configuration Manager add-on to the Network Policy Server that provides the ability to judge whether a given client complies with required patch levels.
In brief,
1. Client health state evaluation proceeds by the client producing a statement of health locally and sending this to the Network Policy Server.
2. When received, the statement of health is evaluated against configured conditions and a resulting client health state is determined. The state may be
· Compliant, resulting in network access
· Noncompliant, resulting in network access being denied until the detected problem is remediated
An error condition may be returned that prevents evaluation.
The system health validator point validates a statement of health using a sequential series of checks. These include the following:
· Time validation when the statement of health was created
· Validation against the health state reference
· Compliance status and failures
The system health validator point never communicates directly with Configuration Manager 2012 R2 site servers to validate client statements of health. When a Configuration Manager Network Access Policy is created or modified or inherited from a parent site, the site server writes a health state reference to Active Directory Domain Services. The system health validator point periodically retrieves the health state references for all Configuration Manager primary sites that are enabled for Network Access Protection (NAP).
Because Active Directory Domain Services is used to store the health state references, the Active Directory schema must be extended with the Configuration Manager 2012 R2 extensions. The health state reference is published to a System Management container in Active Directory, which requires that Configuration Manager 2012 R2 publish site information to Active Directory Domain Services. When there is more than one Active Directory forest and your Configuration Manager site servers and system health validator points are not in the same forest, you must designate which forest and domain will store the health state references.
If the system health validator point role has not yet been added, it will need to be selected. Until now components have been installed on just the site server system. In production it is unlikely that the site server will also act as a Network Policy server, so configuring this role will likely require creating a new site system server to host the role. The new site system server should be the server hosting the Network Policy server components in the environment.
1. In the Add Site System Roles Wizard select to add the System Health Validator point role.
2. Click Next to proceed to the System Health Validator page of the wizard. There are no properties to configure on this page.
3. Simply complete the wizard to install the component.
Software Requirements
Configuration Manager 2012 R2 system health validator points require that all site servers be members of a Windows 2003 or higher Active Directory domain.
Troubleshooting a Configuration Manager 2012 R2 System Health Validator Point
Within the entire Network Access Protection scenario, this role allows the infrastructure to validate the statement of health from a NAP-capable Configuration Manager client. For troubleshooting, use the SMSSHVSetup.log file, which documents the prerequisite and installation progress.
State Migration Point
Think of the state migration point role as a reverse distribution point. The state migration point is a Configuration Manager site system role that provides a secure location to store user state information as part of an operating system deployment. User state is stored on the state migration point while the operating system deployment proceeds and is then restored from the state migration point to the new computer at the appropriate time during imaging. Each state migration point site server can be a member of only one Configuration Manager 2012 R2 site, but each site may have multiple state migration points if needed.
If the state migration point role has not yet been added, you will need to select it, as shown in Figure 4.54.
1. Choose the site where the state migration point will be located, and select the role in the Add Site System Roles Wizard.
2. Click Next to proceed to the State Migration Point page of the wizard, shown in Figure 4.55.
Figure 4.55 Add Site System Roles Wizard: State migration point selected
Figure 4.56 Add Site System Roles Wizard: State Migration Point page
This page allows configuration of the state migration point.
3. First, choose the folder that will host user data sent to the state migration point.
This includes choosing the drive, the folder name, the maximum number of clients that may be served by the state migration point, and also the minimum amount of disk space that should be reserved.
4. Configure the Deletion Policy to show how long user state data is held following a successful operating system deployment before being deleted.
This raises an important point. When user state data is stored on the state migration point, it is with the intention that the state data will be restored to either the same system or a different system as imaging nears completion. If the state data is never restored, it is never marked as eligible for deletion because there might have been problems during the imaging process, and allowing deletion would remove potentially needed data from the system. This is particularly true if the deletion settings specify to remove data immediately.
5. Finally, flag the state migration point as being in restore-only mode.
This special setting, disabled by default, allows administrators to configure a state migration point so that it doesn’t receive new state data but is available for use in already stored state data. Typically you would set this option if you have a state migration point server that is scheduled for maintenance or replacement; you could also use this option if you are building a new state migration point but you don’t want it to go into service yet.
6. Once the configuration settings are complete, click Next to proceed to the Boundary Groups page of the wizard, shown in Figure 4.57.
Figure 4.57 Add Site System Roles Wizard: Boundary Groups page
Like the distribution point, the state migration point needs to be added to an appropriate boundary group to make it available for use by clients. If the state migration point is being installed on a server that already hosts the distribution point role, then the boundary group may be prepopulated.
7. Make any needed changes and click Next to continue through the wizard and finish up.
Software Requirements
Configuration Manager 2012 R2 state migration points must be members of a Windows 2003 or higher Active Directory domain.
Troubleshooting a Configuration Manager 2012 R2 State Migration Point
This role is leveraged during the operating system deployment. In particular, it is used to store user data for migration back onto their machine that was just reimaged or replaced. The health of the state migration point is visible in the Monitoring node of the console and also by reviewing the following logs:
1. smssmpsetup.log This log documents the appropriate prerequisites and logs the initialization of the smp.msi file and installation completion.
2. smpmsi.log This log documents the installation setup progress of the smp.msi file.
Fallback Status Point
The fallback status point role helps address today’s greater security requirements while enabling a mechanism to catch clients that are not communicating properly. When deploying clients it is critical to know if problems are being encountered. Typically these problems are reported to the management point in the form of status or state messages. When installing the client, there is a time when it is not possible to send data to the management point. In addition, there may be problems reaching the management point even after install. In such cases, if the client does not have a mechanism to notify the site of problems, it will become orphaned and unusable. The fallback status point role provides an administrator with insight into the installation and management of a client and works well because the location of the fallback status point is configurable on the command line when client installation is initiated.
A fallback status point is similar to a proxy server that proxies client status messages up to the site server. Two types of messages may occur: the normal messages that appear during client installation and assignment or those identifying unhealthy Configuration Manager 2012 R2 clients. In either scenario, the fallback status point fills the gap and shows the administrator that there are client issues that need to be addressed.
Because of the potential security threat of an unknown client or client status, it is recommended that the fallback status point be placed outside a physical site server. It can be a low-end server, because of the relatively small number of potential requests it should receive. As in any design decision, the criteria of scale versus risk should be investigated before a decision is made.
Through detailed reporting, an administrator can gain knowledge and take proactive measures to ensure that availability remains in its highest state. These reports include detailed client information on capable and incapable client communication.
Installation of a fallback status point is not a requirement for a site but it is recommended. Typically there is one fallback status point installed per site that hosts clients.
If the fallback status point role has not yet been added, you will need to select it.
1. Choose the site where the fallback status point will be located, and select the status point in the Add Site System Roles Wizard.
2. Click Next to proceed to the Fallback Status Point page of the wizard, shown in Figure 4.58.
Figure 4.58 Add Site System Roles Wizard: Fallback Status Point page
There is little configuration to be done for the fallback status point. The only option is to configure the number of state messages that are allowed to be processed during the given time window. Typically the default values are fine.
3. Make any needed changes, and click Next to complete the wizard.
Software Requirements
Configuration Manager 2012 R2 fallback status points require that all site servers be members of a Windows 2003 or higher Active Directory domain.
Troubleshooting the Fallback Status Point
The fallback status point is meant for clients that are having difficulties communicating with a Native mode Configuration Manager hierarchy. To provide insights into the proper configuration of this role, the component status is available in the Monitoring node of the console and also by reviewing the following logs:
1. SMSFSPSetup.log This log documents the prerequisites and kicks off the fsp.msi installation.
2. fspMSI.log This log provides the installation status of the fallback status point role.
Out of Band Service Point
The out of band service point is the site system role that serves as the management interface between Configuration Manager and client systems that are operating with Intel’s Active Management Technology (AMT) vPro chipset, a technology available in workstation-class systems.
Intel is the first hardware vendor to provide direct hardware interactions to leverage Windows Remote Management capabilities. These capabilities include remote boot control, forced PXE boots, remote network boots, and direct inspection of the hardware inventory and power state. AMT is even able to wake a machine from sleep state if needed! A goal of this technology is to empower full system management without the expense of desktop visits. These capabilities become very attractive when addressing geographically dispersed branch offices where there is little or no support staff to physically remediate workstations. Since Configuration Manager is the world-class systems management suite, the inclusion of AMT as a capability just makes sense.
Before a system is able to be managed, it must be provisioned. In Configuration Manager 2007, a provisioning process known as out-of-band provision was supported, a process that allowed a workstation to be configured even without an installed operating system. Configuration Manager 2012 R2 supports in-band provisioning only—meaning that a Configuration Manager 2012 R2 client needs to be installed and assigned to a site. Provisioning also requires the use of certificates. The out of band service point is the focus of activity during provisioning because it connects to and interacts with AMT-capable systems.
Setting up Configuration Manager/AMT integration and management requires several steps. One of the first steps in the process is to install an out of band service point. One out of band service point will be needed at each primary site that provides AMT management. If the role has not yet been added, you will need to select it in the Add Site System Roles Wizard.
1. Choose the site where the out of band service point will be located, and select the service point in the Add Site System Roles Wizard.
2. Click Next to proceed to the AMT Service Point page of the wizard, shown in Figure 4.59.
Figure 4.59 Add Site System Roles Wizard: AMT Service Point page
3. On the AMT Service Point page, configure the number of retry attempts that should be made, along with the delay between retries, when attempting to connect to an unresponsive AMT system.
You can also specify the maximum number of transmission threads between the out of band service point and AMT-equipped systems on this page. If AMT is heavily utilized, it may be appropriate to change the default settings. If you make changes, however, take care to ensure the performance of the host system is not adversely affected.
The transmission offset is the last setting on this page and defines how long before any scheduled activity, such as scheduled software distribution, an AMT system wake-up command should be sent. This is an important feature of AMT and should be considered along with Configuration Manager Wake On LAN capabilities.
4. Adjust configurations as needed, and click Next to proceed to the AMT Provisioning Certificate page, shown in Figure 4.60.
Figure 4.60 Add Site System Roles Wizard: AMT Provisioning Certificate page
5. On the AMT Provisioning Certificate page, browse to the provisioning certificate that will be used and import it.
A provisioning certificate will be used for validation when connecting to AMT-enabled systems and initializing the provisioning process.
6. Choose whether to enable CRL checking for the AMT provisioning certificate, and then click Next.
Configuration Manager 2012 R2 out of band service points require that all site servers must be members of a Windows 2003 or higher Active Directory domain.
Reporting Services Point
The Reporting Services point provides integration between Configuration Manager and SQL Server Reporting Services (SSRS) to facilitate report publishing and rendering. This is a big change in Configuration Manager 2012 R2; the reporting engine available in previous versions of Configuration Manager, classic reporting, is gone. SSRS integration was first introduced in Configuration Manager 2007 R2 and was available in parallel to classic reporting, providing customers time to adjust to the new (and long overdue!) approach to reporting.
SSRS integration just makes sense. Most people don’t enjoy reading through line after line of tabular reports and would prefer to encapsulate that same data in a graphical format. SSRS can handle most any reporting scenario with ease.
If the SSRS role has not yet been added, you will need to select it in the Add Site System Roles Wizard.
1. Choose the site and server where the Reporting Services point will be located.
If a Central Administration Site is in place, then it is a good choice as a site to host this site system role. It is also possible to install this role on a primary site or to install it in multiple locations. Which options you choose depends on the overall configuration of the hierarchy and reporting needs.
2. Select the role in the Add Site System Roles Wizard. Click Next to proceed to the Reporting Service Point page of the wizard, shown in Figure 4.61.
Figure 4.61 Add Site System Roles Wizard: Reporting Services Point page
3. On the Reporting Services Point page, provide the server name that is hosting the Configuration Manager database instance and also the database name.
The server listed here can be the same server hosting the Reporting Services server instance or a remote server.
4. Click Verify to confirm connectivity.
5. Then configure the reporting server component by providing the folder name where the reports will be stored along with the specific SQL Server instance hosting the Reporting Services and the authentication method that will be used for security validation.
Note that for this section there is no option to specify a server name because it is assumed the site system where the role is being configured is the server hosting the SSRS instance.
6. Once these configurations are complete, click Next.
Software Requirements
The Configuration Manager 2012 R2 Reporting Services point requires that all site servers be members of a Windows 2003 or higher Active Directory domain.
Troubleshooting the Reporting Services Point
The Reporting Services point is the reporting engine for Configuration Manager 2012 R2 and is a key role for most users. Ensuring this role installs and functions correctly is also critical. To provide insight into the proper configuration for this role, the component status is available in the Monitoring node of the console and also by reviewing associated log files.
1. srsrpsetup.log This log tracks the setup status of the reporting point.
2. srsrpMSI This log provides detail status of the reporting point setup process.
3. srsrp.log This log tracks ongoing operational health of the reporting point.
Application Catalog Web Service Point and Application Catalog Website Point
A significant change in Configuration Manager 2012 R2 is its user-centric focus. One component of user-centric focus, and a feature that has been much anticipated, is the ability for users to browse a web page–hosted catalog of published applications available for installation in the environment. These published applications may either be available without restriction to users or configured to require administrative approval prior to installation. Only software deployed to users will appear in the Application Catalog.
Two site system roles work in tandem to provide the Application Catalog service: the Application Catalog web service point and the Application Catalog website point. At first glance, the difference between these two site system roles may not be apparent.
1. Application Catalog Website Point The Application Catalog website point is the site system providing the software catalog service to users.
2. Application Catalog Web Service Point The Application Catalog web service point is the site system role that serves as a connection point between the Application Catalog web service point site systems and the Configuration Manager site, providing software information to the website for presentation to users.
About the Example
For the example, the Application Catalog web service point and the Application Catalog website point are presented together. It should not be implied, however, that these site system roles will necessarily be configured on the same server in all cases. While both site system roles are required to facilitate Software Catalog services, they are not required to be configured together.
If the Application Catalog website point and Application Catalog web service point roles have not yet been added, you will need to select them in the Add Site System Roles Wizard, as shown in Figure 4.62.
Figure 4.62 Add Site System Roles Wizard: Application Catalog website point and Application Catalog web service point selected
1. Choose the site and server where the Application Catalog website point and Application Catalog web service point will be located.
The exact servers chosen depend on the overall configuration of the hierarchy and mobile management needs.
2. Select the roles in the Add Site System Roles Wizard. Note that the order of the next couple of figures could be different depending on how you choose to install the roles. The net result is the same.
3. Click Next to proceed to the Application Catalog Website Point page of the wizard, as shown in Figure 4.63.
Figure 4.63 Add Site System Roles Wizard: Application Catalog Website Point page
4. On the Application Catalog Website Point page, configure the name for the website to be used.
Also note the web application name suggested. If the name of the web application is modified on the Application Catalog Web Service Point page, this URL will need to be modified accordingly.
5. Also on this page, choose whether the website will support HTTP or HTTPS traffic and, if HTTPS is selected, whether the website will allow only intranet-connected clients or also allow Internet-connected clients.
Supporting Internet clients requires the use of certificates. In addition, if mobile devices will be supported in the environment, enabling the website to support HTTPS-connected clients is required.
6. Once all configuration is complete, click Next to proceed to the Application Catalog Website Point page, as shown in Figure 4.64.
Figure 4.64 Add Site System Roles Wizard: Application Catalog Website Point page
7. On the Application Catalog Website Point page, configure the web application name for the website to be used and whether the website will use HTTP or HTTPS.
8. Once all configuration is complete, click Next to proceed to the Application Catalog Customizations page. Here administrators are able to provide some minor customization as to the presentation of the catalog (organization name and website theme). Make any modifications desired and click Next to complete the wizard.
Software Requirements
The Configuration Manager 2012 R2 Application Catalog website point and Application Catalog web service point require the following:
· All site servers must be members of a Windows 2003 or higher Active Directory domain.
· .NET 4.0 must be installed.
Troubleshooting the Application Catalog Website Point and Application Catalog Web Service Point
The Application Catalog roles are key interfaces to enable user self-provisioning of content. Thus, ensuring that these roles are functional is critical. As with all roles, the Monitoring node of the console can provide insight into overall health. In addition, log files are useful to track ongoing operation as well:
1. smsawebsvcsetup.log This log tracks the installation of the application web service.
2. smsportwebsetup.log This log tracks installation of the application web portal.
3. awebsvcMSI This is a detailed MSI log to track installation of the application web service.
4. portalwebMSI This is a detailed MSI log to track installation of the application web portal.
5. awebsctrl.log This log tracks the ongoing operation of the application web service.
6. portlctl.log This log tracks the ongoing operation of the application web portal.
Enrollment Point and Enrollment Proxy Point
Mobile devices have become commonplace in IT environments. With the increase in device number and increasing power and function of these devices, providing management capabilities in the enterprise is becoming more of a focal point for administrators. Configuration Manager 2012 R2 provides two types of management for mobile devices: lite management and depth management.
1. Lite Management Lite management is provided to any device that is capable of interfacing with Exchange Server through the ActiveSync connector. Such devices include Windows Phone 7 and iPhone and Android devices. Configuration Manager 2012 R2 provides an Exchange Server connector that works with Exchange ActiveSync–connected devices and facilitates settings management, general inventory, and remote wipe capabilities.
2. Depth Management Depth management is available for legacy Windows phone platforms, such as Windows Mobile 6.1 and 6.5 as well as Nokia Symbian devices, and it allows for a more robust management experience, including the ability to install a native Configuration Manager 2012 client on a device. Depth-managed devices provide all of the features of lite management (though not through Exchange ActiveSync) but also include support for software distribution and over-the-air enrollment. Further, inventory options available for depth-managed clients are more extensive and flexible than those provided through lite management.
Depth-managed devices require a client to be installed, along with certificates to provide access to the various Configuration Manager 2012 R2 systems. Once the client is installed, the device acts similar to a PC, looking up and making use of management points for retrieving policy, sending data such as inventory, and also making use of distribution points for software deployments.
Site Systems and Mobile Devices
Site systems that will interact with mobile devices must be configured to support HTTPS communication. Mobile devices use certificates for authentication and must be able to use these certificates to validate against management points and distribution points (and optionally, Application Catalog servers).
The process of placing the client and certificates on the mobile device, known as enrollment, requires the use of two site system roles: the mobile device enrollment proxy point and the mobile device and AMT enrollment point. These site systems work in tandem to facilitate enrollment, provisioning, and management of mobile devices. At first glance, the difference between these two site system roles may not be apparent.
1. Enrollment Proxy Point This is the site system role typically placed in the DMZ and is the initial point of communication for devices. It is also the location where mobile devices find and download the mobile version of the Configuration Manager client. Once the client is installed, and as a part of enrollment, the mobile device enrollment proxy point will communicate with the mobile device and AMT enrollment point, typically located inside the protected network, to retrieve needed certificates and present them to the device being enrolled.
2. Configuring multiple mobile device enrollment proxy points at a single site to support multiple DMZ configurations is supported.
3. Enrollment Point This is a site system role typically installed inside the protected network, and it serves as an interface between the mobile device enrollment proxy point and the Enterprise Certificate Authority as certificate requests are presented from mobile devices and generated certificates are sent back to mobile devices.
Certificates are also required for provisioning AMT-capable devices. This site system role also serves as the interface between AMT devices requesting certificates and the Enterprise Certificate Authority.
Tidbits about Site System Roles
It is not required that these site system roles exist on the same site system server. If you’re using lite management of mobile devices, neither of these site system roles is required.
About the Example
For the example, the mobile device enrollment proxy point and mobile device and AMT enrollment point are presented together. It should not be implied, however, that these site system roles will necessarily be configured on the same server in all cases. While both site system roles are required to facilitate depth management of mobile devices, they are not required to be configured together.
If the enrollment proxy point or the enrollment point roles have not yet been added, you will need to select them in the Add Site System Roles Wizard.
1. Choose the site and server where the enrollment proxy point and enrollment point will be located.
The exact servers chosen depend on the overall configuration of the hierarchy and mobile management needs.
2. Select the roles in the Add Site System Roles Wizard System Role Selection. Click Next to proceed to the Enrollment Point page of the wizard.
3. On the Enrollment Point page, shown in Figure 4.65, configure the name for the website to be used.
Figure 4.65 Add Site System Roles Wizard: Enrollment Point page
If you make any changes, then the virtual directory name in the URL configured for the mobile device enrollment proxy point must be updated as well. You can also specify which account will be used for database communication. Of the two site system roles, this is the only one that needs to access the database directly.
4. On the Enrollment Proxy Point page, configure the name for the website to be used, as shown in Figure 4.66.
Figure 4.66 Add Site System Roles Wizard: Enrollment Proxy Point page
Note that the website must support SSL communication and that a default URL pointing to the mobile device and AMT enrollment point is already present. This URL is configurable and will need to point to whichever location is chosen to host the mobile device and AMT enrollment point role. Note also that the end of the URL refers to the EnrollmentService virtual directory. This is the default name. If a non-default name is chosen for the virtual directory, the URL will need to match.
Note also that there is a virtual application name listed on the current page that is similar in name. Don’t be confused by the similarity; the virtual directory name here is the one used to configure the mobile device enrollment proxy point and is not changeable.
5. Once all configuration is complete, click Next.
Software Requirements
The Configuration Manager 2012 R2 mobile device enrollment proxy point and mobile device and AMT enrollment point require that all site servers be members of a Windows 2003 or higher Active Directory domain.
Troubleshooting the Enrollment Proxy Point and Enrollment Point
Enrollment points are the key roles to enable mobile devices and AMT-enabled systems to enter into the ConfigMgr world. To provide insights into the proper configuration of this role, the component status is available in the Monitoring node of the console and also by reviewing the following logs:
1. Smsenrollwebsetup.log This log tracks the installation of the enrollment web proxy point.
2. Smsenrollsrvsetup.log This log tracks the installation of the enrollment web point.
3. Enrollwebmsi This log tracks the installation of the enrollment web proxy point in detail.
4. Enrollsrvmsi This log tracks the installation of the enrollment web service point in detail.
5. Enrollweb.log This log tracks the ongoing operation of the enrollment web point.
6. Enrollsvc.log This log tracks the ongoing operation of the enrollment web proxy point.
Click Next to proceed to the Summary page of the Add Site System Roles Wizard. Review the settings. If all are correct, click Next to proceed with installation and to finish the wizard.
Software Update Point
The software update point role is integral to the software update mechanism and is responsible for synchronizing all patches from Microsoft Update and making them available in the Configuration Manager 2012 R2 interface for deployment. The software update point requires that Windows Software Update Services 3.0 SP2 be installed on the same server where the software update point is being installed and requires that the instance of WSUS be dedicated to interfacing with the software update point and providing service to Configuration Manager. No sharing allowed! Also, administrators should not perform any administrative work on the WSUS server itself. All administrative work should be done through the Configuration Manager console. You will find that the options available in the Configuration Manager console are very similar to what are found in WSUS itself.
If the software update point has not yet been added, you will need to select it in the Add Site System Roles Wizard, as shown in Figure 4.67.
Figure 4.67 Add Site System Roles Wizard: System Role Selection page with Software Update Point selected
1. Choose the server where the WSUS component is installed.
2. Select the role in the Add Site System Roles Wizard.
3. Click Next to proceed to the Software Update Point page of the wizard.
4. On the Software Update Point page, configure whether to use ports 80 and 443 for client communications or the customized 8530 and 8531. Determine what kind of client connection type you expect, whether they are intranet-only, Internet-only, or both. Click Next to proceed to the Proxy and Account Settings page of the wizard.
5. A proxy server should be used when synchronizing software updates and also when downloading content with auto deployment rules. Also, choose whether alternate credentials will be used to connect to the WSUS server. If a proxy server is needed, supply the needed information for the proxy server. This is shown in Figure 4.68.
Figure 4.68 Add Site System Roles Wizard: Proxy and Account Settings page
6. Once all configuration is complete, click Next to proceed to the Synchronization Source page of the wizard, shown in Figure 4.69. If software update services will be used in Configuration Manager, at least one software update point is required. Note that a single software update point on properly sized hardware is capable of supporting 100,000 clients in Configuration Manager 2012 R2.
Figure 4.69 Add Site System Roles Wizard: Synchronization Source page
7. On the Synchronization Source page, configure the location that the software update point will use for obtaining update information. Typically this setting will be to synchronize from Microsoft Update from the Internet.
If this software update point is installed at a child site in a hierarchy, then the option to choose here will be to synchronize from an upstream update point. In this case the CAS would host the top-level software update point and the primary site would synchronize from it.
If the software update point is on the CAS and the CAS does not have access to the Internet, then it’s possible to synchronize manually. If this is the case, choose the option Do Not Synchronize From Microsoft Update Or Upstream Data Source.
8. In the WSUS Reporting Events section, choose whether or not to create any or all WSUS reporting events.
9. Once all configuration is compete, click Next to proceed to the Synchronization Schedule page. Choose whether or not synchronization should proceed on a schedule. It is not required that the software update point be configured to synchronize automatically, but in most environments a recurring schedule is ideal. The schedule is up to you; just remember that Microsoft publishes new patches the second Tuesday of every month and from time to time will have out-of-band patch releases. If you are using Endpoint Protection in Configuration Manager, it is recommended to perform synchronization no less than daily (or as often as three times per day).
10.If you would like an alert when synchronization fails (a good idea), select that option as well.
11.Once all configuration is complete, click Next to proceed to the Supersedence Rules page shown in Figure 4.70.
Figure 4.70 Add Site System Roles Wizard: Supersedence Rules page
12.On the Supersedence Rules page, choose the behavior that happens when a new update is available and synchronized that replaces an existing update. This option is new to Configuration Manager 2012. The first option, Immediately Expire A Superseded Software Update, is the default, and this was the only option in Configuration Manager 2007. This option caused frustration in many environments—not because an update was superseded, but because the action of superseding also caused the original update to be expired. When an update is expired it can no longer be deployed. While it is a good idea to stop deploying a superseded update when it has been replaced, the truth is that testing cycles in many environments do not easily allow for this kind of rapid change. For that reason, the second choice (Months To Wait Before A Superseded Software Update Is Expired) was made available in Configuration Manager 2012 R2. Note that the superseded update is still superseded; it just isn’t expired and can still be deployed.
13.Once all configuration is complete, click Next to proceed to the Classifications page shown in Figure 4.71.
Figure 4.71 Add Site System Roles Wizard: Classifications page
14.On the Classifications page, choose the classifications of updates that should be retrieved from Microsoft Update and made available in Configuration Manager 2012 R2 for deployment.
15.Once all configuration is complete, click Next to proceed to the Products page shown in Figure 4.72.
Figure 4.72 Add Site System Roles Wizard: Products page
16.On the Products page, choose the products or product families that should be included when retrieving updates from the categories just configured. The expanded list is shown in the figure.
17.Once all configuration is complete, click Next to proceed to the Languages page. Here, choose all languages that are in use in your environment. This will ensure the appropriate language-specific patches are included during synchronization as well.
18.Once all configuration is complete, click Next and proceed through the remaining wizard pages to complete the configuration.
Software Requirements
The Configuration Manager 2012 R2 software update point requires that all site servers must be members of a Windows 2003 or higher Active Directory domain. In addition, the software update point requires WSUS 3.0 SP2 and Internet Information Services to be installed. It’s also a good idea to install WSUS 3.0 SP2 hotfixes KB2720211 and KB2734608 (in that order) to ensure stability and performance in WSUS and your software update point.
Troubleshooting the Software Update Point
The proper installation of the software update point is key to delivering updates through Configuration Manager 2012 R2 in your environment. To provide insights into the proper configuration of this role, the component status is available in the Monitoring node of the console and also by reviewing the following logs:
1. Supsetup.log This log tracks the installation of the software update point.
2. WCM.log This log tracks connections to the WSUS server for subscribed update categories, languages, and classifications.
3. WSUSCtrl.log This log tracks connectivity to the database and the general health of WSUS for the site.
4. WSYNCMGR.log This log records all synchronization operations for the site.
Endpoint Protection Point
If you will be using Configuration Manager 2012 R2 for Endpoint Protection services, then you must install the Endpoint Protection point role. This role is available only at the CAS and requires that separate licensing be in place. Installing this role is very easy and simply enables the use of Endpoint Protection in the hierarchy.
If the Endpoint Protection point has not yet been added, you will need to select it in the Add Site System Roles Wizard:
1. Choose the server where the Endpoint Protection point will be located.
2. Select the role in the Add Site System Roles Wizard. Note that when you attempt to place a check mark in the role, you will see a popup notifying you of default configurations that will be set.
3. On the Endpoint Protection page, accept the license agreement.
4. Once all configuration is complete, click Next to proceed to the Microsoft Active Protection Service page, shown in Figure 4.73.
Figure 4.73 Add Site System Roles Wizard: Microsoft Active Protection Service page
5. On the Microsoft Active Protection Service page, read the description of the Active Protection Service membership, and choose what type of membership you would like, if any.
6. Once all configuration is complete, click Next through the wizard to complete installation.
Software Requirements
The Configuration Manager 2012 R2 Endpoint Protection point requires that all site servers be members of a Windows 2003 or higher Active Directory domain.
Troubleshooting the Endpoint Protection Point
The proper installation of the Endpoint Protection point is key to managing malware and firewall settings through Configuration Manager 2012 R2 in your environment. To provide insights into the proper configuration of this role, the component status is available in the Monitoring node of the console and also by reviewing the following logs:
1. EPsetup.log This log tracks the installation of the Endpoint Protection point.
2. EPCtrlmgr.log This log details the synchronization of malware threat information from the Endpoint Protection role server to the Configuration Manager 2012 R2 database.
3. EPMgr.log This log monitors the status of the Endpoint Protection site system role.
Asset Intelligence Synchronization Point
If you will be using Configuration Manager 2012 R2 for Asset Intelligence information, then you will likely want to install the Asset Intelligence synchronization point role. This role is available only at the CAS and is not required but is beneficial. Installing this role enables synchronizing of catalog updates from the Internet and also allows you to upload custom catalog requests and categorization information to Microsoft.
If the Asset Intelligence synchronization point has not yet been added, you will need to select it in the Add Site System Roles Wizard.
1. Choose the server where the Asset Intelligence synchronization point will be located.
2. Select the role in the Add Site System Roles Wizard.
3. On the Asset Intelligence Synchronization Point Settings page, select whether to use this system as the active system and, if you have a certificate, the UNC path where it can be found. Note that the use of a certificate is not required. This is shown in Figure 4.74.
Figure 4.74 Add Site System Roles Wizard: Asset Intelligence Synchronization Point Settings page
4. Once all configuration is complete, click Next to proceed to the Specify The Synchronization Schedule page. Here, configure the schedule you would like to use for synchronizing the catalog and also sending your update requests for the catalog to Microsoft. Typically, the default schedule is appropriate.
5. Once all configuration is complete, click Next through the wizard to complete installation.
Software Requirements
The Configuration Manager 2012 R2 Asset Intelligence synchronization point requires that all site servers be members of a Windows 2003 or higher Active Directory domain.
Troubleshooting the Asset Intelligence Synchronization Point
The proper installation of the Asset Intelligence synchronization point is key to keeping your Asset Intelligence catalog up to date for use in Configuration Manager 2012 R2. This is also critical to communicate your requested updates to the catalog to Microsoft. To provide insights into the proper configuration of this role, the component status is available in the Monitoring node of the console and also by reviewing the following logs:
1. AIUSsetup.log This log tracks the installation of the Asset Intelligence synchronization point.
2. AIUSMSI.log This log tracks the specific MSI installation process detail for the Asset Intelligence synchronization point.
3. AIUpdateSvc.log This log tracks the ongoing operation of the Asset Intelligence synchronization point.
The Bottom Line
1. Understand Configuration Manager 2012 R2 sites and the new approach to hierarchy design. Configuration Manager 2012 R2 has three types of sites: the Central Administration Site, which is new, and the primary and secondary sites, which are familiar. Although two of the three site types are familiar, their use and approach to hierarchy design—or whether a hierarchy is needed at all—are quite different now.
1. Master It Describe the purpose of each site type and map each to specific management needs.
2. Construct a Configuration Manager 2012 R2 hierarchy. The site hierarchy in Configuration Manager 2012 R2 consists of the site types just described. The approach to design is very different from the previous version, with the number of primary sites being limited to a single tier. The chapter walked through configuring a hierarchy with all three site types.
1. Master It Describe a Configuration Manager 2012 R2 site hierarchy. Detail components needed for site-to-site communication and security settings.
3. Determine when to expand a hierarchy and when to simply add a site system role for additional service. A major design goal of Configuration Manager 2012 R2 is simplified hierarchy design. Administrators familiar with previous versions of Configuration Manager may be tempted to retain old hierarchy approaches when designing Configuration Manager 2012 R2. Taking such an approach will often lead to inefficient designs and additional server cost and in some cases simply won’t work.
1. Master It Understand the changes in sites and site components that lend themselves to hierarchy simplification and enable parity management with fewer site servers.
4. Deploy and configure the various site system roles available per site. There are many roles available to enable management at a site. Understanding each role and the service it delivers is critical to getting the most out of an investment in Configuration Manager 2012 R2.
1. Master It Review critical system roles and understand the services that are enabled through each.