Get Actual Url of Master Page For Specific Page

I needed to know the full url of the actual master page for each page in my SharePoint farm, so I wrote a piece of code that will do all the magic for me: Read html contents from page file, find the master page tag, get the actual master page from master token, then construct the full url string.
Here is the useful section of the code with 2 methods below:

HtmlContent = web.GetFileAsString(PageUrl);
Match MasterMatch = Regex.Match(HtmlContent, "MasterPageFile=\".*.master", RegexOptions.IgnoreCase | RegexOptions.Multiline);

MasterTag = MasterMatch.Groups[0].Value;// Example: "MasterPageFile=\"~masterurl/default.master"
if (!String.IsNullOrEmpty(MasterTag))
{
// remove 'MasterPageFile=\"' portion
MasterPageValue = MasterTag.Remove(0, 16);

MasterPageUrl = getMasterPageUrlFromToken(web, MasterPageValue);
MasterPageFullUrl = getMasterPageFullUrl(web, MasterPageUrl);
}



/// Convert Master Page token to url
private static string getMasterPageUrlFromToken(SPWeb web, string MasterPageToken)
{string Url = String.Empty;
if (MasterPageToken.Equals("~masterurl/default.master", StringComparison.CurrentCultureIgnoreCase))
{
MasterPageToken = web.MasterUrl;
}
else if (MasterPageToken.Equals("~masterurl/custom.master", StringComparison.CurrentCultureIgnoreCase))
{
MasterPageToken = web.CustomMasterUrl;
} else if (MasterPageToken.Equals("~site/default.master", StringComparison.CurrentCultureIgnoreCase))
{// Will use "default.master" file in Web Master pages gallery
MasterPageToken = web.CustomMasterUrl;
}
else if (MasterPageToken.Equals("~sitecollection/default.master", StringComparison.CurrentCultureIgnoreCase))
{// Will use "default.master" file in SiteCollection Master pages gallery                     
MasterPageToken = web.CustomMasterUrl;
}
return (MasterPageToken);
}

  
private static string getMasterPageFullUrl(SPWeb web, string MasterUrl)
{// Input Examples:
// "/sname/_catalogs/masterpage/seattle.master"
// "../_catalogs/masterpage/seattle.master"
// "../../_catalogs/masterpage/default_noimage.master"
// "~site/_catalogs/masterpage/default_copy1.master"
// "sites/Office_Viewing_Service_Cache/_catalogs/masterpage/v4.master"

string FullUrl = String.Empty;
string tempUrl = String.Empty;
if (SPUrlUtility.IsUrlRelative(MasterUrl))
{tempUrl = MasterUrl.Substring(MasterUrl.IndexOf("_catalogs"));
FullUrl = String.Format("{0}/{1}", web.Url, tempUrl);
}
else

FullUrl = MasterUrl;
return (FullUrl);
}

Fixing deploymet error: The feature is not a Farm Level feature and is not found in a Site level defined by the Url

If you have a SharePoint 2013 site that was migrated from SP2010 but the visual upgrade was not performed, then it will be on SP2010 UI mode as you can see in Fig #1 below (unlike the case of a brand new SP2013 or after the visual upgrade as in Fig #2).

Figure #1 -  Sharepoint 2013 with SP2010 UI

Figure #2 – SharePoint 2013 with SP2013 UI

So in SharePoint 2013 site with SP2010 UI mode, if you are deploying a feature (for example a visual web part) through Visual Studio or PowerShell then the following occurs:

• The feature is scoped to "Site", and Activate on Default is set to true.
• Active deployment configuration is default\
• Solution will be added to farm
• Feature will be installed on farm, and feature files will be copied to features folder in 15 hive (\15\TEMPLATE\FEATURES).
• .Dll files will be deployed to GAC or local bin folder
• User controls will be copied to control templates folder in 15 hive (\15\TEMPLATE\CONTROLTEMPLATES).
• Feature is not added to site collection features page.
• Enable-SPFeature command will fail with error message:
  The feature is not a Farm Level feature and is not found in a Site level defined by the Url [Site Collection Url].
• The .webpart file will not be copied to Web Parts Gallery (_catalogs/wp) in target site collection.
• Web part cannot be added to any page.

Solution:

Use CompatibilityLevel parameter in Install-SPSolution PowerShell cmdlet to deploy the solution in either or both 14 & 15 hives:

