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

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