Office365 SharePoint Online Portability Issues Strike Again
I had another situation today where the portability issues between Office365 and an on premises installation reared its ugly head. This is the reverse situation from the issues I had a while ago trying to move my demo sites from my VM to SharePoint Online.
Last week, I shared a WSP containing some of my demos with my friend Christian Ståhl (@cstahl) at the MVP Summit in Redmond. It was a WSP that I had saved from my SharePoint Online instantiation of my demo sites. When Christian tried to instantiate the solution in his on premises environment, he got the error:
The site template requires that the Feature
{232b3f94-9d6e-4ed6-8d55-04d5a44ac449} be installed in
the farm or site collection.
A little Binglage told me that the 232b3f94-9d6e-4ed6-8d55-04d5a44ac449 GUID represents the HelpCollectionRemoveDefault feature, which is specific to SharePoint Online. (Tip ‘o the beret to Rene Modery @Modery for that tidbit.) Unfortunately, there doesn’t seem to be any way to disable the feature if you actually need to, which might be a bad idea, anyway. That means that a WSP created in SharePoint Online can’t by hydrated on premises by a normal person. (AFAIK, it’s not possible to run PowerShell with SharePoint Online to deactivate the feature.)
The moral of the story seems to be that Office365 saved site templates (WSPs) can be instantiated in Office365 and on premises saved site templates can be instantiated in on premises installations and the twain can rarely meet, at least not easily. As I’ve said quite a few times before, getting this portability thing right is going to be absolutely imperative for a lot of people to want to use Office365, IMO. My guess is that many people may want to move their content to SharePoint Online and back again over time. This is just way too difficult given these feature mismatch issues.
Marc,
Why not just make a blank feature with that ID and deploy to the local farm? When teh WSP activates it, nothing happens, but you won’t be told you require it either.
.b
Bjørn:
That sort of proves my point. You shouldn’t need a developer to do this.
Also, I’m creating the WSP to share with others, who shouldn’t need to add unnecessary features. This is a site with demos from my Developing in SharePoint’s Middle Tier sessions. Remember that I’m a “no code” guy. (Don’t get me started on that.)
M.
Uhm… You need to be a developer to create a file on the server? It’s a matter of right-clicking and choosing Add new folder, then inside that folder, add a text file, name it feature.xml, and paste this:
(?xml version=”1.0″ encoding=”utf-8″?>
(Feature Id=”232b3f94-9d6e-4ed6-8d55-04d5a44ac449″
Title=”Workaround”
Scope=”Site”
Hidden=”True”
xmlns=”http://schemas.microsoft.com/sharepoint/” >
(/Feature>
(Starting parenthesis replaced with start XML tag.)
As for you, if you create a WSP, regardless of method, you can simply rename it to .cab, open it up, make the changes, and remake the WSP using makecab. At most, it’s a 5-minute process.
It’s not about development, it’s about simple commands to work around a very straight-forward requirement: That the target environment has the same features and capabilities as the source environment. It’s a must, you can’t expect to take a component from one platform and reuse it on any other platform, simply because it would be easier. If that were the case, it would kill any third-party products, as ‘anyone’ would be able to share WSP-files created with commercial software and just run it anywhere they wanted.
I’m really not seeing this as a problem.
.b
Put yourself in the shoes of a real user. This is just too complicated and confusing.
I do indeed have to get a developer involved if I want to add a new folder to the server. Do end users have access to the server file system? Do they know what the correlation ID even means? (What’s a correlation ID?)
M.
Well, perhaps ‘real’ users shouldn’t do this task then. If we’re tasking ‘real’ users with migrating solutions from one platform to another, but can’t expect them to be able to understand file operations, then I’m fairly certain we’re on the wrong track.
Consider the following scenario: A user has used Photoshop to create a .PSD file on a laptop. Now, moving that PSD file to another machine, the user is unable to keep editing or opening it, because the target machine lacks the required components.
Should we simply say that “Oh, this is because Photoshop is too difficult to use” or is it a reasonable requirement that the target environment should have the components needed to do the task?
.b
“Uhm… You need to be a developer to create a file on the server? It’s a matter of right-clicking and choosing Add new folder…”
Just for the sake of less experienced folks who may find this post, it’s probably worth noting that as a best practice never, ever, should you be manually creating feature folders and features in the 14 hive of your server. While this process may be acceptable in a personal, development VM, it should never be done in production, and since it doesn’t scale cleanly to environments with multiple web front ends, it’s just a bad habit people shouldn’t get used to doing.
Hi Marc,
i have experienced this problem a couple of times too. Not only with Office 365. You might end up in the same situation if you move web site templates from one farm to another where different features are installed. Don’t happen that much but can happen.
Rene Modery has a script that will fix this situation and i joined him up to create a end user ready solution to this.
You will find his script http://modery.net/powershell-script-office-365-site-template-updater/
greetings
Stefan
OMG! Bit by Microsoft agian!
Along the same lines, I thought I would try something else: Save a template in Office 365 (SP 2010) then try to rehydrate it in Office 365 Beta (SP 2013.) I was able to upload and activate the template, but the custom site was not one my choices to create a new site in SP 2013. Have you had any experience with this?
I haven’t tried this. When we went from 2007 to 2010, the Site Template files (STPs) no longer had context, as we needed WSPs. I wonder if there hasn’t been another change that means that templates saved in 2010 can’t be hydrated in 2013. It would certainly be par for the course. It would mean that you’d have to do an upgrade rather than a hydration.
M.
I got the same problem when tried to create a site in SharePoint 2013 (on-premise) from a site template saved from SharePoint Online. Uploaded the template to SharePoint collection, successfully activated it and… nothing happened – no change in template list!
The issue was in Language settings: on-premise SharePoint was installed in one language (Russian) and the site template was created by SharePoint Online with English locale (primary language in SharePoint Online).
You cannot find any mention of it in export/import dialogs and site template collection. I was just guessing and tried to install English Language Pack for SharePoint – and it worked! When you select English in the Create Site dialog – you see your custom templates, choose another language – they disappear!
So installing Language Pack will solve this Problem. It can be found on MSDN or MVLS and is named Office Server 2013 Language Pack.
You can just change site language in site settings later if you need – nothing happens because there is no other locale in template.