1. The script is invoked, specifying the project name and additional metadata (cost centre, deployment location, etc).
2. Two AAD groups are created, one for team contributors and one for team readers. Note the script doesn't add users to these groups, so you'll need to do that separately.
3. A new resource group is created in accordance with a simple naming convention
4. Tags are applied to the resource group, recording the project name, cost centre, etc.
5. RBAC is applied to the resource group, assigning the Contributor and Reader role to each of the two new AAD groups
6. Resource Policy is applied to the resource group. I've got two policies, but you could add more:
   1. A policy that applies the resource group's Tags to each resource that is added to the group
   2. A policy that prevents resources from being deployed outside of a list of approved locations

Onboarding PowerShell Script

Tagging Policy

Policy file

Parameters file

PowerShell to create the Policy Definition

• Subscription Reader role, for people who have a need to view (but not change) any resources deployed in the subscription
• Subscription "specialist" roles, for people who deal with specific technologies across any resource group. For example a network engineer may be granted "Network Contributors" so they can view and modify network resources (but nothing else) in any resource group.

• Avoid role assignments at the resource level (for example, on an individual Virtual Machine). While there may be valid scenarios for this, setting permission at such a granular level is likely to be hard to manage and cause confusion.
• Use built-in roles where possible. Custom roles are a powerful and sometimes useful capability, but they should be reserved for cases when you really need them as they can also introduce complexity. There are 38 built-in roles which should cover most normal scenarios.
• Assign access to groups, not users. The Azure Portal is not really the ideal place to define who is working in which teams. A better approach is to put the users into a Group (in AAD directly, or in AD synced to AAD) and then grant Azure permissions to the group. This way you can add and remove group members externally to Azure, with permissions always being current, while also allowing that group to be used for other purposes such as mailing lists.
• Don't use Microsoft Accounts. Azure access can be assigned to users in your Azure Active Directory, or to personal Microsoft Accounts. In an enterprise scenario, Microsoft Accounts are normally a bad idea, as they aren't associated with an organisation who can do things like disable their account when they leave the company. If you're collaborating with people from outside your organisation, AAD B2B Collaboration can be used to invite those external users as "guests" in your directory.
• Don't forget Service Accounts! In a mature team, most deployments and resource changes should be made by automated processes such as CI/CD or Azure Automation scripts, rather than by individual users. If this applies to you, make sure your RBAC supports this by limiting rights to deploy resources to service accounts instead of users.

• Dump Azure ARM VMs to CSV
• Dump Azure Classic VMs to CSV

ASM to ARM Migration Options

1. ASM2ARM
2. Platform Supported Migration
3. MigAz

What is MigAz?

Using MigAz

1. Run MigAz.exe on a Windows PC or server.
2. Sign into your Azure account.
3. Select the ASM resources that you want to export.
4. Export the resources to an ARM template.
5. Use Azure PowerShell to deploy the ARM template to a new Resource Group. If the template includes Virtual Machines, you'll get errors the first time you deploy. Don't worry, this is normal as you haven't yet copied the VHDs from the ASM storage account to the new ARM one.
6. Run the BlobCopy.ps1 PowerShell script included with MigAz to copy the VHDs into the new storage account.
7. Redeploy the ARM template to the same Resource Group. With the VHDs in place, everything should be ready to go.
8. Test the ARM deployment and edit/redeploy the template as needed.
9. Decommission the ASM resources at the appropriate time.

Contributing to MigAz

Scenarios

Accessing Azure Billing Data

Making this Work

Param(
   [string]$EnrollmentNbr = "",
   [string]$Key = "",
   [string]$Month = ""
)
# access token is "bearer " and the the long string of garbage
$AccessToken = "Bearer $Key"
$urlbase = 'https://ea.azure.com'
$csvAll = @()

Write-Verbose "$(Get-Date -format 's'): Azure Enrollment $EnrollmentNbr"

