@PHITEK Thanks for your reply Phil, hopefully with help from you and @Gus_Issa I'll be able to get this working.
We have actually been using the WinUSB drivers with these devices from the start, but we have been installing on Windows 7 with a custom .INF. I hadn't looked into completely hands-free WCID based installation before, although apparently with the right USB descriptors on the device it has been working since Windows 8 right out of the box, and automatically with Windows 7 with a one-off download of the WinUSB drivers from Microsoft (That wouldn't have worked for our client as the process machines are not allowed internet access)
Anyway now we have been given a corporate "standard build" VM image to test on, these things are so locked down by Group Policy almost everything is going to fail somehow, and the first hurdle was the requirement for signed drivers. The WinUSB drivers themselves are signed, but the custom .INF means they won't be loaded, at least not without some trickery that I'd rather not require of the end users.
The best source of information I've come across on setting the device up so drivers auto-install can be found here: https://github.com/pbatard/libwdi/wiki/WCID-Devices
(The required descriptors actually appear in various forms in the USB config files in the GHI NETMF-Open-Firmware Git repo right from the start, in easy to read C.)
I worked through the process of building them in C# until they all appeared correct, using the the xusb tool from the examples in libusb (https://github.com/libusb/libusb.git) under Linux, to avoid the problem of polluting the Windows registry with bad versions. (Testing on Windows I updated the Product number for each build, and reverted to a saved VM snapshot every so often for a clean start)
[BTW xusb is a great tool, clearly coded and easy to modify. One minor fault in the current version is that it converts the Unicode string descriptors to Ascii to display them, which means the Vendor code at the end of the MSFT001 string may not be displayed correctly, but that is easy to fix and there is a pull-request waiting to do just that.]
I'm not sure what will happen when/if I manage to change to bcdUSB code to 0x0200, I was hoping it would be easy to do and everything would fall into place, but of course it may bring other problems that bring the USB stack down, Gus probably knows that better than anyone.
Not being an expert in C#, I thought for a start I could derive from the GHI USBClient to change the code, but as it uses a static class that didn't work. Then I tried extension methods, still no go. Then tried building the whole class from scratch using the JetBrains decompiled code and calls into the DLL, but that didn't seem to work properly either.
My thoughts were then "All I want to do is change one byte, it shouldn't be so hard, I don't know why anyone would use C# when C is so much better in every way, and why do they have to keep coming up with new languages every few months?", showing my age and ingrained bias from 35 years coding in C, and turned to this forum
I'll take another look at it tomorrow (and post anything useful I get from USBView), but if someone can see an obvious thing I'm missing (likely), or knows it can't be done at all with the 4.2 firmware I'm using (also likely), please let me know!