The Road to Microsoft Endpoint Manager with co-management

The road to MEMCM co-management 

In the world of systems management, Microsoft’s Endpoint Manager (Configuration Manager) solution, is and has been one of the most powerful and flexible solutions for many years.  However, in the modern day where IT administrators need to manage devices that may only be internet connected, without a VPN connection; relying on MEMCM alone will not necessarily be a viable solution.  MEMCM can be configured to manage internet only connected devices, but to do so does rely on a complex set of requirements, design considerations and corresponding configuration decisions.  MEMCM internet-based management of devices and users is referred to as IBCM.  In the past it has been called SCCM IBCM.  I will refer to this solution as MEMCM IBCM.

Alternatively, MEMCM can be configured to use a Cloud Management Gateway (CMG) approach which is much simpler to setup but more expensive to maintain.  This approach will be referred to as MEMCM CMG.  Previously it may have been referred to as SCCM CMG

 

MEMCM IBCM 

In summary MEMCM IBCM implementations follow one of three designs. 

1. A MEMCM internet offering server is placed in the perimeter network. That network also has a read-only domain controller to authenticate users. A firewall between the perimeter and internal networks allows Active Directory packets.
2. A MEMCM internet offering server is placed in a perimeter-based forest. The perimeter forest trusts the internal forest. A firewall between the perimeter and internal networks allows the trafficking of authentication packets. 
3. A MEMCM internet offering server is in the intranet-based forest (Data Centre). The MEMCM internet offering system is published to the internet with a web proxy server. 

• 
  

A MEMCM IBCM solution to internet connected devices without a VPN can be complex but is possible.  Due to this complexity however, along with associated security concerns of exposing internal systems publicly, MEMCM introduced the CMG (Cloud Management Gateway) method of managing internet facing MEMCM devices. 

MEMCM CMG 

The cloud management gateway (CMG) provides a simple way to manage Configuration Manager client agents over the internet. The CMG is a cloud service in Microsoft Azure that does not require additional on-premise infrastructure.  Devices that are internet connected and without a VPN connection can retrieve MEMCM policies and because of this can install deployed applications or have their devices configured according to deployed policies. 

This solution relies on an on-premise MEMCM site system being configured with a CMG connection point.  The CMG connection point, as the name suggests, connects the on-premise MEMCM site to the CMG in the cloud.  The Service connection point, responsible for MEMCM release updates and fixes, also communicates with the CMG in the cloud. 

 

 

If the MEMCM CMG approach is used then, at the time of writing, the best pathway is to ensure that the on-premise MEMCM site is upgraded to 2107. In version 2107 you deploy the CMG with a virtual machine scale set. 

An Azure virtual machine scale set manages the load for a group of VMs. VM instances can automatically increase or decrease in number in response to demand. Thus, with scale sets there is high availability and simplicity in managing a multitude of VMs. 

When you create the CMG in the MEMCM console, the default option is to allow the CMG to function as a cloud distribution point.  And so, we have here a very simple way of providing content and policy to MEMCM internet only roaming clients.  There are of course, additional Azure costs incurred when this solution is implemented, even if it does not incur the costs of setting up additional on-premise infrastructure. 

MEMCM – Tenant Attach 

Many organisations do not want to allow their devices to be without a connection to the corporate network.  These machines, they would argue, are in a rogue environment and MEMCM has no mandate to provide managing capability to such machines.  But as for machines that are connected to the corporate network, the IT administrator should be able to manage these machines from a web portal from anywhere.  

Even from their mobile phone if necessary.  Thus, here arrives the concept of Tenant Attach.  The MEMCM devices are uploaded to the cloud and typical MEMCM console actions such as forcing a machine policy refresh, or viewing the devices details using resource explorer, can be done from the Microsoft Endpoint Manager Admin Center portal.  The clients themselves however, must be connected to the corporate network, either by being located at a corporate office, or connected via a VPN. 

MEMCM – Co-Management 

The underlying cloud management solution that makes Tenant Attach possible is Intune. 

Intune is a complete Modern Device Management (MDM) solution in itself, and can be used even to manage devices that are not part of a corporate Active Directory. 

There is no reason therefore, why Tenant Attach cannot be extended to provide management of clients that belong to a corporate Active Directory and are part of a MEMCM infrastructure - but are not connected to a VPN or directly to Active Directory. 

 

