When organizations migrate their Exchange infrastructure from Windows Server 2012 R2 + Exchange 2016 to newer platforms like Windows Server 2019/2022, they sometimes notice unexpected behavior when running PowerShell storage-related commands.

One commonly reported case:

Running Get-Volume on a DAG member suddenly shows volumes from another DAG node — even though those disks are not physically attached to this server.

If you came from 2012 R2, this looks strange (and even alarming). Let’s break down why this happens, what changed, and why it matters.

✅ Observed Behavior

• On Windows Server 2012 R2, Get-Volume lists only local volumes on the node.
• On Windows Server 2016 and later, the same command may display:
  • Local disks of the current server.
  • Volumes belonging to another node in the Database Availability Group (DAG).

Example:

On 2019/2022 servers in a DAG, you might see duplicated labels or unexpected entries for disks that should exist only on another Exchange node.

✅ What Changed in Newer Windows Versions?

Starting with Windows Server 2016, Microsoft introduced Cluster-aware behavior in the Storage PowerShell module.

The note in the official documentation confirms this:

When used in Failover Cluster, cmdlets from the Storage module operate on cluster level (all servers in the cluster).
📎 Docs – Get-Volume

This means:

• If a node is part of a Failover Cluster (which is true for DAG members), Get-Volume and similar cmdlets:
  • Query cluster-wide storage metadata.
  • Show volumes known to the cluster, even if they are not mounted on the current node.

Why didn’t this happen on Windows Server 2012 R2?

• In 2012 R2, Get-Volume worked only in the local context.
• Cluster awareness for storage cmdlets was introduced in 2016 and carried forward.

✅ Why It Matters for Exchange DAG

Unlike SQL FCI, Exchange DAG does not use shared disks.
Each node has its own local storage for database copies. However:

• DAG is built on Failover Clustering.
• Because of that, the Storage module sees the cluster membership and assumes cluster-level storage management.

This can lead to confusion when:

• Checking free space (HealthCheck scripts).
• Automating storage tasks.
• Troubleshooting performance or migrations.

⚠ Potential Risks

While reading volume info is harmless, problems start if you assume all volumes are local:

• Accidental destructive operations
  Running Clear-Disk, Initialize-Disk, or Format-Volume without filtering can impact another node’s disk.
• Incorrect automation logic
  Scripts written for 2012 R2 that assume “Get-Volume = local disks only” may produce wrong results in 2016+.
• False monitoring alerts
  Free space calculations might include non-local disks, triggering false warnings or hiding real issues.

✅ How to Safely List Only Local Volumes

Get-Volume alone is not enough in cluster-aware environments. Use one of these approaches:

1. WMI/CIM-based filter

• Filters volumes physically present on the current node.
• DriveType -eq 3 = fixed disks.

2. Cross-check with Get-Disk

• Maps volumes to locally available disks.
• Excludes disks that belong only to another node.

✅ Summary Table: Behavior Change

Feature	Windows Server 2012 R2	Windows Server 2016+
Get-Volume scope	Local only	Cluster-aware
Cluster integration	None	Enabled
Risk for automation	Low	High if no filtering

✅ Key Recommendations

• Review all storage-related scripts before migration.
• Filter for local context explicitly in automated checks and maintenance scripts.
• Never run disk operations without confirming local ownership.

📌 Final Thoughts

This is not a bug — it’s by design to simplify cluster management.
However, for Exchange DAG admins migrating from 2012 R2, this can be a surprise with serious implications for automation and operational safety.

The end.