Windows 365 Boot
Hi folks – Mike Hildebrand here! It’s the July 4 th holiday here in the good 'ol USA and happens to also be our country’s 250 th birthday … and where I live, that means it’s probably hot. VERY hot. So, I’m taking some time to enjoy the A/C and type up a ‘cool’ post about a ‘cool’ solution. In the land of Windows 365, there are a couple of physical endpoint connectivity options – the Windows App or browser from any device and thin-client or other purpose-built devices, like our own Link (and one soon coming from Asus). We also have another option called Windows 365 Boot. In this nifty little situation, we take a full-throated Windows 11 device and apply policy from Intune to transform the shell and other settings into a Link-like experience. NOTE: For a long time, the Boot configuration process was only configurable via a ‘black-box’ guided flow in the Intune portal – and that works just fine. However, after an update of docs and the Intune Settings Catalog, the W365 Boot configurations can now be hand-carved like all of your other Intune configuration policies. Recently, I was part of a customer conversation where they had a substantial quantity of Flex Dedicated CPCs used by rotating call center staff and accessed from a fleet of Windows 11 PCs deployed at hot-desk stations. They wondered about a model to simplify and streamline access directly to the CPCs, bypassing the local Windows OS, which wasn’t used/needed and sometimes caused confusion. The physical devices were still ‘current’ and had a lot of life left (i.e. warranty coverage, driver and firmware support, parts availability, etc.) - and due to the price-jumps of new devices, it made ‘dollars and sense’ ( 🙂 ) to leverage that investment and re-purpose them. They also wondered if they could use Autopilot in ‘Self-deploy’ mode to further automate the deployment process for these endpoints. “Let’s try it out” I proposed a rapid, off-the-cuff ‘right now’ PoC to try out the W365 Boot scenario in their environment and they were up for it. These days, it’s common and easy to perform carefully controlled ‘production pilots’ to more accurately validate the proposed experience. NOTE: Since the customer already had Entra, Intune, and modern management in steady-state operations for quite some time, we were able to make this idea very real, very fast. We reset a few of the test PCs they use for their hot-desks and uploaded them into Autopilot via the Get-WindowsAutopilotInfo PowerShell script and the -online switch. Entra – Create a Device Group We created a device group in Entra for the PoC Boot devices and added the Autopilot-uploaded test devices into it as members This group was used by Intune to target several different elements of the PoC: o An Autopilot Self-deployment Profile - for an almost zero-touch rollout o An Enrollment Status Page (ESP) profile - to prevent access to the Boot device until the Windows App is installed o The Windows App – used by the Boot device to connect to Cloud PCs o A W365 Boot Configuration Profile to transform the Windows 11 OS into a W365 Boot device Intune - Autopilot Self-deploy Profile We created an Autopilot ‘self-deployment’ profile via Intune, to automatically enroll the physical endpoints at the call center desks. Autopilot self-deploy requires very little interaction at the endpoint - plug in power, connect to network and turn it on. o There are some specific URLs and other requirements for Autopilot Self-deploy devices so be sure to check this (i.e. you can’t use Hyper-V VMs) https://learn.microsoft.com/en-us/autopilot/self-deploying Intune – Enrollment Status Page We created an ESP targeted at the device group to block access to the Boot devices until the Windows App is installed. Intune – Windows App They already deploy the Windows App to ‘All Devices,’ so this step was easy 😊 The key thing here is make sure it installs in the ‘System’ context: Intune - Boot Device Configuration Policy We created a very simple Configuration Policy (two settings from the Settings Catalog – that’s it) in Intune to transform these self-deployed endpoints into “Shared PC Mode” Windows 365 Boot devices. These have minimal ‘end user’ configurations/apps because they boot to the W365 purpose-specific ‘cloud shell’ – which allows the user to sign in to the Boot device and be directly SSO’d into their CPC. NOTE: The ‘Boot to Cloud PC Enhanced’ setting includes many other settings/behaviors but they’re all bundled up which makes it super easy to deploy this NOTE: If the ‘Personalization > Company Name’ setting isn’t used, you’ll see ‘Cloud PC’ at the sign in screen Self-deploy…oh the joy! Plug it in; turn it on … Autopilot Self-deploy OOBE screen, followed by a brief ESP NOTE: As part of the Autopilot deployment profile, a device naming template was applied and the devices were renamed; this was reflected in various portals/UIs Before: After: “So, what does it look like for the users?” I thought you’d never ask! A PIN, a touch and TA DA! NOTE: The org already was using FIDO2 for these users, so they insert their FIDO2 key to the Boot device, enter the PIN for it, touch it for ‘proof of presence’ - and that’s it. No long username to type in; no long password to remember/type; no additional prompts. The users glide right through to their CPC desktop. NOTE: Hello for Business (H4B) is supported for the “Dedicated Mode” Boot deployment option but since we used the “Shared PC Mode” setting, where H4B is not supported, we didn’t test. Maybe official H4B support will come later to Shared PC Mode, but given how easy FIDO2 is, and the fact that the target users already use FIDO keys, we didn’t spend any more time on H4B. At the end of the shift, disconnect the session from the CPC desktop to get back to the Boot sign in screen: A few FAQs “What if a user has more than one CPC?” Connection Center is supported via Boot – here’s one of my demo users, using Boot w/ more than one CPC: Further, you can select ‘Connect automatically’ from the three dots of a specific CPC’s card; then you’ll always bypass the Connection Center and get SSO’d right into that one. o To get back to the Connection Center from the Cloud PC, you can use the hotkey combo of <Ctrl> + <Windows key> + <Up Arrow> o BONUS SECRET HOTKEY COMBO (just between us) – For detailed connection info, from the Cloud PC: <Ctrl> + <Windows key> + <Down Arrow> “Can I customize the look and feel of the Boot sign in experience?” Yes – There are policy settings for a custom icon, company name and wallpapers to help differentiate Boot devices from other PCs/devices. o Personalization CSP | Microsoft Learn TIP: those docs indicate needing to use a URL for files – you can use this syntax for local content already on the device: file:///C:/Folder/File.jpg There you have it, folks … Windows 365 Boot (or, DAS BOOT!! as I like to sometimes yell) … in the form of a quick PoC. P.S. A special shout-out is in order for Mr. Liu for his assistance and appreciation of the Boot scenarios. Stay cool out there… HildeWindows Hello for Business - Registered Methods and Last-used Method
Hi folks – Mike Hildebrand here! Today, I bring you a short post about gaining more awareness of Windows Hello for Business (WHFB) configuration information from across your fleet of Windows PCs. Over time, we’ve improved the built-in "Authentication Methods" reporting in the Entra portal. As far as WHFB goes, at this point, the Entra Portal provides high-level counts of WHFB registration and usage: However, we IT Pros are a curious bunch, always looking for more information and more detail about what’s going on in our enterprise. A while back, after being asked by numerous customers for a way to get more details about their WHFB deployment, I published a post about using Entra sign-in log data and a custom Log Analytics Workbook to obtain that information. That post/report has proven helpful - from Entra sign in logs, we can determine who is using WHFB, from which device (and there’s even a map to show where in the world it’s happening). Nice. But that's only the 'cloud-side' of the situation - there are almost always two follow up questions that can only be answered from the endpoint: What WHFB methods has a user registered on the endpoint(s)? PIN only? PIN + fingerprint? Face? Which WHFB method was last used by a given user on a given endpoint? Ask, and yee shall receive Here are two easy/quick Intune Proactive Remediation detection scripts you can use that send configurations to a Windows endpoint and retrieve the local device details (via reg-values) around WH4B enrollment methods and the last-used WHFB method. NOTE: In my 12 days of Christmas blog-a-thon, I posted about creative uses of Intune Proactive Remediations. Once again, thanks to Marius Wyss and his core scripts to collect the WHFB registration and 'last used' info from local endpoints. They’re the real magic here. !! CAUTION !! There is PowerShell code involved here. Due diligence is required on your part. Raise your right hand and read this out loud: “Like everything else, I will thoroughly test this and all code/changes that I work with before I deploy to production. I will document the before-change state to ensure I can revert any changes I make.” CODE DISCLAIMER – These sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims 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 Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be 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 sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. REMINDER/NOTE - When using your scripting editing tool of choice, always be aware of any additional spaces or odd quotation marks or other issues that may result from edit/copy/paste. “Enrollment Types” Detection The ‘Enrolled Methods’ script from Marius o Intune-Remediation-Scripts/WH4B/Enrolled Methods at main · MrWyss-MSFT/Intune-Remediation-Scripts · GitHub o My Remediation Script Settings: o My results: “As of 2/2/2026 at 9:40 AM, Adele registered a PIN (default/required) - a face - and a fingerprint - for WH4B on the SURFACEPRO5 device” “Last Used Method” Detection The ‘Last Used Method’ script from Marius o Intune-Remediation-Scripts/WH4B/Last Used Method at main · MrWyss-MSFT/Intune-Remediation-Scripts · GitHub o My Remediation Settings: o My results: “As of 2/2/2026 at 9:40 AM, Adele last used a face/camera for WHFB on the SURFACEPRO5 device” Additional Examples of Results Enrollment Types Registered o NOTE: Remember, a PIN is required, so where you see ‘Fingerprint configured’ in the output, it means ‘PIN + Fingerprint’ Last-used method There you have it folks - by combing these two Detection Scripts with the Log Analytics Workbook mentioned at the start of the post, you have a solid solution for ‘end to end’ WH4B reporting. HildeWindows 365 Link – Deployment Planning, Setup and Enrollment
Introduction and Initial Thoughts The Windows 365 Link is a neat little purpose-built device, designed to enable easy deployment and simple, secure access to your Windows 365 Cloud PCs. The Link device is a ‘last mile’ endpoint device; there are pre-requisites that need to be in place in Intune, Entra and Windows 365 for both deployment of Link, as well as on-going use of Link to access Cloud PCs. In many cases, where Intune, Entra and Windows 365 are in ‘Production’ use in typical enterprise environments, many/most of the pre-reqs will already be met – but not always. Lastly, it is easy to forget that “Entra Join” and “Intune enrollment” are separate backend actions, occurring separately, in separate services and with different limits and controls All that to say, your current tenant configurations might allow you to successfully deploy Link devices, right now. If you’re feeling lucky, give it a try; otherwise, read on… Deployment Model – User-driven or Admin-driven User-driven – a given end-user goes thru OOBE and moments later, device is Entra joined, and Intune enrolled. The user is passed right into her CPC (or the ‘CPC chooser’ if she has more than one assigned). IMPORTANT: If Link is enrolled this way, by a typical end user: It will be listed (and renamable and resettable) in that user’s Company Portal device list. If the Link device is going to be shared, you might not want the enrolling user to be able to reset or rename it as that could impact others use of the Link device. Link devices start off as ‘personal’ Windows devices. You may need to adjust your Intune tenant’s Windows device platform enrollment restrictions to accommodate for this. Otherwise, you’ll probably encounter this failure during enrollment: To address this, you can either: Upload a “Corporate device identifiers” CSV file into Intune with the Link device info (probably the simplest way to deal with this situation): OR Set the default policy to “Allow” personally owned Windows devices to enroll (not common in enterprise environments) OR If you’ve set the default policy to “Block” personally owned Windows devices from enrolling (common in enterprises): You can create a subsequent “Device Platform Enrollment Restriction Policy” and set the Windows platform to “Allow” personally owned devices, then assign the Policy to ‘All Users’ (or a group of users) and use an Intune filter (discussed further below) to Include the Link devices Admin-driven - a DEM ID is used to go through OOBE and moments later, device is Entra joined and Intune enrolled and then the device is ready for users to access their CPCs DEM IDs are ‘normal’ Entra IDs that are marked specially in Intune and are: o Limited to the Entra join settings defined in the Entra portal o Limited to enroll up to 1000 devices into Intune - but not bound by the Intune device enrollment limit settings defined in the Intune portal o Exempt from Intune “Device Platform Enrollment Restrictions” Because of these conditions and depending on your tenant settings, you might need to create more than one DEM ID if you need to deploy 100s or 1000s of Link devices (maybe create “one DEM ID per location” or “one DEM ID for each “batch” of Link deployments or something similar). Also, consider your DEM ID naming standards (i.e. DEM-LNK-01) and be sure to have processes in place to exempt the DEM IDs from being cleaned up/purged; deleting DEM IDs used to deploy active devices is a no-no: NOTE: Since DEM IDs generally don’t have a CPC provisioned/licensed, there is an error after the OOBE/Entra join/Intune enrollment completes – just click ‘Sign out’ and the link will return to the Sign in screen: Review Existing Tenant Configurations Entra settings Limits to Entra Join device counts- limits apply to all users (incl DEM IDs) NOTE: ‘Custom’ can be any value up to 100: Authentication Methods – managed via Entra; apply to both enrollment of the Link, as well as day-to-day use to access Cloud PCs For enrollment, username + password is the default but you can use others by clicking ‘Sign-in options’ on the OOBE screen (i.e. a FIDO2 key): For day to day use you can use two options (a) Web sign in – by default, and out of the box, username ('Email) and password is available (b) FIDO2 key – you’ll need to enable the “Use Security Key For Signin” setting via Intune and target the Link devices before the security key icon/option will show up. Intune settings Limits to Intune enrollments – limits for users (up to 15); DEM IDs ignore these limits (each DEM can enroll up to 1000 devices) Additional Considerations and FAQs Link device names can’t be customized/edited during deployment, but the devices can be renamed via Company Portal or the Intune Portal, after deployment, if desired: “CALL-CTR-01” “ALEXW-LNK-01” “Do Link devices on-board to Microsoft Defender for Endpoint?” If your existing Intune tenant is configured to on-board devices into MDE, then yes However, the MDE agent, AV settings, etc. are NOT active within the OS – you’ll just see a device record in MDE with some device telemetry “Do I need to configure Link devices for Windows Update settings, rings, etc.?” No, the Link OS has local Windows Updates settings defined to check for OS and firmware Updates, each night at 3:00 am local time. If the device is in a ‘sleep’ state, the OS will wake itself and check for Updates, including firmware. NOTE: this wakeup only checks for Updates – it doesn’t wake the MDM stack in the OS nor check-in to Intune if it’s in a ‘sleep’ state. NOTE: a manual check for Updates can be done from the device “What are the most-common policy settings that aren't OS defaults?” The following common power and privacy settings can be changed via Intune as shown: Set the device’s 5-minute default screen time out (set to 1 hr/3600 seconds in the policy below) Set the device’s location service to discover and auto-set the local-to-the-Link time zone Set the device’s Power Management settings to prevent it from going to ‘sleep’ IMPORTANT: As mentioned above, a Link that’s in a ‘sleep’ state isn't remotely admin-manageable from the Intune portal “How do I create an Assignment Filter for Link in Intune?” “Can I turn off physical capabilities on the device?” Yes - take a look here for UEFI controls to manage ports and configurations at the firmware level Manage firmware settings for Windows 365 Link devices. | Microsoft Learn “Does SSO work to get me signed into the Link and right into my Cloud PC?” Indeed, it does! Just make sure SSO is enabled and working for the CPCs Realize this requires more than just the checkbox in the CPC Provisioning Policy; review additional SSO setup Unbox and Connect In the box is the device, a power brick and a power cord Ports Front 1 - standard headphone jack 1 – USB-A port Power light Power button Back 1 - USB-C port 2 - USB-A ports 1 - DisplayPort 1 - HDMI port 1 - RJ-45/LAN 1 - Power jack Here's my desktop setup for this article: En'Roll the Bones After plugging it all in, turn it on and at OOBE, click ‘Next’ NOTE: You’ll see the Wi-Fi connection UI if not using a physical network cable Enter ID and pwd or click ‘Sign-in options’ for different sign in method (i.e. FIDO2): NOTE: Even though ‘Domain join instead’ is listed there as a Sign-in option, it doesn't work and isn’t supported For those more inclined to 'Moving Pictures' ... Full enrollment + Link Sign-in + CPC SSO + disconnect - NOTE: this first vid SEEMS 'long' but I'd argue it's actually amazingly fast (Entra Join + Intune Enrollment + CPC sign in + close Evernote + Disconnect) ... ~1 minute and 30 sec 😎 Link Sign-in + CPC SSO + Disconnect ~30 seconds NOTE: Right-click the vid > 'Refresh' to watch again A Few Other Resources Setup vid (first 6 min are overview; setup starts around 6 min mark) https://www.youtube.com/watch?v=joec9L6EeqU&t=4s Docs - https://learn.microsoft.com/en-us/windows-365/link/ That's a Wrap! If you can't tell, I think the Link is a great device that continues to expand the Windows 365 solution. I hope these details help you as you try them out in your environment. Drop a note into the comments and share how your Windows 365 journey is going. Also, a couple of shout-outs - AJ for allowing me to 'borrow' the Link device (good luck getting it back); Dan Ram for validating scenarios and details; Mr. Shannon and Matt A. for their Link help and Brandon Wilson for helping (as always) w/ blog snafus. Cheers! HildeWindows 365 Enterprise – Points of Clarification and PoC Proven Practices
It took me a while to get my head around some of the technical aspects of Windows 365 Enterprise. Here, I'll share my own confusions, some common questions encountered in the field and tips for success with Windows 365 Enterprise. I've also included a planning document to help plan your efforts and a high-level visual aid.
