Windows Offline Disks After Migration
Windows Offline Disks After Migration
Problem Description
After migrating a Windows VM from VMware vCenter to PCD using vJailbreak, additional disks (beyond the primary C: drive) may not be visible inside the Windows operating system, even though they are successfully attached to the VM in PCD.
Symptoms
- The VM migrates successfully and shows as active in PCD
- PCD shows all volumes/disks are attached (e.g., 3 disks attached)
- Inside the Windows VM, only the primary C: drive is visible
- Additional drives (e.g., E:, F:, G:) that existed before migration are missing
- The disks exist but are in an “Offline” state in Windows Disk Management
Root Cause
This issue occurs due to Windows SAN Policy settings. When Windows detects disks on a SAN (Storage Area Network), it applies a policy that determines whether new disks are automatically brought online or kept offline.
After migration from VMware to PCD, the storage subsystem changes, and Windows may apply the “Offline Shared” SAN policy to the migrated disks. This policy keeps disks offline by default to prevent data corruption in shared storage scenarios.
The default SAN policies in Windows are:
- Offline Shared: Keeps all shared disks offline (common after migration)
- Offline All: Keeps all new disks offline
- Online All: Automatically brings all new disks online
Manual Workaround
Before migrating the VM, you can manually fix this issue by changing the SAN policy and bringing disks online.
Step 1: Check Current SAN Policy
Open Command Prompt as Administrator and run:
C:\> diskpartDISKPART> SANYou will likely see:
SAN Policy : Offline SharedStep 2: Change SAN Policy to Online All
DISKPART> SAN POLICY=OnlineAllStep 3: Verify the Change
DISKPART> SANYou should now see:
SAN Policy : Online AllStep 4: Bring Offline Disks Online
While still in diskpart:
DISKPART> list diskIdentify offline disks (marked with an asterisk *), then for each offline disk:
DISKPART> select disk <number>DISKPART> online diskStep 5: Exit and Verify
DISKPART> exitCheck File Explorer - your drives (E:, F:, G:, etc.) should now be visible.
Automated Solution
vJailbreak provides automated scripts to detect and fix this issue during first boot after migration.
Available Scripts
Two BAT scripts are available in the scripts/firstboot/windows/ directory. These scripts generate PowerShell scripts that run on first boot:
check-disks.bat- Generates a diagnostic PowerShell script that only checks disk statusdisk-online-fix.bat- Generates an automated fix PowerShell script that brings offline disks online
Usage: Copy the contents of either BAT file and paste it into the Post Migration Script field in the migration form. The script will execute automatically on first boot after migration.
Script 1: Check Disks (Diagnostic Only)
The check-disks.bat script generates check-disks.ps1 which performs a read-only analysis:
- Scans all physical disks
- Reports operational status (Online/Offline)
- Lists partitions and drive letter assignments
- Identifies disks without drive letters
- Checks for read-only disks and health issues
- Generates a detailed report at
C:\DiskStatus_Report.txt
Script 2: Disk Online Fix (Automated Repair)
The disk-online-fix.bat script generates and executes check-disks-fix.ps1 which automatically fixes offline disk issues:
- Performs all diagnostic checks from Script 1
- Automatically brings ALL offline disks online
- Logs all actions to
C:\DiskStatus_Report.txt
Note: The generated PowerShell script (check-disks-fix.ps1) is a separate file from the diagnostic-only check-disks.ps1. It includes all diagnostic functionality plus automated repair capabilities.
⚠️ Important Warnings
Blanket Online Policy
The automated fix script uses a blanket approach to bring ALL offline disks online without discrimination. This is necessary because:
- Pre-migration disk states (online/offline) are unknown
- The script cannot determine if a disk was intentionally kept offline before migration
- This is designed for automated firstboot scenarios after VM conversion
Risks and Considerations
-
Intentionally Offline Disks: If the source VM had disks that were intentionally kept offline (for backup, security, or operational reasons), the script will bring them online. This may not align with your original configuration.
-
Shared Storage: In environments with shared storage, bringing disks online indiscriminately could potentially cause issues if the same disk is accessed by multiple systems.
-
Testing Required: Always test this script in a non-production environment first to ensure it aligns with your migration policy.
-
No Drive Letter Assignment: The script does NOT automatically assign drive letters to partitions. If a partition lacks a drive letter, you must assign it manually using Disk Management or PowerShell cmdlets.
Recommendations
- Review the diagnostic output from
check-disks.batbefore running the automated fix - Document which disks should be online in your source environment
- Test the migration process with a non-critical VM first
- Review the log file at
C:\DiskStatus_Report.txtafter running the fix script - Manually verify that all expected drives are accessible after the fix
Prevention
To prevent this issue in future migrations, you can:
- Pre-configure SAN Policy: Before migration, set the SAN policy on the source VM to
OnlineAll - Post-migration Automation: Copy the contents of
disk-online-fix.batinto the Post Migration Script field in the migration form - Document Disk States: Maintain documentation of which disks should be online/offline for each VM