After the "legacy network adapter" is gone in newer Hyper-V implementations, you are stuck with the normal network adapter emulation.
And that does not work for network installations, because it has a serious bug in the tftp boot client that is buildin.
On boot time, the DCHP part works ok, but when it comes to TFTP the client "hangs" and finally times out.
Doing some reseaches with a LAN analyser you can see, that all packets send from the server are fragmented and the client is unable to reassemble them. So no data packet is ever successfully transmitted.
This fault origins in the wrong blocksize (1482) the microsoft driver annouces to the remote tftp server during first chat. 1482 is wrong for ethernet because it iss 1428 (Ethernet MTU, less the TFTP, UDP and IP header lengths) according to RFC 2348.
I assume this is a simple typo hacked into the sources, somebody just flipped the last 2 digits.
You dont notice the problem with many TFTP servers, because the server can alter the requested packet size and lower it to a sane value. But there are some servers (for instance "SERVA") on the market that just obey the wishes of the clients.
It would be wise to fix both sides, make the client ask for a correct size and make SERVA check the size and lower it when needed.
Play it safe...