Setting up Yammer with On Premise SharePoint 2013 Start To Finish

I went through and did an entire setup for on premise SharePoint 2013 and how to integrate Yammer using the app in the SharePoint Store. This covers all the prerequisites such as setting up the service applications, configuring DNS, and then goes over the changes that must be made in SharePoint to replace SharePoint social features with Yammer features. Check it out:


Creating New Configuration Database Error “Cannot connect to database master at SQL server”

I just spun up a clean SharePoint 2013 (w/ March 2013 PU) VM and went to go create my configuration database only to be greeted by the error: “Cannot connect to database master at SQL server <SQLServerName>.

new config db error

I forgot one quick setting in SQL Server Configuration Manager. Enable TCP/IP under SQL Server Network Configuration > Protocols for MSSQLSERVER.

SQL Config Settings

Long Server Name Causing App Fabric Service to Crash

After a fresh installation of SharePoint 2013 I started noticing this error a lot in the ULS logs: “Unexpected Exception in SPDistributedCachePointerWrapper::InitializeDataCacheFactory for usage ‘DistributedViewStateCache’.” This error is related to the SharePoint service Distributed Cache, which is also related to the Windows service ‘App Fabric Caching Service’. I took a look at the services mmc snap-in and noticed that the windows service was stopped (The SharePoint service was started). I tried to start the service and it immediately stopped (and reported a faulting .dll error in the eventvwr application log). After some research I found some PowerShell that let me view the health of the “cache cluster.” Running the start-cachecluster cmdlet showed that the service was indeed down, and it also showed me that the HostName was shortened. The server name is 17 characters and it appears that this service doesn’t like the shortened HostName (Shortened after 15 characters).


I ran the following command to export the cache configuration:

And then changed the following line in the config (Added the missing characters): cacheHostName=”AppFabricCachingService” name=”SPDEV13LongServer”

And finally imported the edited config:

After importing the new configuration I confirmed that the host was the actual server name by running get-cachehost. After that I ran restart-cachecluster so the server could be added.


After I got the Windows Service healthy, I re-provisioned the Distributed Cache service in SharePoint:

I ran into this (along with some other interesting items) since the server name was over 15 characters so I would definitely recommend a server name less than the 15 character limit for NETBIOS names.

Some other things I learned from this:

  1. Always make sure that these 2 commands match up or else the User Profile Sync service will not start:

  2. If AppFabric gets uninstalled in a SharePoint farm, you must use the Prerequisites installer to reinstall WindowsServerAppFabricSetup_x64.exe. If the install does not work (Giving you a 1603 error code), look at the PSModulePath environmental variable. In my case SQL Server had added a quotation mark at the end of its path, which caused the installer to fail.
  3. The Distributed Cache being stopped could result in partial data loss and could cause some other issues around the farm such as giving errors when a site administrator goes to create a new subsite.

SharePoint 2013 App Environment Configuration

