Skip to main content


AdvancedSchedule generates error when using monthDays for new schedule

If I want to deploy a monthly schedule on for example the last day of the month I encounter an error message when I used the REST API or the ARM template. The body of the REST API for creating schedules I used look likes this: { "name": "demoSchedule", "properties": { "startTime": "2022-05-07T22:00:00+02:00", "interval": 1, "frequency": "Month", "advancedSchedule": { "weekDays": [], "monthDays": [ -1 ], "monthlyOccurrences": [] } } } When I execute this REST call I receive the following error message: { "code": "BadRequest", "message": "Argument requestScheduleData with value Orchestrator.Schedules.DataAccess.Models.ScheduleAllData is not valid. Error message: The input value is not valid for Monthly Schedule Type" } After spending a lot of time of trial & error I
Recent posts

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(

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