locked
Import-CSV | New-ADUser script RRS feed

  • Question

  • Trying to accomplish a very simple script that will take account information from a pipe (|) delimited file, and create new AD users.  This is what I have so far:

    Import-CSV c:\new-users.txt -delimiter '|' | New-ADUser

    The problem I have is that I have non-standard header for the .txt file.  This cannot be changed.  Here's the file's header:

    Blank|GLID|QLID|ComboName|Lastname|FirstName|Blank2|Blank3|Address|Blank4|City|state|ZIP|Country|NoIdea1|NoIdea2|Ph|Blank5|email|Something|NoIdea3|Blank6|Blank7|Org

    This is set in stone and cannot be changed.  I am aware there's a technique using Select-Object that could possibly assist but I cant seem to get it working.  What I want is for this thing to pull from the .txt file all of the information it needs, change that header information to reflect what it is looking for and then create the user account.  With the fewest lines of code possible.  How can I accomplish this?

    Tuesday, August 7, 2012 6:53 PM

Answers

  • The New-ADUser cmdlet help (use "Get-Help New-ADUser -Full") documents the parameters that are supported, and provides examples. The parameters are what I call Property Methods (my term) because they are methods that may or may not correspond to the AD attributes. In many cases the Property Methods involve a conversion. For example the Get-ADUser cmdlet has a SID parameter. Of course, there is no such AD attribute. The corresponding AD attribute is objectSID, but this is a byte array. The SID property method converts the byte array into a string. Similarly, the -AccountExpirationDate parameter of the New-ADUser cmdlet converts a date value into the corresponding Integer8 (64-bit) integer (correcting for the local time zone) and assigns this to the accountExpires AD attribute (which is actually in UTC).

    The Help for New-ADUser documents the lDAPDisplayName of the attribute that corresponds to each parameter. If you want to assign values to attributes for which there is no corresponding parameter, you can use the -OtherAttributes parameter, which can handle any single or multi-valued string attributes. You may even what to use -OtherAttributes for all attributes you want to assign.

    As far as efficiency goes, I would suggest you use whatever method you prefer. The code you posted in your last reply uses ADSI and is supported by PowerShell V1. Especially for someone familiar with AD, it may make more sense. The PowerShell V2 AD module cmdlets are designed to be "user friendly" and hide as much detail as possible. That means many aliases are used, which only confuses people like you and me that are familiar with AD. The AD cmdlets can save keystrokes if you work at a command prompt. However, for most tasks I prefer to script, so I can troubleshoot, re-use the code, and modify for bulk import/export/update operations. Then the number of keystrokes matters less.

    When I have tested, the AD cmdlets are much slower than code using ADSI (by a factor of 2 or 3). In most cases this doesn't matter unless you are dealing with ten's or hundred's of thousands of objects. It is also easier to be inefficient with the AD cmdlets, for example piping Get-ADUser to a WHERE instead of using the -Filter or -LDAPFilter parameters to reduce the size of the resultset communicated over the network. I should note that my testing might be biased, as I compared Get-ADUser with [ADSISearcher]. The Get-AD* cmdlets retrieve a default set of parameters, whether you need them or not. Several of these parameters require conversion (such as SID and objectGUID) which adds even more overhead. I have not yet compared New-ADUser to code similar to yours, so the differences may be less.

     As noted by others, the names used in the header line of your csv can be anything. It's up to you to get the proper name for each attribute. Each field in the csv is referenced by $_.<csv field name> when you pipe the output of Import-Csv, where <csv field name> is the name defined in the header line.


    Richard Mueller - MVP Directory Services


    • Edited by Richard MuellerMVP Wednesday, August 8, 2012 12:59 AM changed GUID to objectGUID
    • Marked as answer by Henry Dunn Thursday, August 9, 2012 4:48 PM
    Wednesday, August 8, 2012 12:48 AM
  • Import-CSV c:\new-users.txt -delimiter '|' |
         %{ New-ADUser -lastname $_.lastname -firstname $_.firstname...etc

    }

    Just use the field names as they are.  Reference them in the loop as $_.<fieldname> as I hav edemoed above.


    ¯\_(ツ)_/¯

    • Marked as answer by Henry Dunn Thursday, August 9, 2012 4:07 PM
    Tuesday, August 7, 2012 7:12 PM
  • @jrv

    It gives the following error:

    New-ADUser : A parameter cannot be found that matches parameter name 'lastname'.
    At line:2 char:29
    +      %{ New-ADUser -lastname <<<<  $_.Lastname -firstname $_.Firstname
        + CategoryInfo          : InvalidArgument: (:) [New-ADUser], ParameterBindingException
        + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.ActiveDirectory.Management.Commands.NewADUser

    I run just the import and it enumerates the expected info from the .txt file.  Coupled with the point past the pipe, it fails.  Not sure what I'm doing incorrectly here.


    You say you are well versed in AD, so I assume that you know that the command at line 2 is trying to create a new user with the indicated 'firstname' and 'lastname' attributes. that would fail in our domain as well, as the actual name of the attribute giving one's first name is 'givenname', while the last name attribute is actually called 'sn'.

    What you need to do is determine which AD attribues correspond to the various columns in your csv file, and convert these names from the weird set to the AD set as they are processed using a filter of some sort.

    Of course, nobody here will be able to tell you what, if anything, the GLID, QLID, ComboName, Something, and noIdea fields might represent in AD. I also suspect you might have to derive some AD fields such as sAMAccountName, unless the HR department that provides you with the csv file has embedded them in some of the weird fields as valid and non-colliding values that would actually work.


    Al Dunbar -- remember to 'mark or propose as answer' or 'vote as helpful' as appropriate.

    • Marked as answer by Henry Dunn Thursday, August 9, 2012 4:47 PM
    Tuesday, August 7, 2012 9:39 PM

All replies

  • Hi,

    What do you mean by "non-standard header"?

    Bill

    Tuesday, August 7, 2012 7:03 PM
  • Import-CSV c:\new-users.txt -delimiter '|' |
         %{ New-ADUser -lastname $_.lastname -firstname $_.firstname...etc

    }

    Just use the field names as they are.  Reference them in the loop as $_.<fieldname> as I hav edemoed above.


    ¯\_(ツ)_/¯

    • Marked as answer by Henry Dunn Thursday, August 9, 2012 4:07 PM
    Tuesday, August 7, 2012 7:12 PM
  • And you think that this is the most elegant, simplest way to accomplish what I'm after?  I am a novice with scripting/powershell so keep that in mind.  Can you explain what you did there after the pipe in detail a little bit?  Thanks.
    Tuesday, August 7, 2012 8:14 PM
  • The header that I listed is not what New-ADUser would look for/bind to automatically.  Not the ADSI standard names.  It's coming in from an HR source that I cant control and it wont really be very efficient to change, as it will be thousands of records.

    Tuesday, August 7, 2012 8:16 PM
  • Weel  I guees it would be best if you learned a bit of PowerShell.  The exampe is very explicit.  The CSV fro is enumerated and teh fields are applied to teh atributes you use to create a new user.  WIthout a full course in WIndows AD and the AaD Cmdlets in Powershell there is really not much more that I can tell you.

    There is a button on the upper menu called "Learn" which links ot an extremely ruich set of learning tools and videos for PowerShell.


    ¯\_(ツ)_/¯

    Tuesday, August 7, 2012 8:32 PM
  • I am interested in learning and am using this as a learning experience.  I am however under a time crunch and figured I'd reach out to the forums for some help in understanding the bits I dont understand.  Thanks for your help...
    Tuesday, August 7, 2012 8:39 PM
  • @jrv

    It gives the following error:

    New-ADUser : A parameter cannot be found that matches parameter name 'lastname'.
    At line:2 char:29
    +      %{ New-ADUser -lastname <<<<  $_.Lastname -firstname $_.Firstname
        + CategoryInfo          : InvalidArgument: (:) [New-ADUser], ParameterBindingException
        + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.ActiveDirectory.Management.Commands.NewADUser

    I run just the import and it enumerates the expected info from the .txt file.  Coupled with the point past the pipe, it fails.  Not sure what I'm doing incorrectly here.

    Tuesday, August 7, 2012 8:47 PM
  • unfortuabely I gave yu the explanation above and you didn't understand it because you do not know enough about AD or PowerShell. To explian it all to you owould take more than a page. If you knew the basics teh above would be enough.

    Type

    help New-ADUser -full

    help Import-Csv -full

    for complete examples and

    The examples will give you more detail.  If you have a specific question I can try to answer it.


    ¯\_(ツ)_/¯


    • Edited by jrv Tuesday, August 7, 2012 8:49 PM
    Tuesday, August 7, 2012 8:49 PM
  • @jrv

    It gives the following error:

    New-ADUser : A parameter cannot be found that matches parameter name 'lastname'.
    At line:2 char:29
    +      %{ New-ADUser -lastname <<<<  $_.Lastname -firstname $_.Firstname
        + CategoryInfo          : InvalidArgument: (:) [New-ADUser], ParameterBindingException
        + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.ActiveDirectory.Management.Commands.NewADUser

    I run just the import and it enumerates the expected info from the .txt file.  Coupled with the point past the pipe, it fails.  Not sure what I'm doing incorrectly here.

    I did not match up the parameters.  I just showed you how it would let you bind to your header.  You need to bind the New-ADUser parameters to your file items. as many as you need.  You need a minimum of a name.  Start by reading the help.

    Here is  little better exampe but you still need to provide a samaccountname and a username.

    Import-CSV c:\new-users.txt -delimiter '|' |
        ForEach-Object{
            New-ADUser -samaccountname "????" -AccountAPssword 'ziplmuxpltux'-GivenName $_.FirstName -Surname $_.Lastname -City $_.City -State $_.State -Address $_.Address -WhatIf
        }


    ¯\_(ツ)_/¯


    • Edited by jrv Tuesday, August 7, 2012 9:03 PM
    Tuesday, August 7, 2012 9:02 PM
  • The script errored out with the error I pasted.  Can you explain why and what i'm doing wrong?  I have a basic understanding, which is what I stated earlier.
    Tuesday, August 7, 2012 9:04 PM
  • I am very well versed in AD by the way.  It's the scripting piece and specifically the powershell commands I only have basic knowledge of.  I've done exactly what you just said, looked at the full detailed help file for new-aduser.  I needed to get some expert explanation as it's not working for me the way it is explained.  That is all i'm trying to gain help on.  I am sorry if I am not being clear here, didnt know I would have to defend my basic knowledge.  I thought that's what these forums were for, to gain further understanding.  Can someone else please help out with this?
    Tuesday, August 7, 2012 9:06 PM
  •     ForEach-Object{
            New-ADUser `
                        -samaccountname '<generate a unique name>' `
                        -AccountAPssword 'ziplmuxpltux' `
                        -DisplayName "$($_.FirstName) $($_.LastName)" `
                        -GivenName $_.FirstName `
                        -Surname $_.Lastname `
                        -City $_.City `
                        -State $_.State `
                        -Address $_.Address `
                        -WhatIf
        }

    Here is an even more explicit version.


    ¯\_(ツ)_/¯

    Tuesday, August 7, 2012 9:08 PM
  • I am very well versed in AD by the way.  It's the scripting piece and specifically the powershell commands I only have basic knowledge of.  I've done exactly what you just said, looked at the full detailed help file for new-aduser.  I needed to get some expert explanation as it's not working for me the way it is explained.  That is all i'm trying to gain help on.  I am sorry if I am not being clear here, didnt know I would have to defend my basic knowledge.  I thought that's what these forums were for, to gain further understanding.  Can someone else please help out with this?

    Use New-ADUser without the file and ry to create a user using the examples until yu are compfortable with how you crate users in AD>  The GUI does almost everything for you automatically.  Thger is much you do not know about AD if you have not scripted it.  Using the GUI is not about knowing AD it is about using a wizard to create objects.  Thin about what you have to provide to create a new user.  You need a asmname, a display name a CN and a password.  Everything else is optional.

    The AD CmdLets allow yu to do that too.  Jsut try it.  Use 'Whatif" so you don't actyually create teh user.  This will allow you to repeat teh asm caopmmnd over and over and it will tell you teh "you would have created teh user"  it wil erero if the command is wrong.

    After about 15 or 20 minutes you will see what it is you want to do.


    ¯\_(ツ)_/¯

    Tuesday, August 7, 2012 9:22 PM
  • @jrv

    It gives the following error:

    New-ADUser : A parameter cannot be found that matches parameter name 'lastname'.
    At line:2 char:29
    +      %{ New-ADUser -lastname <<<<  $_.Lastname -firstname $_.Firstname
        + CategoryInfo          : InvalidArgument: (:) [New-ADUser], ParameterBindingException
        + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.ActiveDirectory.Management.Commands.NewADUser

    I run just the import and it enumerates the expected info from the .txt file.  Coupled with the point past the pipe, it fails.  Not sure what I'm doing incorrectly here.


    You say you are well versed in AD, so I assume that you know that the command at line 2 is trying to create a new user with the indicated 'firstname' and 'lastname' attributes. that would fail in our domain as well, as the actual name of the attribute giving one's first name is 'givenname', while the last name attribute is actually called 'sn'.

    What you need to do is determine which AD attribues correspond to the various columns in your csv file, and convert these names from the weird set to the AD set as they are processed using a filter of some sort.

    Of course, nobody here will be able to tell you what, if anything, the GLID, QLID, ComboName, Something, and noIdea fields might represent in AD. I also suspect you might have to derive some AD fields such as sAMAccountName, unless the HR department that provides you with the csv file has embedded them in some of the weird fields as valid and non-colliding values that would actually work.


    Al Dunbar -- remember to 'mark or propose as answer' or 'vote as helpful' as appropriate.

    • Marked as answer by Henry Dunn Thursday, August 9, 2012 4:47 PM
    Tuesday, August 7, 2012 9:39 PM
  • Here's what I had:

    $objOU=[ADSI]“LDAP://OU=Sample_Users,DC=domain,DC=local”
    $dataSource=import-csv “new-users.txt” -delimiter '|'
    foreach($dataRecord in $datasource) {
    $cn=$dataRecord.FirstName + ” ” + $dataRecord.LastName
    $sAMAccountName=$dataRecord.FirstName + “.” + $dataRecord.LastName
    $givenName=$dataRecord.FirstName
    $sn=$dataRecord.LastName
    $sAMAccountName=$sAMAccountName.ToLower()
    $displayName=$sn + “, ” + $givenName
    $email=$dataRecord.email
    $ph=$dataRecord.ph
    $cube=$dataRecord.cube
    $city=$dataRecord.city
    $street=$dataRecord.Address
    $zip=$dataRecord.ZIP
    $userPrincipalName=$sAMAccountName + “@testlabs.internal”
    $objUser=$objOU.Create(“user”,”CN=”+$cn)
    $objUser.Put(“sAMAccountName”,$sAMAccountName)
    $objUser.Put(“userPrincipalName”,$userPrincipalName)
    $objUser.Put(“displayName”,$displayName)
    $objUser.Put(“givenName”,$givenName)
    $objUser.Put(“sn”,$sn)
    $objUser.Put("mail",$email)
    $objUser.Put("telephonenumber",$ph)
    $objUser.Put("l",$city)
    $objUser.Put("streetAddress",$street)
    $objUser.Put("postalCode",$ZIP)
    $objUser.Put("physicalDeliveryOfficeName",$cube)
    $objUser.SetInfo()
    $objUser.SetPassword(“P@assw0rd”)
    $objUser.psbase.InvokeSet(“AccountDisabled”,$false)
    $objUser.SetInfo()
    }
    What i'd like is to use the cmdlets in the same fashion, exactly the same fashion.  I think that the cmdlets would be more flexible and efficient in accomplishing what I want.  Less code, more flexibility.  I could be wrong on that.  This method above works and it is able to create accounts using the pipe delimited txt file.

    Tuesday, August 7, 2012 9:58 PM
  • Al - close.  New-AdUser does not use sn and the others which is why I flubbed it the frist time,  I bew it was non-standard but didn't remember.  I use New-ADUser -? to often of jsut use tab completion.  It makes me lazy after a while.

    The parameters are GivernName and SurName  I suspect that "sn" might be an alias but really never tried it.

    Good info though.  You put the end part well.  I couldn't com up with a good wording.


    ¯\_(ツ)_/¯

    Tuesday, August 7, 2012 10:05 PM
  • Henry - if youare going to bounce around like that I ma going oto leave you to fend for yourself.  I really don't want ot make helping you my lifes work.

    YOu seem to already know wht you want to do. 

    The posting of the CMdLet is exactly the same thing as you just posted.  Like I said. YTou ned to learn the basics of both POwerSHel and Active Directory.

    Good Luck.


    ¯\_(ツ)_/¯

    Tuesday, August 7, 2012 10:07 PM
  • Al - close.  New-AdUser does not use sn and the others which is why I flubbed it the frist time,  I bew it was non-standard but didn't remember.  I use New-ADUser -? to often of jsut use tab completion.  It makes me lazy after a while.

    The parameters are GivernName and SurName  I suspect that "sn" might be an alias but really never tried it.

    Good info though.  You put the end part well.  I couldn't com up with a good wording.


    ¯\_(ツ)_/¯

    I don't use New-ADUser or any of the other AD-related cmdlets, whether from MS or Quest. I find it odd that they too (like Henry's nonstandard header) seem to provide their own version of the AD attribute names. Even if they are more consistent than native AD nomenclature, that just adds a layer of abstraction that I expect may generate confusion.

    When I do a query and display all returned attributes, I see 'sn', not 'surname'. If both are valid in AD, that makes it look like 'surname' is the alias rather than 'sn'.


    Al Dunbar -- remember to 'mark or propose as answer' or 'vote as helpful' as appropriate.

    Tuesday, August 7, 2012 11:40 PM
  • The New-ADUser cmdlet help (use "Get-Help New-ADUser -Full") documents the parameters that are supported, and provides examples. The parameters are what I call Property Methods (my term) because they are methods that may or may not correspond to the AD attributes. In many cases the Property Methods involve a conversion. For example the Get-ADUser cmdlet has a SID parameter. Of course, there is no such AD attribute. The corresponding AD attribute is objectSID, but this is a byte array. The SID property method converts the byte array into a string. Similarly, the -AccountExpirationDate parameter of the New-ADUser cmdlet converts a date value into the corresponding Integer8 (64-bit) integer (correcting for the local time zone) and assigns this to the accountExpires AD attribute (which is actually in UTC).

    The Help for New-ADUser documents the lDAPDisplayName of the attribute that corresponds to each parameter. If you want to assign values to attributes for which there is no corresponding parameter, you can use the -OtherAttributes parameter, which can handle any single or multi-valued string attributes. You may even what to use -OtherAttributes for all attributes you want to assign.

    As far as efficiency goes, I would suggest you use whatever method you prefer. The code you posted in your last reply uses ADSI and is supported by PowerShell V1. Especially for someone familiar with AD, it may make more sense. The PowerShell V2 AD module cmdlets are designed to be "user friendly" and hide as much detail as possible. That means many aliases are used, which only confuses people like you and me that are familiar with AD. The AD cmdlets can save keystrokes if you work at a command prompt. However, for most tasks I prefer to script, so I can troubleshoot, re-use the code, and modify for bulk import/export/update operations. Then the number of keystrokes matters less.

    When I have tested, the AD cmdlets are much slower than code using ADSI (by a factor of 2 or 3). In most cases this doesn't matter unless you are dealing with ten's or hundred's of thousands of objects. It is also easier to be inefficient with the AD cmdlets, for example piping Get-ADUser to a WHERE instead of using the -Filter or -LDAPFilter parameters to reduce the size of the resultset communicated over the network. I should note that my testing might be biased, as I compared Get-ADUser with [ADSISearcher]. The Get-AD* cmdlets retrieve a default set of parameters, whether you need them or not. Several of these parameters require conversion (such as SID and objectGUID) which adds even more overhead. I have not yet compared New-ADUser to code similar to yours, so the differences may be less.

     As noted by others, the names used in the header line of your csv can be anything. It's up to you to get the proper name for each attribute. Each field in the csv is referenced by $_.<csv field name> when you pipe the output of Import-Csv, where <csv field name> is the name defined in the header line.


    Richard Mueller - MVP Directory Services


    • Edited by Richard MuellerMVP Wednesday, August 8, 2012 12:59 AM changed GUID to objectGUID
    • Marked as answer by Henry Dunn Thursday, August 9, 2012 4:48 PM
    Wednesday, August 8, 2012 12:48 AM
  • The issue of default properties (and also "extended" properties) retrieved by the Get-AD* cmdlets is not documented anywhere that I can find, so I wrote a Wiki article on the subject:

    http://social.technet.microsoft.com/wiki/contents/articles/12031.active-directory-powershell-ad-module-properties-en-us.aspx

    This attempts to document what each property (parameter) corresponds to in AD (the lDAPDisplayName of the corresponding attribute, plus an indication if some conversion or other code is required). This article links other articles on the "extended" properties for each cmdlet (the list is my own, after much testing). This only applies to the Get-AD* and Set-AD* cmdlets, but most of the New-ADUser parameters match those for Get-ADUser.


    Richard Mueller - MVP Directory Services

    Wednesday, August 8, 2012 1:09 AM
  • I knew there was a reason why I held off on entering a "where is Richard Mueller when we need him" post!

    Thanks for the excellent explanation. Having struggled (with your help) through some of the apparent inconsistencies and quirks of AD I imagine there would be a rational for functionality that emulated a "simpler" view of AD. I mean, we could probably guess that "sn" meant surname, but who knew that "l" (for "location") meant "city"? And those pesky date, byte-array, and multivalued attributes (one of which can only contain one value)...

    But your explanation solidifies my contention that, for my purposes, there is little to be gained by adding this level of abstraction. Thanks for that.


    Al Dunbar -- remember to 'mark or propose as answer' or 'vote as helpful' as appropriate.

    Wednesday, August 8, 2012 9:58 PM
  • Richard - excellent.

    We need a table of allmappings to LDAP and to AD name.  AD uses 'dash' syntax.

    Such as the CN is "Given-Name" and the LDP Display Name is  "givenName".

    http://msdn.microsoft.com/en-us/library/windows/desktop/ms675719(v=vs.85).aspx

    Example: (this is not what we need but a mapping such as this with the AD Cmdlet names agains LDAP alomg with access andother info would behelpful for those who are learning.

    CN

    SAM-Account-Name

    Ldap-Display-Name

    sAMAccountName

    Size

    Less than 20 characters.

    Update Privilege

    Domain administrator

    Update Frequency

    This value should be assigned when the account record is created, and should not change.

    Attribute-Id

    1.2.840.113556.1.4.221

    System-Id-Guid

    3e0abfd0-126a-11d0-a060-00aa006c33ed

    Syntax

    String(Unicode)


    ¯\_(ツ)_/¯


    • Edited by jrv Thursday, August 9, 2012 6:31 AM
    Thursday, August 9, 2012 6:24 AM
  • Thanks guys, appreciate the help.  I've been able to get it to work without error.  I'll need much more logic, like when an account already exists, I need still to check all attributes and add anything that is changed or different.  I'll cross that bridge when I get there.  Right now I just want a working script that will create the accounts, which I've got now.  Thanks again.
    Thursday, August 9, 2012 4:45 PM
  • I'm not sure what you mean by "AD uses 'dash' syntax", unless perhaps you are not referring to the actual AD, but to the AD cmdlets. I cannot think of any AD attributes that contain anything other than alphabetic characters.

    While such a mapping would be useful for some of us, it seems only an issue for those using the AD cmdlets. I currently use only my own simple powershell functions for querying AD, so I do not have to convert from one dictionary to another. Well, of course, powershell renders and interprets all AD attributes in lower case rather than the native case of AD (i.e. samaccountname vs sAMAccountName); fortunately, this is a relatively easy fact to remember...


    Al Dunbar -- remember to 'mark or propose as answer' or 'vote as helpful' as appropriate.

    Thursday, August 9, 2012 4:53 PM
  • I'm not sure what you mean by "AD uses 'dash' syntax", unless perhaps you are not referring to the actual AD, but to the AD cmdlets. I cannot think of any AD attributes that contain anything other than alphabetic characters.

    While such a mapping would be useful for some of us, it seems only an issue for those using the AD cmdlets. I currently use only my own simple powershell functions for querying AD, so I do not have to convert from one dictionary to another. Well, of course, powershell renders and interprets all AD attributes in lower case rather than the native case of AD (i.e. samaccountname vs sAMAccountName); fortunately, this is a relatively easy fact to remember...


    Al Dunbar -- remember to 'mark or propose as answer' or 'vote as helpful' as appropriate.

    Al - the attributes as you know them are teh AD display names or What is referred to as the LDAPDisplayName,  The actual bname of teh attribute in the schma is:

    CN

    SAM-Account-Name

    Ldap-Display-Name

    sAMAccountName

    Note the dashes in the CN for the schema name.  If we are doing a raw retrieval of teh shema item we use the schema name (schema CN) and not the LDAP-Display-Name.

    The point I was making was that MS needs to add a lookup like this one mapping the AD CmdLet attribute names to the LDAP-Display-Name the same way they did with the tables I posted in the above link.

    That ia all I was referering to.


    ¯\_(ツ)_/¯

    Thursday, August 9, 2012 7:07 PM
  • Each AD attribute has a corresponding object with class attributeSchema in the Schema container (cn=Schema,cn=Configuration,dc=MyDomain,dc=com) of AD. The cn attribute of this object is the "Name" of the attribute, but the lDAPDisplayName is used in all scripts and code. These objects also have other useful attributes, like isSingleValued, rangeUpper (max characters allowed), attributeSyntax, isMemberOfPartialAttributeSet (is in GC), and flags indicating if the attribute is indexed, operational, or replicated to all DC's.

    Many attribute cn's have dashes, like cn=Account-Expires. Most of the lDAPDisplayName's eliminate the dashes, like accountExpires. But there are exceptions, like msDS-SiteName and msPKI-Enrollment-Servers. Long ago I wrote a VBScript program to document all of the attributes in the schema, linked here:

    http://www.rlmueller.net/Schema.htm

    Using this, and other scripts, I created a spreadsheet of all attributes in a default installation of AD (no Exchange), which is the second Excel spreadsheet linked on this page:

    http://www.rlmueller.net/UserAttributes.htm

    Microsoft seems to like aliases, such as samid with dsquery. In the Wiki articles I linked earlier I tried to show the lDAPDisplayName of the attribute corresponding to all parameters supported by most of the PowerShell AD cmdlets. To be honest, I had to guess in some cases. I could find no other documentation.


    Richard Mueller - MVP Directory Services

    Thursday, August 9, 2012 8:03 PM
  • Richard - yu rwork on this is excellent.  I have referred to it in the past.  The Wiki article is extremely useful.

    What I wanted to note was that MS needs to do this in a more complete way.  There are many more aliases that can be used.  In fact. In many cases the LDAP-Display-Name is an alias amd it should be always although that could create conflicts I suppose.

    Quest flubbed on nomenclature in many ways.  Microsoft flubbed in completely different ways.  Neither Microsoft nor Quest have figured out how to deal with the complexity of AD and make it simple to the end user. Now there is an added layer of confusion because what the AD CmdLets do does not match well with previous documentation.


    ¯\_(ツ)_/¯

    Thursday, August 9, 2012 8:25 PM