Re-associate orphaned virtual machine with its VM role in System Center 2012 R2 with Update Rollup 7

If you have been using Azure Pack and the VM Cloud Provider, you have most likely been tempted to use the concept of VM Roles too.

VM Roles is a powerful technology that makes it possible for you to provide a lot more than just a sysprep’d operating system to your tenants. Through a resource extension, a VM Role can be deployed with any application you’d like, ready to go for the tenants.

However, there has been some challenges since the release of Azure Pack and VM Roles.

Some of the challenges has been related to Azure Pack directly, and some of the challenges has been related to Virtual Machine Manager.

I won’t cover everything here, but the following picture should summarize some of the challenges of a VM Role and a stand-alone VM, where some parts such as “static disk” wasn’t enabled for VM Roles before UR5. With UR6, we also got support for Gen2 VMs as part of the VM Roles.

Also note that “backup” and “DR” on VM Role is categorized as a “no go”.

Luckily and as usual, David and his great team at Microsoft has listened to our feedback – and with Update Rollup 7 for Virtual Machine Manager 2012 R2, we are now able to re-associate a VM Role!

Background:

A couple of months ago, I reached out to the VMM team through David Armour and explained a rather bad situation for him that one of my customer suddenly was in the middle of.

It turned out that several of my MVP friends also had experienced similar issues and this was becoming a critical issue for those customers. Here’s some details around the problem we saw:

In the case of some underlying storage issues in the cloud environment, many of the virtual machines that was running in VMM, SPF and Azure Pack ended up in a pretty bad state, and the only way to solve it was to generate new IDs for those VMs.

Now, this sounds very tempting and applicable in certain scenarios. But given the fact that the VMs actually were part of a VM Role in Azure Pack, turned out to be a bad experience.

Once a VM is no longer associated with the VM Role in WAP, it will appear as a stand-alone VM with no way for you to perform advanced operations through the tenant portal. The VM Role itself will appear as an orphaned object.

Our biggest challenge in this satiation was:

1)      There was no way to re-associate a VM instance with a VM role once this relationship was broken (so Remove-SCVirtualMachine with –Force parameter was not an option)

2)      If we could re-associate with a VM role (once the VM appeared in VMM again with new ID), the usage would be broken for that VM. Yes the customer was actually using the usage API in WAP to charge their tenants.

For this customer the issue was most likely caused by some underlying storage problems. However, you could easily end up in a similar situation by using native Microsoft technologies such as backup/restore and DR through Hyper-V Replica/ASR. Or simplier, by removing and adding a host/cluster to a VMM Cloud

With Update Rollup 7, we have finally support for re-associate both an orpahned VM from a VM Role and a Service Template deployment.

Example of a PowerShell cmdlet that will join an orphaned virtual machine to a VM Role:

$myvm = Get-SCVirtualMachine –Name “KN01”

$myVMRole = Get-CloudResource –Name “mywebservice”

Join-SCVirtualMachine –VM $myvm –VMRole $myVMRole

For more information, please read the following KB:

https://support.microsoft.com/en-us/kb/3083085

SCVMM Fabric Controller Script

We are reaching the holidays, and besides public speaking, I am trying to slow down a bit in order to prepare for the arrival of my baby girl early in January.

However, I haven’t been all that lazy, and in this blog post I would like to share a script with you.

During 2014, I have presented several times on subjects like “management stamp”, “Windows Azure Pack”, “SCVMM” and “Networking”.

All of these subjects have something in common, and that is a proper design of the fabric in SCVMM to leverage the cloud computing characteristics that Azure Pack is bringing to the table.

I have been visiting too many customers and partners over the last months just to see that the design of the fabric in VMM is not scalable or designed in a way that gives some meaning at all.

As a result of this, I had to create a Powershell script that easily could show how it should be designed, based on one criteria: turning SCVMM into a universal fabric controller for all your datacenters and locations.

This means that the relationship between the host groups and the logical networks and network definitions need to be planned carefully.

If you don’t design this properly, you can potentially have no control over where the VMs are deployed. And that is not a good thing.

