- Exchange's Core Components
- Design Goals
- Architecture Similarities
- Terminology Changes
- Architecture Changes
- Directory Services
- Directory Access
- How DSProxy Is Used
- How DS Referral Is Used
- Transport Services
- IIS Integration
- Distributed Configurations
- Addressing with Exchange 2000
- Address Generation
- Directory Connectivity
- Active Directory Connector (ADC)
- Site Replication Service
- Address Lists
- Accessing Filter Rules for Address Lists
- Configuring Filter Rules for Address Lists
- Active Directory Users and Computers
- Creating Users
- Creating Groups
- Creating Contacts
- Managing Users
- Managing Groups
- Managing Contacts
- Tools
- ADSIEDIT
- NTDSUTIL
- Troubleshooting
- DS Referral
- Configuration of Diagnostic Logging
- Displaying Routing and Administrative Groups
Managing Groups
Now that groups are in the Active Directory, the logical progression is toward the management of these groups. Using the AD Users and Computers interface, groups can be managed directly. (See Figure 3.33.) Programming interfaces also can be used to manipulate these objects without the use of the MMC snap-in.
){kind=link}
Figure 3.33 Administrators can create a customized MMC that contains both the Exchange System and AD Users and Computers snap-ins.
To access the user properties, right-click the group object. A pop-up context menu will appear. From this menu, select Properties. The property dialog box will be presented with the General tab in front. (See Figure 3.34.) From the General tab, the administrator can modify the email address, the description, or the pre-Windows 2000 Group name. The AD group name can be modified by clicking the group object from AD Users and Computers, and then selecting Rename. A new dialog box with two fields will be presented. The first field is verifying the new name whereas the second is allowing the operator to change the pre-Windows 2000 group name.
){kind=link}
Figure 3.34 Note that the Group scope and type can-not be changed from this interface. Re- creation of the group object is the only way to change these settings.
The Members property sheet lists the members that belong to the group. Objects can be added or removed from this property sheet. In the example, the Whitewater Kayak Interest List has three members. (See Figure 3.35.) Two of these members are users, and the third is a public folder.
){kind=link}
Figure 3.35 It is important to note that any mail-enabled AD object can be a member of a group.
The Member Of property sheet displays the group to which the group belongs. Nested groups can save an administrator a lot of effort. The following is an example of nesting groups. Accounting Northeast, Marketing Northeast, and R&D Northeast are the three groups that collectively contain all the users in the northeast region. An administrator could create a high-level group called Northeast and make the three groups members of this highlevel group. Now users sending mail to the Northeast group would effectively reach all three subgroups, and subsequently all the users in the northeast region.
The Managed By property sheet is used to set the group administrator. The administrator specified for the list will be able to modify group membership from their client.
The Object property sheet is strictly informational, providing no user-editable fields. From this sheet, the administrator can see the fully qualified domain name of the group object. For troubleshooting the synchronization process, the USN numbers can also be found here.
The Security property sheet can be used to set ACL permissions for this object. These settings are the same as other Active Directory objects.
The Exchange General property sheet has two fields that can be modified, Alias and Display Name. The Message size setting can be used to restrict the size of messages sent to the group. The Message restrictions settings can be used to limit a single user, or group of users, by allowing or denying access on an individual user-by-user basis. (See Figure 3.36.) AD objects other than users can be specified here. For example, group objects could be used to control access to a group.
){kind=link}
Figure 3.36 Some of the Exchange General property sheet features for the group object might look familiar. They are similar in function to the features of the user object.
The E-Mail Addresses property sheet is where the user's email addresses can be found. Several different types of email addresses are supported. An administrator can create multiple addresses for the user of the following types: Custom, X.400, Microsoft Mail, SMTP, cc: Mail, Lotus Notes, and Novell GroupWise. At the bottom of the window is a check box called Automatically Update E-Mail Addresses Based on Recipient Policy. This check box allows the administrator to make bulk changes to recipient addresses by applying a policy. In lines of business where mergers and acquisitions are frequent, this is a useful feature indeed.
The Exchange Advanced property sheet contains several settings that an administrator can use to control the behavior of the group object. (See Figure 3.37.) Very important is the setting allowing the change of the server to be used for the expansion of the Group membership. This is very useful in large environments requiring a dedicated Expansion server. By default, the group is not hidden, nor does it allow the free flow of out-of-office messages.
){kind=link}
Figure 3.37 The Exchange Advanced tab holds many features that an administrator would expect to find here.
To add Public Folders to group membership, right-click the group object. A pop-up context menu will appear. From this menu, select Add Exchange Public Folders. The property dialog box will be presented with which public folders can be added. (See Figure 3.38.)
){kind=link}
Figure 3.38 The ability to add Public Folders (PFs) to a group could be used to store the traffic from an interest list in a PF. This PF could be leveraged in many different ways, Web accessibility being only one possibility.
Security IDs (SIDs) can be used to configure delegation on groups. Delegation cannot be done on mail groups' distribution lists because they do not have SIDs. Thus, delegation can be done only on security groups. The mode (mixed or native) of the environment also plays a role. Universal groups are not available in a mixed-mode environment. In mixed mode, no ability to nest a group within another group exists. To take full advantage of Windows 2000, Active Directory, and Exchange 2000, a move to native mode must be part of the plan.