wiki

Codit Wiki

Loading information... Please wait.

Codit Blog

Posted on Monday, April 15, 2013 1:26 PM

Sam Vanhoutte by Sam Vanhoutte

The moment we’ve all been waiting for is finally there. Windows Azure Infrastructure Services reached the General Availability milestone today. Read more in this blog post.

The moment we’ve all been waiting for is finally there.  Windows Azure Infrastructure Services reached the General Availability milestone today.  This contains the following capabilities:

  • Windows Azure Virtual Machines: you are able to have persistent virtual machines deployed in your Windows Azure subscription.  For this, you can bring your own (Linux or Microsoft) images or select them from the existing gallery.
  • Windows Azure Virtual Networking: you are able to provision and manage virtual private networks (VPNs) in Windows Azure and securely connect them with your local IT infrastructure.

More information can be found on the blog of ScottGu: http://weblogs.asp.net/scottgu/archive/2013/04/16/windows-azure-general-availability-of-infrastructure-as-a-service-iaas.aspx

What is new with this release ?

There are some interesting new items available with the new release:

  • High memory instances.  These are machines with much more memory assigned to it that can serve some specific workloads.  (these are not the high compute machines.  The names for these machines will be A6 and A7, instead of XXXL)
  • Monthly SLAs.  There will from now on be SLA’s provided, that will measure on a monthly basis.  SLAs for Virtual Machines are 99.95% and require 2 instances.  For Virtual Networking, the monthly SLA will be 99.9%.
  • More validated & supported Microsoft workloads.  There will be much more workloads and images added to the platform.  Also BizTalk Server 2013 will be available soon.
  • The actual prices will start as from June 1, but are seriously decreased, also for PaaS images!

What does it mean for you ?

  • From now on, you are able to have a real better together story that fits your preferences: cloud, on premises or hybrid.
  • You can manage all these machines, using the System Center suite
  • And you can share the same identity management through Active Directory and Federation Services
  • There is no lock in.  This is a common concern for enterprises, but with these infrastructure services, you are now able to move virtual machines from the cloud and run them again in your own data center, because of the VM portability.
  • You can now have both the software and the infrastructure layer provided by the same vendor: Microsoft.  This should help you in getting better quality and support through the wide network of Microsoft partners and local Microsoft teams.

What about BizTalk Server ?

As described in the MSDN article “Configuring BizTalk Server 2013 on a Windows Azure VM”, you can install BizTalk Server in Windows Azure infrastructure services.  Until now, these virtual machines were running in preview mode, meaning they were not officially supported or backed up by SLAs.  But from now on, you can have BizTalk Server officially installed and supported on Windows Azure.

Sam Vanhoutte

Categories: Azure
Tags: IaaS
written by: Sam Vanhoutte

Posted on Saturday, December 11, 2010 3:25 PM

Sam Vanhoutte by Sam Vanhoutte

Creating your own virtual machine on Azure: Introducing VM Role

Apparently, I was lucky to be in the first batch of beta participants for the 3 new Azure beta programs:

  • I received the confirmation for the extra small instances rather fast
  • Wednesday evening, I received confirmation for the Azure Connect beta program.  You can read my post on that here: Azure Connect: VPN as a Service, a quick introduction.
  • And later that night, I received confirmation for the VM Role beta program.

This post will demonstrate how to upload a virtual hard disk to the Azure storage and how to configure it to run it as your own instance(s) in the cloud.

Creating the VHD

Microsoft Hyper-V on server, or VMWare workstation on laptop?

I was very happy with Windows Virtual PC.  It was lightweight, free and pretty stable.  It allowed us, developers, to use it on our laptops on the road, at our customers, in the office.  But there is one important thing: Virtual PC does not support a 64-bit OS on a guest system.  And that became a big problem with the introduction of Windows Server 2008 R2; that operating system is only available in 64-bit, which makes sense. 

Because of this, we needed an alternative:

  • Hyper-V: free, stable, Microsoft-product, but not running on Windows 7
  • VMWare Workstation: not free, stable, non-Microsoft product, but running on Windows 7

So, I decided to use VMWare for the creation of my virtual machines for Azure. 

To leverage the full capabilities of the VM Roles, it would be better to use Hyper-V though, since that allows the usage of differencing disks, which would be a big timesaver for incremental updates to a virtual machine image.  But for now, I’ve used VMWare, since I didn’t have a physical Hyper-V server available.

Preparing the Virtual Machine

I took the following steps to create the Virtual machine.

  • Created a virtual machine
  • Installed Windows Server 2008 R2 Enterprise edition on it
  • I enabled the Application Server and Web Role (and therefore also the .NET Framework 3.5.1 features)
  • I installed all updates, but disabled the auto update feature.

Installing the Windows Azure Integration Components

  • The Windows Azure Integration Components are a set of components that are needed to be able to communicate with the Windows Azure Fabric controller.  They need to be installed on the virtual machine, prior to uploading the machine to the Azure storage.
  • Load the iso file that is found in the Azure SDK (iso directory - wavmroleic.iso) as a DVD/IDE in your virtual machine
  • Start the installer on the virtual machine, by double clicking WaIntegrationComponents-x64.msi
  • Follow the installation screen (Next-next-finish)

Please make sure that the firewall windows service is enabled (see ‘Things to know’ at the end of this post)

Sysprepping the Virtual machine

There are some specificities with VM Roles that are different from a typical hosting/IaaS solution.  I discussed some of these in my previous post: Hosting BizTalk Server on Azure VM Role.  One of the important things to know is that the machine name of the Virtual Machine is changed and assigned at runtime by the Azure Fabric controller.  This makes sense, since it is possible to configure multiple instances for a VM Role.

To make the virtual machine ready for these actions, the machine needs to be ‘sysprepped’.  This is a typical action that is taken when creating a base image for a machine.  It provides a different SID and name for the machine.

  • Run the %windir%\system32\sysprep\sysprep.exe tool
  • In the popup windows, select the “Enter System Out-of-Box experience (OOBE)” for the System Cleanup Action
  • Make sure that Generalize is selected and select Shutdown in the Shutdown options.
  • OK

vm0 sysprep

 

[Only with VMWare] : Convert to VHD file

  • This step is only needed when using VMWare. 
  • I used the tool VMDK to VHD Converter and that allowed me to convert my VMWare virtual disk to a VHD.

Uploading the Virtual Hard disk (VHD)

