Set-AzureAutomationSchedule is bugged - "The start time of the schedule must be at least 5 minutes"...

We host our development servers in the cloud, and to save serious  bucks, they only run during office hours (50 hours a week out of the the 168, thats a nifty 70% saving).

There are two azure automation tasks, one shuts down the computers every evening, and another starts them up half an hour before anyone gets to the office.

However, overtime happens, so there is also a script that each developer can run that delays the evening shutdown with a couple of hours. This basicly disabled the evening shutdown Automation Schedule, and the morning startup script turns it back on.

This is the theory.

In practice, Set-AzureAutomationSchedule is a piece of crap and doesn't work half the time. When I try to set the status of a perfectly valid schedule, I encounter the following error message;

Set-AzureAutomationSchedule -AutomationAccountName maintenance -Name "Evening shutdown" -IsEnabled $true Set-AzureAutomationSchedule : The start time of the schedule must be at least 5 minutes after the time you create the schedule.

Mind you, the script works on the first day when you create the schedule, only later does it stop working.

The workaround is simple; instead of enabling and disabling the schedule, I simply drop and recreate it.

Things to do before uploading a VHD to Azure

I recently had to upload several virtual machines into azure. No sysprep, no image creation, just moving a domain consisting of a couple of virtual servers and a DC into the cloud.

After uploading the disks, creating a virtual network, creating virtual machines etc I got the following super annoying message.

Remote Desktop can’t connect to the remote computer for one of these reasons:1) Remote access to the server is not enabled 2) The remote computer is turned off 3) The remote computer is not available on the network

Neither restarting, nor recreating the machines, nor resizing the machines, nor deleting the RDP endpoint and recreating it helped (if you encounter the same error try these steps nevertheless)

After a bit of trial and error I created the following checklist for future endeavours, maybe it will help you as well. 

1. Enable Remoting in System/Remote settings (well duh)
2. Open incoming TCP on port 3389 in the firewall for all network profiles. (Or just turn the whole windows firewall off, Azure doesn't allow any incoming traffic anyway)
3. Install Azure VM Agent (from here for example). It seems like if you don't do this you will be stuck on the "Installing VM extensions" step of creating the virtual machine

My experience had been that I could only log in after the Installing VM Extensions step completed.