Under Script Control
How to give users more control with what they can see and edit in Exchange's Global Address list.
- By Bill Boswell
I manage an Exchange 2003 system. My users would
like to edit some of the information they see in the Global Address List
property pages. I know about the Galmod32 tool that enables users to edit
their own information, but this tool doesn't list many of the fields that
my users want to edit. Also, we use the Employee Number field in Active
Directory. I've added the Employee Number field to the GAL pages but I'm
tired of using the ADSI Editor to add and modify the entry.
What I'm looking for is a GUI tool where non-IT personnel can edit some
of the GAL information and where I can update fields that don't appear
in Active Directory Users and Computers without resorting to ADSIEdit.
Do you know of any tool or solution to this problem?
Help from Bill
Got a Windows or Exchange question or need troubleshooting
help? Or maybe you want a better explanation than provided
in the manuals? Describe your dilemma in an e-mail
to Bill at mailto:email@example.com;
the best questions get answered in this column.
When you send your questions, please include your
full first and last name, location, certifications (if
any) with your message. (If you prefer to remain anonymous,
specify this in your message but submit the requested
information for verification purposes.)
Larry: If the user's update needs were limited to a few
items, you might be able to get by with using the Windows Address Book.
This often overlooked applet comes on every flavor of Windows. You can
search Active Directory similar to the way you do lookups in the GAL.
The difference is, if a user has permission to change an attribute, he
or she can actually put in a new value from the Windows Address Book,
whereas the GAL properties window displays values in read-only form.
As I'm sure you know if you've done a Google search, there are quite
a few vendors who provide tools for accessing and updating Active Directory
information. Some of these tools have special interfaces that are relatively
simple to manage for users or department gurus. You might want to take
a look at products such as Directory and Resource administrator from NetIQ
and Hyena from SystemTools www.systemtools.com/hyena.
(Send other suggestions to firstname.lastname@example.org).
But ... I took this question as an opportunity to demonstrate how a
little work with scripts can help to resolve these kinds of issues. Not
only does using a script avoid the cost of a third-party product, you
gain flexibility because you can include attributes that are not displayed
in ADUC or third-party interfaces and you can incorporate functionality
that the packaged solution might not have.
Just as an aside, the inability to access all User and Computer fields
in ADUC is a pet peeve. Microsoft should include a Custom tab in the Properties
pages for User and Computer objects in ADUC and permit an administrator
to select any attribute to include in this tab. Exchange System Manager
has this functionality using Details Templates. That's how Larry added
the Employee ID to the GAL properties. It shouldn't be that hard to add
the same functionality to ADUC.
Anyway, back to the subject. I put together a sample Web page containing
an ASP script that displays User attributes from Active Directory that
you might want to let end users update. They won't actually be able to
do an update until you give them Write access to the properties (more
on that in a second). The script also gives an administrator the option
of entering a user name and updating that user's information. The script
name is UpdateUsers.asp, which you can download by clicking here;
the script includes documentation. As usual, don't run this script in
a production environment without thorough testing.
Figure 1 shows you what the page looks like. Users would not see the
search field at the top of the page; they would only see their own values.
(Click image to view larger version.)
Assigning Write Permissions to Users
Whether you use this script or the Windows Address Book or a third-party
product, if you want users to change Active Directory attributes, you
have to give them permission to do so. This involves using the Delegation
of Control Wizard in Active Directory Users and Computers. Try this on
a test OU first:
- Right-click the OU in ADUC and select Delegate Control from the flyout
menu. This launches the wizard.
- In the Users and Groups window, either type SELF or select SELF from
the browse list. This is a placeholder that gets instantiated with the
SID of the logged-on user. By delegating permissions to SELF, you're
giving permission to update properties only on a user's personal User
- In Tasks to Delegate, select the Create a Custom Task radio button.
- In Active Directory Object Type, select the Only the Following Objects
radio button and check User Objects.
- In the Permissions window, leave the General option checked, scroll
down the list, and check Read and Write Personal Information. This is
called a "Property Set." It's essentially a shorthand way
of assigning access to a list of properties rather than picking them
one at a time from the list. If you're interested in the properties
included in the Personal property set, search the Windows Server 2003
online help for "Property Set."
Once you complete the wizard, log on as an average user who resides in
the test OU and use the Windows Address Book to find the user. If you
open the Properties window, you'll find that several of the fields now
permit you to make changes. The remainder stay dimmed, indicating that
Running the Script
Because the demo script comes inside an ASP page, you'll need to
run it on a Web server that has IIS 5 (Windows 2000 or XP) or IIS 6 (Windows
- Create a folder on the server called UserUpdates (or some other name
that you like) and place the UpdateUsers.asp file in folder.
- Use the IIS Manager console to create a virtual folder called UserUpdates
and point it at the new folder.
- Set the folder properties to allow ASP scripts to run.
- In the Properties window of the new virtual folder in IIS Manager,
set the Security settings to allow only Windows Integrated authentication.
Uncheck Anonymous and Basic. This is important. Without this
step, the script won't run. It uses thread impersonation to bind to
Note: When connecting to the Web server in Internet
Explorer, use the short name of the server. If you use the fully qualified
DNS name (such as server.company.com) then you will get prompted for
credentials then the script will fail to run. This is because IE assumes
that any host name with a dot in it lies in the Internet zone and
will not allow Windows Integrated authentication.
At this point, you can access the page from the console of the IIS server.
If you want to access the page from a browser on another machine, you'll
need to configure the server in Active Directory as "Trusted for
Delegation." Without delegation, you'll get a run-time error because
the script uses impersonation to bind to Active Directory. There are other
workarounds, but this is precisely the reason delegation was included
in Windows, so you might as well use the feature.
Note: Windows Server 2003 has the ability to constrain
Kerberos delegation to a specific service. If this sounds like something
you as readers might want to do, let me know and I'll cover it in a
If you can't get the script to run, contact me at email@example.com
and I'll be happy to help you figure out the problem.
Contributing Editor Bill Boswell, MCSE, is the principal of Bill Boswell Consulting, Inc. He's the author of Inside Windows Server 2003 and Learning Exchange Server 2003 both from Addison Wesley. Bill is also Redmond magazine's "Windows Insider" columnist and a speaker at MCP Magazine's TechMentor Conferences.