The VHD file now needs to be uploaded.  For this, the Azure SDK 1.3 comes with a command-line tool: CSUPLOAD.  Using this tool, we can upload the VHD to our Azure subscription.

  • Open the Azure SDK Command prompt
  • Type the following command to link the context to your current subscription:
    csupload Set-Connection “SubscriptionId=[SubscriptionId];CertificateThumbprint=[tp]”
    The subscription id can be found on the management portal in the property grid, when selecting a subscription.
    The certificate thumbprint needs to be a private certificate that is installed on the local machine and that is linked to the management certificates on the Azure portal.  On the Azure portal, you can easily copy the thumbprint from the property grid.
  • Now the upload command needs to be done
    csupload Add-VMImage –LiteralPath [localpathtovhd] –Location “West Europe” –Name [cloudname]
    Passing in the localpath to the VHD is important.  Next to that, the location (data center) needs to be defined where the page blob will be created.  And optionally you can specify a friendly name that will be used on the Azure management portal.
    vm1_commandline
  • When this is done, a verification window pops up.  This indicates that the image will be mounted to verify some settings (like Operating System, etc).  This verification is important because it can prevent you from uploading a VHD of several GBs, and then finding out there is an incorrect configuration.
    If the operating system you’re uploading the VHD from does not support mounting a VHD, you can use the parameter –SkipVerify of the CSUpload tool to skip this step.
    vm2_verification
  • After the verification, the upload to the Azure data center starts and that seems to be a good moment to have a sleep (like I did), take a break, or do something else.  The upload typically will take some hours and therefore, the csupload tool is recoverable from connection errors.
    vm3_inprogress
  • As soon as the upload process starts, you can already look at the Azure portal and see the status of the VHD as pending.  The VHD is created as a page blob.
    uploadportal
  • After the upload is completed, you can see the status of the VHD to committed on the Azure portal.  When the connection breaks, it is possible to re-execute the command and the upload will resume where it stopped.  (see ‘Things to know’)

Configure the Azure Role Service

 

Create Visual Studio Project

  • In Visual Studio (after installing the Azure SDK 1.3 and the VMRole Beta unlocker), you can create a new Visual Studio Cloud project and add a VMRole to the Cloud project.
  • On the property page of the VMRole project, you can specify the credentials and the VHD that is uploaded to the Azure platform.
    vm4_prop1
  • On the Configuration tab page, you can specify the number of instances and the size of the instances (notice that I can use the Extra small instance size here, part of the beta program)
    vm4_prop2
  • It is also required to open the endpoints when needed (like when IIS needs to be used, you’ll typically create an HTTP endpoint on port 80 or 443)

Publishing the project to Azure

  • Now it is straightforward to publish this project to Azure, using Visual Studio, or by uploading it on the Azure management portal.
  • After the upload is done, you can see on the management portal the process of the Virtual machine.
  • The roles take the following statuses
    • Initializing
    • Waiting for host
    • Setting up Windows for first use
    • Starting Windows
    • Starting Traffic
    • Ready

portal_status1
portal_status2
portal_status3
portal_status4
portal_status5

Things to know & troubleshooting

Don’t disable the Windows Firewall service

On my virtual machine (locally), I had disabled the Windows Firewall service.  Because of that, the installation of the Windows Azure Integration Components failed with the following exception (copying it here for bing/google search):
Product: Windows Azure VM Role Integration Components -- Error 1720. There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor. Custom action InstallScriptAction script error -2147023143, : Line 81, Column 5,

After I enabled the Windows firewall service again, things worked smooth again.

Resuming the upload

  • Just before the upload finished, I received a timeout exception on the csupload command.  So, I decided to find out if the resumability of the CSUpload tool works as announced.
  • I re-executed the command the 1st time and I noticed the upload started again at 3,2%…  Knowing that I’ve seen the upload pending at 98%, the last time I checked, I decided to retry it again.  (ctrl+c to exit the command)
  • The second time, the resume started at 87,3%.  So I tried again.
  • And, third time lucky!, now I immediately received a confirmation of the upload.  And the management portal also reflected this well.

Don’t install the Windows Azure SDK on the Virtual Machine

It is not supported to install the Windows Azure SDK inside a VM intended for use with VM role. The Windows Azure SDK and the Integration Components are mutually exclusive.

No support for startup tasks

Unfortunately there seems to be no support to use Startup tasks in VMRoles.  So startup tasks will have to be ‘embedded’ in the Virtual Machine startup process.  This might change after the beta, off course.

Conclusion

Again, just as with the Azure Connect, I was very surprised by the simplicity of the process of getting things to work.  Off course, it takes more time, because of the preparation and the upload, but besides that, things looks solid and stable.

Things that I hope to see soon:

  • Base images on Azure that can be downloaded, so that only the differencing disks need to be uploaded.  This would save a lot of time and bandwidth.  (download is cheaper/faster than upload)
  • Start up tasks.

Great stuff.

Sam Vanhoutte, Codit

Categories: Azure
Tags: IaaS
written by: Sam Vanhoutte
2 comments

Posted on Monday, June 23, 2014 4:48 PM

Guest by Guest

Automating the provisioning of a Microsoft Azure virtual machine when your machine boots: An Azure Virtual Machine spins up, automatically connects and displays the virtual machine with my account in a remote desktop session in the morning and automatiically shuts down when you log off in the evening. Learn how in this blog post.

A desktop environment in the Cloud

I recently created a virtual machine in the cloud with the purpose to use this as my own remote desktop. For me, one of the biggest benefits of the IaaS model is the fact that I can easily access the machine from anywhere with any device and I don't need to worry about buying or maintaining hardware, or Windows licenses.

In general, the biggest cost for Microsoft Azure Virtual machines is “compute hours”. Which means, I pay for every minute my remote desktop uses CPU power. To limit the costs, I perform a startup in the morning and shutdown the machine in the evening.
Starting a virtual machine in the morning means I need to login in the Azure management portal, perform some clicks and wait for the provisioning since this can take up to 30 minutes in my experience. Afterwards I provide my credentials and establish a remote desktop connection. The annoying part is I have to do this manually every morning.

I now automated this process: when my laptop boots, the Virtual Machine spins up, automatically connects and displays the virtual machine with my account in a remote desktop session. The reverse process also happens in the evening: when I pull down the lid of my laptop, the Azure VM will shut down.

Pre Requirements

PowerShell with Azure SDK
The first requirement is that we need to install PowerShell and the SDK of Microsoft Azure. The installation can be found here:
http://www.windowsazure.com/en-us/downloads/?fb=en-us
It might be possible you'll need to update your version of PowerShell as well.

