I recently came across a posting from someone attending ITForum in Barcelona mentioning that Exchange 2007 has many server roles... "how many servers do we need!"?
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.
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.
Today a co-worker was discussing teachers and made the comment that he "never had any bad teachers" and always had a good relationship with them.
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:
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
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.
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:
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:
Per-domain configuration steps:
For each new hosted email domain
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:
I'm a frequent Outlook Web Access user, even when I'm at work but especially from home or when on a trip. One of the things that I think is best about OWA in Exchange 2007 is it's prominent "search" bar. This makes it very easy to find whatever email I'm looking for -- and since I have 10,000 messages in my Inbox folder alone (since Februrary) -- this is no easy task.
We've posted a Wiki Entry on exchangeninjas.com that describes how server-side search works in Exchange 2007 -- check it out.
We finally have the Scheduling Assistant video posted that Paul Tishhauser and I made for the Exchange Team blog. This is what I discussed in my first series of posts (1) (2).
UPDATE: The original video had some problems being played; a new one has been uploaded.
Need help troubleshooting Outlook 2007 / Exchange 2007 "AutoDiscover" and free/busy features?
We've started to populate the Exchange Wiki (http://www.exchangeninjas.com/) with some Exchange 2007 related information.
A PM on my team posted instructions on understanding and debugging Outlook's use of web services in E2k7. http://www.exchangeninjas.com/AvailabilityServiceFAQ. Its a good start and has some information that is not in current versions of the "official" documentation.
Some background --
Many moons ago when we began the process for planning Exchange 2007, we had a goal of reducing TCO for Exchange (well, this is really a perpetual goal). In our investigations, we discovered that the top corporate helpdesk expense -- in supporting Outlook & Exchange -- was helping users to configure their Outlook profiles. Even I, as a member of the Exchange team, have had to call the helpdesk before in order to configure Outlook Anywhere (RPC over HTTP) -- because I just didn't know the server name.
Out of this was born the idea of creating an "AutoDiscover" service -- a way for Outlook users to get automatically connected without having to manually type in a bunch of server settings. The approach was chosen of having clients connect to autodiscover.[my email domain].[tld] in order to retreive an XML file containing their profile settings. All the end user would have to know was their email address and password -- pure simplicity. In addition to the mailbox server, this mechanism was also used to help Outlook "discover" other new Exchange 2007 services that it could connect to -- including our new free/busy, new OOF assistant, Unified Messaging settings and the Offline Address Book.
While this approach of using autodiscover.[my email domain].[tld] was reasonable for Outlook clients connecting from the Internet, we soon discovered it wouldn't work from within many corporate environments -- a good percentage of which do not enable Outlook access from the Internet anyway using RPC/HTTP. Furthermore, there was a poor "out of the box" experience -- if you installed Exchange, and then installed Outlook 2007 -- it didn't "just work" -- you had to fiddle with DNS and certificates instead. Sometimes, the people configuring Exchange didn't even have access to the corporate DNS to make the necessary changes to create autodiscover.[my email domain].[tld].
We needed a solution that balanced the necessary security when connecting over the Internet with the simple out-of-the-box experience that most locally-connected, domain-joined users should have.
Exchange had a plan of automatically generating and installing self-signed SSL certificates when it was installed. Although these certificates cannot be fully 'trusted', the traffic to those servers is then automatically encrypted -- which is certainly better than nothing at all.
The conflict was -- when connecting over the Internet, we knew that autodiscover.[my email domain].[tld] should require a valid, trusted SSL certificate -- or else it could be spoofed, and you could accidentally try to authenticate against a bad, bad server and get bogus server settings. Because we had these self-signed certificates, Outlook would not connect at all to Exchange without installing the certificate on the client machine or setting a regkey that would cause Outlook not to use SSL. While this could be viewed as a security 'feature' when connecting in over the Internet, it was a real pain when you were inside the corporate network and just trying to get your brand new Outlook 2007 client to work properly with Exchange 2007.
The fix....
Luckily a smart PM lead (not me) dug around and came up with a solution using a capability of the Active Directory (AD) that we hadn't realized existed -- something called a Service Connection Point. (SCP). This was specifically created to help client applications locate particular services within an AD forest.
The decision was then made to use this SCP thing to help Outlook find an AutoDiscover server without having to use autodiscover.[my email domain].[tld]. If Outlook was on a client machine that was part of an AD forest, and it could contact a Domain Controller -- it would do an LDAP query to find an SCP for Exchange AutoDiscover and then use that URL to connect. In this case, because we definitively know that Outlook is running on the corporate network, Outlook would ignore SSL certificate errors when trying to connect to Exchange web services.
If Outlook was unable to contact a domain controller, it would fall back to trying to connect directly to autodiscover.[my email domain].[tld] -- the method that does require DNS configuration. In this case, valid & trusted SSL certificates are required to prevent any sort of server-spoofing on the Internet.
Still having problems?
The scheme described above made it into Exchange 2007 Beta 2 but was too late for Outlook 2007 Beta 2 -- so you won't see a great out-of-the-box experience with Outlook 2007 Beta 2 until the "Technical Refresh" of Beta 2 is published. But when it is, you should try the two out together and let me know if this seems to fix the issues for you.
And hopefully, some of the information here (http://www.exchangeninjas.com/AvailabilityServiceFAQ) can help you get going in the right direction.
We're going to be launching a public Wiki site for Exchange administrators to share tips & tricks. At first, I think it will be Exchange 2007 focused.
Here is a super-early preview (it won't be announced on the Exchange team blog for a few weeks):
http://www.exchangeninjas.com/
Leave some comments if you have some ideas on what would be useful to do with this wiki.
Infoworld's top article for this month is on Exchange 2007 Beta 2. One article was a list of the "Top 10 Features in Exchange 2007." Over time, I'll be talking about three of these areas:
I think they missed off the list two minor features that are sure to please --
This is a "guest blog" post from Julian Zbogar-Smith, Exchange PM for 'Messaging Records Management'
If you're part of an organization of any kind, that organization probably has records. These records can exist in a variety of forms, from paper to Word documents to e-mail. And if you have records, you probably have some way of managing them. They may be in a pile on a desk, in a file cabinet, or stored on a computer or in a more complex filing system.
At a high level, records management is the way in which an organization handles their stored information. This information carries with it a vast amount of intellectual property and to be productive workers need to have access to what's important to them. Organizations need to develop a system to manage what is kept and what isn't, control what is accessible and to whom, and make sure that workers can find why they need quickly while preventing information overload. In addition to that, thousands of points of law and regulation exist governing the management of records.
None of this is new information, so why is everyone talking about it now? There have been some big changes over the last few years that have sparked a strong interest in records management:
There's a lot more data now than there used to be: University of California at Berkley researchers estimating that 5 exabytes of new data were created and stored in 2002, 92% of which was on hard drives (link). That's 37,000 US Libraries of Congress and the number is growing each year. Figuring out what to do all with all this data has become complex problem given its scale and accelerating growth.
Managing records has become more expensive. You may be wondering what I mean by that, given that the storage costs per gigabyte of data have been plummeting over the last few years. As storage costs drop, the legal penalties for mismanaging information have gone up dramatically. Here are a few examples:
In December of 2002, The Securities and Exchange Commission, levied a fine of $8.25 million for failing to follow rules pertaining to electronic communications. This fine was split amongst Deutsche Bank Securities Inc., Goldman, Sachs & Co., Morgan Stanley & Co. Incorporated, and Salomon Smith Barney Inc, link).
In March of 2004, the SEC penalized Banc of America Securities for "Repeated Document Production Failures During a Pending Investigation" because they" "failed promptly to produce electronic mail" pertaining to ongoing litigation. The fine this time was $10 million and it was levied against one company alone. link).
In May of 2005, Morgan Stanley was ordered to pay $1.45 billion in a civil lawsuit, due in large part to failure to properly produce electronic documents. The judge ruled that Morgan Stanley had committed "willful and gross abuse of its discovery obligations" and reversed the standard burden of proof, requiring Morgan Stanley to prove that it had not committed the infractions of which it was accused of instead of requiring the plaintiff to prove that it had (link).
New laws and court judgments have made records management downright scary. Individuals are increasingly being held liable for mistakes and negligence.
In July of 2002, the Sarbanes-Oxley Act became law in the U.S. Unless you've been living under a rock, you've probably heard of this one. Among other things, it specifies jail time for executives who knowingly sign off on inaccurate financial statements. link)
In April of 2003, former investment banker Frank Quattrone of Credit Suisse First Boston was indicted for obstruction of justice. He sent an e-mail instructing some of his colleagues to "clean up those files" while some of them are being sought by regulators and a grand jury (link).
Understanding these trends, the Exchange team has made some significant investments in Exchange Server 2007 to provide tools to help you better manage your e-mail. Over the next few weeks, we'll be providing some further posts that give you more insight into how this works.
-Julian Zbogar-Smith
Program Manager
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:
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:
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 8th-22nd 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).
One of the features that my team is especially proud of for Exchange & Outlook 2007 is the new "Scheduling Assistant" that is in Outlook Web Access and Outlook 2007. If you want to see a live demo of this functionality (and all of Exchange 2007 calendaring) you should take a look at this TechNet Webcast that Paul Tischhauser, PM for the feature, did. Anyway, I thought it might be interesting to talk a little bit about how this feature evolved over time – starting from an idea to its development & completion.
Purpose of the "Scheduling Assistant"
We knew that calendaring was going to be one of our major points of investment in Exchange 2007. In the fall of 2003 and spring of 2004, we visited a number of companies to observe information workers, learn their pain points, and find out how they interacted with the product. One of the things that kept coming back to us was that – calendaring was too difficult, it takes too long to set up a meeting, and nothing has improved in Outlook in this area since it was first shipped. Since our team was tasked with making Exchange 2007 the best server for Outlook users, we wanted to figure out what we could do – across both server and client – to improve this experience.
We knew, from experience and from talking to users, that the "AutoPick Next" functionality in Outlook 2003 really wasn't that useful for scheduling meetings. For people that had busy schedules, and were trying to schedule a meeting within the next week or two, using this button would certainly find a time for the meeting – but it would be three months away. We wanted to figure out the right way of balancing all of the various inputs and requirements that go into meeting scheduling, including:
So we started brainstorming on various ideas around how to simplify the scheduling experience, and put together some prototypes. I was originally a big fan of doing something similar to the flexible search options found at Orbitz. (I like how they let you be specific, yet flexible, about your requirements – and how they present search results in a very powerful way. Three years later, I still think it is the best airline search out there). In the end, we went a different direction – based on user feedback – and came up with a design that enables users to slowly transition into a new way of thinking about scheduling without taking away what they like about the current design.
Round 1 – Conference Room search & Booking
Paul and I worked closely with one of the excellent members of our design team, Michael, to come up with some prototype ideas to test in front of users. For one of the first iterations of our design, we looked just at the issue of booking a conference room. First you would enter in the criteria for your conference room. This could include things like equipment you needed, the building the conference room was in, and the timeframe that you needed this in. Then, you would get back search results that would show you available time slots, and a drop-down list of rooms to choose from that were available at that time. We knew that some conference rooms will always require approval before booking them, so we wanted to also include that information in the results list. This is what that looked like (click on it for full detail):
This produced what I still think is some nice looking UI, but there were really two problems with this design:
Round 2 – Integrated into Outlook; People AND Resources are important
This next design shows integration into Outlook – as a new tab on the meeting form called "Smart Scheduling." (The "tab" design was before Outlook had implemented the "Ribbon"). In this design, you still specified your search criteria explicitly for your meeting. You could provide "flexible" or "specific" search criteria (my influence from liking Orbitz) for both the time of your meeting as well as the resources required for your meeting. I still kind of like this design, although it would have been more complex than our final implementation. Here is the first time you see the meeting options listed on the right-hand side in a format that is fairly close to what we ended up with. (Click on image for full detail).
We tested this type of design in front of users, but the feedback we got is that they missed seeing the individual attendee's free/busy, like they could in the normal scheduling tab. Although users appreciated our meeting options as a quicker way to find a good time to meet, they weren't comfortable with it unless they got to "see the data themselves" to confirm that our "smart" suggestions were really doing the right thing.
This is when we determined we needed to figure out a way to deliver the best of both worlds – in a way that enabled users to slowly transition from their current free/busy-based way of picking meeting times to using our new model.
I'll talk about how this continued to evolve in a subsequent post…
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.