Skip to content

Case – broken export-spweb. (Understanding the solution package version and DeploymentServerType)

July 19, 2016

Another case from the recent customer support work. The customer had a 3rd party solution with a list template, list and a web part which seemed to be created for SharePoint 14 (2010) originally and simply recompiled. (And I cannot change or recompile the sources).


The customer has SharePoint 2013 farm, made of 2 App servers (let us call them APP1 and APP2) and 2 web front ends (WEB1 and WEB2).

APP1 also runs central admin.


Another 3rd party backup solutions the customer is using is doing a granular SharePoint backup (up to document) and internally uses the Export-SPWEB command.


The Export command breaks.

Errors are similar to the ones described here:


Error: Feature ‘d57f4817-f1f9-42aa-863c-139804c731b0’ for list template ‘100’ is not installed in this farm.  The operation could not be completed.


During investigation I have found out the few reasons.


First – the 3rd party solution was installing in the 14 Hive.



The solution files and features were added to the “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\14\TEMPLATE\FEATURES\”  but NOT added to the “C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\FEATURES\”


Apparently the solution was compiled with the 14 compatibility option.




Probably it is not a good idea to go through all servers and copy the files, so to achieve the result we need to tell SharePoint to deploy the solution to both 14 and 15 hives.

Would be simpler if the solution would recompiled with 15 compatibility option, but I could not do it, so I had to run the following command to deploy the solution



Install-SPSolution -Identity <yoursolution.wsp> -AllWebApplications -GacDeployment -CompatibilityLevel {14,15}


This made the files to appear at the 15 hive.

However, the files were only deployed to the WEB1 and WEB2, and the export command were still not working at the APP1 and APP2, despite the fact that it started to work fine at the WEB1 and WEB2.


The customer was really reluctant to run the Export jobs at the Web frontend and thus increasing the load.


To understand why the files did not appear at the APP1 and APP2, let us look at another setting:



So this setting is telling us if the solution will be deployed to web front end or an application server.

But how does SharePoint define which server is the application server?


Well you might assume that it is server role.



For SP2013 it seems that this does not matter.

It seems that the  Sharepoint defines the web front end as a server that runs a “Microsoft Sharepoint Foundation Web Application” service.



If the solution package deployment type is “WebFrontEnd”  – it’s assets are deployed  to the servers that have the “Microsoft Sharepoint Foundation Web Application” on.

So the solution was simple – start the Microsoft Sharepoint Foundation Web Application service on the server? Simple?


One more tricky thing. Starting the service on the server that has a Central Admin – causes the IIS to restart, and thus central admin to restart. So we may encounter the problem. In this case run the command



Get-SPServiceInstance | where {$_.TypeName.Contains('Web Application')} | ft -Property Id,TypeName,Server,Status -Autosize


Find the service instance on the server you want it to run on, and then run the

Start-SPServiceInstance -Identity <guid> command




That is all! the case is solved. So we have fixed the version by installing the solution with the correct compatibility levels and also added a Web Role to the application servers.


Woah woah woah wait a second.


Added a Web Role to the application servers???

Yes, however we did not break the farm topology. These servers APP1 and APP2 HAD the “Microsoft Sharepoint Foundation Web Application” service but were NOT used as Web  Front ends. Simply the load balancer had no idea they do have the IIS and so the requests were not redirected here.

We just solved the problem.






From → Uncategorized

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: