Powershell "Net User" equivalent
malckelly
"net user user1 /domain"
or really just a "net user" command.
Marco Shaw [MVP]
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
Brandon Shell [MVP]
than net.exe.
If your interested I will post some examples.
"malckelly" <malc...@discussions.microsoft.com> wrote in message
news:90D1F7A8-98D7-4DD8...@microsoft.com...
malckelly
object. At the moment I have to parse the output with regex and I just think
there must be an easier way.
malckelly
return the result as an object so that it could be handled easier. At the
moment I have to user Regex to gather specific information.
Marco Shaw [MVP]
> It was really a powershell equivalent that passes out the result as an
> object. At the moment I have to parse the output with regex and I just think
> there must be an easier way.
Try the Quest cmdlets, otherwise Brandon has a lot of AD
experience/knowledge.
Example (using the 2.0 CTP):
PSH> get-qaduser foo_user|get-member -force|select name
(Don't use "-force" with PSH 1.0)
Name
----
pstypenames
psadapted
psbase
psextended
psobject
PsStandardMembers
Close
Equals
GetHashCode
GetPropertyValue
GetType
get_CanonicalName
get_City
get_Company
get_ConnectionParameters
get_CreationDate
get_Department
get_Description
get_DirectoryEntry
get_DisplayName
get_DN
get_Email
get_Fax
get_FirstName
get_Guid
get_HomePhone
get_Initials
get_IsOpen
get_Item
get_LastName
get_LogonName
get_Manager
get_MemberOf
get_MobilePhone
get_ModificationDate
get_Name
get_NetworkCredential
get_Notes
get_Office
get_Pager
get_ParentContainer
get_PhoneNumber
get_PostalCode
get_PostOfficeBox
get_Sid
get_StateOrProvince
get_StreetAddress
get_Title
get_Type
get_UserPrincipalName
get_WebPage
Open
RefreshCache
ToString
accountExpires
badPasswordTime
badPwdCount
cn
co
codePage
countryCode
distinguishedName
dSCorePropagationData
employeeID
givenName
homeMDB
homeMTA
instanceType
l
lastLogoff
lastLogon
lastLogonTimestamp
legacyExchangeDN
lockoutTime
logonCount
logonHours
mail
mailNickname
managedObjects
mDBUseDefaults
mobile
msExchALObjectVersion
msExchHomeServerName
msExchMailboxGuid
msExchMailboxSecurityDescriptor
msExchPoliciesIncluded
msExchUserAccountControl
mSMQDigests
mSMQSignCertificates
msRTCSIP-ArchivingEnabled
msRTCSIP-FederationEnabled
msRTCSIP-InternetAccessEnabled
msRTCSIP-IsMaster
msRTCSIP-PrimaryHomeServer
msRTCSIP-PrimaryUserAddress
msRTCSIP-UserEnabled
nTSecurityDescriptor
o
objectCategory
objectClass
objectGUID
objectSid
primaryGroupID
proxyAddresses
pwdLastSet
sAMAccountName
sAMAccountType
scriptPath
showInAddressBook
sn
st
telephoneNumber
textEncodedORAddress
userAccountControl
uSNChanged
uSNCreated
whenChanged
whenCreated
Item
CanonicalName
City
Company
ConnectionParameters
CreationDate
Department
Description
DirectoryEntry
DisplayName
DN
Email
Fax
FirstName
Guid
HomePhone
Initials
IsOpen
LastName
LogonName
Manager
MemberOf
MobilePhone
ModificationDate
Name
NetworkCredential
Notes
Office
Pager
ParentContainer
PhoneNumber
PostalCode
PostOfficeBox
Sid
StateOrProvince
StreetAddress
Title
Type
UserPrincipalName
WebPage
Brandon Shell [MVP]
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
it would be nicer if it was something that was included in powershell. (I
don't know about you but I feel like I am forever installing bolt-ons for
psh). Any idea if there is going to be anything like this in PSH2?
What's the .Net option?
Much appreciated
Brandon Shell [MVP]
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>
Karl Prosser[MVP]
> It would be for domain users. Quest CMDlets I will go and investigate, but
> it would be nicer if it was something that was included in powershell. (I
> don't know about you but I feel like I am forever installing bolt-ons for
> psh).
I think the bolt-on thing is by design.. MS does provide some ADSI
functionality built into powershell but really that is an odd fit, in
the future it will be a bolt-on from the active directory team i
suppose, and almost all other things will be a bolt-on for the
particular product akin to exchange for now. It would default the
purpose of powershell ,as a language and a base platform, to try to put
all functionality inside powershell itself, i think there is a
philosophical point here, but feel free to disagree ;)
one good thing about powershell being built on the dotnet framework is
that you have a HUGE premade, prerequisite bolt-on already there. If it
wasn't for that, i think i'd be depending on an awful lot more snapins.
sspenning
wrote:
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.
Brandon Shell [MVP]
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...@hotmail.com>
s> wrote:
s>
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>
sspenning
wrote:
>
> - 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.
Brandon Shell [MVP]
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...@hotmail.com>
s> wrote:
s>
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>