Anonymous_User Absent Member.
Absent Member.
302 views

Windows Scripting Driver Issue


I am working on converting over to the latest 4.0.2 Windows Scripting
driver (using the scripting service) from the earlier 3.6.1 driver. I
am running into an issue where if Exchange slows down a bit on
provisioning or some other cmdlets that I get the following:

7/21/2014 09:00:19 System.Threading.ThreadAbortException: Thread was
being aborted.
at System.Threading.WaitHandle.WaitOneNative(SafeHandle
waitableSafeHandle, UInt32 millisecondsTimeout, Boolean
hasThreadAffinity, Boolean exitContext)
at System.Threading.WaitHandle.InternalWaitOne(SafeHandle
waitableSafeHandle, Int64 millisecondsTimeout, Boolean
hasThreadAffinity, Boolean exitContext)
at
System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable
input)
at System.Management.Automation.RunspaceInvoke.Invoke(String script,
IEnumerable input, IList& errors)
at
Novell.IDM.WSD.ScriptService.ScriptServiceServer.ExecuteScript(String
sScriptPath, String sArg0, String sArg1, String sArg2, String sArg3,
String sArg4, String sArg5, String sArg6, String sArg7, String sArg8,
String sArg9)


After which, it doesn't ever really recover and get endless exceptions
like:

7/21/2014 09:00:25
System.Management.Automation.PSInvalidOperationException: Pipeline not
run because a pipeline is already running. Pipelines cannot be run
concurrently.
at
System.Management.Automation.Runspaces.PipelineBase.DoConcurrentCheck(Boolean
syncCall, Object syncObject, Boolean isInLock)
at
System.Management.Automation.Runspaces.RunspaceBase.DoConcurrentCheckAndAddToRunningPipelines(PipelineBase
pipeline, Boolean syncCall)
at
System.Management.Automation.Runspaces.PipelineBase.CoreInvoke(IEnumerable
input, Boolean syncCall)
at
System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable
input)
at System.Management.Automation.RunspaceInvoke.Invoke(String script,
IEnumerable input, IList& errors)
at
Novell.IDM.WSD.ScriptService.ScriptServiceServer.ExecuteScript(String
sScriptPath, String sArg0, String sArg1, String sArg2, String sArg3,
String sArg4, String sArg5, String sArg6, String sArg7, String sArg8,
String sArg9)


I have extended the script timeout, but this doesn't seem like a
graceful way of handling this.


--
schwoerb
------------------------------------------------------------------------
schwoerb's Profile: https://forums.netiq.com/member.php?userid=2338
View this thread: https://forums.netiq.com/showthread.php?t=51377

Labels (1)
0 Likes
4 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Windows Scripting Driver Issue


So extending the script timeout worked around the problem?

I'll look into how timeouts are handled.

Thanks,
Sam S.


--
Zygomax
------------------------------------------------------------------------
Zygomax's Profile: https://forums.netiq.com/member.php?userid=215
View this thread: https://forums.netiq.com/showthread.php?t=51377

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows Scripting Driver Issue


TL;DR: OK, the ScriptService will now run only one PS script at a time.

This fix will be available in the 4.5 version. Note that the 4.5
Scripting Integration Module may come out later than the 4.5 IDM engine.

The problem:
1) The driver shim (wsdriver.exe) would execute the Script Client
command and wait for it in its Subscriber thread.
2) The driver shim would run its polling operation in its Publisher
thread. However, the driver shim only runs one command at a time, so it
would wait for the prior command to complete.
3) The initial command would time out. PowerShell would trace the first
exception.
4) The polling command would execute, but the Script Service is still
working on the initial command, so the "already running" exception is
traced repeatedly.
5) Subsequent commands have the same problem until the initial command
completes.

Now:
The Script Service will wait until a command is finished before running
another one.

Caveat Emptor:
It's still a good idea to have a generous script timeout value. The
Script Service currently has no concept of a timeout, so it will keep
plugging away at its command until it completes. That means other
commands will queue up behind it.

Ideally, it would be good to execute operations asynchronously in the
scripts, and terminate them if they go over the timeout. But that's not
always possible.
----
So it's not perfect. I'll look into a way to have the Script Service
timeout. Not sure I'll have that ready for v4.5 though.

Thanks,
Sam


--
Zygomax
------------------------------------------------------------------------
Zygomax's Profile: https://forums.netiq.com/member.php?userid=215
View this thread: https://forums.netiq.com/showthread.php?t=51377

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows Scripting Driver Issue

Zygomax wrote:

>
> This fix will be available in the 4.5 version. Note that the 4.5
> Scripting Integration Module may come out later than the 4.5 IDM engine.
>
> The problem:
> 1) The driver shim (wsdriver.exe) would execute the Script Client
> command and wait for it in its Subscriber thread.
> 2) The driver shim would run its polling operation in its Publisher
> thread. However, the driver shim only runs one command at a time, so it
> would wait for the prior command to complete.


So you are saying that the publisher channel scripts (poll.ps1) doesn't run via the script client when you have configured the script service?

> Caveat Emptor:
> It's still a good idea to have a generous script timeout value. The
> Script Service currently has no concept of a timeout, so it will keep
> plugging away at its command until it completes. That means other
> commands will queue up behind it.


Does this mean when script commands have queued up for execution by the shim on the subscriber channel, this will block polling/heartbeat on the publisher channel?

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Windows Scripting Driver Issue


So you are saying that the publisher channel scripts (poll.ps1) doesn't
run via the script client when you have configured the script service?


No, it does run via the Script Client. I used the terms "operation" and
"command" in a subtle way. By operation I meant the process of setting
up to run the polling command, which is the script client.


Does this mean when script commands have queued up for execution by the
shim on the subscriber channel, this will block polling/heartbeat on the
publisher channel?


Sort of... In the -shim- only one command can be queued up, because the
shim only works on one event a time. In the -Script Service- you could
have multiple commands queued up.

An example might help:
1. A script command, that resulted from a Subscriber event, is started
in the Script Service.
2. A poll operation starts and waits in the shim for the prior command
to complete.
3. The command times out. The -shim- terminates the Script Client and
returns timeout to the IDM engine. However, the Script Service is still
running the command.
4. The shim executes the poll command. It gets blocked in the -Script
Service-, waiting for the initial command to complete.
5. Another Subscriber event comes along and gets blocked in the -shim-,
waiting for the poll to complete.
6. The poll operation times out and its Script Client is terminated. The
Script Service notices that its Client has been terminated, so it kills
the thread that was going to run a command.
7. The latest Subscriber command is executed, but blocks in the Script
Service.
8. The initial command completes its PS execution. However, once that is
done, the Script Service terminates the thread since there's no Client
any more (like the poll thread above).
9. The latest Subscriber command executes normally.
----
So the problem I see is that commands are "orphaned" if they time out.
So IDM and your external system may have an inconsistency. For example,
you could execute an "add" expecting an association back. But the
operation times out, so you get an error back to the engine. But the
command chugs along in the Script Service and completes successfully. So
you have your external identity created with no association. Thanks to
querying, this particular situation may not be too hard to fix, but
other scenarios may be more problematic.

So say we put in a timeout in the Script Service, which dutifully ends
the command on timeout. Now your script only ran partially, perhaps
leaving things in a very strange state.

Robust policies and scripts will help with unexpected results.
----
So some of this has been thinking "out loud". I'll look into this
further. If you have any suggestions, let me know.

Thanks,
Sam


--
Zygomax
------------------------------------------------------------------------
Zygomax's Profile: https://forums.netiq.com/member.php?userid=215
View this thread: https://forums.netiq.com/showthread.php?t=51377

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.