8 replies to this topic

[misty]

Installing Windows 7 to an iSCSI target - thanks to Erwan.l's instructions (here) this proved to be relatively easy once I'd set up the iSCSI target.

Cloning to iSCSI - more bloody frustration!!!! Lots of 0x7b errors

After a fair amount of googling and lots of tests I stumbled accross the following instructions - http://blog.zorinaq.com/?e=41
 

Disable the LightWeight Filter (LWF) driver for the NIC that will be used for iSCSI boot. As explained in KB976042 this driver cannot start at boot time and would prevent the NIC from being available during iSCSI boot. One way to unbind the LWF driver from the NIC is to use bindview.exe which has to be compiled from the Windows Developer Kit(!) If you are like me and prefer easier solutions, do this by editing the registry (thanks to Takahiro Wagatsuma for this information):

1.Open HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}

2.Find and open the subkey for the NIC (eg. 0007)

3.Open the subkey Linkage

4.Edit the value FilterList. Delete the line that refers to the LWF driver UUID {B70D6460-3635-4D42-B866-B8AB1A24454C}. In my case I had to delete the second line. Before:
{158B0494-2576-4DE5-9E32-98DB9E177DD8}-{B5F4D659-7DAA-4565-8E41-BE220ED60542}-0000
{158B0494-2576-4DE5-9E32-98DB9E177DD8}-{B70D6460-3635-4D42-B866-B8AB1A24454C}-0000

After:
{158B0494-2576-4DE5-9E32-98DB9E177DD8}-{B5F4D659-7DAA-4565-8E41-BE220ED60542}-0000

The entry for my NIC was also in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\007 registry key - on two systems - admittedly with similar hardware (a thinkpad X61 and T400).

Edited the key as described (in my cloned disk image - my iSCSI target) and PXE booted the client system.

Worked first time - when Windows finished booting I was prompted to reboot following the driver installation for the new (iSCSI) disk Windows was running on. Rebooted and received an 0x7b error again

Looks like this key is repopulated on every boot!!!!

Any ideas?

BTW, cloning my system is not that straightforward due to limited hard disk space so I did another test -

