There a three aspects that you may have to deal with when considering LOB sideloading: licensing requirements, technical requirements and management of sideloaded apps. You will want to understand all of them to understand if there is additional cost,  how plan for the best way to enable your devices for sideloading or what are your options for handling new App version updates. Let´s have a look then.

1. Sideloading Licensing Requirements

Sideloading functionality is available “out of the box” for Windows 8.1 Professional and Windows 8.1 Enterprise but only if they are domain-joined. The addition of the Professional edition is new and has been announced as recently as April 2014:

[1] Building the Mobile Workplace with Windows and Windows Phone

"Easier Deployment – Delivering Windows 8.1 Update via Windows Update allows businesses to deploy updates with increased predictability. And, to help businesses develop and deploy modern apps for their workforce, we are enabling sideloading for any domain-joined Windows Pro PC or tablet"

The Windows 8.1 Professional, Windows 8.1 Enterprise that are not domain-joined and the Windows 8.1 RT edition (that cannot be domain-joined) still can be enabled for sideloading but will require a sideloading key that has to be installed and activated on the device. It is a multiple activation key (MAK) and you can obtain it from the reseller.

[2] Volume Licensing reference guide Windows 8.1 and Windows RT 8.1

page 12 and further has a full detail in section “Windows 8.1 Enterprise Sideloading”.

Typically, the sideloading activation key will have to be acquired by to owner of the operating system license. So how much it is going to cost? Well, the thing to check is if you have existing volume licensing Enterprise Agreement with Microsoft. The licensing guide mentioned above lists all of the programs that include them free of charge as of 1 May. If you are in a qualifying licensing program, just contact your reseller who will make the keys available to you.

If you do not have a qualifying volume licensing program then you can purchase from a reseller unlimited number of sideloading activation keys for approx. $100 through the Open contract as also mentioned by [1]. The best thing is to contact the reseller that you normally work with to check out all these options for your particular case.

So in summary, if you are dealing with devices that will not be in domain and you want to install LOB Store App you will need the sideloading activation key. Before you attempt the installation, however, the devices will have to be prepared by your IT pro, so read on.

2. Technical Requirements for Sideloading

There are three technical requirements that have to be met by the device before you attempt to install Store App on it regardless if you are doing it manually, via Powershell scripts or via Mobile Device Management system such as Windows Intune. You will find them explained in

[3] Configure PCs for Sideloading Requirements

but here they are summarized and I illustrate them with screenshots taken on Windows 8.1 Professional with Update 1 that is not domain joined and therefore requires all the steps.

1. Enable the Windows Registry key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1.

If you are dealing with domain joined device you get this key set via group policy Allow all trusted applications to install. If you are preparing a device that will not domain joined you will most likely find out that the Appx in not present in HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows. In that case: a) create a New Key named Appx b) right click the Appx node you just created and select New-> DWORD (32-Bit) Value, assign it a Name AllowAllTrustedApps c)right click the DWORD you just created and select Modify and type 1 in the Value Data. You should have an entry as per figure below:

.

Figure 1. AllowAllTrustedApps Windows Registry Key2. Ensure that the

2. Ensure that the code signing certificate has been issued by a trusted certification authority.

All Store App packages are signed with a code signing certificate. If the developer uses an Authenticode code signing certificate that has been purchased from common certificate authority (e.g.: Symantec, VeriSign) then you do not need to take an action because the root certificates for these authorities are already present in the Local Machine\Trusted Root Certification Authority certificate store. However, if the application package has been signed with the certificate emitted by customers own Certification Authority or the developer used the self-signed certificate generated by Visual Studio then you will have to make sure the root certificate is present in the Trusted Root Certification Authority store.

You can locate the code signing certificate in Visual Studio solution by looking up the application manifest as shown in the figure below

Figure 2. Application Manifest with code signing certificate

Configure Certificate button allows developer to pick existing code signing certificate from the certificate store a file or get Visual Studio to generate a self signed certificate. If you click the View Full Certificate button you can get the full certification path, copy the certificate to a file, etc. When the Store App is packaged (using the Store->Create App Packages option) the code signing certificate will also be available in the AppPackages solution subfolder. So if you are using self-signed certificate you could just pick it up together with the .appxbundle that contains the application package and take both to your target machine.

On the device that you want to configure simply double click the self signed certificate (.cer) file, select Install Certificate and then in the Certificate import Wizard select Local Machine as the Store Location instead of Current User that will be selected. In the next step select Place all certificates in the following store and browse for the Trusted Root Certification Authorities store to get it installed.

Should you install incorrectly then on Windows 8.1 with Update 1 you will get explicit error message (on Windows 8 you may get more cryptic error HRESULT: 0x80073CFF) as per figure below:

Figure 3. Lack of root certificate error

If all is well the command will complete silently and you should be able to locate the application installed. For domain joined machines you would be able to run the app at this stage, however, for cases that require sideloading key you will see the message App can´t open as in the figure below

Figure 4. App can´t open message

This is because we are missing the step 3 described below.

3.  Install and Activate the sideloading key on the devices that require it (as described it in previous section).

There are two commands that we have to execute exactly as described in the “To activate a sideloading product key” section of the sideloading requirements: one to install the key and the second to activate it. You need Administrator privilege to execute these commands as per figures below:

Figure 5. Installation of the sideloading key

Note that the key you type here is the sideloading key that you have purchased from your reseller.

Figure 6. Activation of the key.

In this second step the string supplied (ec67814b….) is always the same because it is a guid that identifies the sideloading feature that we are enabling. If you are unsure if the device has already the sideloading key activated you can check it with command slmgr / dlv that will display the license information. Then scan it for the section with Name: APPXLOB-Client add-on and ensure that the line License Status is showing Licensed.

With all these steps concluded you can install and launch the Store Application successfully.

