IntegrationWorkz

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

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

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