[go: nahoru, domu]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

azauto schedule json conversion #3744

Closed
anyasabo opened this issue Apr 9, 2017 · 5 comments
Closed

azauto schedule json conversion #3744

anyasabo opened this issue Apr 9, 2017 · 5 comments
Assignees
@safeermohammed
Labels
Automation automation-cheetah must also have the "Automation" label Service Attention This issue is responsible by Azure service team.

Comments

@anyasabo
Copy link
anyasabo commented Apr 9, 2017 •
edited by azuresdkci
Loading

Cmdlet(s)

Get-AzureRmAutomationScheduledRunbook

PowerShell Version

5.1.14393.693

Module Version

AzureRM 3.8.0, or rather AzureRM.Automation 2.8.0

OS Version

10.0.14393.693

Description

When retrieving a specific azure automation runbook schedule, it appears the cmdlet sometimes has difficulty parsing the returned JSON. The json looks to be valid, so seems to be an issue with the cmdlet rather than the service.

Getting the specific schedule returns more info, such as the parameters, than what is returned when you query for all of the schedules on an automation account, and it is here that the parsing error happens. In this case, a parameter has a value of "04:00:00" which appears to be making the json parser error out. From what I can see, this is valid JSON though.

This cmdlet is used to re-register existing schedules after updating modules in an automation account, so a fix here would be greatly appreciated.

Note that this particular runbook/schedule is one that is created by OMS for its update deployments feature, but I am not sure if that is relevant here.

Debug Output

Instructions: to get Debug Output, set $DebugPreference="Continue" and then execute the cmdlet or script causing the issue.

Get-AzureRmAutomationScheduledRunbook -AutomationAccount $automationaccount -ResourceGroup $resourcegroup -JobScheduleId "SCHEDULEUUID" -Debug

DEBUG: 1:06:22 PM - GetAzureAutomationScheduledRunbook begin processing with ParameterSet 'ByJobScheduleId'.
[redacted auth section]
DEBUG: ============================ HTTP REQUEST ============================

HTTP Method:
GET

Absolute Uri:
https://management.azure.com/subscriptions/SUBUUID/resourceGroups/RGNAME/providers/Microsoft.Automation/automationAccounts/AZAUTOACCTNAME/jobSche
dules/SCHEDULEUUID?api-version=2015-10-31

Headers:
Accept                        : application/json
x-ms-version                  : 2014-06-01

Body:



DEBUG: ============================ HTTP RESPONSE ============================

Status Code:
OK

Headers:
Pragma                        : no-cache
x-ms-request-id               : ee94fa59-3f1a-4fd2-8f69-95bc77213584
Strict-Transport-Security     : max-age=31536000; includeSubDomains
x-ms-ratelimit-remaining-subscription-reads: 14984
x-ms-correlation-request-id   : 74fdfd85-a80e-4904-a948-58e41e7dfdf8
x-ms-routing-request-id       : SOUTHCENTRALUS:20170409T180623Z:74fdfd85-a80e-4904-a948-58e41e7dfdf8
Cache-Control                 : no-cache
Date                          : Sun, 09 Apr 2017 18:06:23 GMT
Server                        : Microsoft-IIS/8.5
X-AspNet-Version              : 4.0.30319
X-Powered-By                  : ASP.NET

Body:
{
  "id": "/subscriptions/SUBUUID/resourceGroups/RGNAME/providers/Microsoft.Automation/automationAccounts/AZAUTOACCTNAME/jobSchedules/SCHEDULEUUID",
  "properties": {
    "jobScheduleId": "SCHEDULEUUID",
    "runbook": {
      "name": "Patch-MicrosoftOMSComputers"
    },
    "schedule": {
      "name": "SCHEDULENAME"
    },
    "runOn": null,
    "parameters": {
      "Duration": "04:00:00",
      "ScheduleName": "SCHEDULENAME",
      "WorkspaceId": "AZAUTOACCTNAME",
      "ComputerIdList": "REDACTED",
      "AdditionalOptions": "REDACTED"
    }
  }
}


Get-AzureRmAutomationScheduledRunbook : Invalid JSON primitive: 00:00.
At line:2 char:1
+ Get-AzureRmAutomationScheduledRunbook -AutomationAccount $automationa ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Get-AzureRmAutomationScheduledRunbook], CmdletInvocationException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Automation.Cmdlet.GetAzureAutomationScheduledRunbook
 
DEBUG: 1:06:25 PM - GetAzureAutomationScheduledRunbook end processing.
DEBUG: 1:06:25 PM - GetAzureAutomationScheduledRunbook end processing.

Script/Steps for Reproduction

Create a runbook that accepts a parameter. Create a schedule that passes a parameter value of "04:00:00". Run Get-AzureRmAutomationScheduledRunbook against this schedule.
@anyasabo
Copy link
Author
anyasabo commented Apr 9, 2017

