HyperVPVSFix service – to use Citrix Provisioning on Hyper-V with synthetic NIC

When running Citrix Provisioning devices on Hyper-V, you are limited to use Legacy 100Mbit NIC adapter at boot, even when booting from an ISO file. To be successful with the 10Gbit syntechic NIC adapter, you need to boot first on a legacy NIC and then switch to synthetic NIC after Windows is loaded. There are some scripts out there to do this, however I wanted to keep this very process very simple and robust. So I did the job Citrix should have done. Created a small service that will check for PVS standard mode, then disable IP on legacy NIC when synthetic NIC is connected. In private mode, the service will not touch the NIC’s at all. The service is packaged as a simple MSI file, just run it, and you’re done.

The service will start immediately after setup completes.

Eventlog will show what the service is doing.

In private mode nothing happens. IPv4 is still enabled on the legacy adapter.

Reboot to standard mode and watch the magic happens

Now IPv4 is disabled on the legacy adapter.

The service will try for 10 minutes to look for a synthetic adapter before disconnecting the legacy adapter. If not found, the legacy adapter will be used.

The MSI package installs 3 files, the service, the nvspbind tool from Microsoft that actually does the IPv4 bind/unbind, and a command line version of the fix, if you want to run this in a script or manually during debugging.

You need dotnet 3.5 to use this service.

You may download and use this tool for free, but please remember that the use of this tool is completely on your own risk, and is not supported in any way. Always test in a proper test environment before you use it in production.

English version


German version


33 thoughts on “HyperVPVSFix service – to use Citrix Provisioning on Hyper-V with synthetic NIC

  1. Hi Maganar,
    Great write up. In case you didn’t know this issue with switching legacy traffic from legacy to synthetic was addressed by the provisioning services team in the Excalibur release. I showed this demo last year at Synergy which demonstrated the switch from legacy to synthetic post pxe. It is does this automatically with no msi installers needed. Please download the project Excalibur code and try this function as its enabled by default in the pvs client. If you have any questions please send me a tweet @tonysanchez_ctx

  2. Hi Maganar,

    I’m testing out your fix in a test environment, I found that it definitely is able to switch the traffic over to the synthetic NIC from the emulated one.

    I am having an issue however, that when I RDP (or people use ICA) to connect to the server, it drops a significant number of pings. This seems to be the worst during session creation and eventually gets better. (rdp times out once or twice while connecting and ica connections take longer than usual to start)

    Are you using this fix in production?
    Do you notice similar issues?


    • I haven’t seen this. Have you checked that the ip of the syntechic NIC is not registred in DNS? Also there could be additional NIC tuning that needs to be done, like disabling TCP offload. I’ve not yet looked at this with hyper-v.

      • I’m using the 2 nic scenario, both register in DNS. Using them for streaming and prod traffic (because they are 10gig and not really segregated currently)I’m using mac spoofing and have given them the same MAC/same IP (DHCP reservation)

        should I change to try using a 3 nic scenario?

    • I’ve seen this, I think it’s because you are using a different mac address when shutting down the device, and the device will not be marked as down in PVS. I will look into this. Maybe MAC spoofing could solve this.

  3. Hi,

    I have installed a script in windows 8 with Hyper-v3. I get the message Syntectic adapter not found. I use XenDesktop 7 and PVS 7.

    Do you have any idea ?

    • It should work with Windows 8, but please check the name of the adapter, i’ll check the code next week. I’m not sure if the fix is still nescessary with pvs7, will check next week.

    • I’m detecting
      “Microsoft Virtual Machine Bus Network Adapter”
      “Microsoft Hyper-V Network Adapter” as synthetic and “Intel 21140-Based PCI Fast Ethernet Adapter (Emulated)” as legacy.

  4. Do i still need this fix(service) with PVS 7.0, which is now available? Some said, that you don’t need this fix in 6.2 beta code, but is this issue addressed in 7.0 as well? I can’t find anything in the release notes. thanks.

    • Seems like PVS7 is switching the PVS traffic, however the legacy nic is still IP enabled so if you have both NIC’s in same LAN you will have problems. I’m working on an updated version of the fix.

  5. Hi Magnar, thanks for Feedback.
    The name of the legacy adapter is:
    “Intel 21140-basierter PCI Fast-Ethernet-Adapter (emuliert)”
    and the Hyper-V Adapter:
    “Microsoft Hyper-V-Netzwerkadapter”


  6. Pingback: Experience with Hyper-V and PVS 7 | Virtual eXperience

  7. Pingback: Experience with Hyper-V and PVS 7 | Conde Malagueta

  8. hey Magnar, first of all I wanna say this is brilliant ! Absolutely brilliant. When I read about your idea I was thrilled. I am tryign to run it in an environment where Citrix doesn’t do this yet and because my adapter is named slightly different it says “syntectic adapter not found”. Would you perhaps consider to update this tool with a possibility to manually (registry, ini file…) specify the name strings to look for upon service restart ? Really would love that

    • I’ve made an updated version where you may set the name of the adapters here. C:Program Files (x86)HyperVPVSfixHyperVPVSfix.exe.config. Just change the name in this section:

      Microsoft Hyper-V Network Adapter

      Intel 21140-Based PCI Fast Ethernet Adapter (Emulated)

      You need to download the updated version of the fix from here: https://dl.dropboxusercontent.com/u/1266927/HyperVPVSFix/HyperVPVSfix2.zip

      Note that I’ve not tested this version in production, please test it in test environment first.

      • I just tried this version out. Now after editing the config file and restarting the service it correctly says the exact new name in the eventvwr but still says: “synthetic adapter not found” and decides to take no action. I compared the device names and they are an exact match: “Microsoft Hyper-V Network Adapter #69”. Thx for trying though

  9. Hi Magnar,
    I have a problem with our german umlauts. Will it be possible to get sources to fix it by myself or it would be gread if you look into it?

Leave a Reply

Your email address will not be published. Required fields are marked *