SharePoint Explorer 365

UPDATE: Newer version of the tool now available here.

Ever wanted to see what is happening under the UI in your SharePoint Online (Office 365) environment? Read on for a download link to a tool that may come in handy...

I recently came across Stefan Stanev's very useful SharePoint Explorer, which is a bit like the SharePoint Manager tool that many SharePoint developers would be familiar with. The key difference with SharePoint Explorer is that it uses the .NET Client Object Model to connect to SharePoint, so it can run on any machine with connectivity to your SharePoint environment!

The Client OM is available in SharePoint Online, but one major difference is the authentication system which I have been playing around with recently for some project work. It's not too difficult to shoe-horn the MSDN sample code for authenticating into SharePoint Online into the source code for SharePoint Explorer (which Stefan has graciously shared with the SharePoint community). Now we can get a quick and easy view of object properties which are generally hidden from view.

Disclaimer:
This tool is best used for examining the state of SharePoint objects and making quick development changes in non-production environments. As always, be careful! Although it is restricted by the boundaries of the Client OM, this tool has enough power to turn your site collection into a nasty state of affairs (e.g. if you ask it to delete your root web, it will comply and then your site will be completely broken). With this in mind:

• Don't log in with higher privileges than you absolutely need;
• Don't log in to production if you can avoid it;
• Don't make any updates (especially in production) if you can avoid it;
• Don't use it as a short cut for proper deployment methodologies; and
• Use at your own risk!

OK, so now you've gotten past the disclaimer, here's the download for the Office 365 version of SharePoint Explorer.

When you connect (see below), there is an option to specify whether you are connecting to a SharePoint Online environment. If you are, the remaining authentication details are ignored and the code provides you with a login screen into Office 365. If the current user has an active cookies from recently logging in to Office 365 in Internet Explorer, then the tool will reuse the cookie so no additional login is required.

See Stefan's blog post entry for detail on how the tool works once you're connected. Massive thanks to him  for making the SharePoint Explorer source code available!

Specifying to connect to a SharePoint Online site on Office 365

The login form you will use if you don't already have an active cookie available for the tool to reuse

The tool in action

Let me know how you go with the tool, I've found it quite handy to track down and delete orphaned hidden Taxonomy columns created by SharePoint whilst testing my content type provisioning feature. Much faster than having to write sandbox code or custom Client OM code!

SharePoint Saturday Perth - Customising SharePoint Online Resources

Hi all,

Here are the resources referenced in my SharePoint Saturday Perth presentation on Customising SharePoint Online:

SharePoint Online Restrictions:
http://msdn.microsoft.com/en-us/library/gg615454.aspx

Sandbox Logging:
http://spsl.codeplex.com 

Client Object Model Authentication:

http://www.wictorwilen.se/Post/How-to-do-active-authentication-to-Office-365-and-SharePoint-Online.aspx

Free 30-day trial Office 365 tenancy:

http://www.microsoft.com/en-us/office365/free-office365-trial.aspx

Office 365 Service Descriptions:

http://www.microsoft.com/download/en/details.aspx?id=13602

Office 365 Developer Training Course :

http://msdn.microsoft.com/en-us/hh181605

SharePoint Online Developer Resource Centre :

http://msdn.microsoft.com/en-us/sharepoint/gg153540.aspx

Thanks to Brian and all the SharePoint Saturday Perth sponsors, presenters and attendees!

Feature Stapling in SharePoint Online (Office 365)

I've been working with sandbox solutions lately and I've come across something rather unexpected: it looks like you can't use feature stapling (the FeatureSiteTemplateAssociation element) in the cloud.

I created a sandbox version of the branding solution I've used a few times in the past to apply a custom master page and some custom CSS to a site. The sandbox version of the solution contains a site collection scoped feature that staples a web scoped feature to a wide range of SharePoint site definitions. This works as expected in my on-premises development environment: when the site collection feature is active, newly created sites have the custom web feature already activated.

However, when I apply the exact same sandbox solution to my SharePoint Online tenancy, the feature stapling doesn't seem to apply. Everything else works except for the stapling. The only information I have been able to find is this link on the Office 365 community site where a Microsoft support team member seems to indicate that feature stapling isn't available in SharePoint Online.

So it seems that for now we'll need to find alternative ways to automatically customise newly created SharePoint Online sites. I'm interested to hear if anyone else has any more info on this or perhaps has found a way to get feature stapling working in Office 365.

Update:
I've just checked the site definition being used for my SharePoint Online site - I had a suspicion that perhaps Online uses slightly different site definitions because this would explain why the feature stapling wasn't being applied. However, the WebTemplate and WebTemplateId properties are both identical in my SharePoint Online site and my on-premises site. So this doesn't explain the difference in behaviour between the two environments.

I've also tried using the GLOBAL value for TemplateName which should staple to all site definitions (except where the AllowGlobalFeatureAssociations property is false), and I still don't see any feature stapling.

Why is my document forgetting its content type?

Background:
For our MOSS project we had a series of document libraries that used custom content types, each with its own document template. For ease of maintenance and administration, we placed all of these document templates into a common document library.

Issue:
Users would go to their document library, click the New dropdown and select the appropriate content type. This would open up the template in Word as expected. Users would then save their document and set the properties.

However, when users then navigated to the document library, they found that their document didn't retain the content type that they originally selected from the dropdown. The document had somehow 'converted' to the default content type for that library. Why?

Discussion:
The key is SharePoint's property promotion and demotion. All a document's properties including the name and ID of its content type are stored within the document as well as in the document library. You can see this by renaming a .docx file to a .zip file and examining the contents.

Whenever a document in a document library is modified, either via its contents or its document library properties, SharePoint detects this change and synchronises the properties. So, if the property value is changed in the document, SharePoint 'promotes' that change into the document library column to match, and if the document library column is changed, SharePoint 'demotes' that change into the document contents. This is most visible in the Document Information Panel or when your documents contain Quick Parts.

How is this relevant? Our template documents were all stored in a central document library, and when we created this initially we didn't allow content type management because it wasn't considered necessary. Hence the document library internally used only the SharePoint default Document content type (which has the ID 0x0101). So, the instant we placed our document templates into this library, SharePoint converted the documents from our custom content types into Document. It also updated the internal contents of these document templates - via property demotion - to reflect that fact.

When users created new documents from these templates and saved them into a document library, the internal information stored within the template was retained, and SharePoint recognised that the documents were actually of the Document content type. It then promoted that information into the document properties at the document library level, overriding the selection made by the user from the New dropdown! Because of the way our custom content types and libraries operated, our document libraries didn't have the Document content type enabled. SharePoint couldn't match the content types accurately and (fairly sensibly) just went with the default content type for the library.

Solution:
We needed a way to make sure that the content type information was always preserved for our custom content types, so we enabled content type management for the document library containing the templates. We then ensured that each template was an instance of the content type for which it was the template. Then, there was no conflicting content type information to confuse SharePoint and the entire process worked perfectly.

Summary:
The key is that if you're going to store content type templates in SharePoint, make them instances of their respective content type. This is easy enough but it has a few implications:

• It will be difficult to reliably reuse a template across multiple content types
• If you're reusing content types across multiple site collections, make sure your content type IDs match - the SP2010 content type hub is useful in this case

SharePoint's property promotion is a pretty amazing thing, but it can edit your documents in ways you're not expecting - I've even seen it conflict with custom event receivers! When troubleshooting unexpected document metadata issues, remember that the process is always there, synchronising silently in the shadows...