3.5 Distribution groups

 < Day Day Up > 



There are three types of Windows groups:

  • Universal groups

  • Global groups

  • Domain local groups

Universal groups are available anywhere within a forest. In other words, you can use a universal group to control access to any resource in the forest. Windows publishes details of universal groups in the GC, and clients resolve membership of universal groups when they log on by reference to a GC. This step ensures that clients receive a full set of credentials and are able to access resources through membership of any universal group they may hold.

Confusingly, Windows does not publish details of global groups in the GC. Similar to the definition of global groups used in Windows NT, global groups can be present in the ACL of any object in the forest, but they can only contain members from the domain that "owns" the group.

Domain local groups are the most restricted, since they only apply within the domain in which they are created. Again, Windows does not publish details of domain local groups in the GC. Domain local groups can contain universal or global groups along with individual users.

As you can see in Figure 3.26, Windows also defines groups by type. If a group is a "security" type, it means that the group holds a security principal and you can use it to control access to resources. A group that is a "distribution" type does not have a security principal, but you can use it with Exchange as a way to distribute messages, which is very close in style to the original definition of an Exchange distribution list. Figure 3.26 also shows that a security group can be mail enabled (the group has a published email address). A mail-enabled universal group that holds a security principal is the most powerful group. It is available anywhere in the forest, can be used to secure resources, and you can use the group as a traditional email distribution list.

click to expand
Figure 3.26: General properties of a Windows group.

Exchange is a messaging system, so it is extraneous to talk about distribution groups, even if this is accurate in terms of Windows. When you mail enable groups, they become functionally equivalent to distribution lists, so from this point on, I will only refer to groups when required by a feature or requirement of Windows and distribution groups in reference to Exchange.

3.5.1 Forming Windows groups

As with Exchange 5.5 distribution lists, Windows groups are composed of a set of backward pointers to individual directory objects (other groups, users, and contacts) that form the group. The left-hand screen in Figure 3.27 shows group membership as viewed through AD Users and Computers. The right-hand screen shows the membership of the same group, this time viewed through the ADSIEDIT utility. Here we see that the AD holds the membership of a group in a single, multivalued attribute called "Member" and that the attribute is formed by the distinguished name of each of the members. The AD uses the distinguished name as the pointer to the records for the individual members when it has to resolve or expand group membership. Because Windows builds a group through a set of pointers to AD objects, you have to be careful if you need to perform an authoritative restore of the AD to recover from a database failure, since you may affect group membership if the restore removes some of the pointers. For this reason, you should take great care to check important group membership after completing any AD restore.

click to expand
Figure 3.27: Viewing group membership.

The AD features attribute-level replication, but any change made to the membership of a group results in essentially the complete object being replicated, because the membership is held in a single attribute. This is true for Windows 2000, but the situation is a little different in Windows 2003, which includes a new mechanism called linked value replication (LVR). LVR addresses some of the problems associated with large distribution groups that span more than a few hundred members. People tend to leave and join groups on a regular basis, so the "churn" in membership generates an obvious issue in excessive network traffic to handle replication of the membership attribute. In addition, because the AD is a multimaster directory where any replica (DC) can originate an update, the danger exists that the AD will ignore updates when users make changes to group membership in multiple places at approximately the same time.

In this situation, the AD must reconcile changes coming in from multiple places without the benefit of human intelligence, and it does not always make the right decision. In Windows 2000, the AD is handicapped, because it updates only one attribute-the membership-for each of the changes it must reconcile. Thus, the change originating from the New York DC looks the same as the change from London. Which change should win? The AD uses its normal conflict resolution techniques to decide the "winner" (the update that is finally made). Timestamps eventually help to resolve the conflict, and the AD uses the last timed update to the group membership and applies that update to the group. Administrators may only know about a reconciliation snafu when a user complains that he or she is not able to access a public folder or that he or she does not receive email sent to a list. LVR helps to solve the conflict issue, because the AD is now able to resolve changes at the level of individual members rather than handling the complete group as one entity.

The fact that multiple changes to a group can overwrite each other is a flaw in the directory that the AD multimaster model exposed in Windows 2000. The problem also exists in the Exchange 5.5 DS, the ancestor of the AD, but its effect is less obvious, because sites own distribution lists (the DS equivalent of distribution groups) and only administrators from the owning sites can modify list membership. Thus, you have a reduced potential that multiple administrators modify a list at any time. Going back even further, this issue did not exist in Windows NT 4.0, because you had to make changes to group membership at the PDC, which acted as an arbiter.

