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.

Automated deployment for SharePoint Online can be one hell of a job. Apps and sandboxed solutions are the designated methods for provisioning, but are very limited. How about PowerShell? Yes! But not the default flimsy SPO cmdlets library. No, we are using SharePoint PowerShell, a third party PowerShell API for SharePoint (Online and On-premise).

SharePoint PowerShell

SharePoint PowerShell in fact a bunch of PowerShell Modules talking to CSOM, created by a guy called Jeffrey Paarhuis 🙂  Very usefull for Office 365 and private clouds where you don’t have access to the physical server.

What can you do with it?

  • Site Collection
    • Test connection
  • Site
    • Manage subsites
    • Manage permissions
  • Lists and Document Libraries
    • Create list and document library
    • Manage fields
    • Manage list and list item permissions
    • Upload files to document library (including folders)
    • Add items to a list with CSV
    • Add and remove list items
    • File check-in and check-out
  • Master pages
    • Set system master page
    • Set custom master page
  • Features
    • Activate features
  • Web Parts
    • Add Web Parts to page
  • Users and Groups
    • Set site permissions
    • Set list permissions
    • Set document permissions
    • Create SharePoint groups
    • Add users and groups to SharePoint groups
  • Solutions
    • Upload sandboxed solutions
    • Activate sandboxed solutions

And yet more to come…

How does it work? Well, like this:

# Include SPPS
Import-Module .\spps.psm1

# Setup SPPS
Initialize-SPPS -siteURL "" -online $true -username "[email protected]" -password "password"

# Activate Publishing Site Feature
Activate-Feature -featureId "f6924d36-2fa8-4f0b-b16d-06b7250180fa" -force $false -featureDefinitionScope "Site"

#Activate Publishing Web Feature
Activate-Feature -featureId "94c94ca6-b32f-4da9-a9e3-1f3d343d7ecb" -force $false -featureDefinitionScope "Web"

# Create a subsite
Add-Subsite -title "Subsite" -webTemplate "STS#0" -description "Description..." -url "subsite" -language 1033 -useSamePermissionsAsParentSite $true

# Create document library
Add-DocumentLibrary -listTitle "Testdoclib"

# Copy testfiles to this document library
Copy-Folder "C:\example\Testdoclib" "Testdoclib" $false

Try it yourself: example application 

And let me know what you think of it and how it can be improved!


Due to the success of this post I continued this as a project on CodePlex:


But if you still want to continue reading this post, go ahead.

How it works

Download this file and extract the DLL to an easy location to reach from PowerShell. Because this assembly uses the Client Object Model you need to install the COM Redistributable as well.

These are the PowerShell commands to run:

You need to run PowerShell in single-threaded mode (the authentication requires it).

powershell -STA

Import the DLL.


Instantiate a new SPOContext providing your SharePoint Online site URL. (Don’t forget the https)

$spoContext = new-object SPOContext("")

Now, let’s test it:

$spoContext = new-object SPOContext("")
$web = $spoContext.Web
Write-Host $web.Title

As you already might understand, this solution is based on the SharePoint Client Object Model. This means that everything that’s possible with the COM is possible to script. This post explains how to work with Sites, Permissions, Documents, etc. with the COM. It is written in C# but it’s fairly easy to translate to PowerShell.


Init spoContext

powershell -sta
$spoContext = New-Object SPOContext("")

Print sitename

$web = $spoContext.Web

Add property to bag

$web.AllProperties.FieldValues.Add("propA","Property A")

Show features

$site = $spoContext.Site
$features = $site.Features

Permissions stuff

Function GetWeb
 Return $ctx.Web

Function GetList ($name)
 $web = GetWeb
 if ($web -ne $null)
 $lists = $web.Lists
 $list = $lists | where {$_.Title -eq $name}
 return $list
 return $null

Function GetRole ($rType)
 $web = GetWeb
 if ($web -ne $null)
 $roleDefs = $web.RoleDefinitions
 $roleDef = $roleDefs | where {$_.RoleTypeKind -eq $rType}
 return $roleDef
 return $null

