anyweb

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } here's the full reply from my chat with Copilot, you should try it too Short answer: yes — your boundary configuration is very likely the issue. Using only Active Directory Site boundaries can absolutely cause exactly what you’re seeing: Clients resolve a boundary But don’t get a valid DP or fallback DP assignment Result = updates sit at 0% downloading ✅ Why this is happening SCCM content download (including updates) depends on: Client is inside a boundary That boundary is part of a boundary group That boundary group has a Distribution Point (DP) assigned With AD Site boundaries only, problems occur when: AD Sites are not accurately mapped to IP subnets (very common) Clients’ IP ranges are not tied to the correct AD site Subnet definitions in AD are missing or incorrect 👉 Result: Clients may: Fall into no boundary Fall into a boundary group without content locations Try to download from a DP they cannot reach Sit at 0% downloading indefinitely 🔍 Your specific situation Your IP ranges: 192.168.0.0 172.20.0.0 172.10.0.0 172.40.0.0 But you're using: ✅ Active Directory Site only 🚨 Problem Unless all these IP ranges are properly mapped in Active Directory Sites and Services, SCCM cannot correctly assign clients. This is extremely common in environments where: Networks expanded over time AD Sites weren't kept updated Multiple IP ranges exist in one logical site ✅ Recommended Fix (Best Practice) ✔️ 1. Add IP Range Boundaries Yes — you should absolutely create IP Range boundaries for each of your ranges. Example: Boundary Type Range IP Range 192.168.0.1 – 192.168.0.254 IP Range 172.20.0.1 – 172.20.0.254 IP Range 172.10.0.1 – 172.10.0.254 IP Range 172.40.0.1 – 172.40.0.254 👉 Adjust ranges appropriately to your subnet masks. ✔️ 2. Add them to the correct Boundary Groups Put all new IP range boundaries into your existing boundary groups Ensure each boundary group: ✅ Has a DP assigned ✅ Has site assignment enabled (if needed) ✔️ 3. Leave AD Site boundaries (optional) You can keep them, but: 👉 Best practice: Use IP range boundaries as primary Use AD Site boundaries only if you trust their accuracy 🔧 Additional things to check ✅ Check Boundary Group settings Verify: DP is assigned: Administration → Hierarchy Configuration → Boundary Groups Under References tab: ✅ Distribution Points listed ✅ "Use this boundary group for site assignment" if applicable ✅ Check fallback configuration If clients are failing to find content: Enable fallback (optional, but helpful) Configure: Neighbor boundary group relationships Fallback time (e.g., 20–60 minutes) ✅ Verify client logs On one affected machine, check: LocationServices.log Look for: Boundary detection Assigned boundary group DP location requests ContentTransferManager.log Look for: Stuck download attempts CAS.log Look for: Content location failures DataTransferService.log Look for: BITS download issues 🧪 Quick validation test On a problem client: Run: PowerShell ipconfig Show more lines Then check: PowerShell nltest /dsgetsite Show more lines 👉 Compare the AD Site vs actual IP If: IP doesn’t match AD Site mapping → confirmed root cause ✅ Expected result after fix Once IP boundaries are added: Clients correctly map to boundary groups SCCM returns valid DP locations Updates move from: 0% downloading → downloading → installing 💡 Pro Tips (real-world SCCM guidance) ✅ IP ranges are the most reliable boundary type ❌ AD Sites are often neglected → unreliable ✅ Always verify with logs, not assumptions ✅ If “0% downloading” appears → it's almost always boundary/content location ✅ Final Answer Yes — relying only on Active Directory Site boundaries is very likely causing your issue. 👉 You should: Add IP range boundaries for all your networks Associate them with your boundary groups Ensure DPs are correctly assigned

a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } from Copilot. 1. Add IP Range Boundaries Yes — you should absolutely create IP Range boundaries for each of your ranges. Example: Boundary Type Range IP Range 192.168.0.1 – 192.168.0.254 IP Range 172.20.0.1 – 172.20.0.254 IP Range 172.10.0.1 – 172.10.0.254 IP Range 172.40.0.1 – 172.40.0.254 👉 Adjust ranges appropriately to your subnet masks. ✔️ 2. Add them to the correct Boundary Groups Put all new IP range boundaries into your existing boundary groups Ensure each boundary group: ✅ Has a DP assigned ✅ Has site assignment enabled (if needed) ✔️ 3. Leave AD Site boundaries (optional) You can keep them, but: 👉 Best practice: Use IP range boundaries as primary Use AD Site boundaries only if you trust their accuracy

Introduction I’m sure by now that we are all aware of the coming changes to Secure boot certificates as documented by Microsoft here. To cut a long story short, when Secure Boot was introduced by Microsoft back in 2011 or so, they secured it with some default certificates which are set to expire in June 2026. Secure boot checks the bootloader and verifies it’s digital signature, if it’s trusted it allows it to run, otherwise it blocks it, which is a good way of blocking rootkits, bootkits and other low-level firmware attacks. Historically speaking Secure boot became part of UEFI 2.0 specification in January 2006, but Microsoft started rolling it out in 2011 including distributing the first Secure Boot signing certificates in 2011. These were later released to mainstream computers with the release of Windows 8 in October, 2012 where Microsoft required OEMs (Original Equipment Manufacturers) to enable Secure boot and ship systems with UEFI mode enabled. The original 2011 secure boot certificates were designed with a 15 year lifecycle, and in 2023 Microsoft introduced new 2023 certificate authorities. So here we are, all those years later, updating the bios (firmware) of modern laptops and desktops to ensure that they are capable of updating/supporting the new certificates prior to them expiring. There are plenty of good blog posts out there today showing you how to best deal with the Secure Boot certificate problem, but they are really focusing on supported, modern hardware, below are some examples. https://blog.mindcore.dk/2026/04/secure-boot-certificate-update-intune/ https://joymalya.com/intune-secure-boot-2023-certificate-update-rollout-part-1/ https://pureinfotech.com/windows-11-secure-boot-certificates-expiring-june-2026/ https://techcommunity.microsoft.com/blog/windows-itpro-blog/secure-boot-playbook-for-certificates-expiring-in-2026/4469235#community-4469235-_option2 What about older hardware ? But where does that leave older hardware that does support UEFI and secure boot, and should they be turned off/disposed of ? Security experts would most likely say yes to the latter question as they’d be wide open to rootkits/bootkits which is a painful reality when you consider the cost of new computers today thanks to the AI boom. I’m actually writing this article on an old Lenovo T570, which technically is old, it was released in 2017, but has been updated with Windows 11 25H2, and 32GB ram. It’s not the snappiest but it works fine for what I need. I looked at Microsoft Intune’s infamous secure boot status report and it showed me lots of red x’s for my older hardware even though I was already pushing out remediation scripts in my Intune lab to deal with the Secure boot certificates expiry mess. The following were looking sad: Lenovo T570 Dell Optiplex 9020 Microsoft Surface Pro 2 You can access this report in the Intune console by clicking on Reports, Windows Autopatch, Windows quality updates, Reports, and finally selecting the secure boot status report. You can see the details of the report that I ran below, the green arrow shows my Lenovo T570 is not up to date for any of the 4 certificates listed in the report. So I posted a tweet on Twitter (yeah, that’s what I call it) and got some instant feedback, which is the reason for this blog post. In the screenshot below you can see when the bios was last updated on my Lenovo (2024). Fellow MVP, Mike Terrill responded with some great advice. You should still be able to push the certs into the active db. However, the default db wouldn’t get the updated certs. If you did a factory restore of the bios, then the active ones would be replaced and need to be installed again. And he included some Powershell examples from his talk at MMS. I’m including his Powershell code below. All credit to Mike Terill and Gary Blok (I believe). $SecureBootRegPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' New-ItemProperty -path $SecureBootRegPath -name "AvailableUpdates" -PropertyType dword -Value 0x1844 -Force Start-ScheduledTask -taskname '\Microsoft\Windows\PI\Secure-Boot-Update' #verify get-securebootuefi -decoded -name DB | Where-Object {$_.Subject -match "2023"} | Select subject get-securebootuefi -decoded -name KEK | Where-Object {$_.Subject -match "2023"} | Select subject So basically I ran the code above on my Lenovo T570 (from an elevated prompt) and the results were interesting. Below we add a reg key and trigger a scheduled task. The registry value tells Windows to deploy all available certificate updates as documented here and/or here (thanks Jon). and reveal the certificate status after a reboot To my joy, the following day the secure boot status report looked much much better for my Lenovo. Success! thanks Mike! I also got info from another Twitter user and he advised me to look here for some additional advice for patching older systems. https://www.elevenforum.com/t/garlins-powershell-scripts-for-updating-secure-boot-ca-2023.43423/ I did of course try the same method on some other old computers (Microsoft Surface Pro 2, Dell Optiplex 9020) and while it had some success with some of the certs, it couldn’t update the Microsoft Corporation KEK 2K CA 2023 certificate. According to Copilot this was because the firmware on the Dell and Surface, was just too old. Perhaps, perhaps. But then why did my Surface Book 2, which has a firmware (bios) date of wait for it, 2015 update all of the 4 certificates without any issue. That remains to be seen. I’ll update this blog post as I learn more, I definitely don’t want to ‘trash’ some old computers just because their secure boot certificates can’t get updated, worst case scenario I’ll convert them to Linux. On My Surface Pro 2 it updates 3 out of 4, the 4th being the missing KEK certificate, just like on the Dell. Looking in the SYSTEM event viewer, Event ID 1803 is showing every time I trigger the scheduled task from the Powershell script. That links me to this: Understanding Secure Boot Events 1802 and 1803 – Microsoft Support Learn more Finally, if you want to learn more aboute this subject (better late than never) take a look at this Patch My PC webinar, or Johan Arwidmarks free training on the subject: https://patchmypc.com/events/secure-boot-2026-are-you-actually-covered/ https://academy.viamonstra.com/courses/mini-course-secure-boot-2026 Summary Windows Autopatch on it’s own is not enough for getting these systems up-to-date with regards to the Secure boot certificate expiry. There are remediation scripts which definetly help, but they are mostly aimed at modern hardware. Thankfully, you can update some older hardware by using the example script above, either manually or push it out via Intune/ConfigMgr after you have of course ensured that the bios version is the latest available and that Windows is up-to-date. Thanks again to Mike, the beer is on me at MMS in October

