Start with TID7012362, I know it's not perfect but the subject is so
complex (for me it is) that I'd have to write a novel to cover it.

You problem ties into two problems; Local RunSpace and Remote RunSpace.
This is why you are seeing this specific problem, and you cannot do this
with Exchange 2013 onwards.

Prior to Exchange 2013 (here I only have interest in Exchange 2010) we
where using the "normal" Exchange Service which would load the Exchange
Powershell environment into Local Runspace (which also creates
limitations), but it would allow us to run AD cmdlet's in the same
command as Exchange cmdlet's.

With the change to the Powershell Service with Exchange 201x (also works
with Exchange 2010), it will use Remote Runspace, which means that: 1)
we connect to the powershell on the Exchange Server we talk to, 2) we no
longer can make use of local cmdlet's (like AD).

So, the non-powershell give the option to use all cmdlet's, but have a
limitation on the rights required to do so (require elevated rights),
and the powershell service will run with limited rights, but cannot run
local cmdlets (ie. it will only work with exchange cmdlets).

As for rights, I am only talking about Exchange Rights.

But the limitation of Local- and Remote Runspace is what is causing your

So the short answer is that with the current implementation you cannot
mix Exchange 2013 Cmdlet's and AD Cmdlet's.

If that is an requirement, then you'll have to use the Scripting Driver.


On 6/20/14, 6:44 PM, bprulhiere wrote:
> I work with Exchange 2013 and I have installed the IDM Powershell
> Service on the server where the AD remote Loader is installed.
> Casper Pedersen;245743 Wrote:
>> Right, you need to provide a bit more information:
>> - which version of Exchange ?
>> - which Exchange Service are you using (looks like PowerShell but I
>> need
>> to be sure before I can tell you why this happens) ?
>> This is very important, as they behave differently.
>> On 6/20/14, 5:34 PM, bprulhiere wrote:
>>> Hi,
>>> I try to create Linked Mailbox in an AD driver.
>>> I have an AD driver connected to the User Domain.
>>> I have an other AD driver (+ PowerShell Service) connected to the
>>> Ressource Domain.
>>> In this driver, there is the following rule :
>>> Code:
>>> --------------------
>>> <rule>
>>> <description>Adding PSExecute to Create Linked

>> Mailbox</description>
>>> <comment xml:space="preserve">Adding PSExecute to Create Group

>> Mailbox</comment>
>>> <conditions>
>>> <or>
>>> <if-operation mode="regex" op="equal">add</if-operation>
>>> </or>
>>> </conditions>
>>> <actions>
>>> <do-set-local-variable name="lvUPN" scope="policy">
>>> <arg-string>
>>> <token-src-attr name="userPrincipalName"/>
>>> </arg-string>
>>> </do-set-local-variable>
>>> <do-set-dest-attr-value name="PSExecute">
>>> <arg-value type="string">
>>> <token-text xml:space="preserve">Enable-Mailbox �Identity

>> </token-text>
>>> <token-local-variable name="lvUPN"/>
>>> <token-text xml:space="preserve"> -LinkedDomainController

>> �Domain� -LinkedMasterAccount </token-text>
>>> <token-local-variable name="lvUPN"/>
>>> <token-text xml:space="preserve">

>> �LinkedCredential(New-Object System.Management.Automation.PSCredential
>> ("adm", ("Pwd" | ConvertTo-SecureString -AsPlainText
>> �Force))))</token-text>
>>> </arg-value>
>>> </do-set-dest-attr-value>
>>> </actions>
>>> </rule>
>>> --------------------
>>> I tested the Powershell command on the Exchange Management Shell and

>> it
>>> works well but with IDM I have the following error :
>>> Code:
>>> --------------------
>>> Error completing powershell command. ERROR: The term

>> 'New-Object' 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
>>> --------------------
>>> Does the IDM powershell service causes limitation about the use of
>>> cmdlet ?
>>> Thanks,