Install-SPSolution -identity SolutionName.wsp -GACDeployment -CompatibilityLevel{14,15} -WebApplication https://ServerName.Domain.com

Also, you can apply the CompatibilityLevel parameter to Enable-SPFeature cmdlet to activate individual features in either or both hives.

Cannot Edit And Save Documents In Client Program or Open From Explorer SharePoint 2013

The users complain from 2 problems, so let's describe the situation:

Problem 1: Document Edit/Save in client doesn't work

When user clicks on a document link in document library to open in edit mode (through a browser popup or from client program), the client program (for example MS Word) opens the document. However, user will not be able to save back to server, because when he clicks on ‘Save’ button, it will display the ‘Save As’ dialog box where user can only select local destination to save the file. Also, if it was a Microsoft Office document, user can click on File tab and sees that the document is in ‘Read Only mode’ even though he opened it with edit mode.

Problem 2: Open With Explorer doesn't work either!

Here are the environment details:

• This is a fresh SharePoint 2013 installation (Out-of-box)
• Some Web Applications are on port 80 (http) while others are on port 443 (https)
• WFE Servers configurations: Installed Desktop Experience feature on WFE servers, enabled WebClient service to run automatically, library contribute permissions are set correctly. Users tested as site members and as site collection administrator, removed all Office 2013 products from WFE servers including SharePoint Designer 2013.
• Client machine configurations: Office 2010 installed, added site to Trusted Sites zone, installed Add-ons for IE

Errors in logs:

Digging into ULS resulted in finding the following errors for w3wp.exe process:

Failed to get document content data. System.ComponentModel.Win32Exception (0x80004005): Cannot complete this function     at Microsoft.SharePoint.SPSqlClient.GetDocumentContentRow(Int32 rowOrd, Object ospFileStmMgr, SPDocumentBindRequest& dbreq, SPDocumentBindResults& dbres)     cda7da9c-4e98-509a-9976-8129b3f554cb
Could not get DocumentContent row: 0x80004005.
Failure when fetching document. 0x80070012


Root Cause:

Actually this is is really about one thing: the SharePoint WebDav. Both features 'Document Edit/Save'  'Open In Exporer' depend on it.

Document edit mode uses SharePoint WebDav http calls to upload the document back to target location (i.e. Document Library) when document is saved in client program (such as MS Word). 
When user clicks 'Save' button in client program, the client program has to discover if server supports required protocols including WebDav service (this is called Office Protocol Discovery). The client program checks first for cached info (called Office Protocol Discovery Cache) in client machine. This depends if there was a prior successful call to the same resource (i.e. the Doc Library). The cache is a windows registry key: HKEY_CURRENT_USER\Software\Microsoft\Office\[Version]\Common\Internet\Server Cache

If there is no value for the target location folder in that key , then browser will try to initiate an http OPTIONS request to ask for folder info, and will require separate authentication. Otherwise, if there is a sub-key value for the target location folder, then no need to initiate OPTIONS request and automatic logon will proceed automatically. 

When client program initiates an OPTIONS request (and in some cases it needed to initiate PROPFIND requests too), The OPTIONS request is getting rejected. This is because of an IIS settings coming from IIS-lockdown script that disallow the ‘OPTIONS’ http verb from being processed. As a result, SharePoint never received the call for edit and assumes the default Read-Only mode. The client program will get an HTTP 404 (not found error).

Refer to the following useful links for more info:

• http://support.microsoft.com/kb/838028
• http://support.microsoft.com/kb/2019105
• http://sharepointinterface.com/tag/webdav/
• http://blogs.msdn.com/b/javaller/archive/2013/07/30/client-integration-with-sharepoint-2010-gotcha.aspx

 Solution:

IIS must allow the ‘OPTIONS’ http verb to be used.

For a specific web application, check if IIS is blocking ‘OPTIONS’ verb (the ‘Allowed’ value is set to false).  To fix this, remove the ‘OPTIONS’ entry from Request Filtering section in IIS, this will affect web.config file for target web app only. You must do this for all WFE servers where the web applications are available.

The same change can be applied for the entire farm, and this will affect applicationhost.config file.

Now both saving from client and 'Open with Explorer' features work!

Example:

I used Fiddler to show the inner data of what's going on for a sample document inside Shared Documents library: /sites/IIbraheemTestSite/Shared%20Documents/TestDoc.docx

	Before Change	After Change
OPTIONS request	Failed	Succeed
Registry folder sub-key in client machine	No data stored	Data stored

Hope that helps!