Server 2008 R2 freezes while copying data from network

I figured out a workaround last night. I discovered it had something to do with my original MAK key and its reuse.

The original VM was a Server 2008 R2 VM with an MSDN MAK Key (which is valid for standard and enterprise edition)

I did the DISM upgrade using the "489J6-VHDMP-X63PK-3K798-CPX3Y" KMS key for enterprise (from this post) http://social.technet.microsoft.com/Forums/en-US/winservergen/thread/0c68ffd9-ed83-4437-aa79-2f7decc75c0f.

After the DISM upgrade I switched back to my original MAK key (and activated successfully). A secondary behavior of this was that Remote Desktop was no longer functional on any machine that used the MAK Key. I then did some additional research and found that other people had experienced the same problem using the DISM upgrade ( http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/6debc586-0977-4731-b418-ca1edb34fe8b ). On a hunch I switched back to the KMS key and was then able to install SP1 (and remote desktop was reenabled). I then tried a Std/Enterprise license from a different MSDN account and it activated successfully, as well as kept Remote Desktop enabled. I also tested switching back to my original MAK key and this worked as well. I then just switched the rest of my VM's to the new MSDN key and this was successful as well, without re-introducing the KMS key.

Best I can tell, there must be something unique to using the same key at each end of the standard -> enterprise DISM upgrade path.

We used to have a problem like this where I'm at. I don't remember the exact details, but the final solution had to do with a conflicting mac address assigned dynamically to a virtual network adapter. Pinning those down so they weren't dynamic helped a lot. You normally don't want to do that because it can make it harder to move a virtual machine to a different host, but it helped us in this instance.

The other part is the physical nics were made by broadcom and we also had a configuration error there, where a previous admin had tried incorrectly to use the broadcom utility to trunk the two nics together on the host for improved bandwidth/throughput. We removed that setup and configured one of the nics so it had no IP at all on the host machine, but could still be used for passthrough to virtual guests. Then we set each virtual machine to only use one nic or the other, balancing the load based on historical traffic. Of course that means no failover if an adapter or connection goes down, and we haven't followed through well to see whether traffic has remained balanced over time, but it's been rock solid stable since then.