Demystifying MinRole in SharePoint Server 2016:

MinRole – I hope everyone would agree with me when I say that “MinRole” has become a buzz word among many SharePoint folks ever since Microsoft released SharePoint Server 2016. I myself have personally read many articles/blogs and viewed some videos on it to understand in detail about MinRole and how to make use of it. However, there has been times where I couldn’t really understand it completely and I had to work with many SharePoint experts in the industry to understand in detail about what MinRole is and how it works. But still I can sense a lot of uncertainty among few SharePoint folks in understanding MinRole and how to make use of it. Hence, in this article I’ll be explaining in detail about the below mentioned points….

  1. What is MinRole?
  2. How to deploy a SharePoint 2016 farm using MinRole topology?
  3. Different server roles in MinRole
  4. Different type of MinRole topologies
  5. MinRole -Before and after Feature Pack 1
  6. The benefits of using MinRole
  7. MinRole Administration
  8. MinRole compliancy
  9. Opting out of MinRole
  10. How/where to deploy 3rd party apps while using MinRole?

160121MinRole_lg.JPG

Alright, so let’s get started …

  1. What is MinRole?

To put it in very simple words, MinRole is a new farm topology based on a set of predefined server roles which got introduced in SharePoint Server 2016. Unlike the old traditional SharePoint farm topologies where you add a server to a farm and then configure it, here you can select the role of a server when you create a new farm or join a server to an existing farm and SharePoint will automatically configure the services on each server based on the server’s role. SharePoint Server 2016 by default has been optimized for the MinRole farm topology.

So, the point here to understand is, with MinRole you don’t need to add servers to a SharePoint farm and then configure each server in the farm as WFE, APP, Search etc.… MinRole will do that magic for you. Once you add a new SharePoint 2016 server to a farm and run the configuration wizard you would get a screen as shown below which asks you to choose the appropriate role .Once you select the appropriate role ,SharePoint will automatically turn on and configure the necessary services based on the server’s role.

2.png

Now that we have understood about MinRole, let’s understand how to deploy a SharePoint 2016 farm using MinRole topology.

2.How to deploy a SharePoint 2016 farm using MinRole topology?

Before I go ahead and discuss about how to deploy a SharePoint 2016 farm using MinRole topology, let’s refresh ourselves by taking a glance at the default SharePoint 2013 streamlined topology which we’re already used to. Let’s look at the image below to understand about the default SharePoint 2013 streamlined topology…

18.png

So as shown in the image above, in SharePoint 2013 when you create or add a new server to the farm you have to manually go to the “Manage services on server “section on Central administration site and turn on the required services after which you would be configuring the required service application (Ex: Search Service Application, Managed metadata service application, User Profile service application & Distributed Cache service application etc.…)

services-on-server.jpg

However, the good news with SharePoint 2016 you don’t need to spend time on turning on the required services under “Manage services on Server “. You just need to focus on choosing the required role on the “Specify server role “window which I just described above and SharePoint  will take care of the rest for you. Hang on, let’s be clear here …. SharePoint will only take care of automatically turning on the required services but the service application has to be configured by you as an admin. I guess while reading this, you must have this question in mind … “Well this is cool, but how does SharePoint manages to do this by itself? “…The answer to this follows, when you create a new farm or join a machine to an existing farm, SharePoint starts the base set of service instances that are required for the server’s role. It also detects which additional services have been enabled in the farm and starts the matching service instances as appropriate for the server’s role. Finally, it detects which service applications have been created in the farm and which services are necessary to support those service applications. Those service instances will be started as appropriate for the server’s role, as well.

MinRole management of service instances doesn’t happen only when you join a server to a farm. As you enable or disable services in the farm, or as you create and delete service applications in the farm, MinRole starts and stops service instances on the existing servers in the farm. This ensures that each server in your SharePoint farm is running exactly the services it needs.

So, the end result is, you as a SharePoint farm administrator can only focus on what services you want to run in your farm and not worry about where they’re running. The MinRole topology in SharePoint will take care of the rest.

Also, let’s take a look at the image below which illustrates how the SharePoint services are scattered between these different server roles while using MinRole topology.

1.PNG

All the user interactive scenarios would be running on the WFE role, all the background tasks such as Search, UPS etc. would be running on the APP role and finally the caching services would be running on the DC role .

Well, hang on …. I still didn’t tell you how to deploy a SharePoint 2016 farm using MinRole. There’s two variants to do this … 1. Using the SharePoint product configuration wizard 2. Using PowerShell.

  1. Using the SharePoint Configuration Wizard:

So, you can choose the role of a server while adding it to the farm using the below mentioned screen which you get while running the product configuration wizard.

