So I was trying to use sharing of ISO files instead of copying when mounting on virtual machines. The really helpful dialog box in System Center Virtual Machine Manager (SCVMM) 2012 SP1 politely informs you that

OK, so what configuration?

I found these steps for VMM 2008: How to Enable Shared ISO Images for Hyper-V Virtual Machines in VMM

In short this is what you have to do:

• Use a domain account as the VMM service account
• Grant share and NTFS Read permissions to the VMM library shares that contain ISO files for both the VMM service account and the computer accounts of any Hyper-V hosts that need to access those ISO files
• Configure constrained delegation for each Hyper-V host to allow delegation of credentials to the VMM library servers
• Add the Hyper-V hosts to the Windows Autorization Access builtin group

If you use a group to grant access to you Hyper-V hosts to the library share, like I did you have to restart them to update their security tokens. Configuring constrained delegation also requires a restart.

But it wasn’t working! VMM just told med “Update failed” each time I tried to mount an ISO on a VM. This is the error I got:

Error (12700)
VMM cannot complete the host operation on the <Hyper-V host> server because of the error: ‘<VM>’ failed to add device ‘Virtual CD/DVD Disk’. (Virtual machine ID <GUID>)

‘<VM>’: User Account does not have sufficient privilege to open attachment ‘\<VMM Library server>MSSCVMMLibraryISOs<ISO file>’. Error: ‘General access denied error’ (0x80070005). (Virtual machine ID <GUID>)
Unknown error (0x8001)

Recommended Action
Resolve the host issue and then try the operation again.

The Internet didn’t know why it didn’t work either. I know because I asked it!

As far as I cloud see my permissions were correct so I had to figure out if there was another account involved. The best way I know to do that is by auditing object access. So first I enabled auditing of object access on my VMM Library server:

Next, to catch all security principals trying to access the files in the VMM Library, I added audit System Access Control List entries for both Authenticated Users and Everyone:

After setting this up I tried mounting the ISO again and then opened the Security Event Log. The first event of interest was a logon event (Event ID 4624):

The account listed here is the Run As account I use for Hyper-V host management. This was an Audit Success event since the account was allowed to log on to the VMM library server.

Next was an attempt to access a share (Event ID 5140):

Again it was the RunAs account this time trying to access the VMM Library share with read permissions (ReadData or ListDirectory). Again, this was an Audit Success event since this was just a request for access. This was followed by something called a detailed file share (Event ID 5145):

This was our first Audit Failure event. This event is the result of the File Share request in the previous event. As you can see it was not successful. For the user this will result in an access denied message; exactly what I was seeing in the VMM console.

So apparently the RunAs account is also involved in accessing the share. To test to see if this was the solution I added the RunAs account to the share and NTFS permissions with Read access. Immediately it was successful and the VM could access the ISO file directly from the VMM Library.

Happy that I made it work I was still interested in knowing why the RunAs account was used for this. The answer was to be found in the VMM Add Resource Wizard. This is the wizard used to add fabric resources to VMM, like Hyper-V hosts or clusters. On the Credentials page we see this:

So the RunAs account is stored and used to access the hosts discovered with the wizard. The universe was once again in balance.

We are all aware of the lag between the evolution of the Windows Server platform and the System Center suite. It always takes some time from when a new feature in Windows Server is released, before it is supported in the System Center products. Now, it seems, this applies to Windows Azure as well. Consider the following…

Recently I did a Windows Azure project for a customer which included the introduction of System Center App Controller 2012 SP1 in their environment. They were already using System Center Virtual Machine Manager 2012 SP1 to manage their Hyper-V hosts. We specifically wanted to use App Controller to be able to easily migrate VMs from on-premise Hyper-V into Windows Azure IaaS.

To add an Azure subscription to App Controller you need access to the subscription ID (obtained from the Azure portal e.g.) and a management certificate in PFX format, i.e. you need access to both the private and public keys of the certificate. This certificate needs to already be registered in the subscription. I my case adding the two subscriptions the customer used presented no problems. However, when I came back a few weeks later more instances had been created in the subscriptions and now we had the following error in App Controller under the Public Clouds heading:

* Service unavailable

The first I checked was the status of the App Controller Windows Azure Provider (cmazure) service. This Windows service is responsible for communicating with the Windows Azure platform through the REST API. On my server the service was not running. I started the service and refreshed App Controller, but got the same error. Checking the service status again I found that it had crashed!

The first remedy I tried was updating the App Controller installation with the System Center Service Pack 1 Update Rollup 2 (KB2802159). That did not prevent the cmazure service from crashing but now I had a new error in the App Controller console:

* Requested value ‘A6’ was not found.

A6 and A7 are the IDs of the new HighMemory SKUs introduced in Windows Azure back in April 2013. They are higher memory variants of the Large and Extra Large SKUs respectively. My next move was to check if App Controller knew about these newer SKUs. But first I had to determine if one of my subscriptions in Windows Azure were in fact using any A6 or A7 instances, and if so, remove that subscription. To do this I logged on to the portal, and it was indeed the case. One of the subscriptions had two A6 machines.

I deleted that subscription from App Controller so that I could test my theory that the reason for the error was that App Controller did not know about A6 and A7. Here is a screenshot of deploying a new VM to Azure from App Controller:

As you can see, the Instance size list does not contain the A6 and A7 SKUs. Mystery solved!

This case was very surprising to me in several respects. First, it seems strange that App Controller keeps its own definition files of what is available in Windows Azure (a platform that is updated every 4-6 weeks) instead for dynamically downloading that information on demand and caching it. Secondly it seems like bad code when the introduction of a new instance SKU actually crashes a Windows service. Surly that exception could easily be handled in the code.