My Old IIS.NET BlogTechNet Magazine Articles Learn about IIS7 from a book I wrote a few years back!
Blogs I Read
For many environments, the Virtual Machine Manager 2008 R2’s self-service portal is very useful. It provides day-to-day users of your virtualization farm the ability to access their virtual machines and do key actions like start, stop, create checkpoint, and many other tasks. They can do this only when presented the appropriate rights (via user role, ironically, called Self-Service User).
So you’ve decided to dive in feet first and build out your infrastructure and give your end-users the ability to create new Virtual Machines. You’ve done your homework and determined that in order to create virtual machines the end-user must be a member of a role that has access to a virtual machine template. A template, which comprises together a hardware profile & os configuration profile, makes up the virtual “hardware” and Windows configuration. You’ve done this…
We’ve all had that person, that teammate, who you’ve sent an email notification too that they are all set. You’ve created the template, added it to a role, and then added their user account to that role. In fact, you’ve even gone one step further and created the VM for them and assigned them as owner. You quickly received a message from the end-user saying “I can’t see the VM you created for me in the self-service portal…”
You’ve checked your dots and crosses (ya know, for your i’s and t’s) but it doesn’t matter. They still swear that when they access the portal they do not see this template you just created for them.
For a lot of environments, you might make use of a flat hierarchy for the Host Groups. However, as the years progress and your virtualization investment grows you will quickly learn that organizing is your friend. In VMM, this is done through the Host Groups view in the Virtual Machine Manager.
This will make it nice for you to manage your view of your empire, um, I mean virtualization hosts.
When you start breaking it out into folders, with hosts existing in various different folders, you’ve now created a security boundary by which you can easily provide rights too. For example, why do India-based employees need access to templates created for Redmond-based physical hosts. The same goes for Vice Versa.
When you are providing permissions for a “role” that is based on self-service rights, you need to pay close attention to the following:
In the above example, let’s walk through the experience that can break you…
For this, I’m going to walk you through the typical scenario that breaks your self-service experience until you correct it.
The above problem was created by my user account having complete self-service rights and full ownership of virtual machines but no rights to “Scope” that these templates were applicable too. This is by design.
As you can see above, I removed my self-service user role from having access to Redmond physical hosts. In order to correct this problem, I open the User role again and grant this role permissions -
If I now check the self-service portal again, I will now have a template that is shown because I have access to physical hosts that match the template:
You might be asking yourself, well, isn’t this obvious. Yes, it is now that we know it. It is just a little “gotcha” that got me recently where I knew for a fact that the user role was configured properly but the end-user could not see their machines. It was very frustrating. You now know the importance of “Scope” when you are creating your user roles. Keep ‘sain my friends…I sure didn’t!