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.


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