contact me on Teams, and i'll see if i have some time > niall@windowsnoob.com

pros versus cons means what is positive about the solution (pros) and what is negative about it (cons)

only what i posted directly above, which explains it quite well.

if you are only talking about the WSUS server then the following could be possible, but messy. Short answer: Yes, you can enable HTTPS on a WSUS server without a full PKI infrastructure, but you still need some form of certificate, and the approach has trade‑offs. 🔐 What WSUS requires for HTTPS WSUS itself doesn’t require a Microsoft AD CS / enterprise PKI. It only requires: An SSL certificate bound in IIS to the WSUS website Clients that trust that certificate So the real question is not “PKI or not,” but how you issue and trust the certificate. ✅ Your main options without PKI 1. Self-signed certificate (most common workaround) You can generate a self-signed cert directly on the WSUS server. Steps: New-SelfSignedCertificate -DnsName wsus.yourdomain.local -CertStoreLocation Cert:\LocalMachine\My Then: Bind it in IIS to the WSUS Administration site Configure WSUS to require SSL: & "C:\Program Files\Update Services\Tools\wsusutil.exe" configuressl wsus.yourdomain.local ✅ Pros No PKI needed at all Quick and simple ❌ Cons Clients won’t trust it automatically You must manually or via GPO: Export the cert Deploy it to Trusted Root Certification Authorities on all clients 2. Public certificate (rare for WSUS, but possible) If your WSUS server has a publicly resolvable name, you can use a certificate from a public CA (e.g., DigiCert, Let’s Encrypt). ✅ Pros Already trusted by clients No GPO distribution needed ❌ Cons Usually not practical (WSUS is internal) DNS + internet validation required 3. Private CA alternative (lightweight, not full PKI) If you don’t want “full PKI,” you can still: Stand up a minimal AD CS (even temporary) Or use tools like: OpenSSL CA Small internal CA solution This is technically “PKI,” but much lighter than a full enterprise deployment. ⚠️ Critical things people overlook 1. WSUS only secures metadata, not update binaries Even with HTTPS: Update content can still download over HTTP This is by design (Microsoft signs updates) So HTTPS mainly protects: Client ↔ WSUS communication Metadata integrity in transit 2. Required IIS configuration WSUS does not require SSL on all virtual directories. You should: Require SSL on: SimpleAuthWebService DSSAuthWebService ServerSyncWebService APIRemoting30 ClientWebService Do NOT require SSL on: Content Selfupdate 3. Group Policy must be updated After switching to HTTPS: Specify intranet Microsoft update service location Change: http://wsus:8530 To: https://wsus:8531 4. Firewall and ports Default WSUS HTTPS port: 8531 Ensure clients can reach it ✅ Recommended approach (real-world) If you truly don’t want a PKI: 👉 Use a self-signed certificate + GPO distribution This is the most common setup in smaller environments. 🧠 Bottom line ✅ You do NOT need a full PKI infrastructure ✅ You DO need a certificate ⚠️ The key requirement is certificate trust on clients

you can't convert from http to https without a pki infrastructure in place first. Moving to https means you need something to deliver and create those certificates, that's where the PKI infrastructure comes into play. There is something from Microsoft called enhanced http, but that's not the same thing, you can read about it here: https://learn.microsoft.com/en-us/intune/configmgr/core/plan-design/hierarchy/enhanced-http so if you truly want your SCCM and WSUS infrastructure and clients to operate in PKI (https) mode, then you'll need a PKI infrastructure in place, it's not that hard to setup if you follow my detailed guides. Test in a lab first !! below is the response from Copilot on this subject Short answer: No — you can’t properly convert SCCM (Configuration Manager) from HTTP to HTTPS without a PKI infrastructure. Why PKI is required SCCM’s HTTPS mode relies entirely on certificates for: Client authentication Site system role authentication (MP, DP, SUP, etc.) Encrypted communication between clients and site systems These certificates must come from a trusted Certification Authority (CA). That’s exactly what a PKI provides. Without it, SCCM has no trusted mechanism to validate identities. What happens if you try without PKI Clients won’t trust the management point Authentication will fail You’ll see certificate or communication errors (MP unreachable, client not approved, etc.) Core features like software deployment and inventory break Your realistic options ✅ Option 1 — Stay on HTTP (not recommended long-term) Works without PKI Less secure (deprecated in modern environments) Microsoft is pushing away from this model ✅ Option 2 — Use Enhanced HTTP (recommended middle ground) Does NOT require full PKI Uses self-signed certificates automatically managed by SCCM Provides encryption and improved security compared to HTTP Much easier to implement 👉 This is what most organizations do if they don’t have PKI. ✅ Option 3 — Build PKI and move to full HTTPS Requires: Active Directory Certificate Services (AD CS) Certificate templates (client auth, web server, etc.) Deployment of certs to clients and servers Most secure and fully featured option Recommendation If you currently have no PKI: Enable Enhanced HTTP first Plan PKI deployment separately Later transition to full HTTPS when ready Summary Mode Requires PKI Security Level Notes HTTP ❌ Low Deprecated direction Enhanced HTTP ❌ Medium Best without PKI Full HTTPS ✅ High Requires PKI

