Device Management in Microsoft articles

From “Push the Patch” to “Prove the Patch”: Rethinking Windows Updating with Intune

MikeGriz — Wed, 01 Apr 2026 15:34:15 GMT

For years, many of us have approached patching like we’re running a shipping dock: build the package, label the box, push it onto endpoints, and then chase down the ones that “didn’t get the memo.” SCCM (Configuration Manager) made that model powerful—deployments, collections, maintenance windows, retries, and all the knobs we learned to love. If you were like me, you built your entire understanding of software updates around this model.

Intune flips the mental model. Instead of pushing patches as discrete payloads, you configure Windows Update behavior (rings, deadlines, restart experience, feature update targets), then you use compliance and reporting to confirm devices are meeting expectations: patch level, minimum OS, and overall update health. The job becomes less “Did I deploy the thing?” and more “Are we getting the outcome?” We get requests from various customers asking us how we "push patches" in Intune vs SCCM. The answer is... we don't.

Why the SCCM “push” model made so much sense

The classic SCCM patching story grew up in a world of on-prem networks, controlled bandwidth, and a very reasonable belief that “if I don’t deploy it, it won’t happen.” You staged content, targeted collections, controlled timing, and could often explain exactly why a given device didn’t patch (client health, boundary groups, scan failures, missing content, reboot pending… pick your favorite).

What changes with Intune: policy first, compliance always

With Intune, you’re mostly not shipping update bits around. You’re shaping how Windows Update behaves: when quality updates install, how long users can defer, when deadlines kick in, what the restart experience looks like, and which feature version a device should land on. Then you validate reality with reporting and compliance signals.

SCCM mindset: Create deployment → target devices → monitor deployment success.

Intune mindset: Define update expectations → let Windows Update do the work → monitor compliance and remediate exceptions.

The uncomfortable part: you’re giving up some control to gain better control

This is usually where the room gets spicy: “But I need to push patches.” Translation: “I need to be able to prove we’re safe, and I don’t trust a model I can’t micromanage.” Fair! But in a modern, internet-first fleet—remote users, always-on VPN (maybe), devices that come and go…, trying to keep the old push mechanics can actually reduce your real control.

Intune’s superpower is that it encourages you to define measurable outcomes: “Devices must be on minimum OS version X,” “quality updates must be installed within Y days,” and “devices outside tolerance are noncompliant.” You stop arguing about whether the deployment ran and start managing an update SLA.

A practical way to start (without breaking your brain)

Define your update posture. What’s your target time-to-patch for quality updates (e.g., 7/14/30 days)? What feature version do you support? Write it down like a promise.

Configure Windows update behavior in Intune. Use update rings to set deferrals, deadlines, active hours, and restart options. Add feature update policies to target a specific Windows version. Use expedited quality updates when you truly need “now.”

Express minimums in compliance policy. Set requirements like minimum OS version (and other guardrails you already care about).

Use Conditional Access (where appropriate) to make noncompliance matter. Not as punishment—more like a seatbelt.

Watch the exceptions, not the whole herd. Use reporting to find patterns: stuck devices, reboot avoidance, update scan issues, or users who live in “Remind me tomorrow.”

Remediate deliberately. Fix root causes (health, disk space, servicing stack issues), and reserve heavy-handed actions for the few devices that earn them.

A question worth asking

If your patching success still depends on the sentence “the deployment ran,” it might be time to upgrade the belief system, not just the tooling. In the Intune model, success is: devices are updated, versions are within tolerance, and noncompliance is visible and actionable.

So here’s the challenge: what would your patching program look like if you treated Windows updates less like a package you ship and more like a standard you enforce? You might find you didn’t lose control at all—you just moved it to where it belongs: policy, visibility, and outcomes.

Device Inventory in the Microsoft Environment

Bankim Patel — Thu, 27 Feb 2025 19:04:50 GMT

The introduction of enhanced Device Inventory in Intune has been eagerly awaited by several teams within our organization. The inventory data, along with CMPivot-like real-time and cached query functionality provided by the Intune data platform, represent significant advancements. These improvements fulfill the promises of cloud-native management and establish a foundation for future developments, such as Copilot integration, cross-platform support, and integrated device actions.

Device Inventory

The initial capabilities in this area emerged in early 2024 with Single Device Query, introducing the ability to perform real-time queries on a Windows device. This was further developed with Device Inventory, which implemented inventory collection through a Properties Catalog policy applicable to multiple devices. The data collected by an agent on managed devices is made available in the Resource Explorer blade for individual devices. The Data platform schema specifies each supported Entity and its applicability to Inventory and Device Query scenarios.

The processing of the Properties Catalog policy on a device eventually results in a CSP firing off to install the “Microsoft Device Inventory Agent”, which appears in Add/Remove Programs and is registered as a Windows Service (InventoryService). The main install directory is %ProgramFiles\Microsoft Device Inventory Agent, which also contains a Logs folder useful for troubleshooting. The Intune Diagnostics data collection also has been updated to pick up Inventory logs. The agent leverages a SQLite DB for its operations, tracking periodic local changes and then performing a daily upload. This is independent of any device sync activity. Intune Admins can rely on the Discovered Apps report to keep track of Agent install counts. Like the Intune Management Extension and EPM agents, agent upgrades occur without any explicit Admin/end-user involvement. The Properties Catalog policy report also has per-property inventory state for each device.

The internal Intune environment at Microsoft is typically the first at-scale tenant where major features like Device Inventory are validated. Engineering teams frequently rely on the environment for validation across individual features, scale/perf and end-user experience (hence “Customer Zero”). The initial waves of rollout in our environment for pre-release versions of the agent were gated to devices in the tens of thousands. The targeting was then switched over to “All Devices” to simulate the at-scale rollout that would be expected in most customer environments. Randomization is factored into the initial Inventory upload, so across our major expansion we did not see issues reported from end users relating to local/network perf. Oddly, we encountered a somewhat painful bug relating to a high CPU condition on agent upgrade, which was addressed quickly. Our team still sees this as a win as internal validation prevented this issue from hitting customer tenants.

Multi Device Query

Device Query for Multiple Devices relies on the inventory data uploaded by devices and introduces the capability to write custom queries to gather insights on device configuration. The Kusto Query Language (KQL) query editor supports IntelliSense and has a parser tuned for this scenario. Docs call out the set of operators currently supported.

Joins between entities follow a natural/implicit style where the join field is automatically configured to be the DeviceId with join type of innerunique. The Device entity is also linked to by default, which allows for core Device attributes to be used (example below). Please see additional info on current query and join limits here.

The returned result set supports dynamic paging to automatically refresh the UI for any large outputs. There is a ~40 min cache retention where the same query re-run within a session is expected to pull data directly from a cache. In our environment, we treat the Managed Devices -> Query permission as an elevated permission, so standing access is not allowed and a separate Group based PIM needs to be activated for access.

Copilot Integration (in development)

Copilot in Intune integration for Multiple Devices builds on the previously released capability for Single Device queries. Copilot simplifies query authoring via the Natural Language to KQL skill. This is an absolute timesaver for those new to KQL or the Device Query schema or those that prefer Copilot build an initial query that can be further refined. Recently, we had an issue that caused some duplicate device records to appear in Device Query. As seen with the prompt below, Copilot not only understands the exact entity properties to leverage but also creates the KQL compliant query.

Query Output

Conclusion

We hope this post helps with your own implementations of Device Inventory, Device Query and Copilot in Intune. We look forward to sharing more on our implementation as new capabilities emerge.

How to manage FileVault personal recovery keys with Intune on previously encrypted MacOS devices

naveenak — Fri, 03 May 2024 06:08:51 GMT

With the rapidly evolving digital landscape, organizations are increasingly turning to Microsoft Intune as their preferred MDM (Mobile Device Management) provider and working on migrating devices from existing MDM solutions to Microsoft Intune.

Migrating device management from one MDM Provider to Microsoft Intune requires several configurations - more details can be found in this article. In this blog, we are going to take a closer look at MacOS device migration from JAMF to Intune, with focus on FileVault key escrow feature.

Migrating MacOS devices from JAMF to Intune involves several steps to ensure smooth transition of the device to Intune and minimizing the impact of productivity. During this process, one of the biggest challenges is getting FileVault recovery keys escrowed back to Intune. We will be focusing on steps which we took to escrow the personal FileVault recovery key to Intune. The specifics of your migration may vary depending on your organization's requirements and the complexity of your existing setup. It is recommended to thoroughly plan and test each step to minimize disruption during the migration process.

There are two main scenarios in which the FileVault key storage process can be categorized:

Device was not FileVault enabled before Intune enrollment (FileVault enabled via Intune policy after enrollment)
1. Devices marked as “Personal”: Recovery key can only be seen by the user via the Company Portal Website
2. Devices marked as “Corporate”: Recovery key can be seen by IT (information technology) administrators in addition to owner of the device
Device was FileVault enabled before Intune enrollment:
1. In this case, the FileVault recovery key is not managed, and Intune is unable to escrow. It is most likely that the recovery key was stored in iCloud.

From this point on, we will be focusing on the 2nd scenario.

The following error message will be shown for the FileVault setting in Intune policy reporting, if FileVault was enabled before Intune enrollment. Intune requires FileVault ownership to apply the “Enable FileVault” setting successfully:

There are multiple ways in which FileVault management can be assumed by Intune. In our implementation, we chose options 2 and 3 from below because they do not require decryption and re-encryption of the drives. Re-encryption adds additional complexity as it will expose user data during this process and consume more time to complete migration. Also, regardless of the option, the steps outlined must be executed by the user who initially enabled FileVault:

From MacOS GUI (graphical user interfaces): From GUI, there is no option to just refresh the recovery key, so it is required to decrypt the device and re-encrypt the device.
1. On the device, choose Apple menu > System Settings, click Privacy & Security in the sidebar, then click FileVault on the right. (You may need to scroll down.)
2. Turn off FileVault and turn it back on
3. Device sync
Terminal commands to refresh the recovery key
1. Users need to launch the Terminal app on the device.
2. Run “sudo fdesetup changerecovery -personal”
3. You will be prompted to enter device admin credentials.
IT Admin generated script/app: Sample scripts can be found at below locations, and these scripts can be customized and deployed as an app.

https://github.com/jamf/FileVault2_Scripts/blob/master/reissueKey.sh

shell-intune-samples/macOS/Config/FileVault/migrateFileVault.zsh at master · microsoft/shell-intune-samples · GitHub

Deploy FileVault key refresh script as Application from JAMF
Unenroll the device from JAMF
Enroll device to Intune
Deploy FileVault policy from Intune 
Run the key refresh script (which deployed previously) from application applet

Once the user executes the application, the device generates a new personal recovery key, Intune assumes management of FileVault encryption on next Intune check-in, and users can see the recovery key in the Company Portal website.

Hopefully, this helps you understand the various methods to escrow FileVault recovery key to Intune.

Accurate Usage of Device Filters in Intune Policy Assignments

ClaudiaZH2021 — Mon, 06 Nov 2023 22:45:40 GMT

Since the Microsoft endpoint management team introduced device filters to the Intune management console, administrators have increasingly embraced them for policy and application deployment assignments. Device filters have significantly enhanced deployment performance and reduced latency in assignments workload. Their impact is most pronounced in large Intune environments, such as those with over thousands of devices. Besides their excellent performance, administrators appreciate their ease of use.

However, while device filters offer numerous advantages compared to traditional Azure AD device groups and user groups, their usage requires careful consideration.

Device filters are created based on device properties like device name, device model, device manufacturer, and device category. In theory, device filters should be evaluated at enrollment and when the device checks in with the Intune service. However, the timing of enrollment evaluation and device check-in can be somewhat tricky in real-time device management environments.

Scenario one:

A policy is applied to the Intune "All devices" virtual group with a device filter set to "exclude" as below picture. At the moment of enrollment evaluation, if the properties in the device filter rule are not set on the device, a newly enrolled device might be evaluated as having null values for those properties, and the policy is applied successfully. However, during the next device check-in (possibly just seconds later), the device's filter properties have been updated, returning the expected evaluation results. If the policy applied is tattooed (“tattooed” means that the policy is permanently applied to the registry and do not revert back to their original state even when the policy is removed or set to “not defined”) or persistent, it won't be automatically removed. This can lead to significant device management issues, which can also occur during application deployments.

A common example of this device filter usage issue relates to Microsoft Teams Rooms Windows devices (MTRW). Many customers enroll their MTRW devices in Azure AD, which are then managed by Intune. One of the prerequisites for using MTRW devices is that autologon should be enabled, meaning that no device lock policies, like password policies, should be applied to these devices. Administrators often use a device filter with device models or device names set to "exclude" in password policies. However, after the MTRW device is enrolled, the password policy is still applied during the enrollment moment because the device properties in the filter rule are not available. This triggers the application of Exchange ActiveSync (EAS) settings to the device. At the next device check-in, the device is successfully evaluated with the filter and excluded from the password policy. However, the EAS settings are tattooed, permanently disrupting the MTRW autologon functionality.

To address this issue, consider the following solution: When using a device filter to exclude devices in policies or application deployments, include an additional line in the regular device property rule as "device.property -eq $null." This addition effectively prevents the issue mentioned above. When a new device is enrolled without device properties available for evaluation, "$null" is presented for evaluation, and the device is excluded as expected. For example, here's a filter example you can use for excluding MTRW devices from password policy:

((device.deviceName -startsWith "cf-") and (device.deviceName -contains "-MTR")) or (device.model -eq "10V50000US") or (device.model -eq $null).

When it comes to using device filters as "include," be cautious when assigning policies or applications to device groups or Intune virtual group "all devices." These groups experience workloads high-performance during device enrollment. If tattooed settings or applications are applied to devices before the device filter is evaluated, administrators may face challenges in troubleshooting which devices unexpectedly received these settings. In most cases, user group assignments with device filter as "include" provide a more accurate targeting result than device groups with device filters. If the policy is applied to user group with device filter, during the enrollment moment, the enrollment will need to evaluate user membership with user login information first before device filter is evaluated, so the devices get enough time to present their properties for filter evaluation. However, there can still be timing challenges between user login and device property evaluation.

Scenario two:

where using device filters as "include" is not recommended is when combining "all devices" assignments with device filters as "include" and Azure AD devices groups as "exclude" as below screenshot. Azure AD device groups have membership evaluation latency, and deploying tattooed settings in this combination may lead to devices in the excluded group receiving the settings before Azure AD membership is evaluated.

For example, suppose an admin needs to disable USB debugging settings for most Android Teams devices, but allow some exceptions for special purposes. The admin may use the following steps to achieve this:

Set the assignment to “all devices”.
Set the Android Teams device filter to “include”.
Create an Azure AD device group with the devices that need USB debugging enabled and add it to the device filter as “exclude”.
Apply the policy.

The devices in the exclude group will also have their USB debugging settings disabled if the admin follows these steps. This is because there is a delay in the device group evaluation, and the “all devices” group and the device filter take precedence over it. The setting in those devices is irreversible and cannot be recovered by a full synchronization later. Therefore, the admin should be very careful when applying this policy and avoid affecting the devices in the exclude group.

In summary, when creating and managing assignments in Intune, it's crucial to consider which assignments are suitable for different scenarios:

Use device group assignments with a device filter as "exclude" and include device.property -eq $null to prevent unexpected devices from receiving settings or applications.

Avoid using the combination of "all devices" assignments and device filters as "include" with Azure AD devices groups as "exclude" for tattooed settings or applications deployment.

Exercise caution when using user or device groups with device filters as "include" for tattooed settings and applications assignments.

For tattooed settings and applications, consider using user groups or device groups for assignments.

Many thanks to Jerry AboueInasr, you did a great job in providing test scenarios and validating the new solutions for device filters. I learned a lot from your insights and suggestions. Thank you for your valuable contribution!

Troubleshoot Cloud PC connection issue

ClaudiaZH2021 — Mon, 10 Apr 2023 16:00:00 GMT

Cloud PC users may encounter connection failure when they restarted the Cloud PC after Windows update or suddenly lose connection without obvious reason. These blog troubleshooting steps are not for a special reason of connection failure. It is a general troubleshooting method for users themselves and Cloud PC admins to bring the Cloud PC back online.

If users restarted Cloud PC because of Windows feature update, it is reasonable to wait around 30 minutes to get a connection because Cloud PC backend infrastructure needs more time to resume all services for supporting Cloud PC than a regular physical devices restart.

End User troubleshooting

If a user gets a connection failure, the user can follow below steps to mitigate the issue and bring the Cloud PC back to online:

Go to web portal of Cloud PC connection Windows 365 (microsoft.com), then click the 3 dots in the right side of Cloud PC tab, click “Troubleshoot”, in the next popup window, check “Yes, I want to troubleshoot this Cloud PC”, click “Start”. The Cloud PC will show “Troubleshooting connection” as below third screenshot. This troubleshooting will remove the Cloud PC session host from current host pool, re-install RDagent and RDbootloader in session host and add the session host back the host pool. Consequently , it will fix RD client Cloud PC connection issue, unavailable resource issue, normally it can fix sixty percent connection issues and bring the Cloud PC online. If this way fixes the connection issue, the below forth screenshot will show “No issues detected”.

Intune or Cloud PC Administrators troubleshooting

On Intune console, Administrators have more options to troubleshoot and monitor the Cloud PC connection issues.

Administrators need to log in to Intune management console, go to Windows devices, find the Cloud PC name, click it to open device properties, go to “Performance”, then click “Connectivity history\Unavailable\Troubleshoot this connection”. If the “Troubleshoot” fixes the issue, the “Activity” in below second screenshot should be all “Success”.

If the above troubleshooting doesn’t fix the connection issue, Administrators can do “restore” from Device\Overview. Administrators can select any good time point to restore the Cloud PC back to its good connection status. After the “Restore” is finished, Intune Console will show “Complete” under “Device action status”. Administrators also can check “Connectivity history” to monitor restarted Cloud PC status to make sure it is restored to the healthy status.

Place failed Cloud PC under review

If end users and administrators cannot fix the above connection issue, administrators can place the Cloud PC under review and escalate this issue to Microsoft Global Helpdesk. Administrators should open the Cloud PC “overview” from Intune console, click “Place Cloud PC under review”:

In the window below, input Azure Subscription and choose Azure Storage account, then click “Place under review”. Administrators should have full access permission for this Azure subscription. During this procedure, the Cloud PC VHD will be uploaded to Azure storage account for Windows 365 engineer team to review and root cause the issue.

Cloud PC connection issues can be caused by many factors. But with services improvement of cloud PC, this kind of connection issues will be more specifically addressed and fixed by backend infrastructure. The cloud PC service will be more stable. More and more tools will be developed to support Cloud PC.

Provision Azure AD Joined Windows 365 for users with special scenarios

ClaudiaZH2021 — Tue, 28 Mar 2023 22:53:17 GMT

Windows 365 provisioning is the automated process in the base of provisioning policies created in Endpoint Manager admin center Windows 365 blade. After users are assigned the Windows 365 licenses and provisioning policies are created and targeted to Azure AD user security groups or Microsoft 365 groups, the devices provisioning process will kick off automatically and the devices will be automatically assigned to the users in policy assignments group.

Provisioning policies can be created in the base of different Azure regions, different images, or other different customer requirements. But one user cannot be put in assignments groups of different provisioning policy because the Windows 365 service always uses the first assigned policy to provision the devices for that user.

Scenario 1, Provision Windows 365 in the base of azure region

If a customer has users in different physical branches like in Asia, Europe, US etc. The customer can provision Windows 365 for their users in the base of their physical locations for network connection benefits.

Sign into the Microsoft Endpoint Manager admin center, select Devices > Windows 365 > Provisioning policies > Create policy, below is an example of creating a provisioning policy and targeting it to West Europe users. All the users in the assignments group will get their devices from West Europe.

Users can confirm their Windows 365 location. Open https://windows365.microsoft.com, log in with Azure AD account, users will see the provisioned Windows 365 under their name. Click settings\System information, the

Scenario 2, Provision multiple Windows 365 with different settings for one user

Technically there is no blocker to target multiple provisioning policies to one user. However, only the earliest created policy will be working to provision Windows 365 for the same user. If the user requires multiple versions of Windows 365 devices with different Azure regions or OS images, we can update the same provisioning policy to provision more than one Windows 365 devices with different regions or OS versions for the same user. Below are the two circumstances:

If the user has 2 Windows 365 devices with same OS and regions provisioned already, but the user needs one of the existing Windows 365 devices to be reprovisioned to a new OS image or a new Azure region, Windows 365 Admin can update the provisioning policy to use new OS image or new Azure region at first, then reprovision one of the existing Windows 365 to the new version. After the reprovisioning is finished, admin needs to change the provisioning policy back to its original region or OS image selection in order not to impact other users in the same assignments group reprovisioning. For example, A user has 2 4V16G Windows 365 devices with windows 10 in West US region already, if he\she wants to change one of the 4V16G windows 10 to Windows 11, or change to Europe region, we can use above way to reprovision one of the existing Windows 10 to Windows 11.
If the user has existing Windows 365 devices already, he wants to add one more device with different region or OS image from his existing devices. Windows 365 admin can update the provisioning policy to use new OS image or Azure region at first, then assign the user with new Windows 365 license, the new Windows 365 device will be provisioned with the new OS or Azure region immediately. For example, A user has existing 4V16G Windows 10, then he\she wants to add a new Windows 11, Admin can modify the current provisioning policy to point to Windows 11 and the correct region, then go to AAD assign the new license to the user. The new Windows 365 with Windows 11 will be provisioned for this user right away.

