Great opportunity for Office 365 folks:

office 365.png

Microsoft has  planned and set up 8 different Office 365 Labs webcasts that will be delivered during September and these are the topics that will be discussed in the webcast.

1. Office 365 Labs – Using PowerShell to automate tasks
2. Office 365 Labs – Mastering Azure AD Connect
3. Office 365 Labs – Mail flow
4. Office 365 Labs – Getting the best out of Outlook and Exchange Online
5. Office 365 Labs – OneDrive Synchronization 101
6. Office 365 Labs – Sharing and collaboration with internal and external users in SharePoint Online
7. Office 365 Labs – AD FS and multi-factor authentication explained
8. Office 365 Labs – Exchange Online compliance features (In-Place Archive, In-Place Hold, eDiscovery)

Please use this link below to enroll yourself for these sessions

Office 365 Labs webcasts coming in September


Clearing the myths between Request Management service in SharePoint 2013 and Network Load balancer:

Alright. So the heading of this article would have pretty much given a brief explanation about what this post would be about and hence I’m not going to write a brief introduction session here about this post. I’m pretty sure that a lot of SharePoint Geeks out there have written a lot about Request Management service in SharePoint 2013 and Load balancer configuration for a SharePoint 2013 farm, however there seems to be a lot of confusion among SharePoint practitioners in understanding the difference between these two .I didn’t mean to offend anybody here but the features and functionalities of these two are so similar so that anybody would possibly get confused. So in this post I’ll be explaining what these two mean in detail and how they differ from each other (meaning where the boundary for Request Management service stops when compared to a load balancer).

Now let’s get into the meats and potatoes ….

1. Request Management service in SharePoint 2013 :

For those who are new to SharePoint 2013 or if you’re hearing about “Request Management service”  for the first time , please go ahead and take a look at my blog post on Request Management service .  I’ve given a detailed explanation on what “Request Management service” is all about and how it works. However, to put it in simple words….Request Management service take care of managing  incoming requests by evaluating the logic rules set against them in order to determine which action to take, and which machine or machines in the farm (if any) should handle the incoming requests . Now there’s a lot of mechanism which happens in RM service, please take a look on Spencer Harber’s article on Request Management service to know about that in detail. As always Spencer has did a fabulous job in explaining it on detail.

In addition to this there are couple of other important points that one should be aware of as far as Request Management service is concerned.

  1. Request manager is the first code that runs in response to HTTP requests. It is implemented in SPRequestModule
  2. Request Manager requires the SharePoint foundation web application service to be started on the server.
  • Request manager service should only be started on a server that’s acting as a WFE, else it’s of no use.


2.Load balancer for SharePoint :

Now as you’re aware high availability in SharePoint is achieved in the web tier level by deploying multiple front end servers to serve web pages and host web parts. A load balancer directs traffic across these servers, monitors health and ensures that the best possible target is used for individual requests. The default SharePoint architecture works in such a manner that any server in the farm which has the “SharePoint foundation web application service “turned on will be acting as a Web Front end server. Hence you can go ahead and turn off this service on a server that is acting as an App server. However, if your servers have enough resources then there shouldn’t be any harm on leaving it on, as in case if you WFEs go down you can let APP server handle user web requests temporarily.


Now let’s discuss on how they differ from each other so that we don’t get confused by their similar functionalities:

The first thing which we need to understand is that the Request Management service becomes effective only when the user request gets passed the Network Load balancer which takes care of handling user traffic . As you’re aware the NLB is the one which takes care of handling user traffic and if a user’s request doesn’t even gets passed the load balancer then technically it means that the user’s request is not hitting the SharePoint farm where the Request management service is configured .To put it in simple words the user’s request need to pass the 1st gate which is the NLB and only upon the successful completion of that the user’s request will hit the appropriate Web front servers where the Request Management service will be configured . So once the user’s request hits the SharePoint farm then the RM service will validate the request and will then act accordingly. I believe the image below will give you a clear understanding of how this is configured for a SharePoint 2013 farm.

Dedicated mode:

3.jpgIntegrated Mode:


In both the modes you can notice that the user traffic first has to go through the HLB before it reaches the SharePoint 2013 farm where the Request Management service is configured. Now if you’re more curious in understanding the difference between the above said two modes ….In the first mode (i.e. Dedicated mode) you will have a SharePoint farm configured only for Request management service (meaning all the servers in that farm will have only the RM service turned on the WFE’s) .In this mode the SharePoint farm which has the RM service configured will be configured in such a way that it’s kept between the LB and the actual PROD server where the user’s content exist. The second one is called the (Integrated mode) where you will find the RM service being turned on all the WFE servers in the SharePoint farm. The first mode is pretty expensive bearing in mind the license costs and will be mostly used in very large SharePoint farm implementations .The second mode is pretty affordable because in this mode all the WFE servers which are part of the actual farm will have the RM service turned on in it.

To conclude RM service and NLB/HLB are two different things altogether and they don’t suffice the same purpose .The NLB/HLB takes care of sending the user request to the appropriate WFE’s whereas the Request management service takes care of how to handle that incoming request which is sent to the WFE server . Both these are optimal for any successful SharePoint implementation.

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


Fix for follow web part broken issue in SharePoint My site:

Alright as mentioned in my previous blog post , we heard back from Microsoft about the fix for this issue and looks like Microsoft will be rolling out the fix for this in October 2016 CU for SharePoint server 2013. So if you’re facing this issue in your environment please wait for October 2016 CU as that should include the fix for this.

Happy SharePointing!!!

foloow 1

SharePoint 2013 –Followed count webpart stopped working in My site:

This post is related to a known issue which most SharePoint professionals might have experienced after patching your SharePoint 2013 farm with August 2015 CU . I hope everyone would agree that it was one of the most expected CU during the time of its release as this introduced the Hybrid search functionality in SharePoint 2013 ( meaning : If you want to deploy Hybrid search between SharePoint 2013 and Office 365 then your farm should be patched with August 2015 CU ) . In addition to that, it also broke some other functionalities and I’ve also blogged about that (please check this link for that) .Now in this blog post we will be discussing about a known issue which we recently happened to encounter in our SharePoint 2013 farm.

The issue which I’m talking about here is something which you might have experienced for yourself when you try to access your SharePoint My site and may be your end users might have reported about this behavior to you. When you try to open the SharePoint My site you would end up getting an error message as shown in the screenshot below.

foloow 1

Now inorder to temporarily get rid of this you can use SharePoint designer and close this webpart so that your end users won’t be seeing this annoying error message when they access their My site. As you already know the “followed count” web part in your SharePoint My site displays all the sites you follow. From here all the sites you follow in SharePoint are just a click away.

As the initial phase of troubleshooting this issue ,we turned on verbose logging and grabbed the logs to understand what was causing this and we found these entries in the logs.

