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