Export (0) Print
Expand All

Example Roaming Scenarios for Configuration Manager: Complex

Applies To: System Center Configuration Manager 2007, System Center Configuration Manager 2007 R2, System Center Configuration Manager 2007 R3, System Center Configuration Manager 2007 SP1, System Center Configuration Manager 2007 SP2

The scenarios in this topic will help you understand how roaming and related scenarios work in Configuration Manager 2007, using some more complex scenarios that build on the basic scenarios in Example Roaming Scenarios for Configuration Manager: Simple and using the same fictitious company multi-site deployment of Configuration Manager.

Before reading these scenarios, see About Client Roaming in Configuration Manager.

The following scenarios focus on clients obtaining content for advertisements and software updates when their network location is outside their assigned site in the Configuration Manager hierarchy:

Configuration Manager 2007 supports both the concept of clients being managed anywhere in a distributed environment and of protecting wide area networks (WANs) so that they do not become saturated with network traffic. These two concepts can sometimes come into conflict, and a combination of configurations and factors can sometimes result in unexpected or unwanted results.

For example, to ensure that clients can always access the content they need, clients that roam into another site will fall back to asking their assigned site for content if it is not available locally. However, the default configuration for advertisements and software update packages is to not allow this content to be downloaded when a client connects on a slow boundary. Configuring distribution points to be protected can also prevent clients from another site from downloading content and can also prevent clients in the same site from downloading content.

The scenarios in this topic cover some typical situations where the behavior of clients with respect to downloading content and communication across WAN links is unexpected and usually not wanted. However, there might be some situations where the outcome is wanted because of a specific business requirement.

Some best practices to avoid these conflicts are the following:

  • Make sure that clients' network location on the intranet fall within a defined boundary in the Configuration Management hierarchy. Collaborate with other service administrators, such as Active Directory administrators, who define the Active Directory sites, and DHCP administrators, who define the ranges of addresses that will be used by clients (including addresses for VPN connections).

  • Make sure that the defined boundaries do not contain a client’s IP address (or subnet) or Active Directory site for more than one Configuration Manager (or SMS 2003) site. When this configuration occurs, it causes overlapping boundaries and is not supported because the client behavior then cannot be determined.

  • When you configure the boundaries to be fast or slow, be aware of the possible consequences if clients can download content when they are not connected to a fast boundary.

  • If you need to prevent WAN traffic for a particular site, configure the distribution points in that site as protected.

  • To minimize traffic between a primary site and its secondary site, install a proxy management point in the secondary site.

  • To minimize traffic over WAN links when clients roam, extend the Active Directory schema for Configuration Manager 2007.

For more information about boundaries, see the following topics:

Hierarchy Used in All Roaming Scenario Examples

The hierarchy has three tiers of primary sites:

  • At the top of the hierarchy is the central site, a primary site in Toronto named TOR.

  • At the second level of primary sites, there are three primary child sites in Houston, London, and Shanghai, named HOU, LON, and SHA respectively.

    • The Houston child primary site has two secondary sites in Seattle and Boston: SEA, BOS.

    • The LON child primary site has one secondary site in Manchester: MAN.

    • The SHA child primary site has no secondary sites.

  • At the third level of primary sites, there are two primary grandchild sites in Sydney and Helsinki, named SYD and HEL respectively.

    • The SYN grandchild primary site has two secondary sites in Melbourne and Brisbane: MEL, BRI.

    • The HEL grandchild primary site has no secondary sites.

This hierarchy is shown in the following illustration.

ConfigMgr Hierarchy Used with Scenarios

User Cannot Download Content When Roaming Because of Default Advertisement Setting

A user whose laptop is assigned to Houston (HOU) travels to Sydney (SYD).

The administrator in Houston created an advertisement for Microsoft Office 2007, with the option When a client is connected within a slow or unreliable network boundary: Do not run program on the Advertisement Name Properties: Distribution Points Tab. The advertisement package is added to the distribution points at Houston (HOU), Seattle (SEA), and Boston (BOS), as shown in the following illustration.

Roaming Client Can't Obtain Content

Global Roaming Capability

When the laptop connects to the network in Sydney, the user tries to run the advertisement. The Configuration Manager client contacts the resident management point in Sydney, but the content is not available in that site.

The client falls back to asking its default management point in Houston for distribution points so that it can download source packages from its assigned site in Houston (HOU).

However, although the contents exists in Houston, the advertisement configuration prevents the content from downloading because the default management point realizes that the client's network location does not fall within the fast boundaries configured for Houston.

The user returns but makes a stopover in Seattle, visiting its assigned site's secondary site, SEA.

When the laptop is connected to the Seattle network, it identifies the site it is in and finds the proxy management point from Active Directory Domain Services. It communicates with the proxy management in SEA for policy, sending hardware inventory and content location requests.

The user tries to run the advertisement again, and this time it succeeds because the proxy management point finds distribution points in SEA that host the content. The client is now within fast boundaries for the Seattle site.

Regional Roaming Capability

When the laptop connects to the network in Sydney, the user tries to run the advertisement. The Configuration Manager client contacts its default management point in Houston, which has no knowledge of the site in Sydney. However, the management point knows about the distribution points in Sydney, but those distribution points do not host the content that the client is requesting.

The default management point in Houston returns a list of distribution points in Houston that host the content needed for the advertisement.

Although the contents exists in Houston, the advertisement configuration prevents the content from downloading because the default management point realizes that the client's IP address does not fall within its fast boundaries.

The user returns but makes a stopover in Seattle, visiting its assigned site's secondary site, SEA.

When the laptop is connected to the Seattle network, it communicates with the default management point in Houston. The default management point informs the client of the proxy management point to use in SEA.

The user tries to run the advertisement again, and this time it succeeds because the proxy management point finds distribution points in SEA that host the content and the client is on a fast boundary for the Seattle site.

User Cannot Download Content When Roaming Because of Protected Distribution Points

A user whose laptop is assigned to Shanghai (SHA) travels to London (LON).

The Shanghai site has deployed an add-on for Microsoft Office and hosts the software package on all distribution points in the Shanghai site.

WAN links to and from Shanghai are slow and expensive, so to prevent these links from being saturated with content downloads, all distributions points in the Shanghai site are configured to be protected with the boundaries that are configured for the Shanghai site.

The content is not available in the London site, so the laptop roaming from Shanghai falls back to asking its default management point in Shanghai for a list of distribution points. Although the content is available in Shanghai, the client's network location in London is not within the boundaries that are configured for the protected distribution points in Shanghai, and the user cannot install the advertisement until she returns to the Shanghai site.

This scenario is depicted in the following illustration.

Roaming Client and Protected Distribution Points

Similar Behavior

When the protected distribution points in Shanghai are configured for fast boundaries only, the same behavior would be seen in the following circumstances:

  • If the Shanghai site has a slow boundary defined for a VPN scope for remote users, users connecting over the VPN will not be able to download the content until they connect directly to the network in Shanghai (on fast boundaries).

  • If a client is assigned to the Shanghai site but its network location is not within the configured boundaries for the Shanghai site, it is automatically considered to be connecting over a slow boundary. This user will never be able to download content from the distribution points in its assigned site until its network location is added to one of the boundaries configured for the protected distribution points.

Client Assigned to Site but Outside Its Site's Boundaries Cannot Run Advertisements or Install Software Updates

A client has a network location that falls within a fast boundary for the London site but is mistakenly assigned to the Houston site.

A software update is deployed at Toronto and hosted on all distribution points in the hierarchy, and the software update deployment is configured with the default setting to not run if clients are on a slow boundary. This scenario is depicted in the following illustration.

Client Outsides Its Site Boundaries

Global Roaming Capability

The client receives the software update notification and contacts the resident management point in the London site (LON). The management point in London returns a list of distribution points in London that have the content needed for the software update. The client is on fast boundary in the London site, and the software update installs.

Regional Roaming Capability

The client receives the software update notification and contacts its default management point in Houston. The management point in Houston returns a list of distribution points in Houston that have the content needed for the software update. However, the client is not within a fast boundary in the Houston site, and the software update installation is not initiated.

