Offline SharePoint

This is the fourth post in a guest series I’m doing here on Email Management in SharePoint. The third post was Myth #2.

Emailing a post to a blog … very cool or archiving an Exchange Discussion List to a SharePoint list … super cool … but be careful. Email-enabled self service lists can easily get out of control. Microsoft IT, which loves to use nearly every feature of SharePoint, decided against using email-enabled lists.

Email-enabled lists can be a significant IT resource drain. Without the proper planning and management, AD objects will be created with archiving and no lifecycle. Contact account naming standards are another reason. IT doesn’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”. If you have a process or even a workflow to get requests and manage these requests, you can better manage who needs them, when they are needed and for how long. So, my recommendation here is to know what you’re doing. Otherwise, it’s very easy to end up with a mess.

Like Public Folders, email-enabled lists can also pose security risks if not managed properly. Fortunately, they are more often secured to the context of the team so they are not as much of an exposure.

List scalability can pose problems with email-enabled lists. You don’t want to send all data from all users to one list. Put content in context in different site collections, sites, folders, as it relates to the context of the group, team, or project.

Most SharePoint environments don’t need the email-enabled functionality and the oversight it requires. Those that decide to use it should plan to set-up specific content objects and point the lists at them. Steve Smith’s document called “How to configure Incoming Email Enabled Libraries in MOSS2007 RTM using Exchange 2003 in an Active Directory Domain” explains in detail how to set-up email enabled lists. Don’t be surprised if it’s more complex to set-up than initially thought. I recommend setting it up in a preproduction environment first and learning how it works, then exercising administrative tasks and troubleshooting tasks around maintenance of the list, inbound SMTP, and AD contact objects.

In summary, I’d suggest you get answers to the following questions before implementing email-enabled SharePoint lists:

• Are those contact objects in a separate OU?
• How do you know if the inbound SMTP stops working?
• Can anyone send to the list?
• Does the item show up the way you expect it to, or are just attachments showing up?
• Does the metadata look like you expect it to?

The answers will help you better understand the nature of these special lists and help you better take advantage of this functionality, if you decide to use it.

Truth: Use with caution: To be successful, email-enabled lists require management & oversight to scale past a few thousand items.

Joel Oleson discussed some of the advantages and disadvantages of Exchange Public Folders in his last post. Like Public Folders, Colligo Contributor Add-In for Outlook provides a convenient method for linking SharePoint document libraries and lists into Outlook folders. Unlike Public Folders, the addition of shared folders to mailboxes does not necessitate IT involvement. They can be added by end users themselves, based on existing user permissions set in SharePoint. Optionally, IT administrators can push out a configuration file to the clients that automatically links a set of SharePoint document libraries and folders to Outlook without user intervention. This file can also be used to manage a number of configuration options, including default metadata for individual folders.

Joel mentioned that SharePoint is a better option if you are migrating Lotus Notes applications. It is important to consider some gaps that need to be filled when doing these migrations:

1. mail and document management system integration,
2. a rich client experience on the desktop, and
3. offline caching for mobile and remote workers.

Lotus Notes users will be accustomed to a rich desktop client that integrates with the email application and works online and offline. Out-of-the-box SharePoint only supports an online browser-based experience. Outlook 2007 syncs with SharePoint document libraries, discussions, and a few standard lists, but it doesn’t support elements such as custom lists, content types, metadata, or views that users are used to in Notes applications. It also doesn’t support drag-and-drop from Outlook to SharePoint. For an overview of the offline SharePoint capabilities of Outlook, you may find this post from 2006 informative.

If you are looking to provide an equivalent to the Notes client, the Colligo Contributor Add-In for Outlook supports SharePoint’s advanced elements that are used to migrate Notes applications, and it integrates SharePoint with email. In addition, it can cache SharePoint lists and libraries (including views and metadata) so the applications and content can be used offline.

This is the third post in a guest series I’m doing here on Email Management in SharePoint. The second post was Myth #1.

In early 2006, the Exchange Team at Microsoft outlined their thoughts about the future of Public Folders in a blog post titled “Exchange 12 and Public Folders.” It was intended to let customers know that Microsoft was de-emphasizing Public Folders for certain applications, but many misunderstood this to mean that Public Folders were dead.

Microsoft’s position was clarified in March 2008 in a post titled “Updated Exchange Public Folder Guidance,” which encourages use of SharePoint for new deployments and migration where overlap exists. This blog confirmed that Microsoft will continue to support Public Folders in the next release of Exchange and for an additional 10 years from its release.

