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

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.

Get Inside My Head: Infographic on Millennials

           
           

                Check out our data visualization blog.
           

           
           
           
       

Updating SharePoint 2010 Managed Accounts & SQL Server Passwords

If you need to update the passwords for your managed accounts in SharePoint, you have a few different options. To check out your settings/options, navigate to:

Central Admin -> Security -> Configure Managed Accounts

1. SharePoint can manage the password for you and change it automatically on based certain intervals
2. Update the password directly within Central Admin
3. Change the password of the account in Active Directory first, then update the account's password via Central Admin

Your organization's policies can determine which option you choose. In my experience, most organizations have a separate team of System Administrators who maintain all accounts within Active Directory and enforce password policies there.

Let's say a new password policy is coming out next week. You will need to get ahead of the curve and update all of your passwords prior to the changes taking place, otherwise you are afraid your farm will come to a sudden halt. Your system administrators will be updating the passwords but are nice enough to tell you what they are for each service account SharePoint uses. In order to update the passwords in SharePoint, navigate to:

Central Admin -> Security -> Configure Managed Accounts -> Change Password Now -> Use Existing Password -> Enter the password provided by your System Administrator -> Ensure that Enable Automatic Password Change is NOT checked-> Click Ok

The SQL administrator password needs to change to, but uh-oh, that's not one of SharePoint's managed accounts (nor should it be). Your System Administrators, have just changed the password in Active Directory and have notified you. To update the SQL passwords related to SharePoint you will need to update 2 services. Follow the steps below:

1. Log on as administrator to the SQL Server
2. Click Start and search for Server Manager
3. Expand Configuration-> Services.
4. Find the service called SQL Server (MSSQLSERVER) and right-click -> Properties
5. Log On tab -> Type in new password -> Click OK
6. Select Yes when a dialog box pops up informing you that services will need to be restarted in order for the changes to take effect
7. Right click on the same service and select Stop
8. Right click again and select Start

Follow the same steps above to update the password for the SQL Server Agent (MSSQLSERVER) service as well.

Check your SQL Server's Windows Application Event Logs. If you receive errors, be sure that the SP Timer Service has been restarted on the Web Front End server.

Change the SharePoint 2010 Farm Passphrase

If you need to change your SharePoint 2010 Farm's Passphrase, it's definitely doable. A farm passphrase is created when running PSConfig and when joining new servers to the farm. If you inherit a SharePoint farm from someone else and they have forgotten the passphrase (or they left the company), you can always reset the passphrase. You are going to use SharePoint Management Shell (PowerShell) to make this quick and easy change. Here is what you will enter into PowerShell:

$passphrase = ConvertTo-SecureString -asPlainText -Force

PowerShell will then ask you what the new passphrase is going to be....

Once you have that typed in, you will need to enter another line into PowerShell:

Set-SPPassPhrase -PassPhrase $passphrase -Confirm

You will need to confirm the passphrase you entered before. Click Y to confirm this change. Now your farm's passphrase is updated!

Error When Deleting Search Service Application in SharePoint 2010

Scenario: You attempt to delete your Search Service Application in SharePoint 2010 through Central Admin but the process never completes or takes too long to complete (and does not actually delete the application). You attempt to delete the Search Service Application again through Central Admin but now receive an error.

You then decide PowerShell is next viable option when deleting so you use the following script:

$spapp = Get-SPServiceApplication -Name ""
Remove-SPServiceApplication $spapp -RemoveData

You receive another error and are still unable to delete the Search Service Application.

Fix: STSADM becomes your friend again here. You will first need to grab the GUID for the Search Service Application. You can do this by...

1. Log into the server hosting Central Admin
2. Open SharePoint 2010 Management Shell (PowerShell) as Administrator
3. Enter Get-SPServiceApplication
4. Find the Service Application you wish to delete and copy the GUID (You can do this by right clicking in the PowerShell window -> hitting Select All -> Control + C -> Right Click and Paste into a fresh Notepad document -> copy the GUID from the application you wish to delete)
5. While still in PowerShell, type: stsadm -o deleteconfigurationobject -id *type in GUID here*

This will delete your Search Service Application completely!

Error When Deleting a SharePoint 2010 Web Application

Scenario: You have just created a new Web Application in SharePoint 2010 but realized after hitting the "ok" button that you have mistyped an application pool name or even entered the wrong port number. You try deleting this newly created Web Application through Central Admin and PowerShell but unfortunately receive the following error:

"Unprovisioning (your web application name) already exists under the parent Microsoft.SharePoint.Administration.SPWebService named "". Rename your object or delete the existing object."

Fix: You need to delete the Timer Job Definition called "Unprovisioning Web Application (your web application name)". This is because SharePoint is still trying to delete the Web Application from your unsuccessful steps before. 

To delete this Timer Job Definition, go to Central Admin -> Monitoring -> Review Job Definitions -> Paginate to the Job Definition called "Unprovisioning Web Application (your web application name)". Click on it and select Delete. 

Now you can delete your Web Application successfully.