SharePoint is complex!  Add in User Profiles and FIM Synchronization with SSL and SharePoint can become a administrator’s worst nightmare.  Our latest “really?” moment recently occurred when MySite (User Profile) details stopped replicated back to Active Directory in our of our installs.

A quick review of recent Events yield the following nuggets:

Event 6801 FIMSynchronization Service

The extensible extension returned an unsupported error.
The stack trace is:
“System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

and

Event 8311, SharePoint Foundation

An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=*.ARMGASYS.COM, OU=Domain Control Validated\nIssuer Name: CN=Go Daddy Secure Certificate Authority – G2, OU=http://certs.godaddy.com/repository/, O=”GoDaddy.com, Inc.”, L=Scottsdale, S=Arizona, C=US\nThumbprint: ABCDEF123456790\n\nErrors:\n\n The root of the certificate chain is not a trusted root authority..

Awesome, yet another SharePoint SSL issue (Only Microsoft Lync is more painful when it comes to SSL)

The Solution:  Add the SSL certificate chain to the SharePoint trust

Step#1: Download the SSL certificate and related chain

1. Open IE and navigate to the SharePoint site in question
2. Click on the padlock and view the certificate for the site
   
3. Click the Certification Path tab
   
4. For each certificate authority listed in the chain, perform the following:
   1. Select the certificate (I.E. Go Daddy Root Certificate Authority – G2)
   2. Click View Certificate.  A new windows for the certificate will be displayed
   3. Click the Details tab
   4. Click Copy to File
   5. This will launch the “Certificate Export Wizard”
   6. Follow the wizard taking all defaults.  Save the .CER file to an accessible location
5. Copy the .CER files to your SharePoint server or a location where you have access to SharePoint Central Administration.
6. Launch SharePoint Central Administration and Navigate to Security –> Manage Trust
7. For each .CER file, perform the following:
   1. Click New on the Manage Trust screen (located in upper left corner)
   2. Give the certificate a usable name
      HINT: We like to include the month and year… just in case (I.E. GODADDY LEVEL 1 CERT MAR2014)
   3. Browse for the .CER file
      
   4. Click OK

 

Happy encrypting!

So there we were, shiny new installs of Office 2013 x64 (with all three colors!) rolled out to our enterprise.  All was good in the world until we received a phone call from operations asking a seemingly simple question:  “Why can’t I see my SharePoint lists in Datasheet view?”. 
What the…???

The Error

The list cannot be displayed in datasheet view for one or more of the following reasons:

 

The Root Cause

SharePoint 2010 (Enterprise or Foundation) lists do not work well with 64bit versions of Microsoft Office.  This applies to both Office 2010 and Office 2013.

 

The Solution

You need to install “2007 Office System Driver: Data Connectivity Components” on each client workstation / PC which have a 64bit version of office installed.  This install will put the necessary Active-X components on your workstations to allow SharePoint Datasheets to be used with 64bit versions of office.
Download the install from Microsoft at http://www.microsoft.com/en-us/download/confirmation.aspx?id=23734

Performing an upgrade to SharePoint 2013 is relatively straight forward, but is not as easy as upgrading, say, Microsoft Office.  There are some considerations which must be taken into account before performing an upgrade.