This is the first version of this script and the plan is to add more and more stuff to it once I have the time.

The script can be found at downloaded here:

https://gallery.technet.microsoft.com/SCVMM-Fabric-Controller-a1edf8a7

Please note that this script should only be executed in an empty SCVMM environment (lab), and you should change the variables to fit your environment.

Once the script has completed, you can add more subnets and link these to the right host groups.

The idea with this version is really just to give you a better understanding of how it should be designed and how you can continue using this design. 

Understanding Windows Azure Pack and your service offerings

Understanding Windows Azure Pack and your service offerings

From time to time, I meet with customers (and also other system integrators) that is not fully aware of the definition of cloud computing.

I never expect people to know this to the very nasty details, but have an overview of the following:

·         Deployment models

·         Service models

·         Essential characteristics

What’s particular interesting when discussing Windows Azure Pack, is that the deployment model that’s relevant, is the private cloud. Yes, we are touching your own datacenter with these bits – the one you are in charge of.

For the service models, we are embracing Infrastructure as a Service (IaaS – using the VM Cloud Resource Provider), and Platform as a Service (PaaS – Using the Web Site Cloud Resource Provider).

The essential characteristics are also very important, as we’ll find elasticity, billing/chargeback, self-service, resource pooling and broad network access.

If you combine just self-service and IaaS, this tells us that we empower our users to deploy virtual machines on their own. Right?

So having the flexibility to provide such service, we also rely on the underlying architecture to support this. Due to scalability (elasticity), we need to ensure that these users constantly have access to the solution – no matter what device they are using (broad network access), we need to find out who is consuming what (billing/chargeback), and last but not least – be able to produce these services in an efficient way that makes it cost effective and profitable (resource pooling).

So, it starting to make sense.

There is a reason for what we are seeing and we are providing these services by abstracting the underlying resources into clouds, plans and subscriptions with the Cloud OS.

Implementing a complete IaaS solutions may bring some obstacles to the table.

Organizations tends to think that IaaS is something they have provided for years. Perhaps they have provided virtual machines, but not a complete IaaS solution.

The reason for that is that IaaS is relying on abstraction at every layer. This is not only about virtual compute (memory, CPU), but also about virtual storage and virtual networking.

This is when it gets interesting, using network virtualization.

Remember that self-service is an essential characteristic of the cloud, right?

So delivering IaaS would also mean that the user is able to do stuff with the networking aspect as well, with no interaction from the service provider/cloud administrator.

This is why Software-Defined Networking (NVGRE) is so essential to this service model, and hence we run into the following obstacles.

·         The customer (most often service provider) wants to continue to provide managed services, such as:

o   Backup (both crash consistent and app consistent)

o   Monitoring (above the operating system level, covering the application stack)

This is what they are doing today, with their infrastructure. But this also has a high cost to operate due to all the manual operations needed and involved to get the wheels moving.

Luckily, Windows Azure Pack is able to cover both scenarios, providing a consistent experience to users/tenants no matter if they are running resources in a “legacy” infrastructure, or a new modern IaaS infrastructure.

The following architecture shows that we are using two Virtual Machine Management Stamps.

Both of these are located behind the SPF endpoint – which present the capabilities, capacity and much more to the service management API in Azure Pack.

A cloud administrator then creates a Hosting Plan in the Admin Portal of Azure Pack, which is associated with the legacy cloud in the legacy VMM server. This plan is available for the users/tenants who are subscribing to managed services.

A new plan is created, associated with the IaaS cloud and the IaaS VMM server, available for the users/tenants that need IaaS, without the requirement of managed services. They are dealing with these themselves.

Hopefully this blog post gave you an overview of what’s possible to achieve using Azure Pack and combine both kind of services using a single solution.

(Want more info? – please join my TechEd session in Barcelona next week).

Scratching the surface of Networking in vNext

The technical previews of both Windows Server and System Center is now available for download.

What’s really interesting to see, is that we are making huge progress when it comes to core infrastructure components such as compute (Hyper-V, Failover Clustering), storage and networking.