Without reconfiguration of the software update or reassigning the client, the only way this client can obtain the software update for this deployment is to roam to London, where its network location would then fall within a fast boundary for the site.

Similar Behavior

Clients would also fail to obtain the software update if the Houston site had a slow boundary defined for a VPN scope (or no boundary defined for the VPN scope) for remote users. In this case, users connecting over the VPN will not be able to obtain the content when they are connected over the VPN.

Scenario Solutions

Resolve the situation of clients being unable to obtain the content by fulfilling one of the following reconfiguration steps.

 

Reconfiguration More Information

If a client that does not have global roaming capability is assigned to a site but its network location falls within the configured boundaries of another site (that isn't a secondary site of the assigned site), reassign the client.

In the given scenario, the client should be reassigned to the London site.

How to Assign Configuration Manager Clients to a Site

As a failsafe, you might want to consider configuring important advertisements and software update deployments to download content and run locally instead of the default option to not install when clients are connected within a slow network boundary.

noteNote
This configuration can result in other clients also installing this content when they are roaming to another site if they fall back to asking their default management point for content

Configure these options on the following dialog boxes:

Reconsider the slow boundaries that you have configured for the site. For example, a VPN connection might be fast enough and reliable enough to be configured as a fast boundary so that VPN users can always install content that is hosted at their assigned site.

Planning Configuration Manager Boundaries

Mixed Mode Client Roams to Native Mode Site

A laptop user from Houston roams to the Toronto site just after a critical software update is deployed and hosted on all distribution points in the hierarchy, with the configuration to download and run locally when clients connect from a slow boundary, as shown in the following illustration.

Mixed Mode Client Roams to Native Mode Site

Global Roaming Capability

A client that has global roaming capability will identify that it's now connected to the Toronto site and attempts to communicate with the resident management point. However, the Toronto site is in native mode and will not allow communication from a mixed mode client. The client falls back to communicating with its default management point in Houston and installs the software update from a distribution point in Houston.

Regional Roaming Capability

A client that has regional roaming capability does not identify that it has roamed into another site. It continues to communicate with its default management point in Houston and asks it for the nearest distribution points from which it can download the software update. The management point in Houston cannot find distribution points in Toronto, so it returns a list of distribution points from the Houston site, and the client installs the software update from a distribution point in Houston.

Scenario Solutions

There are no solutions to this extra traffic between the client that roams to the Toronto site and its assigned site in Houston. When a site is in native mode, it rejects client communication from mixed-mode clients to ensure the integrity of the site.

If the Houston site were migrated to native mode, a client with global roaming capability would be able to communicate with the resident management point in Toronto and download content from the Toronto distribution points.

Native Mode Client Roams to Mixed Mode Site

A laptop user from Toronto roams to the Houston site just after a critical software update is deployed and hosted on all distribution points in the hierarchy, with the configuration to download and run locally when clients connect from a slow boundary, as shown in the following illustration.

Native Mode Client Roams to Mixed Mode Site

Global Roaming Capability

A client that has global roaming capability will identify that it's now connected to the Houston site and attempts to communicate with the resident management point. However, the Houston site is in mixed mode, and mutual authentication using a certification authority between the client and resident management point fails.

If the client is configured with the option Allow HTTP communication for roaming and site assignment, it can communicate with the resident management point in Houston, using mixed mode communication, and ask it for distribution points in the Houston site.

However, if the client is not configured with the option Allow HTTP communication for roaming and site assignment, it cannot communicate with the resident management point in Houston using mixed mode communication. It falls back to its default management point in Toronto and downloads the software update from one of the distribution points in the Toronto site.

Regional Roaming Capability

A client that has regional roaming capability does not identify that it has roamed into another site. It continues to communicate with its default management point in Toronto and asks it for the nearest distribution points from which it can download the software update. The management point in Toronto returns a list of distribution points in Houston.

If the client is configured with the option Allow HTTP communication for roaming and site assignment, it can communicate with the distribution points in Houston, using mixed mode communication, and then installs the software update from the Houston site.

However, if the client is not configured with the option Allow HTTP communication for roaming and site assignment, it cannot communicate with the distribution points in Houston using mixed mode communication. Instead, it installs the software update from its assigned site in Toronto.

Critical Configuration Steps

The following configuration step is required for this scenario to succeed.

 

Configuration More Information

If you want a native mode client to roam into a mixed-mode site and download content locally from the mixed-mode site, configure it with the option Allow HTTP communication for roaming and site assignment.

noteNote
This a less secure configuration than not allowing HTTP communication.

Decide If You Need to Configure HTTP Communication for Roaming and Site Assignment (Native Mode)

Client Communication in Mixed Mode and Native Mode

How to Configure HTTP Communication for Roaming and Site Assignment

Client Roams into Another Configuration Manager 2007 Hierarchy

A consultant from the Houston site visits another company in Michigan where it also has Configuration Manager 2007 installed. When the laptop is connected to the other company's network, it receives an IP address from a DHCP server and has network connectivity. The consultant tries to run a previously received optional advertisement to install an add-on for Microsoft Office 2007.

The Microsoft Office 2007 add-on is also available as an optional advertisement on the other company's Configuration Manager 2007 hierarchy, so the user expects it to install. However, the content is not available to this user with the other company's hierarchy, as shown in the following illustration.

Client Roams to Another Hierarchy

Global Roaming Capability

A client that has global roaming capability will query Active Directory Domain Services for its site and default management point.

On another network, the client computer will not be authenticated and cannot access Active Directory Domain Services. When global roaming capability fails, the client reverts to regional roaming behavior.

Regional Roaming Capability

A client that has regional roaming capability will attempt to find its assigned site’s default management point when it connects to the new network.

The most likely scenario is that the client will fail to find a management point for its assigned site on the new network. If the same site code is not used in the new network or if the client cannot locate a management point, the client falls back to attempting to use its currently assigned management point in Houston. Unless the two hierarchies have a network connection between them, this will fail and the client will be unable to download the content until it returns to its own Configuration Manager 2007 hierarchy.

If the client’s assigned site code matches that of the site code on the new network, the client will attempt to locate its site’s default management point using DNS, the server locator point, and WINS. For this to succeed, the new hierarchy must contain the same site code as the client’s assigned site and one of the following must also be true:

  • For the client to find a management point for its assigned site code using DNS publishing, the client must be configured for DNS servers on the new network, and either the management point on the new network must have the same domain suffix as the management point in Houston or the value for the option Specify or modify a DNS suffix for site assignment below is reconfigured on the client.

  • For the client to find a management point using a server locator point, exactly the same server locator point name or IP address must be used in the new network if the client was assigned a server locator point, or the client must be configured for WINS servers on the new network that have a manual entry WINS entry for a server locator point. Additionally, for a native mode client to communicate with a server locator point, it must be configured with the option Allow HTTP communication for roaming and site assignment.

  • For the client to find a management point using WINS, the client must be operating in mixed mode and be configured for WINS servers on the new network.

If any one of these conditions is met, the client will update its assigned management point with a management point on the alternative hierarchy. However, the client cannot be managed because the client will not trust the management point in the new hierarchy for one of the following reasons:

  • Mutual authentication fails in native mode.

  • The client communication mode is different from the management point’s site mode.

  • The client is configured with a different Client Request port number than the site is using.

  • The client fails to authenticate the management point’s certificate using its own hierarchy’s trusted root key.

Scenario Solutions

If the advertisement is configured as mandatory with the configuration of download and install locally, this scenario would have succeeded if the content had completed its download before the laptop was removed from the Houston site.

Internet-based client management offers another possible solution for laptops that regularly disconnect from their company's intranet. On another company's intranet, the client will attempt to connect to its Internet-based management point and retrieve content over the Internet. For this to succeed, the user might have to configure the Configuration Manager client to use a local proxy server for Internet access. For more information, see the following:

See Also

For additional information, see Configuration Manager 2007 Information and Support.
To contact the documentation team, email SMSdocs@microsoft.com.
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft