On Dec 6, 8:54 am, Brandon Shell [MVP] <a_bshell.m...@xxxxxx>
wrote:

> You can use this
>
> function Get-ADUsers{
> Param($Dom)
> if($Dom){$Dom = [ADSI]"LDAP://$dom"}else{$Dom = [ADSI]""}
> $filter = "(&(objectcategory=user))"
> $searcher = New-Object System.DirectoryServices.DirectorySearcher($Dom,$filter)
> $searcher.pagesize = 1000
> $searcher.findall()
>
> }
>
> Q: Any idea if there is going to be anything like this in PSH2?
> A: I may be off base here, but my general feeling on this is the Powershell
> Team is not going to provide this functionality and to be honest I agree
> with that decision. IMO the Powershell team is directly responsible for the
> Powershell framework and base CMDLets. Extenstions should be provided by
> "Internal Third Party Teams" ie Exchange,Active Directory,SMS, MOM, and Office.
> Treating internal products like external third party products is great. It
> allows the Powershell team to focus on the actual functionality of Powershell
> itself.
>
> Brandon Shell
> ---------------
> Blog:http://www.bsonposh.com/
> PSH Scripts Project: www.codeplex.com/psobject
>
> m> It would be for domain users. Quest CMDlets I will go and
> m> investigate, but it would be nicer if it was something that was
> m> included in powershell. (I don't know about you but I feel like I am
> m> forever installing bolt-ons for psh). Any idea if there is going to
> m> be anything like this in PSH2?
> m>
> m> What's the .Net option?
> m>
> m> Much appreciated
> m>
> m> "Brandon Shell [MVP]" wrote:
> m>
>

> >> Do you want local or domain accounts?

>

> >> for local you will need to use WMI or .NET
> >> for Domain you can use the free Quest CMDLets or .NET
> >> Brandon Shell
> >> ---------------
> >> Blog:http://www.bsonposh.com/
> >> PSH Scripts Project: www.codeplex.com/psobject
> >> m> It was really a powershell equivalent that passes out the result
> >> as
> >> m> an object. At the moment I have to parse the output with regex
> >> and I
> >> m> just think there must be an easier way.
> >> m>
> >> m> "Marco Shaw [MVP]" wrote:
> >> m>
> >>>> malckelly wrote:

>

> >>>>> Is there an equivalent in powershell for doing

>

> >>>>> "net user user1 /domain"

>

> >>>>> or really just a "net user" command.

>

> >>>> What were you looking to do? You can just use "net user user1
> >>>> /domain" from within PowerShell.

>

> >>>> The Quest AD cmdlets also provide a lot of information, and there's
> >>>> a
> >>>> free version:
> >>>>http://www.quest.com/powershell/
> >>>> Marco
> >>>> --
> >>>> Microsoft MVP - Windows PowerShell
> >>>>http://www.microsoft.com/mvp
> >>>> PowerGadgets MVP
> >>>>http://www.powergadgets.com/mvp
> >>>> Blog:
> >>>>http://marcoshaw.blogspot.com

I appreciate that PowerShell is developed separately from other
technologies inside Microsoft. You are absolutely right that it makes
for a more focused and reliable product.

What you are forgetting is that I, like most other PowerShell users,
don't care.

All we want is for you (read Microsoft) to provide a consistent
toolset to manage the keystone MS enterprise product (i.e. Active
Directory). It does not matter to me one whit if the AD management
tools come from the Exchange team, or the AD team or even from the
janitorial dept. We are already faced with a fragmentation in the AD
management by the Exchange toolset touching on AD but then only doing
what Exchange needs and no more. Now we are faced with the prospect
of having get-user for Exchange and then get-QADUser for the Quest
tools and maybe if we are lucky get-ADUser from the Active Directory
team. What if the MOM, SMS and Office teams also touch on AD as
well? Things fall between the cracks when tools are that scattered
and it's the user who ends up paying the price.

Is this sentiment at all unreasonable for someone who exists outside
the MS organization?



