Scheduled Start not working - Response status code does not indicate success: 400 (Bad Request)

[microsoft]

Scheduled Start not working - Response status code does not indicate success: 400 (Bad Request)

[parojasmsft]

Hi Oramoss,

I have notified our dev team of the issue so they can look into it.

[oramoss]

Is this fixed now then? If so, what was the resolution and how do I get it installed please?

[balas77]

Sorry accidently closed it.

[balas77]

Did the start operation was working fine for you?

[balas77]

From your payload the action was mentioned as stop so checking on the status of the start operation

[oramoss]

start and stop both fail in same way. Thanks for reopening.

[oramoss]

I was trying to do it on a subscription which wasn't the one where the software is installed and thought it might be that but also tried for same schema last night and that has same issues.

[balas77]

Hey, can you make sure you have added the managed identity of azure functions with role as contributor into other subscriptions?

https://github.com/microsoft/startstopv2-deployments/blob/main/README.md#enable-multi-subscription-support

[oramoss]

Was already Contributor on the two subscriptions (the one in which the Function App is installed and one it is not installed).

[balas77]

Are they in same tenant?

[oramoss]

Yes, same tenant.

[balas77]

Just now tried to test the same behavior on our side and it works fine. Probably next step is to find the logs from the function/monitor (as mentioned in the below link) to figure out whats going on.

https://docs.microsoft.com/en-us/azure/azure-functions/start-stop-vms/troubleshoot

[oramoss]

Article suggests looking through logs for the "Scheduled" HTTP function...there are no errors showing against that function, for it's entire history.

Screen only shows logs for last 20 invocations so I click on Run query in App Insights to see the older ones...I find the ones that relate to the errored run and they show the same 500 return code but there are no details of logs/messages to dig into...doesn't seem to help.

Leave with me to dig...

[balas77]

Can we have a quick call in teams? Would like to see whats going on and help you to unblock. Not sure what time zone you're currently in but can meet either today or Monday so please let me know.

[oramoss]

Hi

I could do a call on Monday sometime - I'm in UK so it's now 19:31 here.

Thanks
Jeff

[balas77]

Cool then I will setup meeting on our Monday morning 10am March 3rd which will be 6pm monday your time, rite? can you please share your email id to invite you?

[oramoss]

[email protected] 6pm Monday UK time is fine

[balas77]

Hey Jeff,

Thanks for joining the meeting. I am happy to say that we have fixed the bug and updated the package and thanks for helping us to find this bug.

We haven't tested this in a subscription where classic provider was disabled/not supported which is the root cause of this issue.

Will it be fine for you to do the new deployment of this solution? Our Auto-Update feature (which allows customer to get the updates without re-installing) is disabled for now hence asking you to re-install in a new resource group.

After installing please give it a try and update us on the outcome!

[oramoss]

Will try shortly....

[oramoss]

That worked, at least to use scheduled start/stop to start a VM in the Development Spoke, from the Hub installation.

A couple of issues:

1. When I installed I first removed all resources from the target resource group (where I install this facility). The resource group was then empty prior to installing. The deployment ran with errors - image below. Complaints about inability to change scope...not sure why...but the facility worked for scheduled start/stop as I say.
2. When running across subscriptions - as I tested - you advise giving Contributor role at Subscription level, to the Function App. Can we be a little less generous on the privileges - least privileges principle wise?
   

[balas77]

Glad that it works finally!

Comments on your points

1. I think that error is ok for now. The recommended way is to delete the RG instead of deleting the individual resource. These alerts/queries wont show up in the RG hence when you redeploy in the same RG it was unable to override hence that issue. I will check and improve the experience.
2. Thanks for the feedback. I will explore the options on this. Probably "Virtual Machine Contributor" would be the fit but today we are doing few other operations like cost savings which needs to call other API's etc which might benefit of having the generic contributor perms.

[oramoss]

Yeah, I did just remove the resources in the RG rather than the RG itself - fair enough. Maybe if I'd checked show hidden I would have seen them and removed them as well.
No problem - for now Contributor is fine but clearly better if it can be locked down in time.

Many thanks for the swift response of your team.
Regards
Jeff

[balas77]

Thanks & happy to work with you Jeff! I will go ahead and close this issue!