Automation: running EG projects in headless mode via SSH

[Frank09]

Hi @js5 ,

Do you have progresses on this? I have the same problem. 

[Kurt_Bremser]

Still true what has been said multiple times: create a .sas program file from the project, and use server-side scheduling. MUCH less hassle.

[js5]

It is probably true. While the effort keeping the exported code with the .egp is non-zero, we gave up trying to make EG run remotely. The issue is that there is no graphical session available in SSH. psexec is being mentioned as a possible solution, but it seems to require admin access.

[Frank09]

Thanks for your comments! I agree with you that it's ok for some .sas programs to be scheduled by SAS server. However, for many legecy EG project files, people don't want to change something to export them as .sas files. They prefer to use EG VBscript to call them directly.

[Sajid01]

Hello @js5 
When one logs in to another machine using SSH it is as good as logging into that machine.
With your error being  'Could not create object named "SASEGObjectModel.Application.8.1" '  there are two things that need to be checked

1.SAS EG 8.1 is installed on that machine.

2.Make sure that SAS EG executible and the cscript file locations are in your path.
 This can be verified using echo %PATH% command in the command shell.

If not then add the paths to the environment variables.

[Frank09]

In my testing:  1. The SAS EG 8.1 has installed on the remote machine. 2. Even though I add the EG exe path to the PATH variable, the same error is reported. However, when I run the VBscript using admin account, there is no error reported. So I suspect that only admin privilege can execute the VBscript through SSH. But why we can run in locally using non-admin account, that weild issue should be expained by SAS. 

[Patrick]

"But why we can run in locally using non-admin account, that weild issue should be expained by SAS. "

Can you run any VB Script via SSH on the remote machine with a non-admin account? I assume what you observe is due to security policies and not related to SAS.

[Frank09]

Thanks for reply! Yes, I can execute a VBscript which just write a log into disk file without any other function involved. However, when I call CreateObject("SASEGObjectModel.Application.8.1"), it reported "runtime erro: Object required"; when I call CreateObject("Excel.Application"), it reported "Permission denied". Thus I suspect, though SSH connection, it is not possible to execute VBscript with CreateObject function using non-admin account.

@ChrisHemedinger , do you have any advice for this case?

[ChrisHemedinger]

I don't have any experience using SSH to automate EG remotely. The fact that you get the "Object required" error indicates to me that the CreateObject call is not finding a registered SEGScripting module. Usually that happens when you have a bitness mismatch, for example using the 64-bit cscript.exe with 32-bit EG, or the other way.

If 32-bit, be sure you are kicking off the script with the 32-bit version of cscript:

c:\Windows\SysWOW64\cscript.exe c:\projects\AutomationNewProgram.vbs

If 64-bit, use:

c:\Windows\system32\cscript.exe c:\projects\AutomationNewProgram.vbs

(I know those folder names seem backwards...but they aren't.) 

[Sajid01]

I have seen cases where SAS EG jobs being executed using external schedulers. 
In the instant case in addition to the suggestion by @ChrisHemedinger, I feel assistance on Windows Admin should be taken in resolving this issue.

[Frank09]

Thanks! In theory, it should be ok to use exteral scheduling. However, in the VBscript, if it calls  application like Excel which may run in Desktop sesstion, the OpenSSH protocol may not be suitable.

[Frank09]

Thanks for your reply! Yes, I know the difference between 32 bits and 64 bits. I use this one because we run 32 SAS EG on 64 machine.

c:\Windows\SysWOW64\cscript.exe c:\projects\AutomationNewProgram.vbs

 The problem is that this command can run successuflly on command prompt locally.

I see other comments in this communities and some people suggested to run the following two commands:

1. C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe /tlb:SASEGScripting.tlb /codebase "C:\SASHome\x86\SASEnterpriseGuide\5.1\SASEGScripting.dll"

2. C:\SASHome\x86\Integration Technologies\RegTypeLib.exe  C:\SASHome\x86\SASEnterpriseGuide\5.1\SASEGScripting.tlb

I just wonder that whether these two commands are useful and safe to fix the problem. Our system is running in production. I can't try any command before I conclude that it's safe.

[Sajid01]

Just curious, I hope the vbs file is located on the remote machine. This is, in my experience, the requirement.
When one logs in via SSH, it is as good as logging locally to the machine.
If one can run the script by physically logging in to that machine, then the expectation is that it should run after connecting via ssh.
If it does not, and if you are in a managed environment, then, please get your Windows Admin involved and make find out if there are any restriction.

[Frank09]

Thanks for your reply! The VBscript is on the remote machine. In fact, per my understanding, when login on through OpenSSH, it uses a network login on session, it is different from the local login on session. But I don't know the real difference between them, especially for calling applications like SAS EG.

[AlanC]

We run regasm, a lot, on thousands of machines. It is part of our normal install script. What it does is create the tlb files which are typelibs for COM/.NET communication. The tlb files allow a .NET program (ex. EG) to communicate with COM interop. Those libs need to be registered in the registry to work. I rely on them for communication between an Office ribbon and the underlying Office components. 

Chris is an expert at this and can clarify if I missed something.

VBS is an issue and I would recommend other approaches if you plan on using it in the future: 

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/vbscript-deprecation-timelines-and-next-s...