I should mention for completeness that in development environment you do not require sideloading key. The store apps can run thanks to the Developer License. This license is temporal and periodically will expire. If you are putting in production the machine that was perhaps previously a test machine you can check if it has developer license installed (Get-WindowsDeveloperLicense) and remove it (Unregister-WindowsDeveloperLicense) before configuring production sideloading key using the powershell commands documented in

[4] Windows Developer License Cmdlets in Windows PowerShell

3. Application Management

The licensing requirements and the technical requirements mentioned in the two previous sections have to always be met regardless of the actual method you choose for installing the applications. You have already seen that you can install the application using the Add-AppxPackage command. The command will take an application package (.appx) or the newer application bundle (.appxbundle) as an argument. You can use the Remove-AppxPackage to remove the application.

However, most customers will require more sophisticated solution to manage the application. They will want to assign specific LOB Apps to users in certain groups (Finance, HR) and will want to have a mechanism to install the new versions of the applications even for users with no access to domain.

Windows Intune offers a complete Mobile Device Management solution. It can help not only manage the applications but also (in case of Windows RT) activate the sideloading keys and install root certificates on devices that user enroll for management. Also Windows Intune integrates with System Center Configuration Manager that many customers already have deployed.

The end user has access to the Company Portal application that lists the applications that the Administrator made available in Windows Intune. The Company Portal is essentially a Store App that communicates with the Windows Intune tenant.

You can view two videos that show Windows Intune capabilities with respect to App sideloading:

[5] The Deployment Sessions - 006 Sideloading to Windows RT from Windows Intune

[6] The Deployment Sessions - 005 Sideloading to RT with Configuration Manager 2012 and Intune

Also you can see the commercial information in

[7] Windows Intune Purchasing and Support Guide

The alternative to Windows Intune is to build this capability yourself. This could be as basic as the network share containing the scripts or a more complex application equivalent to the Company Store communicating with your package repository of choice (Azure Storage / SharePoint, etc.) but you would need to decide if the development effort would be worth it.

Business Models

There are two basic models depending if it is Partner or Customer who purchases the Windows Azure subscription and therefore has a billing relationship with Microsoft. It is common for ISV Partners to own the Azure subscription as they offer to customers their solution(typically a web based application) as a Software as a Service (SaaS). The Customer typically is not aware of where the software is hosted. He pays a subscription fee (typically per user per month) for the service. In this model the Partner has to ensure that the Azure infrastructure costs (virtual machines.) required to run the software and the variable costs derived from the user activity (bandwidth, storage costs) can be recovered from the subscription revenue he receives. It is easier to do that, if it is possible to share parts of the Azure infrastructure to deliver the software to multiple customers. SaaS developed by ISVs as well as multi-tenant services  delivered by hosting partners acting as Service Providers would fall into that category (for a technical example of multitenant hosting see Windows Azure Desktop Hosting Reference Architecture Guide).

In the second model it is the Customer that owns the Windows Azure subscription and has a billing relationship with Microsoft. This model can typically be found with System Integrators (SI) that help customer to move their infrastructure to the Cloud. Apart from the consultancy fees for the execution of the project there is an opportunity for partner to provide value added services such as: backup and recovery services, reporting, monitoring, capacity planning, disaster recovery, IT outsourcing and management for a recurring revenue. For Partners that commit to this model, Microsoft offers sale incentive (see below) that is a percentage of Azure consumption that his Customers generate during a specific time period.

There is nothing stopping any one Partner to have relationships with various Customers in one or the other model.

Azure Discounts

The prices for Windows Azure services published on Azure portal are for the Pay-As-You go tariff but Partners as well as Customers can obtain discounts in return for commitment to consume Azure services during a fixed period of time (6 or 12 month) or by prepaying. “Flexible Savings” page has a summary of the various tariffs available for purchase on-line. You can terminate the Pay-As-You go subscription anytime, however with the commitment tariffs you are committed to stay with the subscription for the specified time period so make sure you read the details.

ISV Partners that implement SaaS type services typically will use the same Azure subscription for multiple customers and therefore will reach quickly the minimum $500 Azure consumption per subscription required for commitment tariffs. However, it is very common for Partners to have separate Azure subscriptions for their Customers and may end up for example with 10-20 subscriptions but where none reaches the $500 minimum. In that case Partners can opt for purchasing Azure through Enterprise Agreement (EA).  This allows them to pull together all new (and also existing) subscriptions to get them qualify for a volume discount. The current guidance for EA is that the total Azure consumption is of the order of $24 K/year but it is a guidance and it can be negotiated.  The EA is typically a multiyear contract and you need to commit to certain Azure consumption level each year and prepay it. You can find more information about EA contracts on Volume Licensing site.

Azure Sales Incentives

Because in the SI Model the Customer owns Azure subscription he will get the Azure discounts described above. Partner obtains money for migrating customers infrastructure and for value-added services he may be offering. Microsoft offers a sales incentives in this model where the Partner will receive a percentage of the influenced Customer revenue during a time period of 2 years. You can find all the details and conditions in “Windows Azure incentive guide” on Microsoft Partner Network site. Starting January 2014 the incentives will require MPN a Cloud competency. You can find out more about the upcoming changes in the Cloud competency, requirement for Silver and Gold Cloud competency levels and the incentives in “Microsoft Partner Network Disclosure of Upcoming Program Changes”.

Because the Web and Worker Roles instances can be moved to a different hardware when Azure Host OS is updated, we need to ensure that the data source is automatically created for us.

In general, ODBC DSNs are created with the ODBC Data Source Administrator that stores information in Windows Registry. You can create System (accessible to all users) and User (accessible by a given user) DSNs. In our case we will focus on System DSNs.

To automate creation of the DSN on Azure Web/Worker Role we will use a startup task that will write to the Windows Registry the same information that the ODBC Data Source Administrator creates.

This article contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base: 322756 “How to back up and restore the registry in Windows”.

