WB to WB Communications

[LAKosin]

Briefly; I have a Winbatch (Program_A) that runs (successfully) with elevated credentials on Domain_A.
I need to modify Program_A to also do some functions on Doman_B.

I'm assuming that I will need have Program_A start a Program_B which will run on Domain_B with a different set of elevated credentials.

I need to have a way for Program_A wait for Program_B to finish and report back its' results before Program_A finishes up.

I've never had to do this before and I am unclear what is the best approach to do this.

Thanks in advance for any suggestions.

Larry

[td]

The term "Domain_A" and "Domain_B" are a bit ambiguous but the best guess is that you mean different computers  joined to different Windows network domains.  One way to accomplish your task is to use the free  MSFT supported system internals psexec.exe utility.  This utility can be downloaded here:

http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

The following Tech DB article contains an over-the-top example of using psexec.exe to run applications remotely:

http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/Launching~WinBatch~and~Other~Apps+RemoteRun~wbt~-~User~Sample.txt

The article is a bit intimidating.  You can also review the psexec.exe utility's command line options to get some idea of how to use this powerful tool.

By default psexec will wait until the remote process completes so it provides the synchronous behavior you need. 

The procedure to obtain result information depends on what information you need back.  If you need more than simple success/failure information, the easiest solution may be to have the second program write the information to a file on a shared folder that both program 'a' and program 'b' can access.  Program 'a' could simply read the contents of the file once pcexec returned.

If a simple success/failure flag is all that is needed then you could have your remote script return a value via IntControl request # 1000.

WMI can also be used to start a remote script but it requires fiddling with some security settings to allow remote WMI access.

Getting this working takes a bit of time and fiddling but it is doable in almost all cases.

[LAKosin]

I was trying to be precise as I am dealing with 2 different windows domains.
I'll check out PSEXEC.EXE; thanks.

I was wondering if a 'named pipe' might allow for a communication channel?

The first program will need to pass a good bit of information to the second in order to accomplish what I need.
Then the second program only needs to pass a 'success' message/code back to the first.

[td]

I was trying to be precise as I am dealing with 2 different windows domains.

Understood but the term 'domain' can mean many different things in the context of computers or scripting when used without qualifiers.  I have caused confusion more than once by not being specific enough and by assuming one thing when a forum contributor meant another... 

I'll check out PSEXEC.EXE; thanks.

I was wondering if a 'named pipe' might allow for a communication channel?

You may very likely run into security issues using named pipes across domains.  The WinBath implementation of named pipes does not provide many security options and that can be an issue when crossing network domains or when using newer versions of Windows.

The first program will need to pass a good bit of information to the second in order to accomplish what I need.
Then the second program only needs to pass a 'success' message/code back to the first.

You can pass information from the first to the second program using a file on a share, as well.

[DAG_P6]

In similar circumstances, I have in many cases found that the simplest solution is have Program A deposit information into a file, FILE_A, in a known location that is accessible to both hosts, such as a network share. Program B then waits for FILE_A to appear, immediately renames it to something like FILE_A.SEEN, thus hiding it from Program A, which is then free to create a brand new FILE_A. When Program B finishes processing FILE_A.SEEN, it either deletes it or renames it something like FILE_A.DONE, and returns to its loop waiting for a new FILE_A to appear.

I've been using this approach off and on for about as long as I can remember, and I have recent  production examples that have run nicely for about nine years.

The nice thing about using files in this way is that it's usually fairly easy to arrange for both machines to have access to a network share. Obviously, this is a matter of coordinating the creation of the share and assignment of permissions to security principals on both hosts. This should be feasible even across Windows domains if there is a trust relationship between them. Of course, different hosts within the same domain are even simpler to manage.

[kdmoyers]

I agree with DAG.  As long as the rate of message passing is fairly low, using files on a share is solid, reliable.  It's also easy to debug because the evidence is sitting there on disk.  I've been doing for decades.

When it doesn't work is when no disk share is possible, of course.

my $0.02
-Kirby