you haven't stated if you have a pki infrastructure in place, do you ? if not you'll need to set that up also, see > to convert SCCM and WSUS services to HTTPS i cover the process here, my recommendation is test this in a lab first and/or hire a pki consultant to assist with the job

Introduction I bought a second hand replacement laptop for a mis-behaving Surface Pro 4 (jittery screen) and to save my time (the computer wasn’t mine) I decided to image it. Anyway, long story short, after I restored 82GB of data on the target laptop (HP 830 G5), I tried to boot it but got a HP bios error stating something like no operating system found, please reinstall the operating system. So I booted from some usb based Windows installation media and checked the partitions, all the data was there, Windows was there, it all looked good but obviously the boot loader was broken. I googled and found the following suggestions. Bootrec /fixmbr Bootrec /fixboot (Note: If this fails with access denied try BOOTSECT /NT60 SYS and then issue the command again) Bootrec /scanos Bootrec /rebuildbcd The problem however, is that after issuing Bootrec /rebuildbcd it stated “Total identified Windows installations: 0” which of course, didn’t leave me feeling super confident that this would work. The value should be 1 at a minimum. Another quick google and the advice out there all stated something like the following… bcdedit /export C:\BCD_Backup C: cd boot But that gave me the following error “The system cannot find the path specified” because there was no C:\boot folder. This folder doesn’t exist as this computer (Windows 10) is UEFI based and not legacy based as I guess the gazillion guides out there assumed. Due to the format change (legacy versus UEFI) this computer uses an EFI partition to store the boot files, but that partition doesn’t have a drive letter and the path to the BCD is different to all the guides out there, so how do you fix that ? To find the efi partition, boot from the Windows installation disc, and select Install. Next click on Repair your computer then select ->Advanced Options ->Troubleshoot ->Command Prompt. Once done, launch diskpart and then select the disk on your computer (most likely disk 0) like so diskpart sel disk 0 list vol that will show you the partitions on your computer. Then I selected each of the two SYSTEM partitions, and assigned a drive letter to them so I could view the files on them using sel vol x (where x is the volume number) assign After assigning a drive letter and exiting diskpart I could browse to that drive in another command prompt by typing it’s drive letter, for example: D: and view the files on it using: DIR I did this a few times to identify the correct drive, after I was done with that drive I removed the drive letter in the diskpart command prompt using: remove Once I identified the EFI partition I navigated to where the bcd files were located using: cd D:\EFI\Microsoft\Boot and that path was D:\EFI\Microsoft\Boot as shown below, note your EFI partition may end up on a different drive letter using the ASSIGN command. Now that I found the BCD, shown above, I removed the SYSTEM, READ ONLY and HIDDEN attributes from it before renaming it to bcd.old and then rebuilt the BCD. attrib bcd -s -h -r ren bcd bcd.old bootrec /RebuildBcd And that was it , all I had to do before rebooting was to un-assign the drive letter using the remove command. and finally, reboot the computer cleanly using wpeutil reboot I hope you found this useful, if you do please leave a comment and share this with others cheers niall

Introduction Microsoft released an update to Windows 365 recently that allows iPhone users to control the mouse via bluetooth when connected via a USB-C connected iPhone. In this blog post myself and my MVP buddy Paul Winstanley look at the new feature, review it’s capabilities, take it for a spin and give our thoughts. We previously tested accessing Cloud PC’s from a USB-C connected iPhone docked to a HP E-24M docking station/monitor combo, but the experience was not good as the only mouse support at that time was using the iPhone’s screen as a touchpad. Paired bluetooth mice did not work and neither did USB connected mice. Now however, Microsoft have solved that problem, at least if you use their mouse. This blog post is broken down into the following sections: Prerequisites Optional Extras Updating the firmware Pairing bluetooth devices Install the Windows app Configure Windows app permissions Configuring Auto-lock on the phone Connecting to your Cloud PC Video meetings Multi-monitor support Summary So let’s get started! Prerequisites As usual there are some prerequisites highlighted below: The Enterprise user must be licensed for Windows 365, Intune and Entra ID P1. Compatible Microsoft bluetooth mouse as documented here. Apple iPhone 15, 16 or 17 with USB-C support Optional extras to make the experience even better include: A monitor or docking solution capable of USB-C connection A bluetooth or USB connected keyboard A bluetooth headset A stand to support your iPhone while docked Updating the firmware Once you meet the prerequisites all you need to do is ensure the firmware of your supported Microsoft mouse is updated on a Windows PC to version 2.2 or later before starting. Download the firmware from here and verify the version of the firmware on a Windows PC via the Surface app. The strange thing about updating the firmware is you must first install the MSI (elevated), restart the computer then pair the mouse to the Windows computer, then wait 10 minutes for it to update. It’s all in the instructions. To verify the firmware version, install the Microsoft Surface app on that Windows computer, and you’ll see the firmware version in that app. If it doesn’t update, close and then re-open the app. Pairing bluetooth devices Now that the Microsoft Arc mouse firmware is up to date, simply pair it with your iPhone. Once done, you can optionally pair a bluetooth keyboard or use a USB keyboard plugged into the HP dock (monitor) and pair your bluetooth headset. Note: Even when you pair a bluetooth headset to your iPhone, when it’s connected via USB-C to a dock or external monitor it behaves differently and will always want to default to the audio capabilities of the docked monitor via USB-C. What this means in practice is that after you’ve docked to the HP monitor with your iPhone, and playback audio, the audio will come from the speakers in the monitor. To solve this, from the top right of the iPhone swipe down to show the widgets menu. Select the audio playback widget (top right of this screen). Click the speaker output option and finally, select your bluetooth headset. Install the Windows app At this point, install the Windows app from the Apple App Store if you haven’t already done so. Once installed click on + in the Windows app to add your work account, that will give you access to any Cloud PC’s provisioned for your account. After adding your work account, any Cloud PC’s made available to your account will show in the Windows app. Note: The notifications icon in the Windows app is useful to keep track of, click on it to see what it’s alerting you to. Configuring Windows app permissions In the newly installed Windows app, click on your username photo in the top left and select App permissions, flip the following settings to On. Camera Location Microphone Bluetooth Local network Configure Auto-lock on the iPhone On your phone, you may want to configure screen lock from the default 30 seconds to 5 minutes while using your Cloud PC, otherwise when your iPhone locks the screen you’ll be disconnected from your Cloud PC session. Below is what you’ll see when the iPhone screen locks. To configure it, open settings, Display and Brightness and scroll down to Auto-lock. Set it to your desired timeout and if necessary, but don’t forget to revert it after you are finished with the Cloud PC. For security reasons never leave your phone unattended when this is set this way. Connecting to your Cloud PC To connect to your cloud PC, once the above is done, simply plug in the USB-C cable from your docking solution/USB-C monitor. On your iPhone, open the Windows app, and click on your Cloud PC. It will appear on your HP monitor, but most likely in an incorrect resolution. To use the correct resolution, you’ll need to configure the resolution settings in your Windows app by clicking on the Windows icon and selecting the appropriate resolution, usually 1920×1080, or configure the desired resolution in the Windows app by clicking on your username photo, and selecting the option there. Video meetings To have a video meeting in Microsoft Teams, you must use the camera in your iPhone. Camera’s built into monitors or docking monitors are not supported, therefore you’ll probably want a stand to support your iPhone in a suitable location. Once the phone is placed in a suitable spot, you can use the phone's camera for Teams/Webex/Zoom meetings. Multimonitor support This solution only supports one monitor, the monitor that you are currently connected to. Dual monitors are not supported for this scenario. If you require dual or more monitors use a Windows computer with the Windows app, or macOS. Summary We were left very impressed, being able to work by simply bringing your iPhone to a desk that has a docking station with the Microsoft Arc mouse is actually a killer feature. You can absolutely work using this setup, and even receive phone calls on your phone while working on the Cloud PC. But while this is definitely a huge step forward for using your Cloud PC via an iPhone, there are still some gaps that hopefully will be solved in the future. We summarize them below: We would like to see the ability to use any popular bluetooth mouse (such as the Logitech MX Master) which allow connections from up to 3 different devices. The Microsoft Surface Arc mouse can only connect to one device and it does not feel as professional as the Logitech mice. We would also like to see better security or options regarding the auto-lock feature of the iPhone screen, in conjunction with the connection to your Cloud PC. Once the screen locks on your iPhone, it instantly disconnects your Windows 365 session which makes working hard/frustrating. Setting the timeout to 5 minutes or never helps, but it’s a security risk in an Enterprise. Also, why does the iPhone forget your chosen external resolution every time you connect, can’t we set that in the Windows app and make it stick? Thanks Microsoft for yet another update to Windows 365, this one really is well worth checking out. Highly recommended and a genuine use-case here! see you in the next one, Niall & Paul