Azure virtual machine
If you do not have an Azure Virtual machine, create one through the portal and make sure to enable the remote desktop endpoint:

Azure subscription file
To access your account through PowerShell, download your azure subscription file on this link:
https://windows.azure.com/download/publishprofile.aspx

User rights
User rights to edit the group policy. According to MSDN: "You must be logged on as a member of the Domain Administrators security group, the Enterprise Administrators security group, or the Group Policy Creator Owners security group."

Create the script

Provision virtual machine and start remote desktop session

The startup script can be found below.
The service name of the Virtual machine can be found if you grab the DNS name of het VM and remove the ".cloudapp.net" string.
The name of the VM is as shown in the Azure management portal.

Azure_vm_startup.ps1

#Import Azure PowerShell module and your publish settings file
Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1'
Import-AzurePublishSettingsFile '"C:\start_vm\Visual Studio Premium with MSDN-1-3-2014-credentials.publishsettings"'

#Access the VM
$vm = Get-AzureVM -ServiceName 'myservicename' -Name 'myname'

#Start the VM
$result = Start-AzureVM -ServiceName $vm.ServiceName -Name $vm.Name

do{
  $vm = Get-AzureVM -ServiceName $vm.ServiceName -Name $vm.Name
sleep 5
}until($vm.PowerState -eq 'Started')

#Read the remote desktop adress
$endpoint = Get-AzureEndpoint -Name "Remote Desktop" -VM $vm
$remotedesktopurl = $vm.ServiceName + ".cloudapp.net:" + $endpoint.Port;

#Start remote desktop session
mstsc /v:$remotedesktopurl /f

Shutdown the virtual machine

Azure_vm_shutdown.ps1

#Import Azure PowerShell module and your publish settings file
Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1'
Import-AzurePublishSettingsFile 'C:\start_vm\Visual Studio Premium with MSDN-1-3-2014-credentials.publishsettings'

#Acess the VM
$vm = Get-AzureVM -ServiceName 'myservicename' -Name 'myname'

#Stop the VM
if($vm.PowerState.Equals("Started")){
    $result = Stop-AzureVM -ServiceName $vm.ServiceName -Name $vm.Name -Force
}

Create logon and log off triggers

To trigger the start and stop scripts, I used the group policy in Windows, which gives us the possibility to trigger scripts at the logon and log off event of the user.

Open the Group Policy editor:
Start => Run => gpeditor.msc

Navigate to the Scripts section of the user:
Local Computer Policy => User Configuration => Windows Settings => Scripts (Logon/Log off)

 

Double click the Logon record, navigate to the tab PowerShell scripts, Click add and add navigate to your script.
Repeat the same step for the log off task

To apply the changes immediately, update your Group Policy:
Start => Run => gpupdate

Windows Policy Pitfalls

If you log off your user, and logon again, you should see a remote desktop login popup.
The first time you'll need to provide your credentials and click "Remember my credentials".

Rarely enough, you'll see that the button "Remember my credentials" won't work. Windows is by default disabled to remember those credentials.
I tested this on my Windows 7 and saw this message: "Your system administrator does not allow the use of saved credentials to log on to the remote computer because its identity is not fully verified. Please enter new credentials"

Luckily, we can change this behavior, so open again to the group Policy Editor (Start => Run => gpeditor.ms)
Navigate to the Credentials delegation section:
Local Computer Policy => Computer Configuration => Administrative Templates => System => Credentials Delegation

Double click the record "Allow delegation saved credentials" and click enabled in the section on top.
Click the "Show.." Button and add "*" to the list.

Update the Goup Policy again (start => Run => gpupdate) and log off, logon your user account.

Conclusion

We learned some basics on how to use PowerShell with Microsoft Azure: how to start and stop a VM and dynamically and start a remote desktop session based on configured endpoints.


The solution will give us a lot of comfort in the morning, as long as the machine is connected to the internet at logon and log off time!!
Automating provisioning of a virtual machine saves us time and money. You can now enjoy your coffee even more in the morning.

Categories: Azure
Tags: IaaS
written by: Guest
1 comment

Posted on Friday, June 7, 2013 3:04 PM

Peter Borremans by Peter Borremans

Windows Azure IaaS - Explore how you can automatically provision Virtual Machines in Azure and how to setup a BizTalk environmnet in the cloud! Also find out how to create network connectivity between your cloud and on-premise networks.

Introduction

With the release of BizTalk server 2013, BizTalk Server is ready to run in the cloud in 2 ways:

- BizTalk Server in an IaaS model

- BizTalk Services in a PaaS model.

In this post I will explain step-by-step how-to setup a BizTalk environment in Windows Azure IaaS in an automated way.

The environment we will setup will consist of 3 servers:

- A domain controller

- A SQL Server hosting our BizTalk databases

- A BizTalk 2013 Server

Besides the servers, we will also create a Virtual Network in Windows Azure and we will connect the Virtual Network with our local (on-premise) laptop.

To automate the provisioning of our environment we will make use of PowerShell and Remote PowerShell into our machines in the cloud.

STEP 1 – Prepare PowerShell

To be able to perform our Windows Azure tasks with PowerShell, you will need to download and install Windows Azure PowerShell.

You can find Windows Azure PowerShell on this location: http://www.windowsazure.com/en-us/downloads/ => download and install.

After downloading Windows Azure Powershell, it doesn’t know yet about your Azure subscription and how to connect to it.

To get this right, you have to download your PublishSettings file from this location: https://windows.azure.com/download/publishprofile.aspx.

You will be prompted for the credentials of your Azure account. Download the PublishSettings Xml file. This file contains the details about your Azure account and subscriptions.

Next, launch Windows Azure PorwerShell as an administrator.

Edit and execute these PowerShell commands:

#Initial settings
Set-ExecutionPolicy Unrestricted

#Import publish settings
Import-AzurePublishSettingsFile '<PATH>\Azure.publishsettings'   

# SET AZURE SUBSCRIPTION
Set-AzureSubscription -SubscriptionName 'BizTalk Launch' -CurrentStorageAccount biztalkvms
Select-AzureSubscription -SubscriptionName 'BizTalk Launch'
Set-AzureSubscription -DefaultSubscription 'BizTalk Launch'

First we change the ExcecutionPolicy to ‘unrestricted’.

Then we import the PublishSettings file we just downloaded.

After importing the PublishSettings file, set the Azure Subscription. If you have more subscriptions available in your Azure account, this will tell PowerShell on with subscription to work, and what storage account will be used.

 

Make sure you have a storage account prepared to store the Virtual Machines disks on:

