IntegrationWorkz

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

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

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

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