Introduction In a previous blog post I showed you how you can resize Enterprise Cloud PC’s, you can review that here. In this blog post myself and fellow MVP buddy Paul Winstanley teamed up again to look at the resize ability provided by Microsoft for Frontline Cloud PC’s and show you how you can use this new feature (new to Frontline). Microsoft announced this new ability a couple of weeks ago here. Admins can now resize Frontline Dedicated Cloud PCs after provisioning to adjust compute and storage configurations without reprovisioning. This capability provides greater operational flexibility when user requirements change and helps reduce the overhead of managing capacity. Admins can respond more easily to evolving performance needs while keeping existing Cloud PCs intact. For more information, see Resize Windows 365 Frontline Cloud PCs in dedicated mode. Why resize? Imagine you have a user that has a Frontline Dedicated Cloud PC assigned, with the following SKU. Cloud PC Frontline 2vCPU/8GB/128GB This may have been good enough for the tasks that that user was initially doing, but let’s imagine that they got access to new tasks that demanded more CPU/ram/storage, or that they simply noticed that the Cloud PC they were given was under powered. Sometimes you may find that a Cloud PC is not powerful enough for a user, or is too powerful and not being used to it’s full potential (low utilization). With this new ability you can resize low or high utilization Frontline Dedicated Cloud PCs on the fly. Identifying low utilization You can now identify low utilization on Windows 365 Cloud PCs in the Intune portal directly. In the Reports node, expand Windows 365, select Cloud PC Overview and then select Cloud PC recommendations. Unfortunately this report only seems to cover Enterprise Cloud PC’s and we are focusing on Frontline Dedicated in this blog post. But there’s another way, in Devices, expand Device Onboarding, select Windows 365 and select Resource performance. This brings up Endpoint analytics with lots of resource performance details. You could click on the highlighted Insights and recommendations or click on the Model performance or device performance tabs to get more details. And sure enough, there’s our Frontline Dedicated Cloud PC showing as needs attention due to CPU spike time and to a lesser degree, RAM spike time. Now that we’ve spotted the Frontline dedicated Cloud PC’s that need help, it’s time to fix the problem. Resizing So let’s take a look at the new feature. Take note of the role, ip address and other requirements as detailed here. To resize a Frontline Dedicated Cloud PC, locate it’s provisioning policy, and scroll down to Assignments, click Edit. Click on Cloud PC size highlighted in blue. This will bring up a Select Cloud PC size window where you can select from available sizes. From there, pick an option to fix the problem, in this case we’ll resize the current Frontline Cloud PC from one sku to another via the Available sizes drop down, as it’s only an example of the resize operation. Note: In reality, to fix this problem you’d want to resize to a vCPU with more power and possibly more RAM too based on the endpoint analytics report, however we don’t have either of those available in this tenant. Also to note, downsizing is not supported for lower storage or GPU. Take note of the warning, which states that All the Cloud PCs provisioned from this assignment will be resized to the selected size. Connected Cloud PCs will be disconnected, and unsaved changes might be lost. This is important and you should most likely only resize when your Frontline users are not actually using these Cloud PC’s if possible. Finally, click Next and click Update to update the provisioning policy assignment with the new resized SKU. You can see the entire operation in the GIF below. Job done! Read more Announcement – https://learn.microsoft.com/en-us/windows-365/enterprise/whats-new#week-of-march-2-2026 Frontline dedicated Cloud PC resize – https://learn.microsoft.com/en-us/windows-365/enterprise/resize-cloud-pc-frontline Summary Resizing Frontline Dedicated Cloud PC’s is now a reality and available today in the Intune console. You have to modify the provisioning policy to resize the Cloud PCs which can mean several Cloud PC’s being impacted from this change, rather than just one. Still, it’s a welcome change and we are glad to see it. See you in the next one!

Introduction The Remote Desktop client app is commonly used for connecting to a variety of devices including: Connecting to Azure Virtual Desktop (AVD) Accessing Windows 365 Cloud PCs Access Remote Desktop Services (RDS) Connecting to remote PCs (when configured for RDP) The app is popular due to the fact that it has multi device support including Windows, macOS, iOS and Android, but it’s interface looks dated to say the least. Below you can see how it looks today including the end of support message on the top. The app is soon to be end of support as of March 27th, 2026 and you are reminded of that in the banner on the app itself (shown above) and via the downloads webpage shown below. You should start migrating the app on any devices that have it installed to the new Windows app. The remote desktop client app does not automatically upgrade to the Windows app so migrating it is needed. Migrating from the remote desktop client to the Windows App can be complicated. It can be used as-is or modified to suit your individual needs. It performs the following actions: Installs the Windows App via MSIX package download Optionally uninstalls the legacy Remote Desktop client Sets registry keys to control auto-update behavior Logs all actions to a specified log file Myself and my fellow MVP buddy Paul Winstanley look at a migration tool provided by Microsoft and show you how you can set this up in your Intune tenant based on the instructions that come with it. Setting it up To set it up do as follows, in Microsoft Intune select Devices, Scripts and remediations and select Platform scripts. In there click on Create and give the script a suitable name such as Migrate from remote desktop client to Windows app. Click Next and in Configure script settings point to the downloaded Remote Desktop Client Migration script and set the following options: These settings force the script to run in SYSTEM context (required to set registry keys and install provisioned packages, in addition to uninstall system-level apps). Click Next and add a group of one or more targets to migrate from the Remote desktop client agent to the Windows app. You could also exclude a group containing devices that already have the Windows app. Monitor the results After deploying out the script you can check the results via the log. The log (on the target clients) is available at $env:windir\temp\RDC-Migration.log. Below is an example of that. Within Intune itself, you can look at the script results, if there are errors below are some common error codes. If the Windows app is shown as installed in the log but not actually installed on the device you can run the following two Powershell checks to see why it’s reporting this. # Check provisioned packages Get-AppxProvisionedPackage -Online | Where-Object {$_.DisplayName -like "*Windows365*"} # Check user installation Get-AppxPackage -Name *Windows365* -AllUsers In our case the Windows app was not available on the device any more (had been uninstalled prior to deploying the migration script). But still Windows thought it was installed even though we logged off/logged on again prior to the test. Related reading Download the Remote desktop client app – https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/connect-windows-cloud-services?tabs=windows-msrdc-msi Migrating to Windows app – https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/migrate-msrdc-windowsapp Remote Desktop Client Migration script – https://github.com/microsoft/Windows365-PSScripts/tree/main/Remote Desktop Client Migration Script Summary The impending end of support of the remote desktop client app is coming in less than 20 days, so it’s a good idea to migrate your install base to the new supported solution, the Windows app. Microsoft have been kind enough to provide a script, and it works as you’d expect a Powershell script from Intune. Powershell scripts however are limited when deployed this way and we think it would be better to deploy this migration tool as a Win32 app or even a remediation solution. For example, you might consider wrapping it with PSADT (Powershell application deployment toolkit) or similar and deploy it as a Win32 app to get better results, otherwise you might see issues relating to the Remote desktop client agent app being in use and thus not removed or that the user didn’t login yet. Most of the observed issues are listed in the troubleshooting section of the downloadable script. That’s it for this blog post we’ll see you in the next one!

