by David Mosier
This chapter provides an overview of directories and covers the administration of the Exchange directory. It quickly covers the concepts of International Standards Organization (ISO) X.500 Directory Services, the foundation of the Exchange directory. Next, the chapter explains the major objects in the Exchange directory and how to administer the security options. It also explains the tools for importing and exporting information with the Exchange directory. This chapter provides an understanding of what the Exchange directory is and how to manage it. You should also get an idea of how the Exchange directory relates to the X.500 directory standard.
A directory is a hierarchical database of descriptive information organized for fast and efficient retrieval. Each entry in the directory can have several pieces of information, or attributes, associated with it. One of the best examples of a directory is the residential telephone book. Despite the fact that there can be tens of thousands of entries in a two- or three-inch telephone book, given a person's name, you can generally find their address and telephone number in less than a minute.
A directory is similar to a relational database but there are some significant differences. Unlike most relational database systems, a directory is read much more often than it is updated. Because the information is more static than a relational database, a directory can use a simple replication process to distribute entries across multiple systems rather than the more complex two or three phase commit protocols employed by distributed relational databases. Also, whereas a relational database is organized around tables of interrelated information, a directory is organized around a hierarchy of objects, each with attributes that describe their associated entry.
A computer-based directory service provides a structure for information storage as well as the methods for the secure and reliable entry and retrieval of information. A directory service that is distributed across multiple computers must also provide a method for sharing or replicating the entries in each computer with all the other computers participating in the directory service.
Exchange uses a distributed, computer-based directory service to store entries about system configuration and about each user. Each entry is referred to as a directory object. Each group of objects, for example mailboxes, distribution lists, or link monitors, is referred to as an object class. Object classes have specific attributes or properties. Some attributes are required, such as the directory name for a mailbox object, while others such as middle initial are optional. The object class is responsible for knowing what attributes it has, which ones are optional, and which ones are required. Object classes enable the Exchange directory to store virtually any kind of information. Exchange only needs to keep track of the object class of a directory entry, the object class keeps track of the structure of the information in the entry.
The X.500 standard is actually a family of interrelated standards. Each section of the family is a standards document in its own right. In addition, X.500 references other standards for such things as data formatting and remote processing. Following is a list of the standards documents that together make up what is commonly referred to as the X.500 standard.
The X.200 family of standards provides high-level functions for communication including data format, remote operations, and session setup. These functions provide a basic framework over which the directory services operate.
Recommendation X.500 and X.501 provide the logical structure of the directory and the models for administration and control. Combined with recommendations X.520 and X.521, which define basic object classes and their attribute type, these documents define both the Directory Information Base (DIB) and the Directory Information Tree (DIT). The rest of the X.500 recommendations specify how the various elements of a directory interact with one another.
In the development of the Exchange 4.0 directory, Microsoft closely followed X.500, X.501, X.520, and X.521. The rest of the X.500 family of standards were either not implemented or not fully implemented. Therefore, Exchange 4.0 directory is based on X.500 but is not fully X.500 compliant. Microsoft has committed support for X.518, X.519, and X.525 in the next release of Exchange, enabling interaction with other X.500 directories.
The X.500 model describes a directory service distributed across one or more servers. Each of the servers participating in the directory service are referred to as directory service agents (DSA). They store the directory information base (DIB) and present it to directory users as the directory information tree (DIT). Directory users, either individuals or programs, access the directory through a directory user agent (DUA). The DUA accesses the DSA through a protocol called directory access protocol (DAP). Communication between the distributed DSA systems is accomplished through the directory system protocol (DSP), the directory operational binding management protocol (DOP), and the directory information shadowing protocol (DISP). DSP enables one DSA to look up an entry in another DSA, usually on behalf of a client DUA. DSA systems use DOP to establish a working relationship and security context. A DSA uses DISP to replicate all or part of their entries to another DSA. Figure 19.1 illustrates the X.500 model and where each protocol is used.
Figure 19.1. The X.500 directory and protocols.
The X.500 standard uses three models or views to outline the directory: the directory user information model, the directory operational and administrative information model, and the directory service agent information model. The directory user information model identifies how entries are named and guarantees each has a unique name. The directory operational and administrative information model identifies how the directory is administered. Administration covers the type of entries that can be stored in a given part of the directory and who can access them. The two previous models look at the directory as a single entity. The directory service agent information model defines how the directory information is distributed and accessed across multiple systems.
The information defined in all three models is referred to collectively as the directory information base (DIB). The DIB is a series of entries where each entry is an object with associated attributes. The entries are related to one another hierarchically. The hierarchy, or logical structure of the DIB is referred to as the directory information tree (DIT). Thus the DIB is the raw collection of information and the DIT is the structured view of the information. For users and administrators alike, it is usually the DIT that is of interest. Figure 19.2 demonstrates the difference between the DIB view of information and the DIT view.
Figure 19.2. Comparison of DIB and DIT.
Any significant directory has a schema. A schema is the set of rules that ensures order in the directory. It determines what type of objects can be stored in the directory, where they can be stored, what attributes the objects can have, and what values the attributes can hold. The schema is the map that enables users to make sense of the information in the directory.
Every object in the directory must have a name. The X.500 standard refers to two types of names: the distinguished name (DN) and the relative distinguished name (RDN). The RDN identifies an object within a collection of objects with the same parent. Thus, two objects can have the same RDN as long as they do not have the same parent. As an example, you can have two towns named Columbia as long as one is in the state of Maryland and the other is in the state of South Carolina.
The DN is a concatenation of the RDN of each ancestor, starting at the root of the directory and proceeding down through all the parent directories to the RDN of the specific object. The UNIX file system is a good example of this. Assume there is a root directory called PlantLife with a subdirectory called Trees, and in the Trees directory is a file named Oak. From within the Trees subdirectory, the file Oak can be referenced simply as Oak. This corresponds to the RDN. However, the full path name of the file Oak is /PlantLife/Trees/Oak. This corresponds to the DN. Figure 19.3 shows how the RDN relates to the DN and how the DN relates to the DIT.
Figure 19.3. Naming conventions in X.500
X.500 security is based on authentication and access control lists. The standard defines two types of authentication: simple authentication and strong authentication.
Simple authentication is essentially the exchange of an ID/password combination. The password can be sent as clear text, encrypted text, or a token derived from the password can be sent instead of the actual password. Simple authentication can be quite effective but it can break down in a distributed directory. The primary drawback to simple authentication is the requirement for a secure link outside the directory system for each messaging system or user to establish and update ID/password combinations. As directories and connections grow, administration becomes unwieldy.
Strong authentication involves using public and private key pairs to encrypt messages and to generate digital signatures. Strong authentication has two main advantages over simple authentication. First, it is unaffected if the transmission channel crosses an unsecured link such as the Internet. Secondly, the public keys can be registered with a secure system that is trusted by all participants in the directory or even by other directories. By establishing a secure link to the mutually trusted system and maintaining the list of public keys on that system, secure transmissions can flow between any systems without any previously established relationship.
The ISO X.500 committee is responsible for the directory services standards. They designed a tree-structured directory capable of holding large amounts of information. The standard enables for distributing the information as well as administration over many computer systems. The entire directory, whether it exists on a single system or is distributed over multiple systems, is referred to as the directory information base (DIB). The logical structure or view of the DIB is referred to as the directory information tree (DIT). The X.500 documents specify in detail the ordering or schema of the DIT, as well as the directory access protocol (DAP) used to access the information. DAP is complex and can be difficult to implement. To address these limitations the lightweight directory access protocol (LDAP) has been developed by the Internet community and documented in 1992 by Internet RFC-1487. LDAP has since been updated by RFC-1777.
It should be noted that LDAP is an Internet specification and is not OSI compliant. As such, it is not formally part of the X.500 standard. However, whether the ISO officially recognizes it or not, the use of LDAP within the Internet, combined with the explosive growth of the Internet itself has made LDAP a part of the X.500 landscape.
The Exchange 4.0 DIB follows the 1988 version of the X.500 directory schema. Therefore, in the definition of object classes and attributes as well as the syntax of data storage and object names, the Exchange directory is X.500-1988 compliant. Figure 19.4 shows an example of an X.500-style tree structure used by Exchange.
Figure 19.4. A directory tree structure.
In addition, Exchange 4.0 at least partially implements the DSP protocol for DSA to DSA communication. However, rather than breaking the directory into pieces and distributing it across the various site servers, Exchange 4.0 replicates the entire directory to all servers in the organization. Although replicating the entire directory throughout the organization is not the norm in X.500 environments, it is not a violation of the X.500 standard and probably has the effect of reducing client response times. The Exchange 4.0 partial implementation of DSP does not enable interaction or replication with other X.500-compliant directories.
The only other significant piece of the X.500 1988 standard that Exchange 4.0 does not at least partially implement is the DAP protocol specified in X.519 protocol specifications. In addition, Exchange 4.0 does not implement the de-facto Internet standard LDAP, which is documented in Internet RFC-1777. These protocols were probably left out to focus development effort on other features.
Microsoft addressed the issue of client access protocols by announcing Directory Server, a service for Windows NT Server. Directory Server is scheduled for release as part of Cairo in 1997, although a preview version is available for NT Server 4.0. Currently, support for both DAP and LDAP are planned. However, because DAP operates over complex OSI protocols that are not commonly installed on desktop computers and LDAP operates over TCP/IP, LDAP support will probably receive more development effort than DAP.
In 1997, with Cairo, Exchange 5.0, and Directory Server released, several pieces of the NT registry will move to the directory, including the accounts database and shared resource definition. In addition, this new directory will contain objects unrelated to NT or Exchange, such as human resource records, enabling the directory to become the corporate information repository.
Thus Exchange 4.0 is in a position where the directory itself is X.500 compliant, but no X.500 client applications can access it. In place of DAP and LDAP, Exchange 4.0 uses an interface called directory application protocol interface (DAPI) to access the directory. It is possible to access the directory using the mail application protocol interface (MAPI), but the process can involve more coding and result in slower performance.
The next version of Exchange is expected to implement more of the X.500 directory standard. In comparison to Figure 19.1, Figure 19.5 illustrates the Exchange directory and its protocols. The cc:Mail Connector did not ship with the initial release of Exchange 4.0 but is expected out before the end of 1996 with support for message transfer, attachments, Rich Text, and ADE directory updates. Not shown in the figure are the growing number of connectors from companies such as LinkAge for other mail systems like PROFS and Lotus Notes.
Figure 19.5. The Exchange directory and protocols.
If you want to view the actual X.500 directory schema without interpretation, start the Exchange Administrator in raw mode. Go to a command prompt and type ADMIN /R. You can then select almost any of the objects in the Administrator interface and press Shift+Enter to view their attributes. If you want to go all natural, select View and click Raw Directory. A new container called Schema shows up under each site. The Schema container has an alphabetic listing of every object class in the site.
Be extremely careful when you use ADMIN.EXE in raw mode. Do not change anything without direction from support. The destructive force of ADMIN.EXE /R is roughly equivalent to that of REGEDT32.EXE times the number of servers in your Exchange organization.
Why does Exchange create a complex directory structure to store configuration and user information when NT already has the registry? The Exchange directory does not replace the NT registry. It is in addition to the NT registry and provides Exchange with scaleability and adherence to open standards. The NT registry is intended for use primarily by the local NT system to store its configuration. It does not scale well when storing large amounts of data and its interface is unique to NT. In fact, the NT registry's method of storing quickly accessible user information is the primary reason for the limitation of user accounts in a single domain. When NT adopts an X.500 directory for user account information, the number of users permitted in a single domain will no doubt be much higher.
Exchange uses both the NT registry and a directory to store information. Configuration information required by each Exchange server, such as file locations, site name, and protocol parameters is still stored in that server's NT registry. But information useful throughout the organization such as mailboxes, distribution lists, public folder definitions, and link monitors is stored in the Exchange directory where it can be quickly and easily accessed from anywhere in the organization by anyone with the proper authorization. Figure 19.6 illustrates how various information is stored in the NT registry and the Exchange directory.
Figure 19.6. Configuration and directory storage in NT and Exchange.
The Exchange DIT represents an organization's users and configuration. Much of the configuration information about Exchange itself is stored in the directory. Also, every detail about every recipient is in the directory. That includes recipients native to the Exchange organization and site as well as remote recipients such as SNADS or foreign X.400 users. This represents hundreds of different object classes and attributes. However, for the purposes of administering the Exchange directory, the focus is on the following three object classes: mailbox, custom recipient, and distribution list.
The Mailbox object class name is mailbox and it stores attributes for users with accounts in the Exchange organization. These users are sometimes referred to as native Exchange users. Table 19.1 lists all of the attributes associated with the mailbox object class. Only Object-Class and Common Name are required to create a mailbox object and import information into it. However, to create a functional mailbox object, the imported information should include Object-Class, First Name, Last Name, Primary NT Account, Home Server, and Directory Name. All other information is derived. Of course if the defaults do not fulfill your organization's requirements then other attributes can be included.
Accept messages from
|
Accept messages from DL
|
Address
|
Admin Note
|
Admin-Description
|
Admin-Display-Name
|
Alias Name
|
Enable rich text
|
Alt-Recipient
|
Alt-Recipient-BL
|
Alternate Recipient
|
Ancestor-ID
|
Assistant
|
Assistant phone number
|
Assistant-Name
|
Assoc-Remote-DXA
|
Auth-Orig
|
Auth-Orig-BL
|
AutoReply
|
AutoReply-Message
|
AutoReply-Subject
|
Business phone number 2
|
Can-Create-PF-BL
|
Can-Create-PF-DL-BL
|
Can-Not-Create-PF-BL
|
Can-Not-Create-PF-DL-BL
|
City
|
Comment
|
Common-Name
|
Company
|
Country
|
Custom Attribute 1-10
|
Deliv-Cont-Length
|
Deliv-EITs
|
Deliv-Ext-Cont-Types
|
Deliver to both
|
Deliver-And-Redirect
|
Deliverable Information Types
|
Department
|
Description
|
Direct Reports
|
Directory Name
|
Display-Name
|
Display-Name-Printable
|
DL-Mem-Reject-Perms
|
DL-Mem-Reject-Perms-BL
|
DL-Mem-Submit-Perms
|
DL-Mem-Submit-Perms-BL
|
DSA Signature
|
E-mail Addresses
|
Expiration-Time
|
Extension Name
|
Extension-Attribute-1-10
|
Extension-Data
|
Extension-Name-Inherited
|
Fax number
|
First Name
|
Given-Name
|
Heuristics
|
Hide-From-AB
|
Hide-From-Address-Book
|
Home phone number
|
Home phone number 2
|
Home-MDB
|
Home-MDB-BL
|
Home-MTA
|
Imported-From
|
Incoming message size limit
|
Initials
|
Instance-Type
|
International-ISDN-Number
|
Is-Deleted
|
Is-Member-Of-DL
|
Last name
|
Locality-Name
|
Mail-nickname
|
Maintain-AutoReply-History
|
Manager
|
MAPI-Recipient
|
Master-DSA
|
Member of
|
Mobile number
|
Notes
|
NT-Security-Descriptor
|
Obj-Dist-Name
|
Object-Class
|
Object-Version
|
Office
|
Outgoing message size limit
|
Owner-BL
|
Pager number
|
Period-Rep-Sync-Times
|
Period-Repl-Stagger
|
Phone Number
|
Physical-Delivery-Office-Name
|
Postal Code
|
Proxy-Addresses
|
Public-Delegates
|
Public-Delegates-BL
|
Reject messages from
|
Reject messages from DL
|
Replication-Sensitivity
|
Reports
|
Reps-From
|
Reps-To
|
Reps-To-Ext
|
Secondary-Proxy-Addresses
|
Security-Protocol
|
Simple display name
|
State
|
State-Or-Province-Name
|
Sub-Refs
|
Submission-Cont-Length
|
Supporting-Stack-BL
|
Surname
|
Telephone-Assistant
|
Telephone-Fax
|
Telephone-Home
|
Telephone-Home 2
|
Telephone-Mobile
|
Telephone-Number
|
Telephone-Office1
|
Telephone-Office2
|
Telephone-Pager
|
Teletex-Terminal-Identifier
|
Telex-Number
|
Text-Country
|
Title
|
Trust level
|
Unauth-Orig
|
Unauth-Orig-BL
|
User-Cert
|
USN-Changed
|
USN-Created
|
USN-DSA-Last-Obj-Removed
|
USN-Last-Obj-Removed
|
USN-Source
|
When-Changed
|
When-Created
|
X121-Address
|
X500-Access -Control-List
|
Object-Class |
There are 140 different attributes that describe a mailbox object. Only 13 of the attributes are exported using the defaults for the Tools | Export Directories menu option in the Exchange Administrator program. To export additional attributes, include their object class names in the header line of the export file. All of the directory objects are documented in the Exchange section of the BackOffice SDK 2.0 which is available to MSDN level 3 or Enterprise level subscribers. There is also a utility, HEADERS.EXE, included in the Exchange Server Technical Resource Guide (Microsoft Part No. 098-64705) that can create a header line with any or all of the mailbox object attributes. An explanation of the 13 default attributes exported by the Exchange Administrator program can be found in Table 19.2.
Attribute Name
|
Multivalued?
|
Purpose
|
First Name
|
No
|
First name of user; used to create default Display Name, Alias, and Directory Name
|
Last name
|
No
|
Last name of user; used to create default Display Name, Alias, and Directory Name
|
Display Name
|
No
|
Name that appears in the address book (for addressing messages, creating distribution lists, etc.)
|
Alias Name
|
No
|
Mail nickname; a short name that can be used to address messages. Also used to generate X.400, SMTP, and MS mail addresses (i.e. alias@site.organzation.com)
|
Directory Name
|
No
|
Internal name used by the directory service to reference the user; cannot be changed
|
Primary Windows NT Account
|
No
|
NT domain\account used to for security purposes and to authenticate the user
|
Home-Server
|
No
|
The server on which the user's mailbox resides. The server that provides the user with information store and directory store services
|
E-mail address
|
No
|
Not used for mailbox object; Used by remote recipient objects (custom recipient) to hold their target-address
|
E-mail Addresses
|
Yes
|
The user's reply-to addresses for any foreign mail systems such as X.400, SMTP, and MS Mail.
|
Members
|
Yes
|
A list of all the distribution lists to which the user belongs
|
Obj-Container
|
No
|
The parent container to which the user belongs; by default it is Site\Recipients
|
Hide from AB
|
No
|
Indicates whether the user's name should be hidden from the address book |
The Hide from AB attribute can be used during migration to enable users to moved from the old mail system to Exchange in manageable groups. Create all the Exchange accounts for a given site or organization, hiding them from the address book. Then when groups or individuals begin to use their Exchange account, unhide them using the Exchange Administrator programfirst click View | Hidden Recipients and then unmark the Hide from Address Book attribute on the Advanced tab of the Site\Recipients\user-name property page.
The custom recipient object class name is remote. Remote users in Exchange are really just place holders. The place holders permit users on foreign mail systems to appear in the Exchange address book. This enables Exchange users to conveniently address mail to the foreign users and include them in distribution lists. It also enables Exchange administrators to include information about the foreign user such as telephone number, FAX number, and company that can make the Exchange directory more useful for native Exchange users.
The remote object class uses most of the same attributes as the mailbox object class and only adds one additional attribute, Target-Address. The target-address attribute holds the address of the recipient in their native mail system. For example, if a FAX gateway is installed in your site the target-address attribute for a custom recipient available through the FAX gateway might be FAX:918005551212.
The distribution list object class name is dl. The dl object class reuses most of the attributes from the mailbox object. However, several additional attributes are required to handle the unique functionality of distribution lists and are defined in Table 19.3.
Attribute Name |
Multivalued? |
Purpose |
DL-Member-Rule
|
Yes
|
Determines if distribution lists can be members of this distribution list. This is a hidden attribute. By default all distribution list permit distribution lists as members.
|
Hide-DL-Membership
|
No
|
Determines if the membership of this distribution list is hidden from the address book. The default is false.
|
Member
|
Yes
|
Lists the members of the distribution list.
|
Member-of
|
Yes
|
A backwards link to any distribution lists that this list is a member of.
|
OOF-Reply-to-Originator
|
No
|
Sends mail message back to originator if a member of the distribution list is out of the office.
|
Owner
|
No
|
The full distinguished name (DN) of the owner of the distribution list.
|
Report-to-Originator
|
No
|
Determines if the message originator receives a report when a message exceeds the size limit for the distribution list.
|
Report-to-Owner
|
No
|
Determines if the distribution list owner receives a report when a message exceeds the size limit for the distribution list. |
The Hide-DL-Membership attribute can provide a false sense of security. By setting it to true the membership list doesn't appear in the address book, but a user can quickly and easily determine the list membership by sending a message to the distribution list with return receipt turned on. If you use this attribute you should also control who is permitted to send to the distribution list.
The directory import tool reads information from a text file and updates the Exchange directory based on the header and contents of the import file. Although the DAPI import function, BImport, is capable of importing any class of object into any part of the Exchange directory, the Tools\Import function of the Exchange Administrator can only import objects into or below the recipient container. It can import mailbox objects, custom recipient objects, distribution list objects, and container objects. You can run the import utility from within the Exchange Administrator by using menu option Tools\Import, or from the command line.
The import function not only saves hours at installation time, it improves accuracy. It can also make directory maintenance significantly easier and faster. With the addition of the Mode field in the import file header, the import function is able to update or delete existing objects. The following example shows an import file that can change the membership of an existing distribution list. A distribution list that has just been created is being populated with three members.
Obj-Class, Mode, Directory Name, Members dl, MODIFY, Managers, Recipients/cn=Kim%Recipients/cn=Megan%Recipients/cn=Morticia
When the previous file is imported, Exchange changes the value of the Member attribute for the distribution list object, Managers, and it also changes the Is-member-of-DL attribute for the mailbox objects of Kim, Megan, and Morticia to reflect their membership in the Managers distribution list. As you can see, the import function can be quite powerful. Although this example is trivial, a file with the same basic header can be used with 500 users and 30 different distribution lists.
Figure 19.7 shows the main screen for Tools | Import. The Windows NT domain list box and MS Exchange server list box control where the Exchange mailbox is created and where the mailbox gets its security context. The domain listed in the Windows NT domain list box is where any NT account is created or deleted. This is especially useful in organizations using the master domain model or the multiple master domain model for their NT domain architecture. The system listed in the MS Exchange server list box is the home server for any mailboxes or custom recipients created. It is also the only server the import tool looks in for mailboxes to be modified or deleted.
Figure 19.7. Exchange Administrator import utility.
If the Exchange service account for the domain where the import utility is running does not have administrative privileges in the target domain, then NT account creation or deletion fails.
Depending on the value of the radio buttons Use selected container if not specified in the file and Always use selected container, the value in container box serves different purposes. If the Use selected container if not specified in the file option is selected then the container is the default for operations where no container is specified. If the Always use selected container option is specified then the container is where all adds, updates, and deletes are performed, no matter what the import file specifies.
The easiest way to move a large number of users between recipient containers is to export mailboxes from one container, delete them, and then import them into another container. But don't forget these three important steps. Move each users mailbox messages that are currently stored online to their .PST file. Export all of the mailbox attributes, not just defaults for export. See Table 19.1 for the list of possible attributes. Delete the existing profile on the Exchange client and create a new one. The distinguished name (DN) used by the existing profile points to the old container.
The Recipient Template button sets the mailbox object to be used as the source of default information. For example, you can create templates for different departments that include information such as company name, address, manager, and FAX number. Then import users grouped by their department, and the template accounts populate the department-specific information.
The account creation options enable the import utility to perform account maintenance on the NT domain specified in the Windows NT domain list box. The settings in this group directly cause accounts to be created or deleted. These settings tell the import utility what to do regarding NT accounts in the event that there are entries in the import file instructing the import utility to either create or delete a mailbox object. When an NT account is created or searched for in the target domain, the default for the NT account name is the value of the common name attribute, unless a value is given for the primary Windows NT account attribute.
In the Exchange Directory, common name and directory name are two names for the same attribute. They make up the last part of an object's X.500 distinguished name (DN).
If Create Windows NT Account is selected, the option Generate random password becomes undimmed. If this box is selected then a random password is generated that is at least four characters, more if required by the account policies of the target NT domain. If this option is not selected then the password is set to the value of the common name attribute. If the common name attribute is not long enough to fulfill the requirements of the account policies of the target domain, the password is left-justified and the spaces are filled with lower case "x". Whether a random password is generated or not, the password is written to a file with the same name as the import file and the extension of PSW. If an NT account already exists in the target NT domain, no changes are made to that NT account.
If an NT account is created, a password is always created for the new account. However, the option to require the user to change their password at the next login is not selected.
The logging level during the import function can be set to three levels. Setting logging level to None enables only two entries into the event log: begin import and end import. No other information is recorded. The Low logging level permits errors to be logged as well as start and finish messages. The High logging level logs the same information as the Low logging level but in addition logs warnings and informational messages. Informational messages are usually letting you know that the error file or export already existed and had to be renamed. Warnings and errors are written to the application log of the NT event log.
The entries that cause an error are written to a file with the extension of .ERR and the same name as the import file. So an import file named Marketing.CSV that generated an error has an associated error file named Marketing.ERR. This feature makes it fast and easy to determine which entries caused errors, to fix the entry, and to import just the entries that were not previously imported.
Care should be taken when setting the value of the Multi-valued properties radio buttons. Multi-valued properties are attributes that can have more than one value. SMTP addresses are an example. One mailbox object can have more than one SMTP address. In some cases, as when you are trying to replace the existing SMTP address, the Multi-valued properties radio button should be set to Overwrite. In other cases, as when you want to add an additional SMTP address to the existing address, the Multi-valued properties radio button should be set to Append. If you don't know which value to use, leave it on Append.
So far this chapter has focused on the graphical interface to the import function. However, the import function can also be called as a command line utility. By default the ADMIN.EXE program is in the \exchsrvr\bin directory. The command line parameters are defined in Table 19.4 and the syntax for the command-line version is as follows.
admin /i <import file> /d <directory server name> /n /o <options file>
Parameters |
Description |
/i
|
Tells ADMIN.EXE to run in command line batch import mode. This parameter in required
|
<import file>
|
The file containing the directory information to be imported. This parameter is required
|
/d <directory server>
|
The name of the server who's directory is to be updated. This is the same as the MS Exchange server list box.
|
/n
|
Prevents the progress bar from displaying during the import process.
|
/o <options file>
|
The file containing the options that control the import process. Most of the options are the same as the graphical mode. |
The import options file takes the place of the user interface of the Exchange Administrator Tools | Import menu option. Most of the items in the import file have equivalent options in the graphical import utility. The DirectoryService is the same as the MS Exchange server list box in the graphical version. OverwriteProperties is the same as Multi-valued properties.
ApplyNTSecurity, RawMode, and CodePage are all unique to the command line version of the import utility. Applying NT security means matching the mailbox with an existing NT account. CodePage controls the character set used, -1 equals Unicode, 0 equals the active code page, and any other number refers to other code pages. The InformationLevel option accepts None for no logging, Minimal for logging of errors only, and High for logging of errors and warnings. Table 19.5 describes all the items in the import options file and provides their defaults.
Item |
Default |
Description |
DirectoryService
|
N/A
|
The computer name of the directory server into which the utility imports the entries
|
BasePoint
|
The local site
|
The X.500 DN of the target site for the import
|
Container
|
Recipients
|
The RDN or common name of the target for the import
|
InformationLevel
|
Minimal
|
The amount of logging that is performed during the import
|
RecipientTemplate
|
None
|
The X.500 DN of a mailbox object to be used for the defaults for any undefined attributes
|
NTDomain
|
Logon domain
|
The NT domain where accounts are searched for, created, or deleted
|
OverwriteProperties
|
No
|
Determines whether attributes capable of holding multiple values, such as SMTP address, are overwritten or appended
|
CreateNTAccounts
|
No
|
Determines whether NT accounts that do not exist in the domain specified in the NTDomain option are created in UPDATE or CREATE mode, or an error generated
|
DeleteNTAccounts
|
No
|
Determines whether NT accounts that do exist in the domain specified in the NTDomain option are deleted in DELETE mode
|
ApplyNTSecurity
|
Yes
|
Determines whether NT accounts that do exist in the domain specified in the NTDomain option are matched to the target mailbox in UPDATE or CREATE mode
|
GeneratePassword
|
No
|
Determines whether a random password is generated, or if the value of the common name attribute is used for the password of NT accounts that are created
|
RawMode
|
No
|
No attributes are inherited, constructed, etc. Aliases for attribute and class names is not recognized
|
CodePage
|
Current
|
The codepage that the import file uses |
Most of the alternate values for items in Table 19.5 are obvious. The InformationLevel and CodePage are discussed here. The InformationLevel also accepts None for no logging and High to log all warnings and errors. CodePage accepts -1 for Unicode, 0 for the current ANSI code page, or any other code page number.
RawMode should only be used by individuals with much experience in the Exchange directory, and even then requires good typing skills. Essentially raw mode turns off the automatic generation of attribute values such as Display Name, which by default is First Name Last Name. This enables the import utility to directly enter values for any attribute. However, there is no error checking in raw mode. If the import file instructs the import utility to make modifications that harm the directory, the import utility makes the modifications anyway.
The format of the import file is for the most part, self-documenting. The first line of the file contains a header that defines the format of the lines that follow. There is no limit imposed by the import utility on the number of entries in the header or the number of data lines following the header. The contents of the header are object class names from the Exchange directory schema. The import utility reads either ANSI text or Unicode and automatically senses which format is used. Table 19.6 shows the types of objects that can be imported with the import utility and their required fields. The separators for the import file and the defaults are shown in Table 19.7. The command line import utility does not enable the default separators to be modified. However, the graphical version does enable the defaults to be modified.
Object Class |
Description |
Required Fields |
mailbox
|
Native Exchange user
|
Directory Name, Home Server
|
dl
|
Distribution list
|
Directory Name
|
remote
|
Custom recipient
|
Directory Name, Target Address
|
container
|
Recipients container
|
Directory Name |
Character |
Separator Type |
Default |
, (comma)
|
Field separator
|
Yes
|
(tab)
|
Field separator
|
No
|
(space)
|
Field separator
|
No
|
% (percent)
|
Value separator
|
Yes
|
! (exclamation)
|
Value separator
|
No
|
# (pound)
|
Value separator
|
No
|
$ (dollar)
|
Value separator
|
No
|
& (ampersand)
|
Value separator
|
No
|
* (asterisk)
|
Value separator
|
No
|
@ (at symbol)
|
Value separator
|
No
|
^ (control symbol)
|
Value separator
|
No
|
" (double quote)
|
Encloses text with imbedded spaces
|
Yes
|
' (single quote)
|
Encloses text with imbedded spaces
|
No |
Although the import utility does not enforce any limits on the size of the header or the number of data lines, the program or utility that you use to manage the import file might. For example, Excel 7.0 can handle spread sheets of 16,384 rows by 256 columns, and an individual column can be 255 characters wide. These numbers are impressive for a spread sheet, but even a medium-sized distribution list can easily exceed the 255-character limit for column width.
There are two required fields in every import file, Obj-Class and Common Name. Obj-Class must be the first field in the header. It tells the import utility what class of object must be created, deleted, or modified. Given the object class, the import utility knows what attributes are required for the imported entry and what attributes are optional. Common Name identifies which unique object in the Exchange directory is the target for the import operation. The Common Name is actually only a relative distinguished name (RDN), but when combined with the distinguished name (DN) of the object's container, it becomes the DN for the target object. The DN of the parent container is specified in the setup screen for the graphical import utility (i.e. MS Exchange Server\Container) and in the options file of the command line import utility (i.e. BasePoint\Container).
The Mode field enables the import utility to be used for more than just initial installation of Exchange and importing new entries from time to time. The Mode field is not a required field. If the Mode field is present then it must be the second field in the header. If it is not present, the import utility assumes the Mode is update. The legal values for Mode are create, delete, modify, and update. The Mode of create tells the import utility to create a new object. If the object already exists then an error is generated. The Mode of delete tells the import utility to delete an existing object. If the object does not exist then an error is generated. The Mode of modify tells the import utility to look for an existing object to change. If the object does not exist then an error is generated. The update Mode first attempts to locate an existing object and if one is not found, an object is created.
If you do not know the object class names to use for the headers of the import file you are creating, use the Export function. Go to the Exchange Administrator menu item Tools\Export Directory. Click on Export File. Type in the name of a file that does not exist and click the OK button. When prompted to create the file answer yes. Now select whichever of the Export objects the selected container has least (to reduce processing time). When you click the Export button, the file is created and populated. Now open the file in Notepad. Delete all the entries after the first line. The first line of the file is the default headers required for an import file.
Listings 19.1 and 19.2 are two examples of the use of the Mode field. The first example import file creates a distribution list and populates it with two members. The second example import file modifies an existing list called Mail Witches by adding MarieD to the list of members.
Listing 19.1. Import file: example one.
Obj-Class, Mode, Directory Name, Members dl, CREATE, "East Coast", Recipients/cn=Marilyn%Recipients/cn=Georgia
Listing 19.2. Import file: example two.
Obj-Class, Mode, Directory Name, Members, Home-Server, Address dl, MODIFY, "Mail Witches", Recipients/cn=MarieD,, mailbox, UPDATE, MarieD,,ARLF2,"1320 Blue House Road"
In Listing 19.1, the following must be true or errors are logged in the event log:
In Listing 19.2, the following should be noted:
The import utility can import entries into the recipients container or any of its sub-containers. It cannot import entries into any other containers. This means that you can import containers, mailboxes, custom recipients, and distribution lists. You cannot import public folder schema or configuration information. The BImport function on which the import utility is based can import into any container. If you require an import utility with more flexibility, you can modify the sample application in the BackOffice SDK. But remember, with the increased flexibility comes increased ability to do harm to the directory.
Directory export is essentially the reverse of the import process. Although, the export process is by its nature less complicated than the import process. The export process need only dump out data that is already known and previously sorted into meaningful information. The export process has no interaction with NT security and little if any interaction with any other DSA than the one providing the entries being exported.
As Figure 19.8 illustrates, the user interface of the export utility is very similar to the user interface of the import utility. The primary changes to the interface are that the export utility does not affect any NT accounts and the interface enables you to export all recipient objects or just specific object types. The import file format and the export file format are identical. The header information is exactly the same and in the same order.
Figure 19.8. The Exchange Administrator Export utility.
The Exchange Server Technical Resource CD-ROM includes a utility named HEADERS that creates properly formatted header files for import and export. It has every attribute for most of the object classes.
admin /e <export file> /d <directory server name> /n /o <options file>
The command line of the export utility is almost identical to the command line of the import utility. The only difference is that /e is substituted for /i as the first switch.
The format of the export options file is different from the format of the import options file. Table 19.8 describes the items in the file and provides their defaults.
Item |
Default |
Description |
DirectoryService
|
N/A
|
The computer name of the directory server from which the utility exports the entries
|
HomeServer
|
The home server of the objects to be exported
| |
Basepoint
|
Local site
|
The X.500 distinguished name (DN) of the site from which the utility exports the entries
|
Container
|
Recipients
|
The X.500 relative distinguished name (RDN) of the container from which the utility exports the entries
|
ExportObject
|
Mailbox
|
The object class name of the type of object to be exported
|
InformationLevel
|
Minimal
|
The amount of logging that is performed during the export
|
BasepointOnly
|
No
|
Export only the requested attributes from the BasePoint object specified in the Basepoint option
|
Hidden
|
No
|
Determines whether hidden objects are exported
|
Subcontainers
|
No
|
Determines whether to export all the sub-containers of the container object specified by the container option
|
CodePage
|
Current
|
The codepage that the import file uses |
Most of the alternate values for items in Table 19.8 are obvious. The ExportObject and InformationLevel are discussed here. The ExportObject also accepts the values DL for distribution lists, Remote for custom recipients, and All for all three types of recipient containers. The InformationLevel also accepts None for no logging and High to log all warnings and errors.
Security services can be divided into two classes, authentication services and access control services. Exchange enables NT to provide authentication services. Before accessing an Exchange mailbox, a user must first logon to an NT domain with a proper user ID and password, thus proving their identity. Exchange security is concerned with access control.
Access control is accomplished through the use of rights, roles, and inheritance. In the Exchange directory, there are five predefined roles; admin, permissions admin, service account admin, send as, and user. The five roles are granted various rights. There are seven basic rights; add child, modify user attributes, modify admin attributes, delete, send as, mailbox owner, and modify permissions.
Individual NT accounts or NT groups can be granted permissions to access a container object, such as recipients. When they are granted permission to the object they are assigned a role, and the role determines exactly what rights they have in the container object. Whatever rights a user has on a container object, they also have on any objects within the container object. That is referred to as inheritance. The child object inherits the permissions, or in X.500 terms, the access control list, from their parent container object. Figure 19.9 shows the permission screen for the recipients container.
Figure 19.9. Permissions on the recipients container.
Permissions can also be set on child objects within container objects, such as the user Charlie Smith in the recipients container. However, the Exchange Administrator assumes that manually setting permissions on individual child objects is the exception rather than the rule. The default behavior of the Exchange Administrator program is to not show the permission page for non-container, or leaf node objects. To change this, from Tools | Options, select the Permissions page, and check the Show Permissions Page for all Objects box. Figure 19.10 shows the Permissions page of Tools | Options.
Figure 19.10. The Permissions page of Tools | Options.
After the Permissions page has been enabled for all objects, there are three ways to have the Exchange Administrator display the Permission page for a specific object. First, to select a recipient, click once on the object in the Exchange Administrator program. Then, either press Shift+Enter, click File | Properties, or press Shift and double-click the object. Any one of these methods displays the properties page for the object and the Permissions page will be available.
The Permissions page for an individual object illustrates how the Exchange security model works. Notice in Figure 19.11 that in the box labeled Windows NT Accounts with Permissions, the user CharlieS has been granted user role permissions. Also notice that in the box labeled Windows NT Accounts with Inherited Permissions, CATLAND\mosied has inherited the Admin Permission role from parent container.
Figure 19.11. The Permissions tab for an individual user.
The X.500 family of standards define the logical format of an X.500-compliant directory and how the various elements of the directory, including the user elements, communicate and interact. Exchange 4.0 adheres to the logical format of X.500; full X.500 compliance is scheduled for late 1996 and 1997.
The Exchange directory will not replace the NT registry, but the directory will take on a larger role within NT. Certain elements of the registry such as the accounts database will move to the directory while server specific elements such as filename and location of the Information Store of a given server will remain in the server's registry.
Armed with the knowledge of the attributes for the Mailbox, Custom Recipient, and Distribution List object class, an Exchange administrator can use the directory export and import functions to make many modifications. Changing the display order from FirstName, LastName to LastName, FirstName can be accomplished quickly and with 100 percent accuracy. Creating a new distribution list and adding hundreds of new members becomes a small task.