Function GetPrincipal ($name)
 $web = GetWeb
 if ($web -ne $null)
 $principal = $web.EnsureUser($name)
 return $principal
 return $null

Function GetGroup ($name)
 $web = GetWeb
 if ($web -ne $null)
 $groups = $web.SiteGroups
 $group = $groups | where {$_.Title -eq $name}

 return $group
 return $null

Function GetDocumentLibrary ($name)
 $web = GetWeb
 if ($web -ne $null)
 $docLibs = $web.Lists
 $docLib = $docLibs | where {$_.Title -eq $name}
 return $docLib
 return $null

$web = GetWeb

$web.BreakRoleInheritance($true, $false);
$principal = GetGroup "MyGroup"
$roleType = [Microsoft.SharePoint.Client.RoleType]"Contributor"
$role = GetRole $roleType

$collRdb = new-object Microsoft.SharePoint.Client.RoleDefinitionBindingCollection($ctx)
$collRoleAssign = $web.RoleAssignments
$collRoleAssign.Add($principal, $collRdb)


$list = GetList "Shared Documents"

$list.BreakRoleInheritance($false, $false);
$roleType = [Microsoft.SharePoint.Client.RoleType]"Reader"
$role = GetRole $roleType

$collRdb = new-object Microsoft.SharePoint.Client.RoleDefinitionBindingCollection($ctx)
$collRoleAssign = $list.RoleAssignments
$collRoleAssign.Add($principal, $collRdb)



You might see the following errors from time to time, which aren’t a big deal:

– “The requested site does not appear to have claims enabled or the Login Url has not been set.”.
Problem: This usually means that no session can be instantiated (SharePoint Online bug).
Solution: Navigate to your site in Internet Explorer, when your site doesn’t show, refresh it a few times until it shows, or go to When you get a login page, go back to your script.

– “The remote name could not be resolved: ‘'”
Problem: During scripting, the context timed out.
Solution: Re-instantiate the $spoContext object. When running a script in one go, this error shouldn’t pop because the Context will not prematurely expire.

Under the hood

How does it work under the hood? What’s in the DLL? What makes SharePoint Online so difficult?

In line with this one I’ve written a post that explains what the problem with SharePoint Online is and how to build your own DLL. Read it here.

UPDATE (11-7-2012):

Forgot to mention you need to install the COM Redistributable.

UPDATE (3-9-2012):

Added samples.

It may take some time before we can see the first of SharePoint 15 (or some might say SharePoint 2013).

Till that time, Microsoft has released some technical documentation in the form of an API. It’s far from complete, I hope, but it gives us a bit insight in the new features of the new SharePoint.

There are a few interesting features that we can trace from this API. You can find the API here But for the one that’s too lazy to disassemble the API himself, beneath is a summary of expected features.

Game changing features


In the API there’s one feature that has the upper hand, the Apps. It’s also very certain that a marketplace is coming.  There will not only be a general marketplace, but it will also be possible to have a corporate catalog (apps only available within the corporate).

These new SharePoint Apps are not just web parts, or any other kind of SharePoint solution we know from the current versions of SharePoint. An App is a new solution format that comes with SharePoint 15. A few advantages of Apps, we know so far, are:
– It’s very suitable for a traditional application structure, with multiple pages, theming, configuration, an own database, etc.
– developers can add an own deployment (installation, upgrade, uninstall, etc.)
– a database (MSSQL, and other formats) can be attached
– it has its own user permissions
– it has its own licensing

This is a big step for Microsoft, but also very understandable. Nowadays it seems that the entire society is relying on apps and marketplaces from all kinds of vendors. Microsoft already Marketplaced the Windows Phone, Windows 8 is coming, but they would be stupid if they didn’t also do this for SharePoint. With the Windows Phone Marketplace they were relatively late, but with the SharePoint Marketplace they are just on time.  Using Marketplaces for business purposes is very hot at the moment. I can’t wait to get to work with this.


Minimal Download Strategy is a term that probably doesn’t ring any bells. That’s right, it’s a new framework Microsoft includes in the next SharePoint. It’s mentioned very briefly in the API but I think it’s a big deal.

