Weird issue with dsjob command

[skathaitrooney]

Hi Experts,

I am facing a weird issue with dsjob command. I am not able to run the command using dsadm id. Although if i run it using my own id, it is running fine.

We are ldap authenticated.

I am logged in as dsadm
Below command gives me error

Code: Select all

dsjob -lprojects 

Code: Select all

Last recorded error message =
Connection to the specified engine tier host failed or was refused. Check that the RPC daemon service is running on the host and that no firewall is blocking the connection

Below works fine for me:

Code: Select all

dsjob -domain domainname:9445 -server servername:31539 -user myser -password mypassword  -lprojects

I have 2 instances of IIS installed on the same machine ( v9.1 and v11.5 )
I am facing issues with v11.5

In v9.1, i simply logon as dsadm, and run this command and it runs fine

Code: Select all

dsjob -lprojects

In 11.5 gives an error

Code: Select all

Last recorded error message =
Connection to the specified engine tier host failed or was refused. Check that the RPC daemon service is running on the host and that no firewall is blocking the connection

I read in one of the DSXchange post that

To NOT PASS the Domain, User and Password to the dsjob command and it will use the credentials of the logged in user irrespective of type of Authentication, Credential mappings or LDAP

So i am not passing these values when i run dsjob using dsadm. It workds perfectly fine for me in v9.1

[qt_ky]

I think that you have to provide the -domain and -server arguments and credentials when using non-default port numbers, such as on additional instances. Have you tried that?

[skathaitrooney]

Yes i did try that and it worked.

Is it possible to avoid passing those parameters for non-default ports?
Just curious to know.

[ray.wurlod]

In version 11, no. This is all tied up with the change to mandating https for all connections. And, yes, it's a change from version 9.x behaviour.

[qt_ky]

On a related note, if you want to improve the security or just have fewer parameters/arguments to type, you can look into using the -authfile option and the encrypt.sh script. Most of the command line utilities support an authfile option, letting you store many of these items in a text file. If you also take advantage of the encrypt utility, then your passwords will not floating around in a UNIX process list during execution.