What to do when a User Profile is out of sync with Active Directory

Frequently I will get a report from a user that a user profile is out of sync or doesnt display correct information.

The first thing I do is query AD to make sure that it contains the correct information.  If AD is correct but the SharePoint User Profile is incorrect, you can try to force a full synchronization.  But if this is not successful, here are a couple other things you can try:

1) Use PowerShell Cmdlet to force a sync with AD
Set-SPUser –Identity <domain>\<username> –SyncFromAD –Web http://<webapp>

2) Manually delete and immediately re-add the profile in Central Administration.  This will force the profile service to query AD and populate with the correct information. There are no worries to delete the profile in UPS, because it wont delete the user from any site collections or lose any metadata.  It will simply re-build their profile.

3) If all else fails, you will need to remove the user from SharePoint Site Collection and re-add them.  Please keep in mind that this will remove them from any security groups they may have been added to.  All original permissions will be lost and you will need to re-add them to each of these groups and sites manually.  Use this step with EXTREME caution.

For this, navigate to the User Information List by adding "_layouts/people.aspx?MembershipGroupId=0" to the end of your site collection URL.  Select the user you wish to remove, and click Delete User from Site Collection.

Create web applications that use classic mode authentication in SharePoint 2013

In SharePoint 2013 Central Administration, you can only configure claims-based authentication when you manage web applications.  If you are migrating from a SharePoint 2010 environment where classic-mode authentication is being used, you will need to first create a classic-mode web application in SharePoint 2013, migrate all content, and then upgrade to Claims-Based, to take advantage of server-to-server authentication and app authentication as well as Office Web Apps.

Using SharePoint 2013 Management Shell with an account that has proper permissions to SQL and the farm, use this cmdlet:

New-SPWebApplication -Name "NewWebApp" -ApplicationPool "NewWebApp1.AP" -AuthenticationMethod "NTLM" -ApplicationPoolAccount (Get-SPManagedAccount "webappserviceacct") -Port 443 -Url "https://url.domain.com" -SecureSocketsLayer -DatabaseName "WSS_Content_WebApp_Root"

For more information, visit: http://technet.microsoft.com/en-us/library/gg276326.aspx

Announcing the release of Service Pack 1 for Office 2013 and SharePoint 2013

It's official! Microsoft has released SP1 for Office 2013 and SharePoint 2013.  More details can be found here: http://blogs.technet.com/b/office_sustained_engineering/archive/2014/02/25/announcing-the-release-of-service-pack-1-for-office-2013-and-sharepoint-2013.aspx

Enjoy!

Collapsing Multiple SharePoint 2010 Web applications into a single SharePoint 2013 Web application using Host-Named Site Collections

At a client site, I was tasked to migrate a SharePoint 2010 farm from antiquated physical hardware to a new SharePoint 2013 farm in a virtual environment.  In the existing SharePoint 2010 farm, there are several web applications separating different projects.  This was done to isolate them from each other and provide more granular security.  As we should all know by now, Microsoft's best practices within SharePoint 2013  is to use less web applications (limit of 20 web applications per farm) and implement host-named site collections to create multiple "zones" or to use unique URL headers.  Side Note: If you want to learn more about Software boundaries and limits for SharePoint 2013 , visit: http://technet.microsoft.com/en-us/library/cc262787.aspx).

So began my effort to collapse multiple web applications from a SharePoint 2010 farm into a single web application in a new SharePoint 2013 farm.

Step 1: Identify possible duplicate URLs
The first step is to identify all of the sites within an existing web application to see if any of them have identical URL paths.  For instance there may be a site "/sites/sitecollection1" and in both web applications. I like this little PowerShell cmdlt and use it quite frequently to see how our site collections are growing on a monthly/annual basis:

Get-SPWebApplication https://url.domain.com | Get-SPSite -Limit All | Get-SPWeb -Limit All | Select Title, URL, ID, ParentWebID | Export-CSV C:\filename.csv -NoTypeInformation

