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).

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.

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

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:

• Smart Scheduling (I already blogged on the evolution of this feature)
• Outlook auto-discover (enables easy configuration of Outlook profiles)
• Improved search

I think they missed off the list two minor features that are sure to please --

• Customizable & HTML quota messages & delivery reports
• Raising the 32k rules limit

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.

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.