• booted to WinPE and imaged my local installation using wimlib-imagex
• applied the captured wim to my mounted iSCSI target (a 20gb sparse .vhd mounted as R:)
• mounted R:\windows\system32\config\system registry hive
• edited mounteddevices key and changed the drive letter(s)
• disabled the LightWeight Filter (LWF) driver as per the instructions above
• Deleted R:\boot to get rid of the old BCD store
• used the bcdboot command to create a new BCD store (bcdboot r:\windows /s r:

Rebooted the system and successfully sanbooted the disk image - as it wasn't a cloned image it contained a different disk signature - avoiding any conflict with the existing hard disk on the client system and avoiding the need to remove the disk from my laptop.

Diskpart output from Windows 7 running on the iSCSI target -

Microsoft DiskPart version 6.1.7601
Copyright (C) 1999-2008 Microsoft Corporation.
On computer: X61-PC

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online           55 GB      0 B
  Disk 1    Online           20 GB      0 B

DISKPART> sel disk 1

Disk 1 is now the selected disk.

DISKPART> detail disk

KernSafe iSCSI Adapter SCSI Disk Device
Disk ID: DA7D7987
Type   : iSCSI
Status : Online
Path   : 0
Target : 0
LUN ID : 0
Location Path : UNAVAILABLE
Current Read-only State : No
Read-only  : No
Boot Disk  : Yes
Pagefile Disk  : Yes
Hibernation File Disk  : No
Crashdump Disk  : No
Clustered Disk  : No

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 3     C   ISCSI        NTFS   Partition     19 GB  Healthy    System

DISKPART>

Still have the same bloody issue with the filter driver repopulating on every boot though.

Any thoughts?



Regards,

Misty

[misty]

Not in a position to test this for a couple of days however it looks like the answer to my question might be here - https://support.micr...en-gb/kb/976042.
 

To unbind the NDIS LWF Driver with Nvspbind, do the following:

1.Identify the GUID for the boot NIC by displaying the NIC information with the command: nvspbind –n
For example each NIC will appear similar to the following:
{091786BC-FC48-4CDB-B7C5-94994C83C8CF}
"vmbus\{f8615163-df3e-46c5-913f-f2d2f965ed0e}"
"Microsoft Virtual Machine Bus Network Adapter #2"
"iSCSI1":

2.Determine if NDIS LWF driver is enabled on the NIC with the command: nvspbind.exe {guid}
For example: nvspbind {091786BC-FC48-4CDB-B7C5-94994C83C8CF}

3.When enabled the NDIS LWF driver will appear as follows:
enabled: ms_wfplwf (WFP Lightweight Filter)

4.Disable the NDIS LWF driver with the command: nvspbind.exe /d {guid} ms_wfplwf
For Example: nvspbind /d {091786BC-FC48-4CDB-B7C5-94994C83C8CF} ms_wfplwf

5.Verify the NDIS LWF driver was disabled with the command: nvspbind.exe {guid}
For example: nvspbind {091786BC-FC48-4CDB-B7C5-94994C83C8CF}

6.When disabled the NDIS LWF driver will appear as follows:
disabled: ms_wfplwf (WFP Lightweight Filter)

nvspbind is available from https://gallery.tech...P-Bind-cf937850

Will check this out and report back over the weekend.



Misty

[Wonko the Sane]

 

Still have the same bloody issue with the filter driver repopulating on every boot though.

Any thoughts?
 

Not necessarily a good idea, mind you, but the usual approach with keys/hives/values that are recreated automatically is to remove Ownership/Authorization from them (for either System or TrustedInstaller or both).

The risk is that if the System cannot recreate or modify the key or value will freak out anyway and still crash. 

 

Unbinding the thingy sounds much more correct.

 

Wonko

[misty]

Forgot to report back - I tested using nvspbind (see post #2) sooner than expected due to a very late night last night - it worked
 

[erwan.l]

A bit of aging (sorry) but would you be able to describe the process with nvspbind ?

 

Also, do you run the image on the same hardware?

If so, I would have thought that all was needed was ensuring the services (iscsi and network) were set to auto start.

And possibly disable the firewall service?

[Wonko the Sane]

The actual MS KB (though it was intended for Server 2008 R2) and related to "hardware change" is strangely enough understandable:

https://support.micr...en-us/kb/976042

 

If Windows is installed directly on an iSCSI disk, Windows Setup makes sure that the LWF driver does not get installed on the network adapter used with iSCSI boot.

 

 

In practice they seemingly  wrapped a non-boot filter around a service/driver for a boot device and then made a workaround as an exception in Windows Setup.

 

Most probably this not only applies to a "cloned" Windows install, but also to a directly applied WIM like the fujianabc method (or WINNTSETUP) uses.

 

Besides Nvspbind there is also a Powershell way to enable/disable bindings:

http://www.windowsne...r-bindings.html

But most probably is only 8/8.1 and Server 2012:

https://technet.micr...v=wps.630).aspx

 

Should you want to add the feature to check/enable/disable the bindings to any of your tools, this might be of use, Windows 10 specific, but most probably largely compatible with previous versions, the "bindview" sample should be on earlier SDK/WDK):

https://github.com/M...-driver-samples

https://github.com/M...config/bindview

 

 

Wonko

[misty]

A bit of aging (sorry) but would you be able to describe the process with nvspbind ?

Also, do you run the image on the same hardware?
If so, I would have thought that all was needed was ensuring the services (iscsi and network) were set to auto start.
And possibly disable the firewall service?

The nvspbind process is covered in the KB article Wonko linked to, and also in the Windows 7 AoE Diskless without CCBoot topic on reboot.

This process is for use on the same hardware from a cloned system - setting iscsi and network to autostart without also changing the binding on the network adapter will result in the boot process stalling on the Windows splash screen. This occurs with or without the firewall service enabled.

 

In practice they seemingly wrapped a non-boot filter around a service/driver for a boot device and then made a workaround as an exception in Windows Setup.

Most probably this not only applies to a "cloned" Windows install, but also to a directly applied WIM like the fujianabc method (or WINNTSETUP) uses.

Sums it up nicely. This (wrapping the non-boot filter around the service required for the boot device) caused me a lot of wasted time and effort and much frustration

I suspect that trying to manually unbind the settings on a sysprepped image (including using WinNTSetup, the fujianabc method, manually applying install.wim using wimlib, etc) is a bit of a chicken and egg scenario - the network adapter/service is not configured until later in the setup process - the boot process stalls before this part of setup is reached (at least I suspect that's what was happening).

Regards,

Misty

[erwan.l]

I understand the issue now.

 

I cloned systems in the past onto iscsi but was using windows xp (which does not seem to have that issue with LWF.

I also installed windows 7 to iscsi and never had any issues but not realise that doing so, the windows setup is "smart" enough to not bind LWF against the booting nic.

 

Do I read correctly that the issue is the same while cloning to AOE?

 

Could it be that the ccboot does the same trick as for a time, it seemed to be the only solution to clone windows 7 an up to iscsi/aoe?

 

Downside with nvspbind is that it cannot be used offline.

 

Cheers,

Erwan

[misty]

Do I read correctly that the issue is the same while cloning to AOE?

Yes.
 

Downside with nvspbind is that it cannot be used offline.

True. Maybe a talented developer can come up with another option

There must be some way of doing this offline - Windows Setup appears to manage it. To be honest though it's probably not worth the effort (other than as a technical challenge) - I suspect the target audience is very limited!

Regards,

Misty