Further, Intune is quite good at managing Windows 10 devices whether connected to the corporate network, or not connected.  So why not provide the ability to switch the responsibility of a particular MEMCM workload, such as software updates, from MEMCM to Intune? 

When MEMCM is configured in this way, so that the responsibly for certain management capabilities is handed over to Intune – then we have a MEMCM site in a co-managed configuration. 

 

 

Configuration Manager Technical Preview 2106: Implicit Uninstall

Introduction

Oftentimes an IT administrator is concerned with getting an application ready for installation, without as much concentration on the application's uninstallation procedure.  And if the administrator has specified an uninstall command line then this might be in consideration for an application upgrade. Uninstall old version and install new version.  But most vendors are keen to have their applications easily upgraded and so their setup files will cater for the upgrade requirements as well as the new install requirement.  And sometimes an unattended uninstallation is more difficult to achieve than the installation.

Yes the focus is sometimes mainly on installation, however equal focus should be on the uninstallation.  Some applications are no longer fit for purpose, or their features have fallen behind their competitor's product, or the business model has changed and the application is no longer required, or the application presents a security risk to the organisation - in these situations the IT administrator needs an uninstallation process as robust as the installation process.

Microsoft's Configuration Manager product treats the uninstallation deployment the same way it treats the installation deployment.  It is just another command line to be executed on the user's device - and success or failure is determined by whatever condition has been created to flag a successful installation of the applications.  This could be a file or folder, or an MSI product code - when this installation condition fails for an the application uninstall deployment evaluation then, paradoxically, the uninstall deployment is a success.

Thus the administrator needs to spend as much effort on the management, administration and testing of the uninstall deployment as he or she does on the install deployment.  And this is not always a wasted expenditure because another reason for uninstalling a product may be to save on licensing expenses, or to free up a license, no longer required on a machine, so that another users can take make use of the license.

Microsoft has implemented the implicit uninstallation feature in the technical preview release 2106 of Configuration Manager.  This means that all we have to do is remove a device from a deployment's collection and, providing the deployment type contains a satisfactory uninstall command line, the application is going to uninstall itself without the administrator having to create an uninstall deployment.  

In this article I test this feature using the Sysinternals BGInfo64 tool as an example.  I create a deployment to install the tool to the primary site server system itself.  I then remove the system from the deployment's collection, force a machine policy retrieval, and observe the automatic uninstall of the tool.

The Sysinternals BGInfo64 Application

For my own testing I created a PSAppDeployToolkit package to install the BGInfo64 tool.  I like to use this handy wrapper toolkit for most of my packaging tasks - it provides a standard command line for all installations and all uninstallations, as well as a set of logs written to the Window\Logs\Software directory.  Thus I can easily determine if the application has actually started to install and the logs themselves help me with troubleshooting failures.  It is beyond the scope of this article to detail how this toolkit works or how to use it, however I can say it is very straightforward to learn.  You can download it at the following location.

https://github.com/PSAppDeployToolkit/PSAppDeployToolkit.git

Alternatively you can use use your own registered application for your testing.  If this is the case then you might want to skip to the section titled The BgInfo64 Deployment Configuration for an Implicit Uninstall, if your primary purpose is to learn about Implicit Uninstall and how to configure the deployment.

My package does the following when it is deployed as an installation.

1) Creates a Sysinternals folder at c:\program files\

2) Copies Bginfo64.exe and Pstools.chm files into the above directory

3) Creates a Bginfo64.lnk shortcut file to Bginfo64.exe at c:\users\public\desktop

My package does the following when it is deployed as an uninstallation.

1) Removes the Bginfo.exe file from c:\program files\Sysinternals

2) Removes the Bginfo64.lnk shortcut file to Bginfo64.exe at c:\users\public\desktop.

If you are familiar with the PSApp toolkit and would like to replicate my Bginfo64 PSApp package then you can do the following.

1) Download the Sysinternals tools from:

https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite

2) Extract the BGInfo64.exe and PStools.chm and copy them into the PSApp SupportFiles folder.

3) Edit the deploy-Application.ps1 script file to include the following in the Install section

New-Folder -Path "c:\program files\SysInternals"

Copy-File -Path "$dirSupportFiles\Bginfo64.exe" -Destination "c:\program files\SysInternals\Bginfo64.exe"

Copy-File -Path "$dirSupportFiles\Pstools.chm" -Destination "c:\program files\SysInternals\Pstools.chm"

