Public folders are as old as Exchange Server itself. But with Microsoft gradually reducing the importance of public folders from Exchange 2007 onwards, its future does not seem bright. Also, requirements of organizations are growing beyond the scope of Exchange Public folders. Collaboration specific products like SharePoint and cloud platforms like Office 365 are becoming more and more attractive to organizations. Here, we will just enquire why Public folders are losing their sheen.

  1. Exchange Public folders are for simple sharing only
    Public folders are not meant for document sharing or data archiving. Public folders lack comprehensive features for document sharing, versioning, and document management. For such tasks, Microsoft recommends using SharePoint. Also, it is not a good practice to use Public folders for archiving data.
  2. Public folders are not growing
    Public folders, with the exception of switching its location from Public folder database to Mailbox database to take advantage of its high availability, have not changed much. It hasn’t added any remarkable features to it. This makes Public folders almost an outdated feature. More innovative and advanced products and services like SharePoint and Office 365 are now available for organizations from Microsoft itself.
  3. Administrative difficulties
    Managing Public folders isn’t as easy as accessing and sharing its data. Administrators will have to use complex commands to execute even simple tasks. Obviously, administrators would like a facility or tool with more user-friendly features.
  4. Public folders consume Exchange resources
    Though Public folders act as repository that can be accessed by many email client users of the network, they consume valuable storage space. So, if you can find some facilities for simple sharing of data, you simply can abandon Public folders.
  5. Piling up of unwanted data in Public folders
    Public folders rarely get cleaned as nobody is sure on which information is useful and which information is not useful. Ultimately, it leads to piling up of unused and unnecessary data in Public folders.
  6. An uncertain future ahead
    Public folders may contain items that are required for many users. Calendar items, Contacts, Outlook forms, Journal entries, and even Messages are stored in them. So Microsoft may not be doing away with Public folders. Still, even experts are not sure of the future of Public Folders. Many believe that Microsoft may not provide Public folders in future versions of Exchange.
  7. Public folder to cloud migration is quite easy now
    Migrating the content of Public folders to Office 365 is quite easy now because of tools like LepideMigrator for Exchange ( This user-friendly tool performs data migration, and facilitates one-way or two-way migration between Exchange and Office 365 during the migration period.

Microsoft has not ended Public folders feature in MS Exchange Server. There are still a lot of reasons that prompt Exchange users to migrate their Public folder data to Office 365.

I created a List Event Receiver for my custom List Definition and wanted to set a view list properties programmatically in the EventReceiver. It worked perfectly in SharePoint 2010 but not in SharePoint Online.

To get the list I used the SPListEventProperties.List, but this object was causing some issues in SharePoint Online. I solved it by using the SPListEventProperties.Web.Lists[listname].

Code before:

SPList list = properties.List;

//enable content types
list.ContentTypesEnabled = true;


Code after:

SPList list = properties.List;
 SPWeb web = properties.Web;

// Re-opening the list, seems to be necessary because SharePoint Online has some sort of bug or timing issue.
 list = web.Lists[list.Title];

// enable content types
 list.ContentTypesEnabled = true;


This is a nasty SharePoint bug which caused some trouble in one of the SharePoint Online environments I was working on.

I created a Site Template using the “Save site as template” feature of SharePoint. Now when I created a new site from the template it resulted in the web parts all mixed up in the Left web part zone. Remarkably it was only the Left zone, the others were keeping their correct web part sequence.

When I took a look in the Onet.xml of the Site Template the web parts were nicely divided into seperate AllUsersWebPart’s and having correct WebPartZoneId’s. And although the web parts were also mixed up in the XML, the WebPartOrder properties were set correctly, 1 for the first, 2 for the second and so on. I still tried to rearrange the XML so the web parts would also have the right sequence in the syntax, but with no success, the web parts were still mixed up.

The final thing to do was to create a Web Part Zone for each Web Part. I did this by opening the page in SharePoint Designer and edit in the Advanced Mode (button on the ribbon).

This way the order is hardcoded on the page. I admit, it’s not very neat, but it does the trick.