There's a lot of documentation out there on how to mount ISOs in Microsoft System Center Virtual Machine Manager for Hyper-V hosts. It basically involves setting up permissions on the library shares so that the Hyper-V host machines can consume the share, then setting up constrained delegation in Active Directory. Here's a link: http://blogs.technet.com/b/dutchpts/archive/2009/02/09/hyper-v-and-scvmm-2008-mounting-iso-s-from-a-network-share.aspx?wa=wsignin1.0
And here's the error…
Error (12700)
VMM cannot complete the Hyper-V operation on the HVSERVER1.domain.com server because of the error: 'NewServerHost' failed to add device 'Microsoft Virtual CD/DVD Disk'. (Virtual machine ID 119730D6-8939-4CB9-8456-7941F6925279)
'XSIntWeb1-V': The Machine Account 'XSINC\HVSERVER1$' does not have read access to file share '\\HVSERVER1.domain.com\ISOs\en_windows_server_2008_r2_standard_enterprise_datacenter_web_x64_dvd_x15-50365.iso'. Please add this computer account to the security group of file share. Error: 'General access denied error' (0x80070005). (Virtual machine ID 119230D6-7929-4EB9-9456-6946F6925279)
(Unknown error (0x8001))
Recommended Action
Resolve the issue in Hyper-V and then try the operation again.
If you follow those steps exactly and still have issues, then there might be one more gotcha. Are you trying to connect to a VMM library that is hosted on the same server as both the VMM server and the Hyper-V host's parent partition? (Yes, this is a supported configuration.)
If so, you need to add the NT AUTHORITY\Network Service user account to the share and NTFS permissions. The reason is that the CIFS (SMB) file share is local to the computer needing access. As such, instead of the user appearing as the Hyper-V parent server machine name (such as HVSERVER1$), it will appear as the local account that the Hyper-V server is running as, which is typically the built-in Network Service account.
What makes this a 'gotcha' is that the error message explicitly states the machine account as the culprit. I only figured this out through the power of Process Monitor by SysInternals, which clearly showed the ACCESS DENIED is occurring when Network Service hits the share.
