Tips to avoid and resolve common issues in Azure Automation

Azure Automation is a software as a service (SaaS) application that provides a scalable and reliable multitenant environment in which you can use runbooks to automate processes. There are many tricks you would need to know before you could enjoy this feature.

x

1. The first tip is to handle "Automation Account" creation error. The common issue is the error Classic Run As account creation error like "Classic Run As Creation Error ForbiddenError: The server failed to authenticate the request.".

The way to resolve this is to add the Azure Account as co-administrator or the administrator of the subscription. The procedure is described here.

You can then delete the Classic Run As Creation and then recreate it.

2. The second tip is to handle certificate expiration. Azure automation certificates expire in one year.

You will get error message when it expires. You can renew from the UI or run the powershell to set never expire. The example PowerShell is listed here.  Here are some detailed information.

a. Run PowerShell Login-AzureRmAccount to get "Environment" variable.

b. Run PowerShell to get "SubscriptionId" and "AutomationAccountName".

Install-Module -Name AzureAutomationAuthoringToolkit 

Get-AzureRmAutomationAccount -ResourceGroupName "yourresourcegroupname" 

3. The third tip is to update default modules. The default modules for Azure Automation is old version and may functions may not exist for that version, you need to manually click "Update Azure Modules" in the "Modules". Here is the default modules and you can see most of the modules are in version 1.

Here is the screenshot after updates.

There are few other tips already covered in previous blog.

This link walks you through the pricing model of everything available in Azure.

Here are some documents about Update Management, which uses Log Analytics. 

• Hybrid Runbook Workers: https://docs.microsoft.com/en-us/azure/automation/automation-hybrid-runbook-worker
• Update Management: https://docs.microsoft.com/en-us/azure/automation/automation-tutorial-update-management
• Creating Runbooks: https://docs.microsoft.com/en-us/azure/automation/automation-creating-importing-runbook
• PowerShell Runbooks: https://docs.microsoft.com/en-us/azure/automation/automation-first-runbook-textual-powershell

Three different ways to use NextLabs 8.5 policy to block SharePoint site collections

NextLabs 8.5 provides new policy module to block SharePoint site collections. Here are three most popular ways to block SharePoint site collections.

1. Use Resource Components with site url. 

You can add one site collection url to one resource component and the policy can include multiple Resource Components to clock multiple site collection. See screenshots below.

2. Use expression in advanced condition in the policy.

You can add expression on the urls in advanced condition in the policy as in the below screenshot.

3. Use SharePoint site collection site property bag value or sub-site web property value.

a. First, add the SharePoint site collection site property bag key in the SharePoint Enforcer configuration.xml file.  Bounce the enforcer after the change.

Example is below.

    <PropertyBag disabled="false" level="SiteCollection">
      <Property disabled="false" name="SensitiveSiteCollection" attributename="SensitiveSiteCollection" />
    </PropertyBag>
    <PropertyBag disabled="false" level="SubSite">
      <Property disabled="false" name="SensitiveSubSite" attributename="SensitiveSubSite" />
    </PropertyBag>

b. Add the property to site collection property bag.

c. Construct the component resource in condition with the property bag. Then use the component resource in the policy.

Based on our testing, the option #3 is much simple than other two options. We will implement option #3 in the future for most of the policies. Of cause, the site collection bag can be modified by site owner and the policy can be impacted. As a result, we will need to address the property bag seciruty control if we use option #3.

Procedure to add IP condition for NextLabs policy on version 8.5

If you need to block/allow SharePoint request based on the original user request IP address, here are the procedures.

1. Go to the following web site and convert IPv4 to IP Decimal.

https://www.ipaddressguide.com/ip

2.  Create a resource component. In the conditions, add "inet_address" condition with the decimal value of the IP address from step #1. Then create the policy to include the resource component.

3. If you need to test the original IP in "X-Forwarded-For" that is in the request header but not in the direct request, you can use the "Modify Header Value" add-in for your testing. The screenshots are listed below.

Now you can test any http request header in the NextLabs policy.

Procedure to add IP range like sub-net for NextLabs policy on version 8.5

If you need to block or allow SharePoint request from certain sub-net, here are the procedures.

1. Create the locations file. This is a text file containing any number of location definitions, one per line. Each line has the format    

<LocationName> “<AddressMask>”