So, what is it? MDS allows websites to take much less bandwidth than with traditional technologies. It’s a technology that allows websites to only send the changed part of the page, relative to the previous page, to the client. If you assume that a website has a header, footer, menu, right column and some content, and navigating to another page only changes the content part, then MDS will take care that only the content will be transferred from the server to the client. This way, not only the bandwidth is used more efficiently, but the pages will be more responsive.

For more info on MDS read this:

Other features

More versioning

We know we can version documents and list items, but in the next SharePoint we are also able to version entire parts of SharePoint. An entire site for instance. Fascinating! But whats the big advantage? Well, here it comes. Let’s assume that we already have a site and we would like to make big changes to it, how will we do that? In the current SharePoint we would have to copy the site (preferable to another environment), implement changes and deploy it back. While in SharePoint 15 we could freeze the active version, then create a new version, implement changes to that new version and when done, set the active version to the new site we changed. My guess is that Microsoft did add this feature mainly for SharePoint Online, because most clients don’t have a separate acceptance environment. Deploying this way fits perfectly in a DTAP roadmap for Cloud solutions.


As a developer you can now get a themed version of your CSS that uses the theme colors and styles, with a simple line of code.

Client Object Model

The Client Object Model is extended with Search. The functionality corresponds to that of Microsoft.Office.Server.Search we know from the current SharePoint Object Model.

Features nobody gives a sh*t about

I also found several new features that probably won’t interest a living soul. But because I do want to mention it, I will make a short notice of their presence:

– It will be possible to get more info about crawled contents and status of crawls, programatically.
– Users can now edit a file if it’s exclusively locked by someone else and likely merge it later.
– To get files from BLOB, SharePoint now has streams.
– In the current Client Object Model you would have to add a Form Digest control to be able to talk to SharePoint. In the next version that isn’t necessary anymore, it then can be configured on the ClientContext.

People get lazier every day. I guess it’s some kind of evolution. A few thousand years ago we used to make our own tools. We had to go out into the woods to hunt for a meal,  and with a bit of luck we had a piece of meat at night. Nowadays we drive to work, bang on the keyboard for 8 hours, drive back, and at home a not too scanty meal magically appears on the table. Did we hunt for that? Did we make our own car? Did we make our own PC? Did we even make our own OS? We didn’t even sweat! In the history of mankind someone apparently was smart enough to not kill the caught animal, but let it jump on top of a female of the same kind, and then wait for the beef to spawn on his plate. People get smarter, so they can be lazier. Evolution.

Now back to SharePoint. SharePoint is the perfect platform for the current generation of people. We can find all of our documents, tasks and emails in one place. People even expect one overview for content spread across multiple sites. To achieve this kind of content aggregation, SharePoint 2010 has a few tools available.

In the latest SharePoint eMagazine of the DIWUG (Dutch Information Workers User Group) Brett Lonsdale writes about the multiple tools SharePoint has, that can achieve content aggregation over multiple lists, sites, site collections and even farms. I would really recommend reading the article, but for the lazy (or more evolved) readers, here is a summary.

  • Content by Query Web Part – This is part of the Publishing Infrastructure Feature. It allows you to aggregate content from lists of the entire site collection. This can be done by simple clicking and selecting. This also applies to filtering, grouping and sorting. Out of the box there are multiple styles available, but you can also create your own style by copy and modify a XSL in the Style Library.
    The CQWP is a very powerful tool for content in one site collection. It won’t work with multiple site-collections.
  • Relevant Documents Web Part – This is a very simple web part which doesn’t allow much configuring. You can show your last modified documents, or the documents you created, but it doesn’t get more exciting than that. Oh, and you have to keep in mind that it’s only for the current site, not for the site collection.
  • RSS Feed Web Part – The RSS Feed web part can show the RSS feed of a SharePoint List. If you are using Kerberos you can get the RSS feed of a list in the web part. This is useful across site collections.
  • Data View Web Part – This web part can be found in every SharePoint 2010 version, even foundation. The RSS feed can also be used in this web part. Even more, multiple RSS feeds can be merged, talking about content aggregation. In SharePoint designer there is even more available with this web part. Data sources can be web services, databases, xml, etc.
  • Core Search Results Web Part – This web part is useful when you want to aggregate content of multiple site collections. This can be done by configure a search scope with properties and rules in central admin. One big disadvantage is that the content is as up to date as the latest crawl.
  • Calendar Overlays – In a SharePoint calendar you can get an overlay using the Calendar Overlays button on the ribbon. This function is pretty straightforward.