2.png

  1. Using PowerShell:

POWERSHELL.png

Now that we have understood how to deploy a SharePoint 2016 server /farm using MinRole, let’s try to understand the different roles available in MinRole topology.

  1. Different server roles in MinRole:

The below mentioned image from one of my presentations on SharePoint 2016 clearly illustrates the different roles that are available in MinRole.

3.PNG

4.PNG

So, based on your need/architecture planning you can choose the appropriate role. However, this architecture might sound quite costly because with MinRole you can’t add two application roles together like how we used to do in SharePoint 2013 for small farms with 4 to 6 servers, meaning you don’t get to enjoy the privilege of having Search and Managed metadata or may be Search and User Profile service running on the same server. In MinRole if you do so then that particular server would be marked as non-compliant. But Microsoft has listened to its customers about this and has made some changes to the MinRole feature in Feature Pack 1 release for SharePoint 2016 and I’ll be talking in detail about that later on  this article.

Note: The concept of Service packs is gone in SharePoint 2016 and is now replaced with Feature packs. You don’t get to see Service packs anymore at least on SharePoint 2016. Also, the Feature packs won’t be as separate packages like your service packs which gets released separately( i.e. once in 12 months as a separate package ). A particular month’s CU/PU would be called as a feature pack where Microsoft would ship all the fixes/new features and that month’s CU would be called as Feature Pack. Till now Microsoft has release Feature Pack 1 (i.e. Nov 2016 CU) and you can find the details about that in this link below . So, a specific month’s CU would be released as a FP hereafter .

https://support.microsoft.com/en-us/help/3127940/november-8,-2016,-update-for-sharepoint-server-2016-kb3127940

Microsoft was quite ahead of their schedule while they released FP1 as the original release date was planned on 2017 .However they managed to release that on Q4 of 2016 itself .

This image below depicts the roadmap for SharePoint Server 2016 :

Roadmap.png

Alright , let’s jump into the different type of topologies in MinRole .

  1. Different type of MinRole topologies :

Now that we have seen a lot about MinRole , I guess it really begs the question of how to choose the appropriate SharePoint topology while using MinRole . Well , let’s go and take a look at it . Shall we ?

A typical SharePoint 2013 Topology :

This is how a typical SharePoint 2013 Topology would look like . Please check the image below .

9.png

In this case the SharePoint Administrators manually configure services on each server to fit these roles and in addition that as features and services are added, administrators have to determine where these components should run based on best practices, current server load, etc.

But this is not the case with SharePoint 2016 MinRole Topology , since this is a role based architecture you can directly choose the role you want to deploy and MinRole will take care of the rest . Please check the image below which depicts a SharePoint 2016 MinRole topology architecture .

SharePoint 2016 MinRole Topology :

MinRole topology.PNG

As shown in the image above, you need not less than 4 servers to deploy a SharePoint 2016 farm.  If you’re including SQL then in that case you need at least 5 servers for MinRole. Also , Minimum configuration does not have any resiliency.

Let’s see how this works when you want to plan a SharePoint 2016 HA farm with MinRole topology .

6.PNG

8.png

So, as you can see in the image above , two servers are required for each role . When it comes to  Distributed  cache three servers are required in a cluster quorum . We also need SQL availability groups to achieve HA in the SQL layer. So, in total you might require 13 servers altogether if you’re also adding Office Online server in HA .

However , this count may vary based on your architecture and planning . Please check the image below where I’ve designed a HA SharePoint 2016 farm with proper planning .In this case the total number of servers required is 18 .So the point to note here , based on your business needs you can scale out the total number of servers for HA .

10.PNG

Custom 3 Tier MinRole Topology:

This is how a custom 3 tier MinRole topology looks like. The front-end servers are benefited from MinRole. The custom server role is used to configure custom servers to run majority of SharePoint service applications and reduce the number of servers.  Unlike MinRole, the services have to be manually configured on the custom server role. It’s the job of the SharePoint Administrators to configure the required services on the custom server.

custome 3 tier.PNG

Custom HA Topology with Search:

custom HA with search

This is how this architecture has been planned,

  • Two load balanced servers with Front-end role.
  • Two custom servers running distributed cache, User Profile Sync, Secure Store.
  • Two servers with Search server role.
  • SQL servers configured with always on availability groups.

5.MinRole -Before and after Feature Pack 1:

Now, if you see the complete overview of MinRole you might understand that you need high budget to implement this due to the total number of servers required. Unlike SharePoint 2013, you don’t get to add the roles together in a single server (i.e. Custom Role) while using MinRole topology and this might increase the budget and many customers have reported the same concern to Microsoft. As always, Microsoft listened to their customer’s feedback and they’ve made some changes to this in Feature pack 1. Let’s look at that in the image below.

