Windows (Powershell) / Username=Computername

[Tywyn]

Hi there,

we are using Powershell snapins add local users after cloning.

I read the computername in the powershell-script and a user is added (New-LocalUser) with a username same as computername.
Then I add that user to the local group “Users” (Add-LocalGroupMember)

The user is created, but it is not added to the group “Users”.

This worked fine in Windows 7 32 bit, but not anymore with win7 64 bit and win 10 64 bit.

When username and computername differs, everything is fine.

And idea?

Thanx for your help
Rainer

[Avaryan]

Worked for me when I ran it locally on a Windows 10 Enterprise x64 computer. Will run as snapin soon to test.

Here is my code:

$Hostname = (Get-WmiObject -Class Win32_ComputerSystem).Name
$Password = "password" | ConvertTo-SecureString -AsPlainText -Force
New-LocalUser -Name $Hostname -Password $Password -Description "Local user." | Add-LocalGroupMember -Group "Users"

edit: Did not work when ran as a FOG snapin.

[george1421]

If you run this PS script outside of the context of a snapin (i.e. run it locally on the target computer by hand) does it run correctly? Right now we need to isolate the issue. Is it a FOG Snapin issue vs a PS script issue.

[Tom Elliott]

Pretty sure the computer names aren’t allowed to be the same as usernames. I don’t know why, I think it’s because of domain issues (localhostname\username which when you simply put username auto assumes the role its working for when joined to a domain, or the local system.

So it has no idea if username is meant to be the host you’re logging into, or the username you’re logging into. This is only a limitation, that I’m aware of, with Windows.

[Tywyn]

@george1421 said in Windows (Powershell) / Username=Computername:

If you run this PS script outside of the context of a snapin (i.e. run it locally on the target computer by hand) does it run correctly? Right now we need to isolate the issue. Is it a FOG Snapin issue vs a PS script issue.

Same thing, when I run it locally. I think, it is a Powershell/Windows-Issue

[Tywyn]

@tom-elliott said in Windows (Powershell) / Username=Computername:

Pretty sure the computer names aren’t allowed to be the same as usernames. I don’t know why, I think it’s because of domain issues

When I add a user via the UAC with the same username as the computername it works fine (at least under Win 7 64bit. Did not try it with win 10 though)

[george1421]

@tywyn In your PS script, add a text literal to the computer name (to just change it slightly as a test) when you create the user account. See if that works. That test will give you an idea if the computer name and user name can be the same.

Right now you need to basically take the approach of divide and concur. (find out where the problem isn’t so you can narrow down where it is).

[Tywyn]

@george1421 said in Windows (Powershell) / Username=Computername:

@tywyn In your PS script, add a text literal to the computer name (to just change it slightly as a test) when you create the user account. See if that works. That test will give you an idea if the computer name and user name can be the same.

My tests said, that you cannot have the same names, when you use Powershell, but you can have he same names, when you use the UAC

[Avaryan]

Worked for me when I ran it locally on a Windows 10 Enterprise x64 computer. Will run as snapin soon to test.

Here is my code:

$Hostname = (Get-WmiObject -Class Win32_ComputerSystem).Name
$Password = "password" | ConvertTo-SecureString -AsPlainText -Force
New-LocalUser -Name $Hostname -Password $Password -Description "Local user." | Add-LocalGroupMember -Group "Users"

edit: Did not work when ran as a FOG snapin.

[Avaryan]

Why not just create the local user doing sysprep?

[x23piracy]

Batch!:

net user /add USERNAME PASSWORD
net localgroup GROUPNAME USERNAME /add

@avaryan said in Windows (Powershell) / Username=Computername:

$Password = “password” | ConvertTo-SecureString -AsPlainText -Force

It does not make sense to encrypt the password within the same script.
You need to use the encrypted string and don’t encrypt it within the same script

@Tywyn like @Avaryan said why not use unattend.xml to create local users?

[Avaryan]

@x23piracy said in Windows (Powershell) / Username=Computername:

It does not make sense to encrypt the password within the same script.

PowerShell doesn’t allow you to do passwords in plain text. For testing purposes, it was fine.

[Quazz]

When you try to create a user with the same name as the Computername in command prompt, it will say that the two cannot be the same.

So likely when you create it in UAC, it does some magic behind the scenes to distinguish the 2.

[Tywyn]

@avaryan said in Windows (Powershell) / Username=Computername:

Worked for me when I ran it locally on a Windows 10 Enterprise x64 computer. Will run as snapin soon to test.

Here is my code:

$Hostname = (Get-WmiObject -Class Win32_ComputerSystem).Name
$Password = "password" | ConvertTo-SecureString -AsPlainText -Force
New-LocalUser -Name $Hostname -Password $Password -Description "Local user." | Add-LocalGroupMember -Group "Users"

edit: Did not work when ran as a FOG snapin.

This code worked for me as well now.
Interesstingly, when I have the Add-LocalGroupMember in a separate line, it does not work.

This is what I tried (did not work):

New-LocalUser $UserName -Password $UserPasswordEnc 
Add-LocalGroupMember -Group "Benutzer" -Member $UserName 

Thank you gentlemen!

[Tywyn]

@x23piracy said in [Windows (Powershell) / Username=Computername]

@Tywyn like @Avaryan said why not use unattend.xml to create local users?

Having a Powershell-script, that does more, for example, set ip-addresses, active office/windows, sets the correct time, etc.

AND: I have no idea how to use unattend.xml