BookmarkSubscribeRSS Feed
flux
Calcite | Level 5

I'm using the SAS integration .dll libraries to build a Visual Studio C# application.

 

Code:

SASObjectManager.IObjectFactory2 obObjectFactory = new SASObjectManager.ObjectFactoryMulti2();
SASObjectManager.ServerDef obServer = new SASObjectManager.ServerDef();
obServer.MachineDNSName = "localhost";
obServer.Protocol = SASObjectManager.Protocols.ProtocolCom;
obServer.Port = 0;

var _workspace = (SAS.Workspace)obObjectFactory.CreateObjectByServer("SchdUtil", true, obServer, null, null);
_workspace.LanguageService.Submit(File.ReadAllText(item.Path));

 

 

I'm getting this exception when I try to execute the program remotely.

Access is denied. 0x80070005 localhost SAS.Workspace.1.0 39220

 

 

The program sits on a network path. It runs fine when executed locally. But I can't run the program remotely through Powershell with this:

 

Invoke-Command -ComputerName $x -Authentication CredSSP -Credential $credentials -ScriptBlock {\\some\network\path.exe}

 

 

What type of login mechanism is happening when I use the SAS workspace like this, that is different from running locally?

 

 

16 REPLIES 16
AndreasMenrath
Pyrite | Level 9

This generic error could be caused by many things.

  • SAS is not correctly installed on the remote machine
  • SAS is installed, but in the wrong CPU configuration (64bit vs. 32 bit)
  • the user running your application is not allowed to
    read the Windows registry
    start SAS via COM (maybe no access rights to the file system path where SAS is installed)
    ...

I would recommend that you login to the remote server with remote desktop and interactively run your application there.


BTW: i would not recommend to use the SAS integration DLLs directly in your Visual Studio project. Use the COM libraries instead.

AlanC
Barite | Level 11

I know this is an old thread but it is still pertinent. Can you explain the reasoning behind this statement (I just want to understand it more):

 

BTW: i would not recommend to use the SAS integration DLLs directly in your Visual Studio project. Use the COM libraries instead.

https://github.com/savian-net
ChrisHemedinger
Community Manager

The process of adding the COM references should generate some interop DLLs -- shim DLLs that box up the COM calls for you.  SAS ships these interop DLLs with SAS Enterprise Guide and SAS Add-In for Microsoft Office and the client itself.  Examples:

 

"C:\Program Files\SASHome\x86\Integration Technologies\SASOLAPInterop.dll"
"C:\Program Files\SASHome\x86\Integration Technologies\SASOManInterop.dll"
"C:\Program Files\SASHome\x86\Integration Technologies\SASOMIInterop.dll"
"C:\Program Files\SASHome\x86\Integration Technologies\SASInterop.dll"

It's easiest to simply reference those in your .NET project.  There are CHM files in the IntTech directory that document many of the APIs.

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
AndreasMenrath
Pyrite | Level 9

This generic error could be caused by many things.
- SAS is not correctly installed on the remote machine
- SAS is installed, but in the wrong CPU configuration (64bit vs. 32 bit)
- the user running your application is not allowed to
-- read the Windows registry
-- start SAS via COM (maybe no access rights to the file system path where SAS is installed)
- ...

I would recommend that you login to the remote server with remote desktop and interactively run your application there.


BTW: i would not recommend to use the SAS integration DLLs directly in your Visual Studio project. Use the COM libraries instead.

flux
Calcite | Level 5

Thank you for your reply.

 

This is why I'm stumped as it runs from a remote desktop session. However when you make a powershell remote session (passing in the correct credentials) and invoke command then this error appears.

Also how do you use the COM libraries instead of referencing DLLs in VS? I'm following this: http://blogs.sas.com/content/sasdummy/2013/06/09/sas-client-with-microsoft-dot-net/

 

 

To be thorough I've replied to each of your points below:

 

- SAS is not correctly installed on the remote machine

Definitely installed. 


- SAS is installed, but in the wrong CPU configuration (64bit vs. 32 bit)

SAS works when run manually.


- the user running your application is not allowed to
-- read the Windows registry

Because I can run it in a normal remote desktop session with the same credentials reading the registry shouldnt be a problem.

 

-- start SAS via COM (maybe no access rights to the file system path where SAS is installed)

There is at least read access to the SAS program files installation. Is there some other permissions that I should check?

AndreasMenrath
Pyrite | Level 9

For adding the COM reference use the usual dialog for adding references.

Select the COM tab to the left.

Search for SAS in the search box. I highlighted the usual COM references you will need most likely:

2015-11-30 10_09_16-Reference Manager.png

 

You can also take a look at my open source project for reference: http://sourceforge.net/p/cmdlets4sas/code/HEAD/tree/trunk/

 

 

Your problem might also be a pure powershell problem. Have you tried to run other applications like calc.exe in the remote session?

 

It would also be interesting to start a local SAS session via COM in your remote session with this code snippet:

$objFactory = New-Object -ComObject SASObjectManager.ObjectFactoryMulti2
$objServerDef = New-Object -ComObject SASObjectManager.ServerDef 

$objSAS = $objFactory.CreateObjectByServer(
                "mylocalserver",    
                $true, 
                $objServerDef, # used server definition for Workspace
                $null,   
                $null    
                )

Do you get an exception with the pure powershell code, too?

 

