Category Archives: Azure

Manage Azure Subscriptions with Office 365 Users

Azure + Office 365 = Awesome!

Businesses that have adopted Office 365 are looking for more ways to utilize the public cloud to meet their Infrastructure needs. An Azure subscription can provide huge capabilities in terms of hosting Virtual Machines, Virtual Networks, or public websites.

Azure is the clear choice for businesses that are using Office 365, because they can use their O365 accounts to create and manage multiple Azure subscriptions.

Create a new Azure subscription linked to an Office 365 tenant

This is very straight forward. Go to WindowsAzure.com and click on Free Trial then Try it now.

When prompted to Sign in, click on the Sign in with your organizational account link.

Then just simply complete the sign-up process and the Azure subscription will be linked to an Office 365 tenant.

Manage Co-Administrators

Likely there will be multiple people that need access to the Azure services in one organization. With an Azure + Office 365 connected account, Office 365 users can be set as co-administrators on an Azure subscription.

With the Azure Portal, simply navigate to the settingsadministrators screen.

Click on the Add button

And enter an Office 365 user

After specifying which Azure subscription the user can administer, they can sign in with their existing Office 365 account name and password.

Summary

More businesses and other organizations are switching to Office 365. With an Azure subscription, an organization can further leverage the cloud to meet their business needs.

Azure Websites vs Cloud Services

Update: The Azure Websites team added the ability to stage deployments, I updated the comparison grid to list it as “in preview”

The question of the week is. When do you use Azure Websites as your web platform and when do you use Cloud Services. These two platforms provide similar functionality in that you can deploy your ASP.NET or other IIS based web application projects to either of these platforms. There are some general cases of when to use one over the other and some specific differences that may help in making that decision. In this post I am going to go through these differences and attempt to give some guidance on what to use when.

When to use Websites

Websites-vs-CloudServices

You Are Just Starting – Compared to Cloud Services, Websites may not be as flexible but it is definitely easier. You can build your website using Visual Studio, WebMatrix, or any other IDE of your choice without the need for an SDK or any other additional software.

You can deploy to Azure Websites using WebDeploy, FTP, or even DropBox. You can sync your site code straight from GitHub, BitBucket, Codeplex, or TFS Online. It is incredibly easy and require little to know buy-in to Azure if you want to create an IIS website.

You Have a Single Compute Tier – If you are running an application that does not require internal communication then it would be much easier to use Websites. Again, the stance that I usually take is use the easiest option until you are required to change. If you need multiple machines that talk to each other over a private network, then you cannot use Websites and you need to use Cloud Services (or Virtual Machines).

With Websites you can have multiple servers handling requests if you have a high load, however those servers know nothing of each other and do not have internal addresses or endpoints.

Your Site is Written in PHP, Python, or Node.js – This point is not to say that you cannot use these platforms on Cloud Services, it is just easier with Websites because the machines are configured beforehand. With Cloud Services you get a base Azure Image to deploy onto. The Azure Website system uses that same base image however extra software has been installed to IIS for your convenience.

When to use Cloud Services

You Need Machine Level Access – If you compare the underlying platform of Websites and Cloud Services, Cloud Services provides you with a completely provisioned, unique, stateless virtual machine whereas Websites provides pre-configured IIS application pool, and you may be on the same machine as other sites. With IIS there are many restrictions, not the least of them is machine level access. This restriction could affect the base functionality of .NET like using PFX certificates to sign network tokens, or accessing local user profile data.

When deploying to Cloud Services there is no shared option, this deployment owns the entire virtual machine for its lifetime (which could vary, it is not a state-full instance). This gives you much more control over the deployment environment compared to Websites.

You Perform Background Processing – The Cloud Services platform has two different Role Types, a Web Role, and a Worker Role. If you are familiar with on-premise architectures you can compare the two to an IIS Application and a Windows Service. Azure Websites is all IIS, the web server provides the entire platform, there is no room for long running processes or threads that can sit and wait for communication on another port outside of IIS.

If those Windows Service type scenarios are sounding familiar to you, you may need to consider using Cloud Services for the Worker Role capabilities.

Your Application Requires Internal Communication – With Windows Azure services there is a general level of scaleability. Both Cloud Services and Azure Websites can scale up and down as needed, even automatically. However, if you want to use 2 web front-end machines and they need to communicate to each other, you need to use Cloud Services Roles and Instances. Azure Websites take routed requests in a farm of IIS hosting servers, they have no knowledge of other machines in the same site.

Cloud Services however runs as an overall deployment with multiple Roles and each of those Roles can contain multiple Instances. You can scale different components of your system separate from others. Cloud Service deployments also have an internal network all to themselves to use to communicate between the Roles and Instances. The Azure SDK contains .NET Libraries to determine which machine is the current instance and where to contact the others.

Feature Breakdown

For those more specific features that may sway your decision one way or the other, here is a quick table comparing the two.

Feature WebSites Cloud Services
Scale Out to Multiple Instances Without Redeploy Yes Yes
SSL Yes Yes
Visual Studio Integration Yes Yes
Deploy from TFS On-Prem or Online Yes Yes
WebMatrix Support Yes No
Fast Deployment Yes No
Instances Share Content and Configuration Yes No
Multiple Deployment Environments (Production and Staging) In Preview Yes
Network Isolation No Yes
Support for Windows Azure Traffic Manager Preview No Yes
Support for CDN No Yes
Remote Desktop Access No Yes
Execute Start-Up Tasks No Yes

Summary

If the above information has just left you more confused, here are some basic guidelines that I use for many Azure service match-ups.

Use what you need, until you need more, then switch.

That said, start by creating an Azure Website (hey, it’s free right), get your application out into the world. If you find that you require more complexity and you are considering a multi-tier scenario, consider switching to Cloud Services.

As always, thanks for reading!

Quick Script: Copy All Blobs to New Storage Account Using PowerShell

Copy All The Things

Here is a quick PowerShell script to copy blobs from different storage accounts on different subscriptions.

Import-Module Azure

$sourceAccount = 'myvids'
$sourceKey = '@@@@@@@'

$destAccount = 'destvids'
$destKey = '@@@@@@@'

$containerName = 'videos'

$sourceContext = New-AzureStorageContext $sourceAccount $sourceKey
$destContext = New-AzureStorageContext $destAccount $destKey

$blobs = Get-AzureStorageBlob `
    -Context $sourceContext `
    -Container $containerName

$copiedBlobs = $blobs |
    Start-AzureStorageBlobCopy `
        -DestContext $destContext `
        -DestContainer $containerName `
        -Verbose 

$copiedBlobs | Get-AzureStorageBlobCopyState

That will copy all of the blobs in the source container to the destination container.

Enjoy!