All Activity

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

Hi, I have created a ADR for Windows Defender to deploy every day the new security intelligence update on Windows Client and Windows Server. It works fine, but only one machine (windows server 2025) does not get the security intelligence update. But if I go the device and proprieties, I see on the Deployment, the security intelligence update is there, but not install. How and where check it why? Regards

Yes I want only have the WSUS Server to convert to HTTPS Do have a Guide step by step?

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

it is a lot of work, are you sure, I cannot convert only Wsus Server to HTTPS?

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

No I dont have pki infrastructure in place, I want only to convert or to change the WSUS Server from HTTP to HTTPS. An I have to be sure that after convert the WSUS and SCCM does work together for SUP and Windows Updates. What should I do for WSUS Server on the SCCM and for all Clients machine? Thank you for help

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

Hi, I have a SCCM Server with WSUS Server on the same machine with Windows Server 2025. Now I want to change the WSUS Server from http to https. Is that easy or is there any step by step guide? I have to be 100% sure after change from HTTP to HTTPS, my SCCM and WSUS Server work fine Regards Keywan

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

I know this is old, but I think you can achieve what you want by using a query to populate the targeting collection for devices that do not have the application. Once the application is installed, and policy runs, the devices would no longer fit that criteria and should drop out of the collection. The other option is to just be vigilant that once installation completes, you manually remove them from the respective collections.

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

Hi, I am not sure but since one month my ADR for monthly Windows update does not work. I see the KB deployed to the client machine, but on the Software Center tuck at Downloading (0% complete). All Applications can be downloaded and install it, only Windows Update does not work I restarted the IIS but not help. Can anybody help me? Regards

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 ?

Why do people do that? Post a question asking for help, then when it gets resolved from a solution not provided here, they don't share the fix.

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.

Hello, I've the same problem, i'm unable to download prerequists from the setupdl.exe from ISO disc. it's possible to share a link with me, i see you have prerequest for SCCM2012 RTM/SP1/SP2/R2 ? Thank you in advance, for return. Regards.

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

Hello all, I hope everyone's new year is going well for them. In our environment we have one parent domain and two child domains. For example we have test.com, alpha.test.com and beta.test.com. We have separate defined prefixes for each domain and we have separate task sequences for each domain. I am trying to combine the task sequences into one. We have OSDCOMPUTERNAME set as a task sequence variable on the unknown computer collection so we have to name the computer at the start of the task sequence. For example a group called Join Test Domain, Join Alpha Domain, and Join Beta domain. Under each of the groups is the appropriate Apply Network Settings to get it to join the selected domain. I have tried using both WMI query and task sequence variables to filter the computers to the correct domain based off their prefix or their name. For the WMI query I have used "Select * from Win32_ComputerSystem where Name like "A%" and for task sequence variable I have used OSDCOMPUTERNAME Like "A*", neither of these two methods have worked because even thou we named the computer at the start of the TS the computer names are still showing in the log as MININT-XXXX. Any suggestions on how I would need to call on the OSDCOMPUTERNAME that we used at the beginning of TS? At the start of the TS I have tried to set the task sequence variable to OSDCOMPUTERNAME just like we have on the the Unknown computer collection but it is not prompting me to enter a computer name. I am grateful for any any help or advise, thanks.

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."

Hi all Meanwhile it's 2026 and we also have this issue on any task sequence on any application to install randomly. SCCM Version Current Branch 2503. Not the newest, but not old. Sometimes we can solve the problem by delete the application from the task sequence and add it again. Sometimes it helps to update the distribution point with the failed application. Random. Does anybody have a real solution or an official statemant from microsoft? tx to any help sincerly CL