What I would like to talk a bit about in this blog post, is the new things in networking in the context of cloud computing.

Network Controller

As you already know, in vCurrent (Windows Server 2012 R2 and System Center 2012 R2), Virtual Machine Manager act as the network controller for your cloud infrastructure. The reasons for this have been obvious so far, but has also lead to some challenges regarding high availability, scalability and extensibility.

In the technical preview, we have a new role in Windows Server, “Network Controller”.

This is a highly available and scalable server role that provides the point of automation (REST API) that allows you to configure, monitor and troubleshoot the following aspects of a datacenter stamp or cluster:

·         Virtual networks

·         Network services

·         Physical networks

·         Network topology

·         IP Address Management

A management application – such as VMM vNext can manage the controller to perform configuration, monitoring, programming and troubleshooting on the network infrastructure under its control.

In addition, the network controller can expose infrastructure to network aware applications such as Lync and Skype.

GRE Tunneling in Windows Server

Working a lot with cloud computing (private and service provider clouds), we have now and then ran into challenges for very specific scenarios where the service providers want to provide their tenants with hybrid connectivity into the service provider infrastructure.

A typical example is that you have a tenant running VMs on NVGRE, but the same tenant also wants access to some shared services in the service provider fabric.

The workaround for this have never been pretty, but due to GRE tunneling in Windows Server, we have many new features that can leverage the lightweight tunneling protocol of GRE.

GRE tunnels are useful in many scenarios, such as:

·         High speed connectivity

This enables a scalable way to provide high speed connectivity from the tenant on premise network to their virtual network located in the service provider cloud network. A tenant connects via MPLS where a GRE tunnel is established between the hosting service provider’s edge router and the multitenant gateway to the tenant’s virtual network

·         Integration with VLAN based isolation

You can now integrate VLAN based isolation with NVGRE. A physical network on the service provider network contains a load balancer using VLAN-based isolation. A multitenant gateway establishes GRE tunnels between the load balancer on the physical network and the multitenant gateway on the virtual network.

·         Access from a tenant virtual networks to tenant physical networks

Finally, we can provide access from a tenant virtual network to tenant physical networks located in the service provider fabrics. A GRE tunnel endpoint is established on the multitenant gateway, the other GRE tunnel endpoint is established on a third-party device on the physical network. Layer-3 traffic is routed between the VMs in the virtual network and the third-party device on the physical network

No matter if you are an enterprise or a service provider, you will have plenty of new scenarios made available in the next release that will make you more flexible, agile and dynamic than ever before.

For hybrid connectivity – which is the essence of hybrid cloud, it is time to start investigate on how to make this work for you, your organization and customers.

How Azure Pack is using Service Provider Foundation

How Azure Pack is using Service Provider Foundation

A while ago, I wrote several posts about the different APIs in Azure Pack.

As you may be aware of, Azure Pack consists of what we often refer to as “Service Management API”.

The API is similar to the one we will (not literally) find in Microsoft Azure, where the portal interacts with the APIs, that again aggregate all the wide diversity of resource providers available for us to consume.

A short summary

The Azure Pack Management Portal offers a familiar, self-service interface that every subscriber (tenant) uses to provision and manage services such as the web site offerings and the virtual machine with its virtual network capabilities.

We have portals for the admin (service provider) and the tenants.

Underlying the Management Portal is an OData Rest application programming interface (API) known as the Service Management API.

This API provides access to the underlying services and enables automation and replacement of the existing management portal.

Some of my API posts:

Working with the Admin API in Windows Azure Pack - http://kristiannese.blogspot.no/2014/06/working-with-admin-api-in-windows-azure.html

Azure Pack – working with the Tenant Public API - http://kristiannese.blogspot.no/2014/06/azure-pack-working-with-tenant-public.html

API summary:

Administrator API

REST APIs that are only available to Service Management for administrators. Default this Admin API is using port 30004, so the URI requests should reflect that.

Tenant API

REST APIs that are available for both administrators and tenants. Default the tenant API is using port 30005.

Public tenant API

Public REST APIs that support end-user subscription management for services presented by the service management API. Default the port is set to 30006.