This post also provides the first scenario-based examples where Public Folders and SharePoint are compared. I know both the SharePoint team and the Exchange team were involved since I was on the SharePoint team when it was designed and played a role in getting it cross posted on the SharePoint team blog.

Click to Enlarge

Above is my version of the table in the blog post. I’ve changed some of the wording to make it easier to understand, with a bit of commentary emphasis on really investigating SharePoint functionality when both Public Folders and SharePoint have overlap across a scenario. SharePoint is “strongly encouraged” for most application development, though in some instances there still may be some advantages to Public Folders. For example, the capabilities of team calendars in Exchange vs SharePoint should be compared against the specific requirements of the application. Also, if you are looking at email-enabled lists in SharePoint, you may find that public folders are a better match for your requirements.

While de-emphasizing Public Folders, Microsoft didn’t stop evolving them altogether. For example, in Exchange 2007 there were new ways of managing the Public Folders with Powershell cmdlets. Please note that the functionality and features require investments on the part of the customer. However, the current guidance is that Public Folders are now in maintenance mode.

It’s illustrative to look at what Microsoft IT is doing internally with Public Folders. They decided to impose constraints both on time and size to limit the growth of the stores. Microsoft IT also turned off replication to reduce the unnecessary growth of storage. New folders were locked down to exception-based requests, with new provisioning requests pointed to SharePoint (with the common exception of distribution list archiving).

So why is Microsoft IT moving more content to SharePoint? In contrast to Public Folders, SharePoint was designed as an application platform and it’s important to note that this is the continuing direction of Microsoft. Both Windows SharePoint Services and Office SharePoint Server are major investments for them and they will continue to augment their functionality to support the common scenarios of customers.

While Exchange Public Folders were previously the endorsed solution by Microsoft for sharing email, SharePoint is now the recommended solution. If you are still considering Public Folders, it’s important to understand it has several well known limitations and challenges, described below.

1. Public Folders and custom applications built on them are the bane of the life of an exchange administrator. Control, performance, scale, and replicating chaos are a number of common concerns. Public Folders require heavy upfront and ongoing management.
2. Security is also often a concern due to the public nature of email-enabled Public Folders. Organizations are exposed to large risks if the random content flying around in emails is not controlled, so Public Folders need to be carefully managed. Security and liability are definitely something to be considered in all cases where email content is stored. It’s important to understand who has rights to store email on the server.
3. Public Folders can also be an HR nightmare. These “public” social dumping grounds often become a place where pictures and music are exchanged. As well, DLs (Distribution Lists) can get buried in group and team email-enabled security groups.

Bottom line: if you are deploying both Exchange 2007 and SharePoint technologies (WSS or SharePoint Server), it doesn’t make sense to build up a huge Public Folder deployment. It’s confusing to users and additional overhead for the team managing Exchange.

But should you use Public Folders when you are doing a Groupwise, or Lotus Notes migration? For nearly all your Notes applications you should seriously look at SharePoint. For email it’s a no brainer… it’s Exchange. For discussion groups and archiving, you’ve got a decision to make. When migrating to SharePoint, you should do it with an understanding of what you get out of the box, and what you get with a partner. Most gaps you find in SharePoint are filled by a very solid partner ecosystem.

One last point. If you plan to customize SharePoint sites and site templates, have a look at this blog post on Features and Solutions. Features allow reusable pieces of functionality to be created and deployed to other sites, without modifying site templates. Solutions allow you to package Features in a cabinet (.cab) file and define important metadata about those Features.

Truth: The Exchange Team will include public folders in the next version and at a minimum support them for 10 years after the release. However, they encourage you to seriously consider SharePoint for application development.

As Joel Oleson mentioned in his last post, it is really important to make an email management solution attractive to end users (to ensure it gets used), while providing a mechanism to set metadata (for search) and content type (for retention).

Colligo Contributor Add-In for Outlook enables users to drag-and-drop emails and attachments right into Outlook folders that are synced to SharePoint document libraries. It’s easy to use because it supports the familiar Outlook operations, so information workers readily adopt it to move selected content to SharePoint.

Contributor Add-In also supports the manual application of metadata or automatic application of folder-level metadata. It is ideal for both compliance and collaboration applications since it extracts all the properties from emails (To, From, Subject, Date, etc.) and saves them as metadata. Users can select the content type so that hold periods can be specified. All emails moved through Colligo Contributor are saved in the .MSG format, so they can be easily opened again using Outlook.