image

 

When step 1 is completed successfully, PowerShell is ready to create our Azure Virtual Machines.

 

STEP 2 – Create a Virtual Network

This step is not automated, since the creation of a Virtual Network will typically be done once.

Logon to the Azure Management Portal.

Create a new Virtual Network (custom create):

image

 

In the create Virtual Network wizard, choose a name for your Virtual Network and assign an Affinity Group:

image

Affinity groups allow you to group your Windows Azure services to optimize performance. All services within an affinity group will be located in the same data center. An affinity group is required in order to create a virtual network.

 

On the next screen, you can configure a DNS server for your network (I will leave it blank in my setup).

Later in the setup of this environment we will connect our on-premise laptop with the Virtual Network in the cloud. For this, we will need a Point-To-Site VPN. Enable ‘Configure Point-To-Site VPN’.

image

 

Azure Virtual Networks Connectivity with on-premise networks can be achieved in two ways:

- Point-To-Site VPN

Point-To-Site connectivity allows you to connect individual devices with your cloud network. Point-To-Site connections will even work from behind a firewall!

- Site-To-Site Connectivity

Site-To-Site connections will connect entire networks with one another.

A Site-To-Site connection can be setup in two ways:

- Hardware VPN: a hardware VPN device is necessary (Cisco, Juniper, …)

- Software VPN: Windows RRAS (Routing and Remote Access) is used as a software VPN

In both cases (hardware and software), you will need a public IP that is not behind NAT!

 

On the next screen, select the IP range that will be used for issuing IP’s to the remote devices that connect to you Virtual Network through the Point-To-Site connections:

image

 

Make sure that the IP range used for the clients does not conflict with the IP range of the Virtual Network itself.

 

On the last screen of the ‘Create Virtual Network’ wizard, choose the ip range of the Virtual Network in Windows Azure:

image

 

The IP range will be different than the one we chose on the Point-To-Site connectivity screen.

The Point-To-Site VPN also requires us to have Gateway. The wizard will not allow us to create the Virtual Network without a Gateway.

Click the ‘add gateway subnet’ button. A Gateway will be added. You can keep the proposed IP.

 

When you finish the ‘Create Virtual Network Wizard’, the Virtual Network will be created in Windows Azure:

image

 

When the Virtual Network is created, open its properties in the Windows Azure Management Console:

 

image

 

As you can see, Windows Azure reports an error ‘The Gateway was not created’.

The only problem is that Windows Azure does not generate the Gateway automatically. The fix is easy, click the ‘Create Gateway’ button at the bottom of the screen, and the Gateway will be created for you.

After a while, the Gateway will be ready and the properties of the Virtual Network should look like this:

image

 

The error ‘Certificate not set up’ will be handled in a later step of our setup.

 

STEP 3 – Create Domain controller

In this step, we will run a PowerShell script that will create our domain controller.

The script looks like this (you should edit variables to match your environment).

# CREATE BIZTALK DOMAIN CONTROLLER

#Variables
$dcname = 'btsdcDemoLive'
$AG = 'BizTalkAFLive'
$vnet = 'BizTalkVNLive'
$adminusername = 'codit'
$myDNS = New-AzureDNS -Name $dcname -IPAddress '127.0.0.1'
$vmname = $dcname
$image = 'a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-Datacenter-201305.01-en.us-127GB.vhd'# old image'a699494373c04fc0bc8f2bb1389d6106__Windows-Server-2012-Datacenter-201302.01-en.us-30GB.vhd'
$service = $dcname
$restart = 'false'
$credential = Get-Credential

#Create Virtual Machine
$mydc = New-AzureVMConfig -name $vmname -InstanceSize 'ExtraSmall' -ImageName $image | Add-AzureProvisioningConfig -Windows -Password $password -AdminUsername $adminusername | Set-AzureSubnet -SubnetNames 'Subnet-1'
New-AzureVM -ServiceName $service -AffinityGroup $AG -VMs $mydc -DnsSettings $myDNS -VNetName $vnet -WaitForBoot
WaitStartVM $service $vmname $restart

# Get the uri for remote configuration
# Get credentials to connect to the remote machine
$cmduri = Get-AzureWinRMUri -ServiceName $service -Name $vmname

#Install the certificate for remote PowerShell
InstallWinRMCert $service $vmname
 
#enable ping (closed by default)
Invoke-Command -ConnectionUri $cmduri.ToString() -Credential $credential -ScriptBlock {
Import-Module NetSecurity
Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -enabled True
}

#Add Domain Controller Windows feature
Invoke-Command -ConnectionUri $cmduri.ToString() -Credential $credential -ScriptBlock {
$loglabel = $((get-date).ToString("yyyyMMddHHmmss"))
$logPath= "$env:TEMP\init_dcservervm_install_$loglabel.txt"
Import-Module -Name ServerManager
Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools -LogPath $logPath
}

#Add DNS Windows Feature
Invoke-Command -ConnectionUri $cmduri.ToString() -Credential $credential -ScriptBlock {
$loglabel = $((get-date).ToString("yyyyMMddHHmmss"))
$logPath= "$env:TEMP\init_dcservervm_install_$loglabel.txt"
Import-Module -Name ServerManager
Install-WindowsFeature -Name DNS -IncludeManagementTools -LogPath $logPath
}

#Promote to domain controller
Invoke-Command -ConnectionUri $cmduri.ToString() -Credential $credential -ScriptBlock {
$loglabel = $((get-date).ToString("yyyyMMddHHmmss"))
$logPath= "$env:TEMP\init_dcservervm_install_$loglabel.txt"
$safemodepass = ConvertTo-SecureString <password> -asPlainText -Force
Import-Module ADDSDeployment
Install-ADDSForest `
	-InstallDns:$true `
	-CreateDnsDelegation:$false `
	-DatabasePath "C:\Windows\NTDS" `
	-SysvolPath "C:\Windows\SYSVOL" `
	-DomainName "BTS2013.com" `
	-DomainNetbiosName "BTS2013" `
	-NoRebootOnCompletion:$false `
	-Force:$true `
	-LogPath $logPath `
	-SafeModeAdministratorPassword $safemodepass
}

Let’s go over the steps executed in the script above:

 

Line 4 to 12: we set variables that will be used

Line 8: DNS server, the domain controller will use itself as DNS server

Line 13: Get-Credentials asks for credentials in an interactive way. This allows you to create scripts without passwords in clear text in the script.

image

Line 16 to 17: Here we create the Virtual Machine in Windows Azure based on an Image. We set the configuration of our Virtual Machine via the parameters.