where <LocationName> is the name by which you want to refer to the site when referring to it in Control Center tools such as Policy Studio Desktop Client, and <AddressMask> is a CIDR-like mask for the 32-bit IP address of a machine that is in the given location. Note the following requirements:

• Each address mask must be enclosed in double quotes

• The location name may not contain spaces

• The two elements must be separated by a space

For example, to define a location called VPN that represents all PCs connecting through a virtual private network, you might create the following entry:    

VPN "192.168.254.0/24"

Create additional similar lines for all the other hosts that are part of the VPN group. Here is another example:    

intranet “10.0.0.0/8”

You can also put comments in the file by beginning each comment line with #. For example:

# The following lines define the machines in the

# Boston office 

2. Install the location and run import locations utility.

Change to the directory <InstallDir>\tools. By default, the directory is: \Program Files\NextLabs\PolicyServer\tools\ 

Run the Import Locations utility with appropriate values for all parameters, as shown in the following example. This line must provide the name and path of the locations file and connection information for the system database. The last parameter, -i, is required only if the database type is Oracle or SQL Server.

importLocations.bat -l <LocationsFile> -u <DB_user> -w <DB_password> -s <DB_server> -p <DB_port> -d <oracle|postgres|sqlServer> [-i <instance>]

Example is:

importLocations.bat -l locations.txt  -u NextlabsDBUser -w nextlabspassword-s SPSQLSBX -p 1433 -d sqlserver -i NextlabsDB

When the utility finishes running, all the locations defined in the input file are present in the Information Network Directory. You will see ‘Success’ after running the command.

You can use the enrolled sites as values for the Site property when defining Computer components in Policy Studio. 

3. Create the policy using the required subject and resource and action components. Add the Advanced Condition as below.

After save and deploy, you can use this policy. For more information, check "NextLabs Control Center Unified UI Edition Administrator’s Guide".

Tips to use Azure Automation for SharePoint online with PowerShell

Azure Automation delivers a cloud-based automation and configuration service that provides consistent management across your Azure and non-Azure environments. It consists of process automation, update management, and configuration features. Azure Automation provides complete control during deployment, operations, and decommissioning of workloads and resources. This article provides a brief overview of Azure Automation and answers some common questions. For more information about the different capabilities, visit the links throughout this overview.

We have a project that requires a back end scheduled job using PowerShell scripts to process many SharePoint online list items and send notifications. We have evaluated the Azure function, Webjob, and Azure automation. Azure automation looks like the best fit. Since this is the first time we are using Azure automation, there are few tips we would like to share so you could jump start this good feature. You should check best practice here first before going forward.

1. How to import packages required for PowerShell?

Since we need to use Microsoft.SharePoint.Client CSOM packages, we need to to use two package dlls listed below.

Microsoft.SharePoint.Client.dll

Microsoft.SharePoint.Client.Runtime.dll

This is the way to upload the packages to Azure. You need to zip the dlls into a single zip file. I've zipped them into one file named Microsoft.SharePoint.Client.zip.

Then search the "mudule" in the Azure automation account. Click "Add a mudule". Select the zip file you like to add. The module will be uploaded for you to use as listed below.

2. How to refer the dlls uploaded to module?

You can refer the dlls using the following syntax. Please note the uploaded zip file name "Microsoft.SharePoint.Client" in the path.

Add-Type -Path "C:\Modules\User\Microsoft.SharePoint.Client\Microsoft.SharePoint.Client.dll"

3. How to use encrypted password in the scripts?

In most cases Azure automation needs to connect to external system with user name and password. We could save the password in the Azure automation account object "Credentials". You can add a credential as in the below screenshot.

Then you can use the password in the PowerShell like this.

$creds = Get-AutomationPSCredential -Name 'halotest' 

$userName = $creds.UserName

$password = $creds.Password 

$cred = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($userName, $password)

$ctx.Credentials = $cred

4. How to write the standard output?

You need to change "Write-Host" to "Write-Output" to print out to console. One example is listed below.

write-Output "Connection to SPO successfully " $web.Title

5. How to invoke other PowerShell from PowerShell?

You need to create PowerShell runbook for each PowerShell first. Then refer the other PowerShell like listed below. Please note the slash instead of back slash.

./AnotherPowerShelll.ps1 

Please note the PowerShell refereed need to be published first!

Now, you should have few PowerShell to run and configure as schedule job.