This article explains server roles in Exchange 2007 in more depth.

 A "server role" is just a logical grouping of functionality in Exchange.  In the past, when you installed Exchange, you got it ALL -- and then you had to turn on or off particular features later to determine how that server would function.  (Would it be primarily a mailbox server, a transport server, a front-end server, etc.)? 

 Server roles enable you to declare ahead of time how you are going to use that particular Exchange instance in your enviornment.  It means that after install, you have to do much less of that customization to special-purpose your server.  For example, if you are going to use this server primarily as a client access server (for OWA), you probably don't need a mailbox database on it.  In Exchange 2007, we take care of that for you if you select only the client access role.  It also means that when you are using the Exchange Management Console you can easily tell how you are using that particular server in your environment. 

 However, 'server roles' do NOT mean that you have to use more physical machines in your deployment.  It is possible to put all server roles (with the exception of Edge) on the same computer.

One of my favorite new features in Exchange 2007 for end users is the updated Out of Office assistant.  In fact, this is a picture of me with the manager of our TAP program, KC Lemson, celebrating how much we love this feature in the Museum of Modern Art in NYC:

Why do I love this feature?  This post explains --

The rest is a guest post from Ashish Consul, a PM on my team:

The Out of Office (OOF) feature is commonly used by end-users to let other people know when they are not available to respond to e-mail.  Exchange 2007 Out of Office capabilities such as scheduled OOF, different external and internal OOF messages and the ability to control what kind of OOF to send on a per-domain basis improves the experience for both end-users and for administrators.

For End-Users

In Exchange 2007, some of the new Out of Office Assistant features are:

· The ability to schedule OOF messages in advance.  If users are planning time away from the office, they can set their OOF to begin at a future date and time and do not have to worry about forgetting to turn on OOF right before leaving. 

· Separate internal and external OOF messages.  This way, private information can be shared with co-workers without sending that information out to external senders. 

· External OOF messages can be sent only to a user’s external contacts.  Some users want to send their Out of Office messages only to a limited set of external contacts, but not anyone who might email them – for privacy reasons. 

• OOF messages can now be set as HTML instead of plain-text.

OWA and Outlook 2007 users who are hosted on Exchange 2007 mailboxes will see these new capabilities.  Outlook 2007 users who are on Exchange 2003 (or earlier) servers will have the same features as they have with Outlook 2003. 

This screen shots show the OOF configuration options available to end-users in Outlook Web Access:

For Administrators and Exchange organizations

In Exchange 2007, Administrators can choose to control external OOF capabilities at a per-domain and per-user level. 

Some organizations do not enable external OOF messages today, because they do not believe they are “safe”.  Some users put personal information in their OOF message that should not be leaked externally, and some companies have expressed concern about OOF messages as a mechanism for spammers to validate users’ email addresses.  In Exchange 2007, we believe we’ve addressed this organizational concerns.

For other customers, they would like to enable some of their users for external OOF messages (such as the ones working directly with customers), but not all of them.

Per User Settings

Exchange 2007 lets administrators control per-user external OOF messages using the Monad command “Set-Mailbox” with the “ExternalOOFOptions” parameter:

MSH>Set-Mailbox –id <mailbox identity>  -ExternalOOFOptions [InternalOnly,External]

By default, per-user external OOF option is set to allow external OOF.  By setting this to “InternalOnly” for a given mailbox, instead of “External”, that mailbox will not be able to send OOF messages outside the company, using any client, regardless of what the user selects.

Per-Domain Settings

Administrators can also control which (if any) OOF messages go to which external domains.  These per-domain settings are set via the Monad command  “Set-remoteDomain” using the parameter “AllowedOOFType”:

MSH>Set-remoteDomain –Identity <domain identity> -AllowedOOFType [None,InternalLegacy,Internal,External(Default)]

The AllowedOOFType values are as follows:

· None:  This blocks all OOF messages to the target domain.

· InternalLegacy: This allows either Exchange 2007 internal OOF or OOF set by Outlook 2003 or earlier clients to be sent to the target domain but blocks Exchange 2007 external messages from being sent to the target domain.  You would use this setting with a close partner company who you wanted to receive your internal OOF messages.  You would also use this setting in a cross-forest environment where one company had multiple Exchange deployments.

· ExternalLegacy: This setting allows either Exchange 2007 external OOF or OOF set by Outlook 2003 or earlier clients to be sent to the target domain.  If you already allow OOF messages to flow outside your company, you probably want to use this setting, so that existing Outlook 2003 users do not see any change in behavior.

· External(the default):  This setting allows only Exchange 2007 external OOF messages to be sent to the target domain but blocks internal OOF messages or OOF messages set using Exchange 2003.  If you currently block OOF messages to other domains, you probably want to use this setting in order to keep the same behavior for Outlook 2003 users but allow Exchange 2007 external OOF messages out for those who specifically choose them.

You can choose the wildcard ‘*’ for the target domain if you wish your per-domain OOF settings to apply to all external domains that don’t otherwise have a specific setting for them.

The following screen shot shows the per-domain OOF configuration settings in Exchange Management Console:

In addition, in Exchange 2007 OOF responses are more secure because of the following two checks:

· OOF messages will not be sent out in response to server-detected Junk E-mail.  If Exchange 2007 detects a message as Junk or if the message sender is in the user’s block list, no OOF response is sent. 

· OOF messages are not sent as responses to Internet mailing lists.  Exchange 2007 does not send OOF responses for incoming messages with the Precedence:bulk header set.  However, if this header is missing, it is possible that OOF responses may be sent out because there is no reliable way of determining that the message was sent to a mailing list.  OOF messages are also not sent as responses for incoming messages with the X-Auto-Response-Suppress:OOF header.

For the most part, I think my experiences with teachers were always quite positive throughout my school years and even though sometimes I tended to be the smart-guy making jokes in the class, I usually didn't get in any real trouble for it. 

Today I received information that my former high school principal passed away before his time -- I received additional background information via email that makes this an especially sad/tragic case. 

Now, I haven't seen him in 12 years but he was certainly someone who made an impression.  With his tall stature and deep voice, he could be overwhelming to a student.  And, since students can always come up with "creative" names to call their teachers, our nickname for him was "Lurch."  But when you got to know him he really cared about the students, was friendly, and had a sense of humor.  I can still remember some specific interactions I had with him throughout high school:

• He always taught students to greet people properly and shake hands like adults.  He did treat us like adults if we acted as such.  Anyway, I remember him saying you should shake hands "crotch to crotch" meaning that when you shake someone's hand the "crotch" between your thumb and pointer finger should meet their's.
• He explained to me what the phrase "brownnose" really meant when I (as editor) let the word get published in the school newspaper.  I didn't really know this before then.
• He told me once when he thought I just wasn't doing as well at school as he thought I could.  Mind you, I already had straight A's but he was always challenging us to do better if he thought we could.
• He wrote so many letters of recommendations for me to various colleges and universities (because I applied to quite a few).  Although one time he did say -- perhaps you should ask your parents if they actually have the money to send you to some of these places!  [He was probably right].
• He laughed, and told me I handled the situation like a great actor, when -- during a school play -- I basically lost my pants in front of the entire audience.

As a freshman you were likely to come in a little intimidated by him, but by the time you were a senior you really got to understand him. 

With all that being said, it makes you think about how you treat people -- and the difference you can make in other's lives -- because you never know when they might be gone. 

Requiem æternam dona eis, Domine, et lux perpetua luceat eis

In my last post, I wrote about why records management is important. This post will cover how Exchange 2007 and Outlook 2007 will help you with this.  

1.       Place your e-mail content in a place where you can manage it:

Exchange 2007 offers a wealth of records management features but it has to be able to see the e-mail to manage it. This means that e-mail needs to be in your Exchange mailbox and not stored in a client-only location such as a “Personal Folder” (.PST).  The first move is to increase the size of your mailbox quotas so that users can fit all the e-mail they needed into them. We’ve done a lot of work in Exchange, including the new 64 bit architecture, to make larger mailboxes much more performant and manageable. The next step is to wean users from their .PSTs in as painless a manner as possible. Using group policies, you can prevent new items from being added to .PSTs. Users well still have access to what’s already there while the same time being encouraged to place mail they want to keep into their Exchange mailbox. Eventually, you may want to remove .PSTs altogether.

2.       Give users a way to classify e-mail:

Most laws and regulations governing records management are based on the content of the item being managed. This means that in many cases you cannot simply create a single records management policy for all e-mail and be done with it. Yet even if you do create all the appropriate policies for different classes of items, you still have to classify each e-mail to decide which policy applies. Some automated mechanisms exist, though as yet none have a proven track record and are in widespread use.  Our approach in Exchange 2007 has been to allow the user to participate in this classification.

Administrators can create “managed custom folders,” folders with configurable names and brief policy descriptions that appear in Outlook and Outlook Web Access. These are mailbox folders (not public folders) that map to the various classifications of e-mail in your enterprise. Administrators can push these into the mailboxes of specific users. There is also the self service model available, whereby a custom web application can leverage Exchange web services to allow users to choose their own folders from a web page. Each one of these folders can have its own policy to control the lifespan of the e-mail (I’ll discuss these policies further below). All the user needs to do is move the item into the appropriate folder and Exchange takes care of the rest.

3.       Keep the content that you do need

Each one of the managed custom folders or managed default folders (folder that everyone has, such as the Inbox and Sent Items), can have policies that allow a copy of content to be preserved. This works by journaling (copying) any message placed into one of these folders to another location. This location can be anywhere with an SMTP address, including an Exchange mailbox or a SharePoint server. SharePoint 2007 has some excellent features that allow it to receive e-mail from Exchange and enforce advanced retention policies on it (that team’s blog is here).