The Virtual Machine Image can be either:

- A Windows Azure Gallery Image: Microsoft provided Images

- A self-created Image that you first upload to Windows Azure

- Third party Image

Line 18: The WaitStartVM is a function that waits for a VM to be completely ready to start receiving remote PowerShell commands. By default, PowerShell will not wait for the Virtual Machine to finish ‘provisioning’. PowerShell well continue as soon as the Virtual Machine is ‘Started’. This function will fix that.

The function looks like this:

function WaitStartVM($serviceName, $vmname, $restart)
{
	if($restart -eq 'false')
	{
	Start-AzureVM -ServiceName $serviceName -Name $vmname
	}
	else
	{
	Restart-AzureVM -ServiceName $serviceName -Name $vmname
	}
	do{
	$vm = Get-AzureVM -ServiceName $serviceName -Name $vmname
	$state = $vm.PowerState
	$instancestate = $vm.InstanceStatus
	write-host "Waiting for VM to start..."
	sleep 10
	} until ($state -eq 'Started' -and $instancestate -eq 'ReadyRole')
	write-host "VM Started!"
}

We will also use this function throughout the other scripts of our environment setup.

Line 22: We get the URI where our Virtual Machine will accept remote PowerShell commands.

Line 25: The InstallWinRMCert is a function that downloads and installs the certificate that is necessary to execute remote PowerShell commands on our Virtual Machine in a secure way. More info about this function can be found here.

The InstallWinRMCert function looks like this:

function InstallWinRMCert($serviceName, $vmname)
{
    $winRMCert = (Get-AzureVM -ServiceName $serviceName -Name $vmname | select -ExpandProperty vm).DefaultWinRMCertificateThumbprint
 
    $AzureX509cert = Get-AzureCertificate -ServiceName $serviceName -Thumbprint $winRMCert -ThumbprintAlgorithm sha1
 
    $certTempFile = [IO.Path]::GetTempFileName()
    Write-Host $certTempFile
    $AzureX509cert.Data | Out-File $certTempFile
 
    # Target The Cert That Needs To Be Imported
    $CertToImport = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $certTempFile
 
    $store = New-Object System.Security.Cryptography.X509Certificates.X509Store "Root", "LocalMachine"
    $store.Certificates.Count
    $store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
    $store.Add($CertToImport)
    $store.Close()
 
    Remove-Item $certTempFile
}

We will also use this function throughout the other scripts of our environment setup.

 

Line 28 to 31: The invoke-command executes on a remote machine, in this case our Virtual Machine in Windows Azure. In this step we enable ICMP in the Windows Firewall. This will allow us to ping the machine in the Virtual Network.

Line 33 to 39: We add the ‘Active Directory’ Windows Feature to our Virtual Machine.

Line 41 to 47: We add the ‘DNS’ Windows Feature to our Virtual Machine.

Line 49 to 66: We promote our Virtual Machine to domain controller.

 

Domain Users and Groups

Because we are creating a domain that must host a BizTalk environment, we will also need to created the necessary users and groups in Active Directory.

Also this is scripted.

In the first script, I create the necessary domain users:

#Create Biztalk user accounts

# BiztalkAdmin, btssvc, btsisolated, entsso,
New-ADUser -SamAccountName "BiztalkAdmin" -Name "BiztalkAdmin" -DisplayName "Biztalk Administrator" -PasswordNeverExpires 1
Set-ADAccountPassword -Identity BiztalkAdmin -NewPassword (ConvertTo-SecureString -AsPlainText "azert@12345" -Force)

New-ADUser -SamAccountName "btssvc" -Name "btssvc" -DisplayName "Biztalk Service Account" -PasswordNeverExpires 1
Set-ADAccountPassword -Identity btssvc -NewPassword (ConvertTo-SecureString -AsPlainText "azert@12345" -Force)

New-ADUser -SamAccountName "btsisolated" -Name "btsisolated" -DisplayName "Biztalk Isolated Host Users" -PasswordNeverExpires 1
Set-ADAccountPassword -Identity btsisolated -NewPassword (ConvertTo-SecureString -AsPlainText "azert@12345" -Force)

New-ADUser -SamAccountName "entsso" -Name "entsso" -DisplayName "Enterprise Single Sign Service" -PasswordNeverExpires 1
Set-ADAccountPassword -Identity entsso -NewPassword (ConvertTo-SecureString -AsPlainText "azert@12345" -Force)

#Now Enable those accounts that you just created

Enable-ADAccount -Identity "BiztalkAdmin"
Enable-ADAccount -Identity "btssvc"
Enable-ADAccount -Identity "btsisolated"
Enable-ADAccount -Identity "entsso"

Next, we need to create the BizTalk domain groups:

# Create Biztalk Administrators Domain Group
New-ADGroup -Name "Biztalk Server Administrators" -SamAccountName BiztalkServerAdmins -GroupCategory Security -GroupScope Global -DisplayName "Biztalk Server Administrators" -Path "CN=Users,DC=BTS2013,DC=Com" -Description "Members of this group are Biztalk Server Administrators"
# Create Biztalk Server Operators Group
New-ADGroup -Name "Biztalk Server Operators" -SamAccountName BiztalkServerOperators -GroupCategory Security -GroupScope Global -DisplayName "Biztalk Server Operators" -Path "CN=Users,DC=BTS2013,DC=Com" -Description "Members of this group are Biztalk Server Operators"
# Create Biztalk Server Operators Group
New-ADGroup -Name "Biztalk B2B Server Operators" -SamAccountName BiztalkB2BServerOperators -GroupCategory Security -GroupScope Global -DisplayName "Biztalk B2B Server Operators" -Path "CN=Users,DC=BTS2013,DC=Com" -Description "Members of this group are Biztalk B2B Server Administrators"
# Create SSO Administrators Domain Group
New-ADGroup -Name "SSO Administrators" -SamAccountName SSOAdmins -GroupCategory Security -GroupScope Global -DisplayName "SSO Administrators" -Path "CN=Users,DC=BTS2013,DC=Com" -Description "Members of this group are SSO Administrators"
# Create SSO Affiliate Administrators Domain Group
New-ADGroup -Name "SSO Affiliate Administrators" -SamAccountName SSOAffiliateAdmins -GroupCategory Security -GroupScope Global -DisplayName "SSO Affiliate Administrators" -Path "CN=Users,DC=BTS2013,DC=Com" -Description "Members of this group are SSO Affiliate Administrators"
# Create Biztalk Application Users Domain Group
New-ADGroup -Name "Biztalk Application Users" -SamAccountName BiztalkApplicationUsers -GroupCategory Security -GroupScope Global -DisplayName "Biztalk Application Users" -Path "CN=Users,DC=BTS2013,DC=Com" -Description "Members of this group are Biztalk Application Users"
# Create Biztalk Administrators Domain Group
New-ADGroup -Name "Biztalk Isolated Host Users" -SamAccountName BiztalkIsolatedHostUsers -GroupCategory Security -GroupScope Global -DisplayName "Biztalk Isolated Host Users" -Path "CN=Users,DC=BTS2013,DC=Com" -Description "Members of this group are Biztalk Isolated Host Users"