Let us get back on track

When we are working with the VM Cloud Resource Provider in WAP, we are touching many many APIs on our journey, and one of the important ones (well, all of them are important for this to work) is the Service Provider Foundation (SPF).

SPF is provided with System Center 2012 R2 – Orchestrator (no, you don’t have to install Orchestrator, but the SPF setup is located in the Orchestrator setup/media).

SPF exposes an extensible OData web service that interacts with VMM. This enables service providers to design and implement multi-tenant self-service portals that integrate IaaS capabilities available in System Center 2012 R2 and Windows Server 2012 R2 – Hyper-V.

SPF contains several web services that has two locations to set credentials. On the server that has the SPF installed we use the application domain pool in IIS and the respective group in Computer Management. These groups (SPF_Admin, SPF_VMM, SPF_Usage and SPF_Provider) must contain a local credential (not a domain credential) that is also member of the Administrators group on the SPF server.

The SPF_VMM user must be added as an administrator to VMM in order to invoke actions from the WAP portal.

The Service Provider Foundation Web Services:

Admin Web Service (http://spfserver:8090/SC2012R2/Admin/Microsoft.Management.Odata.svc )

The admin web service is used to create and manage tenants, user roles, servers (like Remote Console), stamps (VMM), and other administrative objects.

VMM Web Service ( https://server:8090/SC2012R2/VMM/Microsoft.Management.Odata.svc )

The VMM web service invokes the VMM server to perform requested operations.

Examples of operations could be:

-          Creating virtual machines

-          Creating virtual networks

-          Creating user role definitions

-          Create cloud services and other fabric

Communication is bidirectional, so that actions triggered by a portal that’s using SPF (like WAP) as well as actions happening directly in VMM will be reflected on both sides.

An example:

You do something in VMM that affect one or more tenants, like adding a new VM to the tenant’s subscription. This will pop up in the tenant portal of WAP.

Another example is when a tenant makes changes to a virtual network in the portal, the jobs are triggered in VMM, aggregated by SPF and shows immediately.

Usage Web Service

SPF has also a Usage Web Service that can only be used by WAP, and uses data from Operations Manager’s data warehouse, which is integrated with VMM in order to collect information of the virtual machine metrics. You must use the spfcmdlets to register SCOM with SPF.

Provider Web Service

Resource providers for delivering infrastructure as a service (IaaS) uses this web service that provides a Microsoft ASP.NET web API. This one uses also the VMM and Admin web services but is not an Open Data (OData) service.

Registering SPF endpoint with Windows Azure Pack

As an administrator, you log on to the management portal and register the Service Provider Foundation endpoint. This will register a connection between the Service Management API and SPF.

Since SPF provides a programmatic interface to the stamps (VMM management servers), it enables service providers and enterprises to design and implement multi-tenant self-service portals that leverage IaaS capabilities provided by System Center and Windows Server.

After you have registered the SPF endpoint with the Service Management API:

·         All stamps that you have created directly in SPF will be listed in the management portal for administrators

·         All clouds created within the VMM stamp(s) will appear in the management portal for administrators

·         You can register stamps directly using the management portal for administrators

·         You can remove/change the association between stamp and service provider foundation

Deploying Service Bus for Windows Azure Pack

Many organizations worldwide has implemented many Azure Pack solutions over the last months.

Especially the VM Cloud has been a highly appreciated resource provider in this solution, but we are also seeing more and more adoption of the PaaS offerings, such as Web Site Clouds and SQL Server Clouds.

Recently, I’ve been implementing the Service Bus Cloud too, which is very relevant for the other PaaS I just mentioned.

Eh, Service Bus? What’s that?

My first meeting with Service Bus was back in 2008 when Windows Azure was new.

In a nutshell, Service Bus provides messaging capabilities that enables you to build, test and run loosely-coupled message-driven applications.

This was something we first saw in Azure, where the developers could take advantage of this scalable service.

Later, we got Service Bus for Windows Server which provides similar capabilities as the ones we find in Azure (one consistent platform), which gives flexibility in developing and deploying applications. It is built on the same architecture as the Service Bus cloud service and provides scale and resiliency capabilities.

What about Azure Pack in this context?

Again, we will return to the Cloud OS vision with the one consistent platform. A developer can now easily develop, test and tune their applications using Azure Pack on-premise. In this case, perhaps they do not have a 24/7 environment where the IT organizations are watching things closely, or do not provide the required support outside of business hours.

Now, the developer and its organization can turn to a service provider who offers the same Azure technologies delivered through Windows Azure Pack. In this case, the service provider will be responsible for the entire Azure Pack environment where these services are living and provide support and ensure business continuity.

Therefore, as a result of having the same platform, this customer can easily deploy the same applications to the service provider cloud using the same experience as on-premises, once they move to production.

The next step is of course to leverage the hyper-scale cloud of Microsoft Azure, which again, has the same capabilities as delivered through Azure Pack.

To summarize, we have a very flexible deployment options now using the Cloud OS where each tenant are able to take advantage of the most appropriate cloud option for their applications.

Great, now I understand a bit more, but what kind of features do we have for Service Bus using Azure Pack?

As stated earlier, the Service Bus on-premise supports the same brokered messaging feature set as Microsoft Azure Service Bus. Service Bus queues offer reliable message storage and retrieval with a choice of protocols and APIs.

First of all, we have the Service Bus Queues which provide load leveling by allowing the message receiver to process messages at its own pace. Service Bus provide load balancing by having multiple competing receivers that accept messages from the same queue.

Next, we have Service Bus Topics which provide rich publish-subscribe capabilities that enable multiple, concurrent subscribers to independently retrieve filtered or unfiltered views of the published message stream.

.

Deployment of Service Bus for Windows Azure Pack

You should at least start with a new virtual machine running Windows Server 2012 R2.

Next, download and install Web Platform Installer so that you can get your hands on the “Windows Azure Pack: Service Bus 1.1” component. Yes, this one is also provided in the same way as every extension, site and API for the Azure Pack.

After the installation, you will find the “Service Bus Configuration” located under Apps.

This will prompt you with a wizard that need some inputs so that you can configure the service bus service.

The options you have is to either create a new farm using the default settings, custom settings, or add to an existing farm.

In this case we will create a new farm using the default settings.

The Service Bus requires a SQL in the backend, and we will use an already existing SQL Cluster to ensure HA for our services. Specify name, username and password and test the connection before you proceed.

Service Bus also requires a service account. Once created in AD, assign the name and the password.

Under Certificate Generation Key, you must specify this and re-enter it in the box below. Please keep a record of this key for future use as you have to provide it every time you add a computer to this farm.

The configuration cmdlets use this key for generating certificates.

The option for “Enable firewall rules on this computer” should be enabled so that the configuration wizard creates required firewall rules. Only uncheck this box if Service Bus clients (applications) will run on the same server as Service Bus.

The last section of the configuration page is where you will enable the Service Bus to be managed by the Service Management API in Azure Pack.

Set the usernames and passwords which are used to secure API calls between the portal and the Service Bus farm.

In the end, you will get a summary that shows your configuration and click finish to proceed.

Adding the Service Bus Cloud to Windows Azure Pack

Logon to the admin portal as an administrator and navigate to the Service Bus Cloud.

Click on “Connect to an existing Service Bus cloud” to register with the endpoint.

Fill in the required information that connects you to the API. Once completed, you will have you new Service Bus Cloud added to WAP.

In order to expose the capabilities to your tenants, you need to present this offering through a Hosting Plan. Either create a new Plan meeting your requirements, or simply add to an existing Hosting Plan to extend your service offerings. In our case, we are adding the Service Bus cloud to an existing Plan.

Heading over to the tenant portal, we can see that the Service Bus offering is made available and that I have already created my first Namespace.

Next, I can go ahead and work with queues, topics and use this as part of my applications.

Happy developing!

Free Webinars - Azure Technologies in the Private Cloud

This is just an announcement that I will be holding a presentation related to my last whitepaper, published by Savision in the upcoming weeks.

Sign up for August 20^th by following this link: http://www.savision.com/webinar-azure-technologies-private-cloud-mvp-kristian-nese-august-20th

Sign up for August 21^st by following this link: http://www.savision.com/webinar-azure-technologies-private-cloud-mvp-kristian-nese-august-21st

During this session, I will walk through the importance of a private cloud and how you can make this become real with technologies from Microsoft.

Especially interesting is the focus on Windows Azure Pack that has gotten a lot of attention during the last months.

Dive in to see what Azure Pack is all about and what the benefits are.

I encourage you all to ask any questions during these webcast, as long as it is related to the content or Led Zeppelin ;-)

Workaround for VM Roles and Storage Classifications

Solving classification for your VM Roles with VMM

Since you are reading this blog post, and hopefully this blog now and then, you are most likely familiar with the concept of Gallery Items in Windows Azure Pack.

Useful Resources

If not, I suggest that you read the following resources: http://kristiannese.blogspot.no/2013/10/windows-azure-gallery-items-getting.html

If you want all the details around everything, please download our “Hybrid Cloud with NVGRE (Cloud OS)” whitepaper that put everything into context.

http://gallery.technet.microsoft.com/Hybrid-Cloud-with-NVGRE-aa6e1e9a

My good friend and fellow MVP – Marc van Eijk, will publish a couple of blog posts at “Bulding Clouds blog”, where he dive into the nasty details around VM Roles. Here’s the link to his first contribution: http://blogs.technet.com/b/privatecloud/archive/2014/07/17/the-windows-azure-pack-vm-role-introduction.aspx

Gallery Items and VM Roles

Before we proceed. Gallery Items brings “VM Roles” into Azure Pack, which reminds you a lot of service templates in VMM in the way that they are able to climb up the stack and embrace applications and services during the deployment. However, a VM Role is not completely similar to a service template in VMM as it has no knowledge of any of the profiles (Hardware Profile, Application Profile, SQL Profile and Guest OS Profile).

This is where it gets tricky.

Gallery Items are designed for Azure and brings consistency to the Cloud OS vision, by letting you create VM Roles through the VMRoleAuthoringTool from Codeplex for both Azure Pack (Private Cloud) and Microsoft Azure (Public Cloud).

The components of a VM Role are:

·         Resource Definition file (required – and imported in Azure Pack)

·         View Definition file (required – presents the GUI/wizard to the tenants)

·         Resource Extension (optional – but required when you want to deploy applications, server roles/features and more to your VM Role

The tool let you create, alter and update all these components and you can read more about the news on this blog post: http://blogs.technet.com/b/scvmm/archive/2014/04/22/update-now-available-for-the-virtual-machine-role-authoring-tool.aspx

So far, in 2014, I have been visiting many customers who are trying to adopt Azure Pack and Gallery Items with VM Roles. They want to provide their tenants with brilliant solutions, that are easy to understand and deploy, and can be serviced easily by the cloud administrators.

However, there are some important things to note prior to embracing the VM Roles in Azure Pack, especially when it comes to storage.

·         VM Roles are only using Differential disks

·         You can’t benefit from storage classifications associated with your VMM Clouds – and determine where the VHDX’s will be stored

Why are we using Differential disks for VM Roles?

This is a frequently asked question. In the VMM world, we are familiar with the BITS operation during VM deployment. Luckily, fast file copy was introduced with VMM 2012 R2 and we can also leverage ODX for deployment now, so hopefully BITS is nothing that you see very often when deploying VMs anymore.

However, in order to speed things up a bit more, we are using Diff disks for VM Roles. This is because we intend to reduce deployment time and improve performance. Shared bits from the parent VHDX would be served up from cache in most scenarios and new VMs simply create a new diff disk and boot up. This goes for both OS disk and data disks for the VM Role. No file copy need to occur (except for the first VM to require the disk). When you then decide to scale a VM Role in Azure Pack (scale out), the new instance can boot almost immediately and start walking through the setup.

Ok, I understand the decision around Differential disks now, but what about storage classification and where to put these disks?

Since VM Roles in Azure Pack are only linked to the disks in the VMM library (by using tags), we can’t map it towards any of the storage classifications.

Out of the box, there is no way to modify this prior to the deployment.

Tip 1 – Default parent disks path on the hosts

In VMM, navigate to Fabric and click on properties on your hosts in the host groups associated with the cloud used by Hosting Plans in Azure Pack.

Here you can specify the default parent disk paths to be used for the virtual machines (VM Roles).

If you have dedicated shares or CSVs, this might be helpful and can streamline where the VM roles are living.

Tip 2 – Live Storage Migration post deployment

At a customer site earlier this year, we ended up by using Powershell to move the disks around after deployment.

This is something we added to SMA afterwards that was automatically triggered post the create operation of every new VM Role.

Here’s the script:

### Get every VM Role in a specific VMM Cloud used by Azure Pack

$vms = Get-SCVirtualMachine | Where-Object {$_.AvailabilitySetNames -cnotcontains $null -and $_.Cloud -like "Service Provider Cloud"}

### Move the storage to the preferred/dedicated directory

      

       foreach ($vm in $vms)

{

      

Move-SCVirtualMachine -VM $vm -Path "C:\ClusterStorage\CSV01\" -UseLAN -RunAsynchronously

      

      

       }

As you can see, we are querying virtual machines that has an availability set associated. Each and every time you deploy a VM Role with Azure Pack, the underlying cloud resource in VMM gets an availability set to ensure that when you scale out the VM Role, the workloads are spread on different Hyper-V nodes in a Cluster (assuming you are using a Hyper-V Cluster for your workloads).

That’s it, and hopefully this gave you some ideas and more information around VM Roles in Azure Pack.

Windows Azure Pack - Infrastructure as a Service Jump-start

If you are interested in Azure Pack and especially the VM Clouds offering (Infrastructure as a Service), then you should mark the date and time so that you are able to join us this week.

We will be arranging a MVA Jump-Start: Windows Azure Pack – Infrastructure as a Service Jump-Start.

http://www.microsoftvirtualacademy.com/liveevents/windows-azure-pack-infrastructure-as-a-service-jump-start

“IT Pros, you know that enterprises desire the flexibility and affordability of the cloud, and service providers want the ability to support more enterprise customers. Join us for an exploration of Windows Azure Pack's (WAP's) infrastructure services (IaaS), which bring Microsoft Azure technologies to your data center (on your hardware) and build on the power of Windows Server and System Center to deliver an enterprise-class, cost-effective solution for self-service, multitenant cloud infrastructure and application services. 

Join Microsoft’s leading experts as they focus on the infrastructure services from WAP, including self-service and automation of virtual machine roles, virtual networking, clouds, plans, and more. See helpful demos, and hear examples that will help speed up your journey to the cloud. Bring your questions for the live Q&A!”

To get a solid background and learn more on what we are going to cover, I highly recommend to download and read the whitepaper we created on the subject earlier this year.

http://gallery.technet.microsoft.com/Hybrid-Cloud-with-NVGRE-aa6e1e9a

Together with some of the industry experts, I will be answering questions during the event – so please use this opportunity to embrace and adopt the Azure Pack.

Azure Pack - Working with the Tenant Public API

In these days, you are most likely looking for solutions where you can leverage powershell to gain some level of automation no matter if it’s on premises or in the cloud.

I have been writing about the common service management API in the Cloud OS vision before, where Microsoft Azure and Azure Pack is sharing the same exact management API.

In this blog post, we will have a look at the tenant public API in Azure Pack and see how to make it available for your tenants and also how do some basic tasks through powershell.

Azure Pack can either be installed with the express setup (all portals, sites and API’s on the same machine) or distributed, where you have dedicated virtual machines for each portal, site and components. By having a look at the API’s only, you can see that we have the following:

Windows Azure Pack and its service management API includes three separate components.

·         Windows Azure Pack: Admin API (Not publicly accessible). The Admin API exposes functionality to complete administrative tasks from the management portal for administrators or through the use of Powershell cmdlets. (Blog post: http://kristiannese.blogspot.no/2014/06/working-with-admin-api-in-windows-azure.html )

·         Windows Azure Pack: Tenant API (Not publicly accessible). The Tenant API enables users, or tenants, to manage and configure cloud services that are included in the plans that they subscribe to.

·         Windows Azure Pack: Tenant Public API (publicly accessible). The Tenant Public API enables end users to manage and configure cloud services that are included in the plans that they subscribe to. The Tenant Public API is designed to serve all the requirements of end users that subscribe to the various services that ha hosting service provider provides

Making the Tenant Public API available and accessible for your tenants

Default, the Tenant Public API is installed on port 30006 – which means it is not very firewall friendly.

We have already made the tenant portal and the authentication site available on port 443 (described by Flemming in this blog post: http://flemmingriis.com/windows-azure-pack-publishing-using-sni/ ), and now we need to configure the tenant public API as well.

1)      Create a DNS record for your tenant public API endpoint.

We will need to have a DNS registration for the API. In our case, we have registered “api.systemcenter365.com” and are ready to go.

2)      Log on to your virtual machine running the tenant public API.

In our case, this is the same virtual machine that runs the rest of the internet facing parts, like tenant site and tenant authentication site. This means that we have already registered cloud.systemcenter365.com and cloudauth.systemcenter365.com to this particular server, and now also api.systemcenter365.com.

3)      Change the bindings on the tenant public API in IIS

