Cost Analysis in Microsoft Azure allows you to analyse the cost of your services; these services can be scoped into Resource Groups, Resources and Services; you can also group your services by Tags.

Azure tags are name-value pairs used to organize resources. You can apply tags for individual resources, display show back or ownership and can be used for automation - but what assigning parent/child relationships to your resources?

Tags work well for most used cases, but there may be times when you want to get a more in-depth view of the service and dependencies - this is where the "cm-resource-parent" tag comes in.

Introduced in Cost Analysis preview, Q3 of 2022, the 'cm-resource-parent tag' allows you to Group related resources together - to help give you a quick view of the solution's total cost in a parent/child relationship. The 'cm' in the tag stands for: Cost Management.

To use the cm-resource-parent tag, you must choose a parent resource (an example may be an App Service or an Azure Virtual Desktop host pool). No changes will be made to this resource, but you need the ResourceID of the resource to apply to Child resources.

To find the ResourceID of the parent resource, you can use the Azure Portal, by

1. Open the resource that you want to be the parent of.
2. Select Properties in the resource menu.
3. Find the Resource ID property and copy its value.

You can easily use PowerShell to find the ResourceID as well:

$ResourceName = 'Parent Resource'
Get-AzResource -Name $ResourceName | Select-Object ResourceId

A resource ID looks like this (you will need to copy the full thing, this will be used on your child's resources):

/subscriptions/4501c644-74a3-4bfc-a456-16425eccd2a4/resourceGroups/vm-preprod-rg/providers/Microsoft.Network/publicIPAddresses/VM-T01-ip

Once you have the Resource ID of your resource, it is time to tag your Child's resources.

As an Azure Tag is a Key/Value pair - the tags will be similar to:

To apply the ResourceID of the parent resource, you can use the Azure Portal, by

1. Open the resource you want to be the child of the parent you selected above.
2. Click Tags
3. Add in: cm-resource-parent in the value and the resource ID of your parent as a value.

Note: You cannot have a multi-hierarchy, i.e. a Parent, then Child and Child off that - it is purely a Parent and Child relationship at this stage. Also, the Resource ID will change if the Parent resources are moved to another Resource group or subscription.

These Tags can work easily with other cost management tags you may be using (but you cannot have more than one cm-resource-parent tag), so it doesn't replace but supplements your visibility. They are supported on any resource that is Tag-capable.

You may have to wait up to a day (24 hours) before the changes are visible in Azure Cost Analysis.

I have the Azure Naming Tool deployed in my example and would like to see the overall cost; these resources are deployed across multiple resources in the same subscription.

Choosing my WebApp as my parent resource, I tagged all child resources (App Service Plan, Container Registry, Storage Account) with the relevant tag and resource ID as seen below:

After 24 hours, I then went to the Cost Analysis (Preview) and selected Resources and could view the current cost of my service after a few days of use.

And another example can be seen below - where I have added a Public IP as a child resource of the Azure storage account, which, although the parent in this relationship, is a child in the Azure Naming Tool.

As you can see, the 'cm-resource-parent' is another way to group related resources of different types from a cost analysis angle; still, in preview, this tag opens up the door for various other initiatives across observability, security stacks etc.

Although not tested, you also should be able to output the resource ID of your Bicep code and add that as a variable for any resources deployed via Infrastructure as Code.

It's worth noting that this feature is still in Preview at the time of this article, so if you incur any bugs or have feature requests, you can use the 'Rate the Cost Analysis Preview' feature in the Azure Portal to supply feedback to the product teams.

This was asked in the Microsoft forums; with the change of platform from being able to see and download certificates for the competition of your Microsoft exam with Pearsonvue to the new Microsoft Learn experience, you might find yourself lost when attempting to view (and print) your hard-earned Microsoft certificate!

The certificate format has also been refreshed.

Old

New

To view and print your certificate:

1. Navigate to: https://learn.microsoft.com/en-us/users/me/activity/
2. Click on: Certifications
3. Find your certificate and click on View certification details.
4. Click a Print certification, then click Print and you can print and save it as a PDF or print (remember to uncheck print Headers and footers, to remove any footers from the print).
5. 

If you want to download it, you can print it to a PDF, to save the certificate to your computer.

When attempting to deploy an Azure Firewall, you may get an error: Conflict, DeploymentFailed error. This error can occur when you have an expressroute connection, and the Firewall is not deployed in Force Tunneled mode, as the routes from the BGP link will be replacing the default Azure internet route, required for the Azure Firewall.

"code": "InternalServerError",
"message": "An error occurred."

If you click Input in the deployment, you may notice your vnetName, vnetAddressSpace and subnetAddressSpace are blank.

Even though the Azure Firewall will appear as deployed. You will notice that it won't have a Private IP assigned.

To resolve this error:

1. Delete the Azure Firewall that has been partially deployed
2. Create a User Defined route for the internet:

1. Link it to the AzureFirewallSubnet
2. Redeploy

This error may occur as your internet route may flow via BGP routes from on-premises; the user-defined route will override this route.

You might access resources such as Azure SQL databases or Azure Storage accounts if you're connecting to a Microsoft Azure network externally (from a non-Azure VM or VPN); mainly if you operate Cloud-only services and don't have an external DNS provider, such as Active Directory - connecting to private link resources, you may have to edit your local host's file and override local DNS to point to the IP of the private endpoint for each service.

This is not sustainable, not scalable, and you might end up throwing your hands in the air and switching back to public-facing services and just whitelisting other users' Public IPs to gain access to Azure resources - which can lead to its own set of issues, such as unmanaged IPs left with access to resources after contractors or users leave or have finished their work, IP address changes if not managed correctly can allow any user or company to have a direct line of sight to your company resources.

Overview​

Today we will concentrate on DNS resolution of Private Endpoints, using Azure DNS Private Resolver as a DNS proxy when connecting to Azure using a Point to Site VPN.

For this article, I assume you have an Azure Point to Site already set up; if you don't, you can refer to a previous article I wrote for Creating an Azure Point to Site VPN using Microsoft Entra ID authentication.

Disclaimer: Azure Private DNS Resolver is still in Public Preview at the time of this article (02/09/2022). If you aim to use this in a Production scenario, functionality and services may change. This also means there are current regional restrictions, and Azure Private DNS Resolver is not currently available in all regions. Also bear in mind the cost of this service.

So what is Azure DNS Resolver?​

Azure DNS private resolver is a cloud-native, highly available, and DevOps-friendly service. It provides a simple, zero-maintenance, reliable, and secure Domain Name System (DNS) service to resolve and conditionally forward DNS queries from a virtual network, on-premises, and to other target DNS servers without the need to create and manage a custom DNS solution. Resolve DNS names hosted in Azure Private DNS Zones from on-premises networks as well as DNS queries for your own domain names. This will make your DNS infrastructure work privately and seamlessly across on-premises networks and enable key hybrid networking scenarios.

Customers will no longer need to provision IaaS-based solutions on their virtual networks to resolve names registered on Azure Private DNS Zones and can do conditional forwarding of domains back to on-premises, across multi-cloud providers, and public DNS servers.

This solution can work with your Azure ExpressRoute, Azure VPN, or Azure Bastion setup.

Inbound or Outbound?​

Name resolution queries for Azure workloads from the on-premises network are conditionally forwarded to the Azure DNS private resolver inbound endpoint, which enables you to perform name resolution of workloads registered on Azure Private DNS Zones from on-premises.

The Azure DNS private resolver inbound endpoint has a private IP that is part of a subnet where the endpoint has been created. The IP address of the DNS private resolver inbound endpoint is then set as a DNS server on the on-premises network.

Azure DNS private resolver outbound endpoint conditionally forwards the request to on-premises or other target DNS servers.

Today, we will connect to private endpoints to concentrate on the Inbound functionality of Azure Private DNS Resolver.

Deployment​

To deploy Azure Private DNS Resolver, we will need a few things.

• A Virtual Network
• A subnet dedicated to resolving DNS queries (/28)
• A private endpoint (i.e. Storage Account, SQL Database) is linked to the virtual network.

Deploy DNS Private Resolver​

I assume you already have a Virtual Network tied to your Virtual Network gateway as part of the 'Point to Site VPN' setup.

1. Open the Azure Portal
2. Click on + Create a resource
3. Type in: DNS Private Resolver
4. 
5. Click Create
6. Select your Subscription
7. Select your Resource Group (I recommend placing the DNS Private Resolver in the same resource group as your Virtual Network - but place this service in a Resource Group that makes sense for your environment, i.e. shared services or a specific network team resource group)
8. Type in a name for your DNS Private Resolver (this is a regional service, but the name does not need a globally unique )
9. Select your region (this needs to be the same region as the Virtual Network)
10. Select your Virtual Network (the same Virtual Network that has your Virtual Network Gateway for the Point to Site VPN and your Private endpoints)
11. 
12. Click Next: Inbound Endpoints >
13. Now its time to add our Inbound Endpoint and create the Private DNS Resolver Subnet, click + Add an endpoint
14. Type in your endpoint name (for example, InboundEndpoint)
15. If you have already created a subnet, select it - else, click Create New
16. Enter in your subnet name and address range
17. Click Save
18. 
19. Click Review + Create
20. Click Create

Adjust Point to Site DNS​

Now that the DNS Resolver has been created, with an inbound endpoint, allowing the lookup of private endpoints, we need to add the Private Resolver DNS relay to our point-to-site VPN configuration; first, we need the newly created private IP of the inbound endpoint.

1. Navigate to the DNS Private Resolver in the Azure Portal

2. Open your DNS Private Resolver service

3. Click on Inbound Endpoints

4. Make a note of the private IP of your inbound endpoint.

5. 

6. Now that the Private Inbound resolver has been configured, we need to add the DNS relay into our Azure VPN configuration so that our DNS queries will respond with a private endpoint; you will need to modify the 'azurevpnconfig.xml' file and reimport the VPN.

7. Right-click 'azurevpnconfig.xml' and edit in Notepad or Visual Studio Code

8. Under:

9. Add (replace the IP listed below with the IP of your Inbound endpoint copied earlier):

   <clientconfig>
   <dnsservers>
   <dnsserver>10.0.18.4</dnsserver>
   </dnsservers>
   </clientconfig>
   

10. Save and reimport to the Azure VPN Client

11. Once connected, ping a resource behind a private endpoint, and you should get the private IP of that resource back and should be able to connect to that resource privately.

12. 

Any future or current private endpoints linked to the same Virtual Network will instantly be accessible without additional changes on the Azure VPN client. If you have a Hub & Spoke topology, then you may place the DNS Private Resolver in the HUB, then use forwarding rules to link to other peered VNETs.

Additional resources​

The third-party resources below include reading and learning about the Azure Private DNS Resolver.

• Quickstart: Create an Azure private DNS Resolver using the Azure portal

• Intro to Azure DNS Private Resolver

• Azure DNS Private Resolver - MicroHack

• My Azure Private DNS Resolver Bicep export for reference:

    param dnsResolvers_PrivateDNSResolver_name string = 'PrivateDNSResolver'
    param virtualNetworks_vnettest_externalid string = '/subscriptions/57627713-eff2-44fa-a546-a2c8fde3c6e3/resourceGroups/pointtositetest/providers/Microsoft.Network/virtualNetworks/vnettest'
  
    resource dnsResolvers_PrivateDNSResolver_name_resource 'Microsoft.Network/dnsResolvers@2020-04-01-preview' = {
    name: dnsResolvers_PrivateDNSResolver_name
    location: 'australiaeast'
    properties: {
    virtualNetwork: {
      id: virtualNetworks_vnettest_externalid
    }
  }
    }
            resource dnsResolvers_PrivateDNSResolver_name_InboundEndpoint 'Microsoft.Network/dnsResolvers/inboundEndpoints@2020-04-01-preview' = {
  parent: dnsResolvers_PrivateDNSResolver_name_resource
  name: 'InboundEndpoint'
  location: 'australiaeast'
      }
    ]
  }
    }
  

