I'm installing Windows Server on a Cisco UCS blade that boots from a Dell EMC XtremIO LUN over Fibre Channel. The blade has one virtual HBA, but the storage array exposes the LUN through two FC ports, so Windows Setup sees the same LUN twice. Installation completes if I select one instance, but after reboot Windows fails with status 0xc0000185 and reports that ntoskrnl.exe is missing or contains errors.
The usual approach is to present only one path during installation, enable Windows MPIO, and then restore the other paths. I don't have administrative access to the MDS switches or the storage array, so I can't zone or mask the extra path. I installed the Multipath-IO feature offline from WinPE with DISM, but the system still fails during boot. My assumption is that MPIO or MSDSM is not loading early enough, or that the XtremIO hardware ID has not been configured.
Is there a supported set of offline HKLM\SYSTEM registry changes that would make MPIO/MSDSM load early enough to claim the FC boot disk? If not, is cloning a disk from another server that already boots from SAN a practical workaround without changing the fabric configuration?
3 Answers
Seeing two entries in Windows Setup confirms that the OS is receiving two independent paths to the same LUN; it does not mean there are two different disks. The clean deployment sequence is to install with one path, boot successfully, install the appropriate MPIO and XtremIO DSM components, confirm that the boot disk is claimed correctly, and only then present the second path.
If you cannot change zoning, masking, or the UCS presentation, involve the UCS and storage vendors for a supported boot-from-SAN design. Manually editing Services, Start values, or MPIO registry keys offline can make a driver load earlier, but it cannot reliably create the required path-selection and boot-disk handling, and an incorrect change can make the installation unbootable.
There usually isn’t a dependable registry-only fix for this scenario. Windows boot-from-SAN must first reach the boot LUN through the firmware and the storage driver, before the normal MPIO stack is fully available. Installing the MPIO feature offline does not necessarily make an already-installed system boot safely when the same LUN appears through multiple paths.
The supported fix is to make only one path visible during installation and the first boot, then install and configure the vendor DSM or MSDSM with the correct XtremIO hardware identification before restoring the second path. If the extra path cannot be removed at the fabric or array level, the UCS boot policy and virtual HBA configuration need to restrict or prioritize the boot target in a way supported by the UCS and storage vendors.
The firmware boot order and the Windows multipath configuration are separate things. UCS can select which WWPN and LUN to boot from, but once Windows loads the fnic driver it may discover both FC paths. If Windows was installed while both paths were visible and no boot-capable multipath configuration was present, the boot manager can lose access to the disk and produce 0xc0000185.
Check whether the UCS service profile can expose only one virtual HBA fabric or one storage target during deployment, and verify the boot-from-SAN requirements for the exact UCS, fnic, Windows, and XtremIO versions. A BIOS or boot-policy change alone may not solve duplicate LUN discovery in the operating system.
Cloning another server is unlikely to help. The cloned system would still encounter the local server’s FC paths and would also risk carrying over storage identifiers, boot configuration, and hardware-specific driver settings.
The UCS boot policy already selects the intended target. The problem occurs after the fnic driver loads: Setup sees the same LUN through both array ports, even though the firmware stage initially sees only the selected boot target.