The 2>&1 is trying to tie both STDERR and STDOUT to the same thing so that it can either log both, or deliberately fail to log both, to either a logfile or to the screen. Here's some stuff I had stored that I had previously found on the internet somewhere:
There are two main output streams that you usually see on the console, stdout and stderr. When you do a > "some file name", it redirects stdout to the file. But stderr still comes to the console. 2>&1 binds stderr to stdout so that all the output is redirected. You see it more often in Unix shell scripts.
Example:
reg export "%REG_SOFTWARE_ROOT%\%PRODUCT_NAME%" "%TEMP_DIAG_OUTPUT%\ProductStuff.reg" > NUL 2>&1
I think the problem with your original syntax after the PASSWORD is that it was missing the chevron to redirect to the log file. I think the original example meant to do something like this:
PASSWORD > C:\other\mount.log 2>&1
But you lost the chevron in a cutNpaste somewhere, so it did this instead:
PASSWORD C:\other\mount.log 2>&1
... Which is syntactically wrong for the NET USE command.
I'm not sure if any of the above works as-I've-typed-it, I'm just pasting stuff in to get the point across.
To the other question about how to do NET USE without needing the share name... There may be something like IPC$ or something that you can put in place of the share name there. Dig around what SS64 has to say about net use, I've always found their stuff more helpful than the plain DOS HELP command:
http://ss64.com/nt/net_use.htmlIf that doesn't help, try eschewing NET USE altogether, and just cache those user credentials into the system's existing cache of passwords so that they Just Work when the guy opens the share. Like this:
Cmdkey /delete:SERVERADDRESS
Cmdkey /add:SERVERADDRESS /user:USERNAME /pass:PASSWORD
The beauty of this is that you can do it more than once store multiple ones just in case you don't know whether they'll be using the IP address, the FQDN, or the server name without FQDN. Like this:
Cmdkey /delete:192.168.1.21
Cmdkey /add:192.168.1.21 /user:USERNAME /pass:PASSWORD
Cmdkey /delete:SERVERADDRESS
Cmdkey /add:SERVERADDRESS /user:USERNAME /pass:PASSWORD
Cmdkey /delete:SERVERADDRESS.domain.com
Cmdkey /add:SERVERADDRESS.domain.com /user:USERNAME /pass:PASSWORD
To have a looksee at what windows credentials are cached, run:
CONTROL KEYMGR.DLL
And click on "Windows Credentials".
Caching those credentials is great if you don't intend to change the passwords. If the passwords change, though, then if you keep hammering the server with the wrong cached creds it'll lock you out. I run into this on my test machines at work all the time, they keep making me change my password so I have to go use a script file with the CMDKEY thing to poke the creds into the test computers before they hammer the server with the wrong cached credentials and lock out the account.
Previous Topic
Index