Update:
I was trying to create an easy script to reproduce it, and I noticed I was unable to. It looks like if you create it a schedule with a parameter like "04:00:00", the posh sdk escapes it at least and actually sends "\"04:00:00\"". This does not error out and the json returned from the service when pulling it is also escaped. This seems silly though, I can't see a reason for why these must be nested strings.

Here are my repro steps that unfortunately do not error out:

$ReproRGName = "ReproRG"
$ReproAzAutoAccountName = "ReproAcct"
$ReproRunbookName = "ReproRunbook"
$ReproSchedule = "ReproSchedule"
$ReproLocation = "southcentralus"
$StartTime = (Get-Date).AddMinutes(6)

#download a simple repro powershell script that simply accepts a parameter and outputs it
$LocalPath = "$env:userprofile\repro.ps1"
$RemotePath = "https://gist.githubusercontent.com/jonsabo/a392b54e5ae538865b14c8d8036b7285/raw/459132bf1c697c20515e7a2311737eecd7c69a24/azautorepro.ps1"

Invoke-WebRequest -Uri $RemotePath -OutFile $LocalPath

New-AzureRmResourceGroup -Name $ReproRGName -Location $ReproLocation
New-AzureRmAutomationAccount -ResourceGroupName $ReproRGName -Name $ReproAzAutoAccountName -Location $ReproLocation -Plan Free
Import-AzureRMAutomationRunbook -Name $ReproRunbookName -ResourceGroupName $ReproRGName -AutomationAccountName $ReproAzAutoAccountName -Type PowerShell -Path $LocalPath

Publish-AzureRmAutomationRunbook -Name $ReproRunbookName -ResourceGroupName $ReproRGName -AutomationAccountName $ReproAzAutoAccountName


New-AzureRmAutomationSchedule -Name $ReproSchedule -ResourceGroupName $ReproRGName -AutomationAccountName $ReproAzAutoAccountName -StartTime $StartTime -DayInterval 1

$Params = @{
"TestValue" = "04:00:00"
}
$LinkedSchedule = Register-AzureRmAutomationScheduledRunbook -ResourceGroupName $ReproRGName -AutomationAccountName $ReproAzAutoAccountName -RunbookName $ReproRunbookName -ScheduleName $ReproSchedule -Parameters $Params -Debug

$runbook = Get-AzureRmAutomationScheduledRunbook -ResourceGroupName $ReproRGName -AutomationAccountName $ReproAzAutoAccountName -JobScheduleId $LinkedSchedule.JobScheduleId -Debug

And here's what it actually sends when it links the schedule to the runbook

DEBUG: ============================ HTTP REQUEST ============================

HTTP Method:
PUT

Absolute Uri:
https://management.azure.com/subscriptions/SUBID/resourceGroups/ReproRG/providers/Microsoft.Automation/automationAccounts/ReproAcct/jobSchedules/3dcf6df3-a6b2-49d2-a3b4-e1bf6a989253?api-version=2015-10-31

Headers:
Accept                        : application/json
x-ms-version                  : 2014-06-01

Body:
{
  "properties": {
    "schedule": {
      "name": "ReproSchedule"
    },
    "runbook": {
      "name": "ReproRunbook"
    },
    "parameters": {
      "TestValue": "\"04:00:00\""
    }
  }
}

@anyasabo
Copy link
Author
anyasabo commented Apr 9, 2017

Also verified that if you schedule a runbook in the portal, when you retrieve it via the api it comes as a nested string

    "parameters": {
      "TestValue": "\"04:00:00\""
    }

So at this point I am not sure if it is a bug in the SDK, or a bug with the service. It seemed at first like a bug with the SDK, since the JSON the service was returning was valid. But maybe the service specifies that parameter values need to be nested strings, and is just not verifying this when schedules are created by other Microsoft services (in this case OMS)?

@anyasabo anyasabo mentioned this issue Apr 14, 2017
Open
@cormacpayne
Copy link
Member

@safeermohammed Hey Safeer, would you mind taking a look at this issue?

@safeermohammed
Copy link
Contributor

REST API expects the Parameter values to be json serialized object. The reason for this is the parameter value can be a PSObject which can be deserialized in runbook.

The first case the cmdlet failed with error "Invalid JSON primitive:" because it tried to deserialize primitive string expecting the value to be json. Ideally the return value from Service for this case should have been json and the cmdlet would have worked, for some reason it is not in that form from the service.

@vrdmr vrdmr added the automation-cheetah must also have the "Automation" label label Mar 15, 2018
@bsiegel bsiegel added the Service Attention This issue is responsible by Azure service team. label Sep 26, 2018
@andyw248
Copy link

Closing as it appears from the third post from the OP that the behavior is consistent between different Automation cmdlets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@safeermohammed safeermohammed

Labels
Automation automation-cheetah must also have the "Automation" label Service Attention This issue is responsible by Azure service team.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@bsiegel @vrdmr @markcowl @anyasabo @cormacpayne @andyw248 @safeermohammed