ChrisHemedinger
Community Manager

The problem could also be related to Code Access Security (CAS), which is a .NET / Windows security feature that can prevent .NET code from running from a network location.

 

To solve, you would need to run a CASPOL command to generate an exception to the policy, adding the network location as "FullTrust" on the machine that you're wanting to run on.  You'll probably need to check the current command syntax for CASPOL.exe, but here is an older example.

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
flux
Calcite | Level 5

Thank you both for your suggestions.

 

I tried Andreas code snippet via a remote ps session and the same error message appears.

 

Powershell code:

Capture.PNG

Result:

Exception calling "CreateObjectByServer" with "5" argument(s): "<connectionAtte
mpts>
    <connectionAttempt>
        <description>Access is denied.
</description>
        <status>0x80070005</status>
        <saslogin></saslogin>
        <sasmachinednsname></sasmachinednsname>
        <sasclassid></sasclassid>
        <sasprogid>SAS.Workspace.1.0</sasprogid>
        <threadid>17200</threadid>
        <name>mylocalserver</name>
    </connectionAttempt>
</connectionAttempts>"
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ComMethodTargetInvocation

 <Edit> Also I've tried running cmdlets4sas Connect-SasWorkspaceLocal cmdlet and I'm getting the same results.

 

 

When I run the same code snippet on a normal remote desktop session it runs fine.

Capture.PNG

 

 

Also the complete .NET program executes successfully over the network. The issue comes when calling SAS COM via powershell remote session.

 

Not sure where to go from here! 😞

 

 

 

 

 

flux
Calcite | Level 5

I'm having a look at SASObjectManager.ObjectFactoryMulti2 and SASObjectManager.ServerDef.

 

Everything is identical except when running through a remote powershell session these variables are added to the objects:

PSComputerName : xy.xy.com
RunspaceId : 41c6cacf-de3d-4e43-938c-b46cacaef717
PSShowComputerName : True

Perhaps when calling SAS COM this way it is losing context or current user creditials are not being passed in?

AndreasMenrath
Pyrite | Level 9

Sorry for the late reply.

 

I come to the same conclusion as you do. The problem is between COM and SAS.

When you execute my snippet or use the Connect-SasWorkspaceLocal you completely bypass any network stuff.

 

So i think your problem might occur between your user and Windows. If you use Powershell Remote services you don't have an interactive Windows session.

For starting a SAS server on the SAS platform the Windows user for starting a SAS server has to have the privilege "Log on as batch job". Ask your Windows administrator for your server to grant your Windows user the "Log on as batch job" privilege in the local security policies of the server machine and try again.

 

As an alternative you might create a new local technical user on the server machine and grant this user the privilege and use the credentials of the technical user to login to your remote powershell session.

 

For narrowing the issue it might also be very helpfull to look in the Windows event log for errors at the server for the time the SAS error occured.

 

I hope this helps you to solve your issue.

ChrisHemedinger
Community Manager

If you are trying to use COM from one machine to launch a process on another machine, that's essentially DCOM (distributed COM).  That mechanism was supported in the early days of SAS Integration Technologies, but over the years there have been so many security changes in Windows (to plug holes) that this type of remote-launching no longer works.

 

You can find some old DCOM information in the SAS 9.1.3 documentation.  However, the settings required to make this work might be contrary to your IT policies.

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
AndreasMenrath
Pyrite | Level 9

@ChrisHemedinger: i don't think that this is related to DCOM in any way.

Flux is using a Powershell Feature called Remote Services to start a new Powershell session under his credentials on a remote server. Communication between the client and the server PowerShell session is provided AFAIK by a native protocoll and not DCOM.

The remote session is just another powershell.exe process on the server listening on a specific network port for commands from the client.

 

However for some reason that powershell.exe process is denied to start a new local SAS session.

ChrisHemedinger
Community Manager

Thanks for that @AndreasMenrath; I'm not familiar with PowerShell remoting.

 

The other complicating factor that sometimes comes into play: when you have a process on one machine that launches a process on a remote machine with your same identity, and that remote process needs to access network resources on your behalf, you need to have the remote machine configured for "Trusted for Delegation".  This comes up most often when SAS environments are configured with Integrated Windows Authentication (IWA), and then the SAS process tries to access a network drive or network-attached printer.

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
flux
Calcite | Level 5

Thank you both for your help.

 

The "Log on as batch job" Windows priviledge seems to be the most plausible solution.

 

Also pointing to this is the same type of "access denied" message that occurs when trying the "New-Object -ComObject" remotely but with a different COM object.

http://powershell.com/cs/forums/t/22700.aspx

 

A solution posted was to remote in and create a scheduled job that runs once, so invoking COM appears local. I tried this but the job doesn't run. The "Log on as batch job" priviledge (I think/hope) is the thing required here.

 

Will update thread when I know for sure.

 

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

SAS Enterprise Guide vs. SAS Studio

What’s the difference between SAS Enterprise Guide and SAS Studio? How are they similar? Just ask SAS’ Danny Modlin.

Find more tutorials on the SAS Users YouTube channel.

Click image to register for webinarClick image to register for webinar

Classroom Training Available!

Select SAS Training centers are offering in-person courses. View upcoming courses for:

View all other training opportunities.

Discussion stats
  • 16 replies
  • 3733 views
  • 1 like
  • 5 in conversation