Scenario 3, Replace provisioning policy assignments group without deprovisioning existing devices

When we remove the assignments group from the provisioning policy or remove the members from the assignments group, the users’ Windows 365 devices will be deprovisioned immediately.

If we accidently attached wrong assignments group to the provisioning policy, and all the devices have been provisioned already and the users actively used them daily, but this assignments group is being used by other purpose and we need to remove it from provisioning policy. Under such circumstances, we can use the steps below to avoid deprovisioning existing devices, subsequently avoid impacting users.

Create a new Azure AD group, add all provisioned devices’ users into this group. Open the provisioning policy and edit the “Assignments”, then add this group to the provisioning policy assignments and save the policy change.

Reopen the provisioning policy, click “Edit” the “Assignments” again, then remove the original group which is also for other purpose and only leave the new group there.

Using Intune device cleanup rules (Updated version)

MikeGriz — Tue, 07 Mar 2023 16:40:28 GMT

As the Intune Service Administrator at Microsoft, we often have to clean up a lot of inactive and stale device records to keep our environment clean. Such records are generated due to test devices enrolled in the environment, workforce changes, users purchasing new devices etc. and can easily skew up the device compliance reporting. The Intune feature “Device clean-up rules”, provides the ability to configure the automatic cleanup rule for the devices that are inactive, orphaned and have not checked in recently. The rule allows administrators to choose between 30 and 270 days to remove the inactive device records from Intune automatically. We had a popular blog post on this from years ago that has grown outdated, so this is an updated version.

For configuring the rule in the environment, navigate to the Devices blade in Microsoft Endpoint Manager admin center and click on Device clean-up rules. Administrator will be able to enable the cleanup rule to delete the devices that have not checked in for {X} days (30-270). At Microsoft, we have configured it as 90 days to keep device count as realistic as possible for such a large environment.

What happens behind the scenes for Device Clean-up rules?

After the Intune Service Administrator enables the rule, Intune services run a background job every few hours to remove all applicable devices from the Intune portal and they will not show up in any Intune blade or device list anymore. The device removal is only applicable to Intune portal and devices do not get removed from Azure AD. Azure AD tenant administrator has to perform the device cleanup task in Azure AD portal to remove the stale record permanently.

What device types get affected from this device clean-up?

Device cleanup rules are applicable for Android, IOS, Windows, MacOS and Linux. The devices that were unable (user abandonment, etc.) to complete the enrollment process are also cleaned up as well.

Does this device clean-up rule perform device wipe or retire?

No, this automatic rule only removes the devices from the Intune portal which are orphaned devices. It means these devices are no longer checking in with the service for the last x days chosen by the administrator before getting removed from the Intune portal.

Is it possible to have devices removed by the device clean-up rule to come back in some scenarios?

Yes, it is possible that some devices can come back in the Intune portal as there is a service criterion to auto-recover the cleaned-up devices if they successfully check-in to the Intune service subsequently. The purpose of this behavior is to recover devices owned by the employees that took a long leave (e.g., Extended vacation, sabbatical, maternity leaves) and the devices were not communicating with the service during their absence. The threshold for devices to show up in the Intune portal is 180 days provided the Intune device certificate is not expired. Please note that Intune service only does the soft delete of inactive device records and the records are still preserved at the backend for certain period to enable such auto recovery.

General reference link: https://learn.microsoft.com/en-us/mem/intune/remote-actions/devices-wipe#automatically-delete-devices-with-cleanup-rules

Posted on behalf of the author, Satish Petwe

New automation script examples on our GitHub repo

james_lieurance — Fri, 03 Mar 2023 16:16:51 GMT

As a follow-up to my previous blog, we have now uploaded the following script examples to our open-source GitHub repository:

Collect SCCM Device Logs
Intune Delete Objects
Intune Device Retire
Intune Device Wipe
Intune Provision W32 Apps
Intune Remove Assignment
Intune Verify Deleted Objects

These example scripts were originally created for use inside of Microsoft. We have modified it to be more generic, so it can be used as a template for other Intune environments outside of Microsoft.

For some ideas on how to create some end-to-end automation that can utilize these examples, you can refer to another previous blog I posted about how we build automation on our team.

Please let us know by commenting on any of the related blog posts if you like additional details or other examples. Thank you! 

4 ways to get your client policy synchronized with the Intune service.

MikeGriz — Thu, 12 Jan 2023 20:26:34 GMT

With any client/server application there are times when things are not in sync between the server and the client, and you want to correct that. Most of the time there are automated ways this will happen, perhaps on a schedule or a triggered event. Inevitably there are also times when you want that resync to happen NOW and not wait until the normal automated processes kick off. There are four ways to do this for Intune devices and while they are very similar, there are differences in what you can expect from them.

In Intune the primary method most admins will be familiar with is from the Admin console. This will tell the software client to do a normal, scheduled, check-in, but more immediately. The client will check for any new policies added or removed for it and then act accordingly. Of note is that if no policy has changed no device compliance calculation and report is created, even if the data which the compliance policy checks has changed.

The second way to initiate a sync with the Intune service is from the client itself. For a windows device this would be through settings / Accounts / Access Work or School / <Your Account> / Info and pressing the “Sync” button. This will tell the client to check in just the same as the method from the admin console above, with the same limitations on compliance calculations.

The third option is via the company portal app. On windows you can find a “Sync” button under the gear icon. Just as the options above, this will cause the device to contact the Intune service and check for any policy additions or removals.

Finally, there is the fourth option (my favorite), which is also in the Intune company portal app as well as the Company Portal website. You can do the sync for any owned device, not just the one you are currently working from. By selecting the device, you can find the “Check Access” button on windows, “check status” on iOS, or “check device settings” on Android. This is the “powerful button.” Clicking this will cause the device to check-in and it will also force a reevaluation of compliance policies and their rules. Therefore, any device or policy changes that may have occurred affecting compliance will be re-evaluated, and the compliance state of the device will be updated as appropriate.

Here at Microsoft, we understand different people work in diverse ways and like to give multiple options to accomplish tasks to meet those different workflows. Hopefully, this helps you understand the various methods to sync a client to get policies, and the one method to force a conditional access compliance re-evaluation.

How the management team at MS integrates with engineering

james_lieurance — Tue, 29 Nov 2022 16:00:00 GMT

Overview:

The MEM @ Microsoft team manages the Intune and Configuration Manager environments at Microsoft. Our service/development engineers combine various components to help automate maintenance of the Intune and Configuration Manager environments (more details about that here). Our work covers various areas besides just maintaining these environments inside of Microsoft. We are part of the Intune engineering organization and so we work together with the product engineers to help build a better management experience for customers (including ourselves). This involves validation of new features before they reach external customers, providing feedback to engineering throughout the design and initial release phases, and sometimes collaborating with the engineering team to develop new features in the Intune product. Another goal we have is to improve the customer experience by providing feedback to Intune engineering teams regarding customer frustrations and to help drive improvements into the product or provide guidance to customers regarding ways to improve your Intune admin experience.

Providing customer guidance:

One of the ways we are working on providing additional guidance is through automation examples uploaded to our open-source GitHub repository. We use automation to reduce maintenance costs of the Intune and Configuration Manager environments and sometimes implement temporary solutions for Intune features that may not be added to the product soon. The repository only has a couple of examples uploaded at this time (QC, Autoscaling VMs, Autopilot deregistration) but we have more automation we could potentially provide examples of, for instance:

Intune - Create, deploy, and deletion of policies.
Intune - Create, deploy, and deletion of applications.
Intune - Retire or wipe of devices.
Intune - Assignment cleanup.
Config Manager - Collect device logs.
Config Manager - Perform collection cleanup.
Config Manager - Perform inbox cleanup.
Config Manager - Health status of the ConfigMgr hierarchy including inbox backlogs, collection evaluation, and audit logs.
Client health telemetry – CM client (SMS agent) installation status, setup failures, and whether service is running or not.

Feedback:

Please let us know by commenting below if there is interest in anything in the list above, or if there is some other area not listed where we could improve the Intune admin experience. Your feedback can help us prioritize what automation script examples we should build and share. As we add more to the GitHub repo, and hear more feedback from customers, we will also continue to provide that feedback to Intune engineering regarding the areas of customer interest and collaborate with them to build more capabilities into the Intune product. Thank you!

Experience with Apple Business Manager Implementation

naveenak — Fri, 30 Sep 2022 20:38:26 GMT

Apple Business Manager (ABM) is a program with the combination of Automated device enrollment (ADE, formerly called DEP) and Volume purchase program (VPP). This is a web-based application which helps organizations to seamlessly onboard and manage devices starting with initial device setup.

We recently implemented Apple Business Manager internally for managing corporate procured devices (before this implementation, these devices used to enroll as BYOD). In this blog, I will be sharing our observations and learning.  

As most of us are curious about what benefits/challenges we will have by having this additional service, here are some of the immediate benefits we observed during the implementation.

Apple Business Manager service can be used for any Apple device procured by organizations like Mac Devices, iPhone and iPads.
Simplifies the device lifecycle, for both IT and end users, from initial deployment to end of life.
Devices can be managed and configured with corporate policies from the initial device setup.
Automated enrollment increases the security of the device and decreases the time for devices to be ready for productive use.
Users will no longer have to configure their device manually, with a few simple operations from the user it will make the device ready to use.
IT professionals can control the behavior of the device setup and user experience based on the organization requirements.
You can have multiple enrollment profiles based on group/division requirements to control the user experience.

Same as benefits, we observed some of the challenges during the implementation of ABM service.

If the company portal app is installed manually before Intune deployed (with required intent), then the device registration will not work, and user see the error “Couldn’t add your device”.
If your organization has conditional access (CA) enforced, then CA requires the device to be registered in Azure AD. When device is enrolled to Intune using the ABM approach, by default device is not getting registered. To get the device to reregister without any problem the Company portal application requires to deploy from Intune and requires user sign-in to the app (currently there will be a user experience difference between IOS and Mac devices).
If the required company portal app (which deployed from Intune) is not the latest or no longer supported, then the users get a notification saying “Version is not supported” during the device registration action. This notification can potentially cause user confusion or delay in the device registration until it updates. This will be a challenge to IT professionals to keep the required application as latest version.
It is possible to have multiple ABM instances tied to a single MDM instance but there are some limitations:

There will be a challenge in verifying the device assignments for all the devices in one location, you need to toggle between them.
Apps and Books tokens (VPP) can’t be shared between two instances.

There is a potential issue if users try to migrate data from old device to new device during device setup. You can avoid this by hiding the “Restore” setting in the enrollment profile.

If your organization allow users to do the migration, you should allow users to unenroll the device by configuring the Enrollment profile setting “Locked enrollment” settings to “No”. And ensure that users do not perform a backup whilst the device is enrolled.

Now you might be wondering about the requirements to implement Apple Business Manager

Setting up a new Apple Business Manager Account is required to establish a process to get the device added to the service when organization procured any Apple device.

To control the permissions and provide access to operate the service, it requires managed Apple IDs and these can be created in ABM portal. (These accounts are not end user accounts, they are specific to ABM)
Apple MDM push certificate (APNs) is required to manage Apple Devices, and the certificate is valid for one year. Failure to renew the certificate before expiry interrupts the device management and requires re-enrolling all Apple devices.

https://learn.microsoft.com/en-us/mem/intune/enrollment/apple-mdm-push-certificate-get

Apple device enrollment program Token is required to establish communication between Intune and Apple Business manager service. With this token, new device details and enrollment profiles settings can sync between both the services (Once the device added to ABM, device show-up in Intune within 12 hours automatically but you can do manual sync once every 15 minutes). This certificate is valid for one year and requires renewing before expiry to avoid any synchronization issues between Intune and ABM.

https://learn.microsoft.com/en-us/mem/intune/enrollment/tutorial-use-device-enrollment-program-enroll-ios#get-an-apple-device-enrollment-token

Configuring Volume Purchasing Program Token is required to sync the content between services and to purchase apps and manage licenses for organization and deploy them using Intune.

https://learn.microsoft.com/en-us/mem/intune/apps/vpp-apps-ios#migrate-from-volume-purchase-program-vpp-to-apps-and-books

Once you have completed the enrollment token configuration, now it is time to create enrollment Profiles to apply defined settings and control the behavior on the device. Based on your organization requirements you can configure multiple profiles (limit is 1000 enrollment profiles per token).

I hope this blog has helped in understanding the implementation of Apple Business manager service and integrate with Intune.

How the MEM @ Microsoft team combines various technologies to build automation.

james_lieurance — Tue, 22 Feb 2022 21:27:37 GMT

Overview:

This is the high-level view of the various components and features we often combine to help automate maintenance of Microsoft’s internal Intune environment. Below I will describe the key tools we use and where we integrate them together. This document is mostly meant to be a high-level overview/starting point. If there is interest, please add a comment and we can provide deeper dives into a particular area.

Starting point: Build a scheduler and gather data

A common starting place for us to build automation is to set up a Flow. Documentation for setting one up can be found here. A flow would normally include the following items:

Recurrence: A schedule for how often the automation should run.

Query: This will require a connection to a data source (e.g., Azure Data Explorer).

Condition: Based on the query results…

Trigger a job: Trigger the automation to run.

Automation: PowerShell Runbooks

Our automation makes use of an automation account to execute runbooks. It takes in data from Flow in the form of a webhook. This automation account is the workspace used to create/manage runbooks for various automation scenarios. The runbook scripts hold the main application logic.

To expand the capability of the automation you can add additional modules to the automation account. By adding additional modules, you can add capability to connect to Azure AD, Graph, or other external resources.

Integrations: Other APIs

In certain scenarios we need to interface with partner resources. We prefer to use managed identity as the mechanism for automation for access to these resources/data sets. These managed identities eliminate the need for developers to manage credentials (like you would with registered applications). These managed identities can be given specific role assignments or graph permissions where they can only access the resources specified.

Reporting: App Insights

We use the App Insights workspace to collect all the logging for azure runbook processing. This workspace allows you to monitor Pass/Fail results, Availability, and other metrics.

Summary:

This covers the basics of what tools our team uses to build automation. Depending on interest, we can take a deeper walkthrough into how we build up any of the resources mentioned above. Please add a comment if you would like more information on a particular area. Based on interest, we could add some code examples to our open source GitHub repository.

VMSS based CMGs and the Cloud heavy ConfigMgr – Part 2

Bankim Patel — Mon, 07 Feb 2022 21:52:23 GMT

This post is a successor to our previous blog post describing the changes to Cloud Management Gateway (CMG) infrastructure in the internal Microsoft environment to align with Zero Trust Networking (ZTN) standards. This post covers the management and migration of Cloud Service Classic CMGs to Virtual Machine Scale Sets (VMSS), aka CMGv2.

Case for VMSS

While the migration to CMG-first communications (described in the previous post) was underway, we were simultaneously piloting early releases of VMSS based CMGs. Within our team and broader organization, there was a push to migrate away from Cloud Service Classic for multiple reasons. In general, Cloud Service Classic is based on legacy Azure Service Manager and moving to a resource fully built on Azure Resource Manager (ARM) model brings parity with other Az resources. For instance, with native support for Autoscale in VMSS, we could make the case to our colleagues on the dev team for future integration with ConfigMgr. The default Cloud Service classic CMG implementation was also based on the older 2012 OS Family model. One of our team’s core goals is to “Stay Current” and hence it was a no-brainer to migrate to the latest VMSS based CMGs when the opportunity arose.

Migration to VMSS CMGs

As we were already piloting VMSS CMGs, we did not perform any conversions from Classic to VMSS. We did perform conversions to larger SKUs as they started to become available. There are some in-house monitoring tools that are required by policy to be running on VM instances, so we generally spun up new VMSS CMGs, confirmed policy compliance and switched existing Proxy Connection Points to the new CMGs in a gradual manner. Note: enviromental configurations (devices being offline, speed at which connectors are moved and inability of some devices to enumerate AD etc..) may cause some devices to not become aware of these changes and potentially continue to access old CMG URLs. We leveraged a Proactive Remediation script in Intune to detect drift and set the appropriate CMG values for the CMGFQDNs key under HKLM\SOFTWARE\Microsoft\CCM. We used the high-level SQL queries below for tracking progress:

--Clients by CMG SELECT SUBSTRING(bgb.AccessMP, 1, CHARINDEX('/', bgb.AccessMP, 1)-1) as 'CMG', COUNT(bgb.ResourceID) as 'Count', SUM(bgb.OnlineStatus) as 'Online' FROM BGB_ResStatus bgb WITH (NOLOCK) WHERE bgb.AccessMP LIKE '%ccm_proxy%' GROUP BY SUBSTRING(bgb.AccessMP, 1, CHARINDEX('/', bgb.AccessMP, 1)-1) ORDER BY 'Count' DESC --Per MP Client Count SELECT b.[DBID] AS SiteName ,b.ServerName AS MPName ,COUNT(CASE WHEN PATINDEX('%CCM_Proxy%', a.AccessMP) > 0 THEN a.ResourceID END) AS CMGClientCount ,SUM(CASE WHEN PATINDEX('%CCM_Proxy%', a.AccessMP) > 0 THEN a.OnlineStatus END) AS CMGOnlineClients ,COUNT(CASE WHEN PATINDEX('%CCM_Proxy%', a.AccessMP) = 0 THEN a.ResourceID END) AS IntranetClientCount ,SUM(CASE WHEN PATINDEX('%CCM_Proxy%', a.AccessMP) = 0 THEN a.OnlineStatus END) AS IntranetOnlineClients FROM dbo.Bgb_ResStatus a WITH (NOLOCK) INNER JOIN dbo.BGB_Server b WITH (NOLOCK) ON a.ServerID = b.ServerID GROUP BY b.[DBID] ,b.ServerName ORDER BY b.[DBID] ,b.ServerName

Monitoring

When only a portion of our client traffic was using CMGs (prior to moving to CMG-first), we did not employ extensive monitoring beyond some general tracking of CMG client counts in operational reports and health monitoring via component status messages for CloudMgr. With the shift to CMG-first for all clients, our team added traffic trends and current connections to our Power BI based reporting :

Additionally, we needed to validate with all clients using CMGs 24x7, if there were any availability issues or excess queuing on the CMG channels. For example, CCMSetup is not a happy camper when timeouts greater than 30 sec occur during client installs. To provide high level insights into availability and response times, we resorted to a URL monitor in Azure Monitor. We used the synthetic URL below against all CMGs and were able to validate high-level response times executed from different Az regions and in the case of an exception, drill into the number of failures and IIS return code (500/503 etc..) as well.

https://CMGFQDN/CCM_Proxy_ServerAuth/AADAuthInfo

Azure Monitor also includes a Downtime and Outage workbook which can be used to analyze potential outages, downtime and failures based on location.

We later relied on our in-house monitoring tools running on VM instances to natively monitor and alert on conditions such as High CPU, IIS errors etc. We have also filed change requests that advocate for additional in-console health monitoring for customers that may pursue CMG-first implementations.

Troubleshooting

In troubleshooting scenarios, at times, nothing beats some of the great logging already available in CMG logs on the Service Connection Point role in your Site. For example, for a quick check on a particular VM instance, you can pull up one of the CMG-cmgname-vminstance0001-CMGService.log files and filter for “Summary” to get some quick health insights:

To quickly examine a Proxy Connector, you can also inspect the SMS_Cloud_ProxyConnector.log files and filter for “ReportTrafficData - state message to send” and amongst all the other per-endpoint details, the very first xml tag will have the MaxConcurrentRequests:

<ProxyTrafficStateDetails ServerName="abc.def.com" StartTime="12/01/2021 03:46:14" EndTime="12/01/2021 03:51:15" MaxConcurrentRequests="5073">

After upgrades/certificate update operations, if individual VM instances have needed a reboot etc.., we’ve used the Az REST API or PowerShell commands to inspect overall config/instances for the VMSS. In PowerShell, this would be via the Get-AzVMSS and Get-AzVMSSVM commands:

#per VM provisioning state Get-AzVmssVM -ResourceGroupName MYVMSSCMGRG -VMScaleSetName MYVMSSCMG -InstanceView #specific VM instance config (with/without -InstanceView parameter) Get-AzVmssVM -ResourceGroupName MYVMSSCMGRG -VMScaleSetName MYVMSSCMG -InstanceID 1

Conclusion

We hope the posts in this series are useful in your own CMG implementations and demonstrate ways of pursuing CMG-first communication with the possibility of simplified infrastructure.

Deploy Teams media optimization with Intune Proactive Remediation to Windows 365

ClaudiaZH2021 — Thu, 13 Jan 2022 00:20:05 GMT