On the 64 bit OS ( Azure OS is 64bit) there are two locations where the configuration can take place depending if your code is 64 bit or 32 bit and therefore if it uses a DSN created with 32 bit (%SystemRoot%\SysWOW64\odbcad32.exe) or the 64 bit version (%windir%\system32\odbcad32.exe) of the ODBC Data Source Administrator.

On the 64 bit machine the former writes to the registry at [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI], whereas the latter writes to the key [HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI].

Quick inspection with the Registry Editor (regedit.exe) shows that the key [HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources] holds the mapping from the DSN to the driver name. On the other hand, the key [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\DSN_ Name] holds the DSN configuration details.

The keys can be exported from the Registry Editor into a file that we will later use to create a DSN. For example consider the following 32 bit System DSN configuration odbc.reg file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\SQLNativeAzure]
"Database"="CustomerDB"
"Description"="NerdDinner database in SQL Azure server"
"Driver"="%SystemRoot%\\system32\\sqlncli10.dll"
"LastUser"="user@ma9zkyiigg.database.windows.net"
"Server"="ma9zkyiigg.database.windows.net"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources]
"SQLNativeAzure"="SQL Server Native Client 10.0"

Note, that in the “Driver” key we cannot use the absolute path to the driver because on the Windows Azure Web or the Worker role we do not know in advance the drive on which operating system files will be installed. Therefore, I use environment variable to work around that problem.

We can test our registry DSN configuration on the development machine running the command

regedit /s odbc.reg

The /s option suppresses informational dialog boxes that would normally be displayed. You should be able to verify with the ODBC Data Source Administrator that the DSN was correctly created.

What is left is to configure in your Visual Studio Azure solution the startup task to run the command.

The startup task must run in the elevated executionContext to ensure administrative permissions required for registry. Following is the example of the relevant part of the ServiceDefinition .csdef file:

<ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
   <WebRole name="WebRole1">
      <Startup>
         <Task commandLine="regedit /s odbc.reg" executionContext="elevated" taskType="simple">
         </Task>
      </Startup>
   </WebRole>
</ServiceDefinition>

Obviously, you should not forget to add the odbc.reg file to the solution and mark the file properties in Visual Studio with Copy To Output Directory=Copy if Newer to ensure it forms part of the package that will be generated.

If you also configure Remote Desktop access to the role instance you can launch the ODBC Data Source Admin on the actual Role instance to confirm that the DSN is set up correctly.

At this stage an application can use the configured DSN in connection string as in the following example:

"DSN=SQLNativeAzure;uid=user@ma9zkyiigg.database.windows.net;pwd=my_password;"

You may be tempted to elaborate a more complex startup task to create the shortcut to the ODBC Data Source Administrator with the idea to use it later in the Remote Desktop (RD) session on the role instance. However, application shortcuts are associated with the user profiles and the Remote Desktop user profile most likely is not created yet when the startup task runs.

What you can do to work around this is to copy a script that creates the shortcut to a well- known folder. After logging to role instance via RD you would then run this script to get shortcuts created for you. But this is a topic for another blog.

In this post I describe my experience from implementing Azure Connect and key findings regarding factors that impact connection latency in a scenario where SQL Server uses integrated authentication and the Azure web role instance is domain joined.

Azure Connect Why Bother?

We have introduced Azure Connect in PDC 2010 Conference. It is currently it is available as a beta (CTP2) technology. You can request access to Azure beta programs on the Windows Azure developer portal. After you log in click Home and then Beta Programs on the left panel. You will see Azure Connect listed there. You can now push the button Apply for Access to request participation. It can take some days before you get approval and this feature is enabled for your subscription.

Azure Connect opens the possibility of new scenarios – building hybrid solutions that include Azure virtual machines (role instances) and on-premise machines. You can join the Azure virtual machines to your domain and access them on your local network just as you access your physical servers.

There are some limitations of course. The biggest one is that the Azure roles do not preserve local state. This means that when the Azure host OS is upgraded you will loose any configuration you did manually. Consequently, we need to use Startup task to automate any configuration changes (pre-requisite components, configuration related to IIS, etc). For a scenario where the Azure role instances are domain joined we need to remember that the identity (machine name) of the role instance may change so we cannot really manage the Azure virtual machines as if they local domain resources.

Some customers object to having a solution hosted in Azure because they do not want to move their data to the Cloud because of legal requirements. Azure Connect now enables a scenario where you can keep your SQL server on your corporate network but move to Azure other servers (web servers). Event better, you do not have to compromise on security. You can domain join the Azure web role instances so that they use windows integrated security when accessing a SQL Server!

Azure Connect Basics

The latest Windows Azure Platform Training Kit contains a lab Connecting an Azure Web Role to an External SQL Server Database with Windows Azure Connect. It describes a scenario where the Azure web role instance contains an ASP.Net page configured for anonymous access. When the page loads it connects to the SQL Server that is located in the on-premise network and uses SQL Authentication. The Azure web role instance is not domain joined but rather works in the workgroup. The instructions in this lab are pretty exhaustive there are just two important points to emphasize:

• The firewall rule to allow incoming traffic on port 1433 on the SQL server machine should be applied not just to Domain or Private but also Public profiles because your Azure role instance connects from the internet.
• Almost certainly we need to control the Connection Timeout property in the SQL connection string. The Azure Connect Relays are now available in US, Europe and Asia so you should select the closes datacenter location.However, there may be cases where so the default connection timeout of 15 seconds is not sufficient and you may need to increase the default value.

<connectionStrings>
  <add name="NorthwindConnectionString" connectionString="Data Source=SQLServer.CONTOSO.COM,1433;Initial Catalog=Northwind;Persist Security Info=True;User ID=labUser;Password=Passw0rd!;Connection Timeout=60" providerName="System.Data.SqlClient" />
</connectionStrings>

A more interesting scenario is when the Azure role instance VM is joined to the local, on-premise domain. In this scenario IIS application pool of the Azure web role can be configured with the domain account instead of the Network Service. Consequently, the on-premise SQL server can be locked down with Windows integrated authentication. So lets have a look what would be required. Essentially, there are two parts of the technical solution:

1. Joining the Azure web role to the domain
2. Configuring the IIS application pool

I should mention that in my case the on-premise components (SQL Server and Active Directory) were located in Madrid, Spain and that I was deploying Azure web roles to Dublin datacenter.

Lets have a look at these two points in turn.

1. The procedure to join an Azure role to the on-premise domain is well documented in MSDN article Overview of Windows Azure Connect When Roles Are Joined to a Domain. and in the product team blog Domain Joining Azure Roles.  Perhaps the point that is worthwhile to call out some practical points.

The first is regarding the certificate that you need to encrypt the domain password (required to join the VM to domain).  it is possible to use the same certificate you use to secure the Remote Desktop password. Most likely RD access will be enabled anyway so if security policy of the customer allow it we can reuse the certificate we already have configured. 

It is also beneficial to configure a domain account for the Microsoft.WindowsAzure.Plugins.Connect.Administrators Connect setting. You can then Remote Desktop into your Web role with the domain account rather than local machine account. Obviously, that you give use the access to the domain resources from the RD session.

The second practical point is that although the Connect agent icon may be telling you that there is some issue do not rely on it. For example on my SQL server I see the agent apparently in the eternal connecting state

but actually it is working fine and this is a UI refresh issue that we expect to be corrected. What is worthwhile to do is to open a firewall for ping so that you can test that the communication between the Web Role VM and the SQL server actually works. You can do this using command

netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6

For the web role you would put this into a startup task of course. Than you can ping your Azure VMs to verify connectivity. Following is a ping from SQL server on-premise to a Web Role VM (in this case the Azure Relay was in US and the solution in Europe hence large latencies for ping here).

2. What is not documented currently on MSDN is how you can set an account for the IIS application pool programmatically from the Web Role. Because the role instances can be recycled in Azure this has to be automated with code. Fortunately, the product team has just published a blog Windows Azure Connect Use Case: Web Role / Application Pool Access SQL Server using Windows Authentication. This code is incorporated into the OnStart() method of the WebRole and has some nice features.

• It will detect if Connect network and DNS are available and if the role is domain joined. If not, it will keep on waiting until they are. Obviously, you will have to manually set up the Connect policy to allow communication between the Connect endpoint on the Web Role and the machines (SQL server, Domain controller) that are on-premise. Once you do so the Connect plug-in will perform the domain join and eventually your role will be in Ready state.
• Only after you are domain joined and have network connectivity will the code set the domain account for the application pool. The code uses AppCmd.exe which is better than other approaches based on writing to the IIS metabase that may require you to configure additional Windows features on the machine.
• The associated IIS application pool password is encrypted with the certificate in the same way as the domain join password and is stored in the configuration file. So it is not being hardcoded into your code.

When you deploy the solution to Azure your role will be Busy. This is expected because although the role has the Connect Agent installed the Azure Connect policy does not exist that would allow it to communicate with the domain controller – making the Azure domain join impossible.

We need to click the Virtual Network in the left panel in the Azure management Portal, expand the Connect node , the subscription and lookup the list of activated endpoints:

Here you can see the Azure web role instance RD00155D361666 listed confirming that it has an active Connect Agent. We now have to define the Azure Connect policy that will allow it to communicate with Active Directory and the SQLServer machine on-premise.

This is easily done by clicking on the Groups and Roles node and Create Group button

In the scenario where we use integrated authentication it is important NOT to check “Interconnected:” check box. What is the reason? More about it below in the section “Reduction of Connection Latency”.

