IntegrationWorkz

When you want to do a role assignment to a principal in an ARM template you will use code like the one below. In this example the role definition is actual the object id of the role. If you want to assign the contributor role you will use the value 'b24988ac-6180-42a0-ab88-20f7382dd24c'. You also have to specify the id of the principal so you will have to retrieve that value yourself upfront. { "type": "Microsoft.Authorization/roleAssignments", "apiVersion": "2020-04-01-preview", "name": "[guid(parameters('roleAssignmentName'))]", "properties": { "roleDefinitionId": "[subscriptionResourceId('Microsoft.Authorization/roleDefinitions', parameters('roleDefinitionId'))]", "principalId": "[parameters('principalId')]", "scope": "[subscriptionResourceId('Microsoft.Resources/resourceGroups', parameters(...

At the moment I am busy with PowerShell DSC scripts that also create objects within the Active Directory. Because it's work in progress you have to delete those objects regularly. Witin this sandbox environment the recycle bin feature is enabled so the objects are kept 30 days.  To permantly delete such objects (so you have a clean testing situation) you can use the following PowerShell command. Get-ADObject -filter {sAMAccountName -eq "<name of object>$"} -includeDeletedObjects -property * | Remove-ADObject

The implementation of Azure Automation in ARM templates has some quirks. The last time I blogged about the lack of idempotency for the jobSchedule resource. In this article I will write about the solution I had to write because the ARM template for webhooks has a little flaw. If you read the template reference documentation you can see that the template format is as follows. { "name": "string", "type": "Microsoft.Automation/automationAccounts/webhooks", "apiVersion": "2015-10-31", "properties": { "isEnabled": "boolean", "uri": "string", "expiryTime": "string", "parameters": {}, "runbook": { "name": "string" }, "runOn": "string" } } Quite straight forward you will think but there is one catch: there are some properties which are defined as not required ...

This week I was busy with writing ARM templates for deploying a runbook within an Azure Automation account. One of the parts you need for this is the jobSchedule object. The first time I created the object the deployment went succesful but when I deployed the same template a second time the deployment fails with the error message "A job schedule for the specified runbook and schedule already exists".  After doing some research I found out that I was not the only one. In Azure Feedback I found a bug item from Yulun Zeng dated January 24, 2018 who encountered the same issue. The bug is under review since January 7, 2020 but is still not solved. Some of the Azure Automation resources are conflicting with a fundamental rule of ARM templates documented by Microsoft. Repeatable results: Repeatedly deploy your infrastructure throughout the development lifecycle and have confidence your resources are deployed in a consistent manner. Templates are idempotent, which means you can ...

I develop C# based web apps and integration solutions (APIs) for years and nowadays they are hosted in Azure. Most of the time I also create the infrastructure to deploy these kind of applications. In accordance with the Infrastructure as Code principles that I use, I do this using ARM templates supplemented with PowerShell (DSC) scripts. As a developer, I am used to writing unit tests to test my applications. Testing infrastructure is a new area for me. The traditional unit test approach does not work here because you cannot test an infrastructure until it has been rolled out. Recently I have gained experience with the use of the Pester framework for performing (pre) deployment verification testing during the rollout of an IIS website environment. In this blog article I share some experiences I have gained during this project. Case The case in this case is the rollout of a WCF API hosted on an Azure VM on which no IIS web server is installed yet. This web service will run under...

In my previous post I explained how to assign an existing certificate with a custom action. Because of all kind of IIS Manager related failures I had on my work with this solution I did some research and constructed a version based on the usage of a PowerShell step within the WiX installer. PowerShellWixExtension In this new scenario I use the PowerShellWixExtension written by David Gardiner which I found on GitHub. To use this extension you have to add a reference to the PowerShellWixExtension.dll in your WiX Setup project. I added this reference with the published NuGet package. Search for PowershellWixExtension in the store. The further steps to use this library are documented on the GitHub page. PowerShell script Add to your WiX setup project a PowerShell file name Add-ExistingCertificateToBinding.ps1 which will contain the steps to find and add the certificate to an existing IIS binding. Add the below PowerShell code to this file. param ( [Parameter(Mandatory = $Fals...

If you want to delete an Azure AD tenant which contains an Azure DevOps Enterprise application record you will first have to remove this Enterprise application record. Removing the Azure DevOps Enterprise record will not succeed from the user interface because the delete button is greyed out. To remove the record follow these steps: Create a new Global Admin account in the directory you are trying to delete. Make sure you copy the temporary password. Start Windows PowerShell commandline and run: Install-Module -Name AzureAD . Once done run Connect-AzureAD . You will be prompted to login, login with the user you created and you will be asked to change your password. Run Remove-AzureADServicePrincipal -ObjectId [Object ID] to remove the Enterprise application record. Remove the Global Admin account you created. After the Azure DevOps Enterprise record is removed you can delete the Azure AD tenant.