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.

Intune Autopatch - Overview and Deployment Rings

Introduction

Patching machines, and user devices in particular, has traditionally been a labour intensive endeavour.  New quality and feature updates, along with updates to Microsoft 365 apps, Edge and Teams do need to be tested and authorized before going out to your entire estate.  And even if the testing phase of an update cycle is successful, there may still be issues that were undetected - and then we enter into an emergency mode.  The IT team will have to frantically find the cause of the issue, and either present a fix or a workaround as quickly as possible.  During such an emergency phase, the culprit update will need to be paused, or even uninstalled.

And if we might put together a wish list for the updating of devices we would surely desire the following:

1) A testing group of devices for initial installation of updates.

2) A phased roll out of updates so that detected issues cripple as few devices as possible.

3) The ability to exclude or include devices in a roll out approach.

4) An agreed level of patching success, with support from Microsoft.

5) A cloud approach whose implementation is relatively straight forward with all requirements clearly defined.

6) A logical grouping of target devices into rings and the automatic placement of devices in these rings.  These rings would receive updates in a phased approach.  A small percentage in the first ring, a bigger percentage in the second ring, etc.

7) Messaging so that the updates administrator is confidently supported by Microsoft and kept up to date with new features and issues.

8) A group of useful reports so that an IT administrator or manager can monitor the installation of updates.

Windows Autopatch does address most of these requirements and more.  In this article I will cover the Deployment Rings Autopatch feature.

For details on how to install Windows Autopatch I recommend the following article by Prajwal Desai.

https://www.prajwaldesai.com/windows-autopatch-setup-implementation-guide/

Note:  At the time of writing the Autopatch rollout of updates for Teams, Edge and Microsoft 365 apps offers few configuration options to the administrator, nor does it give the administrator the option of pausing or uninstalling such updates.  The ability to Resume or Pause updates is mostly confined to Windows Quality and Feature Updates.

The Autopatch Deployment Rings

When Intune Autopatch is enabled, four rings or bands (Deployment groups) of devices are created - Intune itself will put your devices into three of these groups after they register with Autopatch.  The groups are as follows:

1) Test - Microsoft will not place devices into this group.  The administrator is responsible for placing machines into this group.  Machines in this group will receive updates the very day Microsoft release them.  

2) First - If there are 200 or less registered Autopatch devices, 5% of all devices will be automatically placed in this ring.  They will receive updates one day after the release date.  If there are more than 200 Autopatch devices only 1% of devices will be placed in this ring.

3) Fast - If there are 200 or less registered Autopatch devices, 15% of all devices will be automatically placed in this ring.  They will receive updates 6 days after the release date.  If there are more than 200 Autopatch devices 9% of devices are placed in this ring.

4) Broad - If there are 200 or less registered Autopatch devices the remaining 80% of devices go into this group.  They will receive updates 9 days after the release date. If there are more than 200 Autopatch devices 90% are placed into this ring.

So how do these rings present themselves in Intune?  Firstly you will notice Intune groups are created for each ring.  The following capture shows these groups.

Secondly you will notice that the Update rings themselves are created under Devices\Windows\Update rings for Windows 10 and later.  In this capture we see the four rings along with the Quality Deferral setting.

Although the Feature Deferral is set to 0 for each ring - Autopatch does still stagger the feature update implementation.  The feature release date is communicated via Autopatch messaging, along with the deferral periods for each of the rings.  The autopatch documentation predicts the likely deferral date for each of the rings as follows:

Test:  Release date itself.

First: Release date plus 30 days.

Fast: Release date plus 60 days.

Broad: Release date plus 90 days.

In the following capture we see the Feature updates profiles configured for each of the rings, in addition to a Windows 11 Feature update profile..  Each Feature update is assigned to their respective group.  

If we click on the Modern Workplace DSS Policy [Broad] profile and then on Properties, for instance, we can see that it is assigned to the Autopatch-Broad group.

And where would we find the Autopatch messages informing us about Feature update release dates and schedules?  This is found at Home\Tenant admin\Windows Autopatch\Messages.  Currently there are no messages for my test tenant.

Further, if there has been a change to the tenant configuration requiring administrator led activities - information about such demands will be placed in Home\Tenant admin\Windows Autopatch\Tenant management.  In this capture Microsoft has kindly informed me that my tenant is looking good.

Manually populating the Rings/Groups.

As stated, Microsoft will populate the First, Fast and Broad rings for us - which in itself is a great feature of this technology,  It will not populate the Test ring however, and so we need to do this ourselves.  The following procedure also applies if we would like to move devices around the rings according to our own preferences, rather than Microsoft's automated assignment algorithm. 

