PowerShell API Wrapper Tutorial

Revision as of 13:12, 17 February 2014 by Bmeyn (talk | contribs) (Created page with "__NOTOC__ ++ Under construction ++ This tutorial aims to explain the usage of the MailStore Service Provider Edition Management API through...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

++ Under construction ++

This tutorial aims to explain the usage of the MailStore Service Provider Edition Management API through simple Windows PowerShell example scripts. Basic knowledge of MailStore SPE, Windows and PowerShell is a necessary precondition.

The API wrapper used in this tutorial is an example implementation of a MailStore SPE Management API client. As communication with the Management API is done via web requests, it is possible to create different implementations that use the corresponding PowerShell cmdlets. However, such implementations are out of scope of this tutorial.

Please note: It is strongly recommended to use a non-productive test environment for this tutorial as well as for script development in general, in order to prevent loss of data or other problems.

Installation of Necessary Components

The examples demonstrated here use the MailStore PowerShell API Wrapper and are compatible with Windows PowerShell 3.0 and higher. Depending on your version of Windows it might be necessary to download and install a compatible version of PowerShell first. You can find the components necessary for this tutorial here:

Please take note of the system requirements and further notices for the respective version of the Windows Management Framework.

Important Notice: Installation of a Windows Management Framework on systems that require a specific version of Windows PowerShell, such as Microsoft Exchange Servers, is not supported and may lead to massive system failures and data loss.

After downloading and installing Windows PowerShell (if necessary) please unzip the MailStore PowerShell API Wrapper and the example scripts (to C:\MailStore SPE Scripting Tutorial\PowerShell\ by default).

Neither the MailStore PowerShell API Wrapper nor the example scripts are digitally signed, therefore execution of such scripts has to be enabled in an administrative PowerShell session using

  Set-ExecutionPolicy -ExecutionPolicy Unrestricted

Importing the MailStore PowerShell API Wrapper

The MailStore PowerShell API Wrapper is implemented as a PowerShell Script Module (MSSPE.PS.Lib.psm1) and can thus be imported in a PowerShell session via its manifest (MSSPE.PS.Lib.psd1) by using Import-Module.

Please open a PowerShell session and import the API wrapper module using this command:

  Import-Module "C:\MailStore SPE Scripting Tutorial\PowerShell\API-Wrapper\MSSPE.PS.Lib.psd1"

Getting Information about the MailStore PowerShell API Wrapper

The MailStore PowerShell API Wrapper provides several functions to access the MailStore SPE Management API, following PowerShell conventions. Enter the following command to get information about these features:

  Get-Module MSSPE.PS.Lib | fl

Via the module's properties, more detailed information can be gained. For example,

  (Get-Module MSSPE.PS.Lib).ExportedFunctions

returns the functions provided by the module. Via

  Get-Help *MSSPE*

the MailStore PowerShell API Wrapper returns inline help for all its functions.

Calling API Wrapper Functions

The following example script (Example1.ps1 in the tutorial package) explains the basic usage of MailStore PowerShell API Wrapper functions.

  Import-Module '..\API-Wrapper\MSS.PS.Lib.psd1'
  $msspeapiclient = New-MSSPEApiClient -Username "admin" -Password "admin" -ManagementServer "localhost" -Port 8470 -IgnoreInvalidSSLCerts
  $return = Invoke-MSSPEApiCall $msspeapiclient "GetEnvironmentInfo"
  $return.Data.result | fl

The function New-MSSPEApiClient creates a new API client object which the Invoke-MSSPEApiCall function uses for API calls. The values for -Username and -Password have to be supplied, while -ManagementServer defaults to "localhost" and -Port defaults to "8470". The switch -IgnoreInvalidSSLCerts has to be set if untrusted certificates are used; otherwise an error occurs.

Apart from the API client object, Invoke-MSSPEApiCall needs an API command and its parameters if applicable. The command GetEnvironmentInfo in the script does not have any parameters and returns an object as follows:

 Type  : JSON
 Token : 
 Data  : @{error=; token=;
           antiXsrfToken=3bbMS5ztVju5lUE7FQLUFG7CbXzDKdrGjPfQCGFkbWlu;
           statusVersion=2; statusCode=succeeded; percentProgress=;
           statusText=; result=; logOutput=}

The object's Type property has the value "JSON" for synchronous API commands or "JOB" for asynchronous API commands (see below); it characterizes the type of the object contained in the Data property. The Token property is only relevant for asynchronous API commands.

The Data property contains a JSON status object returned by MailStore SPE:

 error           : 
 token           : 
 antiXsrfToken   : 3bbMS5ztVju5lUE7FQLUFG7CbXzDKdrGjPfQCGFkbWlu
 statusVersion   : 2
 statusCode      : succeeded
 percentProgress : 
 statusText      : 
 result          : @{version=8.5.0.9292;
                     copyright=Copyright (c) 2005-2013 MailStore Software GmbH;
                     licenseeName=MailStore Software GmbH; licenseeID=10510;
                     serverName=demo.msspe.test; userName=admin; systemProperties=}
 logOutput       : 

The result property of that object has the actual return value if the request succeeded as indicated by the statusCode:

 version          : 8.5.0.9292
 copyright        : Copyright (c) 2005-2013 MailStore Software GmbH
 licenseeName     : MailStore Software GmbH
 licenseeID       : 10510
 serverName       : demo.msspe.test
 userName         : admin
 systemProperties : @{processors=System.Object[]; totalPhysicalMemory=4398800896; operatingSystem=Microsoft Windows Server 2012 Standard}
 

Calling API Wrapper Functions with Parameters

For most MailStore SPE Management API commands you need to provide parameters. Of course, the MailStore PowerShell API Wrapper's Invoke-MSSPEApiCall function can submit these parameters, as demonstrated by the following script (Example2.ps1 in the tutorial package):

  Import-Module '..\API-Wrapper\MSS.PS.Lib.psd1'
  $msspeapiclient = New-MSSPEApiClient -Username "admin" -Password "admin" -ManagementServer "localhost" -Port 8470 -IgnoreInvalidSSLCerts
  $instances = (Invoke-MSSPEApiCall $msspeapiclient "GetInstances" @{instanceFilter = "*"}).Data.result
  foreach ($instance in $instances) {
    $users = (Invoke-MSSPEApiCall $msspeapiclient "GetUsers" @{instanceID = $instance.instanceID}).Data.result
    foreach ($user in $users) {
      (Invoke-MSSPEApiCall $msspeapiclient "GetUserInfo" @{instanceID = $instance.instanceID; userName = $user.userName}).Data.result | fl
    }
}

The scripts lists details about the users created in a MailStore SPE instance. Because the MailStore PowerShell API Wrapper converts MailStore SPE Management API responses into objects, their properties can be used directly in the script's workflow.

The function Invoke-MSSPEApiCall expects parameters as a hashtable, e.g. @{parametername1 = value1; parametername2 = value2;...}. Parameter names are case sensitive.

First, a list of all MailStore SPE instances is requested with the API command GetInstances which returns an array of instances as follows:

 instanceID     : test01
 alias          : test1
 displayName    : test01
 instanceHost   : demo.msspe.test
 startMode      : automatic
 processID      : 3140
 status         : running
 startStopError : 

The script now iterates over this array using the instanceID property of each entry as a parameter for the API command GetUsers. The list of users of each instance is then also iterated over and each user's properties is requested via GetUserInfo:

For the entry listed above the result could be as follows:

 userName            : johndoe
 fullName            : John Doe
 distinguishedName   : 
 authentication      : integrated
 emailAddresses      : {}
 pop3UserNames       : {}
 privileges          : {login, changePassword}
 privilegesOnFolders : {@{folder=johndoe; privileges=System.Object[]}}

As can be seen in the privilegesOnFolders property, returned objects may be nested and may also contain further objects.