Using Exchange Resource Accounts

Organizations that use Exchange quickly grow beyond the mindset of using the system simply to provide a mailbox for each employee and at some point will create mailboxes that aren’t tied to a specific person but rather to the organization, a business unit, or a function. I call such mailboxes resource accounts. For example, companies often create addresses with names like support@ and help@ so that customers can email their tech support–related questions and problems to these addresses. Some organizations also create mailboxes to distribute communications outward to many recipients. But a mailbox might not always be the best, most cost-effective choice. Organizations might need to consider they need yet another mailbox or use an alternative option. Let's explore how to use the different types of Exchange resources and points to consider when creating resource accounts.

Exchange Resources
When someone from the “business side” of an organization needs a resource on the Exchange server, that person typically requests a mailbox. For example, a manager wants to set up a leave calendar in which members of his staff can post the dates that they’ll be in and out of the office. By using the calendar, the manager will know when multiple team members are out at the same time and thus ensure that all tasks are covered. The manager decides to request a mailbox because he’s familiar with his own mailbox calendar's functionality. Although the calendar hosted in a mailbox might be what’s needed, another option that would work as well (and possibly better) is to use a calendar public folder.

Exchange provides two other resources besides mailboxes: public folders and distribution lists (DLs). You can assign an email address to all the Exchange resources (mailboxes, public folders, and DLs) and grant another mailbox send-as rights. Assigning an email address allows the resource to be addressed from Internet users or by non-Exchange–aware/SMTP applications. Send-as rights let an Exchange mailbox impersonate the resource as a sender in a message’s From field. The beauty of these capabilities is that recipients see that the message comes from the resource rather than a particular person. If recipients choose to reply, the reply goes directly to the resource.

For example, say I’ve been granted send-as rights to the Outage Notifications public folder. I can type “Outage Notifications” in the From field when composing a message. When recipients receive and view the message, they see Outage Notifications instead of my mailbox. If they view the sender’s properties, again they see the resource’s property pages and not mine. If recipients reply, the replies go into the public folder to be viewed later.

Alternatively, we could have used a DL named Outage Notifications and assigned my mailbox send-as rights to the DL. When I send a message, I again enter “Outage Notifications” in the From field. After I send the message, the recipients won’t see my display name, rather they see the DL's display name. The concept of sending from a DL might seem strange, but most internal recipients can't tell that they've received a message from a DL unless they typically look at the sender’s properties. Similarly, since external recipients get only the display name and SMTP address, they won’t know that the object linked to that address and display name was a DL. The beauty of using a DL to send “from” is that you can direct replies to one or more people simply by adding them as members of the DL. When sending, Exchange doesn't use the DL membership at all; Exchange simply uses the DL as a reference for the display name and addresses. But when the reply is sent to the DL, the list’s membership is expanded and each member receives a copy of the reply.

Which Resource Meets Your Core Needs?
So which resource is best? To answer that question, we need to ask more questions. In my experience, most situations don’t require a mailbox's advanced functionality (e.g., rules, delegates) but rather only a subset of capabilities, such as sending mail only, receiving mail only, sending and receiving mail, hosting a calendar, or hosting a scheduled resource. The starter question to ask is “Why do you need a mailbox?” You might get a long, complex answer with details that you’ll need later, but the core answer to take away from the response can be distilled to two basic needs: The user needs a mailbox resource to send or receive email, or the user needs some type of calendar. When you know which of these core needs you’re dealing with, you can ask more probing questions to determine the best resource type and how to configure it.

Mailbox Resources
Let's return to the outage-notifications scenario. For simply sending an outage-notification message, any of the three resource types will work. It’s what might happen after the message is sent or when you want to receive messages that usually has more bearing on which resource type to use. To determine the most suitable resource, ask questions such as these: Will recipients reply to the message? Who will read the replies? Who will respond if needed? Do you need to save copies of responses? Determine the pros and cons of answers to each question for each resource type.

Will recipients reply to the message? Someone always replies—even on messages that say Do not reply to this message. I call these “junk replies,” since no one will ever read the messages and storing them will waste system resources. If you use a mailbox and aren’t running Mailbox Manager, someone will need to periodically purge the replies. If you use a public folder, you could set an age limit on the folder content, and Exchange will delete the messages after the age limit expires. But my favorite trick to prevent the buildup of junk replies is to use a DL with no members. For example, create a DL named Do Not Reply with the email address [email protected]. When the list is used in a message’s From field, external recipients can’t tell that the message came from a DL, and internal Exchange recipients can tell only if they view the sender’s properties. If anyone replies, the reply is addressed to the DL and Exchange’s routing engine will discard the message because there’s no one in the DL membership to deliver it to.

Who will read the messages that arrive? Who will respond if needed? You need to understand who will read the mail—whether it’s replies to a message you send or messages that arrive in a resource that you’ve set up solely to receive mail—and how they use the mail in their job. Again, each resource type can receive mail, but each has unique features that affect usability.

Mailboxes let you grant multiple users access. However, an underlying assumption of a mailbox is that only one person will view a message. Thus, when a message’s state changes to read, there’s no need to consider whether anyone else will read the message. By comparison, a public folder assumes that multiple people, perhaps many, will view a message and provides capabilities to track a message’s read/unread state on a per-person basis. DLs merely deliver content to their members and have no tracking capability whatsoever. They provide a simple way to get content to those who need it without the user performing extra steps to get the content. DLs also provide the simplest and most flexible way of adding new people to the lists of those who need to receive a copy of the replies.