Firstly we have to navigate to Home\Devices\Windows Autopatch\Devices.  We then select the devices we would like to move to the Test ring or to one of the other rings.  In this capture I have selected device VM1234 to be moved.

I then click on Device actions and then select Assign device group.

The Assign group blade will appear.  You are then required to select the ring you would like to place the device, from the Select group pull down list.

Click on Save then moves the device into the selected group.

Pausing a Quality or Feature Release

Our testing may have flagged an issue and we might have to pause a Windows Feature Update or a Windows Quality update.  Or perhaps our testing did not flag an issue, however some users, whose devices are in the First or Fast deployment rings may have reported an issue that we suspect is related to a Quality update or a Feature update.  In these scenarios we can easily pause the deployment.  We will navigate to Home\Devices\Windows Autopatch\Release management.  We then click on Pause.

The Pausing a release blade appears.  We need to define if it is a Feature update or a Quality update that we are pausing and then we need to select a Reason.  After clicking Okay the Pause order is then in place for all deployment rings

Resuming a Quality or Feature Update

After we have resolved the issue or issues that prompted us to pause an update, resuming a paused update is a very similar process.  The main difference however is that we are given the option of resuming a particular update ring.

We will navigate to Home\Devices\Windows Autopatch\Release management.  We then click on Resume.

The Resuming a release blade appears.  We must select either a Feature or Quality update to Resume, along with a Reason for the resumption of the update.  We then select the Update Groups or Rings that are to be Resumed.  In this capture I have chosen to resume the Feature update for the Test, First and Fast update groups.

Clicking on Okay then resumes those deployments.

Conclusion

In this article I have illustrated how updates deployment rings can be managed.  We have covered how they are populated and how they can be paused or resumed.  This admin initiated ability to pause updates and then to resume updates for all, or some deployment groups, is a great option.  Hopefully Microsoft will extend this feature to cover Teams and Edge deployment updates as well, sometime soon.

The 3 R's of Microsoft 365 Defender's Live Response

Introduction

Recently a client had quite an issue with DirectAccess.  I won't go into the specifics but I will say that, in addition to a number of remediation scripts that we needed to run using Intune - we did need to contact a significant number of users directly.  In these cases the user's device did have an issue contacting any of the on premise domain controllers. And because of this, some web based applications could not be accessed.

And we did need to initiate a remote viewing session with each user, either using QuickAssist or Teams.  With QuickAssist we would normally be able to execute commands or scripts with elevated privileges.  But in these cases this was not possible because no domain controller could be contacted to complete a Windows authorisation.  And in Teams we do have a remote sharing feature and also with the ability to take control of the user's desktop when required - but Teams is a collaboration application and not a remote troubleshooting tool - and there is not, as far as I know, any way of taking control with elevated privileges.

And so I thought the Live Response feature in the Microsoft 365 Defender cloud based solution might be the ticket.  And so it was.  You could almost say it was tailor made for our particular problem.

We had to achieve four things when we contacted each user:

1) Check child registry keys were cleared under HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig

2) Check the hosts file in c:\windows\system32\drivers\etc contained a specific IP address and URL

3) Run a PowerShell script if any of the above checks failed

4) Connect via a backup VPN solution and run gpupdate.

Using Teams or QuickAssist we could perform items 1 and 2 but not item 3.  And in any case often times the session would be slow and cumbersome.  Possibly we could guide the user to completing step 3 if they had local admin rights - and as a rule this was not the case.

And so the three R's of Live Response came to our rescue - Registry, Retrieve and Run.  Live response is a Remote Shell connection, giving us administrators a set of powerful commands for troubleshooting devices with elevated privileges.  And such troubleshooting requires no demands of the user - and if they can do some of their required work, issue permitting, then they can do so while the security administrator uses Live Response to troubleshoot and resolve the issue.  It sounds cool and it is cool, as we shall see.

Note: This article will not cover step 4 - connect via a backup VPN solution and run gpupdate

Allowing Live Response

We permit the use of Live Response in the Microsoft 365 Defender portal by navigating to Settings\Endpoints\Advanced features.  Turn on Allow users with appropriate RBAC permissions to investigate devices that they are authorized to access, using a remote shell connection.

In addition, if you need to run unsigned PowerShell scripts, turn on Live Response unsigned script execution.

Using Live Response

A Live Response remote shell is started by navigating, in the Defender Portal, to Devices.  In the Device Inventory blade you can type the name of the troubled device in the Search box

