Boundaries and boundary groups decide which site a Configuration Manager client joins and which management points, distribution points and software update points it uses. Get them wrong and clients pull content across the WAN, join the wrong site or wait hours for downloads. In this deep dive I'll explain how clients evaluate them, how fallback really works, and a layout you can build and verify.
How it works#
Boundaries#
A boundary is a network location. There are five types:
| Type | Matches when | Check on the device |
|---|---|---|
| IP subnet | The network ID calculated from the client's IP address and mask equals the boundary | ipconfig |
| IP address range | The client's address falls inside the range | ipconfig |
| Active Directory site | The client's AD site matches | nltest /dsgetsite |
| IPv6 prefix | The client's IPv6 prefix matches | ipconfig |
| VPN (version 2006 and later) | The client is on a VPN: auto-detected for PPTP-based VPNs, or matched by connection name or description | ipconfig /all |
Boundary groups#
A boundary group links boundaries to behavior. Clients use boundary groups for two things:
- Automatic site assignment, when Use this boundary group for site assignment is selected on the group's References tab.
- Finding site systems: the distribution points, software update points, management points and state migration points listed as the group's site system servers, plus peer cache sources.
A client in several boundary groups treats all of them together as its current group. A client that matches no boundary uses the site's default site boundary group (Default-Site-Boundary-Group<sitecode>). Internet-based and internet-only clients don't use boundaries.
Relationships and fallback#
On a group's Relationships tab you add neighbor groups and set, per role, a fallback time in minutes or Never fallback. Fallback is one hop: clients only use direct neighbors of their current group, never a neighbor's neighbor.
| Role | Fallback behavior |
|---|---|
| Distribution point | The client keeps trying sources in its current group until the fallback time passes (120 minutes by default), then adds the neighbor's distribution points. |
| Management point | Fallback time is always 0. After five errors in 10 minutes, the client tries a management point in a neighbor or the default site boundary group, and returns at its next refresh (24 hours, or a client service restart). |
| Software update point | The client stays with its current software update point and only looks for another when that server fails; the fallback time controls when neighbors become eligible. |
| State migration point | No fallback. |
Task sequences don't wait for fallback times; they use them only to decide which neighbor to try first (see reading smsts.log).
Step-by-step: a layout that behaves#
1. Map the network#
List each office's subnets or ranges, the VPN address pools and the datacenter. Confirm what clients actually report with ipconfig and nltest /dsgetsite.
2. Create the boundaries#
In Administration › Hierarchy Configuration › Boundaries, select Create Boundary. You can't enter a supernet as an IP subnet boundary; use an IP address range instead. For remote workers, create a VPN boundary: if ipconfig shows PPP adapter ContosoVPN, use ContosoVPN as the connection name.
3. Keep site assignment separate#
Create one boundary group per primary site that contains all of that site's boundaries, has Use this boundary group for site assignment selected with the correct assigned site, and references no site systems. Never put a boundary in two groups assigned to different sites: with overlapping boundaries, clients pick a site at random.
4. Create location groups#
Create a group per office or network zone, add its boundaries, and on the References tab add the local distribution point and software update point. Overlapping boundaries are fine here; one boundary can sit in several content groups. If you want clients to prefer a local management point, add it too and turn on Clients prefer to use management points specified in boundary groups in Hierarchy Settings.
5. Define fallback on purpose#
- Branch to datacenter: add the datacenter group as a neighbor with a distribution point fallback time that matches the branch's link and patience.
- Default site boundary group: every group can fall back to it. If its distribution points sit across a slow link, add it on the Relationships tab and select Never fallback for distribution points.
- VPN group: reference cloud sources, such as a content-enabled cloud management gateway, and block fallback to on-premises distribution points if the tunnel can't carry content.
- Protected networks: use Never fallback for management points that other clients can't reach through a firewall.
6. Set the options#
On the Options tab, decide whether clients in the group may download content from peers and whether they should prefer cloud-based sources. Peer downloads rarely make sense for a VPN group.
Verify#
- Group membership: in Assets and Compliance › Devices, add the Boundary Group(s) column. It updates when the client makes a location request, or at least every 24 hours, and is blank for roaming clients. It's only available when the console is connected to a primary site.
- Site assignment:
ClientLocation.logrecords the assignment. - Lookups:
LocationServices.logshows how the client found its management point, software update point and the distribution points returned for each content request. - Actual source:
ContentTransferManager.logandDataTransferService.logshow the distribution point URL used.
A quick check from an elevated PowerShell prompt on the client:
ipconfig | findstr /i "IPv4 Subnet"
nltest /dsgetsite
Get-CimInstance -Namespace root\ccm -ClassName SMS_Authority | Select-Object Name, CurrentManagementPoint
Select-String -Path C:\Windows\CCM\Logs\DataTransferService.log -Pattern 'http' -SimpleMatch | Select-Object -Last 5Good looks like this: the right site code, a local management point, and download URLs pointing at the local distribution point. A branch client using the datacenter before the fallback time has passed means its boundary isn't in the branch group, or the content isn't on the branch distribution point.
Tips and gotchas#
- Subnet math: a client at 10.1.1.20/23 has network ID 10.1.0.0, so a 10.1.1.0 subnet boundary never matches it. When in doubt, use a range.
- AD site boundaries and VPN: VPN clients often report the datacenter's AD site. Because membership is combined, they then also use datacenter servers. Use VPN or range boundaries for VPN pools.
- One hop only: if a branch should reach a regional hub and then the datacenter, make both direct neighbors with different times.
- The default site boundary group is a safety net, not a design. Unmatched clients and fallback both land there, so decide what it references.
- Unassigned clients: clients outside every site-assignment boundary can still be assigned if you configure a fallback site for automatic site assignment in Hierarchy Settings.
