Azure Automation – Creating your Automation Credential

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.

Sending email from SharePoint on-premises via Office 365 – Client SMTP Submission

Installing a local SMTP Relay

The first step is to install an IIS SMTP server that will be used for relaying messages from SharePoint. This can be accomplished by using the ‘Add Roles and Features’ wizard, after completion will add a new option “Internet Information Services (6.0)” in the Server Manager ‘Tools’ menu. This is the interface by which we’ll configure the SMTP server, pictured below:

 

Configure SMTP Virtual Server Settings

By default the server listens to all addresses on port 25 which is the default SMTP server port, and Anonymous access is enabled; no changes are required to either of those items for our scenario. However, to ensure that we don’t relay messages from any machine we’ll limit the systems that are able to connect to and send through our server. From the “[SMTP Virtual Server #1] > Properties > Access” tab, click the “Connection” button which brings up the following window:

 

Be sure to specify the IP Address of each of the servers from which messages will be sent. Typically, multiple IP addresses are bound to each SharePoint server to support SSL bindings – be certain to list each of the addresses. In this screenshot, we’ve configured the SMTP Server to allow connections from two of our SharePoint servers.

Next, we’ll also ensure that only our two systems are allowed to relay messages through the SMTP server, which is accomplished by clicking on the “Connection” button on the same “Access” tab of the server properties. Note that we have the same two IP addresses listed, allowing only those two machines to relay:

 

From here, we need to configure the Office 365 mailbox username/password that the SMTP Server will use when sending messages. This is configured in the “Delivery” tab, using the “Outbound Security” button. Be sure to enter valid credentials for your Office 365 user, and if it’s a newly-created user make note that you’ll need to change the initial password on first login. If you don’t do this, mail will not send despite your best efforts!

 

Next we need to tell the server to use TCP port 587 when attempting to connect to Office 365, which is set in the “Outbound Connections” option of the “Delivery” tab:

 

Lastly, we need to specify which server to send mail through, and we do this by clicking the “Advanced” button on the “Delivery” tab. Be sure to specify the smart host as smtp.office365.com and clear the option to “Attempt direct delivery before sending to smart host”: this will ensure that all outbound mail will be sent via Office 365:

 

Configure Outgoing E-Mail Settings in SharePoint

Finally, we need to let SharePoint know about our new SMTP Server, which is done via Central Administration > System Settings > Outbound E-Mail Settings, as pictured below. Note that I’ve blurred out the values to protect the innocent, but you need to be certain to specify the servername, and your Office 365 mailbox user in the From address.

 

At this point, we’re ready to test our configuration and we’ll use PowerShell on the SharePoint server to do so. This way we can be sure that each component in our configuration is working, from the SharePoint settings through to the Office 365 mailbox. Open a SharePoint Management Shell and run the following PowerShell snippet:

$sdo = new-object System.collections.specialized.stringdictionary $sdo.add("to","raymond@dynamicowl.com") $sdo.add("from","sharepoint@office365domain.com") $sdo.add("Subject","Test message from SharePoint") $web = get-spweb "https://intranet" $messagebody = "This is a test message from SharePoint on-prem" [Microsoft.SharePoint.Utilities.SPUtility]::SendEmail($web,$sdo,$messagebody)

The output of the command will return “True” (and you’ll receive an email message) if it was successful; “False” indicates that something has gone wrong and the message was not delivered.

When things go wrong

In our experience, there are a few items that you’ll want to verify if outbound email is not flowing as expected, including:

  • the SMTP Server service is set to “Manual” start by default; be sure to change this to “Automatic” so that the service starts upon a reboot of your server
  • the Windows Server may require a server certificate in order for TLS to be used; this will generate an error in the Event Log and be evidenced by the SMTP Server Properties “Secure Communication” section of the “Access” tab indicating that no certificate can be found for TLS

Conclusion

E-mail is still a critical communication method in today’s business world, and moving email services to the cloud is more common than ever. We can still send email from an on-premises SharePoint server via Office 365 by setting up a local relay and sending mail from an Office 365 mail-enabled user.