Problem:  People Picker was hanging for about 2 minutes when searching for a user in the Grant Permissions area of the site

Cause:  People picker was not set to search a single forest

Resolution: run the following commands:

stsadm -o setproperty -url http://contoso.test.net -pn peoplepicker-distributionlistsearchdomains -pv corp.contoso.com

stsadm -o setproperty -pn peoplepicker-searchadforests -pv domain:corp.contoso.com -url http://contoso.test.net

Problem: When clicking on the Help links in Central Ad,min

” There is a compatibility range mismatch between the Web server and database "CentralAdmin_Content", and connections to the data have been blocked to due to this incompatibility. This can happen when a content database has not been upgraded to be within the compatibility range of the Web server, or if the database has been upgraded to a higher level than the web server. The Web server and the database must be upgraded to the same version and build level to return to compatibility range.”

Cause: Probably from manually manipulating the WSS_Content_Application_Pools and SharePoint_Shell_Access Database Roles. In this case they were missing

Resolution:

1) create a new SharePoint farm because we are going to need to take a clean, new Central Admin Content database that contains the WSS_Content_Application_Pools and SharePoint_Shell_Access Database Roles

2) Run these scripts:

1. New-SPContentDatabase -Name SP2013_Content_CentralAdmin -WebApplication http://servername:portnumber/
2. Get-SPWebApplication -Identity http://servername:portnumber | Get-SPContentDatabase
3. Get-SPSite -ContentDatabase | Move-SPSite -DestinationDatabase
4. Do an IIS Reset
5. Open the Central Administration web site and navigate to the content databases page to confirm the new database now houses the two site collections (this can be verified too via PowerShell by running command on step 2)
6. Remove-SPContentDatabase -Identity

Steps:
1. Using your documented PowerShell Steps create a new Content Database for the Central Admin Web Application in the new farm and move the existing Central Admin Site Collections to this new Database. Stop at the step where you delete the old Central Admin Content DB.
2. Run the following stsadm command to clean up a couple of orphaned web records left after step 1 (use the Central Admin URL and old Central Admin database name where necessary):
stsadm -o databaserepair -databasename -url -deletecorruption
3. In SQL Management Studio expand the Security section of the original Admin Content database. Remove all Domain\User accounts from Security.
4. Back up the Empty Central Administration Database.

Section2: Move the Resource to the affected Farms
We need to now restore the Empty Central Admin Database from Section1 in all affected farms. During the restore process you can give the database a new name. If you wish to rename the mdf and ldf you may also do this, but will need to take the database offline first.

Steps:
1. Restore the Empty Central Administration Database to one of the affected farms. Complete all renaming of the DB and Database Files at this point.
2. Attach the newly restored database to the Central Administration Web Application (you can use either PowerShell or the UI for this step)
3. Using your documented PowerShell Steps move the Central Administration Site Collection to the database you restored and attached in steps 1 and 2 of this section. Again, do not delete the original Central Admin Content Database. You may also skip the step of creating a new Database as well.
4. From within SQL Management Studio manually add all users from the "old" Central Admin Content Database to the newly restored Central Admin Content Database. Be mindful of the user roles and who the DBO is for the new Central Admin Database.

Problem: When querying a specific term ie "book reports"  via a search web service at url http://server/contentlibrary/_vti_bin/search.asmx they were seeing less than 100 results but when searching via the Search Center it returned 100s of results.

Cause: results from the web site were set to use Stemming, so both plural and nonplural forms of the search were returned. But the web service was NOT using Stemming (aka lemmatizations) so only exact match was returned

Resolution: Enable stemming/lemmatization in the web service queries so that the web service queries will return both plural AND nonplural forms of the search term.

HI everyone,

I will be attending the SharePoint conference next week. For those of you who have been there, I'm sure you'll agree its an amazing experience. This will be my 2nd time attending. I'm looking forward to the many sessions and finally meeting some of you.

For those who are not attending, what do you want to know? List any issues or pressing questions you have about SharePoint 2013 and I will do my best to get the answers.

Talk to you soon!!

Problem: Every time customer would run Upgrade-SPContentDatabase on a specific Content Database it would fail. The database was stuck in a compatibility mode since it could not be upgraded to the build version of the rest of the farm.

Troubleshooting:

• Looked at upgrade logs and found the error 'Field name already exists'. Lucky for us, this content database only has one site collection within it.
• I also noticed something in the logs that referenced a Workflow Content Type
• Used this nifty powershell script to identify the list that has a duplicate field in it. This script will loop through all sites and their tasks lists, then identify which has the problem:
  
  $SiteURL = http://mySitecollection

  param(
  [string]$SiteURL
  )

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") | out-null
$site = new-object Microsoft.SharePoint.SPSite($SiteURL)

#Loop over all webs
foreach($web in $site.AllWebs)
{
 Write-Host "Checking Web: "$web.URL
 
 #Loop over the lists
 foreach($list in $web.Lists)
 {
  #Only continue on Task lists
  if($list.BaseTemplate -eq "Tasks")
  {
   #Loop over content types
   foreach($ct in $list.ContentTypes)
   {
    $isWFCT = $ct.Id.IsChildOf([Microsoft.SharePoint.SPBuiltInContentTypeID]::WorkflowTask)
   
    if($isWFCT -eq $true)
    {
     Write-Host "   Found Workflow Content Type: "
     Write-Host "     List:  "$list.Title
     Write-Host "     CType: "$ct.Name
    
     try
     {
      $field = $list.Fields[[Microsoft.SharePoint.SPBuiltInFieldId]::WorkflowInstanceID]
     }
     catch
     {
      Write-Host "------ERROR WITH WorkflowInstanceID------" -ForegroundColor Red
     }

     try
     {
      $field = $list.Fields[[Microsoft.SharePoint.SPBuiltInFieldId]::GUID]
     }
     catch
     {
      Write-Host "------ERROR WITH GUID------" -ForegroundColor Red
     }

    }
   }
  }
 }
 
 $web.Dispose()
}

• the output looks something like this:

Checking
Web:  http://site1

Checking
Web:  http://site2

   Found Workflow Content Type:

     List:  My Tasks List Items

     CType: Workflow Task

• Now the strange thing was when I went to that list, I did not see any duplicate fields in list settings. But I did see a duplicate reference in their views, in this case, it was the 'Priority' field
  
• customer then made those fields appear in the views to see if there is any data in them. In this case there was not, so they decided to delete one of them.

Cause: This site collection was once a Project Server 2007 site that was migrated to sharePoint 2010. My guess is that this caused some corruption when the site was brought over.

Resolution: Downloaded SharePoint Manager for 2010: http://spm.codeplex.com/downloads/get/526736. This is a great tool that will allow you to view the entire structure (including lists and their fields) of a site in a tree-like structure. You have to install this tool on one of your sharepoint servers. We were able to see the duplicate field that the customer had identified to delete and deleted it via this tool. Re-ran Upgrade-SPContentDatabase successfully.

Fight Comparison: Holyfield vs. George Foreman. Foreman was stubborn, he wouldn't go down. But Holyfield's persistence paid off in the end, just as mine did.