Azure Virtual Desktop allows you to access an entire desktop or a published application with shortcuts and an appearance like it was running locally; depending on the requirements; I prefer published applications where possible to keep the user experience on the endpoint device and keep the cost down.

One of the applications I published for a customer is MYOB IMS Payroll.

IMS Payroll worked well as a published application for months until one day; it didn't seem to open for the user, whether as a published application or in the Full Desktop.

The symptoms were that once the user clicked on the icon, it would appear to open (visible on the Taskbar), but there was no window, and when you hovered over the preview thumbnail, it was blank. The cursor also appeared to be active with a circle, indicating it was trying to open.

Even if you don't have IMS Payroll, you may experience applications with a similar experience, and hopefully, this article will help point you in the right direction.

One noticeable difference we found in our testing - was that it opened for us and other users using different accounts.

After some discovery, we discovered that the user had gone to another branch office site and used a different monitor setup, and IMS Payroll was out of drawing range. Usually, windows would be able to snap this back into view; however, after comparing the registry keys for our user vs the user who had the issue, we discovered that IMS Payroll sets the location in the user registry.

• Registry Key location: \HKEY_CURRENT_USER\IMS Payroll Partner\Layout

In our case, the settings were as follows:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\IMS Payroll Partner\Layout]
"Left"="684"
"Top"="310"
"Height"="713"
"Width"="1127"
"StatusBar"="1"
"ActiveHelp"="0"
"EmployeePage"="0"
"PayrollPage"="5"
"CompanyPage"="1"
"SkipWelcome"="1"
"SkinName"="lfUltraFlat"
"LastPage"="6"

For the users who couldn't see IMS Payroll, their settings looked more like this:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\IMS Payroll Partner\Layout]
"Left"="-1444"
"Top"="310"
"Height"="713"
"Width"="1127"
"StatusBar"="1"
"ActiveHelp"="0"
"EmployeePage"="0"
"PayrollPage"="5"
"CompanyPage"="1"
"SkipWelcome"="1"
"SkinName"="lfUltraFlat"
"LastPage"="6"

The difference was that the Left entry had moved the Window too far, left out of view, so it could not be seen by the user when opening as a published app or on a Desktop.

After the Left entry was changed from -1444 to 684. IMS became visible again as a published application and on the Full Desktop.

Due to the hard-coded user registry entries, this specific issue would have occurred regardless of Azure Virtual Desktop, running in a Terminal Services environment, or even locally, when working with different monitor setups.

Note: Some applications may have configuration files stored in the user's AppData folders instead of the registry; if in doubt, raise a support ticket with the application vendor.