System.NullReferenceException: Object reference not set to an instance of an object.  

 at Microsoft.SharePoint.Portal.WebControls.FollowedCountsWebPart.GetHybridSpoUrl(UserProfile profile)   

 at Microsoft.SharePoint.Portal.WebControls.FollowedCountsWebPart.RenderWebPart(HtmlTextWriter writer)   

 at Microsoft.SharePoint.WebPartPages.WebPart.Render(HtmlTextWriter writer)   

 at System.Web.UI.Control.RenderControlInternal(HtmlTextWriter writer, ControlAdapter adapter)   

 at Microsoft.SharePoint.WebPartPages.SPChrome.RenderPartContents(HtmlTextWriter output, WebPart part

However, all the possible troubleshooting steps we tried was not getting us any closer to fix this issue. Of course we googled about this and found that this functionality was broken after the August 2015 CU for SharePoint 2013 is installed in your farm but we didn’t expect it to remain the same even after patching our farm with Jan 2016 CU . As we were helpless we decided to open a case with Microsoft premier support and that’s when things started getting interesting. Microsoft analyzed all the logs and informed us that the same behavior was identified for SharePoint online portals too and an internal fix was rolled out by Microsoft sometime around August 2015 and was later globally deployed on September 2015. So SharePoint online users will never see this issue.  But looks like this fix was not involved on any further CU‘s for SharePoint server 2013.  However, the same fix was also applied for SharePoint server 2016 in May 2016 CU for SharePoint server 2016 where the error was something like this ….

FollowedCountsWebPart.GetHybridSpoUrl (UserProfile profile)”

So now the only problem is with SharePoint server 2013 as the fix has not been developed for this yet.  If you take a look at the “Improvement and fixes section” for Feb 2016 CU for SharePoint server 2013 you will notice a fix for a “follow” issue but that doesn’t look similar to our scenario here. That speaks about the “follow” functionality getting broken on a multi-farm environment. Check the screenshot below ….

follow 2.png

But the support engineer said that the same fix should work for this scenario also, however he is yet to check with the PG team on that.  As per the latest update from the support engineer our case is being taken over by the PG team for their review.  I’ll write an update on my blog site once I hear back from Microsoft.

How badly can AV scanning impact your SharePoint farm’s performance?

In this post I’ll be talking about an issue which we recently encountered in one of our customer’s SharePoint 2010 environment. Let me talk about the issue first, then how we fixed it and later the lessons we learned from it.

Issue we faced:

Couple of days back we received huge number of support incidents from users across the globe stating that they were not able to access the SharePoint portal .For some reason the issue was intermittent , the site used to load fine at times and all of sudden it stopped loading . We decided to login to each WFE servers in the farm and identify which was throwing the bad request .Listed below are the steps which we did initially to identify the root cause ….

Troubleshooting steps done by us initially:

  1. Tried loading the problematic site from our end and checked whether we’re able to reproduce the issue from our end.
  2. Once we confirmed that we were able to reproduce the issue we changed the host file entry to point to all the WFE’s in the farm and tried to load the site .This was done to identify which WFE server threw the bad request.
  3. During this process we happened to notice some abnormal behavior in two servers (i.e. WFE1 & WFE 2) of the SharePoint farm .The CPU/RAM utilization in these two servers were continuously hitting 100% and because of that all the requests going to these servers were failing. The server was almost in an unresponsive state.
  4. We took a look at the event viewer and found many entries related to Mcaffee Anti-virus software update process getting failed. Then I opened the Mcaffee console to understand what’s happening and as expected I could find many update failures .I pulled the Mcaffee logs and found many entries related to that.
  5. In addition to that we also noticed entries in the ULS logs about the SharePoint farm trying to run a configuration change by itself and it was also invoking an upgrade process. The w3wp.exe SharePoint worker process was also consuming heavy RAM.
  6. Now given the fact that we noticed so many weird entries in the logs we planned to reboot the server and see if that helped. Any yes it helped and the issue was no more.
  7. However, the server reboot was just a week around and we wanted to identify what exactly triggered this as we noticed some weird entries in the SharePoint logs about automatic configuration change and upgrade process .Hence we decided to open a support case with Microsoft for a detailed RCA.

Now let’s take a look on what Microsoft had to say to us about this issue ….

Troubleshooting steps done by Microsoft:

We captured the ULS logs on the exact time the issue was reported and shared the same to Microsoft (please note that this issue which we are currently talking about is a non-reproducible one, meaning: we were not able to reproduce the same behavior to Microsoft as this happened only once, after the server reboot everything looked normal). Microsoft analyzed the logs and this is what they found ….

A huge performance issue was identified as you can see in the logs image below:


AppDomain recycling was happening very frequently as you can see in the screenshot below:



The App domain recycling was happening on both the WFE’s as shown in the ULS logs screenshot below:


What we identified after analyzing the logs?

Now based on the above analysis we identified that the root cause of this issue was that the AppDomain recycle was happening very frequently. This is an isolation process within the W3WP process of the web application. This process went on recycling and that caused the performance issue of the environment.

The possible root cause for this App Domain recycle can be because of the below mentioned two reasons …

a) AV exclusions are not implemented in your SharePoint farm as per the article below. Certain folders may have to be excluded from antivirus scanning when you use file-level antivirus software in SharePoint

b) The application restarts may occur in some situations if any processes accessing Web.config file in the root of the application, the Machine.config file, the Bin folder, or the Global. asax file.

In our case it’s the first one where we didn’t exclude the necessary files/folders from AV scanning and hence we decided to exclude the folders/files as mentioned in the aforementioned article. These are SharePoint system related files/folders and they have to excluded from AV scanning , else when a scheduled full scan kicks off in your SharePoint farm it will start scanning these files too and this will impact the performance of the SharePoint farm .

Lesson’s learned:

If you’re planning to install Antivirus software in your SharePoint farm, please make sure that all the folders mentioned in this article are excluded from getting scanned .These are SharePoint system related files & folders and every time the AV scan engine tries to scan these files it puts the farm on risk as the scanning process will interfere SharePoint’s operation .

Thanks for reading this post!!!   Happy SharePointing.