The last issue is that AD uses more memory (in a component called the version store) than it really needs to when it processes membership in one large chunk rather than being able to focus only on the members who change. The problem becomes more severe as groups grow in size. Adding two members to a group that contains ten objects clearly imposes less stress on the system than when you add the 3,001st object to a group that already holds 3,000. In fact, because the version store is a limited size, it may be exhausted if the AD attempts to make an excessive number of changes in a single operation. The exact point when exhaustion occurs is dependent on the group, members, and forest, but Microsoft knows that problems usually occur around the 5,000 mark. The solution introduced by LVR allows the AD to track changes to individual entries in multivalued attributes and specifically group membership. However, LVR is only available when the Windows 2003 forest runs in interim or full functional modes, and the AD downgrades the feature when it replicates between controllers of mixed vintage.

Considering this information, we can see that it makes sense from a pure AD perspective to limit the amount of updates applied to groups whenever possible, especially for universal groups, since the AD replicates them to every GC in the forest. However, universal groups are very important to Exchange, since they are the only way to implement secure access to public folders and email distribution lists within multidomain implementations.

You can reduce the replication load by building the membership of universal groups from a set of global groups. This means that the effects of changes to group membership are restricted to the host domain of the users or contacts in the group, and the only replication to the GC occurs if a global group is added or removed from the universal group. Seeking to reduce replication in this way is a great example of how the needs of the base operating system do not match the needs of applications. If you include nested global groups in a universal distribution group, only Exchange servers in the same domain will be fully able to resolve group membership. This leads to a situation where you can send email to the same group from accounts in different domains and have messages delivered to different sets of people! Even worse, neither users nor administrators will be aware of the problem, because no problem exists in purely technical terms and Exchange signals no error messages. For this reason, it is a best practice only to use universal groups with Exchange.

3.5.2 Expanding distribution lists

The Exchange Routing Engine expands the membership of any distribution lists that a user includes in a message header and looks up the AD to find the preferred email address of each object in the lists. DSAccess handles the lookup process and may return email addresses from its local cache or after it looks up the AD. The Routing Engine uses the email addresses to help determine the optimum routing path for the message to reach the recipient and then to place the message on the right queue for transmission. All of this work happens in memory, and the Routing Engine does not expand the group membership to insert individual user names and email addresses in the header of the message. You can always view the membership of a group by selecting its name in the addressee list and then look at its properties. If the Routing Engine did expand group membership, Exchange would have to carry around unwanted and unnecessary information in message headers.

By comparison, if you use a personal distribution list to address a message, Outlook (or another client) must expand the contents of the distribution list and add all of the recipients to the header before it can submit the message to Exchange. You can see the impact of distribution list expansion on the size of a message by comparing similar messages addressed and sent to a group and a list, each containing 20 members. The message sent to the group is always far smaller.

Large distribution lists (more than 100 members), or those that contain nested groups, can impose a considerable demand on system resources during expansion. The expansion load does not usually affect servers equipped with multiple CPUs, since one of the CPUs can handle the work. Users can notice the delay in sending a message to a large list (if they are a member of the list), since Exchange can take up to a minute or so to deliver a copy of the message back to the originator. The current version of Exchange may seem slower than Exchange 5.5 in distribution list expansion, but this is a cosmetic change due to the way that the Routing Engine works. The Exchange 5.5 MTA expands distribution lists and immediately begins delivery to local recipients, so they receive their copies first. Now, the Routing Engine goes through a complex categorization process to ensure that it handles all copies of the message in an optimal manner. Local recipients see their copies at approximately the same time as the Routing Engine places copies to remote recipients on its destination queues. Delivery may seem slower, but it happens in a very efficient manner.

3.5.3 How many objects can I have in a group?

Exchange 5.5 distribution lists support a maximum of 5,000 objects, a limit set by the user interface in the administration program and respected by clients such as Outlook. It is possible to add more than 5,000 objects to a list, but only programmatically, using an interface such as ADSI. The AD imposes the same limit for membership of its groups, although, once again, you can manipulate a group through ADSI to add more entries. However, because of some technical issues involved in replicating group membership, Microsoft recommends that you avoid building groups with 5,000 entries. My own opinion is a little stronger on this topic-the limit is technical, not realistic, and you create the potential for problems if you insist on using very large groups. Best practice is to keep group membership under 1,000 to make everything (membership, replication, update collisions, traffic) a lot easier to control. This is particularly true in large, multidomain implementations.

Note the use of the word "objects" when referring to group membership. An object can be a user account or contact, but it can also be another group, so you can build groups from a collection of nested groups and build very large logical groups in this manner. Nested groups greatly expand the total possible user population that you can address through a single directory entry. However, while it is nice to know that it is technically possible to create a megadistribution list to address thousands of users at a single keystroke, once a list contains more than 200 users or so, it is also a weapon for people to use as a form of internal spam.

