Vista Tutorial - Create new user account

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

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


"krukinews@gmail.com" wrote:

> 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
>
>

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

Jim Holbach wrote:
> 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
>
>
> "krukinews@gmail.com" wrote:
>
> > 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
> >
> >

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


<krukinews@gmail.com> wrote in message
news:1160468369.398782.280480@i3g2000cwc.googlegroups.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
>
> Jim Holbach wrote:
>> 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
>>
>>
>> "krukinews@gmail.com" wrote:
>>
>> > 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
>> >
>> >
>

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

"Brandon Shell" <tshell@mask.gmail.com> wrote in message
news:uSLcecG7GHA.4552@TK2MSFTNGP05.phx.gbl...
> 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
>
>
> <krukinews@gmail.com> wrote in message
> news:1160468369.398782.280480@i3g2000cwc.googlegroups.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
>>
>> Jim Holbach wrote:
>>> 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
>>>
>>>
>>> "krukinews@gmail.com" wrote:
>>>
>>> > 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
>>> >
>>> >
>>
>

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

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.

<klumsy@xtra.co.nz> wrote in message
news:1160495216.413768.294980@e3g2000cwe.googlegroups.com...
> 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
>

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

Brandon Shell wrote:
> 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.
>
> <klumsy@xtra.co.nz> wrote in message
> news:1160495216.413768.294980@e3g2000cwe.googlegroups.com...
> > 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
> >

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

"krukinews@gmail.com" wrote:

> 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
>
> Brandon Shell wrote:
> > 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.
> >
> > <klumsy@xtra.co.nz> wrote in message
> > news:1160495216.413768.294980@e3g2000cwe.googlegroups.com...
> > > 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
> > >
>
>

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.


<krukinews@gmail.com> wrote in message
news:1160517867.754472.149770@i42g2000cwa.googlegroups.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
>
> Brandon Shell wrote:
>> 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.
>>
>> <klumsy@xtra.co.nz> wrote in message
>> news:1160495216.413768.294980@e3g2000cwe.googlegroups.com...
>> > 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
>> >
>