11.PNG

I guess the image above gives a detailed explanation about the changes to MinRole topology post FP1 . So, post FP1 you can add two roles together which will reduce the total number of servers required to build a SharePoint 2016 farm using MinRole.

post FP1.png

If you’re interested in knowing more about the new features that was introduced in Feature Pack 1, please take a look at the link below.

https://blogs.office.com/2016/09/26/announcing-feature-pack-1-for-sharepoint-server-2016-cloud-born-and-future-proof/

  1. The benefits of using MinRole:

Listed below are the benefits of using MinRole.

  1. Simpler Deployments
  2. Improved Performance and Reliability
  3. Simpler Capacity Planning and Farm Scalability.

Simpler Deployments:

  • SharePoint Administrators no longer need to worry about which services have been enabled on which servers.
  • Administrators can reduce the risk of slight misconfigurations during installation by leveraging a template-type deployment.
  • Administrators can focus on what functionality to enable in the farm and let SharePoint take care of the rest.

Improved Performance and Reliability:

  • Microsoft has been operating SharePoint online since 2011 and has analyzed key performance characteristics of operating SharePoint at an internet scale such as CPU, Memory, disk I/O and network latency.
  • SharePoint has been optimized for MinRole topology based on all that analysis /learning which Microsoft learned from operating SharePoint Online in their own datacenters for years.
  • Improved service application load balancer services requests from local service instances instead of going across the farm to another server.

Simpler Capacity Planning and Farm Scalability:

  • In SharePoint 2016, Microsoft bases capacity planning on the MinRole topology.
  • Leverage predictable and perspective capacity-planning guidance by deploying a farm based on the MinRole topology.
  • As SharePoint needs grow, easily add more servers to the farm and SharePoint will automatically configure the additional servers.
  1. MinRole Administration:

You can administer MinRole from the Central administration site and also via PowerShell

Using Central Administration site:

13.PNG

You can change the role of a server after it’s deployed and also check whether the server is complaint from the central administration site itself.  The same can be achieved using PowerShell as well. A server in the farm which was acting as WFE today can be made as a APP tomorrow and once you change the role SharePoint will automatically turn on and off the required services .

Using PowerShell:

POWERSHELL.png

Note: There’s some bugs that has already been identified and reported to MS while toggling the role of server from the Central Administration site and hence it’s better to use PowerShell to change the role of a server

8.MinRole compliancy:

  • Once a Server’s role is configured, only those services appropriate for that role can run on that server.
  • SharePoint 2016 has a new set of Health Analyzer rules and timer jobs to identify when a server isn’t MinRole complaint.
  • If a service is accidently turned on and shouldn’t be running on that server, SharePoint will automatically turn it off.

compliancy.PNG

 14.png

9.Opting out of MinRole:

As a SharePoint administrator, you can always say no to MinRole if you’re not planning to use it. This can be achieved by assigning some/all the servers in the farm to the custom role and then manually manage service instances on these servers. Also, you need to consider using “ServerRoleOptional” parameter when creating a new SharePoint farm if existing deployments script needs to remain intact.

10.How/where to deploy 3rd party apps while using MinRole?

Well, the answer to this simple. Yes, you guessed it correctly, so it’s the “Custom Role” that you need to choose while deploying any third-party applications such as (Ninetex Workflows, AvePoint etc.). In addition to that, services like PerformancePoint, PowerPivot etc. would best fit in the custom role.

MinRole is truly phenomenal and would definitely reduce the risk and the time taken by a SharePoint administrator to deploy a SharePoint 2016 farm. Microsoft has done an awesome job in introducing MinRole on SharePoint 2016 which would definitely reduce all our burdens as SharePoint administrators. Thanks for reading this post …. Happy SharePointing!!!

Resolving “Sorry this site hasn’t been shared with you…” SharePoint site error:

Alright .I’ve had a pretty tedious week with SharePoint search were all of sudden the “SharePoint Enterprise search “  site collection started throwing an error stating  “ Sorry this site hasn’t been shared with you “ as shown in the image below .

1.png

Every time any user made an attempt to execute a search query on the search box in the SharePoint site , they got this annoying error stating the “ Sorry this site hasn’t been shared with you “ and it was the same for everyone .I tried  accessing  the Search center using the farm account and it still threw the same error . So in this article I’ll be taking about what this error is all about, what are the troubleshooting steps we did to fix and how we finally managed to fix it.

Initial troubleshooting steps performed to fix this issue:

Since this was on PROD and we had a lot of users who were impacted by this issue and hence we initially decided to create a new search center site collection under a different web application so that for the time being users can live with that .Meaning , we initially had the “SharePoint enterprise search center “ URL  configured and running under web application A and after we encountered this issue we removed that and created a new enterprise search center site collection under web application B so that we can figure out what’s wrong with the previous search center without having any business impact . The image below should help you understand what I’m talking about.

qGosn.png

After making the change here, please go ahead and update the new search center URL in site settings as shown in the image below.

272861.jpg

So after doing that we did the below mentioned steps in sequential manner as suggested in some forums to get rid of the issue….

  1. We thought of clearing IE cache: Open a new browser window –> Go to Internet options –>In the general tab, click the Delete button –>Make sure that passwords and temporary Internet files are selected. Try different browser such as Firefox! ( But doing this wouldn’t make sense in our scenario as the issue was only limited to one site collection in the entire farm .However , we tried this but it didn’t help )
  2. If you didn’t run product and configuration wizard after installation/patch, you may get this error even if you are a site collection administrator. Run it once and get rid of this issue. ( Even this was not quite convincing as the issue was just with one site collection( i.e. SharePoint enterprise search ) in the farm )
  3. Stop and Start “Microsoft SharePoint Foundation Web Application” service from Central Admin –>Application Management–> Manage services on server ( We did try this as well bearing the risk of losing all the sites for quite some time but even that didn’t help .For those who are not aware of what this steps does , it stops and recreates the SharePoint web application sites in IIS )
  4. If the SharePoint farm was migrated from SharePoint 2010, or backup-restore/import-exported: If your source site collection is in classic windows authentication mode and target is in claims authentication, you must change classic mode authentication to claims-based authentication. ( This was not applicable in our case as the sites were working perfectly fine for years after the migration )
  5. Try clearing the Distribution Cache. Do the IIS reset (We did this and it didn’t help either).

6. We also verified whether “NT Authority\Authenticated users” group has enough permissions on the search center and it was positive.

7. Of course we also checked the site collection administrators for the “SharePoint Enterprise Search site collection “and it was perfectly fine.

8. We also took a look at all the Search service application in SharePoint 2013 to verify the settings and they were pretty good.

Also, let me tell you that the issue this issue was reported to us the second time within a month .The first time it was with a different site collection on the same web application and this time it was on the SharePoint search center site collection that’s under the same web application. When it was reported the first time we just did an app pool recycle and also checked out and checked in the master page and that fixed it .But this time nothing was accessible in the Search center site collection.

So finally with no much steps left to do we decided to open a Sev A case with Microsoft and started working with them on this issue.

Listed below is what MS did to fix the issue:

  1. I shared the ULS logs as well as fiddler logs with the MS engineer by reproducing the error and after reviewing the logs he was able to identity that the “super user “ and “super reader “ account which takes care of object cache got corrupted in our environment which lead to this outage .

What’s the super user and super reader account?

The below mentioned link should give you a detailed explanation on the super user and super reader account. It’s very important that any SharePoint environment should have these accounts configured properly for optimal performance and it’s mostly utilized by sites which have the publishing feature enabled.

https://technet.microsoft.com/en-us/library/ff758656.aspx

Ideally, the Portal Super User account must be an account that has Full Control access to the web application and the Portal Super Reader account must be an account that has Full Read access to the web application.

Also, you need to make sure that these accounts are discrete and they should never be used to login to the site and also it shouldn’t be used to to login to the SharePoint servers also as mentioned in the TechNet article that I highlighted above.

3.png

But in our scenario it’s exactly that part which was wrong .The “super user” and “super reader” account was the farm administrator service account and we often use that account for accessing the sites .This was configured mistakenly when the farm was initially configured and it eventually got corrupted which lead to this outage .However, we were not able to identify how it got corrupted all of a sudden and how it managed to run safely for all these years( might be one of those SharePoint mysteries ) . So we went ahead and changed that account and updated that for all the web applications in the farm using the below mentioned PowerShell command

$wa = Get-SPWebApplication -Identity “<WebApplication>”

$wa.Properties[“portalsuperuseraccount”] = “<SuperUser>”

$wa.Properties[“portalsuperreaderaccount”] = “<SuperReader>”

$wa.Update()

Lessons learned:

Please ensure that your SharePoint farm has the “super user” and “super reader” configured correctly for optimal performance and do check and ensure that they are discrete and those accounts are not being used to access SharePoint sites . If by any chance you’re facing this issue for a different site collection and not for SharePoint search the steps which I discussed above would still remain the same except for the “SharePoint search” part.

Also once you’re done reading this post, please ensure that you take a closer look at your web application properties and ensure that these accounts are configured correctly so that you don’t end up seeing surprises like me.Adding these accounts will also kick start a search full crawl .