Windows does not impose a hard-coded limit to the number of groups that can exist in a forest, but you can run into a situation called "token bloat" that can prevent users from logging on. Token bloat occurs when the number of groups that a user belongs to is so large that Windows cannot fit all the groups into the security token. Because they are so useful for email, an Exchange environment is likely to use far more groups than a simple Windows deployment, and you may run into token bloat when you migrate from an earlier version of Exchange and Windows upgrades the distribution lists to groups. This is a good reason to review group membership and remove users from groups that they do not need to belong to.

3.5.4 Managing distribution lists

It is easy to set up new distribution lists, but some forget the hard work to maintain membership. In theory, updates should be automatic and the AD adjusts group membership as it deletes accounts and contacts. The normal problems include:

  • Adding new members: Whom should someone contact if he or she wants to join the list? An easy way to inform people is to include instructions in the "Notes" section of the list's properties, since this text is visible to Outlook when you look at its properties through the GAL (Figure 3.28). Note that a user is only able to manage groups that are part of the user's own domain and that you can control the ability for a manager to update the membership list by an attribute of the list. You cannot manage groups from other domains, because you are using an incomplete copy of the group replicated to a local GC rather than the full copy maintained by DCs in the owning domain. In addition, the group maintainer must have the correct Windows permissions (Allow Read Members and Allow Write Members) to be able to change the membership. You can grant these permissions at either the organizational unit (if the same maintainer takes care of multiple groups) or individual group level.

    click to expand
    Figure 3.28: Details of a list maintainer and its PF repository.

  • The informational text can state whether the potential member should email a request to the maintainer or take another action to join the list. Some companies have sophisticated Web-based applications to allow users to maintain their own group membership, using ADSI to communicate with AD behind the scenes. You can use tools such as the AUTODL utility, which is part of the Exchange Resource Kit, to help users create, manage, and delete distribution lists.

  • You know you have a problem when the list begins to receive "please let me in" messages from people who want to join, since this is a good indication that your procedures are not well known or do not work.

  • You need to know who the members of the list are. This is easy for small lists, but it becomes increasingly difficult as the numbers grow, because the standard tools for list maintenance (through Outlook or AD Users and Computers) have no way to generate membership reports. The ONDL utility, part of the old BackOffice Resource Kit (you may need to ask Microsoft for a copy of the program, because it is not available for download), is a very simple way of generating a membership list that you can then manipulate with Excel or Access. Figure 3.29 shows some sample output from ONDL. The input is the group's alias and the output is a list of each member's alias and display name. Alternatively, you can write your own program and use ADSI to interrogate the AD and retrieve all the necessary information.

    start figure

     C:> ONDL MWIZ Found alias "MWIZ" (Messaging Wizards): abiven, Abiven, Pat OchoaC, Alano, Cindie ….. ZhangPi, Zhang, Pierre hozihe, Zimmermann, Helga ** 574 Members **

    end figure

    Figure 3.29: Sample ONDL output.

  • Removing obsolete members: If your practice is to disable AD accounts and keep mailboxes for a period after their owners leave the company, you should remove them from all groups to prevent the mailboxes from receiving unwanted copies of email. It is a best practice for group owners to review the list regularly to remove recipients who no longer work for the company. Apart from filling Store databases with messages that no one will ever read, this step prevents the other group members from becoming annoyed when they send messages to the group only to receive multiple nondelivery notifications back. The most common reason for NDRs is that Exchange cannot deliver messages to the mailboxes of the disabled accounts (perhaps because the mailboxes have exceeded their quotas with all the messages that have arrived since the owner left the company).

You can block most nondelivery notifications by setting the "Exchange Advanced" properties (Figure 3.30) of the distribution group to:

  • Suppress notifications completely.

  • Send notifications back to the message originator.

  • Send notifications to the owner of the group as defined in the "Man aged by" property page.

click to expand
Figure 3.30: Properties of a distribution group.

The easiest option is to suppress nondelivery notifications for distribution lists, but this means that you never see any indication that someone has a problem-his or her mailbox quota is exceeded or Exchange makes an attempt to deliver to a mailbox that no longer exists, which could mean that directory replication is not working. Sending notifications back to the owner is acceptable if that person can take appropriate action. For example, if you allocate ownership to an administrative assistant, and he or she does not have the correct Windows permissions to modify group membership, then you will end up doing the work to maintain the group. Note that these properties are only valid for a single forest and single Exchange organization. If you operate in an environment where you use multiple Exchange organizations, the settings you make in one organization do not replicate to the others and you will still see notifications unless you turn them off everywhere.

3.5.5 Protected groups

Sometimes, the SMTP address of a distribution group gets outside a company. Apart from the obvious irritation if spam (otherwise called unsolicited commercial email) starts arriving for everyone on the list, there is a danger that unauthorized users could exploit the list to identify personnel within the company-for example, by a recruiter looking for specific talent. Exchange 2000 implements delivery restrictions for groups by checking that it could resolve the sender's address against the directory, but spammers can work around this check by spoofing their identity by inserting a perfectly valid email address in a message's "From:" field. For example, you might restrict a group so that only senior executives can send messages to it, only to be embarrassed when a spammer uses your chief executive's email address (which is often published or known externally) to address the troops.

