Thursday, May 30, 2013

Locate Where a Content Type is Being Used on Your Site

I always run into the problem of wanting to delete an old Content Type but receive the error from SharePoint saying that it is "still in use". Instead of wasting time checking where the Content Type is in use for each list or library, just use the PowerShell script below as was posted by "Dave the SharePoint Engineer":

$targetCT = "ENTER CONTENT TYPE NAME HERE"
$targetWebApp = "ENTER YOUR SITE URL HERE"
$webapp = Get-SPWebApplication $targetWebApp
$sites = $webapp.Sites
foreach ($site in $sites)
{
  foreach ($web in $site.AllWebs)
  {
    foreach ($ct in $web.ContentTypes)
    {
       if($ct.Name -eq $targetCT)
       {
          Write-Host $targetCT is defined as a content type in $web.Url
       }
    }
    foreach ($list in $web.Lists)
    {
       foreach ($listct in $list.ContentTypes)
       {
         if($listct.Name -eq $targetCT)
         {
            Write-Host $targetCT is defined in list $list in $web.Url
         }
       }
    }
    Write-Host
  }
}

Note: If you still cannot delete the Content Type, be sure to check your Recycle Bin for any remaining items which may be attached to that Content Type. Be sure to delete items from the End User Recycle Bin as well as the Site Collection Recycle Bin.

*Credit Shall Be Awarded To: http://blogs.msdn.com/b/david/archive/2011/08/25/powershell-script-to-locate-content-type-useage.aspx

Tuesday, April 23, 2013

Correlation ID Error on Web Parts Using a Data Connection

Issue: Users are navigating to a SharePoint 2010 web page where a web part is displaying a Correlation ID error. There error states:

"Unable to display this Web Part. To troubleshoot this problem, open this Web page in a Microsoft SharePoint Foundation compatable HTML editor such as SharePoint Designer..."

Only some users see the Correlation ID error while some see the actual web part data. The web part on the page was created in SharePoint Designer using a data connection. You have a SharePoint 2010 farm which contains Network Load Balancing (NLB).

Troubleshooting/Symptoms: Users are hitting different Web Front Ends (WFEs) when accessing the page while NLB is enabled on your farm. (NLB distributes network traffic to each WFE.) In order to figure out which WFE users are hitting, try this trick. Users hitting a certain WFE (for example WFE1) see the web part information clearly, while others hitting another WFE (for example WFE2) are receiving the Correlation ID error. Using the ULS Viewer on WFE2, search for the Correlation ID error a user receives. It happens to display this error:

"Error while executing web part: System.Net.WebException: The remote server returned an error: (401) Unauthorized."

WFE1 has Loopback Checking disabled, while WFE2 has Loopback Checking enabled. Only users accessing the SharePoint web page through WFE2 are receiving the correlation ID error.

Explanation of Fix: The reason this occurs is because the NLB is referencing the Fully Qualified Domain Name (FQDN) of each WFE. For security purposes, the default setting is to have Loopback Checking enabled so as to prevent reflection attacks on the server. The NLB could access WFE1 without an issue which is why users getting to the SharePoint page through that server did not have a problem seeing the web part data. Users accessing the page through WFE2 though, will receive a Correlation ID Error (which is actually a "401 Unauthorized" error) upon postback because of the Loopback Checking issue. The fix is to disable Loopback Checking on WFE2 so that the NLB can reference the server without encountering a problem and therefore display the web part data for users who happen to be hitting it.

To set the DisableLoopbackCheck registry key, follow these steps:
  1. Click Start, click Run, type regedit, and then click OK.
  2. In Registry Editor, locate and then click the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  3. Right-click Lsa, point to New, and then click DWORD Value.
  4. Type DisableLoopbackCheck, and then press ENTER.
  5. Right-click DisableLoopbackCheck, and then click Modify.
  6. In the Value data box, type 1, and then click OK.

Note: I know there is a lot of talk about this regarding the better way of ensuring a secure environment relating to this functionality. Microsoft does state the preferred method is to specify host names as opposed to disabling loopback checking. It's up to you, but here is a great blog post on it.