To call cmdlets, create a rule which adds the PSExecute containing the PowerShell command string.
The Office 365 driver looks for the PSExecute attribute in the input XDS code, reads any cmdlets embedded in a <value/> tag, and sends those commands to the Exchange Online service running on the Active Directory server. The Active Directory server executes the commands sequentially using a programmatic PowerShell interface.
NOTE:When including the PSExecute attribute in an Add or Modify event policy, you must adhere to the XDS format, or the driver ignores the embedded cmdlets.
You can create a rule in the Office 365 driver policy to allow an administrator to send PowerShell cmdlets to the driver for execution.
Example 8-1 The following example rule includes a PowerShell cmdlet in an Add event:
<policy>
<rule>
<description>PowerShell cmdlet with add</description>
<conditions>
<and>
<if-operation op="equal">add</if-operation>
</and>
</conditions>
<actions>
<do-add-dest-attr-value name="PSExecute">
<arg-value type="string">
<token-text xml:space="preserve">Get-MSolUser -UserPrincipalName acmeUser@example.onmicrosoft.com | fl * | Out-File c:\msu1.txt</token-text>
</arg-value>
</do-add-dest-attr-value>
<do-add-dest-attr-value name="PSExecute">
<arg-value type="string">
<token-text xml:space="preserve">Get-Mailbox</token-text>
</arg-value>
</do-add-dest-attr-value>
</actions>
</rule>
</policy>
You can also create rules to include PowerShell cmdlets in Modify events. However, if you include a cmdlet in a Modify event, ensure that you use the XDS format for constructing that type of event and including the PSExecute attribute
<policy>
<rule>
<description>Powershell cmdlet in modify</description>
<conditions>
<and>
<if-operation op="equal">modify</if-operation>
<if-op-attr name="Title" op="equal">manager</if-op-attr>
</and>
</conditions>
<actions>
<do-add-dest-attr-value name="PSExecute">
<arg-value type="string">
<token-text xml:space="preserve">Get-Mailbox</token-text>
</arg-value>
</do-add-dest-attr-value>
</rule>
</policy>
Similarly, you also can create a rule to use the PoweShell cmdlets. The following is the sample output for pwd powershell cmdlet.
<status level="success" event-id="0" type="powershell" />
<instance class-name="PowerShell" event-id="0">
<attr attr-name="Drive">
<value>C</value>
</attr>
<attr attr-name="Provider">
<value>Microsoft.PowerShell.Core\FileSystem</value>
</attr>
<attr attr-name="ProviderPath">
<value>C:\Novell\remoteloader.NET</value>
</attr>
<attr attr-name="Path">
<value>C:\Novell\remoteloader.NET</value>
</attr>
</instance>
However, the execution of wrong powershell cmdlet pwdi displays output similar to this:
<status level="error" event-id="0" type="Powershell">The term 'pwdi' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. </status>
The following is a sample query XDS in PowerShell that allows an administrator to search for Microsoft Online users.
<query class-name="MSolUser" event-id="0"
scope="subordinates">
<search-class class-name="PowerShell"/>
<search-attr attr-name="psexecute">
<value>get-msoluser</value>
</search-attr>
</query>
To use cmdlets in Identity Manager, first use Designer to create a new policy in the Office 365 driver. For more information about creating policies in Designer, see NetIQ Identity Manager - Using Designer to Create Policies and NetIQ Identity Manager Understanding Policies Guide.
After you create a new policy, add a rule to the policy that includes an add destination attribute value action to create the PSExecute attribute, which calls one or more PowerShell cmdlets. You can include several cmdlet strings in multiple value tags for a single PSExecute attribute, as necessary.
To configure the rule using the Policy Builder, complete the following steps:
In Designer, right-click the policy in the Outline view and select Edit.
In the Policy Builder, select the location where you want to create the PSExecute attribute.
In the toolbar, click Rule and select Action > Insert Action After.
In the Do field under Define new action below, select add destination attribute value.
Specify PSExecute as the attribute name.
In the Select mode field, select add to current operation.
In the Select object field, select Current object.
In the Specify value type field, select string.
In the Enter string field, specify the PowerShell command string you want to use, enclosed in quotation marks.
Click OK.
Save the policy.
When specifying the PowerShell command string, you can include other variables configured in separate actions within the rule, as necessary.
For example, for the sample policy provided in Sample Office 365 Policy Rule for Executing Cmdlets, you first add a rule to define the variable identityname as the name of the user account you want to disable using a PowerShell cmdlet, and then you specify the following string for the PSExecute variable, which uses the new identityname variable in the PowerShell command string:
"Disable-ADAccount -Identity"+Local Variable("identityname")
NOTE:You can also configure a policy to execute a specified cmdlet by modifying the XML directly, in the XML Source tab of the Policy Builder.
When a PowerShell cmdlet runs successfully, the Active Directory returns a specific success event in the output XML, with the type powershell. After you run a cmdlet, check the output XML file for the following event:
<status level="success" event-id="linux-djs#20120510164317#1#2:facdcbbb-d440-4340-1b85-bbcbcdfa40d4" type="powershell"/>
If the PowerShell cmdlet does not run successfully, the driver instead logs an error event in the output XML. The error message includes the reason for the failure and looks similar tot he following:
<status level="error" event-id="0" type="Powershell">The term 'pwdi' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. </status>
NOTE:If you execute multiple cmdlets in a single rule and one of the cmdlets does not run successfully, the driver does not execute any subsequent cmdlets in the rule and only logs the error event for the failed cmdlet. The driver does not log error events for the subsequent cmdlets, even though they did not run successfully, because the driver does not run those cmdlets after the failure occurs.