Finally, the users we just created must be added to the correct groups:

#Add users to appropriate Groups

#BiztalkAdmin to Biztalk Server Administrators
$user = Get-ADUser -Identity "BiztalkAdmin"
$group = Get-ADGroup -Identity "BiztalkServerAdmins"
Add-ADGroupMember $group -Member $user

#BiztalkAdmin to Domain Admins
$user = Get-ADUser -Identity "BiztalkAdmin"
$group = Get-ADGroup -Identity "Domain Admins"
Add-ADGroupMember $group -Member $user

#BiztalkAdmin to SSO Administrators
$user = Get-ADUser -Identity "BiztalkAdmin"
$group = Get-ADGroup -Identity "SSOAdmins"
Add-ADGroupMember $group -Member $user


#BTSSVC to Biztalk Application Users
$user = Get-ADUser -Identity "btssvc"
$group = Get-ADGroup -Identity "BiztalkApplicationUsers"
Add-ADGroupMember $group -Member $user

#BTSSVC to Biztalk Application Users
$user = Get-ADUser -Identity "btsisolated"
$group = Get-ADGroup -Identity "BiztalkIsolatedHostUsers"
Add-ADGroupMember $group -Member $user


#entsso to entssoadmins and entssoaffiliateadmins
$user = Get-ADUser -Identity "entsso"
$group = Get-ADGroup -Identity "SSOAdmins"
Add-ADGroupMember $group -Member $user


#entsso to entssoadmins and entssoaffiliateadmins
$user = Get-ADUser -Identity "entsso"
$group = Get-ADGroup -Identity "SSOAffiliateAdmins"
Add-ADGroupMember $group -Member $user

 

The Virtual Machines node in the Windows Azure Management Portal should look like this:

image

 

You can open a Remote Desktop session on the created Virtual Machine. Click the ‘Connect’ button at the bottom of the screen.

Let’s also verify that our users and groups are created in Active Directory:

image

 

When the scripts of STEP 3 executed successfully, you will have an operational Active Directory Domain Controller in the Virtual Network created in STEP 2.

The domain is ready and all necessary users and group are created in Active Directory.

We can now continue with the setup of SQL and BizTalk.

STEP 4 – Create SQL Server

In this step, we will run a PowerShell script that will create our SQL Server Virtual Machine.

After analyzing the script of STEP 3, most things will be already familiar! (the explanation will not be repeated here)

The script looks like this (you should edit variables to match your environment).

$credential = Get-Credential
$sqlname = 'sqlbtsDemoLive'
$AG = 'BizTalkAFLive'
$vnet = 'BizTalkVNLive'
$adminusername = 'codit'
$mySQLDNS = New-AzureDNS -Name 'sqldnsLive' -IPAddress '10.0.0.4'
$vmname = $sqlname
$image = '2cdc6229df6344129ee553dd3499f0d3__BizTalk-Server-2013-Evaluation'
$sqlservice = $sqlname
$restart = 'false'
					
#Create the SQL Server Virtual Machine																																																																																																																$password = 'Codit*1234'
$mysql = New-AzureVMConfig -name $vmname -InstanceSize 'Small' -ImageName $image | Add-AzureProvisioningConfig -Windows -Password $password -AdminUsername $adminusername | Set-AzureSubnet -SubnetNames 'Subnet-1'
 New-AzureVM -ServiceName $sqlservice -AffinityGroup $AG -VMs $mysql -DnsSettings $mySQLDNS -VNetName $vnet
WaitStartVM $sqlservice $vmname $restart

#Get the remote PowerShell URI
$cmduri = Get-AzureWinRMUri -ServiceName $sqlservice -Name $vmname
InstallWinRMCert $sqlservice $vmname

#Add the SQL Server Virtual Machine to the domain we created in STEP 3
Invoke-Command -ConnectionUri $cmduri.ToString() -Credential $credential -ScriptBlock {
$domain = "BTS2013.com"
$password = <password> | ConvertTo-SecureString -asPlainText -Force
$username = "$BTS2013\Codit" 
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Add-Computer -DomainName $domain -Credential $credential
}
#Restart for domain join
$restart = 'true'
WaitStartVM $sqlservice $vmname $restart

#Set firewall rule and disable services we don't use (save resources)
#Enable MSDTC network access
Invoke-Command -ConnectionUri $cmduri.ToString() -Credential $credential -ScriptBlock {
Import-Module NetSecurity
Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -enabled True

Set-Service -Name 'ReportServer' -StartupType manual
Set-Service -Name 'MSSQLServerOLAPService' -StartupType manual
Set-Service -Name 'MsDtsServer110' -StartupType manual
Set-Service -Name 'SQLServerAgent' -StartupType automatic
Stop-Service -Name 'ReportServer'
Stop-Service -Name 'MSSQLServerOLAPService'
Stop-Service -Name 'MsDtsServer110'
Start-Service -Name 'SQLServerAgent'
#MSDTC settings!
Set-DtcNetworkSetting -DtcName Local -InboundTransactionsEnabled 1 -OutboundTransactionsEnabled 1 -RemoteAdministrationAccessEnabled 1 -RemoteClientAccessEnabled 1 -AuthenticationLevel NoAuth -Confirm:$false
}

