Microsoft Azure: Configuring Azure PowerShell for OpsMgr to Monitor Azure Subscriptions & Services

The goal here is to allow the SCOM agent to be able to run a PowerShell script (with a run-as account) that uses Azure PS cmdlets with a Microsoft Azure management certificate to obtain the subscription information for monitoring or alerting purposes in System Center Operations Manager. Furthermore, once OpsMgr is able to retrieve the subscription information, it can also be converted to monitoring data and stored in the OpsMgr databases, for reporting or dashboarding.

Here is an example of a summary dashboard for certificate monitoring authored for OpsMgr using the monitoring data (health states, alerts) obtained from the Azure Subscription.


By default, the SCOM agent uses the Local System Account (nt authority\system) as its default action account.
For simplicity, the following steps shows how to allow the SCOM agent to use the Local System Account to run a PoweShell script that uses Azure PS cmdlets with a management certificate in order to obtain the subscription information.
For a more secure approach, use a domain account as the SCOM agent’s run-as account for the related workflows instead of using the Local System Account.

Managing Run As Accounts and Profiles: 

The following guide was used as a reference:
How to install and configure Azure PowerShell:

  1. Download and install the Microsoft Web Platform Installer (WindowsAzurePowerShell.3f.3f.3fnew) on the agent managed server that would be used to run the Azure PowerShell Cmdlets.
    The agent managed server can be an Azure Monitoring Gateway server as follows:

  2. Open a PowerShell session under the local system account (nt authority\system):       
    You can run psexec in a CMD prompt to open a PowerShell session under the local system account:
    psexec -i -s powershell.exe

  3. To use the certificate method to connect to your subscription, run the Get-AzurePublishSettingsFile cmdlet, it opens the Azure Mgmt Portal.

  4. Sign in with an Azure account.

  5. When prompted, download and save the publishing profile and note the path and name of the file.

  6. Run Import-AzurePublishSettingsFile <.publishsettings file> to import the settings.

  7. Observe in mmc certificate created for the user account:


  8. For the local system account, the AzureProfile information file can be located at the following location:

    Otherwise, for other types of user accounts, they would be in C:\Users\[User]\AppData\Roaming\Windows Azure Powershell.

  9. Run Get-AzureService and it should list all the Azure services of the subscription.

Important Note:
When you use the certificate method, the subscription information is available as long as the subscription and the certificate are valid. However, this method makes it harder to manage access to a shared subscription, such as when more than one person is authorized to access the account.

Account-based authentication relies on tokens issued by an authentication provider, and the authentication provider chooses the lifespan of the token, which could be as short as a day or as long as weeks. When the token expires, a user will need to sign in again. If you need persistent client access to service management functions–for example, for long-running integrated deployment scripts or code projects–certificate-based management may be the right choice.


Just in case you want to run the Get-Module cmdlet, the Azure PowerShell’s PSD1 file can be located at: C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure

get-module ‘C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Azure.psd1’


Additional Information:

Windows Azure Deployment – Problem and Solution #2

What’s the difference between account-based authentication and certificate-based authentication, and can I still use certificate-based authentication?    

All information on this blog is provided on an as-is basis with no warranties and for informational purposes only. Use at your own risk. The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of my employer.