I apologize if I seem short in my rant but this is a very obvious
problem that needs to be addressed if you want to see PowerShell taken
seriously in the Enterprise. We don't care who inside Microsoft
provides the functionality we need, all that we care about is that it
gets done. Having access to dotNET functionality is nice but it is
being used as a crutch for not delivering a complete experience. My
understanding is that PS is going to be integrated into the Windows
Server 2008 and I would love to have the tools to properly manage AD
when it launches.

PowerShell is an amazing product, I enjoy using it. I think it is the
first breath of fresh air in an otherwise stagnant field in computer
technology. I hope to see it continue to mature into a usable, and
supported platform.

One qualification on my Part - I dont work for MS

I think everyone agrees that tools should be consistent, but it doesnt seem
like your asking for that. It seems like your asking MS to install all the
CMDLets for all thier products in base Powershell. Because that is not feasable,
what would you like? What products should and shouldnt be included? Then
the problem is why cant powershell be shipped with Third Party snapins from
Citrix/VMware/IBM and a slew of other vendors.

IMO... it much better to let each provider deal with thier own snap-ins.
Let the Powershell team focus on making Powershell better.

All that said, MS did include Powershell in the CEC for 2009, which implies
that most of not all products will support Powershell in some form.

Brandon Shell
---------------
Blog: http://www.bsonposh.com/
PSH Scripts Project: www.codeplex.com/psobject

s> On Dec 6, 8:54 am, Brandon Shell [MVP] <a_bshell.m...@xxxxxx>
s> wrote:
s>

>> You can use this
>>
>> function Get-ADUsers{
>> Param($Dom)
>> if($Dom){$Dom = [ADSI]"LDAP://$dom"}else{$Dom = [ADSI]""}
>> $filter = "(&(objectcategory=user))"
>> $searcher = New-Object
>> System.DirectoryServices.DirectorySearcher($Dom,$filter)
>> $searcher.pagesize = 1000
>> $searcher.findall()
>> }
>>
>> Q: Any idea if there is going to be anything like this in PSH2?
>> A: I may be off base here, but my general feeling on this is the
>> Powershell
>> Team is not going to provide this functionality and to be honest I
>> agree
>> with that decision. IMO the Powershell team is directly responsible
>> for the
>> Powershell framework and base CMDLets. Extenstions should be provided
>> by
>> "Internal Third Party Teams" ie Exchange,Active Directory,SMS, MOM,
>> and Office.
>> Treating internal products like external third party products is
>> great. It
>> allows the Powershell team to focus on the actual functionality of
>> Powershell
>> itself.
>> Brandon Shell
>> ---------------
>> Blog:http://www.bsonposh.com/
>> PSH Scripts Project: www.codeplex.com/psobject
>> m> It would be for domain users. Quest CMDlets I will go and
>> m> investigate, but it would be nicer if it was something that was
>> m> included in powershell. (I don't know about you but I feel like I
>> am
>> m> forever installing bolt-ons for psh). Any idea if there is going
>> to
>> m> be anything like this in PSH2?
>> m>
>> m> What's the .Net option?
>> m>
>> m> Much appreciated
>> m>
>> m> "Brandon Shell [MVP]" wrote:
>> m>

>>>> Do you want local or domain accounts?
>>>>
>>>> for local you will need to use WMI or .NET
>>>> for Domain you can use the free Quest CMDLets or .NET
>>>> Brandon Shell
>>>> ---------------
>>>> Blog:http://www.bsonposh.com/
>>>> PSH Scripts Project: www.codeplex.com/psobject
>>>> m> It was really a powershell equivalent that passes out the result
>>>> as
>>>> m> an object. At the moment I have to parse the output with regex
>>>> and I
>>>> m> just think there must be an easier way.
>>>> m>
>>>> m> "Marco Shaw [MVP]" wrote:
>>>> m>
>>>>>> malckelly wrote:
>>>>>>
>>>>>>> Is there an equivalent in powershell for doing
>>>>>>>
>>>>>>> "net user user1 /domain"
>>>>>>>
>>>>>>> or really just a "net user" command.
>>>>>>>
>>>>>> What were you looking to do? You can just use "net user user1
>>>>>> /domain" from within PowerShell.
>>>>>>
>>>>>> The Quest AD cmdlets also provide a lot of information, and
>>>>>> there's
>>>>>> a
>>>>>> free version:
>>>>>> http://www.quest.com/powershell/
>>>>>> Marco
>>>>>> --
>>>>>> Microsoft MVP - Windows PowerShell
>>>>>> http://www.microsoft.com/mvp
>>>>>> PowerGadgets MVP
>>>>>> http://www.powergadgets.com/mvp
>>>>>> Blog:
>>>>>> http://marcoshaw.blogspot.com

