Microsoft® Windows® 2000 Scripting Guide
« Previous | Next »
Each of the previous code examples demonstrated one of the primary ADSI scripting task categories by completing a single task creating one object, deleting one object, writing one attribute, and reading one attribute. It is more common, however, to perform more than a single task in an ADSI script.
Large scripts start from a discrete set of tasks and tie them together to meet some larger administrative goal. Think about each script task as a building block. Each building block is useful in itself, but properly cementing the blocks together creates a larger, more functional structure, just as tying scripting tasks together makes a more robust and useful script.
When you are presented with a large, sophisticated script, you might be able to run it right away. But if you try to use it as a learning tool, it will be difficult to know where to start unless the script is broken down into its component parts. Therefore, consider documenting your scripts carefully so that other administrators can understand the purpose of your scripts and troubleshoot them when necessary.
Many production scripts include a significant amount of code that has nothing directly to do with ADSI one reason why you might have found other scripts hard to follow. The ADSI scripts included with the Microsoft® Windows® 2000 Server Resource Kit highlight this point. For example, the Resource Kit s ListDCs.vbs ADSI script is 454 lines long. Of the 454 lines, more than 400 lines have nothing to with ADSI. Why are they there? They are there because ListDCs.vbs is designed to be a general-purpose utility much like a command-line executable. As such, the script includes routines to parse command line arguments, format output, and handle errors. Although the routines are important to ListDCs.vbs, they are not part of ADSI technology. Admittedly, there are times when it is necessary to use some non-ADSI code in an ADSI script. The script code in this chapter, however, avoids non-ADSI scripting code as much as possible so that you can clearly see what ADSI scripting is.
To successfully create a script that writes and reads multiple attributes of an Active Directory object, you combine tasks described earlier in this chapter:
Complete the procedures in this section to perform write and read operations against an Active Directory user account object.
As you read this section, copy and paste the appropriate code lines into ModifyUser.vbs.
Complete one of the following steps to add the appropriate binding code line into ModifyUser.vbs:
Set objUser = _ GetObject(
"LDAP://cn=MyerKen,ou=HR,dc=NA,dc=fabrikam,dc=com
")
If you have created an OU of a different name and you do not have a domain named na.fabrikam.com, use the code in this step but change the DN to the Active Directory container where for the test account named MyerKen. For example, if your domain is named contoso.com and the OU that contains the MyerKen user account is named Test, the code statement is:
Set objUser = _ GetObject(
"LDAP://cn=MyerKen,ou=Test,dc=contoso,dc=com
")
Set objRootDSE = GetObject(
"LDAP://rootDSE
") Set objUser = GetObject(
"LDAP://cn=MyerKen,cn=Users,
"& _ objRootDSE.Get(
"defaultNamingContext
"))
This code is similar to the code in Listing 5.1 that is used to bind to Active Directory.
To complete this procedure, you need to determine the lDAPDisplayNames of the attributes you want to write to the user account object. Figure 5.5 shows the General Properties page of the MyerKen user account and the corresponding lDAPDisplayName of each attribute that appears as a label on the page.
Figure 5.5 General Properties Page of the MyerKen User Account Object
General Properties Page of the MyerKen User Account Object
Notice that there is no attribute with an lDAPDisplayName of First name or Last name. Thus the labels on the property pages of an Active Directory object are an unreliable information source for determining lDAPDisplayNames.
There are other ways you can refer to an Active Directory object s attributes in ADSI scripts, but the most consistent approach is by using their lDAPDisplayName. This is also the only way that enables you to write an attribute using the Put method.
To keep this procedure as straightforward as possible, the attributes that can contain more than one value (called multivalued attributes) will not be modified in the script. These are the otherTelephone and url attributes. For information about writing and reading multivalued attributes, see "Administering Multivalued Attributes" later in this chapter.
objUser.Put
"givenName
",
"Ken
"objUser.Put
"initials
",
"E.
"objUser.Put
"sn
",
"Myer
"objUser.Put
"displayName
",
"Myer, Ken
"objUser.Put
"description
",
"HR employee
"objUser.Put
"physicalDeliveryOfficeName
",
"Room 4358
"objUser.Put
"telephoneNumber
",
"(425) 555-0100
"objUser.Put
",
"myerken@fabrikam.com
"objUser.Put
"wWWHomePage
",
"http://www.fabrikam.com
"
objUser.SetInfo
After the script modifies the user account object in Active Directory, you can either review the settings on the General Properties page of the MyerKen user account or add to the ADSI script so that it reads and displays the modifications.
strGivenName = objUser.Get(
"givenName
") strInitials = objUser.Get(
"initials
") strSn = objUser.Get(
"sn
") strDisplayName = objUser.Get(
"displayName
") strPhysicalDeliveryOfficeName = _ objUser.Get(
"physicalDeliveryOfficeName
") strTelephoneNumber = objUser.Get(
"telephoneNumber
") strMail = objUser.Get(
") strWwwHomePage = objUser.Get(
"wWWHomePage
")
Wscript.Echo
"givenName:
"& strGivenName Wscript.Echo
"initials:
"& strInitials Wscript.Echo
"sn:
"& strSn Wscript.Echo
"displayName:
"& strDisplayName Wscript.Echo
"physicalDeliveryOfficeName:
"& _ strPhysicalDeliveryOfficeName Wscript.Echo
"telephoneNumber:
"& strTelephoneNumber Wscript.Echo
"mail:
"& strMail
Send us your feedback | « Previous | Next » |