PlateSpin target SAN OS boot fails a 79% with Brocade 825(ibm oem) HBAs Fix.

We have just been undertaking a set of P2P migrations using Platespin and this issue kicked us where it hurts for a number of days. Open-mouthed smile

Now before we start on explaining the workaround, I think that a little background information is needed.

The current project I am involved with has had a requirement to migrate machines from unknown legacy hardware (the source servers were stored in a dark DC that the customer was vacating from) to new physical hardware based on IBM3550’s,   with the added fun of those machines being SAN boot.

The initial PlateSpin P2V worked flawlessly, our pain only started when we attempted the V2P part of the migration.  We kept getting 7B PSOD errors, on every attempt, remember that a 7B error occurs when your configuration is missing a component that is required to boot your device. Examples of these components include the PCI bus and the IDE/SCSI controller or in our case the HBA driver.  Now we knew we had the correct Device Drivers to inject into that environment, as we had used the very same ones to build several other servers of the same hardware type. after quite a lot of head scratching we decided to check the PlateSpin Driver Manager and finally some sort of sense started to appear.


The diagram above shows the Brocade driver details, as you can see the PnpID is incorrect,  the second images shows what should actually be in that field. this view is from the platespin analyser


So what exactly did we do to get around this rather annoying state of affairs.  Well read on McDuff and you shall see.

Although this workaround is specifically targeted at people who are users of Platespin Migrate 9.0.2 who have encountered issues V2Ping Windows 2003 R2 with SAN booting OS using Brocade 825 IBM branded HBA adapters. It is my belief that the process can be used to aid is sorting out the vast majority of 7B errors.

The first symptom of the issue occurs when the Platespin target deployment has been kicked off and reaches 79% of image deployment, this is the point when the target server  will be preparing to reboot into newly created image OS and this is where you get your first 7B error.

Once the target server has rebooted ensure that the Platespin take control iso is still mounted.  To check and verify that there is a SAN boot issue let the target host boot. Once it reaches the Windows 2003 boot screen it will continue to boot and at some point the server will either BSOD with a 7b error or enter a continuous reboot cycle. If you encounter the latter issue where you do not see a BSOD and would like to see the actual error, just disable the auto reboot feature this and fix for this issue are described in the steps below.

1) Boot the machine with the PlateSpin TakeControl ISO.

2) – Once WindowsPE is booted and it asks for a URL you just have to enter a fake URL like ‘’ and fake credentials for the Portability Suite server.


3) Once network cards are detected enabled and select the NIC card and enter IP details once the server gets an IP address you can use ‘Ctrl’ + ‘C’ to abort the batch job.


4) Now that a network connection is available map a network drive from another server to target host. The other server will have the registry files needed in order to fix the target boot issue.

a. In the command prompt type in net use G: \\\D$ (this will be the ip address and drive letter of the other server where the required files will be stored) hit enter and this will be followed by username and password prompts. Once network drive is mapped ensure that you can view the files.


5) From within the same command prompt run REGEDIT and browse to the HKEY_LOCAL_MACHINE key. Right click on it and select ‘Load Hive…’ then open the System file from the native Windows installation location (this is the image that has been deployed to C:\ on SAN). By default, this installation is located at C:\Windows\System32\Config\System.


6) Enter an arbitrary name when you receive a prompt for a key name in the Load Hive window. In this example I have named it as “Platespin” This loads the original HKEY_LOCAL_MACHINE hive as a subkey of the current key.

At this point before the fix is implemented for those who want to see the BSOD error message drill into the registry sub key “Platespin” to the following key, for those who do not move onto step 7:


Change the value data in the AutoReboot value to 0 (zero), instead of 1

Reboot the target host let the OS boot up and the BSOD should appear.

7) Select the “Platespin” key and from the file menu and import the following registry key for the Brocade 825 HBA into the native windows hive. Copy the txt file shown below to the other server where the network drive has been mapped step 4, remember to rename the extension to .reg rather than .txt

8) Collapse the HKEY_LOCAL_MACHINE subkey and unload the hive, exit out of REGEDIT.


9) Back at the command prompt now copy the device driver files files, in our case they were bfad.sys and bfad_up.sys to the following native server boot OS location ( the files were stored on a the mapped network drive): note by default, this installation is located at C:\Windows\System32\drivers



10) Once the registry importation and relevant device driver files have been imported and copied reboot the target machine without the ISO this should now start the windows boot process and then should load up windows OS.

Now I will reiterate this, the fix has only been tested IBM 3550’s with Broadcom HBAs, but assuming that your target system has 7B BSOD error it is assumed that a above process can be used. All that you need to do is find out the troublesome driver from your target host and then take a copy of the driver and registry from a working system of the same type and using the method above inject the driver and registry keys into the target OS.

One thought on “PlateSpin target SAN OS boot fails a 79% with Brocade 825(ibm oem) HBAs Fix.”

Comments are closed.