Thursday, February 5, 2015

Automating Azure Cloud Service VM Start and Stop

Through my travels I've come to learn of some great automation features in Microsoft Azure lately which have helped me trim some of the compute cost associated with Virtual Machines running during off-business hours.

As an avid consumer of my MSDN monthly Azure credits I found I was consuming compute cost during hours I wasn't working or using the environment and for a long time I didn't bother learning how to use the "Automation" feature in Azure due to the learning curve. I've taken some time to figure out how to use it and offer my findings in this post.

First lets talk about the various components which make up the Automation feature in Azure:

Azure Automation Components

Automation Account: The Automation Account is a placeholder for your other objects which include Runbooks, Assets, Scale configuration, etc.

Assets: An Asset can be a "Connection", a "Credential", a "Variable", or a "Schedule" object which can be linked or referenced in your Runbooks.

Runbooks: The Runbook is essentially the script containing the commands you want to issue to your environment. A Runbook can contain references to Assets such as a reusable "Credential".

Creating your Automation Credential

The newer way of connecting to your Azure tenant from the Automation environment is to use an account in your Azure AD environment, adding it as an Asset (Credential), then referencing it in your connectivity to your environment.
  1. Click on the Active Directory navigation link on the left side of your Azure portal
  2. Click on the Azure AD environment associated with your Azure tenant and click the Users tab
  3. Click the Add User button on the taskbar and add an account called "Azure Automation" with a UPN of "azureautomation@tentantdomain.onmicrosoft.com" 
  4. NOTE: Once you receive the password for the account you must log in at least once to change the password otherwise your Runbook will fail. You can do this by opening a private IE window and logging in to change the password. Remember this password as we will use it to create an Asset shortly.
  5. Click on the Settings link in the left navigation window then click on Administrators
  6. Click the Add button on the toolbar and add your Azure Automation AD account as a Co-Administrator to your subscription
  7. Click on the Automation navigation section and click on your Automation Account
  8. Click the Assets tab and click Add Setting on the toolbar
  9. Choose Add Credential, choose Windows PowerShell Credential, and type a name (i.e. AzureAutomationAccount) and click the Next button
  10. Type the User Name and Password making sure to specify the full UPN (azureautomation@tenantdomain.onmicrosoft.com) and click the Checkmark to complete

Creating your first Runbook...

  1. Click on the Automation link in your Azure tenant, then click the Create button on the toolbar at the bottom of the screen
  2. Give the account a name and set the Region
  3. Click on the account to open it, select the Runbooks tab, then click the New button on the toolbar
  4. Click Quick Create, give the Runbook a name (i.e. StartTestCloudService), give it a description, make sure your automation account is selected, and click on the create link
  5. Click the Runbook which will take you to the Author tab right away

Anatomy of your Runbook script

We need to make a connection to the Azure environment which is done by issuing the following command:

$cred = Get-AutomationPSCredential -Name AzureAutomationAccount

We store the credentials in a variable called $cred which we pass to the function below. This makes it possible for an Administrator to establish a co-administrator ID without giving the password out to another person who might be using the account for scripting purposes.

Add-AzureAccount -Credential $cred

This command will connect to your Azure tenant using the credentials stored in the Asset you created earlier.

Select-AzureSubscription -SubscriptionName "Visual Studio Ultimate with MSDN"

NOTE: Depending on your environment, you may need to change the subscription name to your actual subscription name. So how do you find this information? Well, I suggest downloading the Azure PowerShell tools from: http://azure.microsoft.com/en-us/downloads/#cmd-line-tools. Start the Azure PowerShell tool and log into your account using the Add-AzureAccount function above. After authenticating, type Get-AzureSubscription and note the SubscriptionName parameter's value.

You're now ready to start issuing commands to your VMs. To start VMs in a particular cloud service use:

Start-AzureVM -Name -ServiceName

To stop all VMs in a cloud service, use:

Stop-AzureVM -Name * -ServiceName -Force

Using the "-Force" parameter will ensure the script properly de-allocates your Cloud Service resources including the shared Virtual IP. Without this switch the runbook will fail to shut down all the VMs.

You can save and test your Runbook using the buttons on the bottom toolbar when in "editing" mode to make sure everything is working. When complete, click the Publish button which will allow you now to schedule your Runbook.

Scheduling my Runbook

Now that we've created a Runbook, we want to schedule it to run on a daily basis at 018:00 every day:
  1. Click on the Automation section of your Azure portal and open your Automation Account
  2. Click on your Runbook and click the Schedule tab
  3. Click on the Link button and choose Link to a New Schedule
  4. Specify a name (i.e. 18:00 every day) and click Next
  5. Select Daily and type 18:00 for the time leaving 1 as the recur every value and click the Checkmark
You can go back to your Automation Account then into Assets to view your "Schedule" asset which was created when you clicked the Link button in the above steps.

NOTE: If you need to change the start date, time, or frequency of your Schedule asset it doesn't appear to be and editable object through the UI or Azure PowerShell (i.e. Set-AzureAutomationSchedule) so you likely have to create a new one, link it, and un-link the old one.

That's all for today folks. Enjoy!

Thursday, January 8, 2015

RESOLVED Password write back issue (Event ID 6329 and 32009)

I recently set up a password write-back configuration for a customer giving them the ability to enable self-service resets of their Office 365 users. In testing the password change I could get all the way through the steps up to the point where the password needed to be modified then I would get an error in the web page and Event ID 6329 and 32009 would show up on the DirSync server.


In doing some research I found the MSOL_* account in AD used by DirSync w/password sync needs to have more rights than the default "Domain Users" group gives it. You can either delegate the password change capability or add the account to the "Domain Admins" group in AD. Immediately after doing this I was able to change the password.

Some additional information for reference:
  1. Excellent article on how to enable: http://msdn.microsoft.com/en-us/library/azure/dn683881.aspx
  2. Password write-back configuration steps: http://msdn.microsoft.com/en-us/library/azure/dn688249.aspx
NOTE:
  1. If you have the option in Azure AD Premium requiring users to register before being able to change their password, they must do so before they'll be recognized at the sign-in page (i.e. http://login.microsoftonline.com). For example, if I click on the "Can't access your account" link I'll be taken to https://passwordreset.microsoftonline.com asking for my username and character verification. You will not get past this step if you or your user's haven't registered for the service.
  2. Additionally, you must grant your Office 365 admin account an Azure AD Premium license in order to enable password reset feature(s).
  3. Lastly, it is advised to enter a telephone number on the "General" tab of the on-prem AD user so that the password reset contact method has at least one verification option.