Prefer a CMG for the Default Boundary Group using PowerShell

Introduction

Each MECM site does have its own default site boundary group.  The naming convention is Default-Site_Boundary-Group-<Site Code>.  For instance in my test lab it is called Default-Site-Boundary-Group-<C99>.

And what is the purpose of this Boundary Group?  For a traditional boundary group, you will assign to it a number of IP subnets, or an IP address range, or an Active Directory Site.  And then you will add important site systems to the boundary group such as Distribution Points or Management Points.  The idea is that devices that exist in these boundaries use the site systems assigned to the the boundary group and not other site systems - although you can allow the devices to fall back and use systems from other boundaries if desired.  In this scenario a relationship is defined to another boundary group.

Boundary Group Relationships

If you do specify a relationship to another boundary group and if a client cannot contact a distribution point, for instance, in its assigned boundary group - then it can fall-back and use the distribution point assigned to another boundary group.  This also applies to Management Points and to Software Update Points.  You can even specify how long it will take before the client does fall back to another boundary group's site system.  In this example on my test lab, I have a boundary group called C99 Remote Site defined to have a relationship/link with my main boundary group called C99 BG.  

You will notice as well, that I can specify how long it will take for the client to fall back to a site system in this boundary group - in this case 15 minutes.

The Default Site Boundary Group

You may notice also that I have configured the Default Site Boundary Group to be in a relationship with my created logical boundary group called C99 BG.  I did not have to do this, in fact, because every boundary group in a site actually has an implicit relationship to the default site boundary group.  This is because clients that find themselves orphaned from any defined boundary groups will use the default site boundary group as the go to place for accessing site systems.  It makes the management of devices more stable because we do know that a network is a fluid entity, and subnets change and this may not always be communicated to the Configuration Manager administrator.

So if such a link to the default site boundary group is implicit, why would you want to actually make the link explicit, as I have done in the above example?  The answer is that I can override the length of time it takes for a client to fall back to using the distribution point or the software update point assigned to the default site boundary group.  In the above example it is set to 15 minutes.  If I left the link to the default site boundary group implicit (unspecified) then the time taken for a client to fall back to systems in the default site boundary group is determined by the settings on the default site boundary group itself.  By default this is 120 minutes, as can be seen.

The CMG and Boundary Groups

A Cloud Management Gateway (CMG) is an azure service that facilitates the communication of polices between an internet based client and systems that are positioned in the on-premise MECM environment. It can also be configured as a cloud based distribution point so that application and package content can be retrieved from the cloud.  In addition, although the CMG is an azure service, it can also be associated as a site system to a boundary group.  We see that this is the case in this production environment example.

And this does have advantages because a client, although being located within an on premise boundary or a vpn boundary, may find that it needs to download a package whose content is not on the boundary's Distribution Point but is on the CMG.  In this case a device can download and install the package from the internet.  

Preferring the CMG over on-premise sources

Further, in this day of hybrid working we may prefer that VPN connected clients use the CMG, when possible, rather than internal site systems for software content - even if the VPN client's configuration is defined as a boundary for an on-premise boundary group.  We may even prefer clients that are not VPN connected, but are located on site and in a boundary group - to use the CMG instead of the on site system.  The on site distribution point, for example, may have tenuous connectivity to the requesting client - and it may be better and faster for the client to retrieve files from the CMG instead.  Or the client may be on a remote site with a particularly fast internet connection - and so it makes sense to prefer the CMG.

This can be done on the options tab of the properties of the boundary group.

Unfortunately we do not have this option available for the default site boundary - in fact, there is no Options tab at all on the properties of the default site boundary.  

Prefer the CMG MP in MECM 2207 using PowerShell

With the release of MECM 2207 we do have a way to allow devices, that fall into the default boundary group, to prefer the CMG as a management point, even though there is still no Options tab on properties of the default site boundary boundary group.  So how do we do this?

We need to use PowerShell.  This is how it is done.

1) From the MECM console click the down arrow on the top left corner and select Connect via Windows PowerShell.  

2) The Windows PowerShell session begins.  If prompted select A to always run software from this untrusted publisher.

Type the following command:

Set-CMDefaultBoundaryGroup -IncludeCloudBasedSources $true -PreferCloudBasedSources $true

3) After pressing Enter, the CMG is now configured as the preferred MP for the default site boundary group.