The Microsoft Windows 365 provides all the benefits of Windows, without any of the traditional hardware limitations. It is the most optimized Microsoft 365 powered compute experience delivered from Azure and managed by Microsoft. It is Microsoft’s best expression of Windows and M365 and is always secure and up to date.

Teams media optimization package includes Remote Desktop WebRTC Redirector Service and latest Microsoft Visual C++ Redistributable. With media optimization for Microsoft Teams, Windows 365 can handle audio and video locally for Teams and meetings. Windows 365 can have all the benefits of the modern media stack including HW video decoding with the high-performance peer-to-peer streaming facilitated by media optimization WebRTC. This feature effectively solves some user meeting issues like sound echo which they can encounter during Teams meeting without media optimization. It also provided the same audio and video experience as users who are using physical PCs.

Teams media optimization package has been integrated into the latest Windows 365 OS with integrated office apps. Users may not see audio or video issues initially when they join meetings with Teams if they are using office apps integrated version Windows 365. The below process is still helpful for remediation if Teams functionality is broken in the office apps integrated version. Additionally, if the users didn’t purchase office apps integrated Windows 365 version and they want to install office apps later, the below process is also helpful for them to deploy Teams media optimization package from scratch.

Prerequisites

Before you can use media optimization in Windows 365, the below prerequisites need to be prepared:

Install the Windows Desktop Client on any Windows device which you use to connect to Windows 365.
Deploy Teams Machine-Wide Installer to Windows 365. Microsoft Teams Machine-Wide Installer is included as part of the new installation of Microsoft 365 Apps starting with version 1902. For this step, you can use separate Teams installer or Microsoft 365 Apps deployment.
You must install Microsoft Teams machine-wide installer version 1.3.00.4461 or later – the 64-bit version is highly recommended.

Deploy Teams media optimization with Intune Proactive Remediation

Navigate to the Intune portal https://endpoint.microsoft.com -> Reports -> Endpoint Analytics -> Proactive Remediations. Proactive remediations are script packages that can detect and fix common support issues on the user’s device. It also can be used to deploy customized Powershell scripts to the user device.

In Teams media optimization deployment, if users have Teams installed in ($env:ProgramData)\$env:USERNAME\Microsoft\Teams or in ($env:LOCALAPPDATA)\Microsoft\Teams, we need to uninstall it at first before we install media optimization. Teams media optimization only will be working under the scenario when media optimization is installed before the user profile Teams installation.

Detection Script

#===========================================================================

# Script Name: detectMedia.ps1

# Description: Detect if Team media optimization has been installed and if it is installed, make sure it is

# installed after user profile Teams installation. if it is not installed or installed after

# user profile Teams installation, we need to remove Teams at first before installing media optimization.

#==========================================================================

$TeamsMediaFile = "C:\Program Files\Remote Desktop WebRTC Redirector\MsRdcWebRTCSvc.exe"

$TeamsMediaPath = "C:\Program Files\Remote Desktop WebRTC Redirector"

$TeamMediaFileExist = Test-Path -Path $TeamsMediaFile

$folders = Get-ChildItem -Path C:\users -Directory -force -ErrorAction SilentlyContinue |select fullname,name

$totalFolders = $folders.Count + $folders.Count

if($TeamMediaFileExist -eq $true )

