Azure : Create an URL Rewrite Azure Web App

Azure Web apps provide a rapid and easy way to deploy web applications and publish them on Internet or attach them to your Azure virtual network, so they can be accessed by users.

In this post i will detail how to create an Azure Web app which the purpose is to make URL Rewrites.

Example :

• I have an URL (https://complexURL.samirfarhat.com/dsf5ds4f54sdf54dsf7ds5s7df87fds4qs5d7q7sd57qs687q6f54qfq) which i want to distribute among users so they can access it
• The URL is too long, and users will have difficulties memorizing this URL. The aim is to use a simplest URL (https://SimpleURL.samirfarhat.com) which will be communicated to users. And we want that some mechanism redirect this URL to the desired target URL.
• Using DNS CNAM is not possible since we cannot create a CNAME for a composed URL

–> The solution is to use an URL rewrite solution, which will redirect the simple URL to the composed URL. We can achieve this using an Azure Web app.

The following are the steps which will be conducted during this walk-through:

1. Create an Azure Web app
2. Configure the Azure Web app
3. Create the URL Rewrite Configuration file
4. Upload the configuration file to the Azure Web app
5. Create a Public CNAM DNS record which redirect the Simple URL to the Azure Web App URL

1- Create an Azure Web app

Connect to the Azure portal and sign in using a subscription Admin account

NB : I’m using the Azure preview portal but the classic portal can be used too.

Go to New + –> Web + Mobile –> Web App

The Web app creation wizard will show

 

Type the following information :

Param	Description	Example value
Web app	A suffix for the Web App public URL. This will compose be the Public URL Name for this web app. It will be appended to ‘.azurewebistes.net’, so choose a significant suffix. This suffix is public, that means, you may enter a suffix which is already used by another customer. I recommend including your enterprise name within the suffix since it’s hard that someone else used it. The CNAM  that will be configured later will resolve to  this Public URL	Suffix : MyAzureURLrewrite Public URL : MyAzureURLrewrite.azurewebsites.net
Subscription	Choose the Subscription where to place this Web app	France LAB – SAMIR FARHAT
Resource Group	Choose and Existent Resource Group or Create a new Resource Group for this Web app	MyAzureURLrewriteRG

Now, click on App Service Plan

 

You can create a new Service Plan or use an existent Service Plan

To simplify the description, a Service Plan defines the properties of the underlying compute resources that hold your Web App. Consider the service plans  as different machines with different performances level. A service plan can host one or more Web apps (just like a machine can hold one or more IIS websites)

If you decide to create a new Service Plan, click Create New

Type the Flowing Information

Param	Description	Example value
App Service plan	Choose a name for your service plan	MyBasicPlan
Location	Choose a location where to place this Service Plan (This where the Web App will be hosted too)	North Europe
Pricing Tier	This allow you to choose between the different tiers. You can look here (Azure Service Plans tiers Pricing) for more information about the Service Plan tiers NB: You can upgrade from one tier to another when needed	B1 Basic

Now, you can click on Create. You web app will start deploying.

2- First Configuration steps for the Web App

Go to Browse ALL –> Web Apps and select the Created Web App

2.1- Verify that the Web App is published

Click on the Web App URL. You will be redirected to the Web App. A page with the ‘This web app has been successfully created‘ should appear.

2.2- Add custom domain and SSL Certificate

Because you will not use the MyAzureurlrewrite.azurewebsites.net in the real life, and use instead, a custom URL containing your domain prefix (samirfarhat.com), we should declare which domains will be targeted on this Web app and which SSL Certificate will be used.

Go to All settings –> Custom domains and SSL

 

2.2.1- Add an External domain

Click on Bring External Domains

Add your domains prefixes. Example : samirfarhat.com

NB : As mentioned on the wizard, Azure must verify that you are the owner of this domain name. So you should create a CNAME in a public DNS provider that match your domain to the the Web app public URL (SimpleURL.samirfarhat.com –> MyAzureURLrewrite.azurewebsites.net or awverify.samirfarhat.com –> MyAzureURLrewrite.azurewebsites.net)

2.2.2- Add the SSL certificate for the domain

Now that you successfully added your domains to the Web app configuration, you should bind a certificate which will secure your website when it’s accessed via URLs which contains your domain name.

Example:

In our case, we want to redirect https://SimpleURL.samirfarhat.com to this Web App (http://myazureurlrewrite.azurewebsites.net/). So the user accessing this web app will tape https://SimpleURL.samirfarhat.com in the browser. The certificate have to match the the requested URL, that means SimpleURL.samirfarhat.com

Click on Upload Certificate and upload a Certificate that match your requested URL. The certificate must be of the PFX format (with the Private Key)

NB : If you will use this Web app as a redirect service for many URLs, this web App will receive requests on many names (https://SimpleURL.samirfarhat.com, https://Thehall.samirfarhat.com , https://SSJ.samirfarhat.com…), so to avoid uploading many certificates, you can use a wildcard certificate *.domain.com (*.samirfarhat.com)

2.3- Setup the FTP parameters

Now, we need to configure the FTP user credentials in order to be able to connect (using FTP or GIT) to the Web App content.

Go to All settings –> Deployment Credentials

Param	Description	Example value
FTP/deployment user name	Type the User Name you would use. The user name can contain only letters numbers, hyphens and underscores, and must start with a letter.	samirfarhat
Password	Type a complex password	**************
Confirm password	Retype the password	*************

3- Configure the URL rewrite

After completing the previous steps, we can configure the URL rewrite service. The following steps will be conducted:

1. Prepare the redirection configuration file
2. Upload it to the Web application

3.1- Prepare the redirection configuration file

Download the following file (Web.config)

• Open it with a text editor (Notepad or Notepad++)

• Change the following information :

Param	Description	Example value
name	Type an identification name for this URL to be redirected	SimpleURL
url	Type the URL of the application to which you want make redirect (the composed URL)	https://complexURL.samirfarhat.com/dsf5ds4f54sdf54dsf7ds5s7df87fds4qs5d7q7sd57qs687q6f54qfq
pattern	Type the URL on which the Web app will receive the request, the simple URL (You must respect the format, a ‘.’ is replaced by ‘\.’)	SimpleURL\.samirfarhat\.com

• Save the file and keep the same name (web.config)

NB: If you have more than one URL to redirect, just add a new rule to the same file, by copying/pasting the Rule ‘section’

3.2- Upload the configuration file to the Web App

We will use FTP to connect and upload files to the Web app.

You can use the Windows Explorer or a FTP client like Filezilla (Download Filezilla)

In my Example i will use the Windows Explorer.

• On the Web App blade, locate the FTP hostname and copy thr URL (You can use the copy shortcut)

• Open a Windows Explorer window and paste the copied URL. You will be prompted for the FTP credentials. Enter the credentials you already configured on the previous steps.

• Go to site/wwwroot/ and paste the web.config file

• You successfully created an URL rewrite Web app on Azure

NB: You may have to restart the Web App

4- Create the Public DNS CNAM record

This is the final step, you should now create a public DNS record which will redirect the desired URL (https://SimpleURL.samirfarhat.com) to the Azure Web app URL (myazureurlrewrite.azurewebsites.net)

Annex

The following is the content of the web config file.

<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name=”SimpleURL” patternSyntax=”ECMAScript” stopProcessing=”true”>
<match url=”(.*)” />
<action type=”Redirect” url=”https://complexURL.samirfarhat.com/dsf5ds4f54sdf54dsf7ds5s7df87fds4qs5d7q7sd57qs687q6f54qfq” appendQueryString=”false” redirectType=”Permanent” />
<conditions>
<add input=”{HTTP_HOST}” pattern=”SimpleURL\.samirfarhat\.com” />
</conditions>
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>

Migration paths from VMware to Microsoft Azure (Classic and ARM)

Hi all,

This page describes and presents the different approaches that an enterprise can think about when deciding to Migrate workloads from on-premise VMware platform to Azure. This page is a high level description where the different concepts will be explained, and a comparison will be conducted.

NB : This post also includes the possible actions (when applicable) to make in order to migrate the workloads to the Azure Resource Manager stack (IaaS V2)

1- What are the migration paths

There are many migration paths which can be used, but each one have it’s own advantages and disadvantages. The following table shows the different paths that will be discussed in this article:

• Extend the application roles to Azure
• Manual upload of the Virtual Machine’s virtual hard disks to Azure
• Use MVMC (Microsoft Virtual Machine Converter)
• Use Azure Site Recovery

2- Migration paths description

In this section, the different migration paths presented on 1- What are the migration paths. will be detailed, and the advantages and disadvantages of each one will be presented.

2.1- Extend the application roles to Azure

2.1.1- Description

This this the first path that can be took to migrate workloads to Azure. It depends on the application itself, and it’s not related to the OS underlying stack (Physical, Virtual, VMware or Hyper-V…).

This approach is only possible for application and workloads that supports high Availability or Load Balancing over multiple instances, and usually does not require using third party tools.

Example:

Active Directory Domain Services : If you have one domain controller, you can add an additional domain controller to your topology. This way, users or resources using these DCs can authenticate on either the first or the second DC. The migration path will be the following .

1. Add a second domain controller on Azure
2. Verify that users, servers and the other resources can successfully authenticate using the domain controller on Azure
3. Transfer the FSMO roles to the Azure DC
4. Stop the on-premise DC

–> This way, you migrated the ADDS infrastructure to Azure, in a transparent way, with zero downtime.

The following are the general steps that can be followed for any application that supports extending:

1. Create 1 or more virtual machines in Azure. These VMs will hold the application roles that will be extended. The OS and VM configuration depends on the application.
2. Extend the application role to the (or more) virtual machine in Azure
3. Verify that the new server in Azure is operational and can handle the application services and requests. (A test plan should be run)
4. Plan a transition step to ‘cut’ the on-premise server. This way, only Azure servers are requesting the application services.

The following ‘services’ can generally support this migration path:

Service	How
Web services (IIS, Apache…)	The Web services generally support Load Balancing. Extending a Web service farm is usually supported.
Clustered services	Generally, any service which supports clustering (SQL Server, DHCP, Hadoop…) can use this migration path.
Multi-instances roles	They generally requested via a ‘weight’ or ‘priority’ mechanism. We can mention as examples: Domain Controllers, DNS servers…0

2.1.2- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:

Pro	Cons
Does not require resort to third-party tools Zero or near-zero downtime Fast and guaranteed rollback	Different extension method for each type application Need specialized people, for each product to be extended Change of the application configuration Not applicable for standalone applications

2.2- Manual upload of the Virtual Machine’s virtual hard disks to Azure

2.2.1- Description

This this the second path that can be took to migrate workloads to Azure. This time, it doesn’t depend on the application.

This approach is applicable for both virtual and physical servers. And may need prerequisites prior to start the migration itself.

The next paragraph describes the different steps to successfully migrate workloads using this method:

Physical servers

1. The physical server disks should be converted to the VHD format. There are two possible manners to do it :
   1. Use Disk2VHD : This tool can make an online conversion of physical server’s disks to  VHD files format. The obtained VHDs are a consistent point-in-time snapshots of the converted volumes. (Only for Windows supported operating systems, Linux operating systems are not supported)
   2. Convert the whole Physical server to a virtual machine. There are two ways to finally obtain the desired VHD format
      1. If your target virtualization stack is VMWare :
         1. You can use VMware vCenter Converter. This tool will allow the P2V (Physical to Virtual)  conversion of you physical server to a VMWare virtual machine.
         2. You should convert your VMDK disks to the VHD format. This can be done via several ways :
            • If you have a Hyper-V virtualization platform: You can make a V2V conversion of the VMware virtual machines to Hyper-V virtual machines. That way, you will obtain the desired VHD format. The following blog (Link1, Link2) describes the way to convert VMWare VMs to Hyper-V VMs
            • You can convert directly VMDK virtual hard disks to the VHD format using conversion tools like MVMC (Link1, Link2) or third-party tools like Starwind V2V converter (Link1). But i recommend using MVMC
      2. If your target virtualization stack is Hyper-V : Use MVMC to make a P2V conversion toward a a Hyper-V server (Only for Windows supported operating systems, Linux operating systems are not supported). Choose the VHD format for the disks type.
2. Upload the machine VHD files to Azure. The best two options to use:
   1. For fixed VHD files format : Use AzCopy
   2. For  dynamic or fixed VHD files format : Use Add-AzureVHD powershell command. Follow this blog to optimize the usage of this tool
3. Creation of the virtual machine using the uploaded virtual hard disks : Use the Provisioning script to create a virtual machine from an existing virtual hard disk.

Virtual machines

1. The goal is to obtain the virtual machines disks under VHD format
   1. If your virtualization stack is VMWare: You should convert your VMDK disks to the VHD format. This can be done via several ways :
      1. If you have a Hyper-V virtualization platform: You can make a V2V conversion of the VMware virtual machines to Hyper-V virtual machines. That way, you will obtain the desired VHD format. The following blog (Link1, Link2) describes the way to convert VMWare VMs to Hyper-V VMs
      2. You can convert directly VMDK virtual hard disks to the VHD format using conversion tools like MVMC (Link1, Link2) or third-party tools like Starwind V2V converter (Link1). But i recommend using MVMC
   2. If your virtualization stack is Hyper-V : Hyper-V supports 2 formats : VHD and VHDx
      1. If your virtual machines disks format are VHDx : You should convert the VHDx files to VHD. For that you can the powershell command Convert-VHD
      2. If your virtual machines disks format are VHD : No steps to be done
2. Upload the machine VHD files to Azure. The best two options to use:
   1. For  fixed VHD files format : Use AzCopy
   2. For  dynamic or fixed VHD files format : Use Add-AzureVHD powershell command. Follow this blog to optimize the usage of this tool
3. Create a  virtual machine using the uploaded virtual hard disks : Use the Provisioning script to create a virtual machine from an existing virtual hard disk.

2.2.2- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:

Pro	Cons
Does not require a change to the application configuration Does not require application experts Fast and guaranteed rollback Applicable for standalone workloads	May take long time (Conversion + Upload = Hours) Require server downtime (hours) Several prerequisites Manual process Not  supported for all Operating Systems

2.3- Use Microsoft Virtual Machine Converter (MVMC)

2.3.1- Description

This this the third path that can be took to migrate workloads to Azure.

This approach is applicable only for virtual machines residing on supported VMWare hosts (ESX/VSphere/VCenter)

The next paragraph describes the different steps to successfully migrate workloads using this method:

NB : Because the current version of MVMC (3.1) does not support Azure Resource Manager storage containers, extra steps will be conducted to successfully make the migration. These steps will be marked with green color.

1. Install the MVMC tool on a server which ‘preferably’ belongs to the same network as the VCenter server. The following details the installation prerequisites (Link1). You can download MVMC from the following link (Link2)
2. Make the following steps as prerequisites to use MVMC to migrate VMWare VMs to Azure. The most important step is to upload a management certificate to Azure (Link1)
3. Create a classic (V1 Azure Service Management) storage account where the VHDs will be uploaded. This storage account will be used as an intermediate during the migration
4. There are two options which can be used to convert VMWare virtual machines : Using the MVMC graphical wizard, or use the MVMC cmdlets.
   1. Use the MVMC GUI : Follow this link and follow the steps to connect to a VCenter/ESX server and convert/upload  VMware Virtual machine VHDs to the already created storage account in step 3 (VMWare to Azure using MVMC GUI)
   2. Use the MVMC cmdlets : The following document contains a sample script which can be used to convert and migrate  VMware virtual machines to Azure. Download the MVMC_cmdlets.doc from the following link (MVMC_cmdlets.doc)
5. Move the uploaded virtual hard disks from the temporary classic storage account (created on step 3) to the target storage account (ARM) where the virtual machine storage should reside. The move can be easily done via few steps using the Start-AzureStorageBlabCopy Azure powershell command. Use the ‘Initiating an Asynchronous Copy Request (authenticated source)‘ section (Copy VHDs between Azure BLOBs). You should install Azure Powershell as a prerequisite (Downland Azure Powershell)
6. Create a  virtual machine using the uploaded virtual hard disks : Use the Provisioning script to create a virtual machine from an existing virtual hard disk.
7. Delete the VHDs residing on the classic storage account

NB: MVMC can be used with MAT (Microsoft Automation Toolkit) to make bulk conversion operations. Look the Microsoft Automation Toolkit section on this page (MVMC with MAT)

2.3.2- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:

Pro	Cons
Does not require a change to the application configuration Does not require application experts Fast and guaranteed rollback Applicable for standalone workloads Optimal for low scale migration	May take long time (Conversion + Upload = Hours) May require server downtime (hours) Extra steps  due to lack of  ARM storage accounts support Manual process (though can be automated) Not optimal for an Enterprise migration path

 

2.4- Use Azure Site Recovery

2.4.1- Description

This this the fourth path that can be took to migrate workloads to Azure.

This approach is applicable only for virtual machines residing on supported VMWare hosts (ESX/VSphere/VCenter), and for physical servers.

This method is the most complicated method deploy, but once deployed, it will me a one-click solution to easly migrate workloads to Azure.

NB : Azure Site Recovery  does not currently support Azure Resource Manager, hence it will not be possible to use it with Azure IaaS V2. In the meanwhile, the same steps are applicable when it will be supported in few months (Mid Q4 2015)

In this description, i will highlight the necessary steps to use Azure Site Recovery as a migration solution from VMWare to Azure (But the same steps apply to Hyper-V/Physical). For a detailed explanation, you can refer the Microsoft official documentation (Migrate VMWare to Azure using Azure Site Recovery)

2.4.1.1- What is ASR and what are its components

ASR is an Azure Service which can be used to migrate/protect different kind of workloads from a source site to a target site. For a complete list of Sources and Targets, visit this page : Azure Site Recovery Overview

The following pictures shows the components involved on a ASR protection/Migration of workloads to Azure.

(Image Credit  : Microsoft)

The following components should be used and installed on-premise and on Azure in order to enable workloads protection (Table copied from Migrate VMWare to Azure using Azure Site Recovery)

Component	Deployment	Details
Configuration server	Deploy as a Azure standard A3 virtual machine in the same subscription as Site Recovery. You set up in the Site Recovery portal	This server coordinates communication between protected machines, the process server, and master target servers in Azure. It sets up replication and coordinates recovery in Azure when failover occurs.
Master target server	Deploy as Azure virtual machine — Either a Windows server based on a Windows Server 2012 R2 gallery image (to protect Windows machines) or as a Linux server based on a OpenLogic CentOS 6.6 gallery image (to protect Linux machines). Three sizing options are available – Standard A4, Standard D14 and Standard DS4. The server is connected to the same Azure network as the configuration server. You set up in the Site Recovery portal	It receives and retains replicated data from your protected machines using attached VHDs created on blob storage in your Azure storage account. Select Standard DS4 specifically for configuring protection for workloads requiring consistent high performance and low latency using Premium Storage Account.
Process server	Deploy as an on-premises virtual or physical server running Windows Server 2012 R2 We recommend it’s placed on the same network and LAN segment as the machines that you want to protect, but it can run on a different network as long as protected machines have L3 network visibility to it. You set it up and register it to the configuration server in the Site Recovery portal.	Protected machines send replication data to the on-premises process server. It has a disk-based cache to cache replication data that it receives. It performs a number of actions on that data. It optimizes data by caching, compressing, and encrypting it before sending it on to the master target server. It handles push installation of the Mobility Service. It performs automatic discovery of VMware virtual machines.
On-premises machines	On-premises virtual machines running on a VMware hypervisor, or physical servers running Windows or Linux.	You set up replication settings that apply to virtual machines and servers. You can fail over an individual machine or more commonly, as part of a recovery plan containing multiple virtual machines that fail over together.
Mobility service	Installs on each virtual machine or physical server you want to protect Can be installed manually or pushed and installed automatically by the process server when protection is enabled for the server.	The Mobility service send data to the Process Server as part of initial replication (resync.) Once the server reaches a protected state(after resync is completed) the Mobility service performs an in-memory capture of writes to disk and sends it to the Process Server. Application consistency for Windows servers is achieved using the VSS framework.
Azure Site Recovery vault	Set up after you’ve subscribed to the Site Recovery service.	You register servers in a Site Recovery vault. The vault coordinates and orchestrates data replication, failover, and recovery between your on-premises site and Azure.
Replication mechanism	Over the Internet—Communicates and replicates data from protected on-premises servers and Azure using a secure SSL/TLS communication channel over a public internet connection. This is the default option. VPN/ExpressRoute—Communicates and replicates data between on-premises servers and Azure over a VPN connection. You’ll need to set up a site-to-site VPN or an ExpressRoute connection between the on-premises site and your Azure network. You’ll select how you want to replicate during Site Recovery deployment. You can’t change the mechanism after it’s configured without impacting protection on already protected servers.	Neither option requires you to open any inbound network ports on protected machines. All network communication is initiated from the on-p

2.4.1.2- ASR replication mechanism

This section explains how to migrate a  VMware virtual machine to Azure using ASR. I will highlight the high level steps, explaining the End to End process:

(Image Credit  : Microsoft)

A- Create the Azure Site Recovery vault

The first step is to create an Azure Site Recovery vault. A vault is just a container which will be targeted later for your replication mechanism. After creating the vault, a storage account (GRS type) will be created, it will store the replicated data.

B- Set up the configuration server component on Azure

The configuration server is a server residing on your Azure subscription. As explained on  ‘2.3.1.1- What is ASR and what are its components’, the configuration server  coordinates communication between protected machines, the process server, and master target servers in Azure. It sets up replication and coordinates recovery in Azure when failover occurs. An standard A3 virtual machine is recommended for this component. This server should added to the already created vault

C- Set up the Master Target component on Azure
Now, an Azure VM should be created to hold the master target role. Disks will be attached to this VM, and each disk will receive data from its analogue disk on-premise. So if you are migrating a VM with N disks, the VM should support at least N+1 data disks (Be aware that the maximum supported data disks per VM is limited by its size and series, look to Azure Virtual Machine Sizes). If the Master Target VM reaches the maximum data disks count, you can add a second Master Target VM or upgrade the current size to a size which support the data disks count (N+1)

D- Set up the Process Server component on-premise

A server must be created on-premises and hold the Process server component. It’s recommended to create the server on the same network than the ESX infrastructure. This server with be registered with the Configuration server. It’s recommended to install VMWare VSphere CLI 5.5.0

E- Check the components server updates

It’s highly recommended to install the last windows updates on the component servers

F- Create protection groups

On the Azure portal, create a protection group and configure the default replication settings. We will add later the virtual machines to be migrated to this protection group. One protection group can include multiple virtual machines.

G- Set up the replication for the virtual machines

For each VMware virtual machine to protect, the Mobility Service agent will be installed. Then, the VM will be added to the protection group already created. The Properties for the target virtual machine in Azure can be configured (Name, IP…)

H- Planned Failover

After the initial replication completes, we can make a planned failover. A failover plan should be created which will include the failover properties (one or more VMs, order…)

NB: A planned failover will cause downtime. In fact, the source machine is stopped, the delta between hard disks is synchronized to have an exact clone of the source machine.

I- Validate migration

Once the virtual machine is running on Azure, verify its connectivity with on-premise.

2.4.3- Pro and Cons

The following table resumes the Pro and Cons related to this migration path:

Pro	Cons
Does not require a change to the application configuration Does not require application experts Fast and guaranteed rollback Applicable for standalone workloads Enterprise grade solution Minimal downtime Can be used to failback to on-premise Can use VPN, ExpressRoute or Public internet for replication	Need deployment of different components Not free*

* The protection of a virtual machine is free for the first 31 days (The Initial replication and failover time will always be less than 31 days), so the ASR service is considered free for a migration path. However, the Master Target and the process server will use Azure compute and storage resources, which will be accounted on the bill.

3- Migration paths comparison

In this final section, i will present a summary comparison table comparing the different migration options discussed in this post.

Migration path	Cost	Require a migration platform	Scalability	Manual Effort	Downtime	Rollback	Reverse Migration	Depend on the Application
Extend the application to Azure	Free	No	+	+++++	No	N/A	N/A	Yes
Manual upload of VHDs	Free	++*	+	++++	+++++**	Yes/Fast	No	No
MVMC	Free	++	++	+++	+++++**	Yes/Fast	No	No
ASR	++	+++	+++++	+	+	Yes/Fast	No	No

* Only If the source virtual machines are not under the VHD format

** Depends on the data to be uploaded to Azure and on the outbound bandwidth

4- Which migration path to choose

The following table describes my ‘personal’ recomdantions toward which migration path to choose

Migration path	When ?
Extend the application to Azure	Downtime is not permitted Simple to accomplish
Manual upload of VHDs	Long downtime is permitted Few machines to be migrated
MVMC	Long downtime is permitted Few machines to be migrated Minimize manual steps
ASR	Long-term solution (Enterprise soution) Continous machine migration Minimal downtime needed Postpone the migration decision*

* Once the initial replication is completed, you can decide whether or not to failover the virtual machine to Azure. The VM will keep replicating with the on-premise server until you decide to make the failover.

Microsoft is reducing D-Series pricing

Hi all,

A fast flash info, Microsoft is reducing its D-Series prices starting October 1, 2015.

(Picture Credit : Microsoft)

This is good news since the prices are decreasing at a good rate : Around 20 % in north Europe

( Picture Credit : Microsoft) D-Series prices in North Europe Region

This makes using D-Series advantageous since they offer best CPU performances.

I’m really optimist for what coming, since this is the what we expect from the Public Cloud Platforms : Prices should decrease

Azure Active Directory integration with Salesforce Sandbox

The main goal of this blog is to show how to integrate Salesforce Sandbox environment with Azure Active Directory, using the Windows Azure AD single Sign-On configuration option.

Before continuing, you should meet the following requirements:

• A valid Azure Active Directory Subscription
• A Sandbox environment on Salesforce .com with a System Admin user on this environment.

NB: In this blog, i used the ‘.uisandbox’ as a suffix. You should replace it by the suffix attributed to your sandbox platform

1- Why do not use the same integration procedure with Salesforce (non-Sandbox) ?

A question one may ask is why not use the same Azure Active Directory integration procedure with a (non-Sandbox) Salesforce environment (Described here in a Microsoft Article). The reason is simple : When you get a Salesforce Sandbox environment, your Salesforce production user accounts are cloned to  the Salesforce Sandbox environment (Automatically on the refresh process), but a ‘.uisandbox’ suffix is added to the UserName for each user. This is intentional since a user will know that he is using a Sandbox environment and to avoid confusion just by looking to his username. The email address is also modified to a strange format : Example : Samir.Farhat@Ent.com –> Samir.Farhat=Ent.com@example.com. I personally recommend modifying the email address of a user to match its real email address, but it’s not a must. So, the integration procedure for a production SalesForce environment is not valid for the Sandbox one (The users identifiers changed) . A tuning must be brought in order to achieve the integration. This is the blog’s purpose.

NB

There is an Official Microsoft article about configuring salesforce ‘sandbox’ environment with Azure AD, but, it seems that the content is not accurate and you will not be able to successfully configure the integration.

2- How this will work ?

It’s simple. Thanks to the Azure Active Directory new SAML attributes option (Currently In preview) , we will tell Azure Active Directory to add, every time that an authentication is requested, the suffix ‘.uisandbox’ to the UserName claim. Great !

3- Steps for Integrating Salesforce Sandbox environment with Azure Active Directory

3.1- Configure the Salesforce ‘Sandbox’ application on Azure AD

Where : Azure Management portal

A- Deploy the Salesforce sandbox application

First, connect to the Azure Management portal with an Active Directory tenant administrator account. Go to Active Directory –> Domain Name –> Applications and Click on the Add button

Choose Add an application form the gallery

On the Search bar, type salesforce. Choose the Salesforce Sandbox. Type a Display Name for this application (Example : MySalesforceSandbox) and click Okay

Wait for the application to be successful added. Now we can begin configuring our SSO with Azure AD

B- Configure Single Sign-ON

In this phase, we will configure Azure AD to ‘accept’ authentication requests from Salesforce. In other words, we will configure Azure AD as an identity Provider for Salesforce ‘sandbox’.

Click on Configure Single sign-ON

Select ‘Microsoft Azure AD single sign-On’

Type the Sign ON URL. The sign-on URL is the Salesforce ‘custom’ Sandbox domain URL. Go to step ‘3.2.A- Create and switch to a custom domain’ if you are not aware of this information. The URL must begin with https:// and ends with my.salesforce.com

This step is very important, since it contains ‘required information’ for setting up the SAML settings in Salesforce. Keep the following information:

• Download the Certificate in a local location. You can name it ‘AzureADSalesforcesandboxsso.cert’
• Save the following URL to a text file for example (Of course you can retrieve them later)
  • Issuer URL
  • Remote Login URL
  • Remote Logout URL

Click Next

Type an Email address to receive information about SSO events with this application.

This phase is completed, now we will pass to the next step, a very crucial configuration.

C- Change the SAML attributes claims to match the Salesforce ‘Sandbox’ users settings

Go to Attributes (Even if this feature is currently on preview, it works as expected)

The goal is tell Azure AD that the Name it will receive during the SAML handshake, is not the UserName is AzureAD, but it’s a concatenation of the UserName is AzureAD and the ‘.uisandbox’ expression.

For this, we will edit the ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name’ attribute like the following.

Click on the Edit symbol for the ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name’ attribute

Change it like the following:

Attribute Value : Join()

STRING1 : User.userPrincipalName

String2 : uisandbox

Separator : .

Click OK then Click Apply Changes

NB: In my example, I used the Name as a claim attribute, you can use the email address if you want. But, you have to also to change it in the SAML settings configuration on salesforce on Step ‘3.2.B- Create a new SAML SSO settings’

3.2- Configure the Salesforce ‘Sandbox’ SSO on Salesforce

Where : Salesforce Sandbox portal

Go to https://test.salesforce.com and login with a ‘sandbox’ user account (This user must have System Admin rights on this environment). NB: As discussed, The sandbox user account by default ends with .uisandbox

A- Create and switch to a custom domain

First step to do is to switch to the sandbox domain if it’s already created, or create a new domain for your environment (For users not familiar with Salesforce domains, a Salesforce domain is just a domain name to be used when connecting to your Salesforce environment, this will make you use a domain name like ‘MysalesforcedomainName.salesforce.com’ instead of ‘test.salesforce.com’).

Go to Setup –> Domain Management –> Domains

If you did not already  created a domain, create a new one.

Now, go to Setup –> Domain Management –> My Domain and login to your domain by clicking on Click here to login

Once connected, you will be switched to the custom domain

B- Create a new SAML SSO settings

Now, it’s the main part, where we will configure the settings that will allow the SSO to Azure AD and the matching between the user in Azure AD and in the Salesforce ‘sandbox’.

Go to Setup –> Security Controls –> Single Sign-On Settings and click New

You will have to provide the following information:

Setting	Description	Example
Name	A name for your SSO configuration (Will be shown for users so choose a descriptive  Name)	AzureADSSOSandbox
API Name	Used by SalesForce, keep it the same as the Name	AzureADSSOSandbox
Identity Provider Certificate	The Certificate that you bring from the Azure AD SSO configuration (AzureADSSOSalesforce.cert)	AzureADSSOSalesforce.cert
Entity Id	Used by Salesforce, need to set it to https://test.salesforce.com	https://test.salesforce.com
Issuer		Paste here the Issuer URL got from Azure ADD SSO configuration wizard
Request Signing Certificate	Which Certificate to use to sign the request	Default Certificate
Request Signature Method	The method for the Request signing certificate	RSA-SHA1
Assertion Decryption Certificate	If your assertion is encrypted, choose a certificate to decrypt it with. Otherwise, choose Assertion not encrypted	Assertion not encrypted
SAML Identity Type	Which identity type will be used	Assertion contains User’s salesforce.com username
SAML Identity Location	Where the identity is located	Identity is in an Attribute element
Attribute Name	Which attribute will be used. In our configuration, the name will contain the name that will match the user name in Salesforce ‘sandbox’. In fact, we have to set this attribute in Azure AD to add the ‘.uisandbox’ suffix to the user name	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
Name ID Format		leave it blank
Service Provider Initiated Request Binding		HTTP POST
Identity Provider Login URL		Paste here the Identity Provider Login URL copied from the Azure AD SSO config wizard
Identity Provider Logout URL		Paste here the Identity Provider Logout URL copied from the Azure AD SSO config wizard
Custom Error URL		Leave it blank
User Provisioning Enabled	Check this box if you want to enable the User Provisioning feature on Azure AD

C- Enable the SSO settings for the ‘salesforce’ domain

This is the last step in this configuration walkthrough. We have now to enable the configured SSO authentication for the ‘salesforce’ sandbox domain.

Go to Go to Setup –> Domain Management –> Domains

Select your ‘sandbox’ domain and click Edit

Affect the SSO configuration which was created during the previous steps to this domain then click Save

NB

• You can affect more than one SSO configuration to your domain
• If you uncheck the ‘Login page’, users will not be able to use local ‘salesforce’ users to login to the domain

3.3- Test the configuration

Now, we can test our configuration.

First, you must assign users or groups to be be authorized to use this application (to use the Azure AD Authentication).

In Azure AD, go to the Application –> Users and Groups. Choose the ‘All Users’ or ‘Groups’ filter and assign the desired users.

Now connect to the ‘Salesforce’ sandbox URL (sign-on URL ie your Salesforce ‘sandbox’ domain name ). And choose your ‘AzureAD SSO’ that you already configured.

You have successfully logged using SSO to Salesforce ‘sandbox’ environment.