imoberdorf
Visitor.
668 views

Powershell Scripting Service Driver / Exchange commandlets

I have the latest scripting driver & scripting driver service up and running.
But for some reason I cannot load the Exchange commandlets with 'RemoteExchange.ps1'.

As a workaround I still use the deprecated 'Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn' command.
This works well (Exchange provisioning works flawlessly) and makes believe that the general service combo driver/service is setup properly.

My current setup:
IDM 4.6SP1
Exchange 2016
scripting driver running as local system user on Exchange 2016 server
Script command running as local system user on same Exchange 2016 server
IDM Exchange driver appears to be correct and 'bin\scriptclient.exe' is executed.

scriptservice.conf:
-----------------------------------
-address localhost:8198
-nosecurity
-command . "C:\Program Files\Novell\WSDriver\scripts\powershell\scriptservice.ps1"
-----------------------------------

"C:\Program Files\Novell\WSDriver\scripts\powershell\scriptservice.ps1"
-----------------------------------
Get-Date > c:\Windows\Temp\test.txt

. "C:\Program Files\Microsoft\Exchange Server\V15\Bin\RemoteExchange.ps1"

Get-Date >> c:\Windows\Temp\test.txt

# Workaround, since above RemoteExchange.ps1 does not work, script appears to stop here (only one timestamp in the test file)
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

Get-Date >> c:\Windows\Temp\test.txt

Connect-ExchangeServer -auto -ClientApplication:ManagementShell

Get-Date >> c:\Windows\Temp\test.txt
------------------------------------

What am I missing?

What is the recommended setup?
- under what account should I execute the scripting driver (local system vs. local user vs. AD user)
- under what account should I run the scripting service (local system vs. local user vs. AD user)

What else should I check?
Labels (1)
0 Likes
6 Replies
Highlighted
Knowledge Partner
Knowledge Partner

Re: Powershell Scripting Service Driver / Exchange commandlets

imoberdorf <imoberdorf@no-mx.forums.microfocus.com> wrote:
> I have the latest scripting driver & scripting driver service up and running.
> But for some reason I cannot load the Exchange commandlets with 'RemoteExchange.ps1'.
>


I generally avoid installing the whole Exchange management tools route. The
exchange admins patch their environment and forget to notify the IDM types.
So the management tools installed get stale and IDM integration stops
working.

I use a powershell remoting session to retrieve “just enough” of the
Exchange cmdlets. Often this is via loopback to same server as the
Scripting driver is installed on.

> As a workaround I still use the deprecated 'Add-PSSnapin

Microsoft.Exchange.Management.PowerShell.SnapIn' command.
> This works well (Exchange provisioning works flawlessly) and makes

believe that the general service combo driver/service is setup
properly.
>


This is unsupported because it bypasses the Exchange RBAC model. So that
working but not the "official" way suggests a problem with setup.

> My current setup:
> IDM 4.6SP1
> Exchange 2016
> scripting driver running as local system user on Exchange 2016 server
> Script command running as local system user on same Exchange 2016

server
> IDM Exchange driver appears to be correct and 'bin\scriptclient.exe' is

executed.
>
> scriptservice.conf:
> -----------------------------------
> -address localhost:8198
> -nosecurity
> -command . "C:\Program

Files\Novell\WSDriver\scripts\powershell\scriptservice.ps1"


No need for a separate script. One can have multiple -command entries in
script service.conf


>
> What am I missing?
>
> What is the recommended setup?
> - under what account should I execute the scripting driver (local system

vs. local user vs. AD user)

I generally use Local System. However not strictly necessary.

> - under what account should I run the scripting service (local system

vs. local user vs. AD user)
>


AD user with membership in following Exchange related AD groups


Recipient Management
View Only Organizational Management

Also this AD user needs log on as a service permissions for the server and
local admin rights on the server (or at a minimum, read/write rights to the
WSDriver log directory, as well as to the TEMP directory used by the
account set for the Scripting driver).
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
imoberdorf
Visitor.

Re: Powershell Scripting Service Driver / Exchange commandle

alexmchugh;2471623 wrote:

I use a powershell remoting session to retrieve “just enough” of the
Exchange cmdlets. Often this is via loopback to same server as the
Scripting driver is installed on.


How would you do this? As I understand you cannot have a remote ps session as local user (how would you store the credentials)

Would you mind uploading your config for a reference?
0 Likes
Knowledge Partner
Knowledge Partner

Re: Powershell Scripting Service Driver / Exchange commandlets

imoberdorf <imoberdorf@no-mx.forums.microfocus.com> wrote:
>

alexmchugh;2471623 Wrote:
>
>>

> How would you do this? As I understand you cannot have a remote ps

session as local user (how would you store the credentials)
>


For credentials that is where your choice of user to run script service as
comes into play.

The remote ps session is established using negotiate or Kerberos (so only
place you need to update user/password is on the service itself).

remote powershell is definitely possible to same server. In some cases you
need to do loopback (computer name as just a dot ) and add the
EnableNetworkAccess param to ensure you have correct tokens in your
session.
I don’t recall that being necessary with Exchange though.

> Would you mind uploading your config for a reference?


My config uses a drastically different model to the way you have approached
it. I don’t connect to Exchange on service startup, instead wait for first
event that needs Exchange and connect then. My experience is that the time
taken to load Exchange cmdlets first time interferes with service startup.

Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
schwoerb Absent Member.
Absent Member.

Re: Powershell Scripting Service Driver / Exchange commandle

I use the RemoteExchange.ps1 as well, but it needs to be adapted/modified. The problem is with the write-host statements. If my notes are correct, all I did was wrap two lines in RemoteExchange.ps1. So from this:

get-exbanner
get-tip

To this:

if ( ($psISE -ne $null) ) {
get-exbanner
get-tip
}
0 Likes
imoberdorf
Visitor.

Re: Powershell Scripting Service Driver / Exchange commandle

schwoerb;2472112 wrote:
I use the RemoteExchange.ps1 as well, but it needs to be adapted/modified


That was it. Thank you!
This should definitely be documented somewhere. I wonder no one else but the two us had stumbled over this issue yet.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Powershell Scripting Service Driver / Exchange commandle

imoberdorf;2473051 wrote:
schwoerb;2472112 wrote:
I use the RemoteExchange.ps1 as well, but it needs to be adapted/modified


That was it. Thank you!
This should definitely be documented somewhere. I wonder no one else but the two us had stumbled over this issue yet.


You should report this as a bug, so that it gets fixed in a future version.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.