Skip to main content


Assign role assignments by name in ARM templates

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(
Recent posts

Permantly delete an AD object

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 command was found in the module PowerShellGet, but the module could not be loaded.

While testing a PowerShell DSC script deployed by Azure Automation on an Azure Virtual Machine I ran against the following error message:  The command <command> was found in the module PowerShellGet, but the module could not be loaded. What I tried to accomplish was automatically installing the PowerShell Az modules with the following PowerShell DSC script. # Import DSC modules Import-DscResource -ModuleName "PowerShellGet" -ModuleVersion 2.2.5 Node $AllNodes.NodeName { PSModule "Az" { Ensure = "Present" Name = "Az" Repository = "PSGallery" InstallationPolicy = "Trusted" AllowClobber = $true Force = $true RequiredVersion = 5.6.0 } } To solve this issue you also have to import the PackageManagement module because PowerShellGet has a dependency on this module. The correct version of the script is thus: # Import DSC modules Import

Azure Automation: Use a nested ARM template as an user defined function to bypass the start time issue of schedules

Lately I am busy with Azure Automation . In terms of ARM templates I run into a number of issues with this product. See also my previous blog postings about this. This time too I had to look for another workaround. In this case it concerns the start time of a schedule . This must be at least 5 minutes in the future for the product group each time you do an ARM deployment for the schedule object. This resource is also not complying to the idempotency rules of ARM template. My workaround is to mark the date part of the startTime (for daily, weekly, montly recurring schedules) in my parameter file with ' GEN-DATE ' placeholder and my ARM template will generate each time the correct date if I do the deploy. To replace the placeholder with the correct value I first thought to use an user defined function for this purpose. After reading the documentation, I could conclude that this functionality did not match what I needed. An user defined function consist of input parameters and

Creating a managed service account with PowerShell DSC fails: The KDS Root Key was not found

At the moment I am busy with automating the creation of a Windows 2019 server with the Active Directory role enabled. My PowerShell DSC script is hosted in Azure Automation wich acts as the pull server. The script is installing the Active Directory role and configuring the domain. During my initial test I got the following error when the script tries to create a Managed Service Account. System.InvalidOperationException: Error adding group account 'gMSA-ADSync'. The KDS Root Key was not found. (MSA0019) Microsoft.ActiveDirectory.Management.ADException: Key does not exist System.ServiceModel.FaultException: Active Directory returned an error processing the operation. After doing some research I found out what the reason for this is. According the Microsoft documentation  the reason for this behavior is as follows: Domain Controllers (DC) require a root key to begin generating gMSA passwords. The domain controllers will wait up to 10 hours from time of creation to allow all dom

Azure Automation: deploy webhooks with ARM templates

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

Azure Automation: Solve the 'A job schedule for the specified runbook and schedule already exists' issue

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