Unable to save site as template “unexpected error has occurred”

Unable to save site as template

Unable to save site as template

User has raised the problem ticket by mentioning facing problem while save site as template, additionally the templates are getting saved in the solution gallery but not able to activate it also.

Error Message

An unexpected error has occurred.
Troubleshoot issues with Microsoft SharePoint Foundation
Correlation ID: acd95f50-4049-4625-9682-aa93aded118f

Troubleshooting

Further debugging in the SP ULS logs and we found some strange facts which are based on event receivers- please refer below

SPSolutionExporter: Microsoft.SharePoint.SPException: Feature definition with Id 77658379-50ff-4e1e-a431-5652bee07a87 failed validation
Looking for ‘ReceiverAssembly’ attribute in manifest root node for solution
Looking for ‘ReceiverClass’ attribute in manifest root node for solution
The ‘Format’ attribute is invalid – The value ‘CheckBoxes’ is invalid according to its datatype

I debug further to find out where the problem. I downloaded the saved wsp’s from /_catalogs/solutions/Forms/AllItems.aspx to my desktop. Renamed it to .cab. Extracted all the contents and found some interesting facts along with manifest.xml file like List Instances, Modules, Property bags, web template. Inside List Instances, I found ElementsFields.xml Once I opened the above xml file, search for the check boxes and found the following

save as template

Further exploration on this, it seems that the checkbox attribute is invalid and needs to be modified.

Resolution

Remove that affected column / remove the affected content type – does not require IISRESET also.

Difference between Site page and Application page

Site Page :

  • Site pages are pages that are created, edited, and customized by end users.
  • They are primarily used for the content in a site.

  • Site pages come in two types—a standard page and a Web Parts page.

  • A standard page contains text, images, Web Parts, and other elements.

  • A Web Parts page contains Web Parts in Web Part zones. They have a predefined layout that uses Web Part zones.

  • Both types of site pages are edited using a Web browser or Microsoft SharePoint Designer.

  • Site pages are provisioned from a template page that is stored on the file system of the front-end Web server. When a site is provisioned, SharePoint Foundation creates a pointer to the instance of the page template on the file system. This allows SharePoint Foundation to avoid repeatedly creating copies of the pages, which are provisioned each time a site is created.

  • When a user customizes a site page, the template for the page is then stored in the content database. The page is retrieved from the content database every time it is requested by a user.

  • A customized page can, however, be reset to the original template page through the Web browser or a tool such as SharePoint Designer.

  • Customized site pages cannot contain in-line server code. The set of controls that are allowed to run on the page is governed by the safe controls list in the <Drive>:inetpubwwwrootwssVirtualDirectories<port number>web.config file.

  • It is a recommended best practice to avoid using server-side code on site pages when developing site definitions. If a user later edits or modifies that page, the code will no longer run.

The following are general rules for using server-side code on a site page.

  • If the page is uncustomized, server-side code is supported on the page.
  • If the page is customized, server-side code does not run, and the page does not render. This includes the code-behind for the page itself.

An administrator can add a PageParserPath setting in the web.config file that allows server-side code to run on pages stored at a specified path. This can be a single, specific page or an entire directory of pages.

Security Note

Adding PageParserPath settings gives anyone who can upload pages to the specified folders the ability to write arbitrary, full-trust code to the server. Administrators should use extreme caution when providing these settings and understand the security implications to this action.

The following sample shows a PageParserPath setting that uses a wildcard. Adding this PageParserPath will allow anyone with permissions to the master page gallery to upload server-side code. Use extreme caution when adding this type of PageParserPath setting.

<SharePoint>
<SafeMode …>
<PageParserPaths>
<PageParserPath VirtualPath=”/_mpg/*” CompilationMode=”Always” AllowServerSideScript=”true” IncludeSubFolders=”true”/>
</PageParserPaths>

Application Pages :

  • Application pages are used to support application implementations in SharePoint Foundation.

  • Application pages are stored on the file system of the front-end Web server in the %ProgramFiles%Common FilesMicrosoft Sharedweb server extensions14TEMPLATELAYOUTS directory and exist for every site in a Web application.

  • This folder is mapped to an Internet Information Services (IIS) virtual directory called _layouts. Every site and subsite will have access to the application pages by using the _layouts virtual directory.

  • For example, http://myserver/_layouts/settings.aspx and http://myserver/subsite/_layouts/settings.aspx access the same application page on the front-end Web server unlike site pages, which are an instance for the specified site.

* Application pages are not subject to the same restrictions as site pages. They allow in-line code without restriction.

* They cannot, however, use dynamic Web Parts or Web Part zones or be modified using SharePoint Designer.

* Modifying the default application pages is not supported in SharePoint Foundation. Custom application pages can be added to a subdirectory inside the _layouts folder.

SharePoint Access Requests: Script to Assign Default Groups

One of the features of SharePoint is the ability for users that need access to a site, and are denied access, through the Request Access process.

To enable or review these settings

  • Go to Settings | Site Settings | User and Permissions and click on Access Request Settings. In the Access Request Settings dialog box, select the check box next to Allow access requests. Then provide an email address of the individual you would like to manage this feature.
  • If a site has multiple groups with the same permission levels (Owners, Members and Viewers) but there is not an assigned default group, then you will see the problem where access requests will either not display for the impacted user or an owner will not be able to approve requests.

Windows PowerShell script to change each of the groups for a site so that each is identified as the default group for Members, Owners and Visitors. You will need to a the Microsoft.SharePoint.PowerShell add-in at the top of the script to get the SharePoint references.

#Members Group
$web = Get-SPWeb "https://sharepoint.contoso.com"
$groupToMakeDefaultMembersGroup = $web.Groups | ? { $_.Name -eq "Team Site Members" }
$web.AssociatedMemberGroup = $groupToMakeDefaultMembersGroup
$web.Update()

#Owners Group
$web = Get-SPWeb "https://sharepoint.contoso.com"
$groupToMakeDefaultOwnersGroup = $web.Groups | ? { $_.Name -eq "Team Site Owners" }
$web.AssociatedOwnerGroup = $groupToMakeDefaultOwnersGroup
$web.Update()

#Visitors Group
$web = Get-SPWeb "https://sharepoint.contoso.com"
$groupToMakeDefaultVisitorsGroup = $web.Groups | ? { $_.Name -eq "Team Site Visitors" }
$web.AssociatedVisitorGroup = $groupToMakeDefaultMembersGroup
$web.Update()

If you turn off the feature, you can re-enable the feature by adding an email address to the RequestAccessEmail property. Hope this helps solving the problem around assigning default groups and enabling the Request Access feature in SharePoint 2013.

#Enable Access Requests after it was disabled
$web.RequestAccessEmail = "user@mydomain.com"
$web.Update()