11 Dec 2019 by Mike Weaver
Integration: The Final Step in Change Management
The final step in successful change management is the Integration stage. Here’s how to bring everything together. Watch now.
Public folders have been a part of Microsoft Exchange from day one. Microsoft released Exchange Server 4.0 in 1996 as a successor to its PC LAN-based Microsoft Mail 3.5 product. Against a backdrop of Lotus (now IBM) Notes, Digital ALL-IN-1 and other collaboration platforms, Microsoft needed to deliver a product designed for the enterprise, including both email and collaboration. Email was proliferating throughout organizations at a significant rate, and organizations were looking for ways to share and start collaborating.
The solution for collaboration delivered by Microsoft in Exchange 4.0 was public folders. Touted as the answer to internal bulletin boards, threaded conversations and discussion forums for enterprises, the initial intention of public folders was to allow users to share more than just text. Public folders supported attachments and threaded conversations, allowed folders to hold several types of items (such as calendars and tasks) and a whole set of custom forms.
Twenty-one years later, despite the availability of new collaboration platforms, many organizations still use public folders. Since the introduction of Exchange 2000, Microsoft has tried to convince customers to move away from public folders. Some organizations have succeeded in migrating, but many remain. The fact that public folders have “survived” for so long earned them the affectionate nickname as the “cockroaches of the Exchange world.” Not only are public folders still alive and kicking, but what is perhaps even more surprising is how little they have changed over the course of the last two decades. Let’s take a short trip down memory lane.
When public folders first appeared in Exchange 4.0, Microsoft called them “public fora (or forums)” and positioned them as the cornerstone for collaboration. Visible to all users in the organization by default, public folders allowed people to post notes, work together on email items, or share documents.
Public folders are organized in a hierarchical tree-like structure. Clients like the original Exchange client and later Outlook, opened public folders as one of the resources available in the navigation pane, right below the user’s mailbox folders and their personal folders. The view is still very similar to what you see if you switch to the folder pane in your Outlook client – 21 years later – as illustrated below.The similarities do not stop there. Other familiar features that have been around since the dawn of public folders include: drag and drop functionality, offline copies of public folder content (including conflict resolution), the permissions dialog used to control access to the folder, the use of the inbox assistant (rules) to copy new messages directly to a public folder, and more.
Another important feature, introduced as a competitive response to Lotus Notes, was the ability to publish electronic forms. Public folders supported with a wide spectrum of form types, ranging from simple dialogs, with some custom fields designed to gather information, to full-blown applications, utilizing event hooks, and integrated with the workflow engine. You could even use a form-based application to play chess with public folders, with the individual moves made by players being replicated to the copies of public folders on different Exchange servers distributed around the organization.
Perhaps however one of the most appealing parts of these new ‘Public Folders’ was the ability to restrict access to the information in folders by controlling folders and subfolders with administrative permissions, and also controlling which Exchange servers would show folder hierarchies based on where they were homed.
Replication was key to the success of public folders. It allowed organizations to distribute applications and data to multiple servers, so that documents and items stored in public folders are “close” to the user in network terms. Given the relative lack of network bandwidth and capability at the time, making a connection to a local server that hosted a copy of constantly-updated public folder information was much better than forcing users to make connections to centralized servers. While Exchange replicates the public folder hierarchy automatically to all servers that hold Public Information Stores (nowadays called the Public Folder database), content in public folders needed manual configuration for replication. Replication allowed people to collaborate even when using “slow” links. While replication certainly delivered many advantages, it also needed careful planning to avoid communication bottlenecks in intra-site links and conflicts between replicated items.
One example of note was on an oil drilling platform in the North Sea owned by a large energy company. With 120 employees based on that platform, it was essential to have local access for mail and collaboration (including key notices, policies, and similar). Placing a local Exchange server on the platform delivered local mailboxes for employees and replication for carefully selected Public Folder data.
Microsoft’s released Exchange Server 5.0 in 1997. Attempting to cater for an increasingly connected world, Exchange 5.0 greatly expanded the connectivity protocols available to customers by adding support for NNTP, POP3, HTTP, LDAP to the already existing MAPI, X.400 and SMTP protocols. What this meant for public folders was that feeds from Newsgroups could now flow directly into a public folder. NNTP could also be used to store and retrieve items from newsreader clients (which was important, given NNTP and news servers had a large following in the late 90’s). The admin tools also received a facelift to make some common tasks easier.
The biggest improvement was on the client side. The support for new protocols made it possible for users to access their messages, private, and public folders via a new, lightweight, web-based client, the forerunner of what we know as Outlook Web App today (Figure 2).Exchange 5.0 also delivered another important new feature – unauthenticated, or anonymous access. For the first time, it was possible for people outside your organization to access public folders. With a few clicks, you could configure external access to documents and other items stored in public folders, as shown below.
Microsoft continued the rapid evolution of its email server by releasing Exchange 5.5 in February 1998. This version delivered the last of the major client-facing features to public folders, as we know them today. To match some of the functionality available in Novell GroupWise and Lotus Notes, Exchange 5.5 introduced mail-enabled public folders. Mail-enabled folders can send and receive internal and external mail. This advance opened a set of new use cases. It was now possible to assign email addresses to public folders using the management tools, just like any other object type in Exchange.Mail Enabled Public Folders were a HUGE change and are perhaps one of the most significant reasons they are still in heavy use today. Not only could Public Folders become part of business processes, they could now be integrated with electronic mail: creating workflows, queues and shared ‘to-do’ folders full of mail awaiting processing.
Despite being released less than a year after Exchange 5.0, Exchange 5.5 included many important features. The Extensible Storage Engine (ESE) now supported a whopping 16 TB of storage for the single mailbox or public folder database available on an Exchange server. Public folder affinity (also known as direct referral) was introduced, as was “Wolfpack” clustering, IMAP4 support (including support for accessing public folders, meaning that any client supporting IMAP4 could access the public folder store/tree, another huge win for customers), new connectors for third-party products and more. Some of these features had an indirect effect on public folders, such as the greatly increased storage, or the item recovery (soft-delete) features.