Step 2: Create Web Application
The next step is to create a new web application (if one doesn't already exist in the new farm).  Depending on your authentication method, you can either use Central Administration (claims-based) or PowerShell (classic-mode).  In our case, I needed to create the web application in classic mode and then convert it to claims after everything has been moved over.  This was due to the fact that we were using Office Web Apps which requires claims-based authentication.  Here is the cmdlet used to create the web application in classic-mode:



New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -AuthenticationMethod <WindowsAuthType> -ApplicationPoolAccount <ApplicationPoolAccount> -Port <Port> -URL <URL>

Side Note: For more information about classic-mode authentication, visit: http://technet.microsoft.com/en-us/library/gg276326.aspx

Step 3: Create Empty Root Site Collection
Next, we need to create the top-level site collection.  This is a requirement for any new Web Application.  Also, this will be the only site collection that shows up in the content source.  Even though all other host-named site collections do not appear, by default search will automatically crawl them.


New-SPSite 'http://<servername>' -Name 'Portal' -Description 'Portal on root' -OwnerAlias 'domain\administrator' -language 1033 -Template 'STS#0'

Step 4: Create Host-Named Site Collections

You must use PowerShell to create a host-named site collection, although you can manage it with Central Administration after it has been created.

New-SPSite 'http://portal.domain.com' -HostHeaderWebApplication 'http://<servername>’ -Name 'Portal' -Description 'Customer root' -OwnerAlias 'domain\administrator' -language 1033 -Template 'STS#0'

Step 5: Migrate existing SharePoint 2010 Content Databases to new Host-Named Site Collections
In the interest of staying on topic, I have skipped the steps that include attaching the content database(s), running the pre-upgrade check and testing the spcontent database.  for more information on upgrading SharePoint 2010 databases to 2013, visit this site: http://technet.microsoft.com/en-us/library/cc303436.aspx

Restore-SPSite -Identity <SiteCollectionURL> -Path <Backup file> [-DatabaseServer <DatabaseServerName>] [-DatabaseName <ContentDatabaseName>] [-HostHeader <Host header>] [-Force] [-GradualDelete] [-Verbose]

Side Note from Author: Due to an unexpected time crunch, I decided to not collapse the web applications as part of the migration.  I was hoping to be able to provide additional lessons learned and more information from actual experience, but unfortunately this is as far as I got in the production environment.  Regardless, I wanted to document a few of these steps in case we decide to revisit this again in the future or on another contract.

Avoiding The Pitfalls of Installing and Configuring a SharePoint 2013 farm on Windows Server 2012 R2 - Part 1

Avoiding The Pitfalls of Installing and Configuring a SharePoint 2013 farm on Windows Server 2012 R2 - Part 1

There are several sources online that can assist with a new SharePoint installation, however until SP1 is released, Microsoft is not supporting installation on Windows Server 2012 R2.  I have captured my lessons learned through an actual production installation that will hopefully prevent many of you the frustrations and headaches I've experienced throughout this process.  I have focused more on the initial setup errors because getting over this hurdle is 90% of the effort.  After this, everything is just a straight forward installation and tailored configuration to your environment that I'll put into PART TWO of this blog.

I will assume you already have Windows 2012 R2 installed and a functioning Active Directory structure.  I will not go into planning or architecture, but we'll agree that this installation/configuration will be done for a multi-tier (3) farm.  I will also not address installing/configuring SQL Server in this blog (see my other blog post titled: Installing SQL Server for SharePoint 2013 - coming soon)

STEP ONE - Setting up Initial Service Accounts

The following service accounts are (at a minimum) needed for installing SharePoint bits:

Setup & Install Account

• This account must be a domain account and is used to install and configure SharePoint 
• This account must be member of Local Administrators Group on the server 
• This account must be assigned “dbcreator” and “securityadmin” server roles on SQL Server

Farm Account 

• This account must be a domain account and is used to access databases and administering 
• All the permissions required for this account will be automatically granted after completing SharePoint Farm SharePoint Farm Configuration Wizard

In the next part of this blog, I will address additional service accounts that will be needed for further configuration and customization of SharePoint 2013.

STEP TWO - Adding Server Roles & Features

If you have an Internet connection, use these cmdlets to add the necessary server roles and features for front-end web servers and application servers in the farm.

(estimated time: 30-45 minutes per server)

Online method (as described in http://support.microsoft.com/kb/2765260): 

Open an elevated Windows PowerShell prompt on the SharePoint server (that is, Run as Administrator), and execute the following commands:

Import-Module ServerManager

Add-WindowsFeature NET-WCF-HTTP-Activation45,NET-WCF-TCP-Activation45,NET-WCF-Pipe-Activation45

Add-WindowsFeature Net-Framework-Features,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering,Web-Digest-Auth,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,Application-Server,AS-Web-Support,AS-TCP-Port-Sharing,AS-WAS-Support, AS-HTTP-Activation,AS-TCP-Activation,AS-Named-Pipes,AS-Net-Framework,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-APIs,Web-Lgcy-Scripting,Windows-Identity-Foundation,Server-Media-Foundation,Xps-Viewer -source d:\sources\sxs

The reason I recommend using PowerShell in this instance is because when you use the PrerequisiteInstaller.exe, it will execute this Windows PowerShell code to install the Roles and Features to configure Windows Server 2012 for SharePoint 2013. Part of the Windows PowerShell code for Add-WindowsFeature installation installs the Windows NET-Framework-Core feature that is the Microsoft .NET Framework 3.5. This feature installation requires binaries and other files that are not included in a default installation of Windows Server 2012. because of this, you may get an error using the GUI and will need to point to the installation source files Windows 2012 R2.

Note:
If the server does not have an Internet connection, the PrerequisiteInstaller.exe cannot continue past the "Configuring Application Server Role, Web Server (IIS Role)" phase, and you may receive the following error message:

The 0x800F0906 error code indicates that the computer cannot download the required files from Windows Update.  In Windows Server 2012 and Windows 8, the .NET Framework 3.5 is a Feature on Demand. The metadata for Features on Demand are included in Windows Server 2012 and in Windows 8. However, the binaries and other files that are associated with the feature are not included. When you enable this feature, Windows tries to contact Windows Update to download the missing information to install the feature.  The network configuration and how computers are configured to install updates in the environment can affect this process. Therefore, you may encounter errors when you first install such features. 

For more information about error codes that may occur when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012, see the following Microsoft Knowledge Base article:
2734782 Error codes when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012

STEP THREE - Install the Prerequisites

Normally just running the PrerequisitesInstaller.exe will work, however in our environment, we had the servers configured to use WSUS instead of Windows Update, so I was getting the following error:SharePoint 2013 Pre requisites install fail, Error: The tool was unable to install Application Server Role, Web Server (IIS) Role.  This is more or less the same error you will receive in the previous section, except for a different (but same) reason.

If you come across this issue, there are 2 ways to solve the issue.  If it's an issue with connecting to Windows Update, you may need to set the following Local Policy:

1. Windows Start


2. Run MMC

3. Click File, Add/Remove Snap-in…

4. Select Group Policy Object Editor and ADD it

5. Navigate to Administrative templates / System

6. Select and edit “Specify Settings for optional component installation and component repair”
Enable and select “Contact Windows Update directly to download repair content instead of Windows Server Update Services (WSUS)”

7. Re run the prerequisite installation

If this still doesnt work, your only other option is to manually install the prerequisites:

1. Download all prerequisites from the Internet and save it on local disk of the server, e.g. C:\SP2013Prereqs

SQL Server 2008 R2 SP1 Native Client
Microsoft WCF Data Services 5.0
Microsoft Information Protection and Control Client (MSIPC)
Microsoft Sync Framework Runtime v1.0 SP1 (x64)
Windows Identity Extensions
Windows Server AppFabric
CU 1 for AppFabric 1.1 (KB2671763)

2. Install all prerequisites directly from the prerequisites folder in the download sequence, EXCEPT AppFabric and CU 1 for AppFabric.

3. AppFabric requires special configuration using following statement from command line:WindowsServerAppFabricSetup_x64.exe /i CacheClient","CachingService","CacheAdmin /gac

4. Install AppFabric1.1-RTM-KB2671763-x64-ENU

5. Restart your server

At this point, you should be able to install the SharePoint Server 2013 bits on all web-front ends and application servers without any errors.


(see my next blog post titled: Avoiding The Pitfalls of Installing and Configuring a SharePoint 2013 farm on Windows Server 2012 R2 - Part 2 - coming soon)

Underscores: SharePoint 2010 Search Worst Enemy or Just a Lesson in Futility

This is a really interesting topic.  I'm hoping that I get some feedback on this blog post based on others experience with SharePoint Search.

At a customer site, we have been troubleshooting a search problem where users were not getting any search results from within a site or a list/library, even when you could clearly see the name of the document contained within it.  We are confident that the Search Service is properly configured (because it is working fine on other sites within the farm) and we confirmed that it is running regular incremental crawls.

The more we dug into the issue, we discovered that it appeared that it had something to do with underscores in the name.  It was quickly apparent that any file under a folder that had an underscore, would not show up in the search results.  This made us question how Microsoft designed their search (why would names with underscores be ruled out?), so we created two test site collections (one created with an underscore in the site name and a second without) so we could test out the search in the following 3 scenarios:

1. Create a Document Library with an underscore in the name (underscore_library)
2. Create a Document Library with no underscore (regularlibrary)
3. Create a Document Library with a space in the name (space library)

Within each of those document libraries, we created 3 folders:

1. Folder with an underscore in the name (underscore_folder)
2. Folder with no underscore (folder1)
3. Folder with a space in the name (space folder)

And within each of those folders, we created two test documents:

1. Document with an underscore in the name (document_1)
2. Document with no underscore (document1)

We then ran a full crawl and searched at the site level for a keyword contained within the document.

Wouldn't you know... all our search results showed up?  But we thought it was a problem with the underscores, how could this be???

Ok, we thought, maybe it's one of those things that just needs to get kicked once in a while.. you know... Have you tried turning it OFF and back ON again?

So we decided to run a full crawl on the content source for the user's sites and just like that, all search results then showed up!  I was both elated and disappointed at the same time.  I was happy because the user's search results were now being displayed (and we could mark this ticket closed).. but I was disappointed because this blog post that I had been writing (and the effort to create test site collections) was for naught.

Even though this did the trick for the issue at hand, the question then becomes, what event or change happened to the site and/or the content that would cause it to not get picked up in the incremental?  We did experience a SAN crash last year (after this data was originally created) and this caused us to have corrupted databases that needed to be repaired, but we were not sure this was the reason these files were not getting picked up by the index.  We were at a loss, but I guess sometimes you just have to accept that a "reboot" will often times fix weird Microsoft problems like this and just move on.  No sense burning off a bunch of brain cells to figure every little thing out.  It works - you're a hero - now move along.

I'm always open to ideas, suggestions or perhaps your own experience with similar funky search issues like this one.  I decided to still post this to hopefully remind everyone that sometimes the best solution is the easiest.

If you want to learn more about planning for crawling and federation in SharePoint 2010, we referred to this technet article: http://technet.microsoft.com/en-us/library/cc262926.aspx

Until next time... stay thirsty my friends!

SharePoint 2010 Search Issue: No Search Results for Users in a One-way Trust Domain Scenario

I just wanted to write a quick blog post about an issue we experienced this week in our enterprise SharePoint 2010 environment while it was still fresh in my head.

Even though our search service is configured properly and successfully crawling all the necessary content sources, we were getting complaints from our end-users that they were not getting any search results.  I could performed the same search query they were on the same site and I would get all the results.  So why is this happening?

Well, this is the point in time where all good SharePoint admins reach in their toolbox and pull out the biggest hammer they can find.  That's right, we did a Google search (or Bing if you're not into the whole brevity thing).

Anyway, we stumbled on THIS blog from Matt Stratton dated June 1, 2010.  He explains how to configure SharePoint 2010 Search in a one-way trust scenario.  This described our environment to a "T".

So we dug a  little more.... Then we found this article: http://support.microsoft.com/kb/2344518

EUREKA!

Once we ran the script and performed a full crawl, these users tested their sites again and search was working correctly.  They received results from their site search and everyone in the kingdom was happy.

The End!