New-Shortcut -Path "c:\users\public\desktop\Bginfo64.lnk" -TargetPath "c:\program files\sysinternals\Bginfo64.exe" -IconLocation "c:\program files\sysinternals\Bginfo64.exe" -Description 'Bginfo54' -WorkingDirectory "c:\program files\sysinternals"

4) Edit the deploy-application.ps1 file to include the following in the uninstall section.

Remove-File -Path 'c:\users\public\Desktop\Bginfo64.lnk'

Remove-File -Path 'c:\program files\SysInternals\Bginfo64.exe'

The BgInfo64 Deployment Type command line

Having created the PSApp BGInfo64 package I then registered it as an application in my Configuration Manager primary site, after upgrading it to version 2106.  The Deployment Type command line for the installation is standard:

Deploy-Application.exe -deploymenttype 'install'

The Deployment Type command line for the uninstallation is standard also:

Deploy-Application.exe -deploymenttype 'uninstall'

The BgInfo64 Deployment Type Detection Method Configuration

As stated above, the detection rule looks for the Bginfo64.lnk shortcut file in c:\users\public\desktop

The BgInfo64 Deployment Type User Experience Configuration

In my test package I select Install for system as the Installation behaviour.  I select Whether or not a user is logged on for the Logon requirement.  I select Normal for the Installation program visibility.  I then select Allow users to view and interact with the program installation tickbox.

The BgInfo64 Deployment Configuration for an Implicit Uninstall

Having created my PSApp toolkit package to install the Bginfo64 tool and having registered it in my primary site Technical Preview 2106 Configuration Manager instance as an application, and also having created the Deployment Type with the above configuration - the next steps are:

1) Create a collection and add the name of my primary site server into the collection as a Direct Rule.

2) Create a mandatory deployment to the collection with the option Uninstall this application if the targeted object falls out of the collection selected.

3) Force a machine policy by running the Machine Policy Retrieval & Evaluation Cycle action.

The Configuration Manager BGInfo64 package with Implicit Uninstall Executes

If you are testing your own application deployment then obviously the installation experience will be different.  My PSApp BGInfo64 package manifests itself with an install log at c:\windows\logs\software.  In addition, because I am logged onto the primary site server I am presented with the PSApp Deployment Toolkit wizard allowing me to defer the installation - and this is a rather handy feature and another good reason to use the wrapper for your packaging tasks.

I click on Continue and the installation completes.  As can be seen, a shortcut to Bginfo64.exe appears on the desktop, the Sysinternals directory is created in c:\program files and the bginfo64.exe along with Pstools.chm files are copied into this directory.  In addition the PSApp wizard thanks me for my patience and advises a reboot (not really required of course and you can customise this message as required).

I do click on OK but do not reboot my site server HyperV machine.  We can now test the implicit uninstall feature.

Testing the Implicit Uninstall feature in Preview Version 2106

Now we are in a position to test the Implicit Uninstall feature, and this requires us to remove the direct membership rule, for the targeted machine, from the targeted collection.  After this is done the following occurs:

1) Every 10 minutes a background worker process runs and detects devices the need to have implicit uninstall applications removed (because they have been removed from the install collection).  The activity of this worker process is written to the SMS_ImplicitUninstall.log file on the primary site server.

2) The client performs a computer policy download - by default this is every 60 minutes.

3) 15 minutes later the implicit uninstall application is uninstalled.

In my test I remove direct rule for my device from the collection so that it is now empty.

I then force a machine policy refresh action on the device.

We can see the event triggered in the SMS_ImplicitUninstall.log file

I then complete an Application Deployment Evaluation Cycle.

Note: this last action is not detailed as necessary in the release documentation however it was required in my testing scenario.

As can be seen above, the Bginfo64 shortcut file is removed and the PSApp uninstall log created - this verifies that the implicit uninstall feature has succeeded.

Summary

The implicit uninstall feature is a great new addition to the Configuration Manager product.  It simplifies the administration required to uninstall applications.  It reduces the number of collections in Configuration Manager thus reducing processing overhead.  Obviously care must be taken to ensure that devices are not accidently removed from installation collections.  I look forward to seeing this new feature implemented in the current release version of Microsoft Endpoint Configuration Manager.

I hope you enjoyed reading this article and I wish you similar success in your own testing environments.

Colin