4.       Get rid of the content you don’t need

On each one of these managed custom or managed default folders, you can also configure policies that remove e-mail that’s no longer needed for business or legal reasons. Once this mail reaches a certain age, it can be deleted immediately or moved to another folder where it will remain for a customizable period of time so that it can be reviewed before it’s deleted.

One way to use this is to place a relatively short retention period on default folders such as the Inbox and a longer one on managed custom folders. This encourages users to file items that they want to keep into their managed custom folders. The items left in the Inbox will just go away on their own. Of course, you need to structure your policies in keeping with any laws, regulations, and company mandates that affect your documents.

5.       Monitor and troubleshoot records management

Once you’ve implemented your policies, you can keep an eye on what’s actually happening. To see how users are using their folders, we have a PowerShell task that allows you to generate a report for one or more mailboxes that shows how users are filing items into each of their folders. On the administrative side, we have optional logging for what the server does to enforce policy (journaling, enforcing retention, etc.) as well as logging at the PowerShell level to track what the administrators are doing.  This logging extends beyond messaging records management and keeps a record of any administrative action done using PowerShell or the Exchange Management Console (which uses PowerShell under the covers).  

There’s a wealth of detail to be added here in each of these areas. You’ll see posts from me in upcoming weeks that describe how to use each of these features.

Again, this is a service to help automatically configure Outlook 2007 profiles based soley on a user's email address.  This service also helps retreive the locations of new Exchange 2007 services such as free/busy, out of office, and web-based offline address book distribution.

For Internet Outlook 2007 users, the basics of this service are that they enter their email domain (name@emaildomain.tld) and Outlook automatically tries to connect to:

• https://emaildomain.tld/autodiscover/autodiscover.xml
• https://autodiscover.emaildomain.tld/autodiscover/autodiscover.xml

When retrieving settings from one of these URLs, HTTPS (SSL) is required -- which means there must be a valid security certificate installed for that web site that matches the site name. 

This, of course, poses an interesting problem for Exchange-based messaging hosters who do not want to have to buy a unique SSL certificate and set up a new web site for each new hosted domain.  (If they are hosting mail for mycrazywidgets.org, they don't want to have to buy a valid certificate for autodiscover.mycrazywidgets.org).  This also may be an issue for corporate environments that host multiple email domains but do not wish to purchase a certificate for each one.

Luckily, we have a solution for this -- that you can try out once Office 2007 Beta 2 Technical Refresh is released.  (Check here, I think, for when it is released).

There are a set of "one-time" configuration steps for hosters to get going, and then a set of steps for each new email domain that you host:

One-time configuration steps for multi-domain hosting & AutoDiscover:

1. Create a new virtual web site (on a new IP) that is Internet-facing.  Call it something like "autodiscoverredirect.[hosterdomain.tld]" where [hosterdomain.tld] is your 'main' domain name.  {The actual name of this virtual web site isn't really important}.  No certificate is required for this web site.
2. Create an /autodiscover/ virtual directory on that web site.
3. Create an empty file in this directory called "autodiscover.xml"
4. Through IIS manager, configure that file to be a redirect to https://autodiscover.[hosterdomain.tld]/autodiscover/autodiscover.xml.  (This can be set on the properties page of the file through IIS manager).

Per-domain configuration steps:

For each new hosted email domain

1. The DNS configuration of that email domain must be changed to add a CNAME record for "autodiscover.[emaildomain.tld]" pointed to "autodiscoverredirect.[hosterdomain.tld]".

Given that you already have to make DNS changes to host a new email domain (i.e., configure the MX record), this should just be one small additional step in that existing process.

Client experience

Now, what happens when a user types in emailaddress@[emaildomain.tld] into Outlook 2007?  This isn't the complete list, but Outlook will:

• Attempt to connect to https://emaildomain.tld/autodiscover/autodiscover.xml & fail.
• Attempt to connect to https://autodiscover.emaildomain.tld/autodiscover/autodiscover.xml & fail.
• Attempt to connect to http://autodiscover.emaildomain.tld/autodiscover/autodiscover.xml & succeed -- but receive an HTTP-level redirect to https://autodiscover.[hosterdomain.tld]/autodiscover/. 
• Warn the user about this redirect and ask them if they trust getting their settings from [hosterdomain.tld].  (The warning can be turned off by the user after the first time).  It says:  "Allow this website to configure user@domain.tld server settings?" followed by the URL of autodiscover at the hoster domain.  If the user does not recognize the hoster domain, then they should cancel.
• If the user accepts, Outlook will then connect to https://autodiscover.[hosterdomain.tld]/autodiscover/ and retreive profile settings.

We've posted a Wiki Entry on exchangeninjas.com that describes how server-side search works in Exchange 2007 -- check it out.

UPDATE:  The original video had some problems being played; a new one has been uploaded.