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.

Let me introduce myself...

My name is Jason Mayans and I am the Lead Program Manager for the "Information Worker Team" working on Microsoft Exchange.  But this blog is not about me, it's about what we're doing in Exchange 2007 to improve the experience of the average end-user. 

Hopefully by now you've heard that we've released Beta 2 of Exchange 2007.  Anyone can download this and try it out in their lab environments; hopefully you are able to do this soon.

When we started Exchange 2007 (in 2003), my team was chartered with doing what we can to provide a "better together" Outlook 2007/Exchange 2007 experience for the average end user.  Although "better together" may sound like a marketing buzzword, what it basically means is that we want the end-user experience for an Outlook 2007 user who is using Exchange 2007 to be better than an Outlook 2007 user who is using Exchange 2003. 

To acheive this, we've made investments in the areas of calendaring, resource booking, out of office assistant, automated profile creation, search and messaging compliance.  Through this blog, I hope to talk about these areas and anything else related to Outlook & Exchange together that you find interesting.  I also hope to have various people from my team guest blog on their particular areas of expertise.

Hopefully we can make it interesting & useful for you, and give you some insight into the development of Exchange 2007. 

I posted recently with some background information on the new AutoDiscover service in Exchange 2007.

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.

A guest post from Julian Zbogar-Smith, a PM on my team. 

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.

Part 2: When we last left our superheroes (see Part 1) -- the Exchange Mailbox IW team -- they were still iterating through potential scheduling form designs to come up with the final plan.  (Click on all the images below to see the full size version).

Round 3 – The return of free/busy!

This design starts to get much closer to the final plan. After putting a number of the other designs in front of real users (yes, we actually do this sometimes), they told us loud and clear: we like the meeting suggestions as 'helpful hints', but we still want to see the free/busy. Basically, in order to get users to trust the new suggestions, we also had to give them a view of the original data (free/busy) so they could double-check that we were making smart suggestions. This lead us to the first view that integrated free/busy and meeting suggestions on the same tab.

There are a couple of other things to point out about this design:

• In this design, the "People" section and "Resources" section were split, and overall people preferred this design. It makes a lot of sense because users think about scheduling people differently than they think about scheduling rooms. We were able to get this "split grid" design into OWA (because it was being re-written anyway) but unfortunately weren't able to get it into Outlook due to time constraints.
• The "Location" drop down for Rooms, in this design, is something we should revisit in the future. The idea here was that you could quickly select a location and all of the rooms in that location would be added to your scheduling form (so that one free one could be chosen). We didn't end up getting a completely robust concept of 'location' built into the system, so this got dropped. However, OWA retained part of the concept in the final version with the ability to easily add all 'recently used' rooms.
• In "Round 2", the timeframe for the meeting suggestions was set through a dropdown; in this design, we introduced a calendar control that would pop up in front of the meeting suggestions when you clicked on the tab above it. The idea of the calendar control was that you could select one-by-one individual days that were 'ok' for you to meet in – so that the system would only provide suggestions during those particular days. The orange days you selected were the ones that you wanted suggestions generated for. The other interesting control in this design was a "Time of Day" filter (not shown active). If you clicked on "Time of day", a different control would be shown that would enable you to filter which particular hours of the day you'd like to have the meeting. The "Time of Day" plus "Timeframe" controls together would serve to filter the meeting suggestions that were returned.

Round 4 – Remove the 'time of day' and 'timeframe' controls

At some point, it dawned on us that instead of using the calendar control as a way for the user to filter results, that there were better ways to use it:

• The calendar control could be used to navigate the free/busy grid. One problem we heard and observed when we had talked to users is that it was quite easy for users to get "lost" in the free/busy grid and lose track of which day they were actually viewing. They didn't have an easy way to move around in the grid. We thought the calendar control could be used by the user as a free/busy navigation aid, and it turned out that worked quite well. This made it into the final version.
• In "Round 3", we were asking the user for a lot of input – like the timeframe of the meeting, and their preferred meeting time. Although this allowed for discrete control over the meeting suggestions that were returned, it wasn't clear that the benefits outweighed the cost of asking the user for more information. For one, instead of asking the user for the 'time of day' that they preferred the meeting, we could simply use the working hours already configured in Outlook. And instead of making them choose which days they wanted to potentially meet, we could just show them all the days and then color the ones that were better days for meeting vs. others.

This form also shows equipment called out as a separate row on the scheduling tab. This didn't make it into the final design – and improving equipment scheduling is something we should think about tackling in future releases. [The more I work in this area the more I am convinced there is so much for us to do still. Email and scheduling are far from being 'done'].

Round 5 – Prototype

This is one part of the effort that I'm personally proud of – and also helps to show how it is useful for Program Managers to be able to code up something every once in a while. Before we made the final no/no-go decision on building the feature in Outlook and Outlook Web Access, it was important to see the interaction "in action" to get a feel for how – and if – it could work. I built a prototype in ASP.NET of the design which – except for formatting – you can see looks very similar to the final design in Outlook Web Access. Since we were NOT part of either the Outlook or Outlook Web Access teams, building this prototype helped us have something we could show to them to prove its feasibility.

Round 6 – Final design

This is a screen shot of what it finally ended up looking like in Outlook Web Access. (Outlook looks very similar, except attendees and rooms are not in separate sections of the free/busy grid). In this example, I can see that August 8^th-22^nd are not good days to try to meet with these two other people but other days in August should work fine. I've also added a bunch of potential conference rooms to the form. By doing this, I can click on one of the meeting suggestions on the right – and choose a particular conference room. (No longer do you have to add a bunch of conference rooms, find the one that is free, and then delete the rest off – if you use the suggested times list, this gets taken care of for you).

In fact, the system works best when you intentionally add multiple conference rooms to the form. This way, the suggestions can tell you which room is free for that particular time and select it for you if you click on that suggestion. Intentionally adding multiple conference rooms to the form is a change that users should make to get the most out of this form.

Conclusion

I hope this was an interesting look into how one particular feature got built in Exchange 2007. If you have ideas on how we can improve the scheduling process even more in future releases, leave me some comments. We should also be posting a video walk-through some time with the PM for the feature (we've already filmed it).