Configuring SCCM with UAG DirectAccess (Part 2)

If you would like to read the first part of this article series please go to Configuring SCCM with UAG DirectAccess (Part 1).

Introduction

If you already have a healthy UAG DirectAccess environment and an internal SCCM hierarchy, it should be relatively easy to make SCCM work with your DirectAccess clients. In Part 1 of this series, we looked in detail at how DirectAccess clients make their connections. In Part 2, we’re going to walk you through the steps of setting up SCCM to work seamlessly with DirectAccess. Those steps include:

1. Configuring proper firewall rules for the DA clients
2. Adding the SCCM servers and systems to the “Infrastructure Servers” list
3. Assessing SCCM feature support based on your DA configuration
4. Preparing for potential problems and issues with using SCCM to manage DA clients

Configure proper firewall rules for clients

The first step is to configure the proper firewall rules for your DA clients. To do this, you need to set Firewall Exceptions for CCM Clients according to this link.

The recommended best practice is to do this using Group Policy. In the Group Policy Management Console, go to Computer Configuration->Policies->Windows Settings->Security Settings->Windows Firewall with Advanced Security->Inbound Rules/Outbound Rules. Add all the required firewall exceptions according to the above-referenced TechNet link. Keep in mind the following caveats:

• For each Inbound Rule, you need to set the Edge traversal to “Allow edge traversal” if your clients might be located behind a NAT device.
• To use Remote Assistance: Add an exception for the following executable program: %SystemRoot%\system32\raserver.exe
• To use Remote Control: Add the following predefined rule: Remote Desktop

If the Remote Desktop rule is not pre-defined, here’s how you create a new one:

• Action: Allow the connection
• Programs: This program -> System
• Protocols and Ports: TCP – Local port 3389, Remote port – All ports

Note that if you enter these rules into the DirectAccess client’s Group Policy Object, the custom settings will be overwritten the next time the UAG DirectAccess wizard is run and new GPO settings are deployed. Thus you might prefer to assign an additional GPO to your DirectAccess clients, for the purpose of deploying these settings.

Add SCCM servers and systems into “Infrastructure Servers”

The next thing that you need to do is add the necessary SCCM servers and systems into the “Infrastructure Servers” group, using the Microsoft Forefront Unified Access Gateway Management interface.

The SCCM servers and systems (Management Point, Distribution Point, SHV Point, SUM point, etc.) are required to be in the “Infrastructure Servers” list because clients will need to communicate with these systems before a user is logged on. After you add them, don’t forget to click the “Generate Policies” button in order to ensure that the DirectAccess-related GPOs will be updated with your changes.

After this is done, wait for the changes to take effect on all machines (SCCM site and client). You can run gpupdate /force to force an immediate update to group policy if you’re in a hurry.

You can check to determine that these settings have taken effect by performing the following steps:

1. Check the Windows Firewall with Advanced Security (WFAS) console on the client computer. The rules you enabled in Domain group policy management editor should be enabled with Profile “All”.
2. In WFAS->Connection Security Rules->UAG DirectAccess Client | Client Access Enabling Tunnel | All, the IPv6 address of the SCCM Server should be in the Endpoint 2 list on the “Computers” Tab.

Assess SCCM features supported by your DA configuration

The following table shows you which SCCM features are supported in each UAG DA configuration (based on the IPv6 transition method used on internet and intranet). No native IPv6 configuration is included in the table because we are assuming that there wouldn’t be a native pure IPv6 environment, and that there is no difference in terms of support between an ISATAP and native IPv6 environment.

Table 1

*1. Server Initiated actions will not work with NAT64 because the machine is not IPv6 capable. It cannot connect to the client with the IPv6 address. The workaround is to add a system on the remote site that is IPv6 capable.

*2. The Remote Tool/Assistance function doesn’t work properly in this configuration.

Prepare for potential problems and issues

Let’s take a look at some potential problems and issues that you might encounter when using SCCM to manage your DA clients, and what you can do to head them off.

Boundaries/AD Site settings

AD site boundaries work for DirectAccess clients; when you define an AD site with an IPv6 scope and the client is in that IPv6 scope, it can correctly identify that it is in that AD site. There are some references on how to set AD Site (subnets) for DA clients on the Internet at the following TechNet link.

Before you set boundaries for DA clients, be sure that you understand how boundaries work. Here is a brief overview:

The SCCM boundary will affect the client’s resident (local) Management Point (MP) in the following ways:

• A client’s Assigned MP is the default MP installed o to the site to which the client is assigned.
• A client’s Resident MP is the MP that is located nearest to the client. (If a client is in the boundary of one site, then the resident MP is the MP installed on that site; A resident MP could also be a proxy MP).

When a client starts up, it will check for its assigned MP and resident MP from the domain controller. If a client can find its resident MP, it will use the resident MP. If a client cannot find the resident MP, it will then use the assigned MP.

When the client needs to find distribution points (DPs) for a package, it will first check its resident MP. If the resident MP gives it an empty list, it will fall back to its assigned MP for DP locations. If the resident MP gives it a DP list, the client will try those DPs one at a time. If none of the DPs work, the client will retry before failing. Note that the client will not fall back to its assigned MP again for DP locations. The fallback only happens in one SCCM hierarchy. If the client happened to fall within the boundary of the SCCM site of another hierarchy (this could be caused by incorrect boundaries settings), the client will not fall back to its assigned MP.

It is highly recommended that you don’t set boundaries for DA clients on the internet for the following reasons:

1. When users take their computers back home, their network conditions may vary; some may use 6to4, others may be behind a NAT device and use Teredo or IP-HTTPS. You cannot define boundaries for all of them.
2. This can cause a boundaries conflict and end up being difficult to troubleshoot. For example: When a client is roaming to a sibling primary site/child site/secondary site, it can fall back to its assigned MP; When a client is roaming to a site in another SCCM hierarchy, it will not fall back to its assigned MP.

By default, advertisements and Deployment Templates are configured with the option “Do not run” when the client is in a “slow or unreliable” network. Clients that are not in any boundaries are treated as if they are in a “slow or unreliable” network. Therefore, by default, clients would not be running advertisements unless that flag was specifically changed for all advertisements. To serve DirectAccess clients outside the intranet, we recommend that you don’t setup boundaries for DirectAccess clients on the Internet, so you have to set this option for DA clients to get content from a “remote DP”.

Here’s how you set this option for Deployment Templates:

Figure 1

Here’s how you set this option for advertisements:

Figure 2

NAP Remediation

If Network Access Protection (NAP) is enabled and configured for health validation, the DirectAccess client obtains a health certificate from a Health Registration Authority (HRA) located on the Internet prior to connecting to the DirectAccess server. The HRA forwards the DirectAccess client’s health status information to a NAP health policy server. The NAP health policy server processes the policies that are defined within the Network Policy Server (NPS) and determines whether the client is compliant with system health requirements. If it is, the HRA obtains a health certificate for the DirectAccess client. When the DirectAccess client connects to the UAG DirectAccess server, it submits its health certificate for authentication and access through the intranet tunnel.

For more information about how DA works with NAP, see DirectAccess and Network Access Protection.

SCCM SHV (Server Health Validator) Point

To enable NAP support for DirectAccess clients, be aware of the following:

1. The servers required in the remediation process (such as the MP, DP, etc.) must be in the Infrastructure Servers list in the UAG DirectAccess configuration.
2. The UAG DirectAccess must have UAG Service Pack 1 or above installed.

The other steps are the same as if you setup SHV for the intranet clients.

Native Mode and IBCM (Internet Based Client Management)

The following table compares IBCM and DirectAccess:

Table 2

With DirectAccess enabled, the DirectAccess client on Internet can always access the AD, so DA clients are always on the intranet and will always connect to the intranet MP. If the client fails to retrieve policies from the assigned intranet MP, it won’t fall back to the Internet-facing MP.

IBCM can co-exist with UAG DirectAccess in all three modes:

• Always intranet
• Always internet
• Intranet/internet

For “always intranet” and intranet/internet modes, the clients will always be on the intranet and will communicate with the intranet MP; for “always internet,” the clients will show as being on the internet and will communicate with the Internet-facing MP/DP.

The main differences between an “always internet” client and an intranet/internet capable client are:

1. On assignment, the “always Internet” client will not try to compare the SMS site version and CCM client version, since it has no way to access SMS Site or AD to retrieve the SMS Site version information
2. The “always Internet” client will download Site Signing certificate over HTTP instead of obtaining the certificate from AD
3. On retrieving policy, the “always Internet” client will skip the request for user policy assignments.

Branch Cache and SCCM Branch DP

BranchCache is a wide area network (WAN) bandwidth optimization technology that is included in some editions of the Windows Server 2008 R2 and Windows 7 operating systems. It has two modes: Distributed Cache Mode and Host Cache Mode. Its compatible protocols are: Background Intelligent Transfer Service (BITS), Server Message Block 2 (SMB) protocol, Secure Hypertext Transfer Protocol (HTTPS), and Hypertext Transfer Protocol 1.1 (HTTP). For content distribution, SCCM supports BranchCache with both BITS (http and https) and SMB. SCCM can only utilize BranchCache in Distributed Cache Mode.

To use BranchCache following the BranchCache deployment guide here, no additional configurations are needed on SCCM side.

Comparison of BranchCache and SCCM Branch DP

Table 3

If you would like to read the first part of this article series please go to Configuring SCCM with UAG DirectAccess (Part 1).