#Open SQL Ports in the Windows Firewall (closed by default)
Invoke-Command -ConnectionUri $cmduri.ToString() -Credential $credential -ScriptBlock {
Import-Module NetSecurity
$GroupName = "BizTalk 2013"
$SQLPortLocal = 1433
$SQLBrowserPort = 1434 
$RSQL = New-NetFirewallRule -DisplayName "SQL Server Communication (TCP-In)" -Description "This rule opens the SQL Server communication port $($SQLLocalPort) to the IP Address $($WFEIPAddress) for SharePoint 2013 communication" -Direction Inbound -LocalPort $SQLPortLocal -Group $GroupName -Protocol TCP -Profile Domain -Action Allow -RemoteAddress Any
Write-Host "$($RSQL.DisplayName) created: " -nonewline; Write-Host -foregroundcolor green "$($RSQL.PrimaryStatus)"

#Rule for SQL Browser - UDP Port 1434 Inbound
$RSQLBROWSER = New-NetFirewallRule -DisplayName "SQL Server Browser (UDP-In)" -Description "This rule opens the SQL Server Browser UDP port $($SQLBrowserPort) to the IP Address $($WFEIPAddress)" -Direction Inbound -LocalPort $SQLBrowserPort -Group $GroupName -Protocol UDP -Profile Domain -Action Allow -RemoteAddress Any
Write-Host "$($RSQLBROWSER.DisplayName) created: " -nonewline; Write-Host -foregroundcolor green "$($RSQLBROWSER.PrimaryStatus)"
}

Let’s go over the steps executed in the script above (I will only explain new things):

Line 6: DNS Server: The DNS Server that will be used by SQL Server should be the IP address of the domain controller we set up in STEP 3.

Line 8: Note that even for a SQL Server Virtual Machine we are using the BizTalk Evaluation Gallery Image. The reason for this is, at the point of writing this post, there is no SQL Server Evaluation Image available. The BizTalk Evaluation Image also contains a SQL Server Evaluation.

Line 21 to 28: We add our newly created SQL Server Virtual Machine to the BTS2013 domain we created in STEP 3.

Line 30 to 21: After joining the domain, we have to reboot our SQL Server.

Line 35 to 49: We configure the services start-up types, and stop any service we don’t need on our SQL Server.

Line 51 to 62: We open Windows Firewall to allow BizTalk Server to connect with SQL Server. SQL Server ports are closed by default on the Windows Azure Gallery Image we are using.

When the script of STEP 4 executed successfully, you will have an operational SQL Server in the Virtual Network created in STEP 2.

 

STEP 5 – Create BizTalk Server

In this step, we will run a PowerShell script that will create our BizTalk Server 2013 Virtual Machine.

After analyzing the script of STEP 3 and 4, most things will be already familiar! (the explanation will not be repeated here)

The script looks like this (you should edit variables to match your environment).

#Variables
$btsname = 'bts2013DemoLive'
$AG = 'BizTalkAFLive'
$vnet = 'BizTalkVNLive'
$credential = Get-Credential
$adminusername = 'codit'
$mybtsDNS = New-AzureDNS -Name 'btsdnsLive' -IPAddress '10.0.0.4'
$vmname = $btsname
$image = '2cdc6229df6344129ee553dd3499f0d3__BizTalk-Server-2013-Evaluation'
$btsservice = $btsname
			
#Create the BizTalk Virtual Machine																																																																																																																																						$password = 'Codit*1234'
$restart = 'false'
$mybts = New-AzureVMConfig -name $vmname -InstanceSize 'Small' -ImageName $image | Add-AzureProvisioningConfig -Windows -Password $password -AdminUsername $adminusername | Set-AzureSubnet -SubnetNames 'Subnet-1'
 New-AzureVM -ServiceName $btsservice -AffinityGroup $AG -VMs $mybts -DnsSettings $mybtsDNS -VNetName $vnet
WaitStartVM $btsservice $vmname $restart

#Get URI for remote PowerShell
$cmduri = Get-AzureWinRMUri -ServiceName $btsservice -Name $vmname
InstallWinRMCert $btsservice $vmname

#Add Domain Controller Windows feature
Invoke-Command -ConnectionUri $cmduri.ToString() -Credential $credential -ScriptBlock {
$domain = "BTS2013.com"
$password = <password> | ConvertTo-SecureString -asPlainText -Force
$username = "$BTS2013\Codit" 
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Add-Computer -DomainName $domain -Credential $credential
}

#Restart for domain join
$restart = 'true'
WaitStartVM  $btsservice $vmname $true

#Set firewall rules, Stop all SQL Services and set to manual start-up type, enable network access for MSDTC
Invoke-Command -ConnectionUri $cmduri.ToString() -Credential $credential -ScriptBlock {
Import-Module NetSecurity
Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -enabled True

Set-Service -Name 'SQLWriter' -StartupType manual
Set-Service -Name 'ReportServer' -StartupType manual
Set-Service -Name 'MSSQLServerOLAPService' -StartupType manual
Set-Service -Name 'MSSQLServer' -StartupType manual
Set-Service -Name 'MSSQLFDLauncher' -StartupType manual
Set-Service -Name 'MsDtsServer110' -StartupType manual
Stop-Service -Name 'ReportServer'
Stop-Service -Name 'SQLWriter'
Stop-Service -Name 'MSSQLServerOLAPService'
Stop-Service -Name 'MSSQLFDLauncher'
Stop-Service -Name 'MsDtsServer110'
Stop-Service -Name 'MSSQLServer'

#MSDTC settings!
Set-DtcNetworkSetting -DtcName Local -InboundTransactionsEnabled 1 -OutboundTransactionsEnabled 1 -RemoteAdministrationAccessEnabled 1 -RemoteClientAccessEnabled 1 -AuthenticationLevel NoAuth -Confirm:$false
}

WaitStartVM  $btsservice $vmname $true

Line 40 to 51: I stop all services related to SQL Server. In STEP 4 we set up a separate machine for SQL Server, we don’t need SQL on the BizTalk machines. Also the start-up types are set to manual.

 

When the script of STEP 5 executed successfully, you will have an operational BizTalk Server 2013 in the Virtual Network created in STEP 2.

Let’s now verify that all our machines our up-and-running in Windows Azure.

Navigate to the ‘Virtual Machines’ node. In the screenshot below you can see that the domain controller, SQL Server and BizTalk Server are provisioned and running.

image

Click on the ‘Virtual Network’ node, and navigate to the network that was created prior in this post.

As you can see, our 3 new virtual machines are added in the ‘biztalkvnlive’ Virtual Network.

image

 

STEP 6 – Configure BizTalk Server

The BizTalk Server Gallery images in Windows Azure provide us with a new tool to configure BizTalk.

The Provisioning Tool allows you to configure a complete BizTalk group (multiple servers) at once. You run the Provisioning Tool on one server, all other servers will get their configuration via the tool!

Unfortunately, at this point in time, the Provisioning Tool does not support Active Directory groups yet, so we can’t use it in this situation.

 