s> I appreciate that PowerShell is developed separately from other
s> technologies inside Microsoft. You are absolutely right that it
s> makes for a more focused and reliable product.
s>
s> What you are forgetting is that I, like most other PowerShell users,
s> don't care.
s>
s> All we want is for you (read Microsoft) to provide a consistent
s> toolset to manage the keystone MS enterprise product (i.e. Active
s> Directory). It does not matter to me one whit if the AD management
s> tools come from the Exchange team, or the AD team or even from the
s> janitorial dept. We are already faced with a fragmentation in the AD
s> management by the Exchange toolset touching on AD but then only doing
s> what Exchange needs and no more. Now we are faced with the prospect
s> of having get-user for Exchange and then get-QADUser for the Quest
s> tools and maybe if we are lucky get-ADUser from the Active Directory
s> team. What if the MOM, SMS and Office teams also touch on AD as
s> well? Things fall between the cracks when tools are that scattered
s> and it's the user who ends up paying the price.
s>
s> Is this sentiment at all unreasonable for someone who exists outside
s> the MS organization?
s>
s> I apologize if I seem short in my rant but this is a very obvious
s> problem that needs to be addressed if you want to see PowerShell
s> taken seriously in the Enterprise. We don't care who inside
s> Microsoft provides the functionality we need, all that we care about
s> is that it gets done. Having access to dotNET functionality is nice
s> but it is being used as a crutch for not delivering a complete
s> experience. My understanding is that PS is going to be integrated
s> into the Windows Server 2008 and I would love to have the tools to
s> properly manage AD when it launches.
s>
s> PowerShell is an amazing product, I enjoy using it. I think it is
s> the first breath of fresh air in an otherwise stagnant field in
s> computer technology. I hope to see it continue to mature into a
s> usable, and supported platform.
s>

On Dec 7, 2:11 pm, Brandon Shell [MVP] <a_bshell.m...@xxxxxx>
wrote:

> One qualification on my Part - I dont work for MS
>
> I think everyone agrees that tools should be consistent, but it doesnt seem
> like your asking for that. It seems like your asking MS to install all the
> CMDLets for all thier products in base Powershell. Because that is not feasable,
> what would you like? What products should and shouldnt be included? Then
> the problem is why cant powershell be shipped with Third Party snapins from
> Citrix/VMware/IBM and a slew of other vendors.
>
> IMO... it much better to let each provider deal with thier own snap-ins.
> Let the Powershell team focus on making Powershell better.
>
> All that said, MS did include Powershell in the CEC for 2009, which implies
> that most of not all products will support Powershell in some form.
>
> Brandon Shell
> ---------------
> Blog:http://www.bsonposh.com/
> PSH Scripts Project: www.codeplex.com/psobject
>
> s> On Dec 6, 8:54 am, Brandon Shell [MVP] <a_bshell.m...@xxxxxx>s> wrote:
>
> s>
>
>
>

> >> You can use this

>

> >> function Get-ADUsers{
> >> Param($Dom)
> >> if($Dom){$Dom = [ADSI]"LDAP://$dom"}else{$Dom = [ADSI]""}
> >> $filter = "(&(objectcategory=user))"
> >> $searcher = New-Object
> >> System.DirectoryServices.DirectorySearcher($Dom,$filter)
> >> $searcher.pagesize = 1000
> >> $searcher.findall()
> >> }

>