@JayL can you share the details of the fix with others so that they can get help ?

check your pm.

Introduction Windows 365 User Experience Sync (UES) is a cloud‑native capability designed to give users a seamless, consistent, and personalised Windows experience across Windows 365 Cloud PCs and Windows 365 Cloud Apps. Without UES in place on Frontline Shared devices, Windows personalisation, user settings, application settings, and application data are retained on logoff/logon which can be frustrating for end users who need to reauthenticate or reconfigure to set up their device how they need to use it, only to have to do this each time they log on to the Cloud PC. Instead of relying on traditional profile‑management tools, UES automatically preserves the settings every time the user signs in. Microsoft manages the UES infrastructure, vastly decreasing the implementation complexity and cost compared to other profile based solutions. At the core of User Experience Sync is dedicated, cloud‑hosted user storage that follows each user from session to session. When a user signs in, their individual storage is dynamically attached, providing immediate access to their personal settings and app data. As the user signs out, the profile is detached and stored securely ready for the next session. In this blog post myself and fellow MVP buddy Niall Brady overview this new feature and show you how you can set this up for Windows 365 Frontline Shared Cloud PCs and Cloud Apps. Myself and Niall were part of the private preview for the solution and were heavily involved at that stage. The feature was made generally available in November and we will be interested to see that changes have been made to the solution, based on our feedback, in that time. Requirements The following requirements are needed at present. Windows 365 Frontline license Access to required Windows 365 and Microsoft 365 endpoints Intune management permissions Setting it up When it comes to setting up the Windows 365 User Experience Sync, the enablement of the feature is achieved in the configuration of the Frontline Shared Provisioning Policy. This can be done when creating a new policy, or an existing policy can be modified to add or remove the feature. Let’s focus initially on creating a policy and enabling the UES solution. In the Intune admin center, navigate to Devices | Device onboarding | Windows 365. Select Provisioning policies from the menu and choose Create Policy. When creating the provisioning policy, ensure that you select Frontline as the License type and enable Shared from the Frontline type choice. For Experience, you can choose either Access a full Cloud PC desktop, or Access only apps which run in the cloud, since both Cloud PCs and Cloud Apps support UES. The Configuration section of the provisioning policy wizard is where we configure the UES solution. We have two choices to make; Enable user experience sync and User Storage Size. Check Enable user experience sync to turn on the feature. Managing the UES storage For the User Storage Size, Microsoft offer a predefined pool of user storage that comes included with your Frontline licence. The total available storage is determined by the Cloud PC’s OS disk size and is scaled based on the number of Cloud PCs assigned within the policy. For our Frontline model, we have a Cloud PC Frontline 2vCPU/8GB/128GB licence and 1 Frontline device, therefore the amount of pooled storage available to us is 128 x 1 or 128GB. The User Storage Size allows us to assign up to 64GB per user as you can see from the drop-down menu below. Be aware of the pooled disk space limitations when assigning the the User Storage Size. Exceeded limits: When pooled storage runs out, new users can still sign in, but they receive a temporary profile and cannot create their own user storage. Users who already have allocated storage can continue signing in with their full personalised experience. Exceeded tolerance period: If the pooled storage limit remains exceeded, a 7‑day tolerance window begins. After this period ends, the system automatically removes individual user storage starting with the one that has the oldest “last attach” timestamp. Once the total storage usage drops back below the limit, the tolerance period resets and won’t start again until storage is exceeded in the future. You can manage the user storage by selecting going to Provisioning policies and clicking your newly created policy. Next, select User storage and you will be presented with a view of the Storage information which includes the Total, Available and Used data. Since we are currently provisioning the devices, nothing will be used. Some recommendations to assist with UES are to: Enable OneDrive redirection Manage Edge for cache and temporary data retention Deploy Storage Sense to clean up temporary files, delete downloads and cloud backed files (OneDrive) You can set up alert monitoring for the user storage. This is achieved by navigating to Tenant administration | Alerts | Alert Rules and clicking Frontline Cloud PC User Experience Sync Storage Limits. In the System rule view, you can set to alert when used space is Greater then or equal to a certain percentage. You can set a Severity for the alert, if the Status of the rule is On or Off, whether to have a Portal pop-up Notification and if someone should receive an Email alert. You can enter multiple recipients for the email. What’s Included and Exclude from User Experience Sync (UES) The following is included in the UES solution: User storage includes all data from C:\Users%username%, such as: User settings and application data Registry files, (NTUSER.dat and USRCLASS.dat) Personal files and folders What’s not included: Nonroamable application data AppData\Local\Packages*\AC AppData\Local\Packages*\SystemAppData AppData\Local\Packages*\LocalCache AppData\Local\Packages*\TempState AppData\Local\Packages*\AppDat Nonroamable identity data AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy AppData\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy AppData\Local\Microsoft\TokenBroker AppData\Local\Microsoft\OneAuth AppData\Local\Microsoft\IdentityCache The UES Experience When a user signs on for the first time to a Cloud PC or Cloud App with UES enabled, the personal storage will be created and attached to the session and capture of settings will be automatically enabled and redirected to the storage. On the next login, the UES will be reattached and any saved configuration loaded. Do bear in mind that UES does not roam or persist user installed applications, only settings and preferences are captured. On a Frontline Shared UES enabled device, we are loading the store app Sticky Notes for the first time. We are requested to authenticate to use the app on first run. After authenticating, we can create content in the app with the expectation that this is stored within the UES storage and retained for our next session. If we do not have Frontline Shared UES enabled, then the end user would need to re-authenticate with the Sticky Notes app on each logon to bring up their personalised notes. Installing apps Another thing to note is if the user downloads and installs an app, let’s say Firefox. While this works during the session that the user is logged on to, once they logoff/logon any remnant of that (shortcut, etc) are gone. If you want apps to persist then install them in the base image (custom image). Filling up the storage and reporting on usage One of the areas we fed back on during the private preview, was the lack of warning or information for the end user when the UES becomes full. In the screenshot below, for example, the user has downloaded too many ISO files and filled up their allocation of 16GB. The only message the end user gets is Couldn’t download – Disk full. This isn’t informative enough for the end user in our opinion. Improvements to the experience should be forthcoming and we hope that this is one which is being taken into account by Microsoft. When it comes to usage, the admin can take a look at what allocation of their Total amount is in use in the User storage section of the Provisioning Policy. Remember from earlier, you need to click Provisioning policies and select your policy. Select User storage to view. We can now see that 16GB from the Total of 128GB has been allocated to a user. These stats do not give us a real time view of what a user has actually used from that 16GB allocation. This is another area that we fed back on that we feel needs improvement. If we have set up alerts and total usage across all UES compromises the percentage stated in the rule, then the recipient of the alert rule will receive an email with details of the provisioning policy where the usage is a concern. In Tenant administration | Alerts admins will be alerted with the relevant Severity and with a pop-up, if enabled. Amending an Existing Provisioning Policy To be able to amend an existing provisioning policy to add or remove UES, you first need to remove the the current group assignment from the policy. Navigate back to Provisioning policies and select your Frontline shared policy. Choose Properties. Scroll down to the Assignments and click Edit. Delete the assignment. Click Remove to confirm the removal of the assignment. Click through the wizard to Update the policy. Now Edit the Configuration section of the policy. This is our UES policy with UES enabled. We can, therefore, remove UES by deselecting the Enable user experience sync checkbox. If this was a policy which never utilised UES, we could go into here and select to use and set a corresponding User Storage Size. Once amended, Update the policy and head back to Assignments and Edit. Reassign the policy and enter the relevant Cloud PC size, select your Frontline subscription and Assignment details. The Frontline shared devices will then be in a Provisioning state as the amended configuration is laid down. Read more User Experience Sync for Windows 365 Frontline in shared mode – https://learn.microsoft.com/en-us/windows-365/enterprise/frontline-user-experience-sync Troubleshoot User Experience Sync for Windows 365 Frontline in shared mode – https://learn.microsoft.com/en-us/troubleshoot/windows-365/troubleshoot-user-experience-sync Summary Windows 365 User Experience Sync is a welcome feature for Frontline Shared devices which has been on the wish list for some time now. It is very simple to get up and running, without all the complexity of other solutions and provides instant access to storage of settings and application data. Microsoft is taking into the account the feedback it received during the private preview and we should see some feature changes happening very shortly to improve the end user experience. We look forward to seeing how this new feature matures and develops over time and we’ll blog about the feature improvements as they are released.

