Page 1 of 1

Weird issue with dsjob command

Posted: Thu Sep 15, 2016 6:48 am
by 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

Posted: Thu Sep 15, 2016 7:31 am
by 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?

Posted: Thu Sep 15, 2016 10:00 am
by 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.

Posted: Thu Sep 15, 2016 4:59 pm
by 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.

Posted: Fri Sep 16, 2016 5:43 am
by 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.