Tag Archive for: Architecture

SPC14: Effective Search deployment and operations in SharePoint 2013

06 Mar 2014
March 6, 2014

SharePoint 2013 introduces a new and highly flexible search topology. This gives more flexibility on how to scale a system, and allows search to tackle demanding requirements for query and indexing performance. In this session we will take you through the deployment of a multi-node search installation, provide best practices for common operational procedures, and give you tips and tricks on how to keep your search system healthy.

My session notes for “Effective Search deployment and operations in SharePoint 2013” by Kristopher Loranger and Mert Sangar at SharePoint Conference 2014 in Las Vegas:

Search Architecture

Mert showed a comparison how the architecture of search changed from SharePoint 2010 and FAST Search for SharePoint to SharePoint 2013 – good overview.

Bug: October CU 2013 has an issue that when you have a very long Search Service Application name – things break.

High Availability

Search is FAST Search now – they implemented the high availability concept of FAST.

Set up your initial search topology

Best to do it in PowerShell – I have a sample script here, there is a better one on MSDN by Brian Pendergrass.

Its not supported that you change the index location after provisioning,


I need to clarify that quote – I thought it is supported when you migrate to a new topology where the index is in the new location.

During a repartitioning the search query application is paused, no search results during that time – and I experienced it can take very long!

Recommendation: symmetric index layout.

Demo: Setup up multi-node deployment

Kristopher showed the script in action – nice

Deployment Options for Large Enterprise

  1. Central Search Farm: better relevancy, lower maintaining costs, better end-user experience
  2. Distributed: Search index on each farm, federated results as result blocks
  3. Hybrid: On-prem and O365 – federation, stepwise migration of the cloud

Keep your Search Topology Healthy

Search Diagnostics are available through the UI or with PowerShell (Get-SPEnterpriseSearchStatus) – there is a helper script that renders the results nicely.

Search Reports: Performance, Zero-Result queries, etc.

Monitoring: SCOM and ULS

The yellow state in the UI means its degraded and (might) recover, red means hardware or configuration problems. Use powershell cmdlet to get more information.

Kristopher showed some nice tricks how to get insights out of the many search reports – need to rewatch the video afterwards to internalized this for me.


Daily/Weekly tasks

Admins: check search topology, monitor performance, health, # documents per partition
Business users: create best bets and query rules, check zero results and abandoned query.

Patch and updates

Its recommended to install March PU and at least October 2013 CU. Many changes that regarding to scale.


High Availability

Kristopher showed the concepts behind search high availability (great stuff) and how to replace a failed node in a search installation. Apparently the demo failed, but they prepared a video so all was good.


Most of the stuff I knew already – but the devil is in the detail, right? Kristopher and Mert did a nice presentation, very valuable presentation to me! Q&A afterwards was great, too.

SPC14: Search architecture and sizing in SharePoint 2013

06 Mar 2014
March 6, 2014

In this session we will dig into the new architecture for Search in SharePoint 2013. We will cover all architectural components, plus discuss the differences between the 2013 release versus FAST Search and search in SharePoint 2010. Microsoft has updated topology models for different sized deployments. This will be presented along with sizing and scaling data for both physical and virtual machines – actionable data you can use to assess and use during your planning phase. We will also cover planning for high availability, backup/restore, and migration.

Here are my session notes for “Search architecture and sizing in SharePoint 2013” by Barry Waldbaum and Thomas Molbach.

Search Architecture

Thomas briefly explained the Search Architecture – nothing new here for me, its very well documented on Technet.



SharePoint 2013 Search scales pretty well –. I tried it in a project and it works.


Web Front-End

Display Template, Query Rules – quite a lot happens on the web frontend.



With the analytics service you can do very great things because it provides the insights behind the “Trends” in SharePoint. It even provides a view counter.


Search Query Tool

Thomas showed some nice tricks with the awesome Search Query Tool. There is a property called recommendedfor that accepts a url and shows what other items are recommended for the given url. Then he filtered on ViewsRecent to show the elements that were recently clicked on.

More about the tool will be announced tomorrow by Mikael Svenson (blog).


Benchmark the VMs to verify that you get the performance they IT department promised you

Scaling from small 10M to 40M:

Average document size is 250KB

I use that as a rule of thumb, too – but it has constraints.

SharePoint 2010 had Single Point of Failures – SharePoint 2013 does not have this anymore

Large Topology: 100M Enterprise

24 Servers – phew.

October 2013 Cumulative Update

High Density Indexing: 4 Index Partitions per Node – this cut the amount of server requirements in half (less licenses!) but you have to scale up your hardware.

Q: Why only 10M items in one index?

A: Higher amount: Backup takes longer, Response time gets worse

Analytics: Scale-up, otherwise it eats more network.

That was incredible – I had to stop taking notes, really dense information delivery 🙂

Backup and Restore

Robust backup, no Query Downtime during backup – it is even supported to restore QA backup on PROD (same topology).



Create everything from scratch.

Search First Migration

Publish Search Service Application – done that, works great.

