Not require name in Windows Azure Pack or App Controller for self-service RRS feed

  • Question

  • Looking to implement a self-service portal that allows people to request 90 eval boxes. The server name is auto-generated if it belongs in this architecture.   When using VMM directly, we can create machines from a template and the name of the server is correctly added to AD, displays the server name when viewing the properties of the VM. 

    The problem comes up when we use either app controller or windows azure pack, a 'friendly name' is required so when the VM is created, the server name follows the naming convention, but the friendly name the person typed in is displayed in the VM console.  We want to NOT require or even ask a 'friendly' name.   The template we are using has the naming convention we want to use for machine names. 

    Anyone know of a workaround for this?   Besides this one limitation, we can get self-service portal working.  We are evaluating this with vCAC from VMware for self-service portal. 

    Tuesday, February 11, 2014 5:58 PM

All replies

  • This is an interesting request, as the things you are mentioning are by design.

    Let put it into context to explain the design a bit: A VM name (shown in VMM) is not equal to the %computername% within the guest. This is because you can have one policy for names of AD accounts, while you wan't to give the VM a different name in VMM for the VMM administrators (like SQL server, Exchange server etc).

    Based on how you create virtual machines directly in the VMM console (btw, the vmm console can also be used for self-service users) can inherit the computername from the VM name field. 

    Also, note that Windows Azure Pack is designed to deliver IaaS in a multi-tenant environment, where people have their own network infrastructure, own Active Directory and so on. If it was solely designed for use inhouse, the story might be a bit different. 

    Since the VM Name is a "configurable setting" in the portal, this means the tenant should be able to assign their names as they want. If you don't like this at all, you can create your own resource definitions (which cointains the view definition, presented to the tenants in the portal) that is not asking for - nor exposing the VM name/friendly name. This is when using WAP.

    In App Controller, you don't have too much flexibility on how to present things, as this portal and its content is not so friendly for customization (silverlight).

    So to summarize: All the above is by design, so that the tenants can have their references when working in the tenant portal. Everything is fully documented and the API's are available as well, so the option to create/change thing is there, but it requires some investments. 


    Kristian (Virtualization and some coffee: )

    Tuesday, February 11, 2014 8:03 PM
  • Hi Kristian,

    Your response explains the feature.  I'll politely agree that the intention would be for an external hoster (service provider) to offer this to multiple customers.  I'm speaking from the enterprise perspective where we have control over things like naming conventions although wanting to offer cloud / self-service offers like this.  I've worked both in the enterprise space as well as external hosting provider, I understand the differences and this particular item is perfect for external hosters, the enterprise is different.  I like having the ability to have cloud based options 'on-prem' (I think that is the right buzz phrase), we'll probably have to shim something to meet our requirements. 


    Steve - IIS MVP

    • Proposed as answer by Friday, February 14, 2014 8:01 PM
    Wednesday, February 12, 2014 3:21 AM
  • In a nutshell, Windows Azure Pack (and also part of the App Controller) is solely designed to deliver IaaS (and some PaaS).

    If you look at the IaaS stack, then the cloud or it organization is meant to take care of all the fabric related content including the hypervisor (networking, compute, storage, virtualization abstraction).

    This means that you are providing the tenants with IaaS which also gives them complete control of the guest OS (name, operating system, networking stack etc).

    More details about the background can be found in this blog post:

    Another option for the private cloud which is on-premise, is to use Service Manager with Service Requests offerings. Then you can present what you want and have more control (ITIL) around the entire process.


    Kristian (Virtualization and some coffee: )

    Wednesday, February 12, 2014 7:13 AM
  • Adding service manager on-top of this seems like overkill.  Adding infrastructure like a service manager, assuming the company already has a product to do this, is one option.  I know trying to retrofit an external offering to the enterprise is tricky.   Might be a feature request to the team explaining the use case.  I know new features like this if suggested by the community might get some traction if others see value in it.   
    Friday, February 14, 2014 8:36 PM
  • Thx for the feedback Steve, and I will pass it along. 

    The version of WAP we are seeing now, is meant to provide us with a subset of the same capabilities that we have in Windows Azure, through a common service management API. All of this is extensible and we are most likely to see this solution moving forward.

    I have also worked with other organizations (not only service providers) who requires options like you describes here, and we often ends up by using SMA (Service Management Automation) to bridge the solutions into an enterprise scenario, based on the actions happening in WAP.


    Kristian (Virtualization and some coffee: )

    Saturday, February 15, 2014 5:26 PM