Navigate to IIS and locate the tenant public API. Click bindings, and change to port 443, register with your certificate and also type the correct hostname that the tenants will be using when accessing this API.

4)      Reconfigure the tenant public API with Powershell

Next, we need to update the configuration for Azure Pack using powershell (accessing the admin API).

The following cmdlet will change the tenant public API to use port 443 and host name “api.systemcenter365.com”.

Set-MgmtSvcFqdn –Namespace TenantPublicAPI –FQDN “api.systemcenter365.com” –Connectionstring “Data Source=sqlwap;Initial Catalog=Microsoft.MgmtSvc.Store;User Id=sa;Password=*” –Port 443

That’s it! You are done, and have now made the tenant public API publicly accessible.

Before we proceed, we need to ensure that we have the right tools in place for accessing the API as a tenant.

It might be quite obvious for some, but not everyone. To be able to manage Azure Pack subscriptions through Powershell, we basically need the powershell module for Microsoft Azure. That is right. We have a bunch of cmdlets in the Azure module for powershell that is directly related to Azure Pack.

You can read more about the Azure module and download it by following this link: http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/

Or simply search for it if you have Web Platform Installer in place on your machine.

Deploying a virtual machine through the Tenant Public API

Again, if you are familiar with Microsoft Azure and the powershell module, you have probably been hitting the “publishsettings” file a couple of times.