Thanks for reading this post ….I hope this will help you fix this issue if you happen to come across this in your environment.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

http://sharepoint.stackexchange.com/questions/110417/sorry-this-site-hasnt-been-shared-with-you-when-trying-to-access-mysite

List of build numbers required to upgrade to the next on-premises version of SharePoint:

SharePoint-Upgrade-320x240.jpg

I guess it’s very important to check and ensure that your existing environment is running a version of SharePoint that can be upgraded to the next version while you’re planning for a SharePoint upgrade.

So keeping that in mind, I’ve prepared a list of the build numbers for various SharePoint versions that should help in planning the upgrade.

  • To upgrade from SharePoint 2007 to 2010, your SharePoint 2007 farm should be on this build number–> ( i.e. SharePoint 2007 SP2, build number (12.0.6421.1000) )
  • To upgrade from SharePoint 2010 to 2013, your SharePoint 2010 farm should be on this build number–> ( SharePoint 2010 SP1, build number (14.0.6029.1000) )
  • To upgrade from SharePoint Server 2013 to 2016, your SharePoint 2013 farm should be on this build number–>( SharePoint Server 2013 SP1 + March 2013 PU, build number (15.0.4481.1005) )

 Note: Also, please ensure that you fix the errors in the current environment itself before you upgrade to the next version as the errors will not be fixed once you upgrade to the next version of SharePoint. An error in SharePoint is an error on all the versions and just upgrading it won’t fix it.

Upgrade Methods to the next on-premises version of SharePoint:

The tabular column below should help you in choosing the right upgrade method if you’re planning to move to the next on-premises version

tabular column.png

Thanks for reading this post .Happy SharePointing!!!

 

 

 

 

 

 

Recording of my Webinar Session on SharePoint 2016 Overview

webinar pic.PNG

For those who missed my session on SharePoint 2016 overview, please find the link to the video recording below.

Part 1-Webinar on SharePoint 2016 Overview

Part 2- Webinar on SharePoint 2016 Overview

Thanks once again for attending my session and will see you all soon on a different webinar shortly.

Happy SharePointing!!!

Webinar on SharePoint Server 2016.

Hi All,

Please join me for a webinar on Jan 21st at 6:30 pm IST on ” Overview of SharePoint Server 2016” .

webinar-pic

Agenda:

  • SharePoint 2016 Overview & Focus areas
  • Software & Hardware Requirements to implement SharePoint Server 2016
  • What’s new & what’s deprecated?
  • Deep dive into MinRole,Feature packs and Zero Downtime Patching
  • Deployment Guidelines and Best practices for SharePoint Server 2016
  • Migration approach to SharePoint 2016
  • Recap & Conclusion

I’ll be discussing in detail Microsoft SharePoint Server 2016 and all it’s new features and functionalities.

Meeting details : http://www.c-sharpcorner.com/events/overview-of-sharepoint-server-2016

Resetting Search Index in SharePoint 2013:

searchadministration_thumb2

Search is indeed a mission critical service application in SharePoint and it’s very important that it remains healthy so that you get the results in the Search center whenever you execute a search query. However, it’s quite possible that you may notice some errors in the “Crawl log” stating that the crawler is not able to crawl the contents in the content source and at times it might get even worse such that you may notice all “failures” and no “success” in the crawl logs. In scenarios like that you might have to reset the search index so that the content in the index gets flushed away after which you need to perform a full crawl so that search index component receives the newly processed items from the content processing component and writes them to the search index. Of course, directly resetting the index is not a fix for any search related issue, please ensure that you do all the necessary troubleshooting steps from your end to identify and fix the issue and once you reach a point where nothing really helped, that’s when you should think about resetting the search index.

What happens when you reset the Search Index?

When you reset the search index, all the contents will be immediately removed from the search index and users will not be able to retrieve search results when they execute a search query on the search center.  Once you’re done resetting the search index, you must perform a full crawl on one or more content sources to create a new search index. Users will be able to retrieve search results again once the full crawl is finished and the new search index is created. So in a nutshell there will be a downtime when the search index is getting reset. After a search index reset, the full crawl won’t restore all the analytics features that are powered by the Analytics Processing Component. All the analytics results will be erased after resetting the search index.

When we should reset the search index?

