To illustrate, I'll create a new logon namespace, separate from the domain name, for users in a division of a company. Let's say that you want the users in Division A to be able to log on as userX@divisionA.com, even though that division has an awful legacy domain name—NTSHMINT—that's a holdover from Windows NT days. The first step is to add the DivisionA.com namespace as a UPN suffix to your AD forest. Open the MMC Active Directory Domains and Trusts console, right-click Active Directory Domains and Trusts, and select Properties. At the resulting dialog box, which Figure 3 shows, you can add one or more UPN suffixes. You must keep UPN suffixes short if you want UPNs to match users' pre-Windows 2000 logon names because pre-Win2K names are limited to 20 characters. If your logon names are 8 characters and the at symbol (@) is 1 character, you have only 11 characters for the UPN suffix, including the .com (or .edu or .org) extension. UPN suffixes are case insensitive.
(Note that Win2K supports UPN logons. Currently, Outlook 2000 doesn't support UPN logons, but Microsoft will soon have an update that adds this support. To enable UPN logon for the Exchange 2000 version of OWA, see the instructions in the sidebar "Enabling UPN Logon for OWA," page 3.)
Now, when you add a new user account, you can select the UPN suffix with which you would like the user to log on. Figure 4 shows how you manually select the UPN suffix for a user logon name. If you need to modify many existing user accounts, consider using an LDAP Data Interchange Format (LDIF) file import to replace the domain name with the UPN name in the UPN suffix. For information about how to use the Ldifde utility, see the Microsoft article "Using LDIFDE to Import/Export Directory Objects to the Active Directory" (http://support.microsoft.com/support/kb/articles/q237/6/77.asp).
Alternatively, you can use Microsoft or third-party AD provisioning tools to set the UPN suffix property. Provisioning tools is a fancy name for tools that automate the setup and management of user accounts; some of these tools also track system usage for billing purposes. I'll describe these tools in a future article.
Another option is to use the ADSI Edit utility to select each OU and eliminate UPN suffixes that don't apply to that OU. For more information about ADSI Edit, see Tony Redmond, "Introducing the ADSI Edit Utility," July 2000.
The nice thing about the UPN suffix property, aside from its independence from the underlying domain, is that you can search for it. The value of this searchability will become apparent in my next article, when I'll show you how to set up email addresses for users, but for now, you just need some background information. In AD, the OU is the container that you use to collect common users and groups under one administrative umbrella. You should use as few domains as possible—the OU, rather than the domain, is the administrative and security boundary. Thus, ASPs define OUs for each company that they host under a root OU for the ASP administrators. In fact, the Exchange 2000 and AD provisioning tools define the OU structure I just described. Unfortunately, you can't directly use OU membership to create address lists and set security on the address lists. However, you can use namespace membership for these purposes—for example, you can create an address list for all the logon names that use a given UPN suffix.
I've set up AD by defining a UPN suffix for Division A and associating it with the logon names of the users in that division, but I still need to set up userX@DivisionA.com as a valid email address in Exchange. I'll show you how to do that next time.