Case - broken export-spweb. (Understanding the solution package version and DeploymentServerType)
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 'blalba-guid' for list template '100' is not installed in this farm. The operation could not be completed.
Feature blalba-guid is from the 3rd party solution and it is installed!
During investigation I have found out the few reasons.
First - the 3rd party solution was installing in the 14 Hive.
What?
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.
https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spserverrole.aspx
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 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.
What?
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.