As I already mentioned above, resetting the search index should be the final step of troubleshooting for any search related issue. However, based on my experience this when we should reset the search index ….

  1. Index is corrupted
  2. One or all index component status is degraded
  3. You crawl completed successfully but you are not getting the search results.
  4. When you move the index location
  5. When Index location run out of space.
  6. In a scenario where we have Index partitions spread across multiple servers and the indexed document count is out of sync. For example, we have 2 servers set as index partitions, server 1 has 150K indexed documents and server2 has 145k index documents
  7. If we make any changes to search topology such as removing the search components ,adding the components & activating a different search topology

 Alright, now let’s take a look at the steps to reset the search index …

Pre-requisites: 

Please ensure that you take care of the below mentioned pre-requisites before resetting the search index .Failing to do so will cause adverse effects and at worst case you may end up recreating the entire search service application.

  1. Make sure the crawl status for each content source is “Idle”. If any crawl is running, wait for the crawl to complete or follow the steps to “Stop the active crawls” below.
  2. Make sure continuous crawl for content sources is disabled [if applicable].This step is only specific to SharePoint 2013 and above.
  3. Make sure the crawl rate is 0
  4. Make sure background activity status is “None” on search administration page.

Stopping the Active Crawl(s):

  1. Navigate to search administration page.
  2. Click on Content Sources link towards your left hand side as shown in the image below.

4

3. If any content source is crawling, click on the drop down of the content source and click on “Stop Crawl”.

Disable Continuous Crawl:

  1. Navigate to search administration page.
  2. Navigate to Content Sources link appearing on quick launch.

4

3. Click on the drop down and select “Disable Continuous Crawl” to disable it.

5

4. Click “Ok” when below warning message appears.

6

5. Follow the same steps to disable continuous crawl for other content sources. Finally, all the content sources would show “Idle” status as shown in the image below.

7

Suspend Search Service Application:

This step is to ensure that there is no crawling activity in place while we perform the Index reset.

  1. Open SharePoint Management Shell using service account
  2. Run the below command.

Suspend-SPEnterpriseSearchServiceApplication “Search Service Application Name”

Note: If you don’t know the name of search service application, you can get it by running below command before executing the above command.

Get-SPServiceApplication | Where-Object {$_.TypeName –eq “Search Service Application”}

After suspending the search application, search administration page will show the status as “Paused for: External request” as shown in the image below.

8

 Ensure Crawl Rate is 0:

  1. Navigate to search administration page.
  2. Check the Recent Crawl rate.

9

Ensure Crawler Background Activity is none:

  1. Navigate to search administration page.
  2. Check the status of the Crawler background activity and ensure it shows as “none” as shown in the image below.

10

Once the necessary pre-requisites are taken care, please follow the below steps to perform an Index Reset.

There are 2 ways to perform Index reset.

Using UI [User Interface]: This method can be used when the indexed content in your farm is not much in size i.e. index size is not huge and also when you don’t have large content sources.

Using PowerShell: UI method is not recommended for SharePoint farms with large search index. [i.e. huge count of searchable/indexed documents]. Using the UI method in large farms for resetting the search index can result in time out error. In such cases, we need to use PowerShell method to reset the index.

USING UI:

  1. Navigate to SharePoint Central Administration.
  2. Under “Application Management” category, click on “Manage Service Applications”.
  3. Find out “Search Service Application” and click on the Search service application.
  4. In the quick launch, click on “Index Reset

reset-crawl-index-sharepoint-2013

5. Click on confirm once done .

USING POWERSHELL:

  1. Login to the SharePoint server using Administrator credentials.
  2. Open “SharePoint management shell” with elevated permissions.
  3. Run the below command to reset search index.

12

Post Index Reset Steps:

  1. Check whether the number of searchable items is 0.
  2. Resume the search service application by running the command shown in the screenshot below.

133. Enable “continuous crawl” for the content sources if it was enabled prior to index reset.

4. Run full crawl for the content sources one by one.

This confirms that you’re done resetting the Search index successfully and please keep monitoring the full crawl and ensure that it doesn’t get stuck in the middle. The time duration for the full crawl depends on the size of the content source, if you have very large content sources then it might take days for the full crawl to complete successfully. Once done, please verify the search results and ensure that they return fine. Also check the “Crawl log” and make sure you’re not seeing any errors this time.

Thanks for reading this post …..Happy SharePointing!!!

PowerShell script for generating the site collections list with multiple administrators

powershell.png

Running this script will generate a report which displays the list of site collections that has multiple site collection administrators and will also display the total number of users who have access to those site collections.

Add-PSSnapin microsoft.sharepoint.powershell -ErrorAction SilentlyContinue

Add-Content “Sites.csv” -Value “SiteCollection Name,SiteCollection URL, SiteCollection Administrators, Users Count,Usage in MB”

$webApp = Get-SPWebApplication

foreach($webapps in $webapp)