Click on the returned device and then click on the 3 ellipse points on the right hand side. Select Initiate Live Response Session from the drop down list.

Your command console sessions is then established.

Registry

The first R of our list of requirements, as stated above, is to check a particular registry key in the HKLM hive.  We do this by running the registry command with the path to the key.

registry "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient\DNSPolicyConfig"

After a few seconds the results are returned.

There are clearly many child keys under the DnsPolicyConfig key, and so this particular device does not pass the first of our two checks.

Retrieve

The second check, as detailed above, was to examine the hosts file.  For this we have the getfile command:

getfile c:\Windows\system32\drivers\etc\hosts

We press enter and after a few seconds the hosts file is copied to our Downloads directory for us to examine.

A quick examination confirmed this file to contain the required IP address and URL.

Run

In this particular example, one of our two checks failed - the hosts file checked OK but the DNSPolicyConfig key contained child keys that we need to remove - for the purpose of our DA issue.  

To do this I need to do the following.

1) Upload my script, called cleanDNS.ps1 to the Live Response library.

2) Run the following command in the command shell: run cleanDNS.ps1

Uploading the Script

This is done by clicking on Upload file to library, which is located on the right hand side above the command shell.

The next steps are fairly intuitive.  Click on Choose File and browse to and select the PowerShell script to run,  I chose my CleanDNS.ps1 file.

The next step is to click on Confirm.

Note:  The cleanDNS.ps1 script is very simple and contains the following command - Remove-Item -path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig\*" -recurse

Run cleanDNS.ps1

Now we can run our script using the run <name of script> command.

So we do type in run cleanDNS.ps1 and click on Enter. The script successfully executes.

Note:  The name of the file is case sensitive.

We now have remediated the registry issue.  For this real world example, the next step was to connect the device using the backup VPN solution and run a gpupdate, which would populate the DNSPolicyConfig key with the required child keys, properties and values.  After a reboot the DA feature was once more working and the user could access their required internal web based applications,

I hope you enjoyed reading this article and I wish you as much success with your testing of the Live Response feature in Microsoft 365 Defender

Colin

Lenovo WarrantyLookup BatchQuery and MECM Data

Introduction

MECM is a very powerful management system and does collect a lot of data about devices, and this means I often get asked for information about devices.  One manager might want to know which devices have Firefox installed and another may need to know which devices are low on disk space.  There is so much information in the database and, in most cases, I'm able to whip up a query and deliver on the data request within the hour, workload permitting.

A few weeks ago I got asked about warranty information for laptops.  Which laptops are out of warranty and which laptops will soon be out of warranty.  I was able to produce some reports based on the date the devices were registered in MECM, but this was only an estimation.

1) A machine may have been provisioned months after purchased - and the warranty period starts from the date of purchase or delivery, not the provisioning date.

2) A machine may have been returned for a rebuild - and in this situation the estimation could be hugely inaccurate.

3) A machine entry in the MECM database may have been deleted, for whatever reason, and the client reinstalled and re-registered.

And then I discovered the UK Lenovo Warranty Lookup page at:

https://pcsupport.lenovo.com/uk/en/warrantylookup#/

And then I discovered the Run batch query page at:

https://pcsupport.lenovo.com/uk/en/warrantylookup/batchquery

I knew then I had the means to supply this manager with exactly the information he required for all the Lenovo devices.

In this article I will describe how I completed this request. I will cover the following steps:

1) Download the Lenovo Template.

2) Populate the Lenovo Template.

3) Submit the data and retrieve the warranty information.

4) Retrieve additional data from a MECM query.

5) Create a database and import the required information - this is to add machine name and other information to the warranty data returned from Lenovo.

6) Create a SQL query to connect the Lenovo data with the MECM data.

Download the Lenovo Template

If you are in the UK navigate to:

https://pcsupport.lenovo.com/uk/en/warrantylookup/batchquery and click on Download the Latest Template

An excel files called Warranty_Batch_Lookup_Template.xlsx will be downloaded.  This file contains the columns that need to be populated with information from our MECM database.  At the time of writing we can see that we need the devices' serial numbers and model numbers.

Save this file to a convenient location and provide it with a relevant name such as LenovoUpload.xlsx.

Populate the Lenovo Template

Next, we need to create a query in the MECM console.  This will allow us to populate the Excel template file downloaded in the previous step.  Thus we need to create a query to retrieve the model number and the serial number.  Open the MECM console and navigate to Monitoring\Queries.  Right click and select Create Query.  Enter in a name such as Lenovo Batch Info.