Migrate from SharePoint 2010

Attach the Search Service Application Database

Migrate from Fast Search For SharePoint 2010

Backup/Restore Database – PowerShell script to to some work.


Apparently 50% of the session was not in the description – I expected more Sizing and Architecture and was close to leave the audience. Then the good part with the sizing started and provided really good value to me. WOW – had a blast! The changes that happened in October 2013 CU/SP1 for search are really incredible. Additionally, I waited in the queue because there were so many questions – and learned even more. Great stuff. Did I say it was great yet?

SPC14: Real-world SharePoint architecture decisions

04 Mar 2014
March 4, 2014

Being a SharePoint architect can be challenging – you need to deal with everything from hardware, resources, requirements, business continuity management, a budget and of course customers. You, the architect, have to manage all this and in the end deliver a good architecture that satisfies all the needs of your customer. Along the line you have to make decisions based on experience, facts and sometimes the gut feeling. In this session we will cover some of the architectural changes in the SharePoint 2013 architecture, some of the new guidance from Microsoft and provide insight into a number of successful real-world scenarios. You will see what decisions were made while designing and implementing these projects with emphasis on why they were made.

Session “Real-world SharePoint architecture decisions” by Wictor Wilén, here are my notes:


Distributed Cache Service: Patches will be separately delivered. Wictor recommends to use the latest CU.

Request Management: Rule-based, software load balancing. Missconfigured rules can take down your farm.

Search: Rearchitectured and rewritten with using features from both FAST and SharePoint Search are implemented. Same engine is used for Exchange.

Office Web Apps (WAC): Wictor’s favorite service – separate application, separate server, separate patches.

Workflow: separate product – can be shared with multiple farms (not recommended)

Claims Based Authentication: the new default.

OAuth: Used for Authentication. A basic understanding really helps.

S2S Auth: Apps, Workflow use server to server authentication.


There is no perfect architecture you can download and apply.

Or as I would say: It depends.

3 is the new 2 – and 7 is the new 5


Means you need more servers – but think about the fault domain, if you virtualize you need redundant VM servers, if you do load balancing you need redundancy there. Always ask yourself how to patch this?


Routing, caching and database must be fast – every request go through there, if they are slow your farm will be slow.

Search Layer should have <500 msec latency. Many components are based on Search – make it fast!


Search requires different planning in 203 – cross site publishing, analytics, recommendations need to be taken care of. October 2013 CU contains huge improvements.


Workflow Server: You can install it on 1 or 3 servers – no other options.

Office Web Apps: Separate servers – no other option.

App Server: On prem, co-locate with SP server, Azure or other hosting options (LAMP) to offload the workload.

Certifcates: You should use certificates for about everything – when someone steals your oauth token they could access sensible data. Apps, WAC – and more.

Firewall: Firewall team should be involved early. Wictor will provide a firewall cheat sheet, because Technet lacks a good one.

User Profile: ADI, built-in FIM, External FIM are the options. He suggest to use external FIM but you need to license it.

MySites, Social, Yammer: MySite is a must. DirSync is a must for Yammer (to make it fault tolerant you need 4 additional servers, 2 ADFS, 2 Web Proxies)

Hybrid: Search is the key to hybrid, Mysites can be deployed on-prem or on O365.

Look and Feel: If you want to customize deploy the MySite on-prem.

Social. Yammer is the way forward.

Single Web Application approach

One WebApp to listen to all host headers, and is recommended. AppCatalog has to be in the same WebApp – if you use two, you need two AppCatalogs.

Memory footprint reduced.

Most often requires Host Named Site Collections.

For Host Named Site Collections he recommends a custom site creation provider.


Root Site Collection is required.


You need a load balancer for the custom http header.


Wictor showed us how to create a Host Named Site Collection (HNSC) with PowerShell. Very straight forward, worked like a charm and is another good reason to use PowerShell.


Then Wictor showed some pretty extensive samples – can not write them down, was too complex to summarize, but was very useful to see complex scenarios – would love to see them in Technet as reference.

Forgotten stuff

List of things people often forget in SharePoint architectures:

  1. High Availability and Desaster recovery
    1. 20% of the farms Wictor sees have 99.9% uptime
    2. 10% had 100% uptime requirements (impossible).
    3. Affects the cost
  2. Workflow
  3. Provider Hosted Apps
  4. Access Services 2013

Things to avoid / consider

Multi-tenancy, often done for the wrong reasons. For large-scale hosting consider O365.

Streched Farms – read http://askwictor.com/spstreched

Service Farms and Service Application federation: Makes solution more complex, understand limitations upfront. Managed Metadata Service is a good service to federate.


So many good sessions in parallel – Future of Infopath or the session by Spencer Harbar about Identity Federation (homework) – I am still glad that I attended Wictor’s session, good stuff, I learned quite a lot and “refreshed” many topics I tend to forget. The room was packed, there is obviously a huge demand!

Wictor delivered so many stuff in a short time (my notes are therefore not complete!) – he is really fast paced Smiley

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.