7 min read

(For more resources related to this topic, see here.)

Now it’s down to the real deal—the bits and bytes. In this article, we will go through different roles and services and how they can be deployed as highly available for the clients. We will also walk through some examples of how a simple site design might look like for different scenarios.

First, let’s take a look at roles within Configuration Manager that cannot be deployed as highly available and what options we have.

It is important to note that when installing a site system role on another server Configuration Manager, the installation files are installed on the first available NTFS disk with maximum available disk space. If you wish to exclude a disk, create an empty file called no_sms_on_drive.sms on the root folder of the drive. Also, Configuration Manager uses the site server computer account to try to install the role on a remote server (so, this account needs to be added to local administrator on the server) unless we specify a domain account (which also needs to be a local admin) when we run the setup.

Site Server

The first and foremost important role that cannot be deployed as highly available is the Site Server role. It does not support network load balancing or other clustering features available in Windows Server. In order to make sure that you can restore the site in case of disaster, you have to use the built-in backup tasks.

Endpoint Protection

The Endpoint Protection role allows for management of endpoint protection agents.

If this role is unavailable for the clients, they will still continue to run as before but you cannot update the policy centrally. This role is not seen as critical for Configuration Manager and cannot be deployed as highly available. If something happens to your endpoint server, just reinstall the role on another server. It is important to know that this role can only be deployed once at the top of your hierarchy; so, if we have a CAS, we would place this role there. Same is true if we have a standalone primary site with secondary sites.

Asset Intelligence Synchronization Point

The Asset Intelligence Synchronization Point role connects to System Center online (a cloud service from Microsoft) in order to update the asset catalog with the latest information. If this role becomes unavailable, the site will just store data locally until it becomes online and is able to synchronize again. This role cannot be deployed as highly available, and it is important to note that this role can only be installed on the CAS role (if present) or on a standalone primary site as well.

Fallback Status Point

The Fallback Status Point role is used to monitor client deployments and the clients that are unable to connect to their management point, or if there is something wrong with the management point. All communication between clients and this role happens over regular HTTP requests and therefore this role should be placed on a standalone server.

All status messages that get sent to the Fallback Status Point role will be registered in the logfiles fspisapi.log and fspmgr.log.

This role is not considered critical and cannot be deployed as highly available.

It is important to note that clients can only be assigned to one fallback point and the assignment happens during client installation.

Out of Band Service Point

The Out of Band Service Point role is used to manage and provision clients which have Intel vPRO or Intel AMT functionality, which allows Configuration Manager to manage clients before the operating system is active.

This role cannot be deployed as highly available.

Secondary sites

Secondary sites by default contain one distribution point and one management point, and as mentioned previously, should only be used when you need control on how data is moved up the hierarchy.

A secondary site does not support more than one management point. Data for a secondary site is primarily located in the primary site database. You can recover a secondary site by reinstalling it from its primary site.

Windows Intune Connector

The Windows Intune Connector role is a new role with Service Pack 1. It allows for mobile management from Configuration Manager using Windows Intune. This role can only be installed once and it needs to be in the top-level site in the hierarchy.

So, now that we have covered the roles that cannot be deployed as highly available, let us go forward with the roles that we can deploy as highly available.

Management Point

The Management Point role is used by clients for policy downloads, data reporting, and is the primary role for client-to-site communication.

When a client is assigned to a site (depending on how you have defined the client installation parameters), it will download a list of all the available management points in the site and get assigned to an appropriate one. The clients will connect to another management point if one of the following happens:

  • Client restarts
  • Network changes
  • 25 hours have passed
  • The contact with its primary management point is lost

It will also check if the management point is Intranet-only or is available from the Internet, and if it communicates using HTTP or HTTPS. (Remember that if the management point is set up on the Internet, only HTTPS traffic is allowed.)

Now besides manual installation, clients will look for a management point within one of the following locations if something from one of the points mentioned above happens:

When installing a client manually, you can append the parameters CCMSetup.exe /mp:MPFQDN SMSSITECODE=SITECODE FSP=FSPFQDN. to define which management point to contact, which site to register to, and which FSP to contact.

  • Site information: After a client has successfully signed up with a site, it will download a list of available management points which it stores in its cache. If it does not have any other management point available, it will continue looking in other locations.
  • Active Directory: This only applies if you have extended the schema. Configuration Manager can publish management points directly under System Management Container with the site code. (This can be disabled under Administration | Sites | Site Properties | Configure Site Components | Management Point.)

Extending the schema expands the Active Directory schema with specific Configuration Manager attributes. This allows clients to locate specific Configuration Manager server roles such as Management Points, boundaries, and its site from Active Directory. This is an irreversible action, but it allows for clients to easily locate site resources.

The site code and the management points that are available within the site will be stored under Active Directory Users and Computer | Domain | System | System Management. As you can see in the following screenshot, the clients will look here if there is another management point available within this container:

  • DNS: Clients will write a DNS query for service locator point record within the current domain. All management points will appear within the DNS zone as a prefix _mssms_mp_SITECODE, with a port number, and which host it is pointing to. These DNS records can also be automatically be published by Configuration Manager and can be disabled from the same location as Active Directory publishing. The following screenshot shows the DNS zone showing management point:

  • WINS: If your organization is using WINS, Configuration Manager can also publish site information there as well.

If a client manages to find another management point within one of the locations mentioned in the preceding list, it will try to establish a connection with it.

By installing multiple management points within a site, you will gain redundant communication points for the clients within a site. Since clients have multiple places to get the information, you have multiple fallback points. There is no extra configuration required for the management points to become highly available after they are installed.

It is also important to note that by default the management point talks directly to the site database server, to query for data and to publish data. If we want to reduce the CPU processing against the site database, we can set up a management point against a SQL replica. This requires that we set up a site server database with the same SQL replication installed for the site replica database.

When we set up this management point, we will always query the replica database for information, but since the replication happens one-way (site to replica) the management point will always need to contact the site database to write data to the site. But we can set up multiple management points to talk to the SQL replica server, this will help to offload the site-server database.

Summary

In this article, we went through different roles of Configuration Manager and how we can deploy them as highly available.

Resources for Article:

Further resources on this subject:

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here