Todays blog post is about managing Windows 365 Link devices with Microsoft Intune. I recently got my hands on a Link device as preparation for my employers Wortell Ready event. It was meant for a demo during my session about Windows 365, but if you get your hands on such a popular, but poorly available, device you need to play around with it.
In this post I share my thoughts on managing the device with Microsoft Intune, because although Windows is running on the device, we can not target just all existing policies we have in Intune to these Link devices.
I assume you know what a Link device is, otherwise you wouldn’t be reading the post, but for who don’t know:
A Windows 365 Link device is a physical Windows PC that connects directly to a user’s Cloud PC in Windows 365.
It lets users move seamlessly between the local device and their Cloud PC while keeping the Cloud PC as the main work environment.
The device runs a version of Windows 11, but with the Windows CPC SKU. We don’t have access to anything on the local device but the sign-in screen when the device starts.
The device is secure by design, with a Trusted Platform Module (TPM), BitLocker drive encryption, Hypervisor Code Integrity and Microsoft Defender EDR Sensor.
Requirements for managing the Link
To enroll and manage the device with Microsoft Intune, we have some requirements. The device itself needs to be Entra joined and enrolled in Intune. As Autopilot is not supported for Link devices, we need to have the device enrolled by the end-user or an IT admin with a Device Enrollment Manager (DEM) account. I would prefer to enroll the device with a DEM account, so IT is able to enroll the device before handing out the device to the end-user. This would also prevent the Link device from showing up in the list of devices of the end-user. After joining to Entra we want to automatically enroll the device in Intune, which requires some configuration and the right licenses.
The Link device can only be used in combination with Windows 365 Cloud PCs for which Entra ID single sign-on (SSO) is enabled.
Optionally we can register the corporate device identifier in Intune, to make sure the device is enrolled as corporate device (when an end-user enrolls the device).
The requirements on a row:
- Allow users to automatically enroll their devices in Intune (configured in Entra)
- Microsoft Intune and Entra ID Premium license
- Entra ID single sign-on (SSO) enabled on Windows 365 Cloud PC
- Optional: Register corporate device identifier
Enrollment decisions
As said Windows Autopilot is not supported for Link devices, so we need to come up with a different approach. Although the enrollment of a Link device is no rocket science and with the right permissions and license is possible, I would opt for using a DEM account. Here are some considerations for making a decision for your enrollment:
| Considerations | Admin driven onboarding | User driven onboarding |
| The device is for multiple different users. | Yes | |
| The device is for one user. | Yes | |
| Users aren’t allowed to join or register devices. | Yes | |
| Devices are shipped directly to users. | Yes |
Entra device group
As we can’t just target all our existing Intune configuration and compliance policies, and support for installing apps is not supported at all, we need to make sure we have an Entra device group ready for usage in Intune.
We can create a dynamic Entra group based on device model. We could also use device name, as all Link devices will have a name starting with WCPCD, but what if somebody names his device WCPCDxxx?
So I opt for using the rule syntax: (device.deviceModel -eq “Windows 365 Link”)
Intune assignment filter
Everybody working with Intune knows that processing Entra dynamic groups can sometimes be very slow. Therefor it might be preferred to use assignment filters in Intune, instead of a device group.
We can create an assignment filter in Intune using the device model, like we did for the device group. We could also use the Operating System SKU, as that’s something special for the Windows Link device: Windows CPC (WCPC).
The syntax for both options:
(device.model -eq “Windows 365 Link”)
(device.operatingSystemSKU -eq “WCPC”)
When using the SKU, we can simply select the correct SKU from the dropdown list under value.
Compliance policies
Only the Device Health compliance settings apply to the Link device. At least that’s written in the docs. But as the device is also equipped with a Trusted Platform Module we can also check on the TPM, although that is located under System Security.
Configuration policies
Windows 365 Link runs a small purpose-built Windows based operating system called Windows CPC. Therefore, device configuration for Windows 365 Link follows the same process as Windows in general with two main differences.
- Windows 365 Link can only be Entra joined, so Active Directory Group Policy isn’t supported for the device.
- Windows 365 Link supports a subset of Windows configuration service provider (CSP) policies.
The above comes directly from the Microsoft learn website, where you could also find the list of supported CSPs.
Let’s discuss a few settings which are interesting to configure on our Link device.
Privacy settings is the first one. On the Link device the end-user has the ability to control the privacy settings for Location, Camera and Microphone.
The end-user is able to switch these off, although in most circumstances we should leave these on for the best user experience. The location service for example is used to determine the location of the device and with that information sets the correct time zone on the device.
We have the option to control these privacy settings with a Settings Catalog profile. We can configure the settings to Force allow, so the user can’t (accidentally) switch this off.
Time zone.
Configuring the time zone is also something which is supported on Link devices. If for some reason the time zone is not automatically set right when the location is allowed to be used by an app, we can also force the time zone on Link devices.
Network connection.
A network connection is of course important when working with a Cloud PC.Link devices support several configurations for wired and wireless connections. As I only have a simple Wi-Fi network at home, I was only able to (successfully) test a basic Wi-Fi profile using Intune.
Screen time-out.
By default the screen connected to a Link device turns off after about 5 minutes. I guess it’s a good idea to expand this a little by using another Settings Catalog settings, which is found under System, Power Management.
Delivery Optimization.
Delivery optimization is also in the list of supported configurations. And although there is not much to test around DO on my small network, the policy settings where all applied successfully.
Use security key for signin.
Passwordless is the future. On shared devices, which the Link still is, working with a FIDO2 security key is great. Just connect the key when it’s an USB version, or tap the key on a NFC reader (no not included in the Link unfortunately) enter a PIN or even better use the fingerprint and sign-in is initiated!
Definitely something to consider when working with a lot of Link or other type shared devices in your environment.
Endpoint Security Policies.
Most of the Endpoint Security policies are not applicable for Link devices. But we can onboard Link devices to Defender for Endpoint.
Updates.
Windows 365 Link devices update automatically using the same Windows Update Services used by Windows 11. The Windows 365 Link device checks for updates periodically.
When an update is available and detected by a device that is powered on, the device:
- Silently downloads the update.
- Installs the update during the next reboot or at 3 AM when the device isn’t in use.
Driver and firmware updates occur separately from OS updates, and are also applied during a reboot.
If the device receives driver/firmware updates and OS updates at the same time, both updates occur over one reboot.
More info on the update behavior is found on the Microsoft docs.
What does it look like from the IT admin perspective
When the device is enrolled in Intune, either by the end-user or with a DEM account, the device shows up like any other Windows device.
I used a DEM account and as you can see the device is corporate owned.
It shows compliant and as we can see it’s running the latest Windows 11 24H2 version.
The model is shown as Windows 365 Link and SKU family is WCPC.
Not all device actions are available for Link devices. We can’t trigger an update for Windows Defender security intelligence or perform a BitLocker key rotation. But we are able to send a wipe request and are even able to collect diagnostics when needed.
An overview of the hardware as shown in the Intune portal.
We can see the compliance policy I created shows Compliant.
The three Device health settings and the TPM show Compliant.
The configuration polices I created specifically for the Link devices are all Succeeded.
A policy which was still targeted to my Link device was a Windows Update ring policy. It shows about all settings are not applicable on the device.
And as last, the device is also onboarded to Defender for Endpoint.
What does it look like from the user perspective
When the device is started the sign in screen is shown.
In the low right corner we have access to some controls, like Wi-Fi, Bluetooth and the privacy controls.
As written before, the available privacy controls can be switched off.
But when we force the controls to allow, the controls are greyed out.
By default we are able to sign-in with a username and password (if needed including the possibility to perform MFA).
But when we allow security keys, we get an additional sign-in option on the sign-in screen.
Sign in to your Cloud PC when using a FIDO2 security key works flawless as you can see in the below video.
That’s it for this post.
Thanks for ready!