To configure BizTalk in this case, I will run the BizTalk ‘Configuration.exe’ as a command line tool. The configuration is set by providing an Xml file as a parameter. The Xml file contains the BizTalk configuration.

To run the configuration, execute this command:

configuration /s c:\BTSConfig\btsconfigExport.xml /l c:\BTSConfig\log.txt

The first parameter is the configuration as Xml, the second parameter is the log file to use where possible errors are written to.

After executing the command above, BizTalk will start its configuration:

image

 

STEP 7 – Deploy BizTalk test application

STEP 7 will not be detailed in this blog post. Just create a small BizTalk application that is capable of picking up a file at a certain location and write it to an output folder.

STEP 8 – Network connectivity – Certificates

In this step, I will setup network connectivity between the Windows Azure Virtual Network and my local laptop.

We want this connection to be secure,  because of that, we will need to generate a public/private key pair to secure the connection.

First we will generate a self-signed root certificate. This certificate will be used to generate client certificates for every device that needs to connect to the cloud network.

Certificates can be generated with the ‘makecert’ tool.

To create the root certificate, execute this command:

makecert -sky exchange -r -n "CN=BizTalkVNLiveRoot" –pe -a sha1 -len 2048 -ss My

 

Next, I will generate a client certificate from the root certificate that is just created. The client certificate will serve to identify my client computer to the cloud. The root certificate will be used to validate my client certificate in the cloud.

To create a client certificate from the root certificate, execute this command:

makecert -n "CN=BizTalkVNLiveClient" -pe -sky exchange -m 96 -ss My -in "BizTalkVNLiveRoot" -is my -a sha1

Install the client certificate on your local computer by double clicking the ‘.pfx’ file. Follow the instructions.

Export the root certificate to a .cer file (from the Windows Certificate store).

 

Now we have to tell our Windows Azure Virtual Network what client certificates are trusted to connect to the Virtual Network.

To do this, browse to the Virtual Network that was created in STEP 2.

The follow screen should be visible:

image

 

Click the ‘Upload client certificate’ link. The caption of this link is not correct! We will NOT upload the client certificate. We upload the root certificate that is able to issue client certificates.

 

STEP 9 - Network connectivity – VPN package

After uploading the certificate in the previous step, there is no more error on our Virtual Network:

 

image

Next we will prepare our client laptop to connect to the Virtual Network in Windows Azure.

Download and install the Client VPN Package that matches your machines hardware architecture. The download link to the VPN package is displayed on the bottom right of the screenshot above.

When the Client VPN Package is installed, go to you network settings.

The Virtual Network will have a separate entry in the network list:

image

 

Right click the ‘BizTalkVNLive’ network and click ‘Connect’. You will now connect your laptop with the Virtual Network in Windows Azure.

 

STEP 10 – Verification

In this step, test network connectivity between your client laptop and the Virtual Network by ‘pinging’ BizTalk Server.

When this works, you can add a receive location to the test application that you created earlier. Let this receive location pick-up a file from your local laptop over the Point-To-Site Virtual Network that is connected.

 

 

Peter Borremans

Categories: Azure
written by: Peter Borremans
3 comments

Posted on Thursday, November 25, 2010 7:24 PM

Sam Vanhoutte by Sam Vanhoutte

Hosting BizTalk Server on Azure VM Role

Another great announcement on PDC was the Virtual Machine Role feature.  This feature is added to Azure with the primary goal to move existing applications to the cloud. 

The feature allows us to upload our own VHD (virtual hard disk) with the Operating System on it (Windows 2008 R2 Enterprise).  This machine could have your application pre-packaged and installed.  After doing this, you are now able to spin up multiple instances of that machine.

BizTalk on VM Role?

Being a BizTalk Server architect that is highly interested in the Azure platform, I immediately thought about a scenario where I could have my own BizTalk Server in the cloud, on Azure.  But, knowing some of the limitations of the Azure platform, I knew I would have a lot of potential issues. 

I listed these issues and added the various workaround or solutions for it.  This post is a post, based on the PDC information and can contain incorrect information.  Consider it as some early thinking and considerations.

No MSDTC support with SQL Azure

  • Problem description
    • BizTalk Server relies heavily on SQL Server and uses MSDTC to keep transactional state across databases and with the adapters.
    • SQL Azure does not support distributed transactions and also introduces more latency to the database queries.
  • Solution
    • SQL Server will need to be installed on the VHD image locally
  • Consequences
    • It won’t be possible to build a multi-machine BizTalk Server Group through the VM role.

The OS image is not durable

  • Problem description
    • All changes that are being made after a Virtual Machine instance is started will be lost, once the instance shuts down or fails over.  (there is only one VHD, but multiple instances are possible –> concurrency issues)
    • This means all database state (configuration, tracking, process state) will be lost if an instance fails.
  • Consequences
    • It won’t be possible to have a stateful BizTalk Server configured or to host long running processes on a VM Role BizTalk Server
    • We will need to expose BizTalk Server capabilities as services to a stateful engine (Workflow?)

The Virtual Machine name will be assigned by the Windows Azure fabric controller

  • Problem description
    • Since it is possible to have multiple instances of a VM running, these instances will get a specific Computer Name assigned by the Azure Fabric controller. 
    • It is very hard to change the computer name of a BizTalk Server machine
  • Solution
    • We will need to automate the BizTalk Server configuration, using a Silent Install, once the VM is initiating.
  • Consequences
    • One of the biggest painpoints in setting up BizTalk Server in a VM role will be to configure the BizTalk Server instance on the fly as a startup task.
    • Starting / restarting a BizTalk VM Role instance will take a considerable amount of time

Licenses are needed

  • Problem description
    • BizTalk Server and SQL Server licenses are needed for each instance that is running
  • Solution
    • Since everything will be installed on a single box, we could use a standard edition of BizTalk & SQL
  • Consequences
    • There is no big pricing advantage, except for the operational cost
    • Only 5 applications will be supported , when using the standard edition

General conclusion

If we succeed in setting up BizTalk Server on VM Role at all, it will be a BizTalk Server with the following limitations:

  • No support for long running transactions
  • Single box machine
  • Stateless BizTalk box

Considering that integration as a service is on the roadmap of Microsoft (see session at PDC), we should only consider it as a temporary solution to have BizTalk Server configured on a VM Role.  If we do this, then we should just see it as a BizTalk Server that exposes its various ‘short running / isolated’ capabilities as a service.  (flat file parsing, transformation, pub/sub, connectivity, EDI)

Sam Vanhoutte, Codit

Categories: Azure
written by: Sam Vanhoutte
1 comment