You are browsing the archive for Uncategorized.

Windows Azure Pack, SQL Always On, Listener and Port story

3:20 pm in Uncategorized by Christopher Keyaert

Hi Guys,

Today, I was at a customer where my colleague and I have to install Windows Azure Pack. The DBA gave us the SQL Always On Listener name and we started the setup. We specified the SQL listener, the credentials, the passphrase…

…and it failed with the following error message: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible
The complete error message is available:


System.Data.SqlClient.SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server) —> System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified

at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action1 wrapCloseInAction)

at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)

at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, Boolean withFailover)

at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean ignoreSniOpenTimeout, TimeoutTimer timeout, Boolean withFailover)

at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString connectionOptions, SqlCredential credential, TimeoutTimer timeout)

at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(TimeoutTimer timeout, SqlConnectionString connectionOptions, SqlCredential credential, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance)

at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData)

at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)

at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions)

at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)

at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)

at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)

at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection)

at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)

at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource1 retry, DbConnectionOptions userOptions)

at System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource1 retry)

at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource1 retry)

at System.Data.SqlClient.SqlConnection.Open()

at Microsoft.WindowsAzure.Server.Common.SessionManager.<IsMasterAsyncInternal>d__4.MoveNext()

at Microsoft.WindowsAzure.Management.TaskSequencer.<>c__DisplayClass1e`1.<RunSequenceAsync>b__1d(Task previousTask)

— End of stack trace from previous location where exception was thrown —

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at Microsoft.WindowsAzure.Server.AdminManagement.Service.CleanupRunner.MaintenanceCycleRunner.<RunCycleAsync>d__0.MoveNext()


After digging for a few hours, we finally found the following post: saying that the Listener name could not be enough for certain application and that we also need to specify the port. The format to use is the following LISTERNAME,PORT.

Let’s try that, we specified the our ListerName,Port as below:

And we’ve been able to complete our Windows Azure Pack installation J

It seems that you have to use the same trick when you want to install Service Management Automation with SQL Always On running on a non-standard port.

Have a good week!


Windows Azure Pack: Active Directory Authentication – Part 3

3:16 pm in Uncategorized by Christopher Keyaert

Welcome back to this series about Windows Azure Pack – Active Directory Authentication. Azure Directory is now configured as an identity provider, we will focus on the final WAP Configuration to use Azure Directory for our tenants authentication.

It’s time to go back to Microsoft Azure and open our Access Control Service site. There we have to click on Application Integration and copy the WS-Federation Metada url as below.

Your WS-Federation Metada url should looks like to the following:
Update the PowerShell script below with your own values:

$dbServer = ''
$dbuser = 'sa'
$dbPassword = '*******'
$portalnectionString = [string]::Format('Data Source={0};Initial Catalog=Microsoft.MgmtSvc.PortalConfigStore;User ID={1};Password={2}', $dbServer, $dbuser, $dbPassword)
Set-MgmtSvcRelyingPartySettings -Target @(&quot;Tenant&quot;) <code>
 -MetadataEndpoint </code>
 -ConnectionString $portalnectionString -DisableCertificateValidation 

Logon to the Windows Azure Pack server and start a Windows Azure Pack Administrator PowherSell prompt as Administrator. Copy/Paste the script updated with your own values.

Done, we are now all set and it’s time to test J

We have to start Internet Explorer and go to the Tenant Portal.

We are automatically redirected to our ACCESS Control Service we created in Microsoft Azure.

We have now to sign in with our Azure Active Directory credentials, which are in fact the same than our on premise Active Directory credentials thanks to DirSync.

And we finally have access to our Tenant Portal with our on premise Active Directory Credentials.

From the Management Portal, we could now assign a Subscription to our Account.

This is all for today, have a good day!


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.


SCOM 2012 R2: Unattended installation / Command Line

3:21 pm in Uncategorized by Christopher Keyaert

Today, let’s focus on the PowerShell Command line that you could use to silently install SCOM to your environment.
The scripts below are for System Center Operations Manager 2012 R2 and Windows Server 2012 R2.

Prerequisites installation

One of the first SCOM prerequisites is to install Report View, which also has the installation of SQL Sys CLR as prerequisite. The few lines below will take care of the installation of these components.

$dwnld = 'C:\SCOM2012R2Prereqs'
if (!(Test-Path -path $dwnld))
 New-Item $dwnld -type directory
$object = New-Object Net.WebClient
$RPTurl = ''
$object.DownloadFile($RPTurl, "$dwnld\ReportViewer.msi")

$RPTurl = ''
$object.DownloadFile($RPTurl, "$dwnld\SQLSysClrTypes.msi")

Start-Process -FilePath "$dwnld\SQLSysClrTypes.msi" -ArgumentList '/q' -Wait
Start-Process -FilePath "$dwnld\ReportViewer.msi" -ArgumentList '/q' -Wait

First management server installation

The line below is taking care of the installation of you first management server. Change the parameters to first to your needs.

Start-Process -FilePath E:\setup.exe -ArgumentList '/install /InstallPath:"C:\Program Files\Microsoft System Center 2012 R2\Operations Manager" /components:OMServer,OMConsole /ManagementGroupName:SCOMMgmt /SqlServerInstance:SQLSERVER\Instance /DatabaseName:OperationsManager /DWSqlServerInstance:SQLSERVER\Instance /DWDatabaseName:OperationsManagerDW /ActionAccountUser:Contoso\Administrator /ActionAccountPassword:'XXXX' /DASAccountUser:contoso\Administrator /DASAccountPassword:'XXXX' /DatareaderUser:domhome\Administrator /DatareaderPassword:'XXXX' /DataWriterUser:domhome\Administrator /DataWriterPassword:'XXXX' /EnableErrorReporting:Never /SendCEIPReports:0 /UseMicrosoftUpdate:0 /AcceptEndUserLicenseAgreement:1 /silent'

Other management server installation

Oncec the first management server has been successfully installed, you could use the line below to install the others.

Start-Process -FilePath E:\setup.exe -ArgumentList '/install /InstallPath:"C:\Program Files\Microsoft System Center 2012 R2\Operations Manager" /components:OMServer,OMConsole /SqlServerInstance: SQLSERVER\Instance /DatabaseName: OperationsManager /ActionAccountUser:Contoso\Administrator /ActionAccountPassword:'XXXX' /DASAccountUser:Contoso\Administrator /DASAccountPassword:'XXXX' /EnableErrorReporting:Never /SendCEIPReports:0 /UseMicrosoftUpdate:0 /AcceptEndUserLicenseAgreement:1 /silent'

Web Console installation

The installation of the Web Console needs first to enable some Windows Features. The Script below is taking care of all that.

Import-Module ServerManager

Add-WindowsFeature NET-Framework-Core,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Request-Monitor,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,Web-Metabase,Web-Asp-Net,Web-Windows-Auth,Web-ASP,Web-CGI -Restart

Add-WindowsFeature Web-Asp-Net45,AS-HTTP-Activation

Start-Process -FilePath E:\setup.exe -ArgumentList '/silent /install /components:OMWebConsole /ManagementServer:SCOM.constoso.local /WebSiteName:'Default Web Site' /WebConsoleAuthorizationMode:Mixed /SendCEIPReports:0 /UseMicrosoftUpdate:0 /AcceptEndUserLicenseAgreement:1'

Have a nice day!


Windows Azure Pack: Cloud Cruiser Installation

11:05 am in Uncategorized by Christopher Keyaert

Hi All,

Today, we will focus on the installation of Cloud Cruiser with Windows Azure Pack (WAP). Cloud Cruiser is a company which provides solutions for financial management of cloud solutions released an express version of its Cloud Cruiser software which is included with Windows Azure pack.


In order to get Cloud Cruiser working, you will first need to enable and configure the usage and metering functionality of WAP.
Anders, from Microsoft, did a great blog post series about it, it’s why I will not cover this topic and let you read these posts.

If you previously configured WAP Usage and Metering and that you just applied the UR1, ensure to read this post:

Use the link below to download the Cloud Cruiser Express release for Windows Azure Pack.

The download file is about 230 MB.

Before running the Cloud Cruiser installer, we need to install JRE and create a Windows Azure Pack API password.

JRE installation and configuration

, you need to install Java RunTime Environment, also must know as JRE. (

After you installed Java 7, you must set an environment variable called JAVA_HOME to the location of your Java installation.

  1. Open the System Properties form.
    Using Windows Explorer, one way to open this form is by clicking Start and entering “environment variables” in the search box, then selecting Edit the system environment variables from the results.
  2. Click Environment Variables in the advanced page of the System Properties form.
  3. Click New… in the System variables panel of the Environment Variables form.
  4. In the Variable name field, enter JAVA_HOME.
  5. In the Variable value field, enter C:\Program Files\Java\jre7 (or the appropriate path).
  6. Click OK


Setting the Windows Azure Pack API password

Cloud Cruiser Express uses the Usage REST API of Windows Azure Pack to retrieve subscription and usage data. The user account it connects with, UsageClient, has a randomly generated password by default, so you must set a new password that you can provide to Cloud Cruiser Express application..

To set the Usage REST API password:

  1. On the Windows Azure Pack Admin Site machine, open a Windows PowerShell window.
  2. Execute the following command:

Set‐MgmtSvcSetting ‐Namespace UsageService ‐Name Password ‐Value ‘<newPassword>’ ‐Encode

Note: the new password you created so that you can provide it as part of the Windows Azure Pack connection information in the Cloud Cruiser Express installer.

Cloud Cruiser Installation

Now, it’s finally time to run the Cloud Cruiser Setup.

Review the information and click on NEXT.


Accept the terms and click on NEXT.

Specify the install patch:

As you could see, Cloud Cruiser is using TomCat. Ensure that you are not already using the 8080 port for another application.
Provide the information and click on NEXT.

Select you DB Type and click on NEXT.

Provide your SQL server information.

Provide the Azure Pack Collector properties. (It’s the password that we defined earlier in this post).

Review the information and click on NEXT.

Installation in progress…

System Configuration in progress..

Installation finished J

Windows Azure Pack configuration

We need now to register the Cloud Cruiser REST endpoint. The URL to the REST API method that fetches tenant cost data from the Cloud Cruiser Express server.
This URL is using the following format: <ccServerURL>/rest/v1/wap, where <ccServerURL> is the server where you just installed Cloud Cruiser Express.

For example: http://wapsma001:8080/rest/v1/wap.

Go to your Windows Azure Pack Management Portal > User Costs

Click on Register your Cloud Cruiser REST endpoint.
 Username: admin
 Password: The Admin User Password you created in the installer

Windows Azure Pack Plan Configuration

Now that the REST endpoint is configured, we need to add the Cloud Cruiser service to our existing WAP Plans.

Open one of your plan and click on ADD Service.

Select Cloud Cruiser as Service and Instance.

Confirm that the service has been added to the plan.


NOTE: If you click to thee Cloud Cruiser service in the Plan Services list of any plan, you’ll receive the message “Failed to load configuration for service ‘Cloud Cruiser“.
This is normal as there is nothing to configure for this service.


You are now all set J In another blog post, we will see how to use Cloud Cruiser.