Running PowerShell 5 and 7 on the same server

[Sascha Peter]

​Hello,

I'm new in the Automic area and could use some help to run PowerShell 5 and 7 at the same server.

I want to/(have to) use PowerShell 7 because of some new functionality.

I can't use PowerShell 7 for all scripts, due to the limitation of PowerShell 7 to .Net Core.

Therefore I want to run both interpreters.

The only thing I can imagine is to use a second Windows agent, but maybe I'm wrong with this.

I don't know, if it is possible to run 2 Windows agents, but I guess so.

If I interpret some other threads right, then I have to use a different port and folder for it.
But maybe there is an easier way to achieve this.

Any hint is appreciated.

Regards,
Sascha

[Pete Wirfs]

You should be able to run both versions without much effort.  Do it via this feature;

https://docs.automic.com/documentation/webhelp/english/ALL/components/DOCU/12.3/Automic%20Automation%20Guides/help.htm#Script/Reference/BEGIN_EXT_INTERPRETERS.htm

------------------------------
Pete
------------------------------

[Pete Wirfs]

You have to configure this feature in client 0000.  Here is our configuration.  In your case, you'll want to set up two unique key values, and you will want to fully path the statement under Value2.

------------------------------
Pete
------------------------------

[Malathy THIRU]

Yes - here is an example of multiple perl interpreters we use in our environment 

[Sascha Peter]

​Thanks you both for the fast answer, will try to implement this ​now. Had to hunt for an login for client 0, but have it now and will look into this.

[Sascha Peter]

​I have now configured it this way, the first 2 were already there:

But I'm still a bit confused, what is the difference to the agent INI file with ECPEXE or when is what used. 

(I'm not to lazy to read more, but I'm a bit in a hurry to fix something.)

Is the ECPEXE the default and can be overwritten by :BEGIN_EXT_INTERPRETERS... :END_EXT_INTERPRETERS?

The ECPEXE  is pointing to the PowerShell 7 since one week.

[Michele Adamski]

Maybe I don't quite understand what you're trying to do but I have the same situation wherein I need to call varying versions of PowerShell so all I do is set the "Windows" tab of the job to point to the path to the required PowerShell instance, where the executable is:

Then you have to make sure you're calling the right executable name, e.g. 

(This is one single job, just to give an example. You'd need one job per PowerShell instance.)

You shouldn't need two agents but you can run two windows agents on one server. You must configure it on different ports. 

The default in the agent ini is port=2300, but if you're able, you can run a second agent on port=2301 (or whatever port you chose). You just need to make sure that port is opened back to your AE server. 

[Sascha Peter]

​Seems, there are always several ways to achieve something.

We have set the interpreter to custom interpreter and not to batch.

The working directory is used for the script root folder.

The way from Pete is working fine for me now.

But still I would like to have some clarity, about the ECPEXE  and UC_EXT_INTERPRETERS_WINDOWS.

Is the default set via ECPEXE and can be overwritten by UC_EXT_INTERPRETERS_WINDOWS?

[Pete Wirfs]

The ECPEXE setting in the INI file is a very old and inflexable feature. It can only support a single interpreter, and your process script must be entirely written to that language.  This feature can never be removed because datacenters have implemented quite a few solutions that depend upon it.

Then (I think with V10 or V11) they added the EXT_INTERPRETERS feature to give us more flexibility.   You can now set up an unlimited number of interpreters, and you can call out multiple interpreters in a single process script.

I still find myself taking advantage of both methods depending upon my use-case.  If I want my process script to be 100% powershell, then I still use the ECPEXE approach.  Otherwise, I use the EXT_INTERPRETERS approach.  But there is no technical reason why one should ever prefer ECPEXE... it is functionally replaced by EXT_INTERPRETERS.





------------------------------
Pete
------------------------------

[Sascha Peter]

Thanks Pete, that makes it clear (even for me​).

[Thomas H]

Hi together,

this post made me some things clear :)
Can you help me with another question on this?
How do i catch the errorlevel correct?

i never worked on older Versions than Automic V11 and now we use 12.2.2
this doesnt directly belong to the question but should explain why i maybe dont know the correct answer.

Since i work on Automic - i do BATCH in JOBS.WIN and catch on every Skript Line, if i need to, the errorlevel with these two lines:
@set retcode=%errorlevel%
@if NOT %ERRORLEVEL% == 0 goto :retcode

i accept that - so i work with that.

But now, i do much powershell and i dont have those standard lines to catch an error.
i looked at the "Show generated JCL Script" to see what Automic does with those lines.

How do i realise this in a "correct" - well, clean solution for PS Script.

Well, should i to it at the end of my new learned:END_EXT_INTERPRETERS?
This wouldn´t be a good solution, i think?
The Frame from my JOBS would still be a batch an i would catch the errors in batch instead of in the powershell lines?

Hope someone understand my german englisch and the hidden Problem between the lines ;)

Thank you
Thomas