Naming Conventions in Azure

I must admit right up front: I'm more than a little obsessed with naming conventions. Prefixes...suffixes...I really enjoy coming up with the optimal convention to use so that a name is at least somewhat self-documenting without being horribly long.

In Azure, we use a combination of resource groups and resource names to organize things. Here's the naming convention for resources that I currently prefer:

Purpose --> Type of Service --> Environment

Resource Group examples:




Virtual Machine examples:

BISQLVM1Dev (this one runs the engine, SSIS, and MDS)

BISQLVM2Dev (this one runs SSAS in multidimensional mode)





Storage Account examples (non-managed storage):

BISQLVM1DataStrgDev (this is the unit of recovery for a single VM)


BISQLVM1BckStrgDev (SQL Server backups; sent to geo-redundant storage)


BISQLVM1DiagStrgDev (diagnostic & logging data)


Additional criteria:

  • Some resources require a unique name across all of Azure. This is the case if the resource has a data access endpoint or URI. Therefore, depending on your implementation, you might need to auto-generate part of the name to enforce uniqueness. In that case, I would still try to make the prefix human-understandable, followed by the uniqueString().
  • The type of service in the name helps with logging/metrics in monitoring scenarios. You probably want to use a standard abbreviation (in the examples above, RG is for resource group; VM is for virtual machine; and Strg is for storage).
  • Environment (such as Dev/Test/Prod) as the suffix makes concatenations easier within scripts. You may also want to use tags to denote the environment.
  • We do denote Prod in the name of Production resources (rather than omitting it completely). This is because our Dev/Test/Prod resources are all contained within one subscription, separated by resource group. Therefore, we want to be very specific.
  • No dashes (hyphens) or underscores in the names since all resources don't allow them.
  • Camel case if the resource allows it; otherwise all lower case. (Storage accounts are actually required to be all lower case - the storage example shown above is camel case only because it's easier to read in this blog post.) You might decide to do the opposite: always go lower case so things are consistent. There's some appeal in that too.
  • The maximum length allowed varies quite a bit between resources.
  • Depending on how many teams/groups in your organization share a subscription, you might want to include a prefix of who owns or maintains this resource. This can also be done with a tag, but this sort of naming convention is helpful for sorting resources especially if you have wide permissions to see the entire subscription.
  • There are times when you do need the names to be the consistent across all environments, or you introduce too much complexity. One example of this is Azure SQL Database (its parent server differs between Dev, Test, and Prod but not the database name itself). Another example is for Azure Data Factory - to prevent maintaining duplicate JSON code multiple times I'm finding it best to keep the name of linked services, datasets, and pipelines the same name across data factories (whereas the name of Azure Data Factory resource would differ between Dev, Test, and Prod).
  • In addition to Dev/Test/Prod, we also use a 'Sandbox' as a suffix which essentially means: this is an individual's area for learning or exploration. For instance: DataScienceVMSandbox.
  • Unless you're supporting a multi-tenant platform, putting the organization/company name within the name doesn't add any valuable context.

In the end, the actual naming convention you decide on isn't the important thing. Most important is that you can locate resources easily and secure them properly -- which requires some consistency with the naming policy.

You Might Also Like...

Displaying Columns of Metadata in the Azure Portal

Why Some Azure VM Sizes are Unavailable When Resizing in the Portal

New Whitepaper on Planning a Power BI Enterprise Deployment

I'm excited to share that a new technical whitepaper I co-authored with Chris Webb is published. It's called Planning a Power BI Enterprise Deployment. It was really a fun experience to write something a bit more formal than blog posts. My interest in Power BI lies in how to successfully deploy it, manage it, and what the end-to-end story is especially from the perspective of integration with other data assets in an organization. Power BI has grown to be a huge, wide set of features so we got a little verbose at just over 100 pages.

A huge thank you to Chris Webb for inviting me to be his co-author. Chris is not only whip-smart, but a total pleasure to work with. 

Another big thank you to Meagan Longoria for being our tech editor. I like to think of myself as detail-oriented, but I've got nothin' compared to her eagle eye.

We worked primarily with Adam Wilson at Microsoft in terms of getting information, so he deserves a thank you as well for dealing with the questions that Chris and I peppered him with week after week.

I hope you find the whitepaper to to be useful. 

Displaying Columns of Metadata in the Azure Portal

This is just a quick tip about displaying columns in the Azure portal. If you've not been using this little feature, they can be helpful.

Here's an example of what part of my portal looks like for virtual machines:


For VMs, there is some useful metadata pertaining to IP addresses and disks. If you've started using tags those can be displayed too -- tags are really helpful for things like billing categories, environment names, project or system names, team or group names, who owns or supports a get the idea. If you have multiple subscriptions in your directory, that can be shown as well.

Each Azure resource differs in which columns are available.

You Might Also Like...

Setting Up Azure Disk Encryption for a Virtual Machine with PowerShell

Why Some Azure VM Sizes are Unavailable When Resizing in the Portal


Reusing Datasets Imported to the Power BI Service

I'm a big fan of reusing Power BI datasets whenever possible to minimize redundant datasets floating around the organization. It's less maintenance, less chance of calculation differences, and less data refreshes to schedule. And, this technique is a way to separate who handles report creation vs. creating the dataset, calculations, and relationships (which is typically far fewer people).

Info verified as of: May 20, 2017

In this post I'm referring to datasets which are imported into Power BI (thus requiring a data refresh to update the imported data). We're already "reusing" a dataset which is in DirectQuery or SSAS Live Connection mode, so those are useful techniques too -- just not applicable to this particular post.

To reuse an imported dataset, there are three options I'm aware of:

  1. Report in the Power BI Service. This refers to using the web interface for creating a new report separate from the original PBIX file.
  2. Analyze In Excel. This refers to creating an Excel report and can currently be used by anyone with read or edit access to the dataset. Hence, very useful for self-service BI purposes.
  3. Power BI Service Live Connection. This refers to creating a Power BI Desktop report. This option can currently only be used by people with edit permissions on the dataset (so not appropriate for broad self-service BI reporting at this time).

Report in the Power BI Service

In the Power BI Service, if you have edit permissions, the option to create a report is on the Actions menu. It will open up a blank report connected to the dataset:

When you save the new report, it will appear as another report although it shares the same exact underlying dataset. This is a great way to divide up reporting needs for different people, yet use the same exact dataset.

That was the simple one. Next we have...

Analyze In Excel

In the Power BI Service, if you have edit permissions, the option to use Analyze In Excel is on the Actions menu:


If you're a read only user, it's not as prominently displayed. However, it works the same. You can find it through the "Related Content" pane:

The first time you'll be prompted to download and install an Analysis Services OLEDB driver which handles connectivity back to the Power BI dataset in the Service:


The next thing to know is that the connection will be stored in a separate .ODC file (short for Office Data Connection). You'll want to keep all of your .ODC files in a single location, and only have one .ODC file per connection (this makes it easy to change the data connection info later if you need to).

From there, you can create pivot tables, charts, etc like normal in Excel. The data connection properties inside of Excel will look like this:

If things don't work, you might want to check that this option in the Power BI Admin portal hasn't been turned off for Analyze In Excel (though this Admin portal setting is applicable only to datasets where the underlying data is SSAS in Live Connection mode):


More info about Analyze In Excel is here: - the post has more details about requirements for Excel version, the need for a measure in the dataset, etc. 

Note that you can't publish an Analyze In Excel workbook back to the Power BI Service (because workbooks in Power BI are only supported if it has imported data in the workbook). Maybe we'll get this feature in the future, because having one place to publish would be very nice.

One more option which is similar but not quite...

Power BI Service Live Connection

For this one, we start inside of Power BI Desktop. As of the time I'm writing this, it's still a preview feature which needs to be enabled first in the Options menu:


To get started, visit the Get Data menu. You can locate the "Power BI Service" option under Online Services:


Here's where things differ a LOT from Analyze In Excel. 

If you are a read-only user, you'll see your list of workspaces. However, you won't see any datasets to choose from. That is because currently you are required to have edit privileges on the dataset in order to use this feature.

However, if you do have edit permissions, you can select the dataset. Then it will open a blank report with a connection back to the dataset:


Note that you cannot edit queries or datasets or relationships - just the report. Perfect. That means it looks like it's behaving exactly like the earlier two options discussed.

However, since edit permissions are needed currently in order to use this feature effectively, it's not able to be widely used by self-service BI users. I hope it ends up being the equivalent of Analyze In Excel, for Power BI Desktop instead.

More info about Power BI Service Live Connection is here:

That's it. You keep thinking about ways to reduce the number of duplicate / similar datasets and I'll be a happy girl.

You Might Also Like...

Why a Semantic Layer Like Azure Analysis Services Is Relevant