Hiding OneDrive from Your SharePoint 2013 Pages

Suppose you don't want your customers, for whatever reasons, to access OneDrive from their SharePoint sites, yet you do want them to use Newsfeed and Sites. What to do?

This problem actually has quite a simple solution. Basically you want to write a script (in JavaScript) that would prevent OneDrive from being displayed. The <a> element that contains a link to <span>OneDrive</span> has an ID that always ends with "_ShellDocuments" (e.g., "ctl00_ctl53_ShellDocuments"), and each link has the "ms-core-suiteLink-a" CSS class. Armed with this theory, you can easily design the solution:

1) Create a new ASP.NET user control.
2) Create a site-collection scoped feature whose elements file refers to this control, e.g.

<Control Id="HideOneDrive" Sequence="10" ControlSrc="~/_controltemplates/15/HideOneDrive.ascx" />

3) Add this to your ASP.NET user control:

<script language="javascript">

    _spBodyOnLoadFunctionNames.push("_doHideOneDrive");

    String.prototype.endsWith = function(suffix) {
        return this.indexOf(suffix, this.length - suffix.length) !== -1;
    };

function _doHideOneDrive() {
        var x = document.getElementsByClassName('ms-core-suiteLink-a');
        var i;
        for (i = 0; i < x.length; i++) {
            if (x[i].id.endsWith("_ShellDocuments")) {
                x[i].style.display = 'none';
            }
        }
    }
<script>

That's it. Newsfeed and Sites stay, but OneDrive is gone.

Editing Managed Metadata Fields in the User Profile

The Problem

You're logged on to your MySite in SharePoint 2013, editing your user profile, when you suddenly notice your inability to edit certain fields. The error message is typically this:


 The Solution

Usually this means that the problem is with the Managed Metadata fields. The first order of business is to make sure that your Managed Metadata Service Application is properly provisioned and the corresponding service is running (in Services on Server.) But suppose that both are running OK (as it was in my case), yet you are still unable to edit the Managed Metadata field. Now, it is time to check the ULS log. There, you’re likely to see this:

Error encountered in background cache check System.Security.SecurityException: Requested registry access is not allowed.   

 at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)   

 at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplication.GetMOSSInstallPath()   

 at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.GetChannel(Uri address, Boolean& cachedChannel)   

 at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.<>c__DisplayClass2f.<RunOnChannel>b__2d()   

 at Microsoft.Office.Server.Security.SecurityContext.RunAsProcess(CodeToRunElevated secureCode)   

 at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.RunOnChannel(CodeToRun codeToRun, Double operationTimeoutFactor)   

 at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.ReadApplicationSettings(Guid rawPartitionId)   

 at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.get_ServiceApplicationSettings()   

 at Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplicationProxy.TimeToCheckForUpdates()   

 at Microsoft.SharePoint.Taxonomy.Internal.TaxonomyCache.CheckForChanges(Boolean enforceUpdate)   

 at Microsoft.SharePoint.Taxonomy.Internal.TaxonomyCache.<LoopForChanges>b__0()  The Zone of the assembly that failed was:  MyComputer.

Basically this means you probably ran some update that screwed up the registry access of the application pool account under which the Managed Metadata service is running.  You will need to run the following command:

Psconfig –cmd secureresources

This does the trick!