If the hardware provider veto's the resync operation you may end up with the target LUN offline. If the operation is to resync to a target LUN that is not the same as the original source LUN the target may end up offline after the veto. The veto here is the correct option for the provider as it should fail to overwrite this volume. From Himanshu's blog: LUN-RESYNC WITH DISKSHADOW AND VIRTUAL STORAGE
NOVOLCHECK: This diskshadow flag corresponds to VSS_RECOVERY_NO_VOLUME_CHECK of VSS_RECOVERY_OPTIONS during RecoverSet and helps protect one or more unselected volumes on the target LUN from being silently overwritten during a resync operation. Specifying this option would indicate that the operation need not do the above check and it is OK to overwrite all the drives on the target LUN. A VSS resync operation as in the above scenario will fail in absence of this flag.
The LUNs are left in this state due to VSS not checking their state after the Hardware Provider Veto.
The are a couple of ways to work around this issue:
1) Use Diskpart to online the volume if it has more than one LUN backing it or if it is just one LUN online the LUN
2) Use VDS to perform the above actions using:
To identify this issue in a VSS trace, look for error VSS_E_PROVIDER_VETO (0x80042306) during CVssHardwareProviderWrapper::RecoverSet:
Windows Server 2008 Datacenter, Windows Server 2008 Datacenter without Hyper-V, Windows Server 2008 Enterprise, Windows Server 2008 Enterprise without Hyper-V, Windows Server 2008 for Itanium-Based Systems, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Datacenter without Hyper-V, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Enterprise without Hyper-V, Windows Server 2008 R2 for Itanium-Based Systems, Windows Server 2008 R2 Standard, Windows Server 2008 R2 Standard without Hyper-V, Windows Server 2008 Standard, Windows Server 2008 Standard without Hyper-V