Touching Remote Computers to Add User Accounts

Home Forums PowerShell Q&A Touching Remote Computers to Add User Accounts

You must be registered and logged in to reply to this topic.

This topic contains 0 replies, has 1 voice, and was last updated by  Forums Archives 2 years, 7 months ago.

  • #5856

    by Joat at 2013-04-27 18:09:28

    Greetings,

    I don't consider myself a PS expert, but I have done enough code borrowing and transmogrification that I feel fairly comfortable in day-to-day use. I don't think anything I do is ingenious – usually brute force in nature, and as always, you never learn until something breaks…

    I have around 70 laptops that are used in a field situation where you never know which ones will appear in the field, but it becomes necessary to manage them when they show up. Historically, we use a peer-to-peer network as the field environment is usually short term (several days to several weeks), and usually never exceeds 20-ish computers.

    I have a VBScript that I ran on the old XP platform that I could use to create user accounts on either the local machine or a peer machine by changing the hostname when the script is run (text field that defaults to the local machine). I decided to rewrite the script in PS when we migrated to Win7 and although the resultant script works just fine locally, when I try to create the account on a remote computer, I get an "Unspecified Error". I believe I have narrowed it down to what I believe to be a security setting (which I realize is not necessarily a PS issue, but it's how I came upon the issue), but am unsure where to go next.

    I think I have narrowed the problem down to getting no response from the remote computer. If I run the following manually in the ISE (or ISE (x86)) against the "LocalPC", it runs just fine, but if I run:

    $Computer = [ADSI]&quot;WinNT://RemotePC&quot;<br />$Computer | Select *

    I get:

    format-default : Unspecified error<br />    + CategoryInfo          : NotSpecified: &#40;:&#41; [format-default], COMException<br />    + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Microsoft.PowerShell.Commands.FormatDefaultCommand

    Which leads me to believe there is a permissions issue in the way – call it a hunch.

    All the machines are Win7 64-bit and are based on a core Ghost image with Powershell V3 installed. It's to the point I need to move on and stamp out the newest image, but had hoped to get this working to simplify my day to day management when in this environment. I have tried to locate info about what I am doing in relation to the error, but either I am searching on the wrong text or it's somewhat obscure.

    Thanks in advance for looking and commenting.

    by DonJ at 2013-04-28 08:39:50

    It's probably a security issue, as you surmise.

    A couple of things. First, although you're obviously running these commands in PowerShell, none of the actual technologies are, in fact, PowerShell. ADSI is a fairly old (VBScript-era) technology, and the [adsi] type accelerator doesn't expose its full functionality. What you're doing should work if NTLM passthrough can work – meaning the remote machine has a username, with a password, that matches the one you're using to run PowerShell.

    Lord God, Ghost images. I'm having flashbacks to Duran Duran . Not good. The video for "Rio," in particular, hurts the eyes.

    I would suggest moving to WMI. It can create your new user accounts, rename a remote machine, and more importantly the Get-WmiObject cmdlet supports an explicit credential parameter to use for the connection – something the [adsi] type accelerator does not do.

    Frankly, being a PSH geek, I'd create my new Ghost image (now it's "The Reflex") with PowerShell remoting enabled on those machines. That opens up a universe of better alternatives. You can connect to the machine using Invoke-Command (you'll need to tweak your local TrustedHosts since these aren't in a domain), send them whatever commands (netdom, net user, etc), and it'll run those locally. Much more reliable.

You must be registered and logged in to reply to this topic.