Working with Windows Server 2008 R2 as a Hyper-V guest connecting to Synology NAS via iSCSI, I encountered a peculiar issue where 2 out of 6 LUNs consistently failed to remount after system reboots. Despite identical CHAP authentication configurations across all targets, only specific volumes exhibited this behavior.

First, verify the iSCSI initiator configuration:

# PowerShell command to check persistent targets
Get-IscsiTarget | Where-Object {$_.IsConnected -eq $false} | 
Format-Table -Property NodeAddress, IsPersistent

Key observations from the event logs showed no authentication failures or timeout errors, suggesting the issue occurred during the automatic reconnect sequence.

Synology support recommended these configuration changes:

1. Disable CHAP authentication on problematic LUNs
2. Enable LUN masking (Target Filtering) on the NAS
3. Configure explicit node access control

Implementation example for LUN masking:

# Synology DSM API call example for LUN masking
POST /webapi/entry.cgi?api=SYNO.Core.ISCSI.LUN&method=edit&version=1
{
    "lun_id": "3",
    "initiator_list": ["iqn.1991-05.com.microsoft:hyperv-host"],
    "auth_type": "none"
}

For stubborn connections, modify the iSCSI service dependencies:

:: Batch script to adjust service startup order
sc config MSiSCSI start= auto
sc config mpio start= auto
sc config msdsm start= auto

Additionally, create a scheduled task to verify connections post-boot:

# PowerShell remediation script
Register-ScheduledTask -TaskName "iSCSI Recovery" -Trigger (New-ScheduledTaskTrigger -AtStartup) 
-Action (New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-Command "Get-IscsiTarget | 
Where-Object {!$_.IsConnected} | Connect-IscsiTarget -IsPersistent $true"")

The root cause appears to be a timing issue during Windows boot where:

• iSCSI service initializes before MPIO completes loading
• CHAP negotiation timeout occurs during this window
• Subsequent retries don't execute due to failed initial handshake

For critical environments, consider implementing a connection verification script like this:

function Test-iSCSIConnection {
    param($TargetIQN)
    
    $target = Get-IscsiTarget -NodeAddress $TargetIQN
    if (-not $target.IsConnected) {
        $target | Connect-IscsiTarget -IsPersistent $true
        Start-Sleep -Seconds 5
        if (-not $target.IsConnected) {
            Restart-Service MSiSCSI
            $target | Connect-IscsiTarget -IsPersistent $true
        }
    }
    return $target.IsConnected
}

When working with iSCSI targets in a Windows Server 2008 R2 environment virtualized under Hyper-V, you might encounter situations where certain LUNs fail to automatically reconnect after system reboots - despite identical configuration across all targets. In this case, 4 out of 6 iSCSI volumes from a Synology NAS mounted correctly, while 2 consistently required manual reconnection.

The affected systems exhibited these characteristics:

- All targets configured with CHAP authentication
- Targets appear in the iSCSI Initiator's Favorites list
- No relevant errors in Windows Event Logs
- Virtualized environment under Hyper-V
- Synology NAS as storage provider

The breakthrough came when examining the authentication handshake process. The Windows iSCSI Initiator and Synology target were experiencing negotiation issues during the CHAP authentication phase. This became evident when testing without CHAP:

# Sample PowerShell to modify iSCSI connection settings
Set-IscsiChapSecret -InitiatorInstanceName "iqn.1991-05.com.microsoft:hyperv-server" 
                    -Secret "alternative_password"

Synology's technical support recommended implementing LUN masking instead of relying solely on CHAP authentication. This approach filters which initiators can access specific LUNs at the target level.

Configuration steps on Synology DSM:

1. Navigate to SAN Manager > Target
2. Select the problematic iSCSI target
3. Enable LUN masking
4. Define permitted initiators by IQN
5. Apply changes

For environments where occasional manual intervention is acceptable, this script can automate reconnection:

# iSCSI Auto-Reconnect Script
$targets = @("iqn.2000-01.com.synology:target1", "iqn.2000-01.com.synology:target2")

foreach ($target in $targets) {
    $connection = Get-IscsiConnection | Where-Object {$_.TargetNodeAddress -eq $target}
    if (-not $connection) {
        Connect-IscsiTarget -NodeAddress $target -IsPersistent $true
        Start-Sleep -Seconds 5
        Get-Disk | Where-Object {$_.OperationalStatus -eq "Offline"} | 
                  Set-Disk -IsOffline $false
    }
}

For stubborn cases, modifying the Microsoft iSCSI Initiator service dependencies might help:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSiSCSI]
"DependOnService"=hex(7):52,00,70,00,63,00,53,00,73,00,00,00,00,00

Ensure these elements are properly configured:

1. CHAP credentials match on initiator and target
2. iSCSI service startup type set to Automatic (Delayed Start)
3. Network interfaces bound in iSCSI Initiator properties
4. MPIO policy configured if using multiple paths
5. No IP address changes between reboots