Part 2: Useful Office 365 cmdlets to generate SharePoint Online reports and also for SharePoint Online site administration:

Followed to my previous article about useful office 365 cmdlets in SharePoint Online, in this article I’ll be showing you some more useful PowerShell cmdlets to generate SharePoint Online reports /SharePoint Online site administration. I see a lot of misconception with my fellow SharePoint workers on understanding the difference between SharePoint on-premises cmdlets and Office 365(SharePoint Online) cmdlets, please note that they all don’t have the same functionality even though they almost look similar. There is a lot of difference in what they exactly do, so please pay close attention while utilizing them.


So let’s get into the real meats and potatoes now…

  1. To create a new SPO Site collection:

SyntaxNew-SPOSite -Url -Title “Vignesh” -Owner “” -Template “STS#0” -TimeZoneId 10 -StorageQuota 200


Note: In the above mentioned command you need to specify the URL of your new site collection, Title Name, Template ID, Time Zone and Storage quota size. Please check my previous article on SharePoint Online command to get to know about SharePoint Online Template ID’s

Running this command will create a new site collection in SPO and you can verify this in your SPO admin center as shown below.


2.To list the groups, and all the group memberships, for all of your SharePoint Online sites.


$x = Get-SPOSite


foreach ($y in $x)


        Write-Host $y.Url -ForegroundColor “Yellow”

        $z = Get-SPOSiteGroup -Site $y.Url

        foreach ($a in $z)


                 $b = Get-SPOSiteGroup -Site $y.Url -Group $a.Title

                 Write-Host $b.Title -ForegroundColor “Cyan”

                 $b | Select-Object -ExpandProperty Users




Running the above mentioned command will display the results as shown below,


3.To list the groups, and all the group memberships, for a single site collection:


First let me assign the $siteURL variable to the site collection in question.

$siteURL = “”–> Site in question.

$siteURL = “”

$x = Get-SPOSiteGroup -Site $siteURL

foreach ($y in $x)


        Write-Host $y.Title -ForegroundColor “Yellow”

        Get-SPOSiteGroup -Site $siteURL -Group $y.Title | Select-Object -ExpandProperty Users



Running this command will display the results as shown below .


 4.To lock a SharePoint Online site:

SyntaxSet-SPOSite -Identity $site -Lockstate NoAccess

Specify the $site variable to the site which you want to lock.


Running this command will lock the site and when you try to access it you will get a 403 Forbidden error.

5.To unlock as SharePoint Online site:

Syntax:  Set-SPOSite -Identity $site -Lockstate Unlock


This will unlock the site that we just locked in the previous command.

6.To disable external sharing for a SharePoint Online site collection:


$siteURL = “”–> Site in question

Set-SPOSite -Identity $siteURL -SharingCapability Disabled


You can verify this in your SharePoint Online admin center as shown in the image below. The site in question will have external sharing disabled as shown below.


7.To enable external user and guest sharing:


Set-SPOSite -Identity $siteURL -SharingCapability ExternalUserandGuestSharing


Running this command will enable external user and guest sharing in a SPO site collection and you can verify that in the screenshot below.


Note: By default, this feature will be disabled for SPO sites and this has to be enabled if required.

8.To enable only external user sharing:

Syntax:  Set-SPOSite -Identity $siteURL -SharingCapability ExternalUserSharingOnly


 Running this command will only enable external user sharing in a SPO site collection and you can verify that in the screenshot below.


9.To get the list of sites where sharing capability has been enabled:

Syntax:    Get-SPOSite | Where {$_.SharingCapability -ne “Disabled”}


  1. To get the list of sites where sharing capability is disabled:

Syntax:  Get-SPOSite | Where {$_. SharingCapability -eq “Disabled”}


 11.To change the owner of site:


First let me assign the $siteURL variable to the site collection in question.

$siteURL = “”–> Site in question

Set-SPOSite -Identity $siteURL -Owner “”


12.To change the storage and resource quota of a site:


Set-SPOSite -Identity $siteURL -StorgaeQuota 1000 -ResourceQuota 500

13.To change the Title of the site:


Set-SPOSite $siteURL -Title “New Title”


This will change the title of the site in question. You can verify this below.


Thanks for reading this article. This is all I have for this post and I’ll be back with Part 3 of this article very soon.

Happy SharePointing !!!