After working through a few issues with the App Management Service Application I figured I should blog my findings. The App Management service actually needs another service application created before it’ll work properly: The Subscription Settings Service Application (See here for instructions on setting it up – It can only be configured with PowerShell:

After setting up this Service Application the “Microsoft SharePoint Foundation Subscription Settings Service” needs to be started in order for Apps to work. In 2010 this was only for multi-tenant installations, but there is now a dependency for apps.

After setting up the appropriate services you need to configure a generic web application that has a blank host header and listens on port 80. Because of how the redirect for the app domain works IIS will try to resolve the app URL by using the default IIS web site, which of course doesn’t work. This appears to be fixed in the March 2013 Public Update  (

One gotcha here is that if the NETBIOS name of the server is longer than 15 characters make sure that the generic web application is equivalent to this. Do not go in and change the URL to the full server name as this causes issues!

Here’s a quick checklist to go through when setting up the App Environment:

  1. Create a fwd lookup zone for apps (
  2. Create a CNAME alias from app domain to SharePoint Domain
  3. OPTIONAL: Wildcard SSL Cert for app domain
    1. Note: If you have a wildcard certificate for *, you would need to purchase another wildcard certificate for * if you are using a subdomain as your app domain. Microsoft highly recommends that you create a new domain name for apps.
  4. Create the Subscription Settings Service Application using PowerShell ONLY
  5. Start the Microsoft SharePoint Foundation Subscription Settings Service
  6. Configure the App Management Service Application (Central Admin or PowerShell)
  7. Configure App URLs in Central Admin (App Domain and App Prefix)
    1. Note: Anytime you make a change to this you need to do an IISReset
  8. OPTIONAL: If using Host Headers you will need to create a generic web app that has a blank host header and listens on port 80 (Or 443 if you are using HTTPS). (Unless March 2013 Public Update is applied)


Edit 8/7/13: For a full setup with screenshots check out

Creating a SharePoint 2013 Index Component – PowerShell Bug

After setting up SharePoint 2013 Search with David at Trek Bicycles we encountered a bug with the PowerShell cmdlet:

When using the –RootFolder parameter to specify where you want the index location (For Example: C:\SPSearch) to be you must have the folders created ahead of time. After creating the folders on the servers where you are creating the index components on, you will still received the error message “New-SPEnterpriseSearchIndexComponent : Cannot bind parameter ‘RootDirectory’

The cmdlet does a check not only on the servers you are creating the index component on, but also on the server where you run the PowerShell script (in this case the app server, which will not have any index components at this time). After creating the folders on the app server it will create the index partitions successfully, even though nothing was/should be written to that folder.

This is described at the bottom of this blog post:

Using Fiddler2 as a proxy for SharePoint Search

I was looking for a way to troubleshoot search crawl errors a little bit better and figured why not use a tool I already use daily…Fiddler! Here is a quick guide on how to use Fiddler2 as a search proxy so you can see what is happening when the user agent is crawling the content.

  1. Login to the appropriate SharePoint 2010 Application Server where Fiddler is installed
  2. Run Fiddler2 as the SharePoint 2010 default content access account
  3. Minimize the Fiddler2 window and browse to http://localhost:8888
  4. You should see a screen similar to this:
  5. Fiddler Echo Service
  6. Login to central admin
  7. Go to Application management > Manage Service Applications > Search Service Application
  8. Click on None next to Proxy Server: Select “use the proxy server specified” and type http://localhost for Address and 8888 for port.
  9. Click OK
  10. Now run a full crawl on the content source in question. The crawl results will appear in the Fiddler2 window on the server.

Now watch for any errors…especially those pesky red 500 errors!

SharePoint 2013 Metadata Extraction – Redefining how we should style our documents

I’ve been noticing some odd results coming in from search in SharePoint 2013 so I decided to do some research. These odd results seem to be coming in from the new 2013 feature in search called metadata extraction. SharePoint 2013 search tries to determine the document name based on styling in that document which is usually the first H1 style. For this reason some documents were showing up as the title “Table of Contents” or “Insert Title Here” if the document was a template. I went ahead and did some tests to try and determine what takes precedence in search results. For this testing I created blank Word documents, Excel spreadsheets, and PowerPoint presentations and ran through the scenarios listed in the table below.

Scenario Word (doc/docx) Excel (xls/xlsx) PowerPoint   (ppt/pptx)
No title defined   in SharePoint/File Properties (H1) Displayed Header text Displayed File Name Displayed Title Slide   Text
Title defined in   both SharePoint/File Properties (H1) Displayed Header text Displayed Title Displayed Title Slide Text
No title defined   in SharePoint/File Properties (No H1) Displayed File Name Displayed File Name Displayed File Name
Title defined in   both SharePoint/File Properties (No H1) Displayed Title Displayed Title Displayed Title

**Note: The SharePoint title property and file title property are directly related and one will update the other.

Here’s a little bit more about each test document and how it returned in search results:

1)      Word (one doc/one docx file) – DOCX didn’t extract text from document, but DOC did

doc and docx - metadata extraction

  1. H1: Heading (H1) with sample text (normal) underneath
  2. No H1: Sample Text only

2)      PowerPoint (one ppt/one pptx file) – PPTX didn’t extract text from slides, but PPT did

ppt and ppt - metadata extraction

  1. H1: Title Slide with one content slide. A content slide with a title behaved the same
  2. No H1: One Content Slide (No title at top and text in text box underneath)

3)      Excel (one xls/one xlsx file)  – Both XLS and XLSX extracted text from the spreadsheet, but XLS extracted the title of the sheet as well

xls and xlsx - metadata extraction

  1. H1: Text style with (Heading style applied) and text in column underneath
  2. No H1: Plain text in top 2 cells

Summary: Here is a list of the priorities for the 3 types of documents tested –

  1. Word: H1 (Style) > Title > FIle Name
  2. Excel: Title > File Name
  3. PowerPoint: Title text > Title > File Name