Lessons Learned from Microsoft 365 Deployment with ConfigMgr: Part 4 – ConfigMgr Baseline

Lessons Learned from Microsoft 365 Deployment with ConfigMgr

Part 4 – ConfigMgr Baseline

In this post, I’m going to cover how we are using a ConfigMgr Baseline to control the user experience. I’m not suggesting everyone do it this way. However, for us, we wanted to provide a good user experience, even to those on slow links, and make it look pretty while still looking legit and native.

The Microsoft 365 Baseline is how we control two things—the Microsoft 365 Application in the Software Center and the 365 Toast Notification. The Baseline consists of two Configuration Items: one running as a system to determine the state of the machine, and one that runs in the end user context to display a toast notification. The PreReq CI enables or disables the Toast Launch CI, so we really wanted to have the PreReq CI run and remediate before the Toast Launch CI . . . which we never were able to do. More on that later.

Scripts for ConfigMgr Baseline

• Pre-Req Discovery [The discovery script is also being used to make changes, which typically would be broken out into 2 scripts, this couple be a post of its own]
• Toast Launch Discovery [Checks Registry Key which tells the CI to launch the Toast (Run the Remediation Script) or go back to sleep]
• Toast Launch Remediation [This is the Actual Toast Content and probably needs a post of its own]

The Baseline in the Console:

Originally we had put these into one CI with two different settings, but we wanted to try to control the order of operation, which is just not possible. There is a UserVoice out there now to allow us to control it, but for now, we can’t. We wanted to have the Pre Req Discovery and Remediation both run before the Toast Notification Launch Discovery even ran, but we found out that Baselines run everything in serial.

IE, for all of the CIs in a baseline, it will go through each of the Discovery scripts in Pass 1, then come back around on Pass 2 and run any remediation scripts for CIs that have remediation that was flagged as Non-Compliant.

For this reason, we combined the Discovery and Remediation into one script and placed it into the Discovery section for the Pre-Reqs, to hopefully get to run and set items which the Toast Launch Discovery Script relies on. However, even this has proven only partially helpful.

Pre-Req CI‍

• Runs as System
• Checks:
  • Checks for the M365 Content in the CCMCache
  • Checks if M365 is already Installed
  • Checks if Microsoft 365 Semi-Annual Channel Deployment is targeted to machine and if so, is it visible in the Software Center
  • Checks if Microsoft 365 Semi-Annual Channel Deployment is targeted to machine and if so, checks if has Required Deadline

Based on the returned values, it performs different actions. Currently, we account for 15 different permutations of those values.

Let’s take a few Scenarios: [you’ll see a full list in the script of the 15 case statements]

1. M365 Content NOT Cached, M365 NOT Installed:  The Baseline will see the machine does NOT have the content, and that M365 is NOT already installed.  It will make sure that the application does not show up in Software Center until the content is available.
2. M365 Content Cached, M365 NOT Installed:  The Baseline will see the machine has the content, and that M365 is not already installed. It will make sure the Application (Microsoft 365 Semi-Annual Channel) is available in the software center (visible), remove the deadline and set a registry key to enable the toast notification.
3. M365 Content Cached, M365 is Installed:  The Baseline will see that M365 is already installed.  It will set a registry key to disable the toast notification.

While there are other options, those are the big ones.

Actions the CI will take:

• Toggle the Application Deployment Policy in WMI (“ROOTccmPolicy(USER GUIDActualConfig class name = “CCM_ApplicationCIAssignment”)
  • Toggles UserUIExperience from False to True (This will make it visible in the software center)
  • Deletes EnforcementDeadline property (This will change the application form required with a deadline to “available” in Software Center)
• Toggles custom registry key [HKLMSOFTWARESWDO365 – Property:Enable_0365_Toast – Value: True or False]

Client: You’ll see the Microsoft 365 Self-Service Notification Baseline.

Client Side Logging:

When Machine first gets policy but has not downloaded the content yet.

After the Content is downloaded, you’ll see a bit more action here: (Please note that our Discovery & Remediation are in the same script, and the script is in the “Discovery” Script in the CI. We are NOT using the Remediation Script in the CI.)

It then runs Remediation, to enable the app in the software center, remove the deadline, and set the registry key to enable the Toast.

Those are logs from the “PreReq” Configuration Item, which logs toc:windowstempo365_baseline.log

Launch Toast CI‍

• Runs under the User Context (So the Toast will display in their Context and be seen by the end-user)
• Checks Registry Value HKLMSoftwareSWDO365 – Enable_0365_Toast

Registry Value:

The Launch-Toast Log runs as the end user, so the logs go into the end user’s temp folder (c:users%username%appdatalocaltempo365_baseline.log)

The CI has two Scripts

• Discovery Script
  • If Registry Key = True… Report Non-Compliant to CM which will activate Remediation
  • If Registry Key = False… Report Compliant to CM and not run Remediation.
• Remediation Script

Let’s look at the logs which might help explain more.

Here you can see if the CI runs and the Registry Key is set to false, it does nothing and goes back to sleep. If the Registry key is set to True, it triggers the toast notification:

The Toast Image: (The Launch Toast Remediation Script)

So that explains how the toast works . . . Baseline works.

The scripts are all on GitHub and I’ve tried to add a lot of comments, but if you think they are deserving of blogs, let me know. -Gary

---

Lessons Learned from Microsoft 365 Deployment with ConfigMgr

After sharing my series on deploying Microsoft 365 with ConfigMgr, this follow up series details lessons learned by “someone” during a recent large-scale deployment.

1. Microsoft 365 Deployment with ConfigMgr – Lessons Learned 
2. Microsoft 365 Deployment with ConfigMgr- Lessons Learned – Changing Channels
3. Microsoft 365 Deployment with ConfigMgr- Lessons Learned – Deployments
4. Microsoft 365 Deployment with ConfigMgr – Lessons Learned – ConfigMgr Baseline – You are Here