Normally when logging into Azure or Azure Pack, you reach for the portal, get redirected to some authentication site (can also be ADFS if not using the default authentication site in Azure Pack) and then sent back to the portal again which in our case is cloud.systemcenter365.com.

The same process will take place if you are trying to access the “publishsettings”. Typing https://cloud.systemcenter365.com/publishsettings in the internet explorer will first require you to logon and then you will have access to your published settings. This will download a file for you that contains your secure credentials and additional information about your subscription for use in your WAP environment.

Once download, we can open the file to explore the content and verify the changes we did when making the tenant public API publicly accessible in the beginning of this blog post.

Picture api content

Next, we will head over to Powershell to start exporing the capabilities.

1)      Import the publish settings file using Powershell

Import-WAPackPublishSettingsFile “C:\MVP.Publishsettings”

Make sure the cmdlet fits your environment and points to the file you have downloaded.

2)      Check to see the active subscriptions for the tenant

Get-WAPackSubscription | select SubscriptionName, ServiceEndpoint

3)      Deploy a new virtual machine

To create a new virtual machine, we first need to have some variables that stores information about the template we will use and the virtual network we will connect to, and then proceed to create the virtual machine.

4)      Going back to the tenant portal, we can see that we are currently provisioning a new virtual machine that we initiated through the tenant public API