> >> Q: Any idea if there is going to be anything like this in PSH2?
> >> A: I may be off base here, but my general feeling on this is the
> >> Powershell
> >> Team is not going to provide this functionality and to be honest I
> >> agree
> >> with that decision. IMO the Powershell team is directly responsible
> >> for the
> >> Powershell framework and base CMDLets. Extenstions should be provided
> >> by
> >> "Internal Third Party Teams" ie Exchange,Active Directory,SMS, MOM,
> >> and Office.
> >> Treating internal products like external third party products is
> >> great. It
> >> allows the Powershell team to focus on the actual functionality of
> >> Powershell
> >> itself.
> >> Brandon Shell
> >> ---------------
> >> Blog:http://www.bsonposh.com/
> >> PSH Scripts Project: www.codeplex.com/psobject
> >> m> It would be for domain users. Quest CMDlets I will go and
> >> m> investigate, but it would be nicer if it was something that was
> >> m> included in powershell. (I don't know about you but I feel like I
> >> am
> >> m> forever installing bolt-ons for psh). Any idea if there is going
> >> to
> >> m> be anything like this in PSH2?
> >> m>
> >> m> What's the .Net option?
> >> m>
> >> m> Much appreciated
> >> m>
> >> m> "Brandon Shell [MVP]" wrote:
> >> m>
> >>>> Do you want local or domain accounts?

>

> >>>> for local you will need to use WMI or .NET
> >>>> for Domain you can use the free Quest CMDLets or .NET
> >>>> Brandon Shell
> >>>> ---------------
> >>>> Blog:http://www.bsonposh.com/
> >>>> PSH Scripts Project: www.codeplex.com/psobject
> >>>> m> It was really a powershell equivalent that passes out the result
> >>>> as
> >>>> m> an object. At the moment I have to parse the output with regex
> >>>> and I
> >>>> m> just think there must be an easier way.
> >>>> m>
> >>>> m> "Marco Shaw [MVP]" wrote:
> >>>> m>
> >>>>>> malckelly wrote:

>

> >>>>>>> Is there an equivalent in powershell for doing

>

> >>>>>>> "net user user1 /domain"

>

> >>>>>>> or really just a "net user" command.

>

> >>>>>> What were you looking to do? You can just use "net user user1
> >>>>>> /domain" from within PowerShell.

>

> >>>>>> The Quest AD cmdlets also provide a lot of information, and
> >>>>>> there's
> >>>>>> a
> >>>>>> free version:
> >>>>>>http://www.quest.com/powershell/
> >>>>>> Marco
> >>>>>> --
> >>>>>> Microsoft MVP - Windows PowerShell
> >>>>>>http://www.microsoft.com/mvp
> >>>>>> PowerGadgets MVP
> >>>>>>http://www.powergadgets.com/mvp
> >>>>>> Blog:
> >>>>>>http://marcoshaw.blogspot.com

>
> s> I appreciate that PowerShell is developed separately from other
> s> technologies inside Microsoft. You are absolutely right that it
> s> makes for a more focused and reliable product.
> s>
> s> What you are forgetting is that I, like most other PowerShell users,
> s> don't care.
> s>
> s> All we want is for you (read Microsoft) to provide a consistent
> s> toolset to manage the keystone MS enterprise product (i.e. Active
> s> Directory). It does not matter to me one whit if the AD management
> s> tools come from the Exchange team, or the AD team or even from the
> s> janitorial dept. We are already faced with a fragmentation in the AD
> s> management by the Exchange toolset touching on AD but then only doing
> s> what Exchange needs and no more. Now we are faced with the prospect
> s> of having get-user for Exchange and then get-QADUser for the Quest
> s> tools and maybe if we are lucky get-ADUser from the Active Directory
> s> team. What if the MOM, SMS and Office teams also touch on AD as
> s> well? Things fall between the cracks when tools are that scattered
> s> and it's the user who ends up paying the price.
> s>
> s> Is this sentiment at all unreasonable for someone who exists outside
> s> the MS organization?
> s>
> s> I apologize if I seem short in my rant but this is a very obvious
> s> problem that needs to be addressed if you want to see PowerShell
> s> taken seriously in the Enterprise. We don't care who inside
> s> Microsoft provides the functionality we need, all that we care about
> s> is that it gets done. Having access to dotNET functionality is nice
> s> but it is being used as a crutch for not delivering a complete
> s> experience. My understanding is that PS is going to be integrated
> s> into the Windows Server 2008 and I would love to have the tools to
> s> properly manage AD when it launches.
> s>
> s> PowerShell is an amazing product, I enjoy using it. I think it is
> s> the first breath of fresh air in an otherwise stagnant field in
> s> computer technology. I hope to see it continue to mature into a
> s> usable, and supported platform.
> s>- Hide quoted text -
>
> - Show quoted text -

