You are browsing the archive for 2014 April.

Windows Azure Pack: Active Directory Authentication – Part 2

3:30 pm in Uncategorized by Christopher Keyaert

Welcome back to this series about Windows Azure Pack – Active Directory Authentication. Now that we sync our on premise Active Directory with Azure Active Directory, we will focus on the configuration of Azure Active Directory to use it as an Identity Provider.

In order to be able to use Azure Active Directory as an Identity Provider, we first have to create a new Access Control in Azure. For start, in the Azure interface, we have to click on New > App Services > Active Directory > Access Control.

There, we select quick create and we have to space a unique namespace and location for our Access Control application.

When done, on the Azure Active Directory page, we have to click on the ACCESS CONTROL NAMESPACES. There, we could see that the ACCESS CONTROL has been well created. Select the ACCESS CONTROL NAMESPACE and click on the manage button at the bottom of the page.

This will open the ACCESS CONTROL SERVICE (ACS) website for your namespace.

As we want to use ACS with our Windows Azure Pack portal, we first have to create a new RELYING PARTY APPLICATION. Just click on ADD.

We have now to fill in the settings for our application (WAP Portal). In the WS-Federation metadata section, we need to provide the FederationMetadata.xml file used by our WAP Tenant Portal. This file is located at the following URL: https://YourWAPTenantPortal/federationmetadata/2007-06/federationmetadata.xml

We also have to change the TOKEN FORMAT to JWT.

As we will create a new Identity Provider later on, in the Authentication Settings, we have to uncheck Windows Live ID. Also ensure that X.509 Certificate is selected as Token Signing Type.

When done, click on the SAVE button and we are redirected the Relying Party Applications page where we could confirm that everything has been created correctly.

The tricky part now is that we have to let our Active Directory tenant know about the existence of our ACS namespace. The Authentication Web Page (WS-Federation) endpoints won’t issue tokens for any recipient, only for the ones represented by a service principal object will be eligible.

As of today, the Windows Azure Active Directory portal does not yet offer commands for creating service principal object. The option here is to use the Office365 PowerShell Cmdlets, we have to download it from here:

The installation process is straightforward, just a next/next setup, when done, start an Office365 PowerShell shell. We have to adapt the ACS URL from to PowerShell script below to match with our ACS url. Replace the vnextlab namespace value by your own ACS namespace value and run the script.

Import-Module MSOnlineExtended –Force
$replyUrl = New-MsolServicePrincipalAddresses –Address
New-MsolServicePrincipal –ServicePrincipalNames @(&quot;;) <code>
 -DisplayName &quot;mywap ACS Namespace&quot; </code>
 -Addresses $replyUrl 


We are prompted to enter our Microsoft Azure Credentials

We could confirm that our Service Principal object has been created successfully.

We have now to go back to the ACCESS CONTROL SERVICE website, select the IDENTITY PROVIDERS in the right menu and finally click on ADD.

There we have to select WS-Federation identity Provider.

There we have to provide the WS-Federation metada URL. Replace the yellow part of the URL below by your Azure Subscription information.

As option we could enter the email prefix and finally, we have to select the relaying party application that we created earlier.

We now have our Relying Party and our Identity Providers set up. We should now tell ACS how to transform the incoming Claims from the Identity provider so that the Relying Party can understand it. We do that using Rule Groups which are a set of rules that govern Claim Transformation. We have to click on RULE GROUPS and click on the DEFAULT RULE GROUP FOR your application.

There we need to click on ADD

We have to:
– Select the Identity Provider we created earlier
– Select HTTP://SCHEMAS.XMLSOAP.ORG/WS/2005/05/identity/CLAIMS/NAME as Input Claim Type.
– Enter UPN as Output Claim Type.

When done, click on SAVE.

We are now all set with the ACCESS CONTROL SERVICE configuration. In the last part of this series, we will configure Windows Azure Pack Portal our new Federation Service.


Windows Azure Pack: Active Directory Authentication – Part 1

3:16 pm in Uncategorized by Christopher Keyaert

