Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a basic powershell script that attempts to execute SQLPlus.exe on a remote machine. The remote does not have Oracle Instant client installed, but we have bundled all the necesary dlls in a remote folder. For example we have sqlplus.exe and dependencies in the directory C:\temp\oracle.

If I navigate to that path on the remote server and execute sqlplus.exe it runs just fine. I get the prompt for username.

If I go:

Invoke-Command -comp remote.machine.host -ScriptBlock { C:\temp\oracle\sqplus.exe }

I get the following:

Error 57 initializing SQL*Plus
    + CategoryInfo          : NotSpecified: (Error 57 initializing SQL*Plus:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

Error loading message shared library

Thinking that it's potentially a PATH issue I tried the following:

Invoke-Command -comp remote.machine.host -ScriptBlock { $env:ORACLE_HOME= "C:\temp\oracle"; $env:PATH = "$env:ORACLE_HOME; C:\temp\oracle\sqlplus.exe }

This had the same result.

The error code is not very helpful and is extremely frustrating since it does work when I log on to the machine. What is powershell remoting doing that's making this not work?

share|improve this question

2 Answers 2

This smells to me like an environment issue. Why can't you install the client properly on the remote system?

Is there any way you can dump your environment from the powershell script just prior to invoking SQL*Plus? If so, compare that with your environment when you're logged in and it works. Perhaps something like this:

Invoke-Command -comp remote.machine.host -ScriptBlock { $env:ORACLE_HOME= "C:\temp\oracle"; $env:PATH = "$env:ORACLE_HOME"; set > c:\temp\oracle\set.txt  }

Note: there appears to be a missing double quote in your PATH statement that I added in. I assume that was a transcription error.

share|improve this answer

Error 57 is often related to memory issues. While the output isn't very helpful, and using remoting complicates the issue, it might be down to the memory available to the remote shell, specifically, the MaxMemoryPerShellMB value on the remote machine.

This can be checked with

winrm get winrm/config

and the result is near the end. In our case, this was set to 150, whereas 512 was enough on the targets that didn't fail. The value can be set with

winrm set winrm/config @{MaxMemoryPerShellMB="512"}

or by setting a Group Policy on the machine.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.