{

foreach ($SiteCollection in $webApps.Sites)

{

$url = $SiteCollection.Url

$webs = Get-SPWeb $URL

[boolean] $WriteToFile = $true

$weburl = $SiteCollection.OpenWeb()

$siteowner = “”

foreach ($siteAdmin in $weburl.SiteAdministrators)

{

$siteowner = $siteAdmin.DisplayName + “|” + $siteowner

}

foreach($web in $webs)

{

#Grab all users in the site collections

$siteUserCnt = $web.AllUsers.Count

$Siteurl = $web.Url

$siteTitle = $web.Title

$site = Get-SPSite  $Siteurl

$siteusage = $site.Usage.Storage/1MB

Add-Content -Path “Sites.csv” -Value “$siteTitle,$Siteurl,$siteowner,$siteUserCnt,$siteusage”

$web.Dispose()

}

}

}

Thanks for using this script …..Happy SharePointing!!!!

Recording of Webinar Session on SharePoint Architectural Models:

thumbnail

For those who missed my session yesterday , please find the link for the video recording below .

Webinar Recording on SharePoint Architectural Models

Thanks once again for attending my session yesterday and will see you all soon in different webinar shorlty .

Happy SharePointing!!!!

 

Feature pack 1 for SharePoint server 2016 is out:

1.jpg

Just in case you haven’t heard the news yet, Microsoft has announced the release of Feature Pack 1 for SharePoint server 2016 on November 2016 and this release brings several enhancements based on the recent innovations in Office 365. Please find the details below.

Listed below are the new capabilities that was introduced in this release:

  1. Logging of administrative actions performed in Central Administration and with Windows PowerShell.
  2. Enhancements to MinRole to support small environments.
  3. A new OneDrive for Business user experience.
  4. Custom tiles in the SharePoint app launcher.
  5. Unified auditing across site collections on-premises and in Office 365.
  6. Unified taxonomy across on-premises and Office 365.
  7. OneDrive API 2.0.

Now let’s take a look at all these capabilities in a detailed manner,

Administrative actions logging:

As SharePoint administrators we spend a considerable amount of time troubleshooting administrative changes in the on-premises environment, which can result in failure conditions or other undesired effects. So for this Microsoft has introduced more insightful, granular logging in Feature Pack 1. The Feature Pack 1 introduces the logging of common administrative actions performed in the Central Administration website and with Windows PowerShell.

MinRole enhancements:

One of the infrastructure advancements in SharePoint Server 2016 was the concept of MinRole. MinRole is designed to transform architectural guidance into code, simplifying deployment and scale with SharePoint by ensuring a request is served end-to-end by the receiving server based on the origin of the request (i.e., end user or batch processing) and role of the destination server.

MinRole was originally optimized for larger farm topologies. With four server roles, the minimal requirement for a supported MinRole configuration was a four-server farm. A farm with high availability (HA) requires two servers for each role, making eight servers the minimal requirement for a HA MinRole configuration. However, customers have reported to Microsoft that they would like to have the benefits of MinRole with smaller farm topologies too. We listened to you and enhanced MinRole to address this request.

Once the new MinRole enhancements are enabled, you will notice that two additional server roles are available: “Front-end with Distributed Cache” and “Application with Search.” The Front-end with Distributed Cache role combines the Front-end and Distributed Cache roles together, while the Application with Search role combines the Application and Search roles together. These new roles let you host a multi-server MinRole farm with just two servers or four servers with HA.

2

A new OneDrive for Business user experience:

OneDrive for Business is an integral part of Office 365 and SharePoint Server. It provides a place where you can store, share and sync your work files. OneDrive for Business makes it easy to manage and share your documents from anywhere, and work together in real-time, on your favorite devices. Feature Pack 1 brings the modern OneDrive for Business user experience to SharePoint Server 2016. The new OneDrive user experience is a Software Assurance benefit.

old-scale.png

 

 

SharePoint App Launcher custom tiles:

The App Launcher was introduced in SharePoint Server 2016 with the ability to extend the tiles with the SharePoint Hybrid App Launcher to include apps available in Office 365. The App Launcher provides a common location to discover new apps and navigate between on-premises SharePoint and Office 365 applications. Now, in addition to native SharePoint and Office 365 apps, you can also add your own custom tiles that point to other SharePoint sites, external sites, legacy apps and more. This makes it easy to find and navigate to the relevant sites, apps and resources to do your job.

4

Hybrid capabilities:

Unified auditing—Unified auditing gives SharePoint administrators’ detailed visibility into file access activities across all site collections, on-premises and in Office 365. With unified auditing in place, the Office 365 Security and Compliance Center can provide audit logs search for your SharePoint Server 2016 on-premises audit logs in addition to Office 365 audit logs.

