HOW-TO: Import Out of Band Updates to WSUS using Microsoft Edge Chromium IE Mode and PowerShell
----- I recommend using https://www.powershellgallery.com/packages/Import-WSUSUpdate Full instructions to install the module are located here - https://www.ajtek.ca/blog/the-new-way-to-import-updates-into-wsus/ ----- History: 09/12/2023 - adding PowerShell method to the OP 07/30/2023 - please follow the latest comments for the updated approach using PowerShell. The method in the OP has become obsolete 01/13/2022 - update links and clarification to prevent an error "This update cannot be imported into Windows Server Update Services, because it is not compatible with your version of WSUS", added Troubleshooting and Q&A section. 02/11/2021 - initial version PREREQUISITES: Windows 10 / 11 / Windows Server 2016 or later with WSUS RSAT Tool installed. latest Microsoft Edge installed, version 97 as of time of writing. Internet Explorer (mode) is installed in Settings > Apps > Optional Features or equivalent location in Windows 11 HOW-TO: - Open Edge 97 or later - Open Microsoft Edge Options > Default Browser - Change "Allow Sites to be reloaded in Internet Explorer Mode" to 'Allow' - Add links to add to Microsoft Edge IE Mode - Remove all other links in the scope of *.catalog.update.microsoft.com, only these shall remain for the catalog.update.microsoft.com page. https://catalog.update.microsoft.com/ https://catalog.update.microsoft.com/v7/site/Home.aspx see screenshots below for better illustration. - Close Edge and all catalog tabs if there were any open, especially if you use "Open tabs from the previous session" feature - Open WSUS MMC and right click Updates from the tree > Import Updates - The link in Edge should open in IE mode, there are several indicators on this the open tab to point to https://catalog.update.microsoft.com/v7/site/Home.aspx?SKU=WSUS&Version=10.0.xxxxx.xxxx&ServerName=YOURSERVER.CONTOSO.LOCAL&PortNumber=8531&Ssl=True&Protocol=1.20 NOTES 1.When the link opened in importing updates from WSUS MMC does not contain the "v7/site/" part or does contain a https://www.update instead of https://catalog.update your configuration is wrong. 2. The "Default" setting will not be sufficient to allow the installation and use of the ActiveX plugin. Go back to your update catalog tab, Install the ActiveX if you have not done on this box already. Check if you have not setup restrictions to execute or install ActiveX plugins in IE directly or via group policy. 3. Edge now has the ability to an IE Mode button. Also it has a new feature to automatically add pages to the exception list. Do not use this ability as shown in the picture for this use case as it might add wrong exceptions to the list. 4. When there are wrong exceptions in the exception list for IE mode it might not work correctly and cause a missing but very important redirection, which ultimately cause the import to fail. More troubleshooting assistance below. LINKS STARTING FROM DECEMBER 2021 / JANUARY 2022: Links to add to Microsoft Edge IE Mode https://catalog.update.microsoft.com/ https://catalog.update.microsoft.com/v7/site/Home.aspx TROUBLESHOOTING: Q 1: Microsoft Edge does not allow me to configure any IE Site Mode links (greyed out). A: Either you have not enabled "Allow Sites to be reloaded in Internet Explorer Mode" to 'Allow', or your enterprise has set policies to prevent that. This should be clearly indicated by a lock and message in the Edge settings tab. Q 2: I have followed this guide or a previous version. I can see the cart to import into WSUS but cannot import any or just specific updates. Others fail with a message "This update cannot be imported into Windows Server Update Services, because it is not compatible with your version of WSUS". A: This is a "known" issue and the guide has been updated to reflect this issue and a potential change on the server-side. Please make sure only the two links are included in your IE mode list. They may not include www in the link name. You need to include both links, not just one or the other as in the previous version of this guide. Q 3: May I use the new Edge feature in Settings > Appearance > Internet Explorer Mode button A: I would recommend to refrain using this feature, as the mechanism between WSUS update import and the browser is extremly picky. It would not work if you just copy the same link into a browser tab. The feature of the cart to import into WSUS will be likely missing and you can just download to the Download folder instead. Q 4: Edge offers me to restart this tab in IE mode next time. A: you should not receive this message, otherwise the exceptions as stated in the guide are invalid or you have more than the stated links in place. Go through the guide again and double-check. Do not use this otherwise nice feature. It will cause to add more catalog links to the exception list which will cause an issue to import updates to WSUS, as described in Q #2. Thanks for the hint Eric_VanAelstyn, thanks to abbodi1406 for additional hints after this guide got invalid a redirection change in December 2021 / January 2022. cc AriaUpdated MissyQ cc for the other teams as I did not want to repost it in Edge and Servicing communities, unless you insist 🙂
Hostname Character Limit
Still being limited to 15 characters for hostnames in 2019 is very upsetting. In an age where we are deploying servers in multiple data centres, whether that be on premise or in the cloud and having multiple environments as well means trying to come up with sensible hostnames in just 15 characters is basically impossible. I’m sure I am not the only person who is frustrated by this limit and would very much like it if Microsoft was to revisit this limit and increase it to bring it in line with the wonderful limit our Linux friends enjoy.
Windows Server OSConfig and DSCv3
Introduction I wanted to formalize putting a post out here to get some discussion going on the attempts at modernization of Windows configuration, and importantly, infrastructure-as-code. Hopefully this is a healthy discussion that others can engage in. Much of what I'm going to try and post about is stuff we already are aware of, but I want to highlight how this is an ongoing concern with the Windows Server platform that makes it difficult to encourage people to even consider Windows in their environment other than for extremely legacy purposes. I want Windows Server to be the best it can be, and I encourage others to join in on the conversation! Problem Statement Windows Server needs a modernized configuration-as-code system. Must be capable of orchestrating without cloud tools (offline orchestration) Must provide for regular validation and attestation Ideally should be easily available to 3rd party configuration tools. Since Microsoft appears to have little interest in building their own modernized system that isn't Azure-based, this means that this MUST be orchestrated easily and securely by 3rd party tools. Should be as robust as GPO at maintaining and enforcing state. Security configurations in Windows are a right pain to manage with any 3rd party tooling, with the closest coming to it being the SecurityDSC module which wraps secedit.exe and security policy INFs. Why is OSConfig not the answer? OSConfig doesn't provide for me, as an engineer, to clearly define what the state of my machines are based on my company's business requirements. While the built-in Microsoft policy recommendations are great, there are reasons to deviate from these policies in a predictable and idempotent manner. Applying an OSConfig Baseline -> Then changing settings as-needed with special PowerShell commands This is not the answer. This is a bunch of imperative code that serves nobody. And it makes implementing this feature extremely challenging in today's modern world of Kubernetes, Docker, etc. I encourage the Windows Server team to engage with the PowerShell team on DSC 3.0. I think that team has it right, but they are a small group of people and do not have the resources to implement everything that would make DSC 3.0 a first-class configuration as code platform on Windows. And this is where the Windows team should come in. Steve Lee and crew have done a bangup job working on DSC 3.0, including taking feedback from folks to leverage Azure Bicep language for configuration. Security Policy Challenge The way to access security policies need to change. Even if I were to take DSC 3.0 I'd end up having to create a similar security policy INF file to import into Windows. It just seems so silly to me to have to write all of that out when Windows really should just provide an interface for doing this. In fact, security policy remains to be one of the largest problems to getting a good platform stood up. Windows Firewall Policy and GPO - The reason why host-based firewalling is painful to manage at scale in a Windows environment. GPO is definitely not the right place to be managing Windows firewall policy at scale. Particularly when you often have a core set of management rules you want to implement and application-specific needs. Making robust changes becomes a challenge since each policy is separate, preventing you from doing things like inheriting rules for higher level policies. While this is an inherent limitation of Group Policy, it highlights the need to get off of GPO as the core policy configuration tool for Windows. My recommendations I'd like for the Windows team to implement DSC 3.0-compatible resources for managing all core functionality of Windows. If you can do it in a GPO, you should be able to do it with Configuration as Code. Please stop relying on the community to make this work. All of this should be first party to the platform itself. Furthermore, I'd like to recommend that Microsoft either work with 3rd party configuration systems (Chef, Ansible, Puppet, Octopus, etc.) OR to also provide a way to hit the ground running. Perhaps something that integrates visually into Windows Admin Center would be nice. Conclusion This is a huge problem in the Windows world and continues to seem to fall on some deaf ears somewhere in the organization. While I no doubt am confident that the engineers on all of these teams very well know these issues and maybe even have discussed fixing them, clearly there's a breakdown somewhere.Active Directory Advanced Threat Hunting - Compare GPOs with the Security Compliance Toolkit
Dear Microsoft Active Directory friends, Even in the age of digital transformation, group policy settings (still) play a crucial role in maintaining network security and compliance. Advanced Hunting, an advanced technique for monitoring and analyzing these settings, is an indispensable tool for administrators. This method makes it possible to gain in-depth insights into the configuration and security situation of Windows networks. By using specific tools and scripts, professionals can detect security vulnerabilities, identify configuration errors and ensure that all group policies meet the highest security and compliance requirements. This article introduces the concept of Advanced Hunting for Group Policy settings and how it can transform management and security in IT infrastructures. Do we now need additional software and/or expensive tools? No, all we need is a little time, curiosity and the "Security Compliance Toolkit", which Microsoft is making available to us free of charge (thanks to Microsoft at this point). But first let's take a closer look at the MITRE techniques and the relevant Windows Event IDs. Before we start analyzing the group policy settings. We start with a list of MITRE techniques: Domain Policy Modification https://attack.mitre.org/techniques/T1484/ Domain Policy Modification: Group Policy Modification https://attack.mitre.org/techniques/T1484/001/ Group Policy Discovery https://attack.mitre.org/techniques/T1615/ Domain Policy Modification: Domain Trust Modification https://attack.mitre.org/techniques/T1484/002/ Unsecured Credentials: Group Policy Preferences https://attack.mitre.org/techniques/T1552/006/ The Windows Event ID's for the MITRE techniques: Domain Policy Modification 4739(S): Domain Policy was changed https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4739 Group Policy Discovery Appendix L: Events to Monitor https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l--events-to-monitor Domain Policy Modification: Domain Trust Modification 4716(S): Trusted domain information was modified https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4716 Compare the Default Domain Controllers Policy with the security baselines using the Policy Analyzer! So that we can compare the Default Domain Controllers Policy, we create a backup: Security Compliance Toolkit and Baselines can be downloaded here: https://www.microsoft.com/en-us/download/details.aspx?id=55319 We need the necessary tools and baselines: Extract the files: From the Windows-Server-2022-Security-Baseline-FINAL folder, copy the following file: Paste the file in the Policy Analyzer folder: Open the Policy Analyzer: NOTE: If you have a low screen resolution you may not be able to see the bottom part of the application. It is important that you see the bottom part so that you can adjust the path to the policy rule sets (see red marker). Now we have to add the default domain controller policy: Click on the import button: Give it a name and then click on safe: Now you can compare the policy with the security baseline: HAPPY COMPARING! If you want to examine your Active Directory with PowerShell, you will find a "small" compilation of various PowerShell scripts in the following link: https://github.com/tomwechsler/Active_Directory_Advanced_Threat_Hunting/tree/main/PowerShell NOTE: Before using these scripts, make sure that you have the necessary authorizations. This should always be in writing. Although the scripts do not change any settings or manipulate the system, it is your responsibility how you use these scripts! I hope that this information is helpful to you and that you have been given a good "little" foundation. This article/information is by no means complete and exhaustive. But I still hope that this information is helpful to you. Thank you for taking the time to read the article. Happy Comparing and Hunting, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechsler
Increasingly Issues with Windows Updates
As a Microsoft Partner we're patching the Windows Servers of our customers on a monthly basis. During the past months we recognized more and more issues with the updates (CU's) we wanted to deploy during the maintenance window (either via SCCM or directly through the web). The updates become bigger and bigger and the quality seems to drop 😞 Just wanted to let you know. Regards, PhilippUnderstanding Windows Update Services product categories for Windows Server 2022 and Azure Stack HCI
The new Server 2022 LTSC has arrived. And it is a great release. Some customers still struggle to find their SA benefits and ISOs / licenses and RDSH licenses in VLSC, but it is officially released. If you fail to find it contact VLSC support via phone. The Microsoft Teams have written excellent and brief blogs about the news in Storage, SMB, Security and other topics you can find on techcommunity.microsoft.com. Unrelated to this topic, links to some key improvements of Windows Server 2022 LTSC: Windows Server 2022 Security Baseline - Microsoft Tech Community Enabling HTTP/3 support on Windows Server 2022 - Microsoft Tech Community Storage Innovations in Windows Server 2022 - Microsoft Tech Community SMB over QUIC is now in public preview! - Microsoft Tech Community SMB Compression in Windows Server 2022 and Windows Insider - Microsoft Tech Community OPS104 Securing SMB from within and without - Microsoft Tech Community What's not yet published is changes to WSUS. "Hey Karl, do you speak about this legacy stuff to deploy Updates for on-premises?" Yes, it still exists and is still needed for SMB and SMC and bigger organizations, while latter might use ConfigMgr or MEMCM or ISV solutions, where WSUS is often a needed requirement. Technically we cannot expect anything new in WSUS? Why? The rule to not update any legacy MMCs is in place with Windows Server 2022 LTSC, so also there are no improvements or additions to any MMC consoles, Server Manager, or Active Directory Administrative Center (DSAC). An exception to this rule was an important bug in DSAC that got caught in Windows Server 2022. - Ultimately the issues with detection of WU client OS strings - since Windows Server 2016 and Windows 10 is not fixed in the WU database either. While it possible, there is a paid solution doing this for you to make your reporting great again. - Windows Admin Center support for Windows Update Services is not on the horizon either. I hope for Ignite 2021. So what has changed? Product Categories, naming, that one need to learn and understand. But before we get into let us recap about the history and where we come from. Over the past decades, naming of product categories was rather simple. - Windows Client had its own category per major release - Windows Server had its own category per major release - SQL Server had its own category per major release etc. With the era of Windows 10 OS, which applies to Server and Client OS alike, as these are very similar to the core, this has game changed a bit. At first all Windows 10 versions have been assigned to "Windows 10" category. Later, thankfully, the team added new categories per release. I will explain why this was important. What changed with Windows 10? With Windows 10 1903 Microsoft introduced "1903 and later" category which I supposed and promoted the idea to have one category for 1903 and 1909 as these share the binary same updates. Well, that did not happen. 1903 and later now includes updates for the following: 1903, 1909, 2004, 20H2 and 21H2, where 1903 and 1909 aswell as 2004-21H2 share the same binary updates. So how about Windows Server, Windows Server product like SQL Server etc? Simple as that one category for each release: Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016, 2019 SQL Server each release had an own category from 2000 through 2019. So far so good and simple. Another OS emerged called Azure Stack HCI, got it's own product category. But only for the initial release. Another OS emerged for those with Software Assurance rights, called Windows Server version xxxx aka Windows Server SAC, while xxxx follow the Windows 10 OS naming of YYMM so 1903 for March 2019 release - or more precisely end of development cycle (branch), as release happened sometimes later. Windows Server version will no longer be available after version 2004. Microsoft noticed hindsight putting Azure Stack HCI, which is a SaaS product - same to Windows Server version (SAC) and has a similar release schedule - in one product category was an unfortunate design decision. Why is one product category for any SAC product an unfortunate decision? It means that the limitation Windows 10 versions having all releases in one product category repeats with Windows 11 and you face the same problem. If you place all SAC products into one category, it makes it ultimately harder for an IT Pro using WSUS to automatically approve specific version and decline SAC versions that are no longer in use across the organization. This is because SAC products do have an intended and short support period and will be replaced in production and so will play no further role but bloat up your database and metadata and compliance lists (WSUS reports) with unneeded versions. From this perspective, it would have been wise to not repeat the same mistake name it Azure Stack HCI from the start but Azure Stack HCI, version 20H2. Same as Microsoft factually did separate for Windows Server version, xxx in WSUS product categories. Well that did not happen, did it? To the core of this article. What's next? Starting with Windows Server 2022 and all 21H2 releases this familiar game will change rules. Windows Server 2022 will not see an own product category called "Windows Server 2022" as we would assume and how it is officially named. Azure Stack HCI OS will not be included into Azure Stack HCI OS category, except the first release version 20H2. Both updates will be included in a new category named "Microsoft Server operating system-21H2" Does this break any naming convention and former logic? Does it bother? You decide. How about the driver and servicing drivers categories? That's still complicated. see: https://www.urtech.ca/2016/12/solved-what-do-the-windows-10-product-names-mean-in-wsus/ How about Windows Server 2022 Azure Edition and neat Hotpatch feature? You would assume that due to the naming convention you might find it in the near of Microsoft Server 2022 Azure Edition as a seperate product category. Be disappointed. The naming convention does not apply to any extend. It is called Server 2022 Hotpatch category, yes the full name, not even Windows Server 2022 Hotpatch or sorts. Pardon me but seems like someone hotpatched the category name itself. I do not believe they will change this as this would stress to change the whole servicing and metadata and break things. Any other caveats? There are Windows Server categories for 2019 and other in the developer tools section. This happened due to a catalogue update error, which causes WSUS and ConfigMgr to sync any updates in 2021. These categories do contain any updates. So, make sure you do not check or bother with the Server Categories in the Developer Tools Products. TLDR: - do not use product categories for Windows Server in Developer tools. These are dead. - you will find Azure Stack HCI OS in the Azure Stack HCI product category, but only the initial version 20H2. No future ones. - you will find future Azure Stack HCI OS version 21H2 and Server 2022 LTSC in the category named Microsoft Server operating system-21H2. Source and kudos: Thank you Artem Pronichkin, for the excursion and your help on the topic. https://twitter.com/pronichkin/status/1435723832598224897 History: 01/13/2022 - added notes about Windows Server Azure Edition and Hotpatch, minor fixes, corrected name from ADAC to DSAC 09/24/2021 - typo / grammar corrections 09/10/2021 - more insight from Artem, see reply 09/10/2021 - formatting, typo / grammar corrections, added screenshot 09/09/2021 - formatting, corrections
External private IP addresses registering with DNS server
Hello all, I've been trying to fine-tune our NIDS configuration (which predates my employment here) and more specifically trying to figure out why certain IP addresses/ranges that we don't use, keep appearing in reports/logs. I think I've figured out the root cause, but I'm not sure of the best way to fix it: We have a number of remote users who connect to our network by VPN. As best I can tell, when their laptops connect to the network, they're sending updates to the DNS server running on the DC with both the IP address of their VPN interface (routable on our network) and their private IP address on their home LAN (obviously not routable) - if I do an nslookup on a domain machine, the DC returns two A records, one for each address. This has a slight ripple effect through the network - which manifests mostly with Windows Update Delivery Optimization, where the peer discovery process frequently gets the non-routable private IP somehow and then tries to download Windows updates from it. Long story short: what is the best way to prevent VPN'ed machines from registering external private IP addresses with the DNS server running on the DC?BLOG: Determine and modernize Filesystem Deduplication
Version history - 1.4 revised script so ReFS volumes with classic dedup will be identified, added more eligibly checks and error handling - 1.3 added point #4 in migration guidance - 1.2 revised script - 1.1 formatting This blog explains the two Windows deduplication modes classic Windows Data Deduplication (ReFS or NTFS) and ReFS Deduplication (ReFS). It covers how they differ, why you should consider upgrading to Windows Server 2025 to leverage the new ReFS dedup engine, and clear warnings about scenarios where ReFS is not recommended. Practical migration guidance and detection commands are included. Differences between classic dedup and ReFS dedup File system: Classic dedup runs on NTFS or ReFS; ReFS dedup runs on ReFS and Windows Server 2025 or later, only. Implementation: They are separate engines with different metadata formats and management cmdlets. Management: Classic dedup uses the Dedup PowerShell module (Get‑DedupVolume, Start‑DedupJob, Disable‑DedupVolume). ReFS dedup uses its own ReFS dedup cmdlets (Get‑ReFSDedupStatus, Enable‑ReFSDedup). Conversion: There is no in‑place conversion between the two; metadata and chunk formats are incompatible. Improvements: the new in-line ReFS Deduplication leverages the advantages of ReFS files system. This makes deduplication more efficient and less CPU intensive. The new ReFS Deduplication can also compress data in-line using L1Z algorithm. This makes it up to par with enterprise solutions, often found in SAN storage or Linux appliances. Compression needs to be set per volume, and optional. Why upgrade to Windows Server 2025 Improved version of ReFS Filesystem Improved ReFS in-line deduplication + optional L1Z compression: Server 2025 includes enhancements to ReFS dedup performance, scalability, and integration with modern storage features. Support and fixes: Windows Server 2016 and 2019 are past mainstream support, increasing the likelihood of costly support cases and delayed fixes; upgrading reduces operational risk and ensures access to ongoing improvements. Future compatibility: Newer OS releases receive optimizations and bug fixes for ReFS and dedup scenarios that older releases will not. SMB compression: for reasonably faster data transfer at minimal CPU when transferring data through the networks. Feature and security related improvements refer to availabile Microsoft Windows Server 2025 Summit content on techcommunity.microsoft.com Scenarios where ReFS is not recommended ReFS on SAN in clustered CSV environments: Avoid placing ReFS dedup on top of SAN‑backed Cluster Shared Volumes (CSVFS) in production clusters; clustered SAN/CSV scenarios causing severe performance issues in practice. Please refer to the ReFS documentation. (personal opinion and experience, not endorsed by Microsoft): Many small, fast‑changing files: Workloads with frequent small writes—user profiles, redirected AppData, or applications that churn small config files (for example, Lotus Notes config files)—can cause locks, performance degradation, or unexpected behavior on ReFS. Exclude these paths from dedup or keep them on NTFS. Restrictions, like lockups or high RAM consumption, deadlocks / BSOD might have been addressed in Windows Server 2025. Improving reliability and performance is a top goal for ReFS, to improve the adoption and feature parity with NTFS. For information about feature parity please refer to the ReFS documentation. Migration guidance The following instructions describe a high level and supported migration path from Windows deduplication using the NTFS file system to native ReFS Deduplication. Note: Step #3, data migration is not required when already using ReFS with Data Deduplication. In this case it's enough to execute step #1 and #2. Note: Validate on non‑production data first. Plan for rehydration time and network/storage throughput. Ensure backups are current before starting. Make sure to have a full backup before upgrading Server OS or making changes. 1. Disable classic dedup on the NTFS source: Disable-DedupVolume -Volume YourDriveLetter: 2. Rehydrate (un‑deduplicate) the data: Start-DedupJob -Volume YourDriveLetter: -Type Unoptimization 3. Copy or move data to a ReFS volume (new target): For straightforward NTFS→ReFS copies, robocopy is recommended. Another alternative is the Windows Admin Center File Server Migration Feature For complex scenarios, open files long path names very large datasets (< 5 TB) or many small files restructuring, GUI (including Windows Server Core) automation, improved logging cloud/hybrid migrations I recommend the usage of GScopy Enterprise by GuruSquad for higher speed (up to 40%) and reliability. 4. Optionally remove the Windows Server feature When there is no old deduplication in use consider to remove the feature. Your advantages of doing so: removes an unneccessary service. removes the file system filter driver for dedup, which causes performance impacts, even when not in use. removes the PowerShell commandlets for the old dedup, so they cannot mistakenly used by existing scripts, unaware admins etc. When migrating files over network: SMB compression: consider both source and target run Windows Server 2025 and leverage SMB compression. SMB Compression is available in Microsoft xcopy, Microsoft robocopy and Gurusquad GScopy Enterprise. Balancing and Teaming with SMB: SMB does not require LFBO or SET Teaming. It automagically detects network links and actively balances on its own on Windows Server 2016 and later. Using teaming, depending the configuration, can negatively affect transfer speed. Quick detection and diagnostic commands Check file systems: Get-Volume | Select DriveLetter, FileSystem Check classic dedup feature: Get-WindowsFeature -Name FS-Data-Deduplication Get-DedupVolume Get-DedupStatus Check ReFS dedup: Get-Command -Module Microsoft.ReFsDedup.Commands Get-ReFSDedupStatus -Volume YourDriveLetter: Diagnostic script to detect both: <# .SYNOPSIS Detects classic NTFS Data Deduplication and ReFS Deduplication across local volumes. .DESCRIPTION - Reports NTFS volumes with classic Data Dedup enabled. - Lists ReFS volumes present on the host. - If the ReFS dedup cmdlet exists AND OS build >= 26100, checks ReFS dedup status per ReFS volume. - Color coding: * Classic dedup enabled → Yellow * Classic dedup not enabled → Cyan * ReFS dedup enabled → Green * ReFS dedup not enabled → Cyan .NOTES Version: 1.7 Author: Karl Wester-Ebbinghaus + Copilot Requirements: Elevated PowerShell session, PowerShell 5.1 or newer Supported OS: Windows Server 2025, Azure Stack HCI 24H2 or newer Unsupported OS: Windows 10, Windows 11 (script terminates) #> #region Initialization Write-Verbose "Initializing variables and environment..." $Volumes = $null $Volume = $null $DedupVolumesList = $null $DedupReFSVolumesList = $null $DedupReFSVolumesListLetters = $null $DedupReFSStatus = $null $refsCmd = $null $OSBuild = $null $runReFSDedupChecks = $null #endregion Initialization #region Volume Discovery Clear-Host Write-Verbose "Querying NTFS and ReFS volumes..." $Volumes = Get-Volume | Where-Object FileSystem -in 'NTFS','ReFS' #endregion Volume Discovery #region ReFS Dedup Cmdlet, OS Build and OS SKU Detection Write-Verbose "Checking for ReFS deduplication cmdlet..." $refsCmd = Get-Command -Name Get-ReFSDedupStatus -ErrorAction SilentlyContinue Write-Verbose "Reading OS build number..." try { $OSBuild = [int](Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name CurrentBuildNumber).CurrentBuildNumber } catch { Write-Verbose "Registry read for OS build failed. Falling back to Environment OSVersion." $OSBuild = [int][Environment]::OSVersion.Version.Build } # end try/catch for OS build detection Write-Verbose "Checking OS InstallationType and EditionID..." $CurrentVersionKey = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' $InstallationType = $CurrentVersionKey.InstallationType # "Client" or "Server" $EditionID = $CurrentVersionKey.EditionID # e.g. "AzureStackHCI", "ServerStandard", etc. Write-Verbose "Detected InstallationType: $InstallationType" Write-Verbose "Detected EditionID: $EditionID" Write-Verbose "Detected OSBuild: $OSBuild" # Block Windows 10/11 (Client OS) if ($InstallationType -eq 'Client') { Write-Error "Unsupported OS detected: Windows Client (Windows 10/11). Only Windows Server or Azure Stack HCI are supported. Script will terminate." exit } # Allow Azure Stack HCI explicitly if ($EditionID -eq 'AzureStackHCI') { Write-Verbose "Azure Stack HCI detected. Supported platform." } else { # Must be Windows Server if ($InstallationType -ne 'Server') { Write-Error "Unsupported OS detected. Only Windows Server or Azure Stack HCI are supported. Script will terminate." exit } Write-Verbose "Windows Server detected (EditionID: $EditionID). Supported platform." } Write-Verbose "Evaluating ReFS dedup eligibility based on cmdlet presence and build >= 26100..." $runReFSDedupChecks = $false if ($refsCmd -and ($OSBuild -ge 26100)) { $runReFSDedupChecks = $true Write-Verbose "ReFS dedup checks ENABLED (cmdlet present and OS build >= 26100)." } else { Write-Verbose "ReFS dedup checks DISABLED (cmdlet missing or OS build < 26100)." } #endregion ReFS Dedup Cmdlet, OS Build and OS SKU Detection #region Main Loop foreach ($Volume in $Volumes) { # begin foreach volume loop Write-Host "Volume $($Volume.DriveLetter): ($($Volume.FileSystem))" Write-Verbose "Processing volume $($Volume.DriveLetter)..." #region Classic Dedup + ReFS Volume Listing if ($Volume.FileSystem -eq 'NTFS' -or $Volume.FileSystem -eq 'ReFS') { Write-Verbose "Checking classic deduplication status for volume $($Volume.DriveLetter)..." $DedupVolumesList = Get-DedupVolume -Volume $Volume.DriveLetter -ErrorAction SilentlyContinue if ($DedupVolumesList) { Write-Host " → Classic Data Dedup ENABLED on $($Volume.DriveLetter), $($Volume.FileSystem)" -ForegroundColor Yellow } else { Write-Host " → Classic Data Dedup NOT enabled on $($Volume.DriveLetter),$($Volume.FileSystem)" -ForegroundColor Cyan } # end if classic dedup enabled Write-Verbose "Listing ReFS volumes on host..." $DedupReFSVolumesList = Get-Volume | Where-Object FileSystem -eq 'ReFS' if ($DedupReFSVolumesList) { $DedupReFSVolumesListLetters = ($DedupReFSVolumesList | ForEach-Object { $_.DriveLetter }) -join ',' Write-Host " → ReFS volumes present on host: $DedupReFSVolumesListLetters" } else { Write-Host " → No ReFS volumes detected on host" } # end if ReFS volumes present } # end NTFS/ReFS block #endregion Classic Dedup + ReFS Volume Listing #region ReFS Dedup Status if ($Volume.FileSystem -eq 'ReFS') { if ($runReFSDedupChecks) { Write-Verbose "Checking ReFS deduplication status for volume $($Volume.DriveLetter)..." $DedupReFSStatus = Get-ReFSDedupStatus -Volume $Volume.DriveLetter -ErrorAction SilentlyContinue if ($DedupReFSStatus) { Write-Host " → ReFS Dedup ENABLED on $($Volume.DriveLetter), $($Volume.FileSystem)" -ForegroundColor Green } else { Write-Host " → ReFS Dedup NOT enabled on $($Volume.DriveLetter), $($Volume.FileSystem)" -ForegroundColor Cyan } # end if ReFS dedup enabled } else { if (-not $refsCmd) { Write-Error " → Skipping ReFS dedup check: Get-ReFSDedupStatus cmdlet not present" -ForegroundColor Cyan } else { Write-Error " → Skipping ReFS dedup check: OS build $OSBuild < required 26100" -ForegroundColor Cyan } # end reason for skipping ReFS dedup check } # end if runReFSDedupChecks } # end if ReFS filesystem block #endregion ReFS Dedup Status Write-Host "" } # end foreach volume loop #endregion Main Loop #region End Write-Verbose "Script completed." #endregion End Recommendations and next steps Inventory: Identify volumes using NTFS dedup and ReFS dedup, and map workloads that create many small or rapidly changing files. Plan: Schedule rehydration and migration windows; test ReFS dedup on representative datasets. Upgrade: Prioritize upgrading servers still on 2016/2019 (End of Mainstream Support) to reduce support risk and gain the latest ReFS dedup improvements. Kindly consider reading my Windows Server Installation Guidance and Windows Server Upgrade Guidance Exclude: Keep user profiles, AppData, and other high‑churn small‑file paths off ReFS dedup or on NTFS. Consider Dedup and compression: Enable compression optionally. Mind ReFS dedup compression is not the same as compress files integration in File Explorer or File Explorer properties (Windows 9x). It's transparent to the application Make smart decisions: Avoid using dedup when the dataset is changing fast or your dedup + compression rate is below 20%. Usually you can expect 40% or more savings, and up to 80% in specific use cases like VDI VHDX Plan your dedup jobs: Ensure making use planning features for dedup jobs through PowerShell or Windows Admin Center (WAC) when using ReFS dedup on more than one volume per Server. Otherwise they might all run at the same time and impact your storage performance (esp. spinning rust) and consumption of RAM and CPU. Share and Educate: Inform your infrastructure team about the changes so they avoid using the traditional dedup on ReFS.Add Passkey support to Active Directory
Everyone, Please go to the feedback hub and upvote my suggestion to add passkey support to Active Directory Domain Services: https://aka.ms/AAw8z54 The reason I am recommending this is because there needs to be a standard way to use passkeys in an AD environment.