Consider what impact these functional differences will have on usability. For example, if you need to ensure that all messages are reviewed and responded to, a mailbox is probably the best choice because one user’s action of reading a message will be reflected in the views of all others accessing the mailbox. This reduces the risk that more than one person would read and respond to the same message. If you need to ensure that all users review all messages, a public folder would be the best choice. Say you want to ensure that all employees are kept apprised of security breaches or potential threats. The per-user read/unread status of public folder items make public folders the best choice to help users track whether they’ve reviewed all the posted items.

Do you need to save copies of responses? Generally, if you need to track and maintain replies, you’ll need to establish both the technical solution and a business process to go with the technology. For example, if you give user-level access so that a person can open a mailbox directly, any messages that the user sends go into the Sent Items folder. If you give the user send-as rights so that he or she can send mail using a different Exchange resource from within the user's own account, sent messages will go into the user’s personal Sent Items folder. The same thing happens when sending from a public folder—that is, items sent from a public folder to a user go into that user’s Sent Items folder. This makes it much harder to track who has already responded to the message; responses might be scattered in many different locations, increasing the risk of inconsistent or conflicting replies.

The only way to ensure that copies of replies are retained in a central location is to have the user manually save a copy of the message. For example, after sending a message, the user might need to copy it from his or her Sent Items folder to the resource account’s Sent Items folder. Alternatively, you might have users Cc or Bcc a copy of the message to a public folder or back to the resource’s address.

Scheduled Resources
Calendar resources are somewhat less complex than mailbox resources because Exchange provides only two calendar-resource options: hosted in a mailbox or hosted in a public folder. When someone needs a calendar, ask these questions: Will you invite the calendar in meeting requests? Will a delegate monitor the invitations, or does the calendar need to use rules or send automated replies? Will users post directly to the calendar?

Public folder calendars are generally the best choice when you don’t need sophisticated overlap checking or any type of rule or delegate processing. Public folder calendars are ideal when you mostly rely on the person viewing the calendar to assess the availability and control overlaps. I generally prefer to create calendar resources in public folders because you can centrally locate and organize the scheduled resources to make them easy to locate and manage. I’ve also found that one of the biggest wastes of space in a resource account comes from attachments that are included in meeting invitations. By hosting a calendar in a public folder, you can easily expire old content after a predefined time limit.

A mailbox-based calendar provides a better option when you need a feature such as direct booking, delegates, or rules or you need to track the accept/decline state of the invitees. (For more information about direct booking, see the Exchange & Outlook Administrator article "Using and Configuring Outlook Direct Booking," October 2002.) Another situation that requires a mailbox-based calendar is with an application that relies on free/busy information.

Other Considerations
Whatever resource you use, there are a few things you should consider to assess its impacts on the Exchange system. Ask questions such as how much storage quota will be needed? How long will items remain in the resource? Who will own the resource and be responsible for “tidying up” and keeping the usage below quota? And what's the resource’s expected lifespan? Without strict and correct management, resource accounts can become a system, security, and administrative burden. You should delete accounts that are no longer needed.

In many cases, people who were responsible for resource accounts leave the organization or business unit but don’t transition ownership of the resource. Accounts are frequently left unmanaged, and messages accumulate. Often test accounts are requested but aren't deleted after testing is finished. Many accounts (test accounts included) are usually provisioned into DLs so that they receive mail sent to wide-distribution or “all-users” lists. Accounts that aren't deleted often accumulate months' or years' worth of mail sent to these lists. To counter these problems, you'll need to build standard operating procedures (SOPs) into your account-management process to periodically review and assess whether resource accounts are still needed.

One way to facilitate resource-account management is to include the owner in the manager fields found on the Organization tab in the resource account’s Active Directory (AD) profile, as Figure 1 shows. This field is also visible from within the Outlook address book, as Figure 2 shows. I also recommend that you “flag” the account in some way so that you can easily identify the resource accounts for review. You might do so by placing the resource accounts in an organizational unit (OU) or by adding a text flag to an extension attribute. I personally like the latter method because I can use LDAP queries or the csvde.exe utility to export the manager, extension attribute, and other selected fields to a text file, which makes it easier for me to review and evaluate the resource-account information.

Finally, if the person making the request will be using third-party software to send messages or access the resource mailbox, you’ll need to understand a bit about that software’s needs. If the application uses MAPI, POP, or IMAP, you can use a mailbox only. If the application only generates mail (for example an Active Server Pages—ASP—Web page), it’s probably only using SMTP to generate and send mail to an address. In this case, there are no special requirements and any of the three resource types could accommodate your needs.

To help simplify the process of assessing which mailbox resource will best work for you, use the basic flowchart that Figure 3 shows to guide you in the decision-making process. The flowchart isn't fully comprehensive but does provide a starting point from which you can adapt processes for your organization.

Know the Business, Know the Solution
You can implement resource accounts in many ways, depending on the associated business processes and procedures, concurrent-access requirements, and message-storage and message-reply requirements. No single way of implementing resource accounts will fit every situation because each has a unique set of requirements. The key to selecting and configuring a good solution is often to understand the requirements of the business processes that the resource will support. When you understand the business process, you can integrate the resource into your messaging services with a full grasp of the resource's capabilities and limitations.