can you show a screenshot of your task sequence please, and secondly, share your smsts.log

Introduction I started my day as always and launched the Windows app, I clicked my Cloud PC, entered my credentials and after a short delay I got an error shown below. The error shown above was “something went wrong” with a very not useful error code, -895352830. I tried this on multiple tenants with the same error code being generated. I asked Copilot what this meant and got the following details This code corresponds to an AADSTS65002 token/permission issue during authentication. Microsoft documentation shows the same error pattern: Error: -895352830 (0xCAA20002) — occurs when a Microsoft first‑party app is missing required preauthorized API consent, causing token broker authentication to fail. [learn.microsoft.com] This means the Windows App cannot obtain a valid authentication token due to a Microsoft Entra (Azure AD) app permission issue, often triggered by: Broken SSO token broker A corrupted local identity cache A bad Windows Update interfering with Windows App authentication The last point above (a bad Windows Update) is indeed the cause. More details below: January 2026 security patches (notably KB5074109) are currently breaking logins in the Windows App and Remote Desktop authentication: Microsoft confirms widespread credential failures after the January 2026 update, impacting Windows App sign-ins for Azure Virtual Desktop & Windows 365. [theregister.com] Users report the app immediately fails with authentication errors after pressing Connect. [theregister.com] Removing KB5074109 restores normal Windows App login functionality (confirmed by multiple users on Jan 15–16, 2026). [learn.microsoft.com] According to theregister.com The upshot is that connecting to Windows 365 or Azure Virtual Desktop from the Windows App could be borked due to credential problems. Microsoft posted: “Investigation and debugging are ongoing, with coordination between Azure Virtual Desktop and Windows Update teams.” The problem is widespread and appears to affect every supported version of Windows, from Windows 10 Enterprise LTSC 2016, right up to Windows 11 25H2. Windows Servers 2019 to 2025 are also affected. Great, so now what ? Suggested workarounds are that you can connect to your Cloud PC using the soon to be unsupported Remote Desktop Client Agent available from here. Windows 64-bit Windows 32-bit Windows ARM64 I tried it, but it too failed to connect. Next, I tried via a web-browser, but that also didn’t work. The Cloud PC I’m trying to connect to is protected using the new CKIO feature and the web browser version does not support that. Verifying the problem A quick look in Intune, revealed that indeed the problematic CU was indeed applied to my Cloud PC’s and the PC I was making the connection from (Windows 11 25H2 ARMx64). Here’s a sample. As you can see below Below you can see the CU details… 10.0.26200.7623 10.0.26100.7623 https://support.microsoft.com/en-us/topic/january-13-2026-kb5074109-os-builds-26200-7623-and-26100-7623-3ec427dd-6fc4-4c32-a471-83504dd081cb and within that you can see the known issues including the suggested workaround, which is to install KB5077744. As it’s so new this update is not even available in Windows Autopatch so you cannot currently use expedite updates policy to deploy this. KB5077744 is an Out‑of‑Band (OOB) update for Windows 11 25H2/24H2. It is not delivered through Windows Update automatically and must be manually downloaded and installed from the Microsoft Update Catalog. You must use the Microsoft Update Catalog to obtain the standalone package (MSU). [support.mi…rosoft.com] The fix As KB5077744 is only currently available (at the time of writing, 2026/01/19) via Microsoft’s Catalog, you must deploy it (the msu) from Intune by wrapping it as a Win32 app. Because Intune does not directly deploy .MSU updates as updates, the supported method is to wrap the MSU as a Win32 app and deploy it to your affected clients. Go to Microsoft Update Catalog and search for kb5077744. Download the update that is applicable to your Windows OS version. Be aware that the file size is big, my download was approx 3.6GB. Place the downloaded msu file and this Powershell script in a folder called KB5077744. here’s the contents of the Powershell script, modify it so that it has the exact file name of the msu file you downloaded otherwise it won’t install. Save the file as Install_KB5077744.ps1. wusa.exe windows11.0-kb5077744-x64_fb63f62e4846b81b064c3515d7aff46c9d6d50c8.msu /quiet /forcerestart exit $LASTEXITCODE Note: If you want to control reboot notifications and other options, package this instead using Powershell Application Deployment Toolkit and customize those options as necessary. Using Intunewinapputil.exe wrap the package as a Win32 app. Then add the Win32 app use this command line powershell.exe -ExecutionPolicy Bypass -File Install_KB5077744.ps1 and the following detection script. $sysinfo = systeminfo.exe $result = $sysinfo -match "KB5077744" if ($result) { Write-Output "Found KB5077744" exit 0 } else { Write-Output "KB5077744 not found" exit 1 } Finally, after deploying the update to your affected clients, and waiting for it to install and restart, you’ll be able to connect again. Phew. What a relief. The new Windows build number is highlighted below. 10.0.26200.7627 from a Windows 11 25H2 Cloud PC. and here you can see it successfully installed on the client and of course, via Intune, however Intune still has not yet updated the build number of the CPC yet in the Win32 app install status. Update It seems you need to patch the host PC making the connection to the Cloud PC also, if it’s running x64 Windows and has the .7623 patch level (January update). Strangely I didn’t need to patch the ARM PC at all even though it had the .7623 patch level. Related reading Reddit: https://www.reddit.com/r/AzureVirtualDesktop/comments/1qc3g1x/comment/nzmy4fv/ theregister: https://www.theregister.com/2026/01/15/windows_app_credential_failures/ KB5077744 – https://support.microsoft.com/en-us/topic/january-17-2026-kb5077744-os-builds-26200-7627-and-26100-7627-out-of-band-27015658-9686-4467-ab5f-d713b617e3e4#id0ejbd=catalog