When we save this Azure Connect policy, the Azure connect agents will pick up the policy change automatically (it should happen automatically every 5 minutes or you can force the update right clicking on the Azure Connect icon in the systray and selecting “Refresh Policy”.

You also want to make sure that you use the Relay in the datacenter that is closest to your location (in my case it is Europe). You can change the Relay location clicking the Relay Region button.

With the Azure Connect policy in place the solution deployment will proceed to domain join the web role and eventually the deployment status of the solution will be Ready.

So finally we get the result. We can connect to the WebRole and pull the data from the SQL Server on-premise protected with the Windows integrated authentication

Reduction of Connection Latency

When I made the initial tests with this Web Role I was disappointed by the initial SQL Server connection latency which was about 20 seconds. Investigation with the help of the product group turned out a number of additional issues (sources of latency) that need attention.

The Obvious Ones

In CTP2 of Azure Connect Azure Connect Relays have been deployed to all Microsoft datacenter locations. In most cases it makes sense select the Relay closes to your intranet geographical location. Also the size of the Azure web role matters with higher spec roles having higher performance.

Below you can see ping times from machine in Spain to Azure web role in Dublin (Relay in Europe):

The same ping times for relay in US take 3 times longer :

SQL Server Native Client Connection Latency

When I made the initial tests with this Web Role I was disappointed by the latency which for opening the connection first time which was about 20 seconds. After talking to the product group it turns out Azure Connect will assign both the IPv4 as well as IPV6 address to the SQL Server.

Resolving HostName: [sqlserver] ....
IP: 2a01:111:f102:140:4099:2a08:7370:e519
IP: 10.10.10.3

Because Azure Connect works with IPV6 addresses attempting to contact SQL Server on IPv4 address will lead to a timeout. The SQL Server documentation comments that SQL Server Native client will try first to connect on IPv4 and then on IPv6 address if both are configured. The workaround to this problem is to configure Azure web role instance firewall to block IPv4 traffic. With IPv4 traffic blocked by firewall the SQL Server Native client will try the IPv6 address right away.

Because my “intranet” is on 10.X.X.X sub network following rule worked for me – the initial latency dropped from 20 seconds to 3-4 seconds.

netsh advfirewall firewall add rule name="BlockIPv4SQL" dir=out action=block protocol=tcp remoteport=1433 remoteip=10.0.0.0-10.255.255.255 >> %SystemRoot%\logs\Startup.log

Azure Connect team blog has now published a post that details the configuration required.

SQL Server to Active Directory Latency (Azure Connect Policy induced)

In the scenario where SQL Server uses integrated authentication it is important NOT to check “Interconnected:” check box in Azure Connect policy mentioned previously. What is the reason? If this checkbox is selected then Azure Connect is used for network communication between all endpoints in the group. This means that when Azure web role (WebRole1) attempts to query SQL Server machine then the SQL Server will use Azure Connect to contact Active Directory (rather than local network) to validate the credentials (these are IIS application pool credentials). So your traffic goes from SQL Server machine to Azure Connect Relay (in Europe it may be Dublin) and then to Active Directory-clearly increasing the latency. If the check box in NOT selected then Azure Connect will only be used for communication between WebRole1 and SQL Server and WebRole1 and Active Directory (in both directions). Therefore, SQL Server will contact Active directory using the local intranet. That configuration took off another second from the latency I was experiencing. See following blog from the Azure Connect team to get full understanding.

Web Site Related Latencies

There are additional potential sources of latency. Some of them are located in the web server (Azure web role) itself. One very good source of information is the document “Best Practices for Speeding up Your Website” on Yahoo Developer Network. This document gives a number of tips on speeding up the loading times for the web page ranging from the use of: Content Delivery Network, caching, compression and optimization of java script and CSS.

I used two tips from this document: ” No 404s” and “Make favicon.ico Small and Cacheable” as they are fairly generic and easy to implement. If you Remote Desktop to Azure web role you can look up the IIS log – you will notice the requests browser makes for favicon.ico file. Just aggregate one to your website and it will load a fraction faster.

Summary

The key experience from my experience with Azure Connect implementation was that additional sometimes, non-trivial configuration required in order to reduce the connection latency. The factors or potentials sources of latency are:

1. Azure Connect Relay location and Azure web role size
2. Physical distance of your intranet machines from the datacenter
3. SQL Server Native Client related latency
4. SQL Server to Active Directory latency (Azure Connect policy)
5. Web site related latencies

I commented on how to tackle all of them except for 2 which we cannot do anything about.

In practice this has following limitations:

• if you add or modify pre-requisite component you need to regenerate the Azure solution package
• you will have to pay the bandwidth charge of transferring the regenerated solution package (perhaps 100s of MB) even though you actually want to update just one small component
• the time to update entire role instance is incremented by the time it takes to transfer the solution package to Azure datacenter
• you cannot update individual component rather you update entire package

Below I describe an alternative approach. It is based on the idea to leverage blob storage to store the pre-requisite components. Decoupling of pre-requisite components (in most cases they have no relationship with the Azure role implementation) has a number of benefits:

• you do not need to touch Azure solution package, simply upload a new component to blob container with a tool like Windows Azure MMC
• you can update an individual component
• you only pay a bandwidth cost for component you are uploading, not the entire package
• your time to update the role instance is shorter because you are not transferring entire solution package 

Here is how the solution is put together:

When Azure role starts, it downloads the components from a blob container that is defined in the .cscfg configuration file

<Setting name="DeploymentContainer" value="contoso" />

The components are downloaded to a local disk of the Azure role. Sufficient disk space is reserved for a Local Resource disk defined in the .csdef definition file of the solution – in my case I reserve 2GB of disk space

<LocalStorage name="TempLocalStore" cleanOnRoleRecycle="false" sizeInMB="2048" />

Frequently, the pre-requisite components are installers (self extracting executables or .msi files). In most cases they will use some form of temporary storage to extract the temporary files. Most installers allow you to specify the location for temporary files but in case of legacy or undocumented third party components you may not have this option. Frequently, the default location would the directory indicated by %TEMP% or %TMP% environment variables. There is a 100MB limit on the size of the TEMP target directory that is documented in Windows Azure general troubleshooting MSDN documentation.

To avoid this issue I implemented the mapping of the TEMP/TMP environment variables as indicated in this document. These variables point to the local disk we reserved above.

private void MapTempEnvVariable()
       {
           string customTempLocalResourcePath =
           RoleEnvironment.GetLocalResource("TempLocalStore").RootPath;
           Environment.SetEnvironmentVariable("TMP", customTempLocalResourcePath);
           Environment.SetEnvironmentVariable("TEMP", customTempLocalResourcePath);
       }

The OnStart() method of the role (in my case it is a “mixed Role” - Web Role that also implements a Run() method) starts the download procedure on a different thread and then blocks on a wait handle.

public class WebRole : RoleEntryPoint
    {
        private readonly EventWaitHandle statusCheckWaitHandle = new ManualResetEvent(false);
        private volatile bool busy = true;
        private const int ThreadPollTimeInMilliseconds = 1500;
       
       //periodically check if the handle is signalled
       private void WaitForHandle(WaitHandle handle)
       {
           while (!handle.WaitOne(ThreadPollTimeInMilliseconds))
           {
               Trace.WriteLine("Waiting to complete configuration for this role .");
           }
       }
[...]
         public override bool OnStart()
           {
           //start another thread that will carry would configuration
            var startThread = new Thread(OnStartInternal);
            startThread.Start();
         [...]
           //Blocks this thread waiting on a handle 
            WaitForHandle(statusCheckWaitHandle);           
            return base.OnStart();
        }
}

If you block in OnStart() or continue depends on the nature of the pre-requisite components and where they are used. If you need your components to be installed before you enter Run() – you should block because Azure will call this method pretty much immediately after you exit OnStart(). On the other hand if you have a pure Web role than you could choose not to block. Instead, you would handle the StatusCheck event and indicate that you are still busy configuring they role – the role will be in Busy state and will be taken out of the NLB rotation.

private void RoleEnvironmentStatusCheck(object sender, RoleInstanceStatusCheckEventArgs e){
           if (this.busy)
           {
               e.SetBusy();
               Trace.WriteLine("Role status check-telling Azure this role is BUSY configuring, traffic will not be routed to it.");
           }
           // otherwise role is READY
           return;
       }

If you choose to block OnStart() there is little point to implement the StatusCheck event handler because when OnStart() is entered the role is in Busy state and the status check event is not raised until OnStart() exits and role moves to Ready state.

The function OnStartInternal() is where the components are downloaded from the preconfigured Blob container and written to local disk that we allocated above. When downloading the files we look for a file named command.bat.

This command batch file holds commands that we will run after the download completes in the similar way as we do it with startup tasks. Here the sample command.bat

vcredist_x64.exe /q
exit /b 0

I should point out that if you are dealing with large files you should definitely specify the Timeout property in the BlobRequestOptions for the DownloadToFile() function. The timeout is calculated as a product of the size of the blob in MB and the max. time that we are prepared to wait to transfer 1MB. You can tweak timeoutInSecForOneMB variable to adjust the code to the network conditions. Any value that works for you when you deploy solution to Compute Emulator and use the Azure blob store will also work when you deploy to Azure Compute because you would use blob storage in the same datacenter and the latencies would be much lower.

foreach (CloudBlob blob in container.ListBlobs(new BlobRequestOptions() { UseFlatBlobListing = true }))
                {
                    string blobName = blob.Uri.LocalPath.Substring(blob.Parent.Uri.LocalPath.Length);
                    if (blobName.Equals("command.bat"))
                    {
                        commandFileExists = true;
                    }
                    string file = Path.Combine(deployDir, blobName);

                    Trace.TraceInformation(System.DateTime.UtcNow.ToUniversalTime() + " Downloading blob " + blob.Uri.LocalPath + " from deployment container " + container.Name + " to file " + file);

                    //the time in seconds in which 1 MB of data should be downloaded (otherwise we timeout)
                    int timeoutInSecForOneMB = 5;
                    double sizeInMB = System.Math.Ceiling((double)blob.Properties.Length / (1024 * 1024));

                    // we set large enough timeout to download the blob of the given size
                    blob.DownloadToFile(file, new BlobRequestOptions() { Timeout = TimeSpan.FromSeconds(timeoutInSecForOneMB * sizeInMB) });
                    FileInfo fi = new FileInfo(file);
                    Trace.TraceInformation(System.DateTime.UtcNow.ToUniversalTime() + " Saved blob to file " + file + "(" + fi.Length + " bytes)");
                }

After download has been completed the RunProcess() function spawns a child process to run the batch. The runtime process host WaIISHost.exe is configured to run elevated. This is done in the service definition file using the Runtime element. This is required so that the batch commands have admin rights (the process will run under Local System account)

<Runtime executionContext="elevated">     
    </Runtime>

Then we signal the wait handle (if implemented) and /or set busy flag that is used with the StatusCheck event to indicate configuration has completed and role can move to Ready state.

Trace.WriteLine("---------------Starting Deployment Batch Job--------------------");
                if (commandFileExists)
                    RunProcess("cmd.exe", "/C command.bat");
                else
                    Trace.TraceWarning("Command file command.bat was not found in container " + container.Name);

                Trace.WriteLine(" Deployment completed.");

                // signal role is Ready and should be included in the NLB rotation
                this.busy = false;
                //signal the wait handle to unblock OnStart() thread - if waiting has been implemented.
                statusCheckWaitHandle.Set();

The sample solution includes a diagnostics.wadcfg file that transfers the traces and events to blob store (you want to delete or rename it once you go to production to avoid associated storage costs) every 60 seconds.

<?xml version="1.0" encoding="utf-8"?>
<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration" configurationChangePollInterval="PT5M" overallQuotaInMB="3005">
  <Logs bufferQuotaInMB="250" scheduledTransferLogLevelFilter="Verbose" scheduledTransferPeriod="PT01M" />
  <WindowsEventLog bufferQuotaInMB="50"
    scheduledTransferLogLevelFilter="Verbose"
    scheduledTransferPeriod="PT01M">
    <DataSource name="System!*" />
    <DataSource name="Application!*" />
  </WindowsEventLog>  
</DiagnosticMonitorConfiguration>

You can then deploy the solution to Azure Compute and look up the traces in the WADLogsTable using any Azure storage access tool such as Azure MMC.

Entering OnStart() - 03/06/2011 9:09:51
Blocking in OnStart() - waiting to be signalled.03/06/2011 9:09:51
OnStartInternal() - Started 03/06/2011 9:09:51
Waiting to complete configuration for this role .
---------------Downloading from Storage--------------------
03/06/2011 9:09:53 Downloading blob /contoso/command.bat from deployment container contoso to file C:\Users\micham\AppData\Local\dftmp\s0\deployment(688)\res\deployment(688).StorageDeployment.StorageDeployWebRole.0\directory\TempLocalStore\command.bat; TraceSource 'WaIISHost.exe' event
03/06/2011 9:09:53 Saved blob to file C:\Users\micham\AppData\Local\dftmp\s0\deployment(688)\res\deployment(688).StorageDeployment.StorageDeployWebRole.0\directory\TempLocalStore\command.bat(36 bytes); TraceSource 'WaIISHost.exe' event
03/06/2011 9:09:53 Downloading blob /contoso/vcredist_x64.exe from deployment container contoso to file C:\Users\micham\AppData\Local\dftmp\s0\deployment(688)\res\deployment(688).StorageDeployment.StorageDeployWebRole.0\directory\TempLocalStore\vcredist_x64.exe; TraceSource 'WaIISHost.exe' event
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
03/06/2011 9:10:01 Saved blob to file C:\Users\micham\AppData\Local\dftmp\s0\deployment(688)\res\deployment(688).StorageDeployment.StorageDeployWebRole.0\directory\TempLocalStore\vcredist_x64.exe(5718872 bytes); TraceSource 'WaIISHost.exe' event
---------------Starting Deployment Batch Job--------------------
Information: Executing: cmd.exe
; TraceSource 'WaIISHost.exe' event
C:\Users\micham\AppData\Local\dftmp\s0\deployment(688)\res\deployment(688).StorageDeployment.StorageDeployWebRole.0\directory\TempLocalStore>vcredist_x64.exe /q ; TraceSource 'WaIISHost.exe' event
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
Waiting to complete configuration for this role .
; TraceSource 'WaIISHost.exe' event
; TraceSource 'WaIISHost.exe' event
C:\Users\micham\AppData\Local\dftmp\s0\deployment(688)\res\deployment(688).StorageDeployment.StorageDeployWebRole.0\directory\TempLocalStore>exit /b 0 ; TraceSource 'WaIISHost.exe' event
; TraceSource 'WaIISHost.exe' event
Information: Process Exit Code: 0
Process execution time: 13,151 seconds.
 Deployment completed.
Exiting OnStart() - 03/06/2011 9:10:14
Information: Worker entry point called
Information: Working

If you need to redeploy the component you just upload the changed component versions to blob storage and restart your role to pick it up. When you combine this technique with the Web Deploy to update the code of Azure web role you should notice that the whole update process is faster and more flexible. This approach would be most useful in development and testing where otherwise you redeploy the solution multiple times.

You can download the solution here.

Ryan Dunn has packaged the Web Deploy as an Azure plug-in. He also documented the required configuration process in his blog. You simply download the plug-in and configure it with Windows Azure SDK.

I have followed his blog but had difficulty in getting the Web Deploy to work. I have then found another blog from Wade that explains that some firewalls disallow SSL traffic on any port other than 443. So the solution is to map 443 to the port 8172. Now how to do it and where? – the original source does not make it explicit.

Locate the WebDeploy.csplugin in C:\Program Files\Windows Azure SDK\v1.4\bin\plugins\WebDeploy

Run the Notepad in elevated mode (as Admin) and open this file. Locate the InputEndpoint element and change port attribute as show below.

That is it. The next step is to deploy the solution package into the Web Role. Yes it takes still 15 minutes but now because of the Azure WebDeploy plugin we can use update the role once it becomes ready.

From Visual Studio I can now right click the web application project (associated to Web Role project) and select Publish. The configuration varies from the one described in Ryan Dunn blog.

The update of the WebRole with the web site project that Visual Studio created by default is really fast it took in my case less than 2 seconds.

This is great, but I will need to do more tests on more complex projects to see to which extent this approach is practicable.

1. The first step is to access the Microsoft Platform Ready website. You click the Sign Up link where you can provide some information about yourself and your company. You can then Sign In with your Live ID to access the portal

2. Now we are redirected to a page that lists in panel My MPR the list of applications registered for certification. The application can be added by clicking as small link Add an app below the Application table

3. The form appears where you provide information about the Windows Azure website that you want to certify. The application name, version, description and the URL to the application are provide.

4. In the remaining section of the form we indicate the language of the website and our interest in certifying it on Windows Azure. If the application is already working on Azure specify current date for Target Compatibility Date. Press Save & Submit button

5. We now go back to the main MPR page and can see Windows Azure Platform technology listed when our Azure website is selected in the list of the applications. We can now click the Download tool link that appears in the Actions column (it may take a minute or two for this link to become active).

5. When the link is clicked the tabbed section below list of applications changed to the Test Phase. In that section we can download the certification tool by clicking on the link Microsoft Platform Ready Test Tool. This page allows us also to upload the test results generated from this tool for our registered application.

6. Install the Microsoft Platform Ready Test Tool on your computer.

7.Start the tool by typing Microsoft Platform in the Start->Search… textbox. In the Microsoft Platform Ready Test Tool click on the button Start New Test

8. In the Test Information screen select Windows Azure checkbox, fill out name of the test and press the Next button

9. In the next screen click the Edit link to fill out details required by the test

10. The test requires a URL to the Windows Azure website and its IP address

11. Log in to Windows Azure developer portal to look up these details

12. Copy and paste the DNS name (without the http:// prefix) and Input Endpoints to the test pre-requisites screen and press Verify button. The Configuration Status should be Pass for both items. Press Close button.

13. On the next screen verify that the pre-requisite status is Pass and press the Next button

14. On the next page mark the check box and press the Next button. The status will be Executing tests

15. On next screen you can view the status of the test that should be Pass. Click Next to view the report

16. On the final screen you can click Show button to view the report. Then click Reports button to generate the test results package.

17. On this page select the tests that you want to include in the test results package. Press Next button

18. Review the summary of the tests and press the Next button.

19. Provide the application name and version and press Next.

20. Now we need to specify additional information to generate the package. In particular we specify the Application ID from the http://www.microsoftplatformready.com that was assigned in step 5. On this screen we can also review the Logo agreement. Press Next to generate the package.

21. On the final screen make good note of the location of the test package

22. Now we go back to the http://www.microsoftplatformready.com and log in. In the Dashboard click the application Name in the application table and then click the Test tab on the horizontal tab bar and Test My Apps tab on the vertical tab bar. You should see a screen as below

23. Now upload the test package – this is a .zip archive located in the Documents folder, in the subfolder of MPR\Results Package.

24. Press Upload button to submit it to the portal.

25. Press the Refresh link to refresh test result processing state. You should see a page as below

You can download now the Powered by Windows Azure logo by clicking at the download link.You can also get access to additional marketing material by clicking on the Verify vertical tab and then on the Market horizontal tab.

• 250 users of Microsoft Business Productivity Online Standard Suite for internal use. This includes Exchange Online, SharePoint Online, Office Communications Online and Office Live Meeting.
• 250 users of Microsoft Dynamics CRM Online for internal use.
• Windows Intune to administer up to 10 machines
• Windows Azure subscription which includes a block of monthly resource consumption which is free:

You should look up the up-to-date information in this link.

This offer is interesting to companies that are not yet a Microsoft Partner. Microsoft Partners with MSDN subscription should verify if their MSDN subscription level allows them to access Windows Azure subscription under the umbrella of MSDN program because they will get more generous free resource consumption block. You can read about the Windows Azure benefits in this reference and you can look up how to activate this benefit in my previous blog post.

Step by Step Guide How to Activate Azure Subscription in Cloud Essentials Pack

The process can be confusing because it requires you to interact with four different portals: Cloud Essentials Program portal, Microsoft Partner Network portal and Microsoft Platform Ready portal and Microsoft Online Services portal. Each of these portals handles a different part of the entitlement. Also, you will need a credit card to complete the subscription activation. This is required in case you exceed the free consumption block specified in the table above.

The following instructions can help you throughout the process.

If you are not Partner of Microsoft:

• If you do not have Windows Live ID, you need to obtain one in http://www.passport.net . If you have existing Windows Live ID go to step 2.
• Go to the Microsoft Partner Network (MPN) and enroll. In only three steps you can become MPN member free of charge.
• Once you have completed the registration it can take some minutes until your this is reflected in the system.
• From now on you can follow the steps below for the Partners of Microsoft.

If you have problem registering in MPN online please call the Regional Partner Center you can find a telephone list for all countries here.

If you are already Partner of Microsoft:

1. Go to Cloud Essential portal http://www.microsoftcloudpartner.com
2. Click the button Get Cloud Essentials Login Now
3. If this is first time you are logging in you will be redirected to the page prompting you to log on with your Windows Live ID (the same one you used to enroll in MPN) and afterwards you can push the button to verify your MPN membership.

   

4. In the My Cloud Partner page you will see progress bar of the Cloud Essentials program showing 50%. To continue you will have to register basic details of the Windows Azure application that you want to develop. You can to this by clicking Getting Started tab on this page and Qualify and reviewing the requirements. You will see a link to Microsoft Platform Ready there. Click this link to continue.

5. When you access Microsoft Platform Ready website you will need to push the button Initiate session and complete the profile of your company if it is the first time you access it.

6. In the next page you need to register a Windows Azure application. This is accomplished by clicking on the Add an app link at the bottom of the table listing all your applications

7 . In the following dialog you fill out a form that collects basic data about the application. You should select Windows Azure check box for the technology. You also specify the date by which you will certify your application. When you send this form you will see that the application has associated Windows Azure Platform as a technology and that the application is in the Develop stage as in the figure above.

8. When you go back to the http://www.microsoftcloudpartner.com  you will be able to see that the Cloud Essentials progress status will be at 100%. It is possible that you will have to accept additional screen with Terms and Conditions of the program.

9. Now, you can click the Activate Benefits tab on the left

and scroll down to the section Windows Azure Platform. Note the blue arrow to the right. If you click it - you will be redirected to the Microsoft Online Services Portal. If the Live ID that you use throughout the process has been used in this portal you should not need enter additional details – otherwise you may be asked again about your company details.

10. In the Microsoft Online Services Portal the shopping cart will already contain the Azure Cloud Essentials subscription. You need to fill out the subscription name, mark the check box after reviewing legal agreement and press Next to continue with the subscription activation.

11. What is left is to follow the steps indicated by this simple wizard. You will be asked for your credit card details (this is so that Microsoft can bill you if you exceed your free usage quotas of the Cloud Essentials Pack. Then subscription will be activated. At any point you can return to the Microsoft Online Services Portal and edit the service details by entering in the Subscriptions tab and selecting the Edit service details option in Actions list. This allows you to specify a different Live ID (Service Administrator) that will have access to this subscription in the Azure developer portal.

12. You can now log in to Windows Azure developer portal http://windows.azure.com  logging with the Service Administrator ID (or the Live ID you used to purchase subscription in step 10).

I will post an update once product group completes its investigation, for the time being here are the details:

Symptoms:

If the following conditions hold:

-You have deployed an application that calls GetProfileString or makes use of VB6.0 Printers collection object to Windows Terminal Server 2008 or later

and

-You have enabled Easy Print feature in the Terminal Server

then

your application can experience performance issues in the printer enumeration routine because of the increasing size of the Printers collection over time.

Additionally you observe large number of entries accumulating in the HKCU\Software\Microsoft\Windows NT\CurrentVersion\Devices registry hive.

More Information

Some legacy  applications often rely on the Vb.Global.Printers (PrinterCollection) collection object or GetProfileString() function to enumerate printer objects. The Printers object utilizes a function call GetProfileString() that in turn reads information from the HKCU\Software\Microsoft\Windows NT\CurrentVersion\Devices registry hive. As stated in the documentation GetProfileString() should not be called from server side code.

The registry key accumulation under HKCU\Software\Microsoft\Windows NT\CurrentVersion\Devices that is the root cause of the issue reported there is currently treated as bug and we are working on resolving this issue.

Workaround:

It is recommended that the Winspool API function EnumPrinters is used as a mechanism to obtain a list of user printers in terminal session instead of relying on the Printers object. If the source code is available, references to Printers collection should be substituted with the call to the EnumPrinters function. Performance of this function will vary depending on the type PRINTER_INFO structure returned as described in the Remarks section of the referenced document below.

References

EnumPrinters Function

http://msdn.microsoft.com/en-us/library/dd162692(VS.85).aspx

ACC: Enumerating Local and Network Printers

http://support.microsoft.com/default.aspx/kb/166008

GetProfileString Function

http://msdn.microsoft.com/en-us/library/ms724366(VS.85).aspx

Printer Object, Printers Collection

http://msdn.microsoft.com/en-us/library/aa267233(VS.60).aspx

Introducing Terminal Services Easy Print: Part 2-Per Session Default Printers

http://blogs.msdn.com/rds/archive/2007/05/03/introducing-terminal-services-easy-print-part-2.aspx

Applies to:

Windows Server 2008 Terminal Server

Windows Server 2008 R2 Terminal Server

Visual Basic 6.0