management
699 TopicsAzure Update Manager to support CIS hardened images among other images
What’s coming in by first week of August: Azure Update Manager will add support for 35 CIS hardened images. This is the first time that Update Management product in Azure is supporting CIS hardened images. Apart from CIS hardened images, Azure Update Manager will also add support for 59 other images to unblock Automation Update Management migrations to Azure Update Manager. What’s coming in September: After this release, another batch of 30 images will be added support for. Please refer to the article below to check the details of which images will be supported. Below 35 CIS images will be supported by Azure Update Manager by first week of August. Please note Publisher for all these images is center-for-internet-security-inc. Offer Plan cis-windows-server cis-windows-server2016-l1-gen1 cis-windows-server2019-l1-gen1 cis-windows-server2019-l1-gen2 cis-windows-server2019-l2-gen1 cis-windows-server2022-l1-gen2 cis-windows-server2022-l2-gen2 cis-windows-server2022-l1-gen1 cis-windows-server-2022-l1 cis-windows-server-2022-l1 cis-windows-server-2022-l1-gen2 cis-windows-server-2022-l2 cis-windows-server-2022-l2 cis-windows-server-2022-l2-gen2 cis-windows-server-2019-v1-0-0-l1 cis-ws2019-l1 cis-windows-server-2019-v1-0-0-l2 cis-ws2019-l2 cis-windows-server-2016-v1-0-0-l1 cis--l1 cis-windows-server-2016-v1-0-0-l2 cis-ws2016-l2 cis-windows-server-2012-r2-v2-2-1-l2 cis-ws2012-r2-l2 cis-rhel9-l1 cis-rhel9-l1 cis-rhel9-l1-gen2 cis-rhel-8-l1 cis-rhel-8-l2 cis-rhel8-l2 cis-rhel-7-l2 cis-rhel7-l2 cis-rhel cis-redhat7-l1-gen1 cis-redhat8-l1-gen1 cis-redhat8-l2-gen1 cis-redhat9-l1-gen1 cis-redhat9-l1-gen2 cis-ubuntu-linux-2204-l1 cis-ubuntu-linux-2204-l1 cis-ubuntu-linux-2204-l1-gen2 cis-ubuntu-linux-2004-l1 cis-ubuntu2004-l1 cis-ubuntu-linux-1804-l1 cis-ubuntu1804-l1 cis-ubuntu cis-ubuntu1804-l1 cis-ubuntulinux2004-l1-gen1 cis-ubuntulinux2204-l1-gen1 cis-ubuntulinux2204-l1-gen2 cis-oracle-linux-8-l1 cis-oracle8-l1 Apart from CIS hardened images, below are the other 59 images which will be supported by Azure Update Manager by first week of August: Publisher Offer Plan almalinux almalinux-x86_64 8_7-gen2 belindaczsro1588885355210 belvmsrv01 belvmsrv003 cloudera cloudera-centos-os 7_5 cloud-infrastructure-services rds-farm-2019 rds-farm-2019 cloud-infrastructure-services ad-dc-2019 ad-dc-2019 cloud-infrastructure-services sftp-2016 sftp-2016 cloud-infrastructure-services ad-dc-2016 ad-dc-2016 cloud-infrastructure-services hpc2019-windows-server-2019 hpc2019-windows-server-2019 cloud-infrastructure-services dns-ubuntu-2004 dns-ubuntu-2004 cloud-infrastructure-services servercore-2019 servercore-2019 cloud-infrastructure-services ad-dc-2022 ad-dc-2022 cloud-infrastructure-services squid-ubuntu-2004 squid-ubuntu-2004 cognosys sql-server-2016-sp2-std-win2016-debug-utilities sql-server-2016-sp2-std-win2016-debug-utilities esri arcgis-enterprise byol-108 byol-109 byol-111 byol-1081 byol-1091 esri arcgis-enterprise-106 byol-1061 esri arcgis-enterprise-107 byol-1071 esri pro-byol pro-byol-29 filemagellc filemage-gateway-vm-win filemage-gateway-vm-win-001 filemage-gateway-vm-win-002 github github-enterprise github-enterprise matillion matillion matillion-etl-for-snowflake microsoft-ads windows-data-science-vm windows2016 windows2016byol microsoft-dsvm ubuntu-1804 1804-gen2 netapp netapp-oncommand-cloud-manager occm-byol nginxinc nginx-plus-ent-v1 nginx-plus-ent-centos7 ntegralinc1586961136942 ntg_oracle_8_7 ntg_oracle_8_7 procomputers almalinux-8-7 almalinux-8-7 procomputers rhel-8-2 rhel-8-2 RedHat rhel 8_9 redhat rhel-byos rhel-lvm79 rhel-lvm79-gen2 rhel-lvm8 rhel-lvm82-gen2 rhel-lvm83 rhel-lvm84 rhel-lvm84-gen2 rhel-lvm85-gen2 rhel-lvm86 rhel-lvm86-gen2 rhel-lvm87-gen2 rhel-raw76 redhat rhel 8.1 redhat rhel-sap 7.4 redhat rhel-sap 7.7 redhat rhel 89-gen2 southrivertech1586314123192 tn-ent-payg Tnentpayg southrivertech1586314123192 tn-sftp-payg Tnsftppayg suse sles-sap-15-sp2-byos gen2 suse sles-15-sp5 gen2 talend talend_re_image tlnd_re thorntechnologiesllc sftpgateway Sftpgateway veeam office365backup veeamoffice365backup veeam veeam-backup-replication veeam-backup-replication-v11 zscaler zscaler-private-access zpa-con-azure Below images will be supported in September: Publisher Offer Plan aod win2019azpolicy win2019azpolicy belindaczsro1588885355210 belvmsrv03 belvmsrv001 center-for-internet-security-inc cis-rhel-7-v2-2-0-l1 cis-rhel7-l1 center-for-internet-security-inc cis-rhel-7-stig cis-rhel-7-stig center-for-internet-security-inc cis-win-2016-stig cis-win-2016-stig center-for-internet-security-inc cis-windows-server-2012-r2-v2-2-1-l1 cis-ws2012-r2-l1 cloudrichness rockey_linux_image rockylinux86 Credativ Debian 8 microsoftdynamicsnav dynamicsnav 2017 microsoftwindowsserver windowsserver-hub 2012-r2-datacenter-hub 2016-datacenter-hub MicrosoftWindowsServer WindowsServer-HUB 2016-Datacenter-HUB ntegralinc1586961136942 ntg_cbl_mariner_2 ntg_cbl_mariner_2_gen2 openvpn openvpnas access_server_byol rapid7 nexpose-scan-engine nexpose-scan-engine rapid7 rapid7-vm-console rapid7-vm-console suse sles 12-sp3 suse sles-15-sp1-basic gen1 suse sles-15-sp2-basic gen1 suse sles-15-sp3-basic gen1 gen2 suse sles-15-sp4-basic gen2 suse sles-sap 12-sp3 15 gen2-15 suse sles-sap-byos 15 suse SLES-SAP-BYOS 15 suse sles-sap-15-sp1-byos gen1 Tenable tenablecorenessus tenablecorenessusbyolFrom AI pilots to public decisions: what it really takes to close the intelligence gap
Across the public sector, the conversation about AI has shifted. The question is no longer whether AI can generate insight—most leaders have already seen impressive pilots. The harder question is whether those insights survive the realities of government: public scrutiny, auditability, cross‑department delivery, and the need to explain decisions in plain language. That challenge was recently articulated by Sadaf Mozaffarian, writing in Smart Cities World, in the context of city‑scale AI deployments. Governments don’t need more experiments. They need decision‑ready intelligence—intelligence that can be acted on safely, governed consistently, and defended when outcomes are questioned. What’s emerging now is a more operational lens on AI adoption, one that exposes two issues many pilots quietly avoid. Decision latency is the real enemy In government, decision latency is not about slow analytics, it’s the time lost between having a signal and being able to act on it with confidence. Much of the focus in AI discussions is on accuracy, bias, or model performance. But in cities, the more damaging problem is often this latency. When data is fragmented across departments, policies live in PDFs, and institutional knowledge walks out the door at 5pm, leaders may have insight but still can’t decide fast enough. AI pilots often demonstrate answers in isolation, but they don’t reduce the friction between insight, approval, and execution. Decision‑ready intelligence directly attacks this problem. It brings together: Operational data already trusted by the organization Policy and regulatory context that constrains decisions Human checkpoints that reflect how accountability actually works The result isn’t faster answers—it’s faster decisions that stick, because they align with how governments are structured to operate. Institutional memory is infrastructure Cities invest heavily in physical infrastructure—roads, pipes, facilities—but far less deliberately in institutional memory. Yet planning rationales, inspection notes, precedent cases, and prior decisions are often what make or break today’s choices. Consider a routine enforcement or permitting decision that looks reasonable on current data, but quietly contradicts a prior settlement, a regulator’s interpretation, or a lesson learned during a past inquiry. AI systems that don’t account for this history don’t just miss context, they create risk. Decision‑ready intelligence treats institutional memory as a first‑class asset. It ensures that when AI supports a decision, it does so with: Access to relevant historical records and prior outcomes Clear lineage back to source documents and policies Logging that preserves not just what was decided, but why This is what allows governments to move faster without relearning the same lessons under audit pressure. Why this matters now Public sector AI initiatives rarely fail because of a lack of ambition. They stall because trust questions—governance, records, explainability—arrive too late. By the time leaders ask, “Can we stand behind this decision?” the system was never designed to answer. Decision‑ready intelligence flips that sequence. Governance is not bolted on after the pilot; it’s built into the operating model from the start. That’s what allows agencies to scale from a single use case to repeatable patterns across departments. A practical starting point The cities making progress aren’t trying to transform everything at once. They start small but visible: Identify one cross‑department “moment of truth” Define what must be logged, retained, and explainable Connect just enough data, policy, and work context to support that decision From there, they reuse the same patterns—governed data products, policy knowledge bases, and human‑in‑the‑loop workflows—to scale responsibly. AI in government will ultimately be judged the same way every public investment is judged: by outcomes, fairness, and public confidence. Closing the intelligence gap isn’t about smarter models. It’s about designing decision systems that reflect how governments actually work—and are held accountable. Learn more by reading Sadaf's full article: Closing the intelligence gap: how cities turn AI experiments into operational impact92Views0likes0CommentsGoogle fiber being blocked??
I’m on Google fiber and can't download the newest ISO. I get a msg that says some block of IPs is being blocked because they are not who they say they are. Likewise, I have no anonymizer running and my ip is my own on google fiber. error msg; message code 715-123130 and b64dd3c8-ed16-4d46-87ac-a871691f1c41.Solved759Views5likes10CommentsAutomating Windows Server Licensing Benefits with Azure Arc Policy
Introduction: Managing Windows Server benefits licensing across hybrid environments can be challenging. Azure Arc combined with Azure Policy simplifies this by automatically enforcing licensing compliance. This blog explains how the provided policy works and how to deploy it. Why implement this policy? Automating Windows Server Licensing Benefits with Azure Arc Policy ensures that all eligible machines are seamlessly enabled for essential management services, including Azure Update Manager, Best Practice Assessment, Change Tracking, Inventory, and Windows Admin Center integration. For organizations managing hundreds or thousands of servers, manual enablement can be time-consuming and error prone. This policy continuously monitors your environment, automatically identifying newly added machines and highlighting those missing the required benefits, so you can maintain compliance and streamline operations at scale This learn document detail the benefits available when Windows Server is connected via Azure Arc, especially for machines with Software Assurance or subscription licenses: https://learn.microsoft.com/en-us/azure/azure-arc/servers/windows-server-management-overview?tabs=portal Note – Ensure that your organization has the proper Software Assurance Benefits to cover the machines that are being assigned. Please reference this link for billing information Windows Server Management enabled by Azure Arc - Azure Arc | Microsoft Learn "Customers need to explicitly attest for their Azure Arc-enabled servers or enroll in Windows Server pay-as-you-go to be exempt from billing for these services. Eligibility isn't inferred directly from the enablement to Azure Arc. Eligibility is not inferred from licensing status for the Azure Arc-enabled SQL Server instances that may be connected to an Azure Arc-enabled." Policy Purpose and Logic The policy ensures Arc-enabled Windows Servers are licensed correctly. It evaluates machines based on OS type, license status, and conditions for Software Assurance or Pay-As-You-Go. If compliance is missing, a remediation policy deploys the appropriate license profile. Key Conditions Applies to resources of type Microsoft.HybridCompute/machines with osType = windows. Checks if licenseProfile.licenseStatus equals Licensed. Uses existenceCondition to determine if the machine should have SA or PAYG licensing based on osSku and licenseChannel. Deployment Details The policy uses DeployIfNotExists effect. It deploys licenseProfiles under the Arc machine resource. Two scenarios are handled: Pay-As-You-Go: If licenseChannel contains 'PGS', productProfile.subscriptionStatus is set to Enabled. Software Assurance: If licenseChannel does not contain 'PGS', softwareAssuranceCustomer is set to true. The Policy The policy is located in GitHub (Link) and AzPolicyAdvertiser (Link). Download the policy files to be used in the following steps. Policy Description For 2025 server, if license type is Pay-as-you-go, then this will check the Pay-as-you-go box in license menu. If 2025 and not Pay-as-you-go license or not 2025 server then check Software Assurance box. This policy only checks Windows Server resources and will NOT check unlicensed servers How to Deploy the Policy After downloading the policy file, use Az PowerShell to create and assign the policy: #Create policy definition New-AzPolicyDefinition ` -Name "activate-azure-benefits-for-windows-arc-machines" ` -DisplayName "Activate Azure Benefits for Windows Arc Machines" ` -Policy 'azurepolicy.json' ` -ManagementGroupName "<MyManagementGroup>" ` -Mode Indexed #Assign policy definition $Policy = Get-AzPolicyDefinition -Name 'activate-azure-benefits-for-windows-arc-machines' -ManagementGroupName "<ScopeOfDefinitionCreation>" New-AzPolicyAssignment ` -Name "activate-arc-benefits" ` -DisplayName "Activate Azure Benefits for Windows Arc Machines" ` -PolicyDefinition $Policy ` -Scope "/providers/Microsoft.Management/managementGroups/<MyManagementGroup>" ` -Location 'eastus' ` -IdentityType 'SystemAssigned' # Optional use subscriptions instead of management groups. # or "/subscriptions/<SubscriptionId>" You can also copy and paste the contents of the policy into the portal or use a policy-as-code solution of your choice. Compliance The compliance blade of the Azure Policy will show the machines that do not abide by the policy definition. In this example many of the machines are not enabled for the Windows Server Benefits. The next step will be to use remediation tasks to enable these machines. On the Policy Remediation blade, you can initiate a remediation task to add the machines to enable the Azure Arc Benefits. Choose between the two radio button options for remediating all the selected locations, a single location, or select specific resources to remediate. When the Remediate button is pressed, a task is summitted and a notification will be displaced when the task is completed. The process may take some time and a status of In Progress will be displayed until the status changes to Complete. After this is completed go back and look at the Azure Arc Benefits – Windows Server Blade and you will see the machines activated. Note on Pay-as-you-go enablement When a Windows machine is deployed using Pay-as-you-go, as an example a new Windows Server 2025 machine, the status of the license after creation will be “Unlicensed” as shown below. The policy is not evaluating Unlicensed machines. The machine will need to have the Pay-as-you-go with Azure check box checked at least one time to “License” the machine. After the machine is Licensed the License details will show: Now if the machine would have the benefits removed in the future by unchecking the box, the machine will be audited with the policy. As an example, the Arc machine would show that the License type is Pay-as-you-go, Licensed, Disabled (for the Azure Benefits). Summary This policy automates Windows Server licensing for Arc-enabled machines. It ensures compliance by deploying license profiles for Software Assurance or Pay-As-You-Go scenarios. Deploying this policy reduces manual effort and enforces consistent licensing across your hybrid environment.Configuring WAC on standalone management desktop
I'm trying to configure WAC on a standalone notebook to be used as management station for different customer installation. After installing WAC on the notebook I've followed, I think, all the required steps to configure the connection between my computer to one customer's node. I've configured Winrm on my computer and on the customer node. I've generated a self-signed cert on the node with the CN set as the FQDN used to connect from the WAC. I've imported the cert on the trusted root cert on the WAC computer. I've checked the connectivity with the Test-WsMan from the wac to the server and it works. However from the WAC console the connection to the node fails with the "ssl connection " error. Has anyone been able to configure it in such way ? thanks86Views0likes1CommentHybrid joined devices - convert to entra Joined
how to convert/migrate +5.000 devices/laptops from Hybrid joined devices to Entra joined Only devices (the users are not in scope) - so this is all about the devices and to get this working within a existing infrastructure. Or can someone confirm there's no conversion path for hybrid joined devices to Entra join only?619Views1like1CommentBLOG: Determine and modernize Filesystem Deduplication
Version history - 1.6 Added references / links - 1.5 Added insights from Steven Ekren. Many thanks! / Added ReFS Docs link and added clarification about drawbacks. - 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. Edit: Steven Ekren, a former Senior Product Manager for Hyper-V shared valuable insights on how both engines operate in a comment on LinkedIn: [...] the basic conceptual difference between WS Deduplication and ReFS deduplication is that the Windows Server [dedup] version takes the duplicate file data and moves it to a repository and puts a reparse point in the file system from each point that references the data. This involves data movement and therefore not recommended for workloads that are changing it's data often, but best for more static data like documents and picture/videos. ReFS is a file system that uses links natively for all the objects so leaving the data in place and managing the links is much more efficient and doesn't involve the data copy and managing a repository. Effectively it's built into the file system. As the blog notes, there are some situations not recommended for this version of dedupe, but generally it's lower performance and storage I/O impact. 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, such as user profiles, folder redirection of AppData folders, 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 disks from dedup or keep them on NTFS. Note: Restrictions on high churn rate, like lockups or high RAM consumption, deadlocks / BSOD might have been addressed in Windows Server 2025 and the ReFS Dedup, see comment of Steven Ekren. 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. A GUI and job based alternative to this is the File Server Migration Feature (uses robocopy) in Windows Admin Center. 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 GS RichCopy Enterprise by GuruSquad for higher speed (up to 40%) and reliability, compared to robocopy. 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 ReFS Dedup with 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 with ReFS Dedup + Compression. Plan your dedup jobs: Ensure of making use of the 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. Related blogposts: https://splitbrain.com/windows-data-deduplication-vs-refs-deduplication/ , Thanks Darryl van der Peijl and team. https://www.veeam.com/kb2023 Veeam best practices about Windows Deduplication and ReFS Deduplication.548Views2likes1CommentA CISO's Guide to Securing AI - Securing AI for Federal, DIB, and DoW Entities
Artificial Intelligence (AI) is rapidly reshaping federal missions, defense operations, and critical infrastructure. From intelligence analysis to logistics and cyber defense, AI’s transformative power is undeniable. Yet, with great power comes great responsibility and risk.975Views0likes0CommentsWSUS changing Update Source on its own
We have 2 WSUS Servers and ConfigMgr. A week ago, one of the WSUS servers began changing the Update Source on its own, no changes had been made. It began pointing to the ConfigMgr and when changed back to use MS Update, shortly after checking again it reverted back to use ConfigMgr. Checked all Events, checked the SQL SUSDB for the WSUS server however there was no information related to this action. Any ideas where I can look next ? Thank you76Views0likes0Comments