based on what a previous guy said " I guess you could create a powershell script to check for msiexec process doing this and if so 'wait' until it's done, before installing the app, have you tried that ? here's some untested code that you could use as a wrapper for each app, maybe it will help [CmdletBinding()] param( [int]$TimeoutSeconds = 0, # 0 = wait indefinitely [int]$PollIntervalSeconds = 3, # how often to poll [switch]$Quiet # suppress non-verbose status messages ) function Write-Info { param([string]$Message) if (-not $Quiet) { Write-Host $Message } } function Test-MsiInProgressRegistry { # Windows Installer sets this key while an MSI is actively installing $keyPath = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\InProgress' try { if (Test-Path $keyPath) { # Some builds create the key with values; treat existence as "busy" $item = Get-Item $keyPath -ErrorAction SilentlyContinue $props = $null try { $props = Get-ItemProperty $keyPath -ErrorAction SilentlyContinue } catch {} return $true } } catch {} return $false } function Get-MsiexecProcesses { # Fetch msiexec.exe along with command lines (CIM needed for CommandLine) try { return Get-CimInstance Win32_Process -Filter "Name='msiexec.exe'" -ErrorAction SilentlyContinue } catch { # Fallback to Get-Process (no command line available) try { return (Get-Process -Name msiexec -ErrorAction SilentlyContinue | ForEach-Object { [pscustomobject]@{ ProcessId = $_.Id Name = $_.ProcessName CommandLine = $null } }) } catch { return @() } } } function Test-MsiexecDoingWork { # Heuristic: if command line indicates an actual MSI operation (install/repair/uninstall/update) param( [Parameter(Mandatory)] $Proc ) $cl = $Proc.CommandLine if ([string]::IsNullOrWhiteSpace($cl)) { # If we lack command line, be conservative: any msiexec process could be active return $true } # Common operation switches for msiexec: # /i, /x, /f*, /update, /uninstall, /package, /qn, /qb, /passive often accompany installs $patterns = @( '\s/([ix])\b', # /i install, /x uninstall '\s/f[a-z]*\b', # /f, /fa, /fu, etc. (repair) '\s/update\b', # patch/update '\s/uninstall\b', '\s/package\b', '\.msi(\s|$)', # explicit MSI file '\.msp(\s|$)' # patch file ) foreach ($p in $patterns) { if ($cl -match $p) { return $true } } # Sometimes msiexec runs as the service side without clear switches; if in doubt, treat as busy return $true } function Test-MsiBusy { # Returns $true if Windows Installer is likely busy $procs = @(Get-MsiexecProcesses) if ($procs.Count -gt 0) { foreach ($p in $procs) { if (Test-MsiexecDoingWork -Proc $p) { return $true } } } if (Test-MsiInProgressRegistry) { return $true } return $false } # ---------------------------- # Main wait loop # ---------------------------- $start = Get-Date if ($TimeoutSeconds -gt 0) { Write-Info "Waiting for Windows Installer (msiexec) to finish (timeout: $TimeoutSeconds s, poll: $PollIntervalSeconds s)..." } else { Write-Info "Waiting for Windows Installer (msiexec) to finish (no timeout, poll: $PollIntervalSeconds s)..." } # If already idle, return immediately if (-not (Test-MsiBusy)) { Write-Info "Windows Installer appears idle." return } # Otherwise, poll until idle or timeout while (Test-MsiBusy) { if ($TimeoutSeconds -gt 0) { $elapsed = (New-TimeSpan -Start $start -End (Get-Date)).TotalSeconds if ($elapsed -ge $TimeoutSeconds) { Write-Warning "Timed out waiting for Windows Installer after $([int]$elapsed) seconds." exit 1 } if (-not $Quiet) { $remaining = [math]::Max([int]($TimeoutSeconds - $elapsed), 0) Write-Host ("MSI busy... ({0}s remaining). Next check in {1}s." -f $remaining, $PollIntervalSeconds) } } else { if (-not $Quiet) { Write-Host "MSI busy... next check in $PollIntervalSeconds s." } } Start-Sleep -Seconds $PollIntervalSeconds } Write-Info "Windows Installer is now idle."

it's no longer supported so i doubt it, i'll share a link with you

Introduction While Windows 365 Cloud PCs deploy robust perimeter defences—encrypted transmission channels and multi-factor authentication that thwart network-level attacks—a critical vulnerability persists at the endpoint itself. Malicious software operating on local devices, particularly keystroke capture tools, can intercept sensitive information before it ever reaches the cloud environment. These endpoint-resident threats create regulatory exposure and potential financial damage that traditional cloud security measures cannot address. Windows Cloud IO Protection closes this gap by introducing a kernel-level driver and system-level encryption that sends keystrokes directly to the Cloud PC, bypassing OS layers vulnerable to malware. When enabled on a Cloud PC it enforces a strict trust model: Only verified physical endpoints can connect. Endpoints must have the Windows Cloud IO Protect MSI installed. If the MSI is missing, the session is blocked and an error is displayed. This ensures a secure, uncompromised input channel between the Windows client and the Cloud PC. In this blog post myself and fellow MVP buddy Paul Winstanley overview this new feature and show you how you can set this up for Windows 365 Cloud PCs. Requirements The following requirements are needed at present. The feature is public preview and could change as this becomes Generally Available: Host physical Windows 11 devices Devices must have TPM 2.0 Host devices must have the Windows Cloud IO Protect agent installed Download the Windows x64 release Download the Windows ARM 64 release Windows App running 2.0.704.0 or later The following is not currently supported: macOS iOS Android Windows 365 Link Using the Web client Setting it up When it comes to setting up the Windows Cloud Keyboard Input Protection feature, Microsoft has an interesting approach in that its documentation currently only supports using group policy to achieve this. The setting Windows Components > Remote Desktop Services > Remote Desktop Session Host > Azure Virtual Desktop > Enable Keyboard Input Protection needs to be enabled. During our testing phase, we were fortunate enough to be part of the private preview release, we had to set the following registry keys for Windows 365 devices, with just the former key being required for AVD devices: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\ DWORD - fWCIOKeyboardInputProtection Value - 1 HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings DWORD - SecureInputProtection.KeyboardProtection.IsEnabled Value - 1 To assist with this on your Entra only Cloud PCs, we have created an Intune proactive remediation script to set the values, if they are not present on your Windows 365 devices. These scripts need to be targeted to the Cloud PCs, and not the host devices. You can download the detection and remediation scripts from GitHub. Adding the Proactive Remediation script for Keyboard Protection In the Intune admin center, navigate to Devices | By platform | Windows | Manage devices | Scripts and remediations. Ensure you are in the Remediation view and click Create. Enter a Name for the custom script and add an optional Description. Click Next when done. Click the browse icon for the Detection script file and upload the Detect-KeyboardProtection.ps1 downloaded from GitHub. Repeat the process for the Remediation script file by uploading the Remediate-KeyboardProtection.ps1 script. Leave all other options as default and click Next. At the Assignments section, choose the group of devices that you wish to targeted. You can adjust the schedule for the execution of the remediation by clicking the Daily link under Schedule. For example, for our testing we have set the remediation to run Hourly. Click Apply when you have made your adjustment. The new schedule will be reflected accordingly in the Intune console. When you have completed the proactive remediation wizard, you will see the new remediation listed and with a Status of Active. When the script has executed against devices, the Detection status will be reported back to Intune with statuses of Without issues, With issues, Failed or Not applicable. Any Remediation status data will also be reported where applicable. Installing the Windows Cloud Input Protect MSI Agent Referring back to the Microsoft documentation, the MSI install is documented using a manual method of installation the application, and this would require local admin rights to achieve this. Instead, we can push the Windows Cloud Input Protect MSI via Microsoft Intune to an Intune managed host device. We can configure the application as a Win32 app and, therefore, we need to use the Microsoft Win32 Content Prep Tool, which you download from https://github.com/microsoft/Microsoft-Win32-Content-Prep-Tool, to convert the app into the .intunewin format. Here is a blog written back in 2019 on how to use the Content Prep Tool https://sccmentor.com/2019/02/17/keep-it-simple-with-intune-4-deploying-a-win32-app/ We can package the MSI into the required .intunewin format with three simple switches: -c – this points the tool to the source folder containing the binaries -s – this points the tool to the setup file used to execute the application -o – this tells the tool where to output the .intunewin to Once the tool is run, it quickly creates the .intunewin file for the Windows Cloud Input Protect MSI. We can now take this file and import it into Intune when we create the Win32 app. Navigate to Apps | Platform | Windows, in the Intune admin center. Click Create. From the App type drop-down, select Windows app (Win 32) and then choose Select. You will now be navigating through the Add App wizard. Start by clicking Select app package file. Click the browse icon and locate the .intunewin file that you created. Click OK to upload the file. Details will be automatically added to the App information fields. The only mandatory field you will need to complete is the Publisher field. Feel free to add any further information you require. Click Next when done. In the Program section of the wizard, further details will be automatically added, such as Install command and Uninstall command. We will use these default values for our application. Click Next to continue. In the Requirements section, you can be selective on the specific requirements for the installation of the app. We have ensured that Yes. Specify the systems the app can be installed on is selected and we have chosen Install on x64 systems as we downloaded the x64 release of the MSI. You must also select a Minimum operating system level for the install. Click Next when you have completed this section. For the Detection rules, we have kept this simple and chosen Manually configure detection rules from the Rules format drop-down and chosen the MSI type, which automatically uses the MSI ID for the application. Finally, a reminder that when targeting the Windows Cloud Input Protect MSI agent, we are targeting Windows 365 host devices and not the Cloud PCs themselves. When the Windows Cloud Input Protect MSI agent installs, you will see an entry for the Windows Cloud IO Protection driver in Program and Features on your host device. and, hopefully, this is reflected in the Intune admin center in the apps Overview section. Connecting from a host device which is not running the Windows Cloud Input Protect MSI agent At present, there is no visual indication to let you know if the Cloud PC is running with keyboard protection enabled, and this was one of the feed back areas in the private preview. It is coming and we should expect something fairly soon. When you attempt to connect from a device which is not running the agent, you will get the following error dialog box. and Windows App will report similar. We expect to see something similar, like the AI-enabled heading on a device which has the AI features enabled. Fingers crossed that this arrives soon. Connecting from a non supported device platform can produce different error messages that are less intuitive. For example, the screenshot below shows the error when connecting from the Windows App on an Android device. Hopefully, support will be extended to other device platforms over time, and error messages updated to reflect the connection issue. Read more Keyboard Input Protection for Windows 365 and Azure Virtual Desktop now in preview – https://techcommunity.microsoft.com/blog/windows-itpro-blog/keyboard-input-protection-for-windows-365-and-azure-virtual-desktop-now-in-previ/4468102 Windows Cloud IO Protection – https://learn.microsoft.com/en-us/windows-365/enterprise/windows-cloud-input-protection Summary Windows Cloud IO Protection is a powerful security feature that ensures keystrokes are encrypted and sent directly to the Cloud PC, bypassing OS layers vulnerable to malware. By requiring trusted endpoints with the protection agent installed, it creates a secure, uncompromised input channel that blocks keyloggers and prevents data leaks. Microsoft is taking into the account the feedback it received during the private preview and we should see some feature changes happening very shortly to improve the end user experience. Beyond this, we hope that support is adopted for all device platforms, so that this security feature becomes OS agnostic. We look forward to seeing how this new feature matures and develops before being released to production.