This hybrid auditing capability—powered by Microsoft SharePoint Insights—enters preview with Feature Pack 1. Configuration is simple: a few clicks in Hybrid Scenario Picker wizard and you’re ready to start viewing and experiencing unified auditing.

Unified taxonomy:

SharePoint’s managed metadata service application makes it possible to create a taxonomy for information architecture across site collections and web applications. With Feature Pack 1, you can implement a unified taxonomy across a SharePoint Server 2016 farm and Office 365. You can seed the term store in SharePoint Online from your on-premises term store and then manage your taxonomy in SharePoint Online. Replication to on-premises SharePoint is performed by the hybrid taxonomy feature.

Developer enhancements:

OneDrive API 2.0—The OneDrive API provides a common API for access to files located on-premises and in the Office 365 cloud. The API provides access and enables developers to build solutions that target user data stored in OneDrive for Business and SharePoint document libraries

Things to know about a Cumulative Update:

sharepoint2013

In addition to the SharePoint patching installation guide that was published by me few days back I’ve come up with a new article that gives a detailed description about what a Cumulative Update is all about and the things you need to know about a CU.

Please find the details below …

What is a CU?

A  CU (i.e. Cumulative Update) is a software package which includes fixes for problems with Microsoft products that have been reported by customers to Microsoft support in the form of support cases.

What is included?

As the name says, the updates/fixes that are included in the package are always Cumulative (meaning, it includes all the new and all previously released fixes (CUs and PUs) since the oldest supported service pack (within the first 12 months after a Service Pack has been released the CU includes also fixes released after the previous service pack).

How often does Microsoft release SharePoint Cumulative Updates?

Microsoft releases Cumulative Updates (CUs) once in every month.

How does Microsoft test Cumulative Updates before deployment?

All Cumulative Updates are tested extensively before each public release. If an issue, such as a regression, is discovered on a CU that could potentially impact the application, the CU will be cancelled and will be rescheduled to a later CU.

Are CU’s Multilingual?

Yes. The CU package includes fixes for all the languages. So no matter whatever language you download the CU package on, the fixes/updates in the package will remain the same.

What is the prerequisite?

The oldest supported service pack. For instance, all the SharePoint CU‘s post the SP1 release need the SP1 to be installed for SP 2013 .In case of SP 2010, all the CU’s that were released post SP2 need SP2 to be installed first after which you can install those CU’s .

When to install?

CU’s should only be installed to resolve specific issues fixed with the CUs as mentioned in each CU KB article: “Apply this hotfix only to systems that are experiencing the problems described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.” Or if advised to install by Microsoft Support.

Impact on future fixes: In general, a CU is not a prerequisite of future CUs and PUs. However this may not be the case always .There has been few scenarios where a CU that was released few months back tends to become a pre-requisite for the later CU’s. So before installing any CU please take a look at the related KB article and make sure you have all the necessary pre-requisites in place.

Installation sequence: Installing the CU doesn’t require any specific order, you can do it on any server in the farm and then go on by installing it on other servers in the farm (meaning you can do it on the WFE server first and then on the APP server). Although it’s ok to go ahead and install the CU in any order on the server based on my experience with installing the CU I would suggest you to do it on the WFE server first. Ensure that the WFE is taken out of the Load balancer pool so that it’s not serving user traffic and then go ahead and install the CU and reboot the server. Once the server comes back online verify whether all the components have been installed correctly under Control Panel and the Central administration site is accessible. This is just to ensure that the installed CU didn’t do any harm to the server. It’s ok to lose a WFE but not a APP server, I hope you’re getting the idea here J .Also by any chance if you’re patching the farm on the business hours (which might ideally not be the case unless it’s a TEST /UAT farm) then make sure that the server on which you’re installing the CU is taken out of the load balancer so that the user traffic doesn’t goes to that server. So, the idea to keep in mind is, do it on the WFE servers first and then on the APP server.

Running the SharePoint Configuration Wizard:

Unlike the CU installation you can’t run the “SharePoint Configuration Wizard” in any order, it must be running on the server which is hosting “Central Administration” site first and then on the WFE and APP servers.  It’s a 6-step process which might take an hour at the max (in an ideal scenario) to run and complete. Once it’s completed successfully on the server where CA is hosted, please try opening the CA site and make sure everything looks fine and make sure you’re able to access the SharePoint sites. By any chance if the CA site is not coming up, please stop right there and fix it. Without fixing the CA site issue, please don’t proceed further with running the Configuration wizard on the other servers. This is the basic thumb rule to be followed while patching a SharePoint farm. You need to follow the same procedure for all the servers in the farm.