Windows Server 2016–2025 and Windows 11 storage inspection. Elevated access and storage-owner involvement may be required. No generic online or policy-changing command is prescribed.
Research-based; no hands-on test claim.Identify the disk without writing to it
Capture the exact Disk Management message and the time it appeared. Record the disk number alongside its unique identifier, capacity, bus type and presentation path. Disk numbers can change across boots or configuration changes, so a number alone is not a durable identity.
Determine whether this is a new local disk, a cloned virtual disk, a SAN LUN or cluster-managed storage. Check recent attachment, failover, cloning and recovery activity. If the volume is unexpectedly missing, preserve logs before attempting to initialise or format anything.
Inspect the current policy
In an elevated DiskPart session, san without a policy argument displays the current policy. Exit without issuing change commands. Microsoft documents that the policy affects whether newly discovered disks become online and writable. Read the result alongside the storage topology rather than treating it as an error in isolation.
An offline state may also have another cause, such as identifier collisions or storage availability. Confirm the specific event and vendor guidance. A policy report by itself does not prove that changing the global policy will solve the original problem.
diskpart
san
exitResolve ownership before any state change
For shared storage, involve the storage and cluster owner. Determine which node has the right to mount and write the filesystem and whether the cluster controls the resource. Do not bypass cluster ownership through a local disk tool.
Setting a blanket online-all policy where servers share disks can create simultaneous writers and corrupt data. A clone may also carry identifiers that conflict with an existing disk. Do not alter identifiers, clear read-only flags or bring disks online until you have a supported recovery procedure, a verified copy and a way to identify the correct device.
Validate the approved remediation
For an exclusively owned local disk, follow the documented procedure for the actual cause and record the previous state. For a cluster or SAN, use the platform’s supported management path. Schedule disruption if applications must release handles or storage presentation must change.
Afterwards verify the expected volumes, permissions and application data, and check that other nodes have retained their intended ownership. If a second host sees unexpected changes or errors recur, stop further writes and escalate. Reverting a policy does not undo writes already made to a shared filesystem.