Create new user account

[kruk...@gmail.com]

Hi,

I'm trying to create new user in AD.

$ou=[ADSI]"LDAP://ou=myUsers,dc=test,dc=com"
$user = $ou.Create("user","cn="User1")
$user.Put("sAMAccountName", "User1")
$user.SetInfo()

But this only creates disabled user (without password).

How can I set password and enable this user?
Also how can I add user to some group?

Krunoslav

[Jim Holbach]

All I've been able to come up with so far is this. I haven't been able to set
the password yet.

$ou=[ADSI]"LDAP://cn=Users,dc=test,dc=com"
$user = $ou.Create("user","cn=User1")

$user.Put("sAMAccountName", "User1")
$user.SetInfo()

$User.put("useraccountcontrol",$User.useraccountcontrol.value -band (-bnot 2))
$user.SetInfo()

$Group=[ADSI]"LDAP://cn=dnsadmins,cn=Users,dc=test,dc=com"
$Group.PutEx(3, "member", @("cn=User1,cn=Users,dc=test,dc=com"))
$Group.SetInfo()

---
Jim Holbach

[kruk...@gmail.com]

This is really frustrating.

On Exchange 2007 you can do this

$username = Read-Host "Enter Username: "
$password = Read-Host "Enter password: " -AsSecureString

New-MailUser -Name $username -Password $password -ExternalEmailAddress
($username + "@test.com").ToString() -UserPrincipalName ($username +
"@test.com").ToString() -Organizational test.com/test

It will create a user account, and its way it should be done in
PowerShell. Clean, simple, documented.

To PowerShell team.

You have created something very very good.
I have created script that converts event logs from servers into RSS
feed in less then 3 hours.

And I'm struggling to create simple user in AD, please add some of
Exchange 2007 stuff into final release. Please.

Krunoslav

[Brandon Shell]

To be fair to the developers of powershell. What you are running into is not
a powershell issue... If I remember correctly it is a security feature. If
you want to set a password using the LDAP provider you must use LDAP over
SSL (port 636.) This is simply because LDAP is clear text and you do not
want your password hanging out on the wire in clear text. You will find if
you write the script and run it LOCALLY on a DC it should work.

Options:
1) Do it locally on a DC
2) Do it using LDAP over SSL
3) Use Winnt provider

<kruk...@gmail.com> wrote in message
news:1160468369.3...@i3g2000cwc.googlegroups.com...

[Brandon Shell]

Here is an article: http://support.microsoft.com/kb/269190

"Brandon Shell" <tsh...@mask.gmail.com> wrote in message
news:uSLcecG7...@TK2MSFTNGP05.phx.gbl...

[klu...@xtra.co.nz]

quote:

New-MailUser -Name $username -Password $password -ExternalEmailAddress
($username + "@test.com").ToString() -UserPrincipalName ($username +
"@test.com").ToString() -Organizational test.com/test

It will create a user account, and its way it should be done in
PowerShell. Clean, simple, documented.

reply:
yep to be fair, MS so far has just made an active directory adapter,
not a series of cmdlets for active directory.. I personally think that
for v2 a series of cmdlets for active directory management and an
active directory provider would be a good and valuable addition, so go
to connect and submit it if you think so. In reality though.. it
probably should be the active directory team that writes that for
powershell, just as the exchange team wrote the exchange cmdlets etc...

Karl

[Brandon Shell]

I am fairly certain that is already slated for v2. I believe we have already
some commitment from Mr. Snover for MUCH better AD support as well as
CMDLETS that make it usable for AD ( I say usable because in its current
state... its not at all usable for your typical user.)

I don't think there is any argument at all (even from the Posh Team) about
the crappyness of the AD support of Powershell, but they are working on it.

I responded, because the problem that Krunoslav is a ADSI interface problem
that Powershell should not resolve. The restriction is there for a VERY good
reason.

There is one MAJOR difference between the New-MailUser (exchange provided)
and what your asking for... The Provider. Its important to understand, in
this scenario, Exchange is a third party add-in to Powershell and not is not
native to Powershell. This means Exchange controls both client and server.
It is very easy for someone to write their own snap-in to provide what your
asking for.

In this case however... the developers of Powershell only have control of
the client and MUST abide by the restrictions set by the Server you are
requesting the information from. If a Domain Controller is refusing to
update an object because of known restrictions.. there is not much
Powershell can do about it. Is it possible for the Powershell team to make
it work? I'm sure it is, but is that really something you want them to
determine for you? You (the Admin/developer) should be responsible for work
around for given restrictions... not the Powershell team.

This is just my 2cents... I don't speak for Powershell team in any stretch.

<klu...@xtra.co.nz> wrote in message
news:1160495216.4...@e3g2000cwe.googlegroups.com...

[kruk...@gmail.com]

Hi,

thank you for your replay, now I see what was wrong with my code.

But please understand that I'm coming from VB script. And with VB
script I manage network of about 1200 computers and 90 servers.

I started using PowerShell from version RC1 and I was trilled. I could
access with easy system resources and work with WMI. And with RC2 it
got even better, documentation was almost perfect, for every command
there is lot of examples.

Problem of CMDLETS not working with remote computer (in this version) I
have solved by using .NET directly (EventLogs, Processes, Services...).

But when I started working with AD it became harder.
If you go to ScriptCentre and look for example how to reset user
password (in VB script) you got this

Set objUser = GetObject
("LDAP://cn=MyerKen,ou=management,dc=fabrikam,dc=com")
objUser.SetPassword "i5A2sj*!"

You can now see why I tried to use SetPassword in a way I did.

I now that RC2 means that probably will be no major modification of
code for V1, but when I looked at Exchange 2007 I could not stop
thinking that this is the way to work with AD.

Many thanks to teams who gave as such a good tool for managing an OS
and Exchange 2007. If we could manage AD with same ease it would be
even better.

Krunoslav

[Jim Holbach]

Krunoslav -

Could you post your solution to the password issue? I'd be interested in
seeing that since I'm still stumped on that part.

Thanks.

---
Jim Holbach

[Abhishek Agrawal [MSFT]]

Hi Krunoslav,
Thanks for your feedback. Improving AD management through powershell is
defintely on our radar for V2. Having a AD provider or series of cmdlets
would be the right way to go. The stop-gap solution for V1 is our type
adapter which aims to make it easier to to use .Net DirectoryService object
to do "vbscript like" scripting for AD in powershell.

Thanks,
Abhishek Agrawal [MSFT]
Windows PowerShell team
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

<kruk...@gmail.com> wrote in message
news:1160517867.7...@i42g2000cwa.googlegroups.com...

[Andrew Watt [MVP]]

On Thu, 12 Oct 2006 01:36:45 -0700, "Abhishek Agrawal [MSFT]"
<abh...@online.microsoft.com> wrote:

>The stop-gap solution for V1 is our type
>adapter which aims to make it easier to to use .Net DirectoryService object
>to do "vbscript like" scripting for AD in powershell.

Abhishek,

I *love* the idea of the stop-gap cmdlet.

Can you tell me its full syntax? :)

Andrew Watt MVP

[damian...@gmail.com]

I come across this if it helps.

Clear-Host

Write-Host -foregroundcolor Yellow 'Admin Privileges Required!'

$localuser = Read-Host 'Enter User Account Name For New Account'

$password = Read-Host 'Enter Password for new account'

$description = "Description"

$computer = [ADSI]"WinNT://$env:computername,computer"

$user = $computer.Create("user", $localuser)

$user.SetPassword($password)

$user.SetInfo()

$user.Description = $description

$user.SetInfo()