December 12, 2014 at 8:29 am #21110
I was working on a script to reset password of local admin in workgroup computers. I have more than 500 computers.
I created below code to automate this task, but somehow it is not working. When I am using single computer name in this same script it works.
In error sometime it says “Exception calling "Invoke" with "2" argument(s): "The specified local group does not exist.” OR “Exception calling "Invoke" with "2" argument(s): "The network path was not found.”
The List.txt file contains below lines and there is no space
I can ping/resolve/browse these PCs.
Could someone please suggest me on this.
Admin.txt file attached.
December 12, 2014 at 9:13 am #21112
I didn't spend much time looking this over, but you need double quotes around "$Computer\$UserID" on the line where you assign it to $AdminAccount. Take a look at my example.
PS C:\> $a = 'It is finally' PS C:\> $b = 'Friday!' PS C:\> $c = '$a $b' PS C:\> $c $a $b PS C:\> $c = "$a $b" PS C:\> $c It is finally Friday! PS C:\>
December 12, 2014 at 9:35 am #21114
I tried but same problem.
Exception calling "Invoke" with "2" argument(s): "The network path was not found.”
Please help me.
December 12, 2014 at 9:41 am #21115
I don't know where I am lacking but I spent lot of time to debug this but no luck.
December 12, 2014 at 11:00 am #21119
Maybe not much help, but my personal preference for this type of task is to use Invoke-Expression to execute the code on the remote system. It lessens complexity, and also has the benefit that you can do your password reset operations simply with Net Use, which is infinitely easier.
December 12, 2014 at 11:07 am #21120
It seems the error is with below command
$user = New-Object System.DirectoryServices.DirectoryEntry("WinNT://$Computer/$UserID",$AdminAccount,$AdminPassword)
running only $User gives me same error.
December 12, 2014 at 11:13 am #21121
If the username remains a constant, try throwing 'Administrator' into the path like the example above. I had a similar issue yesterday where the path did not accept the username stored in a variable.
December 12, 2014 at 11:29 am #21122
Thanks Tim !
Invoke-Expression, Invoke-Command need extra settings on remote computer to run commands using PowerShell which I cannot configure, that's why I am using this method.
December 12, 2014 at 11:34 am #21123
$AdminPassword and $NewPassword are both secure (System.Security.SecureString). Perhaps you need to use $pwd1_text (or, $pwd2_text) in place of $NewPassword, and $pwd11_text (or, $pwd12_text) in place of $AdminPassword.
December 12, 2014 at 11:56 am #21124
I tried this also but same error.
December 12, 2014 at 12:06 pm #21125
Thanks a lot Tom !!!!
That was the problem, I used clear txt password and it worked. But I don't want to send clear txt password over network, any workaround so that I can send secure txt. Please suggest.
December 12, 2014 at 12:40 pm #21126
Someone more knowledgeable may need to step in to properly answer the password/clear text portion of this thread. I considered it may send those passwords in the clear, but also suspected it was the problem and so I shared it. It's simply unfortunate you can't use PSRemoting and Invoke-Command. It's secure by default and eliminates these old concerns of sending clear text over the wire. PSRemoting uses encryption by default. In fact, most ways to secure PSRemoting are to secure things that aren't PSRemoting – blocking the ports used at the border firewall, using non-Internet routeable IP space.
December 12, 2014 at 2:00 pm #21127
Thing you're going to have a couple of problems. First difficulty is going to lie in that the actual constructor for DirectoryEntry takes as input values of type string, not secure string. Second is that (from what i can recall) a secure string is only valid using the account in use when it was generated AND only on the system it was created on. i.e. It's not going to be shippable.
BTW are the credential delegation and other winrm applicable settings not changeable on the target machines because of your security policy? If it's just from an implementation challenge point of view, I'm thinking you might be able to go down the psexec route for configuring the systems to have WinRM and CredSSP enabled as required.....
You must be logged in to reply to this topic.