[EDIT: Upgrading to SharePoint 2016?  Check out our post at http://blog.armgasys.com/?p=550]

Consideration#1: There is no direct upgrade from SharePoint 2007
You can only upgrade from SharePoint 2010 content databases.  If you have a SharePoint 2007 install, please upgrade to 2010 first.  See this blog entry on how to upgrade to 2010.

Consideration #2: There is no in-place upgrade from SharePoint 2010
You must upgrade each content database using the Database Attach and upgrade Method.  This blog entry will cover this method in detail.

Consideration #3: SharePoint 2013 does not directly support classic mode authentication
In our experience, the vast majority of SharePoint 2010 web applications utilize classic mode authentication.  For these content databases, several additional steps are required to prevent loss of security configuration and rights management.  This blog entry will assume the conversion to claims based authentication will take place as part of the upgrade.

OK, Lets dive into the details
IMPORTANT: We strongly recommend reading all of the steps below *before* beginning the migration and upgrade process.  It’ll just make things much easier

Step#0 – Backup everything related to the content database you are migrating
Nuf’ said!

Step#1 – Attach the SharePoint 2010 content database to the new database server.
This step only applies if you are also migrating to a new database server during the SharePoint 2013 migration process. If you are not changing database servers, skip to step#2 as the content database will already be in place and ready to upgrade.

Step#2 – Create a new web application in SharePoint 2013
IMPORTANT: If the original web application used classic mode authentication, you must skip to 2B below.  If the original web application used claims authentication, continue with the steps below.

1. Launch SharePoint 2013 Central Administration web site.
2. Navigate: Application Management –> Manage Web Applications
3. Click New on the ribbon
4. Configure the new web application to replicate the web application being migrated
   NOTE: Take the default for Database Name which is “WSS_Content”

2B – Create a classic authentication mode web application in SharePoint 2013

If the original web application used classic mode authentication, you must use this step in order to preserve all of the security and rights from the original content database.
Additional information on creating classic mode web applications is located here.

1. Launch SharePoint 2013 Management Shell as an administrator
2. Enter the following command

New-SPWebApplication
-Name <Name>
-ApplicationPool <ApplicationPool>
-AuthenticationMethod <WindowsAuthType>
-ApplicationPoolAccount <ApplicationPoolAccount>
-DatabaseName “WSS_Content”
-HostHeader <HostHeaderName>
-Port <Port>
-URL <URL>
[-SecureSocketsLayer]

Where:
<Name> is the name of the web application being migrated
<ApplicationPool> is the name of the application pool assigned to the web application
<WindowsAuthType> is either “NTLM” or “Kerberos”
<ApplicationPoolAccount> is the user account that this application pool will run as
<HostHeaderName> is the host header for the web application
<Port> is the port the web application will be created in IIS
<URL> is the public URL for the web application

NOTE:
-SecureSocketsLayer switch is optional and should only be included if HTTPS/SSL is required.  If you require host headers under SSL, please see this this blog entry.

Example:

New-SPWebApplication
-Name “Contoso Internet Site”
-ApplicationPool “ContosoAppPool”
-AuthenticationMethod “NTLM”
-ApplicationPoolAccount (Get-SPManagedAccount “CONTOSOjdoe”)
-DatabaseName “WSS_Content”
-Port 443 -URL https://www.contoso.com
-SecureSocketsLayer

Step#3 – Delete the content database which was just created in Step#2
Yes, you read correctly, delete the content database.

1. Launch SharePoint 2013 Central Administration web site.
2. Navigate: Application Management –> Manage Content Databases
3. Select the web application created in step#2 from the web application drop down located in the upper right of the browser
4. Click on the Database Name which was created in step#2
   It should be named WSS_Content
5. Scroll to the bottom of the database information page displayed and check the Remove Content Database checkbox
6. Click the OK button

What is happening here?
SharePoint requires a target web application for ALL content databases. Why? Because the web application determines which features are supported and installed for all content hosted by that web application. When the actual migration process occurs, the upgrade software scans the content database for all of the features being used by the content (I.E. lists, document repositories, third party, web parts, etc.) and then determines if the target web application supports that feature.

The problem we encounter is that SharePoint has nicely created an empty content database which we are never going to use because we already HAVE a content database (the one we are migrating). So, we need to perform a little bit of cleanup work.

Step#4 – Validate the SharePoint 2010 content database can be upgraded
SharePoint provides a PowerShell comment which will validate the content database against the web application created in Step#3.

1. Launch SharePoint 2013 Management Shell as an administrator
2. Enter the following command

Test-SPContentDatabase
-Name <DatabaseName>
-WebApplication <URL>

Example:

Test-SPContentDatabase
-Name “WSS_Contoso2010ContentDB”
-WebApplication https://www.contoso.com

Review the output for any issues listed as Upgrade Blocked: Yes
Any issue listed as Upgrade Blocked will need to be corrected.
Google will be your dearest friend if you encounter Upgrade Blocked: Yes

Step#5 – Mount the database onto the web application created in Step#3
This step will upgrade and mount the database against your newly created web application

1. Launch SharePoint 2013 Management Shell as an administrator
2. Enter the following command

Mount-SPContentDatabase
-Name <DatabaseName>
-WebApplication <URL>

Example:

Mount-SPContentDatabase
-Name “WSS_Contoso2010ContentDB”
-WebApplication https://www.contoso.com

Step#6 – Reset and validate!
We recommend executing an IISRESET after each migration / upgrade is completed.
Then launch the SharePoint site to validate everything is running.

 

 

Classic Mode Authentication: Final Thoughts
Classic mode authentication has been officially depreciated by Microsoft.  If you migrated a classic mode authentication based content database, it is strongly recommend you convert the database to claims based using the Convert-SPWebApplication PowerShell command.  Full details are available here.

1. Launch SharePoint 2013 Management Shell as an administrator
2. Enter the following command

Convert-SPWebApplication
-Identity <URL>
-To Claims
-RetainPermissions

Example:

Convert-SPWebApplication
-Identity https://www.contoso.com
-To Claims
-RetainPermissions