Set the username and password for DCOM application

comdcomscripting

Is there a way to run a script against a remote machine to enter the username and password for a specific DCOM application? Locally on the server, I can open up Command Prompt, and type:

dcomperm -runas {12345678-1234-1234-1234-00aa00bbf7c7} redmond\jdoe password

which appears to work. I tried to do it with psexec and doesnt do anything, cmd.exe gets stuck until i kill it. The command i tried is:

PsExec.exe \\Server1 -i cmd DComPerm.exe -runas {12345678-1234-1234-1234-00aa00bbf7c7} redmond\jdoe password

Doing this manually every time the application is deployed is becoming a pain and I hope there is a wiz out there that can answer the question 🙂

Best Answer

From our conversation:

You don't need to escape the backslashes in the psexec command, and you also have no need to run your dcomperm.exe executable via a command prompt. So your command should be something like

PsExec.exe \\Server1 -i DComPerm.exe -runas {12345678-1234-1234-1234-00aa00bbf7c7} redmond\jdoe password

From your testing it seems there were a few more flags to add in order for it to work correctly, so the template command is

PsExec.exe \\Servernamehere -i -s /accepteula d:/releasescripts/dcomperm.exe -runas {AppIDhere} username password

where "d:/releasescripts" is the path where dcomperm.exe is located.

Related Solutions

Bash – the difference between double and single square brackets in bash

There are several differences. In my opinion, a few of the most important are:

[ is a builtin in Bash and many other modern shells. The builtin [ is similar to test with the additional requirement of a closing ]. The builtins [ and test imitate the functionality /bin/[ and /bin/test along with their limitations so that scripts would be backwards compatible. The original executables still exist mostly for POSIX compliance and backwards compatibility. Running the command type [ in Bash indicates that [ is interpreted as a builtin by default. (Note: which [ only looks for executables on the PATH and is equivalent to type -P [. You can execute type --help for details)
[[ is not as compatible, it won't necessarily work with whatever /bin/sh points to. So [[ is the more modern Bash / Zsh / Ksh option.
Because [[ is built into the shell and does not have legacy requirements, you don't need to worry about word splitting based on the IFS variable to mess up on variables that evaluate to a string with spaces. Therefore, you don't really need to put the variable in double quotes.

For the most part, the rest is just some nicer syntax. To see more differences, I recommend this link to an FAQ answer: What is the difference between test, [ and [[ ?. In fact, if you are serious about bash scripting, I recommend reading the entire wiki, including the FAQ, Pitfalls, and Guide. The test section from the guide section explains these differences as well, and why the author(s) think [[ is a better choice if you don't need to worry about being as portable. The main reasons are:

You don't have to worry about quoting the left-hand side of the test so that it actually gets read as a variable.
You don't have to escape less than and greater than < > with backslashes in order for them not to get evaluated as input redirection, which can really mess some stuff up by overwriting files. This again goes back to [[ being a builtin. If [ (test) is an external program the shell would have to make an exception in the way it evaluates < and > only if /bin/test is being called, which wouldn't really make sense.

Bash – username and password for rsync in script

Have you tried something like:

rsync -rltvvv --password-file=/root/secret . user@host::dest

Best Answer

Related Solutions

Bash – the difference between double and single square brackets in bash

Bash – username and password for rsync in script

Related Topic