More than I ever wanted to know about the SharePoint Search Topology

The other night I burned way too many hours trying to fix a broken search service application for what seemed like a ridiculous reason. We have an integration server that we are using for a large project. I was working with it earlier in the day testing some front end code. Later in the evening with no apparent cause it decided to throw the error below on the Search Administration screen. This prevented search from operating and all my client side queries returned a nondescript 500 error telling me to check my search service.

“The search service is not able to connect to the machine that hosts the administration component”

After many hours of research it turns out that this error happens fairly often for many different reasons. Essentially the search administration component of the Search Topology gets corrupted. No real reason why, it just happens.

Search if you don’t already know is made up of a bunch of different components. Each component serves a different purpose from administration of the search service to crawling, to indexing the content. Each one of these components is held together as a collection in what is called a Search Topology object. There can be multiple search topologies in the search application but only one active topology. 

When you create your search service application all these component are created for you automatically. In our instance we used SPAutoInstaller to build the box so it provisioned the services using PowerShell. Our search administration became corrupted and search would no longer run or return results.  

There are a lot of fixes out there that reference changing the app pool in IIS that the search service is running in. Not only did this not fix our issue it also seemed very wrong that something that was previously running would suddenly stop running because of the app pool unless the app pool stopped. I also tried elevating the permissions of the app pool account for the account that the service was running in which seemed equally as incorrect. Neither of these solutions resolved our issue. 

I decided to investigate the Search Topology using PowerShell. I could very clearly see the default topology and the components via PowerShell and see the broken component. 

$ssa = Get-SPEnterpriseSearchServiceApplication
$topology = Get-SPEnterpriseSearchTopology -SearchApplication $ssa
Get-SPEnterpriseSearchComponent -SearchTopology $topology.Id -SearchApplication $ssa

Finally, I tried to delete the search service application and recreate it through the UI. The search application removed cleanly and I was able to create a new one from the UI with no issues. I checked the search topology again and it was identical to the previous topology with the corrupted administration component. The default topology was saved somewhere in the SharePoint database. 

Ok, I thought if the search topology is the same then I will use PowerShell and create a new topology as a clone from the last one, delete the corrupted component, and assign the new topology to the search application. No Dice! It turns out that while I could create a new topology I was unable to assign it to the search application because the existing default topology wasn’t working. I was getting ready to revert the server to a snapshot that was old and recreate all the work I had done.

Finally, in a Hail Mary pass, I decided to recreate the Search Service Application using PowerShell. So, I deleted the broken Search Service Application through the UI. Then I went to the database server to ensure that the databases were deleted. I restarted the search services (SharePoint Search Host Controller and SharePoint Server Search 15 from the Services console). I took a deep breath, crossed my fingers, and recreated the Search Service Application using a PowerShell script I modified from Todd Klindt. This fixed the issue. Now I have a happy search service and a PowerShell script to fix the issue the next time it happens. 

Update – 12/11/18
Ian Dicker reminded me that I am a typical developer. Given that I am working on such a search intensive application I should have probably been backing up my search application regularly. I am a developer at heart and love the excitement of flying by the seat of my pants but he is correct. Had there been a backup this would have been a lot quicker. If you are looking for information on how to back up the search application. Look no further than MSDN.

Using Widget Wrangler with PnP for IE

I am creating client-side webparts using the Widget Wrangler for SharePoint. The webparts all use PnP JS. This site needs to work in IE 10+. The webparts work great in Chrome and most other browsers. However, when i run it in IE I get an error about Undefined Headers. This is because PnP uses Promises which IE 10 and 11 don’t support. To fix that I had to include some polyfills and perform a sacrifice to the SharePoint gods.

  1. In the ww-appScripts property I needed to add the following references
    1. https://cdnjs.cloudflare.com/ajax/libs/fetch/2.0.3/fetch.min.js
    2. https://cdnjs.cloudflare.com/ajax/libs/es6-promise/4.1.0/es6-promise.min.js
    3. https://cdnjs.cloudflare.com/ajax/libs/sp-pnp-js/2.0.5/pnp.min.js