The Content Query Web Part is a very powerful OOTB tool for content aggregation. If you want even more then use the Data View Web Part in combination with SharePoint Designer.

I have done a few years of sharepoint developing now. When I began to write small webparts in Sharepoint I was very enthusiastic about the features of the Sharepoint framework and thought it was as easy and solid as writing ASP.NET. Now I know better, developing Sharepoint masterpages, webparts, workflows, etc. is not all beer and skitties. Also when you haven’t encountered any troubles yet, you will get to it! So don’t waste your effort on developing the wrong way.

Here are some points of what I consider “Sharepoint 2007 developing and designing: Best practices”


  • Sharepoint Designer is crap. It´s instable and unfinished. So, try to avoid it where possible. Try to use Visual Studio instead.
  • Use Microsofts Visual Studio extensions for WSS. Always use the latest version: CTP, Beta or RC? It all did work for me, so just use it. Here’s a link to the latest version:
  • Always use embedded resources, never copy your images, css or javascripts to a folder in the 12 hive. An article on how to use embedded resources can be found here:
  • Important! Before developing get you’re Functional Requirements straightened out. It is very important to know if you are going to create an application that is going to be updated (frequently) AND/OR needs to work in other environments, for example an ASP.NET environment AND/OR if it needs to be compatible with other/future versions of sharepoint. If it does, and the most cases will be, then mind the following points
    • Try to use the Sharepoint controls in the Microsoft.SharePoint.WebControls namespace as less as possible. Some controls contain some bugs and off course this way you can easily use the same application in an ASP.NET webpage or implement it in another version of Sharepoint.
    • Create a tiered application. Create for every tier a new project. Create a SharepointData project which handles all data between your project and sharepoint, like users, groups, properties, lists, libraries
    • Try to avoid the use of the IWebEditable interface and the EditorPart class. Handle configurations in a second webpart where only an admin can touch it.

Designing (Master pages)

  • Again. SharePoint Designer is crap, but with designing a master page we cannot evade the piece of beta-software Microsoft has shipped with SharePoint. So, good luck with the frustrations.
  • A disadvantage of Sharepoint is that you cannot deploy a masterpage centralized, you have to do a copy-paste job to create the same look on all sites. Fortunately I have a feature for globally deploying masterpages. In a few steps you can build your own feature, it’s very easy. Here is the article:
  • WARNING! NEVER EVER overwrite the default masterpage located at 12TEMPLATEGLOBAL but use it only to copy, it would be wise to make a backup of it.
  • I discourage the use of a minimalistic masterpage.  Use the default sharepoint masterpage located at <%System Drive%>Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TEMPLATEGLOBAL as you’re base masterpage. Generally implementing a new design will take less effort when tweaking the default masterpage, than creating a new one based on a minimalistic base masterpage.

These are the important points that have been in my head for a while, finally they got stored in HTML and are they readable for others. Did I miss something or do you have any tips yourself? I ‘ll be glad to know.

New blog

June 22nd, 2009 | Posted by Jeffrey Paarhuis in SharePoint Talk - (0 Comments)

Hi, I’ve just created this blog. The purpose of this blog is to provide SharePoint solutions. To me it will be an archive, but to you more importantly, it will be a source of SharePoint solutions. I’m a SharePoint developer for one year now, from the very first day  I dove deep into SharePoint building custom forms and web parts. Now I’m developing mostly workflows with custom forms. One major thing I’ve learned programming SharePoint (especially WSS) is that you need a lot of workarounds and tweaks to get your stuff working. That’s also the reason I started this blog, there are solutions for these common obstacles but they cannot (easily) been found on the internet. I definately am no forum poster and I am not going to subscribe to all the forums I found an answer for. So here is one site for these common problems I stumbled upon.