Diagnose “disk is offline because of policy”

Identify the disk without writing to it

Treat the policy as a storage-ownership control before treating it as an inconvenience. For a newly attached disk owned by one machine, a targeted, supported remediation is preferable to changing how every future disk is handled. On shared SAN or clustered storage, the cluster or storage management path takes precedence because local visibility does not establish the right to write.

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
exit

Resolve 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.

What the three policy names tell you

Microsoft documents three SAN policy choices: OnlineAll, OfflineAll and OfflineShared. They describe treatment of newly discovered disks, not three repair levels. OnlineAll is not inherently a more correct state, and a disk staying offline can be the intended protection against an unintended writer.

The decisive evidence is the exact policy, disk identity and ownership topology. Capacity and disk number help identify the device but do not prove ownership. This problem does not benefit from a speed score or a claimed repair success percentage; the recommendation changes with the cause, especially policy versus a cloned identifier or storage-path failure.