Click on Edit Query Statement.

Click on Show Query Language and copy the following query statement into Query Statement area.

select SMS_G_System_COMPUTER_SYSTEM.Model, SMS_G_System_PC_BIOS.SerialNumber from  SMS_R_System inner join SMS_G_System_PC_BIOS on SMS_G_System_PC_BIOS.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_G_System_PC_BIOS.Manufacturer = "LENOVO" and SMS_G_System_OPERATING_SYSTEM.Caption like "Microsoft Windows 10%"

Click on OK and Next to create the query.

After creating this query, run it to retrieve the results.  Press CTRL A and then CTRL C to select the results and copy the results.

Open the previously created template spreadsheet and paste (CTRL V) the results into the spreadsheet.  Save the spreadsheet.

Submit the data and retrieve the warranty information.

Having retrieved the serial and model numbers from MECM and copied them into the template spreadsheet, we can now upload them to the Lenovo portal and retrieve the desired warranty information.

Navigate to the following URL:

https://pcsupport.lenovo.com/gb/en/warrantylookup/batchquery

Click on Browse and select the previously populated and saved spreadsheet.

Click on Submit to download the required warranty information

After you have had a good look at all this useful warranty information in Excel, save it as a .csv file.  In my case I save it as lenovo.csv.  We will need this file later when we import the data into our custom database.

Retrieve additional data from a MECM query

And this information is what we require, but of course it does not contain the netbios machine names - because this is provided by the engineer after it is purchased.  It does contain the serial numbers however.  And in MECM we have the serial number and the machine name and we need some way to connect the machine name to the warranty information.  We could do this manually but that is not realistic, given there maybe hundreds or thousands of machines.

Note:  The template upload file also has a comments column.  Another way of achieving this is to populate the comments column with the netbios name or any other information you require in the report.  This would be an easier approach if you are more confident working with MECM queries and you are sure exactly what information you would like to attach to the warranty information, before uploading the template spreadsheet.

We need to create a query in MECM that returns at least the netbios names and the serial numbers.  So let us create such a query, in the same way that we created the last MECM query for the upload.  I call this query Basic Information and it has the following SQL query.

select SMS_R_System.NetbiosName, SMS_G_System_PC_BIOS.SerialNumber from  SMS_R_System inner join SMS_G_System_PC_BIOS on SMS_G_System_PC_BIOS.ResourceId = SMS_R_System.ResourceId

After running this query, press CTRL A and then CTRL C and paste the data into an Excel file.  The column headings I added to my spreadsheet were name and serial.

Save this spreadsheet as a .csv file called mecm.csv.  We now have two files called lenovo.csv and mecm.csv.  These will be used in the next section.  The data in these two files will be imported into our custom database.

Create a database and import the information 

And now we have all the data required for our warranty and in two files.  You could hand them over to your database administrator and ask kindly for him or her to do their magic and combine the netbios names in the mecm.csv file with all the warranty data in the lenovo.csv file - but where is the fun in that?

We can do it ourselves.  You might prefer to use an Access database, but here I use the SQL database on my test server.

I open up the Microsoft SQL Server Management Studio and right click on Databases and select New Database.  In the Database name field I enter in WarrantyLookup and click on OK.

The database is created and that is how simple such a thing is.  Now we need to import the lenovo.csv and the mecm.csv files into the database - each file will be imported into its own table.

Navigate to the WarrantyLookup database in the SQL Server Management Studio and right click and select Tasks and then Import Flat File.

Click Next at the Introduction window of the wizard.  On the Specify Input File windows browse to the the mecm.csv file.  You can leave the default table name or change it to mecm to match our example.

Click Next on the Preview Data page.  On the Modify Columns page confirm you are happy with the column names.

Click on Next and then Finish and Close.  We can see that the mecm table is created.

Repeat all of the above steps in this section to import the lenovo.csv file.  Your new database will now contain two tables with the information we need to produce our final report.

 Create a SQL query to connect the Lenovo data with the MECM data

Now we are ready to combine the data from both the tables we created in the previous section.  In the SQL Management Studio  navigate to the WarrantyLookup database and click on New Query, in the upper ribbon.  In query window enter in the following SQL query.

select * from 

mecm me

inner join lenovo le

on le.serial = me.serial

After pressing Execute our required data will be returned.

This data can be copied and pasted into an Excel spreadsheet (CTRL A and CTRL C and CTRL V) and filtered according to your requirements. 

I hope you enjoyed reading this article and I hope your manager appreciates your hard work when you present to him or her, the warranty data relevant to your environment.

Colin