Skip to main content

Query the Azure REST API of Azure DevTest Labs with Postman

At the moment I am middle in the process of writing my ARM templates for deploying an Azure DevTest Lab environment based on an Azure DevOps CI/CD pipeline. Unfortunately not all the options you can configure from the Azure portal are exported by the automation script option of the resource group or are available within the Azure Resource Explorer. So much of the information you need you have to find in the REST API documentation of DevTest Labs.

To find out what the results are from the Policies - List GET method I need to query the REST API. I will be using the Postman app for this purpose. To query the Azure REST API you will need to be authenticated. You can do this in two ways: with your own Microsoft/Azure AD account or with a service principal. Because of the ad-hoc character of my research the Microsoft account route is the one I will use.

Retrieving bearer token

To retrieve the bearer token of my Microsoft account I need to authenticate myself. For this purpose we will have to install the ARMClient app. For the installation I will use Chocolatey.

Start a PowerShell console with administrator rights and use the following command to install Chocolatey if it's not installed on your machine.
Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString(''))
Close your PowerShell console to ensure that chocolatey is loaded correctly. Open a new PowerShell console with administrator rights and use the following command to install ARMClient.
choco install armclient
To retrieve the bearer token you will have to login with the ARMClient. Use the following command.
ARMClient login
Sign in to your Azure account in the prompt you will see. To retrieve the bearer token in your clipboard you will need the following command.
ARMClient token
Save the value for later usage in the Postman app.

Querying the Azure DevTest Labs REST API

Now we have the bearer token we can start quering the REST API of Azure DevTest Labs. Download the Postman app en install it on your machine. After Postman is installed start the app and choose the Request building block.

We have to give the request a name. In this case we enter the value 'List Policies' for the request name field. The request also has to be added to a collection. Via the create collection option we create a new collection named 'Azure DevTest Labs'. After selecting the newly created collection we can save our new request.

From the documentation we copy the GET URL we need to list the policies which are configured within our Azure DevTest lab environment. Extra accolades are added to use the Postman variables.
In this URL we have a few placeholders which have to be replaced with actual values. We can manually replace them in the URL or we can used the environment option of Postman. In the right corner of Postman you will find an option to manage environments. Because we don't have any environments we will have to add one.

We will enter 'Azure DevTest Labs' as the environment name. After that we fill the key-value pairs of the variables. We will have to create a variable for the subscriptionId, resoureceGroupName, labName and policySetName. For the policySetName we use the value 'default'. When all the variables are configured we add the environment via the add button. Don't forget to select the created environment in the pulldown menu.

On the authorization tab we have to select the type. From the pulldown menu we select the Bearer Token option. In the token field we will add the bearer token we retrieved with the ARMClient. After saving the constructed request it's time to test it.

We send the GET request to the REST API and receive an error.
    "error": {
        "code": "ArgumentException",
        "message": "Requested value 'ScheduleEditPermission' was not found."
This looks like that there is a PolicyFactName received which is not part the API definition at the moment. According the current documentation (API Version: 2016-05-15) this is not an allowed value. It's one of the new option which is already available in the UI but not is described in the REST API documentation.

When I change the api-version value to an invalid value like '2100-01-01' I get an error message which indicates that there are newer API versions than listed in the online documentation.
    "error": {
        "code": "NoRegisteredProviderFound",
        "message": "No registered resource provider found for location 'westeurope' and API version '2018-01-01' for type 'labs'. The supported api-versions are '2018-10-15-preview, 2018-09-15, 2017-04-26-preview, 2016-05-15, 2015-05-21-preview'. The supported locations are 'westcentralus, japaneast, westus, australiacentral, australiasoutheast, canadacentral, centralindia, centralus, eastasia, francecentral, koreacentral, northeurope, southcentralus, ukwest, westindia, australiacentral2, australiaeast, brazilsouth, canadaeast, eastus, eastus2, francesouth, japanwest, koreasouth, northcentralus, southindia, southeastasia, uksouth, westeurope, westus2'."
After changing the api-version to the latest version, currently 2018-10-15-preview, retrieving a list of policies works like a charm.
Because retrieving the list now works I also now know how to configure the missing policies which are available in the UI and where not described in the REST API documentation.


Popular posts from this blog

CS8357: The specified version string contains wildcards, which are not compatible with determinism.

Today I was busy with creating a WCF service solution in Visual Studio Enterprise 2017 (15.9.2). In this solution I use a few C# class libraries based on .NET 4.7.2. When I compiled the solution I got this error message: Error CS8357: The specified version string contains wildcards, which are not compatible with determinism. Either remove wildcards from the version string, or disable determinism for this compilation The error message is linking to my AssemblyInfo.cs file of the Class library projects. In all the projects of this solution I use the wildcard notation for generating build and revision numbers. // Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: // [assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("1.0.

Fixing HTTP Error 401.2 unauthorized on local IIS

Sometimes the Windows Authentication got broken on IIS servers so you cannot log in locally on the server. In that case you get the dreadfully error message HTTP Error 401.2 - Unauthorized You are not authorized to view this page due to invalid authentication headers. To fix this issue you can repair the Windows Authentication feature with the following PowerShell commands: Remove-WindowsFeature Web-Windows-Auth Add-WindowsFeature Web-Windows-Auth

Assign an existing certificate to your IIS website with WiX

Recently I had to change the bindings of existing IIS hosted websites and APIs from HTTP to HTTPS. They are installed with a MSI file created with the WiX Toolset . Because I have to use an already on the server installed certificate I cannot use the Certificate element from the IIS Extension because this element only supports installing and uninstalling certificates based on PFX files. After doing some research I found the blog article Assign Certificate (Set HTTPS Binding certificate) to IIS website from Wix Installer which described the usage of Custom Actions for this purpose. I adopted this approach and rewrote the code for my scenario. With WiX I still create the website. <iis:WebSite Id="WebSite" ConfigureIfExists="yes" AutoStart="yes" Description="MyWebsite" Directory="IISROOT" StartOnInstall="yes"> <iis:WebAddress Id="WebSite"