With Exchange 2003, you can block such access by only allowing authenticated users (those who possess recognized NT credentials) to send messages to the list. In AD Users and Computers, select the list you want to protect and set the "From authenticated users only" checkbox on the Exchange General property page (Figure 3.31). This feature depends on a new attribute that Exchange 2003 introduces for user and distribution group objects (ms-Exch-Authenticated-Only), so you can only set authenticated restrictions on a group when working on a server that has the Exchange 2003 management components installed.

click to expand
Figure 3.31: Limiting a group to authenticated users only.

3.5.6 Suppressing OOF

People use out of office notifications, or OOFs, to inform correspondents when they are unable to process messages immediately, such as when they are on vacation. This is a worthy feature, but its side effect is that OOF messages often contain confidential information that you would prefer not go outside the organization. For example, it is common for users to tell correspondents to contact someone else in their department if they need quick action and to give telephone numbers and other information. This information is very useful inside the company, but it can be even more valuable to someone who is trying to learn about company structure. Recruiters can use this information to identify people who do various jobs inside a company and, at the other end of the scale, those who create distribution lists to sell to spammers are delighted to add anyone's email address to their databases.

You can stop Exchange from sending OOF messages across a connector. This step certainly achieves the goal of blocking information going to external recipients, but it is radical surgery because it removes a useful feature from users. When you analyze the problem, the vast majority of problems come from OOF messages that go back to list servers or distribution lists and not from OOF messages sent to friends. Therefore, it makes sense to apply a selective block and stop Exchange from generating OOF messages for incoming messages when you are not on the TO: or CC: list. For example, let us assume that you get a message from your mother, but you will not be able to reply for a few days because you are at an off-site meeting. In this case, you would certainly like Exchange to generate an OOF message to tell your mother that you will reply then. On the other hand, you probably do not want to send OOF messages in reply to every message that you receive because you belong to a very active Internet mailing list that discusses the finer points of wine appreciation or a similar subject.

On Exchange 2003 servers, you can force Exchange to check the set of message recipients to see whether a user explicitly appears in the recipient list rather than receiving a copy because he or she is a member of a distribution group. In this situation, Exchange can suppress OOF messages sent to the group and send them to individual recipients. To do this, you must create a new registry value as follows:

Key: HKLM\MSExchangeIS\ParametersSystem Value: SuppressOOFsToDistributionLists (DWORD) Set to: 1 (suppress); 0 (ignore)

Note that if you make this registry change, it will override the properties of distribution groups that otherwise control notifications.

3.5.7 Using public folder repositories for distribution lists

Popular email lists can attract a lot of traffic. Some of the messages that people send to the list will be very interesting and worthwhile and some will not, but in general the traffic represents a certain core of knowledge that you may want to keep. In this situation, you can add the address of a public folder to a list, which means that Exchange will automatically copy anything sent to the list to the public folder. This is an excellent way of building a record of the communication between the members of the list. An added advantage is that new people who join the list have a way to review previous discussions. At HP, many distribution lists have public folder repositories, some containing nearly 20,000 contributions gathered over the years. Once you start to collect items in the repository, you can then speed up searching for items by indexing the public folder using either Exchange full-text indexing or SharePoint Portal Server.

To add a public folder to a list, make sure that it is visible to the GAL and add it in the same way as you would add a mailbox or contact. You may then want to hide the PF from the GAL so that it only receives items sent to the list. Also, make sure that folder permissions allow list members to add items, since otherwise Exchange will not be able to write new posts into the folder.

With such a volume of data to manage, be sure to appoint someone as the editor of each public folder repository. Without editing, the public folder will become an accumulation of data, where you will find it hard to locate anything. The editor should regularly review the messages delivered to the public folder and remove messages such as the "me too" posts, which we all see too often on email-based lists. Additionally, the editor can compress message threads down to a smaller number of items by removing duplications, which makes it easier for all to navigate through the folder and find information.

3.5.8 Using groups for permissions

Because Exchange treats them like any other recipient, mail-enabled security groups are a useful way of maintaining permissions on public folders, much along the same lines as delivery restrictions. When you give permission to a group, all members of the list inherit the permission. The advantage lies in the fact that it is much easier to grant permission to a single entity, the group, than it is to manage separate permissions for each individual in the group. Better still, when people join a group, they automatically inherit the permissions held by the group and so have access to all of the public folders that are available to the group. Later on, when you remove some members from the group, Windows revokes the permissions they inherit from the group and there is no danger that someone will gain access to confidential information after he or she no longer needs this privilege.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net