# function to invoke the api, download the data, import it, and merge it to the global array
Function DownloadUsageReport( [string]$LinkToDownloadDetailReport, $csvAll )
{
		Write-Verbose "$(Get-Date -format 's'): $urlbase/$LinkToDownloadDetailReport)"
		$webClient = New-Object System.Net.WebClient
		$webClient.Headers.add('api-version','1.0')
		$webClient.Headers.add('Authorization', "$AccessToken")
		$data = $webClient.DownloadString("$urlbase/$LinkToDownloadDetailReport")
		# remove the funky stuff in the leading rows - skip to the first header column value
		$pos = $data.IndexOf("AccountOwnerId")
		$data = $data.Substring($pos-1)
		# convert from CSV into an ps variable
		$csvM = ($data | ConvertFrom-CSV)
		# merge with previous
		$csvAll = $csvAll + $csvM
		Write-Verbose "Rows = $($csvM.length)"
		return $csvAll
}

if ( $Month -eq "" )
{
	# if no month specified, invoke the API to get all available months
	Write-Verbose "$(Get-Date -format 's'): Downloading available months list"
	$webClient = New-Object System.Net.WebClient
	$webClient.Headers.add('api-version','1.0')
	$webClient.Headers.add('Authorization', "$AccessToken")
	$months = ($webClient.DownloadString("$urlbase/rest/$EnrollmentNbr/usage-reports") | ConvertFrom-Json)

	# loop through the available months and download data. 
	# List is sorted in most recent month first, so start at end to get oldest month first 
	# and avoid sorting in Excel
	for ($i=$months.AvailableMonths.length-1; $i -ge 0; $i--) {
		$csvAll = DownloadUsageReport $($months.AvailableMonths.LinkToDownloadDetailReport[$i]) $csvAll
	}
}
else
{
	# Month was specified as a parameter, so go ahead and just download that month
	$csvAll = DownloadUsageReport "rest/$EnrollmentNbr/usage-report?month=$Month&type=detail" $csvAll
}
Write-Host "Total Rows = $($csvAll.length)"

# data is in US format wrt Date (MM/DD/YYYY) and decimal values (3.14)
# so loop through and convert columns to local format so that Excel can be happy
Write-verbose "$(Get-Date -format 's'): Fixing datatypes..."
for ($i=0; $i -lt $csvAll.length; $i++) {
	$csvAll[$i].Date = [datetime]::ParseExact( $csvAll[$i].Date, 'dd/mm/yyyy', $null).ToString("d")
	$csvAll[$i].ExtendedCost = [float]$csvAll[$i].ExtendedCost
	$csvAll[$i].ResourceRate = [float]$csvAll[$i].ResourceRate
	$csvAll[$i].'Consumed Quantity' = [float]$csvAll[$i].'Consumed Quantity'

    # Expand tags
    $tags = $csvAll[$i].Tags | ConvertFrom-Json
    if ($tags -ne $null) {
         $tags.psobject.properties | ForEach { 
            $tagName = "Tag-$($_.Name)" 
            Add-Member -InputObject $csvAll[$i] $tagName $_.Value 
            # Add to first row, as that's what is used to format the CSV
            if ($csvAll[0].psobject.Properties[$tagName] -eq $null) {
                Add-Member -InputObject $csvAll[0] $tagName $null -Force
            }
        }
    }

}

# save the data to a CSV file
$filename = ".\$($EnrollmentNbr)_UsageDetail$($Month)_$(Get-Date -format 'yyyyMMdd').csv"
Write-Host "$(Get-Date -format 's'): Saving to file $filename"
$csvAll | Export-Csv $filename -NoTypeInformation -Delimiter ","

The Result

This post is basically combining ideas and code from the Daemon-CertificateCredential-DotNet AAD sample and Neil Mackenzie’s post on Using a Service Principal for Azure PowerShell Authentication.

Note: Azure’s capabilities and APIs change rapidly. This information is current as of June 2015. If you’re reading this in the distant future, you may want to check with other sources on current capabilities and best practices.

Create a new Application in your AAD tenant

Open up the Old Azure Management Portal, browse to the Azure Active Directory tenant associated with your description, click on the Applications tab and then click Add. Enter a nice name for your application and choose “Web Application and/or Web API” as the type. You’ll need to complete the Sign-on URL and the App ID URI but it doesn’t really matter what they are in this case. Once the application has been configured, click on the Configure tab and make a note of the Client ID.

Associate a Certificate with your AAD account

Next you’ll need to create/acquire a certificate to use for authentication. If you haven’t got one handy, you can create a self-signed one using the makecert tool which you should have access to from a Visual Studio developer command prompt:

makecert -r -pe -n "CN=MyAzureManagement" -ss My -len 2048 c:\temp\MyAzureManagement.cer

