Things to Do Before You Start with Azure in CSP
Microsoft is making a huge push on a new reseller channel for cloud services (Office 365, EMS, Azure, and so on) called Cloud Solution Provider (CSP). There is a good chance that you will be talked to about using the CSP channel to purchase Azure. In this post, I will share some steps that you should go through to verify that you are ready to start an Azure deployment in CSP.
Azure in CSP
CSP is just one of many ways to purchase Azure, but it is the most unique of the ways because Microsoft has drawn a very hard line between Azure of the past (Azure V1 or Service Management) and Azure of the future (Azure V2 or Azure Resource Manager/ARM).
The first thing that you should know about CSP is that it does not support Azure V1. That means that CSP does not include all of the features that you can get when you purchase Azure via an enterprise agreement, through Open, or via the direct (credit card) channels.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
The second thing that you should know is that you cannot use the legacy Azure Management portal with CSP. Instead, you must use the new Azure Portal (formerly known as “Codename Ibiza”), PowerShell, JSON, or REST to deploy and manage your services in a CSP subscription. This has a side-effect because some Azure features might be available in Azure V2 (and therefore in CSP) but the user interface might be missing. This was the case for Azure Site Recovery (ASR or DR in the cloud) and Azure Backup (online backup) until recently, and customers had no choice but to learn and use the PowerShell alternatives.
I work for a Tier 2 (distributors reselling via Microsoft partners) CSP partner and we deal with lots of customers who are keen on using CSP for Azure because of the monthly utility bill model that can be resold to their customers. I have to go through a bit of a conversation with those resellers to verify that CSP is an option for them – unfortunately, all too often, the restricted capabilities of Azure V2 kill the deal.
Check Feature Availability
Whether you work in Platform-as-a-Service (PaaS) or Infrastructure-as-a-Service (IaaS) you will need to check if the features you need now, or in the future, are there in Azure V2, and therefore in CSP. Microsoft has shared a list of features that you can look up but I have found this to be incomplete. I had one situation where a software development company required an IoT/PaaS feature that I had never heard of. I did some online searching, but in the end, I had to sign into my subscription to see if that feature was available. My method went as follows:
- Find out how to deploy the feature using the Classic deployment model (Azure V1)
- Look for the alternative Resource Manager deployment model (Azure V2).
If there was a Resource Manager option, then the feature was available – however, sometimes deployments in ARM are different (load balancing, for example) so this approach can be a bit of a black art.
I have two tips:
- Solutions not features: For example, a disaster recovery solution is much more than Azure Site Recovery (ASR). I normally include Azure RemoteApp in my solutions to allow users to get easy access to applications, services and data after a failover (their PCs burned with the fire too).
- Future, not just the present: What will the business do in 3 months or 6 months? The lack of some features that are not in Azure V2 might not bother you now but it might in the future. Note that whispers on the grapevine lead me to believe that some features that are missing in Azure V2 at this point might not appear for a very long time.
A lot of people have figured out Azure retail pricing using search terms such as “Azure VM pricing” or “Azure storage pricing”. What you get from those searches is the retail pricing for Azure, which is good for the direct (credit card) or Open channels of Azure.
Those searches are still useful – that’s because the Azure pricing pages explain how the resources you will deploy will be priced, even if the displayed pricing is irrelevant.
Note: please ignore any benefits for enterprise agreement customers in the Azure pricing pages.
CSP is a private agreement between the reseller and the customer, and uses a private discounted pricing file. That pricing file is a spreadsheet, and that is much more difficult to use to estimate the price of a solution for the uninitiated. Why? That’s because it’s one flat worksheet with over 4,500 items (May 2016). My tip is to use filters, and filter out the regions you won’t use – but note that the spreadsheet that Microsoft shares with resellers every month uses blank fields to denote services that are in all regions.
Use the Azure pricing pages to understand how Azure pricing is structured, and then use a filtered version of the CSP pricing file to find the prices of each resource that you plan to deploy.
Choose Your Domain Name
Every Azure subscription is uniquely identified by a DNS domain name in the .onmicrosoft.com space. For example, one might have an Azure subscription called petridemo.onmicrosoft.com. You must provide the domain name of your choosing when getting any service via CSP. Ideally, you will keep this consistent with your other Microsoft enterprise cloud deployments.
The CSP reseller will provide you with a user name and password for the new subscription – which should only take a very short time to provision, and some resellers even automate this process via a website. You don’t need to activate anything, copy product keys, or any of those other hurdles with other channels of Microsoft cloud computing. You simply sign in and start using the service.
Azure Active Directory
You are going to need a second, non-CSP, subscription to manage the users & groups in your CSP subscription’s directory. The reason we need this subscription is because we have no classic management portal with CSP, but Azure AD can only be managed via PowerShell and the classic management portal. The solution is to import the directory of the CSP subscription into another non-CSP subscription where we can manage it. We don’t want to pay for another subscription so what you can do is:
- Start a trial subscription (which requires a credit card, but with no payment).
- Opt not to allow additional payments beyond the trial credit.
There will be no cost to this additional directory if you use it purely to manage Azure AD. Note that you will require the following to import the CSP directory:
- A Microsoft Account (not an Azure AD account) with global admin rights in the non-CSP subscription.
- An Azure AD account with global admin rights in the CSP directory.
- I also recommend using a browser in private/incognito mode to avoid cross-over of credentials from your Windows sign-in.
A Resource Naming Standard
Everything in Azure V2 is deployed into resource groups, a logical collection of items, that allow us to manage services as a whole and to delegate administrative and user access (via Azure AD users and groups). This structured approach implies that you should use naming standards for every resource that you deploy. Note that a virtual machine in Azure V2 will result in a lot more visible and manageable resources than a virtual machine in Azure V2 so well-documented, communicated, and understood naming is critical. The approach that I have started to embrace is:
- The resource group is named after the service.
- Every resource is named after the resource group.
- Every resource type is designated by a suffix with an incremental number, such as –vm01.
- Always use lowercase names with no spaces, even if upper case and spaces are allowed – the rules are inconsistent and some PowerShell cmdlets are case-sensitive when it comes to the names of resources.
This article by Mark Simms goes into much more detail on the concepts behind naming standards in Azure.
Resource groups allow you to associate resources that you deploy in Azure based on service affinity. But you might find that the business has a different view on the elements in your system. For example, you might use internal cross-billing to pay for resources where business units pay for elements of different systems.
Another scenario is where you want to use Azure Automation to work with resources, based on some logical selection that has nothing to do with service affinity.
A tag is a simple text string that allows you to easily search for and identify resources no matter what resource group they are in, assuming that you have sufficient rights for the resource groups. If your organization is complex enough to merit it, then you should plan a system of tagging resources based on logical usage by the business or management.