By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
They don't know how to use SharePoint to make Exchange work better -- probably because of the preconceived notions they have about the two.
Learning how to dispel the myths about Exchange email-archiving with SharePoint will put them on the right path. Let's take a look at five myths and the truths that they're hiding:
MYTH #1: Public folders are dead
Everyone thinks that public folders are going away, but that's not so. A couple years ago, the Microsoft Exchange team shared its thoughts about the future of public folders to help customers plan better. It was misunderstood. The truth is that the Microsoft Exchange team has actually been encouraging the use of SharePoint for new deployments as well as encouraging migration where possible and where overlap exists.
But the fact remains that public folders and the custom applications built on them can be a nuisance for Exchange administrators. There are a number of common concerns -- control, performance, scale and replicating chaos, to name a few.
If you are deploying both Exchange2007 and SharePoint technologies— either Windows SharePoint Services (WSS) or Microsoft Office SharePoint Server (MOSS) 2007 -- it doesn't make sense to build up a huge public folder deployment. It's confusing to users, and it is additional overhead for the team that's managing Exchange. Instead, in its next version of Exchange 2007, Microsoft has new ways of managing and supporting public folders with PowerShell cmdlets.
If possible, avoid deploying public folders. If you've got them already, don't freak out. They will continue to be supported without much investment.
|TRUTH: The Microsoft Exchange team will include public folders in the next version of Exchange and, at a minimum, will support them for 10 years after shipping.|
MYTH #2: Pointing managed folders to a SharePoint list will solve all archiving needs in a turnkey, hands-off approach.
In Exchange 2007, Microsoft introduced managed folders with the intention of providing administrators with an easy means to help users archive email. It's an incredibly insightful feature and — when implemented properly -- can reduce mailbox sizes and capture the intended email. But, when not implemented properly, managed folders can be easily abused and used as a dumping ground.
One poor design example could be a managed folder called "Keep." All users can be told to put their stuff in that one folder, and it can be archived to SharePoint. It sounds like a great idea, right?
Wrong. First, putting all that junk into one list means that scale will be an issue. SharePoint doesn't scale well to support millions of items in one list, especially in a single view.
Second, what about the security of that list? Managed folders are an administrative setup. It's an option in Exchange, not an end-user configuration.
So what does a good design look like? How about a managed foldertitled "Legal Hold" that stores requests from users who have legal holds related to an investigation or court case? On the SharePoint side, a specific document library is set up and secured, and a legal site administrator is responsible for any tagging and for managing the views. A special search view might be set up with specific indexed columns to support an easy search with no "Allitems" view.
|TRUTH: To best take advantage of managed folders with SharePoint, you'll need a solid information architecture design as well as trained site and list administrators who understand the scale and can manage the volume with a custom view and indexed columns or folders.|
MYTH #3: It's better to keep all data in one place and to use metadata to search.
Although this is a common practice and popular method for personal storage, knowledge repositories in SharePoint do still require special information architecture designs.
The recommended limit of 2,000 items per folder popularized in WSS 2.0 isn't a bad one for those who don't have the time to invest in designing a query-based interface.
SharePoint administrators may want to recommend to their users that they limit the number of items on their lists to fewer than 1,000.
With an upper limit of 3,000, the IT shop gets involved assisting groups scale their lists more efficiently.
If you're looking for the easy answer to scale a SharePoint list, here is one approach: Use folders or indexed columns.
When the default Allitems view grows as a list into the tens of thousands, not only does it take tens of seconds to render, but it can also cause content database-locking during query time.Microsoft has set up a scan to detect large lists of more than 3,000 items to ensure proper usageand to divide up content where it makes sense.
For document management deployments, use folders for better scale and retrieval. Keep each folder to less than 2,000 items. Even better is a limit of a hundred or so to prevent unnecessary scrolling.
Filters are one way of limiting the number of items displayed, but in large lists, those queries can be inefficient. Using Indexed columns is another way to manage list scalability and increase index query optimization. The most efficient method of retrieval is search queries. Even changing the default view to something quick or a simple search or filtering-based interface provides better performance for large lists.Make sure there is limited exposure to the All items view, which can have an impact on the content database on really large lists.
|TRUTH: Divide up content where appropriate, and use folders to improve scale and retrieval.|
MYTH #4: A SharePoint deployment isn't complete until the self-service email-enabled lists are turned on.
The email-enabled self-service lists can be powerful, but in most deployments they can easily get out of control. Without the proper planning and management, Active Directory objects will be created with archiving and with no lifecycle.
Many SharePoint complaints involve contact account naming standards. IT managers don't want to see random contacts in AD. Everyone wants to have the document library called "docs," and everyone wants to have the discussion list called "discussion." So, the real recommendation here is to know what you're doing because it's easy to end up with a mess.
Again, you don't want to send all data from all users to one list. Put content in context in different site collections, sites or folders, or as it relates to the context of the group, team or project. Information architecture planning and oversight is required to scale a document management repository in SharePoint.
Don't be surprised if it's more complex to set up content than you initially thought it would be. One way to make it easier is to set it up in a preproduction environment first and learn how it works by exercising rightadministrative and trouble-shooting tasks around maintenance of the list, inbound SMTP and AD contact objects.
|TRUTH: Most SharePoint environments don't need the email-enabled functionality and the oversight that all that requires. But if you do decide to use it, plan to set up specific content objects and point the lists at those.|
MYTH #5: Email is safe and searchable.
Email is a place where users feel safe and where they can tuck away all of their important information for later use.
Therein lies the problem because email servers are not always safe. The bigger problem is that each user's inbox and folders are not searchable for anyone else. This is counter-intuitive to enterprises that are trying to make valuable content reusable.
It's time to change this thinking and to start putting files where they belong. Users need to be able to share their relevant information with each other in SharePoint. Using the collaboration platform, they can save email messages in their entirety or their attachments to SharePoint sites even without email-enabled lists.
If users can learn to save important email in SharePoint according to context and in lists and libraries as they relate to projects, teams and groups, then that content is searchable and reusable. Those meeting minutes and project documents—among other files—can now take advantage of version control and history. They can also evolve to become published content in knowledge repositories. The resulting document history—and the collaboration around it—becomes extremely relevant.
What happens to email that isn't saved outside of user mailboxes? It dies. As email evolves, PSTs go away in many corporations. Quotas force email purging, and the liability of some secret conversation from years ago simply expires.
Those who manage compliance of email would probably prefer that the content for legal holds and patents end up in the proper storage location— whether or not that location is a managed folder that's also managed on the SharePoint side. The legal department would probably prefer that the email have a defined expiration policy to keep down the volumes of chatter.
The bottom line is that relevant conversations and important documents that need to evolve should end up in SharePoint so the content can live on. This is a better line of attack than initiating some automatic push policy, which would be a security nightmare.
Microsoft designed SharePoint for collaboration. It's a way of sharing content securely throughout the enterprise. On a SharePoint site, the average document will be reused again and again by many people. The better the context and metadata, the more likely the content can continue to be useful.
|TRUTH:The black hole of collaboration is yesterday's email and file attachments. Today, the way for enterprises to keep content relevant, safe and searchable is to keep it in SharePoint.|
For new Exchange deployments, SharePoint is strongly encouraged for application development. The functionality of calendaring in either system for team calendars should be compared and contrasted based on out-of-the-box functionality based on requirements.
In the email-enabled public folders versus email-enabled SharePoint environments debate, IT shops may find that public folders have increased functionality but, again, they should consider their requirements.
The scalability of SharePoint lists is a major consideration and will require oversight, especially when using email-enabled lists. The default All items view can be problematic, and you may need to replace it with a search or filter-based interface. Use folders and indexed columns for large lists.
Some guidance may be required to help users understand where and when content should be stored. Email messages and attachments stored in SharePoint can contribute to the enterprise immensely in terms of project collaboration and knowledge sharing when secured in the proper context. Training users to tag content with metadata will increase the usefulness of documents.
The clear overlap between SharePoint and Exchange does not need to be a gray area. With the myths cleared away, corporations can understand the distinct differences and advantages and use the right platform for the right purpose. Storage and sharing of documents in SharePoint has advantages in collaboration, document management capabilities and discoverability with a rich search Web interface.
|Joel Oleson is an independent consultant involved in training, speaking, technical evangelism and product management for a variety of companies including Nintex. As former senior technical product manager for Microsoft Office SharePoint Server, Oleson focused on topics related to enterprise deployments of SharePoint, such as performance, scale, backup/restore and high availability. His blog is SharePoint Joel's SharePoint Land.|