To associate the certificate with your AAD account you’ll need to install the Azure AD PowerShell module.

Assign your AAD application to an Azure Management Role

Even though we can now authenticate as your AAD application using a certificate, that account doesn’t yet have permissions to do anything to your Azure account. To enable this, we’ll need to add your AAD application to the appropriate Azure Resource Manager role. Remember that ARM has full role-based access control, so you can be quite fine-grained in what the application should be allowed to do.

The new Azure Portal currently lets you assign permissions to AAD Users, but not to AAD Applications. Since we want to do the latter, we’ll need to use the Azure PowerShell module. In this case I’m adding the application to the “Contributes” role for a specific resource group.

Authenticate to AAD and call the Azure Resource Manager APIs

Finally we have everything we need to call the APIs. As far as I know it’s not possible to use certificates to authenticate to AAD from PowerShell, so we will be doing this from .NET.

The following sample code should run happily in a console app if you add the ADAL (Microsoft.IdentityModel.Clients.ActiveDirectory) and ARM (Microsoft.Azure.Management.Resources) NuGet packages, and update the various constants for your subscription. All it does is list a couple of properties from the resource group but you whatever you want, provided your AAD app has the required roles.

Your subscription or mine?

Possibly the most fundamental question is whether the solution is intended to be run in your own cloud subscription, or in that of your customers.

A solution deployed into your own subscription is normally categorised as a Software as a Service (SaaS) application, as your customers can use it without needing to own or understand the underlying resources (VMs, databases, etc). This is probably the default model for most new cloud services, and it is increasingly the model expected by most customers (although probably not most enterprise IT buyers). Some of the key implications of this model are:

• You (as the owner of the service) need to directly pay for the resources used by the solution
• Your team must be responsible for deploying and managing the production solution, not just building the code
• You can upgrade, monitor and scale the solution as you wish, but you need to manage customer expectations around availability, data retention, privacy etc.
• You won’t be able to cater for any customer requirements that you didn’t explicitly design into the solution.

The other option is to build a solution that is designed to be deployed to a customer’s own cloud subscription. This normally means packaging the solution as one or more VM images, although there are also ways of including PaaS components into such a solution. This approach is often the easiest way to take a “legacy” ISV solution to the cloud, but it can also be a good option for new solutions that may need to be customised or configured extensively by the end customer. Some of the implications of this model are:

• You (as the owner of the service) are not responsible for (and have no visibility of) the resources used by your solution
• You have limited control over if and when customers apply patches or updates (you’ll need to build/leverage some kind of update service to do this). As such you may need to support multiple versions of your application for some time.
• Customers have full control of the resources on which your application runs (VMs, databases, etc) and can tinker with or break them at will.

It’s worth noting that regardless of which option you choose you have the option to promote and monetise your application using the Azure Marketplace. The “Application Services” category is for SaaS solutions that can be “logically” provisioned in a customer’s subscription (even though the resources run in your own subscription), while the “Virtual Machines” category is for VM images that are used to provision VMs directly within the customer’s subscription.

IaaS or PaaS?

Another key question is whether the application should be built on an infrastructure as a Service (IaaS) platform or on a Platform as a Service (PaaS) stack.

IaaS solutions consist of one or more Virtual Machines which you are responsible for deploying and managing. IaaS services are becoming a commodity, with many providers offering similar capabilities. This makes IaaS solutions relatively portable, but it can come at cost of increased complexity and additional management tasks. Some of the key implications of an IaaS based solution include:

• You can choose to use almost any technology in your solution (OSes, frameworks, programming languages, etc).
• The solution can be made to run in different environments (e.g. on-premises, in different cloud providers, or in different users’ subscriptions) with minimal effort
• You (as the VM owner) are responsible for the health of the VM from the OS up, including patching, monitoring, upgrading, etc.
• Implementing High Availability and Disaster Recovery can be very complex.

PaaS is all about providing higher-level abstractions to developers (e.g. websites, queues, databases etc) that hide the details of the underlying Virtual Machines (even though they are still there). This can increase productivity and reduce complexity, but it comes at a cost of reduced flexibility. Some PaaS stacks can run on arbitrary IaaS platforms (allowing them to be run on multiple cloud providers), while others are tied to a single cloud provider. While some people get concerned about the potential for “lock in”, in practice very few solutions are moved from one cloud provider to another. Some of the implications of PaaS based solutions include:

• Features such as high availability, backup and autoscaling are often provided as a part of the service, eliminating additional complexity and costs
• Components don’t need to be individually licensed or deployed
• You will be constrained in which technologies you can use and how they can be configured
• It may not be possible to run the solution outside of the platform it was designed for.

In Microsoft Azure, we’ve seen most people favour PaaS for new development, but they often choose IaaS for migrating existing solutions to the cloud. It’s also worth noting that IaaS vs PaaS is not a binary decision – in many cases the most sensible option is to mix and match the approaches for different solution components (for example, a PaaS Web App talking to a NoSQL database running on a VM).

Single- or Multi-tenant?

The final question for today is whether to go for a single-tenant model (where each customer’s solution components are deployed separately) or a multi-tenant model (where multiple customers are supported by the same set of components).

A single-tenant solution is the natural starting point for an existing on-premises app, or one that is designed to run in customers’ own subscriptions. Typically this results in a solution with one database for each customer, and it may also involve a separate website for each customer. These may be each deployed to their own VMs, or it may be possible to deploy multiple components for different customers to the same VMs. Some of the implications of a single-tenant solution include:

• The solution may make less efficient use of resources (compared to a multi-tenant solution) and hence cost more to run
• Tenants can be deployed, upgraded and scaled independently. This increases flexibility but also significantly increases complexity. For example you could end up having different customer databases running with different versions of the schema.
• Data and code is inherently isolated, making it unlikely that you will accidentally leak data across tenants. However this also makes it difficult to get aggregate data out of the solution for analytics or similar purposes.

Multi-tenant solutions generally require a bit more care to build, as you need to make sure that the solution supports all tenants while maintaining the illusion to your customers that they are the only ones using the app. However the solution should be easier to grow and manage long-term, and as such this is usually the default option for “born in the cloud” apps. Some of the implications include:

• The solution can make efficient use of resources, although you may need to be wary of “noisy neighbour” problems
• The application will be deployed and managed centrally for all customers. This may limit flexibility for users, for example it won’t be possible for some users to remain on an older version.
• You need to be extra careful to maintain data privacy by not sharing any data across tenants (since everyone’s data will be in the same database or other components).

Conclusion

If you’re building a brand new consumer-facing SaaS application, chances are you want to design a multi-tenant PaaS-based solution that is deployed into your own cloud subscription. However many businesses are dealing with challenges such as an existing code base, an existing customer base and evolving business strategies that can mean that other solutions may be more appropriate. In rare cases it may even make sense to build multiple versions of your solution supporting different models, but this should probably only be considered as a part of a short-term transition strategy.

I hope this post has given some useful insight into these questions and the reasons for choosing one model over another.

We’ve found that one of the best ways to help people get productive with new APIs is through simple sample applications which demonstrate just the most critical scenarios, showing the correct implementation patterns with the smallest possible overhead. The samples help you understand what the API can do, allow you to debug through the code to understand how it works, and allow you to copy and paste the code into your own solutions with confidence.

Here at Microsoft we call these kinds of samples “QuickStarts”, and we’ve included them in a number of products of the years, including many deliverables from the patterns & practices team. We’ve also included a number of QuickStarts with the Azure SDK for a few months now, but until now they may have been difficult to discover and use.

With the new Azure SDK 2.6 for .NET, we’ve made a few key changes to provide a better experience for the Azure QuickStarts. First, there are now two ways of finding them. If you’re using Visual Studio and have the Azure SDK installed, you can see find the QuickStarts by choosing File | New Project, expanding the Templates \ Visual C# \ Cloud \ QuickStarts node and selecting the technology you’re interested in:

If you’re not currently using Visual Studio, you can find the exact same samples in the MSDN Code Gallery sample pack. On this site you can view the source code in each sample, download an individual sample or the full pack, as well as rate the samples and ask questions.

In addition to providing more ways to find the samples, we’ve been working to improve both the quality and quantity. Each sample now comes with improved documentation as well as error handling to anticipate common mistakes such as forgetting to update a connection string. We’ve also added new samples for technologies like Azure Active Directory and Azure Files, and we’ll keep adding more over time.

If you have any questions or feedback on the Azure QuickStarts you can provide a comment below or use the Q&A tab present on each sample in the Code Gallery.