I'm not saying that everything should be included by default, far from
it. And adding third party tools is the antithesis of my argument.
You are absolutely right that the PS team should focus on the platform
and not on the tools. My issue is with how (from an outside
perspective) MS has placed no priority on making such tools.
PowerShell 1.0 is over a year old and 2.0 is around the corner. We
still have only three options for managing Active Directory, which is
pivotal in any MS enterprise environment.
1. Code dotNET ADSI objects. This is arduous and outside the skill of
the large portion of the user base. Even more difficult to do it well
and make the code efficient.
2. Install Exchange AND only run through the Exchange branded
PowerShell. This has limited usability as the Exchange team only
coded what fell under their scope and this may conflict with any
official PS extensions that are created by the Active Directory team
or any other MS product team that happens to touch on AD (which if
it's an enterprise tool it would). The fact that the Exchange PS
experience is separate from the generalized PS experience feels a lot
like a fork to me. (I would love to hear the official word on how
Exchange 2007 is going to handle PS2 when it is finalized.)
3. Install the Quest PS extensions. Having to rely upon a third party
provider to manage a fundamental resource like AD is dangerous at
best. At any point in time Quest could decide to withdraw their free
package or change it in a way that they choose.

Please understand I am not complaining about PowerShell itself nor am
I complaining about the PowerShell team. My issue is with the
Microsoft organization for not doing more to embrace this powerful
platform and for not making its adoption by other internal teams a
greater priority. I would have no problem downloading a PS package to
add AD control. We've done it for years in order to manage Group
Policy via the GPMC and a host of other vital tools. After more than
a year I think AD tools are distressingly overdue. Maybe with the
launch of Windows Server 2008 we will see a greater emphasis placed on
AD tools in PowerShell. I know that they will not be included at
launch, though it would seem like an obvious oversight.

If you know where the members of the AD team blog or post I would be
happy to annoy them directly. I've looked all over but I cannot find
a trace of them.

Powershell was added to CEC 2009... so they dont really have a choice now

I am all aboard with you on getting AD Snapins, but the Quest ones are free
and very easy to install so it is a little easier.

Brandon Shell
---------------
Blog: http://www.bsonposh.com/
PSH Scripts Project: www.codeplex.com/psobject

s> On Dec 7, 2:11 pm, Brandon Shell [MVP] <a_bshell.m...@xxxxxx>
s> wrote:
s>

>> One qualification on my Part - I dont work for MS
>>
>> I think everyone agrees that tools should be consistent, but it
>> doesnt seem
>> like your asking for that. It seems like your asking MS to install
>> all the
>> CMDLets for all thier products in base Powershell. Because that is
>> not feasable,
>> what would you like? What products should and shouldnt be included?
>> Then
>> the problem is why cant powershell be shipped with Third Party
>> snapins from
>> Citrix/VMware/IBM and a slew of other vendors.
>> IMO... it much better to let each provider deal with thier own
>> snap-ins. Let the Powershell team focus on making Powershell better.
>>
>> All that said, MS did include Powershell in the CEC for 2009, which
>> implies that most of not all products will support Powershell in some
>> form.
>>
>> Brandon Shell
>> ---------------
>> Blog:http://www.bsonposh.com/
>> PSH Scripts Project: www.codeplex.com/psobject
>> s> On Dec 6, 8:54 am, Brandon Shell [MVP]
>> <a_bshell.m...@xxxxxx>s> wrote:
>>
>> s>
>>

>>>> You can use this
>>>>
>>>> function Get-ADUsers{
>>>> Param($Dom)
>>>> if($Dom){$Dom = [ADSI]"LDAP://$dom"}else{$Dom = [ADSI]""}
>>>> $filter = "(&(objectcategory=user))"
>>>> $searcher = New-Object
>>>> System.DirectoryServices.DirectorySearcher($Dom,$filter)
>>>> $searcher.pagesize = 1000
>>>> $searcher.findall()
>>>> }
>>>> Q: Any idea if there is going to be anything like this in PSH2?
>>>> A: I may be off base here, but my general feeling on this is the
>>>> Powershell
>>>> Team is not going to provide this functionality and to be honest I
>>>> agree
>>>> with that decision. IMO the Powershell team is directly responsible
>>>> for the
>>>> Powershell framework and base CMDLets. Extenstions should be
>>>> provided
>>>> by
>>>> "Internal Third Party Teams" ie Exchange,Active Directory,SMS, MOM,
>>>> and Office.
>>>> Treating internal products like external third party products is
>>>> great. It
>>>> allows the Powershell team to focus on the actual functionality of
>>>> Powershell
>>>> itself.
>>>> Brandon Shell
>>>> ---------------
>>>> Blog:http://www.bsonposh.com/
>>>> PSH Scripts Project: www.codeplex.com/psobject
>>>> m> It would be for domain users. Quest CMDlets I will go and
>>>> m> investigate, but it would be nicer if it was something that was
>>>> m> included in powershell. (I don't know about you but I feel like
>>>> I
>>>> am
>>>> m> forever installing bolt-ons for psh). Any idea if there is
>>>> going
>>>> to
>>>> m> be anything like this in PSH2?
>>>> m>
>>>> m> What's the .Net option?
>>>> m>
>>>> m> Much appreciated
>>>> m>
>>>> m> "Brandon Shell [MVP]" wrote:
>>>> m>
>>>>>> Do you want local or domain accounts?
>>>>>>
>>>>>> for local you will need to use WMI or .NET
>>>>>> for Domain you can use the free Quest CMDLets or .NET
>>>>>> Brandon Shell
>>>>>> ---------------
>>>>>> Blog:http://www.bsonposh.com/
>>>>>> PSH Scripts Project: www.codeplex.com/psobject
>>>>>> m> It was really a powershell equivalent that passes out the
>>>>>> result
>>>>>> as
>>>>>> m> an object. At the moment I have to parse the output with
>>>>>> regex
>>>>>> and I
>>>>>> m> just think there must be an easier way.
>>>>>> m>
>>>>>> m> "Marco Shaw [MVP]" wrote:
>>>>>> m>
>>>>>>>> malckelly wrote:
>>>>>>>>
>>>>>>>>> Is there an equivalent in powershell for doing
>>>>>>>>>
>>>>>>>>> "net user user1 /domain"
>>>>>>>>>
>>>>>>>>> or really just a "net user" command.
>>>>>>>>>
>>>>>>>> What were you looking to do? You can just use "net user user1
>>>>>>>> /domain" from within PowerShell.
>>>>>>>>
>>>>>>>> The Quest AD cmdlets also provide a lot of information, and
>>>>>>>> there's
>>>>>>>> a
>>>>>>>> free version:
>>>>>>>> http://www.quest.com/powershell/
>>>>>>>> Marco
>>>>>>>> --
>>>>>>>> Microsoft MVP - Windows PowerShell
>>>>>>>> http://www.microsoft.com/mvp
>>>>>>>> PowerGadgets MVP
>>>>>>>> http://www.powergadgets.com/mvp
>>>>>>>> Blog:
>>>>>>>> http://marcoshaw.blogspot.com

>> s> I appreciate that PowerShell is developed separately from other
>> s> technologies inside Microsoft. You are absolutely right that it
>> s> makes for a more focused and reliable product.
>> s>
>> s> What you are forgetting is that I, like most other PowerShell
>> users,
>> s> don't care.
>> s>
>> s> All we want is for you (read Microsoft) to provide a consistent
>> s> toolset to manage the keystone MS enterprise product (i.e. Active
>> s> Directory). It does not matter to me one whit if the AD
>> management
>> s> tools come from the Exchange team, or the AD team or even from the
>> s> janitorial dept. We are already faced with a fragmentation in the
>> AD
>> s> management by the Exchange toolset touching on AD but then only
>> doing
>> s> what Exchange needs and no more. Now we are faced with the
>> prospect
>> s> of having get-user for Exchange and then get-QADUser for the Quest
>> s> tools and maybe if we are lucky get-ADUser from the Active
>> Directory
>> s> team. What if the MOM, SMS and Office teams also touch on AD as
>> s> well? Things fall between the cracks when tools are that
>> scattered
>> s> and it's the user who ends up paying the price.
>> s>
>> s> Is this sentiment at all unreasonable for someone who exists
>> outside
>> s> the MS organization?
>> s>
>> s> I apologize if I seem short in my rant but this is a very obvious
>> s> problem that needs to be addressed if you want to see PowerShell
>> s> taken seriously in the Enterprise. We don't care who inside
>> s> Microsoft provides the functionality we need, all that we care
>> about
>> s> is that it gets done. Having access to dotNET functionality is
>> nice
>> s> but it is being used as a crutch for not delivering a complete
>> s> experience. My understanding is that PS is going to be integrated
>> s> into the Windows Server 2008 and I would love to have the tools to
>> s> properly manage AD when it launches.
>> s>
>> s> PowerShell is an amazing product, I enjoy using it. I think it is
>> s> the first breath of fresh air in an otherwise stagnant field in
>> s> computer technology. I hope to see it continue to mature into a
>> s> usable, and supported platform.
>> s>- Hide quoted text -
>> - Show quoted text -
>>

s> I'm not saying that everything should be included by default, far
s> from
s> it. And adding third party tools is the antithesis of my argument.
s> You are absolutely right that the PS team should focus on the
s> platform
s> and not on the tools. My issue is with how (from an outside
s> perspective) MS has placed no priority on making such tools.
s> PowerShell 1.0 is over a year old and 2.0 is around the corner. We
s> still have only three options for managing Active Directory, which is
s> pivotal in any MS enterprise environment.
s> 1. Code dotNET ADSI objects. This is arduous and outside the skill
s> of
s> the large portion of the user base. Even more difficult to do it
s> well
s> and make the code efficient.
s> 2. Install Exchange AND only run through the Exchange branded
s> PowerShell. This has limited usability as the Exchange team only
s> coded what fell under their scope and this may conflict with any
s> official PS extensions that are created by the Active Directory team
s> or any other MS product team that happens to touch on AD (which if
s> it's an enterprise tool it would). The fact that the Exchange PS
s> experience is separate from the generalized PS experience feels a lot
s> like a fork to me. (I would love to hear the official word on how
s> Exchange 2007 is going to handle PS2 when it is finalized.)
s> 3. Install the Quest PS extensions. Having to rely upon a third
s> party
s> provider to manage a fundamental resource like AD is dangerous at
s> best. At any point in time Quest could decide to withdraw their free
s> package or change it in a way that they choose.
s> Please understand I am not complaining about PowerShell itself nor am
s> I complaining about the PowerShell team. My issue is with the
s> Microsoft organization for not doing more to embrace this powerful
s> platform and for not making its adoption by other internal teams a
s> greater priority. I would have no problem downloading a PS package
s> to add AD control. We've done it for years in order to manage Group
s> Policy via the GPMC and a host of other vital tools. After more than
s> a year I think AD tools are distressingly overdue. Maybe with the
s> launch of Windows Server 2008 we will see a greater emphasis placed
s> on AD tools in PowerShell. I know that they will not be included at
s> launch, though it would seem like an obvious oversight.
s>
s> If you know where the members of the AD team blog or post I would be
s> happy to annoy them directly. I've looked all over but I cannot find
s> a trace of them.
s>