{

foreach($eachfolder in $folders)

{

$TeamsPath = $eachfolder.Fullname + "\AppData\Local\Microsoft\Teams"

$TeamsUpdateExePath = $TeamsPath + "\Update.exe"

$TeamsUpdateExist = Test-Path -Path $TeamsUpdateExePath

$TeamsPathExist = Test-Path -Path $TeamsPath

if ( $TeamsUpdateExist -eq $True )

{

$TeamsCreationTime = get-date ( (get-item -path $TeamsPath).LastWriteTime)

$TeamsMediaCreationTime = get-date ( (get-item -path $TeamsMediaPath).CreationTime)

if( $TeamsMediaCreationTime -lt $TeamsCreationTime)

{

$totalFolders = $totalFolders -1

}

elseif( $TeamsPathExist -eq $false)

{

$totalFolders = $totalFolders -1

}

$TeamsUserPath = "C:\ProgramData\" + $eachfolder.name + "\Microsoft\Teams"

$TeamsUserUpdateExePath = $TeamsUserPath + "\Update.exe"

$TeamsUserUpdateExist = Test-Path -Path $TeamsUserUpdateExePath

$TeamsUserPathExist = Test-Path -Path $TeamsUserPath

if ( $TeamsUserUpdateExist -eq $True )

{

$TeamsCreationTime = get-date ( (get-item -path $TeamsUserPath).LastWriteTime)

$TeamsMediaCreationTime = get-date ( (get-item -path $TeamsMediaPath).CreationTime)

if( $TeamsMediaCreationTime -lt $TeamsCreationTime)

{

$totalFolders = $totalFolders -1

}

elseif($TeamsUserPathExist -eq $false)

{

$totalFolders = $totalFolders - 1

}

$TeamsReg = "HKCU:\Software\Microsoft\Office\Teams"

#if this registry key is existing, it will block user profile Teams installation by Teams machine-wide installer.

$TeamRegExist = test-path -path $TeamsReg

if($TeamRegExist -eq $True)

{

$PreventInstallStateKey = Get-Item -Path $TeamsReg

$preventInstall = $PreventInstallStateKey.GetValue("PreventInstallationFromMsi")

}

else { $preventInstall = $null}

if(($totalFolders -eq 0) -and ($preventInstall -eq $null)) { write-host "Compliant" exit 0}

else {

write-host “Not Compliant”

exit 1

}

else {

write-host “Not Compliant”

exit 1

}

Remediation Script

#===========================================================================

# Script Name: UninstallTeams_InstallMediaOptimization.ps1

# Description: Uninstall user profile Teams and Install Teams media #optimizatio.

#==========================================================================

$folders = Get-ChildItem -Path C:\users -Directory -force -ErrorAction SilentlyContinue |select fullname,name

$TeamsReg = "HKCU:\Software\Microsoft\Office\Teams"

$TeamRegExist = test-path -path $TeamsReg

try

{

foreach($eachfolder in $folders)

{

$TeamsPath = $eachfolder.Fullname + "\AppData\Local\Microsoft\Teams"

$TeamsUpdateExePath = $TeamsPath + "\Update.exe"

$TeamsUserPath = "C:\ProgramData\" + $eachfolder.name + "\Microsoft\Teams"

$TeamsUserUpdateExePath = $TeamsUserPath + "\Update.exe"

if (Test-Path -Path $TeamsUpdateExePath)

{

Write-Host "Uninstalling Teams process"

# Uninstall Teams from user profile

$proc = Start-Process -FilePath $TeamsUpdateExePath -ArgumentList "-uninstall -s" -PassThru

$proc.WaitForExit()

}

if (Test-Path -Path $TeamsPath) {

Write-Host "Deleting Teams directory"

Remove-Item –Path $TeamsPath -Recurse

}

if (Test-Path -Path $TeamsUserUpdateExePath)

{

Write-Host "Uninstalling Teams process in ProgramData folder"

# Uninstall Teams from programdata folder

$proc = Start-Process -FilePath $TeamsUserUpdateExePath -ArgumentList "-uninstall -s" -PassThru

$proc.WaitForExit()

}

if (Test-Path -Path $TeamsUserPath) {

Write-Host "Deleting Teams directory"

Remove-Item –Path $TeamsUserPath -Recurse

}

# if this Teams preventinstallationFromMsi is existing, remove it to make user profile Teams installation

# be triggered by Teams machine-wide installer

if($TeamRegExist -eq $True)

{

$PreventInstallStateKey = Get-Item -Path $TeamsReg

$preventInstall = $PreventInstallStateKey.GetValue("PreventInstallationFromMsi")

if ($preventInstall -ne $null)

{

Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Office\Teams" -Name "PreventInstallationFromMsi"

}

#Install Teams media optimization

#Create a directory to save download files

$tempCreated = $false

if (!(Test-Path C:\temp)) {

New-Item -Path C:\ -ItemType Directory -Name temp

$tempCreated = $true

}

# Add registry Key

reg add "HKLM\SOFTWARE\Microsoft\Teams" /v IsWVDEnvironment /t REG_DWORD /d 1 /f /reg:64

#Download C++ Runtime

invoke-WebRequest -Uri https://aka.ms/vs/16/release/vc_redist.x64.exe -OutFile "C:\temp\vc_redist.x64.exe"

#Download WebRTC

invoke-WebRequest -Uri https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4AQBt -OutFile "C:\temp\MsRdcWebRTCSvc_HostSetup_1.0.2006.11001_x64.msi"

#Install C++ runtime

Start-Process "C:\temp\vc_redist.x64.exe" -ArgumentList @('/q', '/norestart') -NoNewWindow -Wait -PassThru

#Install MSRDCWEBTRCSVC

Start-Process msiexec.exe -ArgumentList '/i C:\temp\MsRdcWebRTCSvc_HostSetup_1.0.2006.11001_x64.msi /q /n' -Wait

if ($tempCreated) {

#Remove temp folder

Remove-Item -Path C:\temp\ -Recurse

}

else {

#Remove downloaded C++ Runtime file

Remove-Item -Path C:\temp\vc_redist.x64.exe

#Remove downloaded WebRTC file

Remove-Item -Path C:\temp\MsRdcWebRTCSvc_HostSetup_1.0.2006.11001_x64.msi

}

Write-host "Media Optimization Installed"

exit 0

}

catch

{

Write-Error -ErrorRecord $_

exit /b 1

}

Verify and test the media optimization

After the above remediation script has been run successfully in Windows 365, users should log in to their Windows 365. Teams per user installation will be triggered automatically by Teams machine-wide installer. After the Teams pops up, go to Teams user profile, click “About”, choose “Version”, below “WVD Media Optimized” should be displayed.

Go to Teams user profile, click “Settings”, choose “Devices”, you should see “Audio devices” is set to “Custom Setup”. Speaker, Microphone, and Camera available locally will be enumerated in the device menu as the below screenshot. If the menu shows “Remote Audio”, please sign out and sign in to try again.

If above verifications are done, you can use Teams in Windows 365 with local audio and video to participate in meetings. The performance of the audio and video quality will be the same as when you are using Teams in your physical PC.

Troubleshooting

If users don’t see media optimization as in the above screenshots or Teams doesn’t automatically start after users log in Windows 365:

Check if below registry key has been created in Windows 365:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Teams\

Name: IsWVDEnvironment
Type: REG_DWORD
Value: 1

Check if media optimization and Teams machine-wide installer have been installed in Windows 365:

Check SquirrelSetup.log in %LocalAppData%\SquirrelTemp. The system automatically starts Teams when a user logs in if Teams machine-wide installer is healthy in the device. If the Teams doesn’t start after user logs in, all the failures about Teams installation and updates are recorded in SquirrelSetup.log.

Note: This script/function is provided AS IS without warranty of any kind. Author(s) disclaim all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall author(s) be held liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the script or documentation.

Zero Trust Networking and the Cloud heavy ConfigMgr – Part 1

Bankim Patel — Wed, 05 Jan 2022 18:13:56 GMT

This 2-part blog covers changes to the Cloud Management Gateway (CMG) infrastructure in the internal Microsoft environment to align with Zero Trust Networking (ZTN) standards. The second part of this series covers the management and migration of Cloud Service Classic CMGs to Virtual Machine Scale Sets (VMSS), aka CMGv2.

In a previous blog post, we had alluded to how moving portions of our ConfigMgr client traffic in specific regions to CMGs allowed us to lower the burden on VPN Gateways. We had also mentioned how those actions helped us pilot a model that embraced architectural elements of Zero Trust. Well, not long after, the directive to align with Microsoft’s internal push to Zero Trust Networking standards landed on our team and we then set out to migrate all ConfigMgr client traffic to be internet-first/CMG-first and route through the CMGs.

ZTN and ConfigMgr

There are many salient features of Zero Trust and this post cannot do justice to describe entirely the ZTN shift at Microsoft, so we’ll refer those interested in the details to the following posts by our peers in the Microsoft Digital team:

Transitioning to modern access architecture with Zero Trust

Using a Zero Trust strategy to secure Microsoft’s network during remote work

Lessons learned in Zero Trust networking

One of the core tenets of the ZTN model is the shift away from the traditional flat Corporate network and focus on network perimeter security to one with greater focus on identity, device-health evaluation, segmentation and tight controls on network access. The internet-first model also prefers cloud based or app proxy-based access to Apps in favor of Corpnet/VPN based access. The resulting networking impact to a ConfigMgr client/end-user is that instead of the device in an office location being on a traditional Corpnet, it is instead on an unprivileged/internet-based network that prioritizes access to Cloud resources with the shortest network path. This therefore meant that Clients would eventually lose traditional on-prem based connectivity to ConfigMgr Site Systems. ConfigMgr as an app stood out clearly on the list of candidate apps to migrate to internet-first due to the high number of hits a client would generate for daily actions such as machine policy, BGB/online status etc. The in-box availability of an internet-first routing mechanism via the CMG also made it a prime candidate for migration.

Client Traffic Migration

We decided to follow an East->West regional approach to migrate clients to CMG-first as at the time offices in the Eastern regions were in various stages of reopening and we wanted to understand if the increase in Internet traffic at any location would cause any management issues for networking teams. We then considered two migration methods – replacing on-prem Site Systems with CMGs in Boundary Groups and converting clients to AlwaysInternet mode. After some consultation with our partners in the ConfigMgr Dev team, we decided on the Boundary Group based method as in general it is a tried/tested foundational feature over the years and if any client does consider itself as being on the Intranet, it would be able to leverage Peer Cache even when using the CMG. This option would not have been available if the client were in an Internet-only mode.

We examined our existing client traffic trends and arrived at a ballpark number for the number of concurrent connections our CMGs would need to support and scaled up existing CMGs to meet the requirements (roughly 4x the previous VM instances). We used the published guidance on CMG performance and scale to arrive at VM instance counts. As we have a Primary Site in Asia, we configured CMGs in East Asia and SE Asia Azure regions to manage the regional traffic load. The remaining CMGs based in US regions were linked to our Proxy Connectors at Redmond Primary Sites to manage the traffic load for all other regions.

We migrated clients by adjusting our Boundary Groups across various waves and tracking the progress via a Power BI report. Although this is not an instantaneous change on client side and generally the next Location Request performed by the client would register the boundary change, we exercised a bit of caution with our largest boundaries. The devices in these boundary groups were broken up further by creating new IPv6 prefix-based boundary groups and adopting the VPN boundary group.

The SQL queries that help us derive data are mainly sourced against v_CombinedDeviceResources (for heavy report volume consider BGB_ResStatus/BGB_LiveData_Boundary tables – data is per client/per boundary however):

--Device count based on Boundary Group SELECT cdr.BoundaryGroups, COUNT(cdr.MachineID) as 'Total Count', SUM(CASE WHEN cdr.CNAccessMP LIKE N'%CCM_Proxy%' THEN 1 ELSE 0 END) as 'CMG', SUM(CASE WHEN cdr.CNAccessMP NOT LIKE N'%CCM_Proxy%' THEN 1 ELSE 0 END) as 'Intranet MP', SUM(CAST(cdr.CNIsOnline as int)) as 'Online' FROM v_CombinedDeviceResources cdr WITH (NOLOCK) GROUP BY cdr.BoundaryGroups ORDER BY 'Total Count' DESC

The migration was completed without any significant issues and some bugs were filed for scenarios relating to roaming/default boundaries where some clients would continue to leverage the Intranet MP path. The net benefit was an ~86% reduction in ConfigMgr traffic over the VPN towards the later stages of the migration.

Post Migration Changes

With CMGs now providing access to Management Points/Software Update Points and serving out content to all clients – the case to retain on-prem Distribution Points dwindled. We therefore decommissioned all on-prem Distribution Points and the cost savings were able to make up for additional bandwidth costs incurred with the migration.

Additionally, with no on-prem Distribution Points in place, we were able to stop downloading monthly updates for our Software Update packages as these deployments could just be targeted with the fallback to Microsoft Update enabled. It is not worth replicating this content to the CMGs anyway as the CMG is considered lower priority for content acquisition and the client will prefer Microsoft Update sources if the below option is enabled:

For those wondering about scale/performance – we recently uncovered a nasty bug in the 2107 Hotfix Rollup candidate (pre public release). We were able to leverage a Run Script action and remediate >100k domain joined online clients in a matter of minutes and mitigate a production outage.

An additional tip of the hat here is due to the Proactive Remediations feature in Intune. Not only does it give us another tool in the arsenal to evaluate health and remediate issues with the ConfigMgr client, but it is especially useful in the CMG-first configuration. We specifically encountered an issue causing some devices to inherit an incorrect legacy IBCM MP configuration, in effect breaking ConfigMgr client functionality and were able to remediate impacted devices by a simple script in Proactive Remediation.

Conclusion

We hope this post helps demonstrate the case for the more cloud connected ConfigMgr. But it goes without saying that enabling modern management with Intune and being able to rely on the tools made available via Co-management and Proactive Remediations help us take on more cloud centric postures in ConfigMgr and continue to derive value from it with additional infrastructure simplification. Part 2 of this post follows..

AD Joined Hybrid Windows 365 management in Intune

ClaudiaZH2021 — Sat, 11 Dec 2021 00:18:19 GMT

The Microsoft Windows 365 provides all the benefits of Windows, without any of the traditional hardware limitations. It is the most optimized Microsoft 365 powered compute experience delivered from Azure and managed by Microsoft Endpoint Manager interfaces – portal and associated Graph APIs. It is Microsoft’s best expression of Windows and M365 and is always secure and up to date. The Windows 365 is SaaS virtual desktops/apps which is provisioned instantly for licensed users. It can be accessed anywhere from any device and can scale with a user’s changing compute needs. AD Joined Hybrid Windows 365 machines have connectivity to customer’s on-premises network. In order to align with this feature, Windows 365 service needs of sight into the customer’s virtual network in Azure subscription that must have the connectivity to customer on-premises network. Hybrid AD joined windows 365 solution will be replaced by Azure AD joined zero trust architecture in future market soon.

Prerequisites

To manage AD-joined Hybrid Windows 365 in Intune, be sure the following criteria are met:

Azure subscription has been created for Windows 365 on-premises network connection.

The Windows 365 service needs line of sight into the customer’s virtual network (Vnet on the Azure subscription) that has connectivity to the customer’s on-prem domain.
Service account in on-premises domain should be created and synchronized to Azure AD.

Create on-premises network connection

Navigate to Microsoft Endpoint Manager Admin Center, go to “Devices\Windows 365” blade, choose “On Premises network connections”, Click “Create connection”, Input the connection name, choose Azure subscription in prerequisites, create or choose an existing valid resource group, choose Virtual network in prerequisites, input AD domain full name and service account, after “review and create”, the connection will be created successfully.

If the connection is created successfully, it will be showing “Status” as “Checks successful”.

Create Provisioning policies

Provisioning policy defines which on-premises network connections and what version Windows OS the Windows 365 provisioning process will pick up. Navigate to “Devices\Windows 365” blade, go to “Provisioning policies” tab, click “Create policy”, input policy name, choose the correct On-premises network connection which was created in pervious steps.

After click “next”, choose image type as below:

The final step is to target this provisioning policy to a security group as assignments, the security group will be added with Windows 365 licensed user alias as members.

After the provisioning policy is created successfully, under “Provisioning policies” table, the provisioning policy should be listed.

Now it is ready to provisiong Windows 365. If licensed user alias is added to above provisioning policy assignments security group in AAD, the provisioning process is kicked off right away without delaying. If there is no Azure deployments congestion, normally a Windows 365 can be provisioned successfully from 20-40 minutes. If the user alias is removed from the security group, the provisioned device will be in “Grace” period for 7 days and will be fully decommissioned after that. After the Windows 365 is provisioned successfully, the User will see the Windows 365 connection in remote desktop app as below:

The successfully provisioned Windows 365s show up in Windows 365 blade. These devices can be managed same as other physical devices in Intune.

Deploy apps and policies to Windows 365 from Intune

Since Windows 365s are all AD-joined Hybrid devices, Apps and policies deployment in Intune needs the deployment workload to be shifted from SCCM to Intune. Windows 365 doesn’t have identifier in AD domain attributes or properties, so we only can use device name convention to create configuration manager collection filter rule, then nest Windows 365 collections to co-management collections to shift policy and apps deployment to Intune:

Name convention query:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_Client_ComanagementState on SMS_Client_ComanagementState.ResourceId = SMS_R_System.ResourceId where SMS_Client_ComanagementState.Name like "CPC-%-%"

Client Management

saratc — Tue, 23 Nov 2021 15:18:13 GMT

Today we will discuss how client management is done internally at Microsoft. At a high level we will share how clients are onboarded, managed, and the custom reports used for tracking SLAs and KPIs.

Onboarding:

We have two environments so to speak; devices that are joined to a domain (AD) and devices that are joined to Azure Active Directory (AAD).

Domain Joined:

A Logon script deployed via group policy is used as the primary and only method for installing Configuration Manager client. Given that we support multiple regions, ADM templates are used to stamp regional specific parameters required for installing agent.

Command line: CCMSetup.exe /MP:XXXXXXXXXXX /MP:XXXXXXXXXXXX SMSSITECODE=XXX FSP=XXXXXXXXXXX CCMLOGMAXSIZE=2000000 CCMLOGLEVEL=1 DISABLESITEOPT=TRUE DISABLECACHEOPT=TRUE CCMLOGMAXHISTORY=10 SMSCACHESIZE=10000 IGNOREAPPVVERSIONCHECK=TRUE CCMEVALSENDALWAYS=TRUE

All domain joined devices with Windows OS version RS3 and above will onboard to Intune for leveraging Co-Management (Co-Mgmt) capabilities. ConfigMgr is used as primary management authority in this scenario except for the workloads like Compliance policies transitioned to Intune.

Fig 1: Current workload configuration

Azure AD devices:

All devices connected to AAD are onboard into Intune for management. Intune is the primary management authority in this scenario. We also deploy ConfigMgr client via App for supporting deploying win32 applications and to benefit from rich reporting capabilities.

Command line: msiexec /i "ccmsetup.msi" CCMSETUPCMD="CCMHOSTNAME=XXXXXXXXX.CLOUDAPP.NET/CCM_Proxy_MutualAuth/XXXXXXXXX SMSSiteCode=XXX CCMLOGLEVEL=1 CCMLOGMAXHISTORY=5 SMSCACHESIZE=10000 FSP=XXXXXXXXXXXXX /nocrlcheck" /qn

Monitoring and Metrics:

Monitoring ConfigMgr health is a critical aspect of client management. We track various metrics for monitoring agent health and reach daily. We also have to auto detect and remediate known issues – we keep expanding the functionality based on issues detected during investigations – if mitigation is safe, and issues can be detected programmatically. These remediations are performed using a logon script for domain joined devices. This method is used for tackling both client install failures and health issues. Below are a few most frequently triggered remediations:

WMI repository remediation
Policy provider issues
Provisioning mode configuration
Client registration issues
Dependent service misconfiguration (we see these often given the nature of our environment)

We recently started expanding this functionality to use Proactive remediation scripts in Intune to target Co-Managed devices. We capture telemetry via these scripts to understand issues as well as track effectiveness of these scripts and make improvements. You can refer to the blog my colleague recently wrote about how these capabilities can be used to various scenarios.

Agent Reach:

To ensure the coverage of ConfigMgr client meets the SLA (95%), we closely track over all reach by comparing it against overall discovered devices. For AAD devices, we compare them against overall devices registered to AAD. We use a few reports to track this, examples of the datapoints we monitor – figure 2 and 3 below.

Fig 2: Report to track client install status per domain in the last 24 hours

Fig 3: Reports for tracking onboarding methods. In this case most of them are auto upgrade since site is going through upgrade

Agent Health:

For tracking agent health, we look at several aspects like policy, heartbeat, and hardware inventory for tracking day to day trends; we call these operational metrics. For reporting health numbers, we rely on CCMEVAL data. We use a Power BI dashboard (fig:4) during daily standup calls for tracking and triggering investigations accordingly. Note that these are custom dashboards built on top of Power BI using transformations that aggregate data into Azure SQL.

Fig 4: Dashboard for tracking operational metrics

Co-Mgmt enables us to look at different data points proactively and remediate issues from Intune. Given that these devices are communicating both with ConfigMgr and Intune, it enables us to look at interesting datapoints like devices that are active in one system and not in the other and vice versa. We use the dashboard below to track some of these aspects. We will be expanding to add more datapoints to this in the future. In fig:5, Intune CoMgmt means Intune is primary management authority and SCCM CoMgmt means Configuration Manager is primary management authority.

Fig 5: Co-Mgmt. Devices data points

On a weekly basis we track below insights and share it with leadership, partners, and broader teams.

Fig 6: Weekly Insights

Log Collection:

As everyone can relate to, having the ability to capture logs is critical for understanding the issues at hand. In our environment we use various methods for capturing required logs without contacting users.

Using ConfigMgr Console using Client Diagnostics, this can be used for both domain joined and AADJ (Azure Active Directory join) devices
Through Just Enough Access (JEA)
Through Intune Client Diagnostics

JEA – Just Enough Access functionality for getting restricted access to remote machines. We implemented a custom module to enable a few functionalities like log copy and client remediations. Refer to JEA public documentation for additional information.

Conclusion:

I hope this blog gave high level understanding of how we track and address Client health and reach trends internally. Most of the reporting we have is built in-house using ETLs and ADF pipelines to capture aggregated data from both ConfigMgr and Intune to determine the trends, setup alerting and take appropriate actions. This is unique to our environment and will take considerable hours to maintain which is outside the scope of this post. We plan to cover in a future blog post. We are working towards expanding health and reach for devices managed by Intune as primary management authority across all platforms. We will plan to blog about it once operationalize it. Thank you for reading! Please do share feedback in comments section.

Dynamic Scaling of ConfigMgr Site Systems in Azure

Bankim Patel — Wed, 02 Jun 2021 16:40:35 GMT

This post covers the vertical scaling of ConfigMgr Site Systems in Azure – to realize efficiency gains made available by the elasticity of the Azure Cloud. The migration of the internal ConfigMgr infrastructure at Microsoft from on-prem to Azure has been described in a previous case study. We aim to describe in this post the efficiencies we have been able to drive by scaling ConfigMgr Site Systems such as the Management Point, Distribution Point and Software Update Point to “right size” based on client traffic and compute demands.

As the global scale of the Azure cloud continually expands, our team has been able to reap the associated benefits by seamlessly switching to newer VM SKUs. These typically offer better specs in the form of latest gen CPUs or potentially lower cost tiers, as seen with AMD SKUs. The VM resize involves a reboot/redeployment to the newer SKUs with little downtime and in some cases a prior request to Azure support to increase regional quota allocations. For our ConfigMgr Site Systems, this meant moving from the older F-series SKUs to the Fs_v2 series SKUs.

Client Traffic in the internal Microsoft environment typically follows a cyclical pattern where we observe CPU and Concurrent Connection Peaks early in the business day followed by a leveling off typically around afternoon hours. The rightsizing was aimed with this traffic pattern in mind, but our team initially limited the scope of the scaling solution to evenings and weekends to gather operational insights. Considering the example of Management Points, this meant that at the start of the business day our Site Systems would be scaled up to F8s_v2 to meet peak demands and when average CPU had been measured to be at a lower baseline level in the evening hours, the Site System would be scaled down to F4s_v2 or lower based on CPU load. The sections below describe the high-level design details of the scaling solution.

Runbook Overview

We use an Azure Automation PowerShell runbook to monitor various Virtual Machine groups. Each group typically has 3-8 VMs based on the Site System type and ConfigMgr Site/Region the VMs are located. For example, to handle client traffic in the Southeast Asia region, we have three VM groups for the DPs, MPs, and SUPs. The basic outline of the Runbook is located below:

For each VM group, the runbook will sequentially evaluate CPU load and the current SKU against a set of scale up and scale down thresholds. If the CPU is higher than the defined scale up threshold, say 90%, the automation will scale the VM up to the next SKU. Likewise, if the CPU is lower than the scale down threshold, say 40%, the automation will scale the VM down to the next lower SKU, else no changes are made.

The scaling logic allows us to ensure that there is only one VM per Site System type and ConfigMgr Site/Region that might be unavailable at a time. It also lets us set different configurations based on the Site System type. To allow multiple VMs to scale simultaneously and lower the time to fully execute the Runbook, we modified the logic to process each VM group in parallel. This allows VMs from separate groups to scale simultaneously while still adhering to the downtime requirement described previously. For more information about parallel execution, check out PowerShell Parallel Execution or PowerShell Workflows for Automation Runbooks.

Based on historical CPU and Connection trends, we found it useful to scale the Management Point VMs to F8s_v2 during business day mornings (around 6 am) to prepare for the inevitable traffic. Rather than letting each VM inevitably scale up during peak traffic resulting in VM downtime, we took a proactive approach by scaling up a few hours before peak traffic to ensure all client needs would be handled without those associated downtimes. Once the traffic decreases, the VMs would dynamically scale to a lower SKU as needed.

Log Analytics Query

At present, the most important metric for our Scaling algorithm is the current CPU load for the VM. Our current source of this data is a Log Analytics Workspace where the associated Perf counter is logged every 60 seconds. After querying for the data, we average the results over a specified timespan which gives a single numerical average for the CPU. We have found the CPU load a useful indicator of the utilization of a virtual machine and have not had to consider any alternate metrics such as Current Connections yet. Listed below is a sample Log Analytics query for getting the CPU load of a VM.

Perf | where Computer contains '<VmName>' | where (CounterName == '% Processor Time') and InstanceName == '_Total' | where ObjectName == 'Processor' | summarize CPU = percentile(CounterValue, 95) by bin(TimeGenerated, 1m), Computer, CounterName

Scaling a Virtual Machine

When performing the scale up/down operation, we initially suppress alerts for the VM, update the VM and log the VM Name, CPU load, Old Size, New Size, Start Time, and End Time in a SQL Table. We have observed the average downtime for a VM performing a size change to be around 1-2 minutes, with services coming online in the next 30 seconds. A great blog post to read for more information about resizing VMs can be found here: Resize a Windows VM in Azure - Azure Virtual Machines | Microsoft Docs. As each environment has its own business/availability requirements and Site System configuration, we are sharing a basic version of the Runbook code we implemented in the following link. The code can be modified as needed, but the crux of the scaling solution centers around the following snippet:

Get-AzVM -ResourceGroupName $resourceGroup -VMName $vmName if($cpu -ge 90) { $vm.HardwareProfile.vmsize = "<HigherVMSize>" } elseif($cpu -le 40) { $vm.HardwareProfile.vmsize = "<LowerVMSize>" } Update-AzVM -VM $vm -ResourceGroupName $resourceGroup

A Typical Automation Day

A typical day sees the MP groups with the most scaling events and our DPs and SUPs rarely see scale changes. We’ve mentioned how the MPs in a region (say Redmond) would be forced to scale up to 6 AM. As the day progresses, each MP can downsize to F4s_v2 or F2s_v2 if the CPU falls below a threshold. By the end of the business day, the MPs will almost always downsize to F4s_v2 as CPU load decreases and may even downsize again to F2s_v2 during the night when activity is lowest. At 6 AM the next morning, the cycle repeats, bringing the MPs back to the baseline size of F8s_v2.

The number of size changes that occur throughout the day will depend on how often you run the Scaling Automation runbook. You want to be responsive to changing client traffic and varying CPU loads, so we run ours every 12 minutes. The minimum amount of time allowed when linking the Automation runbook to a schedule in Azure is 1 hour, but we use a workaround to call it more often. We call the runbook from a webhook using a Scheduled Task on a VM. More information regarding this solution can be found in the following blog post: Start an Azure Automation runbook from a webhook.

Auto Scale Power BI Report

To track the history of VM changes, we created a Power BI report that pulls data from the SQL table where each SKU change is stored. This report allows us to filter across different parameters and track detailed VM SKU change events. This report allows us to monitor abnormal automation behaviors in a way that is visually appealing.

Cost Savings

Over the past few months, we have seen steadily increasing savings rates for the VMs due to adding more VM groups to the scaling runbook and refining the logic for our specific needs. In the month of March 2021, we were able to cut the costs of using VMs by 43%. To calculate this savings percentage, the predicted cost was based on how we handled VMs before implementing the autoscaling runbook, keeping all VMs at a specific SKU for the entire month. By comparing this to our actual costs for the month, which were 57% of that predicted value, we calculated a savings of 43%.

Future Goals/Conclusion

We aim to improve our scaling efficiency by investigating a switch to native Azure metrics and piloting the new Azure Monitor agent (preview). This would also enable us to overcome any potential latency issues when ingesting data into Log Analytics.

We hope you’ve found this post useful, especially if you are leveraging a cloud provider for your ConfigMgr Infrastructure. We’ve tuned the solution to meet our business requirements and shifting a portion of our Co-Management workloads to Intune has allowed us to tolerate brief periods of downtime on individual VMs during business hours. We realize complexity and requirements will vary across environments, but there may be cost savings to generate even if similar scaling is restricted to nights or weekends.

How to collect custom inventory from Azure AD Joined devices

MikeGriz — Thu, 03 Jun 2021 15:14:08 GMT

Kubilay Dagdelen on my team worked with several other folks to pull together a method for doing some custom inventory collection with Intune. There are some performance delays that can be encountered if over-used, but it can be handy at times.

ConfigMgr admins love extending hardware inventory and collecting data from Windows devices.
Did you know Intune can do the same?!
The answer is Intune PowerShell scripts! Also known as SideCar… IME… Intune Management Extensions…

Well, IME is just another channel that runs parallel to MDM that sort of acts like the ConfigMgr client. We deliver different features over this channel: PowerShell scripts, Win32 apps, Proactive Remediation scripts, Win32 app log collection…

Can you give us an example?
Maybe you are interested to know more about Win32_BIOS.
Run the following PowerShell one-liner on a device

Get-WmiObject -Class Win32_BIOS | select CurrentLanguage, Description, EmbeddedControllerMajorVersion, EmbeddedControllerMinorVersion, Manufacturer, ReleaseDate, SerialNumber | ConvertTo-Json -Compress

Script outputs the following:

Beautified:

{ "CurrentLanguage": "en-US", "Description": "N2EET43W (1.25 )", "EmbeddedControllerMajorVersion": 1, "EmbeddedControllerMinorVersion": 13, "Manufacturer": "LENOVO", "ReleaseDate": "20191028000000.000000+000", "SerialNumber": "12345678" }

Let’s create an Intune PowerShell script and deploy it to some users/devices to demonstrate Win32_BIOS data as an example.

Tip: <scriptId> is stored in the URL

You can access the data via the following Graph endpoint in graph explorer
https://graph.microsoft.com/beta/deviceManagement/deviceManagementScripts/<scriptID>/deviceRunStates?$expand=managedDevice

It turns out that we store the above-mentioned script output in a property on the service side. If you are familiar with Graph Explorer, then you can take a look at the results

In the property “resultMessage”:

How do I see the data from all devices?
Prerequisites:
Install-Module -Name Microsoft.Graph.Intune

You need one more script to retrieve your results from Graph…

Update-MSGraphEnvironment -SchemaVersion 'beta' Connect-MSGraph $result = Invoke-MSGraphRequest -HttpMethod GET -Url 'deviceManagement/deviceManagementScripts/b113448a-528a-4beb-b7d5-381a117d5184/deviceRunStates?$expand=managedDevice' | Get-MSGraphAllPages $success = $result| Where-Object -Property errorCode -EQ 0 $resultMessage = $success.resultMessage $objResultMessage = $resultMessage | ConvertFrom-Json $objResultMessage | Out-GridView

You can store the data in Log Analytics, SQL etc and visualize the way you want.
Enjoy!

So long, NAA

Bankim Patel — Tue, 27 Oct 2020 00:27:27 GMT

This post covers retirement of Network Access accounts (NAA) in the internal Microsoft environment, aided by simplified authentication to Management Point and Distribution Points in the form of Enhanced HTTP and related access scenarios.

Network access accounts have been used for several years now in current and past releases of Configuration Manager, as service accounts used by clients to get content from Distribution Points. ConfigMgr Consultants and Support Engineers can likely recite in their sleep the standard best practices of configuring a low rights service account for the NAA and not using the same account for Client Push purposes.

The arrival of Enhanced HTTP was well received by our ops teams as it brought with it the prospect of dropping the NAA in favor of token-based authentication. In a zero-OSD, all Autopilot world, this became one less credential to manage/rotate in our Key Vaults and yet another site-specific setting to no longer configure. It is important to mention this is a secondary benefit, as the ability to secure client communication without the overhead of PKI certs is the core value add of E-HTTP, amongst other benefits. Note: our colleagues on the dev team did caution us about “Run from DP” scenarios in legacy Packages likely not functioning with the absence of the NAA, but as we mainly leverage Applications which use download/execute by default – this was not of much concern.

The docs team has documented in detail the workflow a device follows to authenticate via Azure AD user or device token. But what about devices that cannot leverage AAD/PKI? This scenario is also supported by E-HTTP and the 2002 build extended this further by introducing the concept of an added Management Point issued token that a client can also use for CMG communication. This token can also be bulk provisioned for devices with no corporate network connectivity.

In classic 95/5 (80/20 for Sysadmins 🙂 ), the prospect of NAA removal after enabling E-HTTP in our environment required some validation to ensure that even a pure Workgroup device would not be affected.

In a lab enabled for E-HTTP, with two Site Systems:

MP1 (MP with ConfigMgr SSL Binding)

and MPDP2 (PKI based HTTPS MP/DP)

we see even during client setup (ccmsetup.log) that with no PKI cert, the Workgroup client gets site configuration/DP information from MP1 and uses token-based authentication against the MPDP2 (HTTPS) to get content.

We install the client on the device using this command: ccmsetup.exe SMSSITECODE=CM1 /mp:MP1.sccmtest.loc SMSMP=MP1.sccmtest.loc

Examining log snippets, we see the following:

CCMSetup.log:

Sending location request to 'MP1.sccmtest.loc' with payload '<SiteInformationRequest SchemaVersion="1.00"><SiteCode Name="CM1"/></SiteInformationRequest>' Host=MPDP2.sccmtest.loc, Path=/CCMTOKENAUTH_SMS_DP_SMSPKG$/CM100002, Port=443, Protocol=https, CcmTokenAuth=0, Flags=0x11304, Options=0xe0

Post client install, we see in ClientIDMgrStartup.log completion of client registration and indication that the self-prove token is now available. This is the build 2002 feature mentioned above:

[RegTask] - Client is registered. Server assigned ClientID is GUID:A-B-C-D-E. Approval status 1 Updated registration hint. Self-prove token is renewed.

In ClientLocation.log, we see the client also rotating over to the HTTPS Site System (MPDP2), despite the absence of a local PKI cert. At this point the client retrieves the CCM Token:

Getting CCM Token from STS server 'MPDP2.sccmtest.loc' Getting CCM Token from https://MPDP2.sccmtest.loc/CCM_STS Host=MPDP2.sccmtest.loc, Path=/CCM_STS, Port=443, Protocol=https, CcmTokenAuth=0, Flags=0x11204, Options=0x5c0

CCM_STS.log on MPDP2 shows entries indicating validation of the PreAuth/SelfProve token:

Incoming request URL: https://MPDP2.sccmtest.loc/CCM_STS Validated PreAuth SelfProve token. UniqueId: GUID:A-B-C-D-E. ClientKey: XYZ Validated CCM Auth header for client 'GUID: A-B-C-D-E’ Created SCCM token from self-prove pre-auth token

Now for a Content Request, perhaps for Software Center based app install. CAS.log on the client displays the various DP URLs returned:

Download started for content Content_8811d5c2-6028-4c53-bc15-032c212bc676.1 Location update from CTM for content Content_8811d5c2-6028-4c53-bc15-032c212bc676.1 and request {B10D4C07-1B97-4EDB-9A95-D3ACF97FC97A} Matching DP location found 0 - http://MPDP2.sccmtest.loc/sms_dp_smspkg$/content_8811d5c2-6028-4c53-bc15-032c212bc676.1 (Locality: SUBNET) Matching DP location found 1 - http://MPDP2.sccmtest.loc/nocert_sms_dp_smspkg$/content_8811d5c2-6028-4c53-bc15-032c212bc676.1 (Locality: SUBNET) Matching DP location found 2 - https://MPDP2.sccmtest.loc/ccmtokenauth_sms_dp_smspkg$/content_8811d5c2-6028-4c53-bc15-032c212bc676.1 (Locality: SUBNET)

And ContentTransferManager.log shows client switching over to the correct HTTPS URL and using the CCM token:

CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} (corresponding DTS job {A14CFFE4-C27E-4DB1-B2EB-B9FE4C043994}) started download from 'http://MPDP2.sccmtest.loc/SMS_DP_SMSPKG$/Content_8811d5c2-6028-4c53-bc15-032c212bc676.1' for full content download. CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} switched to location 'https://MPDP2.sccmtest.loc/CCMTOKENAUTH_SMS_DP_SMSPKG$/Content_8811d5c2-6028-4c53-bc15-032c212bc676.1' CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} entered phase CCM_DOWNLOADSTATUS_DOWNLOADING_MANIFEST CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} entered phase CCM_DOWNLOADSTATUS_PROCESSING_MANIFEST CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} entered phase CCM_DOWNLOADSTATUS_PREPARING_DOWNLOAD CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} entered phase CCM_DOWNLOADSTATUS_DOWNLOADING_DATA CTM job {E97B1E9D-CA16-4E86-82E1-BE6EE5BACB44} successfully processed download completion.

Note that in this scenario as well, the PKI based HTTPS DP is used. So, there you have it – evidence that the client leverages E-HTTP at the start and can then even communicate with PKI based Site Systems via token-based authentication.

The inner workings are likely best left for discussions with the dev team at an upcoming AMA/conference, but the log snippets and the previously documented workflow essentially reveal the CCM Token to be the primary identity token for the client. The device/user could present either AAD, bulk registration or self-prove/PreAuth token to the MP and get back the CCM token. Any other content access tokens can be acquired thereafter.