To continue my series about Windows Azure Pack, we will take a look today to WAP and Azure Active Directory Authentication. Out of the box, the WAP user management feature is not linked to Active Directory and is using his own user directory/repository. Then you have to manually create and manage your WAP accounts, there is no sync with your Active Directory.

Now the main goal of WAP is to be multitenant and the way to make it possible is to use Microsoft Active Directory Federation Services (ADFS). WAP and ADFS have been covered by Marc Van Eijk:

If you don’t want to install and maintain ADFS, there is an another solution… Azure Active Directory. It’s this topic that I’ll cover in the following series. In my lab, I don’t want to setup an ADFS infrastructure right now, but I want to be able to use my on premise Active Directory Credentials to authenticate to my Windows Azure Pack Portal. The idea is the following:

  • Part 1 – Setup a synchronisation between my on premise Active Directory and Windows Microsoft Azure Directory
  • Part 2 – Configure Azure Directory as an Identity Provider
  • Part 3 – Configure Windows Azure Pack to use Azure Directory

Sync between AD and Azure AD

To use Azure Active Directory, we will need to have an Internet Domain Name available that our users will use to authenticate. Ideally, this Internet Domain Name should match with your Active Directory Domain Name, but this is not mandatory. (See at the end of the post) In my lab, my Active Directory domain name is VNEXTLAB.BE and I’m also owning the VNEXTLAB.BE Internet Domain Name. Thanks to that, I’ll use the same user id ( and password to authentication to Active Directory Domain and my WAP portal.

Now, we need to configure the Internet Domain Name to Azure Active Directory. For that, go to, select Active Director in the service list and finally click on the Directory Name.

Click on the DOMAINS item in the top menu.

Finally, click on the ADD button at the bottom of the page.

We have now to fill in the Internet Domain Name that we will use, in my case VNEXTLAB.BE and click on ADD.
Then Microsoft will ask for a Domain Verification to ensure that we are really owning the domain name that we want to use. This will simply ask us to create a custom DNS record that Azure will check

After a few hours, our domain will be validated and ready to use.

Now, We need to go enable the integration between this new configured domain and Active Directory. For that, simply click on DIRECTORY INTEGRATION at the top of the page, and select ACTIVATED and finally click on the SAVE button at the bottom of the page.

It’s now time to Sync our AD users and passwords (hash) to Windows Azure Directory. For that, we will use the application Windows Azure Active Directory Sync Tool available at the following address:

In my lab, I decided to install this application directly on my domain controller, but you could install it to any computer on your domain.
When download, we start the installation as Administrator.

Simply click on Next.

Accept the Terms.

Specify the installation path.

Installation complete.

My recommendation is now to do a sign out/in, when done, we could start the configuration Wizard (A shortcut is available directly on the Desktop). Click on Next.

We need to provide our Microsoft Azure Credentials.

And also our Windows Active Directory Credentials.

Ensure that the box is not check as we don’t need this feature.

There we need to check the box ENABLE PASSWORD SYNC. (FYI, I will not cover the security question in this blog, there is enough subject about it on internet)

The installation is now complete.

We could directly start the Synchronization process.

In the EventLog, we could see that the Sync started.

We could now sign in again to Azure to ensure that our on premise Active Directory account has been well synced.

Now, if you Internet Domain Name is not the same than the one that you are using to your Active Directory, there is 2 solutions:

  • Add a new user domain name suffix to all your users. (I don’t think that’s the best idea)
  • Change the domain name used by default by Azure Directory to the one we just added. For that, go to DOMAINS, select the domain and click on the CHANGE PRIMARY button.


We now have a sync in place between our on premise Active Directory and Microsoft Azure Active Directory. J
This is ending the first part on this blog series on Windows Azure Pack and Active Directory Authentication.



Service Provider Foundation (KB2932939) – Bindings issue

10:05 am in Uncategorized by Christopher Keyaert

Hi All,

As you are probably already aware, Microsoft published a few days ago the UR2 for System Center 2012 R2.

Part of this, there is an update for Service Provider Foundation (KB2932939) which could cause an unexpected behaviour. Stan already blogged about it here:

Before applying the update, the SPF site is well configured with the right binding

After that I applied the update and did an IISRESET, I’ve been surprised to see that the binding configuration of my SPF site changed to that:

As you could see, the Site is stopped and this new configuration could clearly not work.
To fix it, simply edit the Bindings, and delete the last one as below:

When done, edit the first record and ensure than your SSL certificate is still selected.


And start your website, everything should work perfectly now J

I hope than Microsoft will test more their UR before they released it next time.


SMA: Calling an Orchestrator Runbook from Service Management Automation

2:54 pm in Uncategorized by Christopher Keyaert

Hi All,

Today, a small blog about calling an Orchestrator Runbook from a SMA Runbook. This topic has been already discussed by Tiander here:
The problem with the proposed approach is that for each Orchestrator RB Inputs, you need to add several lines at different places in the SMA Runbook. That’s directly introduce a risk of error/typo, the workflow is less readable and more difficult to maintain.

After a chat with Charles Joy from Microsoft, we improved the SMA RB by using a new hashtable to contain the Orchestrator Variable Names and Values. Like this, if you need to add or remove an Orchestrator parameter, you just need to add/remove an entry in this hashtable.

$RBParamsAndVals = @{
    "Virtual Machine Name" = "VEEAM001"
    "Checkpoint Name" = "Before Software Update"
    "Checkpoint Description" = "Requested by Christopher From SMA via SCORCH"

Now that’s the inputs have been defined, we’ll dynamically populate the Variable values in a new hashtable with the parameter GUID as Key.

What do you think? Easy to use, re-use and maintain J

The full SMA workflow is available below:

workflow Invoke-OrchestratorRunbook
#Connection to SCORCH Runbook
$SCOserverName = ""
$PSUserCred = Get-AutomationPSCredential -Name 'vnextlab\sa_scorch'
$MyRunbookPath = "\SC2012 Solutions\1.0 Cloud Management\1.1.0 VM Checkpoint Management\Cloud Management | VM Checkpoint Management | 1.1.1 Create Checkpoint"  

#Provide the Initialize Data activity parameters:
$RBParamsAndVals = @{
    "Virtual Machine Name" = "VEEAM001"
    "Checkpoint Name" = "Before Software Update"
    "Checkpoint Description" = "Requested by Christopher From SMA via SCORCH"

# Get the url for the Orchestrator service
$url = Get-OrchestratorServiceUrl -Server $SCOserverName 

# Get a Runbook by Path and Name
$Runbook = Get-OrchestratorRunbook -serviceurl $url -credentials $PSUserCred -RunbookPath $MyRunbookPath  

#Correlate the Initialize Data parameters with our values
[hashtable] $paramsTable = @{}
foreach ($key in $RBParamsAndVals.Keys)
     foreach ($param in $runbook.Parameters)
            if($Param.Name -eq $Key)

# Start the runbook
$job = Start-OrchestratorRunbook -runbook $runbook -parameters $paramsTable -credentials $PSUserCred
# Show the Runbook job information

Windows Azure Pack: GridPro – Installation and Overview

5:10 pm in Uncategorized by Christopher Keyaert

You are now used to manage your WebSites, VMs, SQLs with Windows Azure Pack? But what about your Service Manager (SCSM) activities and requests?

 A company named GridPro released a few weeks ago a Windows Azure Pack extension that will let you manage your Request Management directly from the WAP Portal. How cool is that? Windows Azure Pack is really becoming THE portal for all the System Center Produtcs.

If you just installed Windows Azure Pack, you certainly noticed that the GridPro extension is already available from the resources column in the management portal.

If not, just start the Web Platform installer that you used to install WAP and install the 2 GridPro extensions.

When done, you need now to download the GridPro application itself. Go to the following URL and fill in your information. After a few seconds, you will get a mail that is containing a download link.

In my lab, I will install the GridPro application directly on my WAP Server.

Provide information about your SCSM installation (SCSM Server, SQL instance, DB, Service account).

Create an account to let WAP connects to the GridPro WebService. (This is not a domain account or Windows account, just an account that you create here directly here in the GridPro setup).

Accept the license agreement.

Start the installation process.

Done :-) Easy no?

Go to your Windows Azure Pack management portal and click on New at the bottom of the page.

There you need to specify information about your GridPro installation. Basically, the GridPro WebService URL (https://server:30033) and the credentials that you just created earlier during the setup.

Now, in connections, you could see a new entry that represent the GridPro connection to your SCSM server.

By clicking on the connection, you will be able to edit some extra settings. Click on the Edit button at the bottom.

GridPro has 2 running Modes, Subscription and User. Subscription means that all the Service Requests and Activities created will be visible to all the users that are sharing the same Subscription (Ideal when you are working as a Team). User mode means that the Requests and Activities will be available only for the user that created them.

As GridPro extension is fully integrated with the Plan feature, you need first to add your GriProd service to a plan/subscription to be able to use it. Open one of your existing plans and click on add service.

From there, select the Request Management service and the instance that your created.

After a few seconds, the Request Management service is added to your plan.

GridPro Configuration is done, it’s now time to test it.

Incident Request

Start the Service Manager Console and ensure that your have at least one Service Offering published. If not, just create a new one.

Add a Request Offering to your Service Offering. If you don’t have any, you could use the Generic Incident Request, which is a good candidate for that job.

Now, start the TENANT portal and you should see two new services, Requests and Activities. Click on Request and select Create A New Request.

A new window will pop up with your Service Offerings in the left-side column. Clicking on one of the Service Offerings will let you chose one of the available Request Offerings. Below, I selected the Generic Incident Request.

You have now to fill in the exact same information that you should have to if you were directly using the Service Manager Console or the SMPortal.

Confirm your inputs.

As you could see, a new Incident Request has been created.

Of course, the same incident is also visible directly from the Service Management console.

In the WAP portal, if you click on the Request itself, it will show you the details information.

The tracking page displays information from the SCSM Request Log entry. From there, you could directly add a comment and speak with the analyst that is managing your request.

It’s also there that your could see when you request is changing status.

Tacking information also available directly from the SCSM Console.

What do you think of that?

Just a few words about licensing, there is two version of GridPro that are available for WAP, the Express and the Premium. If you want more information about licensing, contact directly:

 Below a small table to see the different features included in each versions.

As you could see, one of the most interesting feature, the Approve/Reject activity, is part of the Premium version. I kindly received a Premium Trial version, so let see how it works. The idea here is to be able to create a new request for the creation of a VM CheckPoint/Snapshot. The approval of this request will automatically trigger an Orchestrator Runbook which will create the VM CheckPoint.

Service Request with Approval Process

In Service Manager, I created a new Service Request, which include a Review Activity and a Runbook activity.

In my review activity, I added my WAP user as reviewer.

My Runbook Activity is triggering an Orchestrator Runbook which will create the VM CheckPoint.

I created a new Request Offering which is using my SR template created above.

When done, I added this Request Offering to an existing Service Offering.

Now, just go to the Tenant WAP Portal and create a new request. I’m now able to select my Create VM CheckPoint (with Approval) request.

Fill in the needed information.

And confirm the request.

After a few seconds, my new request will be created.

In this case, I’m also the reviewer, so in the Activities, I could see that a Review Activity has been created.

By opening this Review Activity, I’m able to directly Approve or Reject this task.

This will automatically release my Orchestrator Runbook, which will create my VM CheckPoint.

Finally, I could see my Request Completed :-)

Have a good weekend!


Windows Azure Pack: Customize the URLs

10:17 pm in Uncategorized by Christopher Keyaert

Now that you are familiar with Windows Azure Pack, it’s time to change the default URLs and Ports of the different WAP Sites to use your own settings. In the following post, I will share my experience with you, but before starting, I recommend you to check the followings three posts about the same topic:

Flemming Riis:
Marc Van Eijk:
Anders Ravnholt:

Ideally, you should use an official SSL certificate and running the sites on port 443. The company Gandi is selling Wildcard SSL Certificate for about 120€/year (, which is really not expensive from what I could see. In my lab (which is running in a hoster datacenter), I’m already using the port 443 for the Remote Desktop Gateway, so I have no other choice that using another port. As this is a lab environment, it’s not really a big deal to not use the 443, so I decided to use the port 444.

Below a summary table of the current and future setup:

When you defined the new URLs, the first step is to create these records to your local and public DNS servers. In my Active Directory domain, I added the following 4 records pointing to my WAP server.

New Tenant Site record:

New AuthSite record:

New AdminSite record:

New WindowsAuthSite record:

When you did it locally, you have to update your DNS at your registrar. Below my Public DNS configuration:

I bought an Wildcard certificate named * that I will use for the different WAP Sites.

To import your certificate SSL to your IIS Server, you could follow this guide.

When imported, your IIS certificate store should looks like below:

Tenant Portal

It’s time to update the Tenant Sites with the new URLs.
In the IIS manager, select the MgmtSvc-TenantSite, do a right click and select Edit Bindings…

Click on Edit:

Follow the steps below:

  1. Change the port.
  2. Specify the site url you defined earlier.
  3. Check the box Require Server Name Indication.
  4. Select your SSL Certificate.

Do the same steps for the MgmtSvc-AuthSite, below my configuration:

Now that IIS has been configured, we need to configure Windows Azure Pack Tenant portals with the new URLs. Start the Windows Azure Pack Administration PowerShell prompt.

Adapt and execute the following commands:

Set-MgmtSvcFqdn -Namespace “TenantSite” -FullyQualifiedDomainName “” -Port 444 -Server sql001

Set-MgmtSvcFqdn -Namespace “AuthSite” -FullyQualifiedDomainName “” -Port 444 -Server sql001

Set-MgmtSvcRelyingPartySettings –Target Tenant –MetadataEndpoint ‘‘ -ConnectionString “Data;User ID=sa;Password=*****”

Set-MgmtSvcIdentityProviderSettings –Target Membership –MetadataEndpoint ‘‘ -ConnectionString “Data;User ID=sa;Password=*****”

We will now test the tenant portal with the new URL, just start IE and type the URL.

You will be redirected to the Tenant Authentication Portal.

When the authentication occurred, you are redirected to the tenant portal.

Admin portal

Now that the Tenant portals (Tenant and Tenant Authentication) have been configured and tested, we will update the Admin Portals with the new URLs.

In the IIS manager, select the MgmtSvc-WindowsAuthSite, do a right click and select Edit Bindings.

Follow the steps below:

  1. Change the port.
  2. Specify the site url you defined earlier.
  3. Check the box Require Server Name Indication.
  4. Select your SSL Certificate.

Do the same for the MgmtSvc-AdminSite, below my configuration:

When done, we need to update the WAP configuration with the new URLs that we just configured in IIS.

Adapt and execute the following command:

Set-MgmtSvcFqdn -Namespace “AdminSite” -FullyQualifiedDomainName “” -Port 444 -Server “SQL001″

Set-MgmtSvcFqdn -Namespace “WindowsAuthSite” -FullyQualifiedDomainName “” -Port 444 -Server “SQL001″

$ConnectionString = ‘Data Source=SQL001;Initial Catalog=Microsoft.MgmtSvc.Config;User ID=sa;Password=XXXX’

Set-MgmtSvcRelyingPartySettings -Target Admin -MetadataEndpoint ‘‘ -ConnectionString $ConnectionString

Set-MgmtSvcIdentityProviderSettings -Target Windows -MetadataEndpoint ‘‘ -ConnectionString $ConnectionString

Configuration done, it’s time to test the connection to the Admin portal.
Just go to your Admin Portal, you will be prompted for your Domain Credentials. You notice that the authentication is requested by the Authentication Site.

Authentication in progress.

Authentication done and redirection for the Admin Site.

Everything is now working as expected and your portals are using your new URLs.

I hope this help, ping me if you have any question.