So the tag ends up looking like this

{“src”: “https://ajax.googleapis.com/ajax/libs/angularjs/1.4.5/angular.js”, “priority”:0},
{“src”: “https://code.jquery.com/jquery-3.2.1.min.js”, “priority”: 1},
{“src”: “https://code.jquery.com/ui/1.12.1/jquery-ui.min.js”, “priority”: 2},
{“src”: “https://cdnjs.cloudflare.com/ajax/libs/select2/4.0.4/js/select2.min.js”, “priority”: 2},
{“src”: “https://cdnjs.cloudflare.com/ajax/libs/fetch/2.0.3/fetch.min.js”, “priority”: 3},
{“src”: “https://cdnjs.cloudflare.com/ajax/libs/es6-promise/4.1.0/es6-promise.min.js”, “priority”: 4},
{“src”: “https://cdnjs.cloudflare.com/ajax/libs/sp-pnp-js/3.0.1/pnp.min.js”, “priority”: 5},
{“src”: “~/bundle.js”, “priority”:6}

Important thing to note that the priority Fetch and ES6-Promise need to come before PnP.

Also in your PnP setup make sure to include

$pnp.setup({
headers: {
“Accept”: “application/json; odata=verbose”
}
});

Managing Office 365 Identities Made Easy

A friend of a friend of a friend told about this thing that totally changed their life. It wasn’t exactly that convoluted but I was complaining to a friend the other day about constantly having to switch credentials for my office 365 tenants. He suggested a nifty trick that a friend of ours Beatrice Baciu wrote about. He showed me how to use Chrome Personas to manage my different office 365 accounts.

If you are like me you have many different office 365 accounts. I have two to access my company information like my intranet and staffing tool. I have two different developer tenants and a few client tenants that I need to keep track of. Chrome has the ability to create different personas. When I actually tried this it changed the way I manage my accounts. I did a little happy dance.

  • Open Chrome
  • In the top right corner you will see either Guest of your name if you are signed in using your google account. Click that and it will bring down a drop down.
    screen-shot-2017-02-08-at-2-23-43-pm
  • The top name is the persona that you are currently signed in as, the bottom list are the personas that you can choose from.
  • Click Manage People
    Screen Shot 2017-02-08 at 2.32.37 PM.png
  • Click Add Person
  • Enter a name for the persona, select an avatar, and click save. This adds a new persona to chrome and will open a new Chrome instance for that persona.
    screen-shot-2017-02-08-at-2-35-40-pm
    screen-shot-2017-02-08-at-2-37-10-pm
  • Look in the top right. The persona is now changed to my new persona. I can now log into my dev tenant.
    screen-shot-2017-02-08-at-2-39-19-pm
  • When you log in to your Office 365 account make sure you check the keep me signed in check box so your authentication persists.
  • I can then open a new Chrome window, switch to a different persona and have two windows open at the same time with different office 365 accounts!!!

I hope this is helpful to someone other than me. I mentioned this to several of the folks that work with me and they couldn’t believe they hadn’t heard about this before so I figured I would get it out there in an effort to make others lives a little better. 🙂

 

Enjoy! – d

 

Provisioning files in a feature in the root directory

I was recently tasked with migrating code that was written for 2007  in a feature. The files that were originally provisioned in the feature we deployed to the root folder of the feature. The code had already been upgraded to SharePoint 2010. I needed to create a wsp using Visual Studio 2010 and package it as a feature. Out of the box when you create a new Module in VS 2010 you get a subfolder so for example you create the feature called Feature1 and a module called Mod1. The default deployment path is 14\templates\features\feature1\mod1\file.txt. What I needed was feature1\mod1\file.txt. I tried modifying all the attributes in the elements.xml file and was not able to get the files to the correct location.

 

In the end what i did was the following

  1. Add the file to the module in visual studio
  2. Look at the properties of the file in visual studio
  3. Under Deployment Location expand the + and clear the Path value.
  4. Ensure that the Deployment Type is Element File
  5. Deploy the file and it should be in the correct location.