Enhancements to Windows Containers
Everyone, I have created a github issue list for getting Windows Containers on par with linux containers: Here are the issues I documented: Syscall/capability-scoped restriction policy for process-isolated containers (seccomp/capabilities parity) #649 — Syscall/capability-scoped restriction policy for process-isolated containers (seccomp/capabilities parity) True PID namespace isolation for process-isolated containers (server silos) #650 — True PID namespace isolation for process-isolated containers (server silos) CimFS-backed overlay mount performance parity with Linux overlayfs for container image layers #651 — CimFS-backed overlay mount performance parity with Linux overlayfs for container image layers Decouple container base image version from host OS version for process-isolated containers #652 — Decouple container base image version from host OS version for process-isolated containers Please check them out and upvote them. We need to make Windows containers as capable as Linux containers.
MSHardenedPolicyEval and/or OSConfig
Hi, basicly the question is: Do they both play nicly together? Is it a "use MSHardenedPolicyEval" or "OSConfig"? Is OSConfig still in active development or will it be retired / deprecated when MSHardenedPolicyEval is GA? While I still really like OSConfig the new MSHardenedPolicyEval looks promising. Best regards, Jan
Storage Migration Service - Cutover Fails/hangs During Rename and Reboot Source Server Step
Hi folks. We are using the Storage Migration Service to migrate several servers from 2K8 R2 to 2019 and running into some issues during the various parts of the Cutover phase. This particular post deals with the Rename and Reboot step of the Cutover phase which we last attempted April 29, 2019(still working with Support, but no solutions yet). Details below: 1) We have an active case open with Support, but I wanted to Post to the Community to see if we get lucky. 2) We were able to get to the "Start Cutover" phase and it began around 5:30 PM CST on our last try. 3) Following it's progress, the process got through the final copy(approximately 600GB of data) and rename of the source server showing it was 44% done around 7:30 PM CST. 4) The source server never completed a reboot, but it did change the name and NIC settings. 5) The last update we saw on the Admin Center page was "44% Adding the source computer to the domain..." 6) We left it at this message until 10:30 PM CST. At this time I went ahead and manually rebooted the source server, hoping it would continue the process. 7) It didn't and since I was running out of time in my Change Window, I renamed the original server back, reset the NIC settings, and restarted it to get it back up and available. 8) I also disconnected the NIC on the new server to make sure we had no conflicts while we continued to troubleshoot. As of today 6/20/19, the new server has been put back on the network, I've wiped out the target drive and re-created it, reset it's network info, set up a new Migration Job, and going to try another Cutover this weekend. Any tips, suggestions, or other ideas appreciated. Thanks, Don K
Profile Bloat in Azure VM and VMware VDI: A Policy-Driven Strategy for Reducing Storage Growth
OneDrive profile bloat is one of those issues that often starts as a minor desktop optimization discussion, but quickly becomes a storage, performance, and governance problem at enterprise scale. In Azure Virtual Machines and VMware VDI environments, when OneDrive is tied to the user profile, the sync cache, local file state, and stale content can accumulate over time and create unnecessary growth in profile containers, VHD/VHDX files, and backup overhead. The result is higher infrastructure cost, slower login and logoff times, and inconsistent user experience across pooled or multi-session desktops. This is not a problem that should be solved by disabling OneDrive. In most enterprise scenarios, OneDrive remains a critical collaboration workload, but it must be managed as a controlled service rather than a user-local convenience. The most effective strategy is to install OneDrive at the machine level, enforce policy by user class and device context, and use Files On-Demand and cloud content dehydration to minimize local persistence. This approach preserves user productivity while reducing the operational impact on virtualized desktop infrastructure. A policy-driven design is particularly important in multi-user environments where not all workloads should be treated the same. Developer desktops, standard business users, and restricted or consultant user groups have different productivity needs and different data-risk profiles. For example: General business users may benefit from a balanced policy with Files On-Demand enabled and moderate dehydration thresholds. Developer or QA environments may require more local flexibility while still controlling profile growth. Restricted or external-user populations should have strong sync boundaries, personal account restrictions, and minimal local persistence. To support this model, organizations should align their deployment around a few core principles: install OneDrive at the machine level in the standard image or build pipeline use group policy and loopback processing to apply user-specific policy based on OU or security group enable Files On-Demand by default configure Storage Sense and cloud content dehydration based on workload profile restrict personal Microsoft account sync in higher-risk scenarios use FSLogix compaction and profile optimization as secondary controls, not as the primary solution This model is especially relevant for organizations running Azure Virtual Desktop, Azure VM-based workloads, VMware Horizon, and other multi-user Windows desktop environments. The benefits are practical and measurable: lower local storage consumption, reduced VHD/VHDX growth, improved desktop performance, lower backup cost, and stronger governance over enterprise data movement. As IT and endpoint engineering teams continue modernizing virtual desktop environments, I would encourage us to think of OneDrive not as a user-profile feature, but as an enterprise-managed workload with policy boundaries. When implemented properly, this gives us the best balance between productivity, storage efficiency, and security. I’d be very interested in hearing how others are handling this in their environments: Are you deploying OneDrive at the machine level? Are you enforcing Files On-Demand by default? How are you segmenting policy by user class or device type? Have you measured the impact on VHD/VHDX growth or profile size after enforcement? Source document: https://github.com/RodrigoACriscuolo/criscra/blob/main/Home.Profile-Bloat
Force a specific default lock screen and logon image
Dear, I currently have a DC deployed on Windows Server 2019. i want to configure a specific default image on lock screens on Windows 10 pro clients via group policy. Is this possible or is it only compatible with Enterprise or Education editions? Thanks in advance,Windows Server 2025 hotpaching
Hola a todos, estoy evaluando la actualización de nuestra infraestructura de servidores hacia Windows Server 2025 Datacenter. Me interesa especialmente la funcionalidad de Hotpatching para aplicar parches de seguridad sin requerir reinicios mensuales en los servidores de producción. Mi duda es: ¿Es obligatorio mantener la máquina conectada de forma permanente a Azure Arc para poder beneficiarnos del Hotpatching en un entorno físico tradicional/On-Premises, o existen mecanismos para distribuir estas actualizaciones mediante un servidor WSUS local Microsoft Configuration Manager en entornos aislados? Agradezco de antemano vuestra ayuda.HA Print Service Windows 2025 Server
There are two servers running Windows Server, both with the Print Spooler service enabled. They share the same printer queues. I created a CNAME alias named "printcore" pointing to Server01; the client can successfully connect to the printer using the UNC path `\\printcore\hpprincipal`, but if I change the alias to point to Server02, the client's connection to the printer fails. I enabled the Service Principal Name (SPN), but that didn't solve the issue. I need help setting up a High Availability (HA) environment for the print service. Alias: `printcore` (pointing to Server01 and Server02)BLOG: Windows Insiders - State of vbscript deprecation - September 2026
While I greatly appreciate the decision of vbscript / cscript / wscript removal, with security and hardening in mind – I would also appreciate if Microsoft could be actively using the vNext release channel, preparing for feature removal. With this blogpost, I am sharing my point of view on the state of dependencies I am seeing in this regard, focusing on a way forward towards the full removal of vbscript. My findings show, that there is a quite some action required, and this stands a bit contrary to the announcement, Microsoft intends removing the optional feature of vbscript by default with the upcoming release - anticipated by fall 2027. Given my lessons learned from Secure Boot CA2023 exchange initiative, Microsoft guidance, foremost PowerShell based scripts, tooling and dashboards have been released quite late, looking at the timeline, considering the impact and scale customers had to deal with, and consequences for their security posture if they are not ready and done, with first certificates to expire soon. Taking this learning into account and and projecting it to vbscript deprecration I come to the following conclusion: SMB customers, enterprises, Microsoft Products, see below, are required to be updated or replaced, in order of adopting this change. I believe there is quite some communication and learning curve required for users, admins, enterprises and OEMs in adopting the implicated change and including changed workflows and automation processes. Looking forward to the next Windows Insider and esp. Windows Server Insider vNext builds! Both Windows Insiders and Windows Server Insiders, also including ISV and OEMs may assist in reviewing and validating the new workflows required - assuming vbscript deprecation is in effect, as planned. Without further ado, I am sharing my observations in regard to VBScript deprecation. I will try to keep this blogpost updated as soon I am aware about public facing changes. Third-Party AMD Their Chipset drivers installer, remains one of the major non-MSFT related adoption blockers for FOD VBSScript removal. Suggestions: Microsoft should initiate talks with AMD and other ISV and OEMs fixing their dependencies, also offering other solutions, see below. Currently AMD Chipset drivers silently using vbscript calls checking for OS and HW platform compatibility. The installer fails when vbscript optional feature is removed. OEM, ISV and Enterprise Potentially affected: expected dependencies for imaging, deployment and management workflows. Related or unrelated to Microsoft products. LOB apps custom Office Integration logon and logoff scripts setup and installers Recommendation: Please observe vbscript related events in Windows Event Viewer at scale using PowerShell, Remoting or Windows Event Subscriptions: VBScriptDeprecationAlert Event ID 4096 VBScript is scheduled for deprecation. Our telemetry indicates that your system is currently utilizing VBScript. We strongly recommend identifying and migrating away from any VBScript dependencies at the earliest. The following process has been detected as using VBScript. The associated process tree and call stack are provided below to assist in identifying the scenario in which VBScript was invoked. Microsoft Windows Server and Client OS affected: slmgr.vbs / printer management vbscripts / product activation logic and UX, setup.exe, slui.exe September 2026 update: Microsoft has published this new guidance surfacing PowerShell commandlets in their lastest OS releases. Office 2024 LTSC affected: slmgr.vbs / ospp.vbs / Office deployment toolkit / product activation logic Microsoft has placed a new PowerShell based script into the respective OSPP folder. This script however is rather offering on checking licensing and cannot activate the Office product at this time. Microsoft 365 Business, Enterprise, Home, Family Affected: ospp.vbs despite being subscription based will also trouble with activation once vbscript is removed Sconfig Related to product activation. no changes so far, relies on external changes. The script itself is safe to comply with the change, now it has been reworked and updated using PowerShell , starting Windows Server 2022. WinRM Affected: the whole WinRM configuration command, e.g. winrm qc Windows Server Roles and Features: KMS / ADBA Potentially affected as they rely on slmgr for adding and removing CSVLK keys. Windows Server Roles and Features: IIS legacy IIS extension management. Windows Server Roles and Features: WSUS related deployment and configuration scripts. System Center Products incl. ConfigMgr there might be depencendies for OS deployments in regard to OS imaging. ADK, esp. Windows Imaging Tools and VAMT 3 potentially affected. Need to adopt changes in regard to activation and other operations. Suggestions: Recommending all these scripts being converted using Claude or Copilot from vbscript to PowerShell. Providing a serviceable PS modules, especially for printer management, product activation, which enables enterprises to automate their activations and printers, even though Microsoft is going to remove vbscript. The modules should be improved for existing day two adminstration tasks and workflows. slmgr, in particular, had some nuances that were tedious such as identifying and removing (stale) activation keys. Existing tools like slmgr and other will not work well in remoting. They do something but their interactive parts and outputs are reserved for interactive user sessions. Example: you can use slmgr in a remote PowerShell session for installing and activating a key but therer is no result return to the shell. Combining slui.exe and slmgr.vbs into aforementioned improvements in functionality and syntax. Consider support for PowerShell 7 in WinRE and Offline Setup phase. Many thanks for your consideration! Directory: C:\Windows\System32\Printing_Admin_Scripts\en-US Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 10:43 AM 98756 prncnfg.vbs -a--- 4/16/2026 10:43 AM 66172 prndrvr.vbs -a--- 4/16/2026 10:43 AM 62698 prnjobs.vbs -a--- 4/16/2026 10:43 AM 95908 prnmngr.vbs -a--- 4/16/2026 10:43 AM 71616 prnport.vbs -a--- 4/16/2026 10:43 AM 44278 prnqctl.vbs -a--- 4/16/2026 10:43 AM 22612 pubprn.vbs Directory: C:\Windows\System32 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 4119 CallUxxProvider.vbs -a--- 4/16/2026 9:14 AM 145712 slmgr.vbs -a--- 4/16/2026 9:14 AM 1720 SyncAppvPublishingServer.vbs -a--- 4/16/2026 9:14 AM 204072 winrm.vbs Directory: C:\Windows\SysWOW64\Printing_Admin_Scripts\en-US Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 10:43 AM 98756 prncnfg.vbs -a--- 4/16/2026 10:43 AM 66172 prndrvr.vbs -a--- 4/16/2026 10:43 AM 62698 prnjobs.vbs -a--- 4/16/2026 10:43 AM 95908 prnmngr.vbs -a--- 4/16/2026 10:43 AM 71616 prnport.vbs -a--- 4/16/2026 10:43 AM 44278 prnqctl.vbs -a--- 4/16/2026 10:43 AM 22612 pubprn.vbs Directory: C:\Windows\SysWOW64 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 145712 slmgr.vbs -a--- 4/16/2026 9:14 AM 204072 winrm.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-a..nagement-appvclient_31bf3856ad364e35_10.0.29574.1000_none_0895f7c27f109b8a Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 1720 SyncAppvPublishingServer.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-iis-legacyscripts_31bf3856ad364e35_10.0.29574.1000_none_ba69ed912e209e30 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 98133 adsutil.vbs -a--- 4/16/2026 9:14 AM 41401 IIsExt.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-p..inscripts.resources_31bf3856ad364e35_10.0.29574.1000_en-us_ 4ad0e09e0339f1ef Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 10:43 AM 98756 prncnfg.vbs -a--- 4/16/2026 10:43 AM 66172 prndrvr.vbs -a--- 4/16/2026 10:43 AM 62698 prnjobs.vbs -a--- 4/16/2026 10:43 AM 95908 prnmngr.vbs -a--- 4/16/2026 10:43 AM 71616 prnport.vbs -a--- 4/16/2026 10:43 AM 44278 prnqctl.vbs -a--- 4/16/2026 10:43 AM 22612 pubprn.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-s..r-core-mgmtprovider_31bf3856ad364e35_10.0.29574.1000_none_62cec50667f8da2a Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 4119 CallUxxProvider.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-security-spp-tools_31bf3856ad364e35_10.0.29574.1000_none_81bcc6c67609fdb9 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 145712 slmgr.vbs Directory: C:\Windows\WinSxS\amd64_microsoft-windows-w..for-management-core_31bf3856ad364e35_10.0.29574.1000_none_0688f60763f16bc8 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 204072 winrm.vbs Directory: C:\Windows\WinSxS\amd64_updateservices-services_31bf3856ad364e35_10.0.29574.1000_none_bae89f3176313538 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 8332 DynamicCompression.vbs -a--- 4/16/2026 9:14 AM 4289 SetAppPool.vbs -a--- 4/16/2026 9:14 AM 5813 SetMimeMap.vbs Directory: C:\Windows\WinSxS\wow64_microsoft-windows-iis-legacyscripts_31bf3856ad364e35_10.0.29574.1000_none_c4be97e36281602b Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 41401 IIsExt.vbs Directory: C:\Windows\WinSxS\wow64_microsoft-windows-p..inscripts.resources_31bf3856ad364e35_10.0.29574.1000_en-us_ 55258af0379ab3ea Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 10:43 AM 98756 prncnfg.vbs -a--- 4/16/2026 10:43 AM 66172 prndrvr.vbs -a--- 4/16/2026 10:43 AM 62698 prnjobs.vbs -a--- 4/16/2026 10:43 AM 95908 prnmngr.vbs -a--- 4/16/2026 10:43 AM 71616 prnport.vbs -a--- 4/16/2026 10:43 AM 44278 prnqctl.vbs -a--- 4/16/2026 10:43 AM 22612 pubprn.vbs Directory: C:\Windows\WinSxS\wow64_microsoft-windows-security-spp-tools_31bf3856ad364e35_10.0.29574.1000_none_8c117118aa6abfb4 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 145712 slmgr.vbs Directory: C:\Windows\WinSxS\wow64_microsoft-windows-w..for-management-core_31bf3856ad364e35_10.0.29574.1000_none_10dda05998522dc3 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 4/16/2026 9:14 AM 204072 winrm.vbs related announcements: https://techcommunity.microsoft.com/blog/Windows-ITPro-blog/vbscript-deprecation-timelines-and-next-steps/4148301 https://techcommunity.microsoft.com/blog/windows-itpro-blog/keep-windows-activation-automation-working-with-powershell/4540459