Introduction Microsoft have invested a lot of time, effort and money on adding AI abilities to core parts of the Windows Operating System and the apps that run on it, for example Office 365 apps or dedicated AI apps such as Microsoft 365 Copilot. Myself and my good friend Paul Winstanley took a look at a new feature to add select AI features to Windows 365 Cloud PC’s and share our thoughts below. Windows 365 AI-enabled Cloud PCs run in Microsoft’s Cloud and stream AI-powered Windows to any device and platform. This allows you to use select AI features that would traditionally be found on physical NPU powered Copilot+ PC’s. Those select AI features are: Improved Windows search Click to Do You can test these AI features on any device using your Cloud PC for example, below you can see an AI-enabled Cloud PC available from an Android powered phone. Note: In the screenshots below from our Android phones, the AI-enabled Cloud PC has an AI-enabled label in the top left corner. But first, let’s take a look at what you need in order to set this up. Requirements The requirements below will most likely change as this becomes Generally Available, but to test it right now in this Frontier release you’ll need to do the following: The end user must be registered in the Windows Insider program The Cloud PC must be in the Windows Insider Beta channel Enable Data diagnostics in your settings Have a Cloud PC that supports AI abilities (8vCPU, 32GB ram, 256GB HDD) The Cloud PC must be in a supported location Setting it up To set it up make sure you’ve enabled data diagnostics in your Windows Privacy settings, as shown here. Set the Send optional diagnostics data to On. Next, enroll into Windows Insider Program and select the Beta Channel (Recommended). Once done you’ll most likely have to restart the CPC, so go ahead and do that. Next, you’ll need to configure a policy (targeted to users) which enables the feature for Cloud PC’s that meet the minimum requirements. To do that select the Windows 365 node in Intune, click Settings and select Create to create the policy. Select Cloud PC configurations (preview) from the options presented. In the Configuration settings part of the wizard, select Enable from the drop down menu to enable AI features. and on the Assignments screen, select a previously created Entra Id group with users that will be using this new ability. Once done, make sure one or more users are in that group and the policy should flow to the CPC’s. Exploring the new AI abilities The first thing you’ll most likely notice is that your AI Enabled Cloud PC’s are now clearly labelled with an AI-enabled label in the Windows app. After connecting to that Cloud PC, you’ll notice the search icon looks different. AI-enabled Cloud PCs are marked by a magnifying glass with a sparkle icon within the search box on the taskbar. Those of you who already have physical Copilot + PC’s will already be familiar with this new search icon. The new AI search abilities are supposed to be better than built-in traditional search, so we put it to the test. We decided to start with by simply searching for a word via the search feature in Windows File Explorer on the users OneDrive. We performed the same search on the AI-enabled CPC as well as on a regular non-AI powered physical device. The AI search results are on the left, and the traditional search results on the right. Look at the difference, 37 hits versus 10, not bad at all. Lets try another search. This time again, more results from the AI search versus traditional search. Click to do Microsoft Click to do is a feature on all Copilot+ PC’s and Windows 365 AI-enabled Cloud PC’s. To use it simply search for it in the start menu and click the app. Once started, you can browse websites with pictures of text (for example) and press the Windows key + mouse click anywhere in the website. This can give you options to do things with what it sees, such as copy text within an image to paste into your favorite text editor, Depending on what you click on you get more or less options, such as below when clicking on the image of a blue CRT. Cool! Changes in Intune When using Windows 365 AI-enabled Cloud PC’s there are some additional things that you can see in the Intune portal to reveal the finer details. There’s a report here to show AI-enabled CPC’s and what (if anything) is wrong with them. To find it select Reports, and select Cloud PC overview. Select the AI-enabled Cloud PC report, and you can then click through the Status column for any Cloud PC that has reported data up to Intune. Once you’ve fixed the issues reported, which in our case we provisioned the Cloud PC in a location that was not yet supported for AI-enabled abilities, you’ll see a new status of Ready to use. You can also see a new status in Cloud PC’s overview, called AI-enabled, which will report Yes or No. Read more AI-enabled Cloud PCs – https://learn.microsoft.com/en-us/windows-365/enterprise/ai-enabled-cloud-pcs Experience next-gen productivity with Windows 365 AI-enabled Cloud PCs – https://techcommunity.microsoft.com/blog/windows-itpro-blog/experience-next-gen-productivity-with-windows-365-ai-enabled-cloud-pcs/4467875 Experience next-gen productivity with Windows 365 AI-enabled Cloud PCs – https://youtu.be/CvL8UXCYzDk Using Microsoft Click-To-Do https://support.microsoft.com/en-us/windows/click-to-do-do-more-with-what-s-on-your-screen-6848b7d5-7fb0-4c43-b08a-443d6d3f5955 Summary This new feature via the Microsoft Frontier Program has a lot of cool potential! It’s great to see that Microsoft is continuing its investment in Windows 365 Cloud PC development, and adding key features like this brings the power of AI to all devices, whether they are Android, macOS, Windows. We look forward to seeing how this new feature matures and develops before being released to production.

can't you boot it into safe mode and then uninstall whatever driver/app that caused the problem ? as it's an old Windows 7 computer have you verified if the disk (hdd) is ok ??

can't you use Windows 10 LTSC then ? (Long Term Servicing Channel) ?

hi Andy, drop me a message and i'll make them available to you cheers niall