Comments have been closed on this page. Please use AppMon & UEM Plugins forum for questions about this plugin.
We have recently updated the FastPack to leverage the latest features of dynaTrace and also tested it with SharePoint 2013. We also provided a package for dynaTrace 6 and 6.1+. A SharePoint blog that guides you through all the steps is in the works! A video on YouTube is already available: SharePoint Performance Analysis with Dynatrace in 15 Minutes.
Get your free license
Microsoft SharePoint FastPack
4.x, 5.x, 6.x
Tested with SharePoint 2007, 2010 and 2013
Andreas Grabner (email@example.com)
Community Supported For questions:
WATCH the YouTube Video on using this FastPack
SharePoint FastPack for dynaTrace 6.1+ (latest)
SharePoint FastPack for dynaTrace 6.0
SharePoint FastPack for dynaTrace 4.x + 5.x
The Performance Dashboard highlights the most interesting performance aspects of a SharePoint Deployment:
The Usage Dashboard helps you to understand which Lists and Views are heavily used and which ones may indicate a problem, e.g: too much load on a List results in high error rates or long response times. In order to answer these questions simply sort the View or List Response Table by Count, Failed % or Response Time.
On the Dynatrace Blog the following posts give a good overview of the FastPack and give additional hints about problematic areas in SharePoint applications:
The Download Package includes everything you need to manage SharePoint Applications:
Follow the following Steps:
Feel free to contribute any changes on Github
Hi - will this work with SP2013? Thanks
it should! - The core classes and interfaces havent changed in SharePoint in the recent years thats why the FastPack should still work. Please let us know how it works out for you
After importing the fastpack I noticed that the dashboards for sharepoint usage does not show metrics for slow and very slow columns
I noticed that on the PurePath measure for these there are no threshholds set for Slow and Very Slow. Are they required to be set manually for each site, or should there be a default value in them?
The FastPack was built a while ago and comes with a System Profile that has different default/out-of-the-box settings than one you would create fresh. Thats an indicator for me that we should update that FastPack or - instead of relying on the System Profile that comes with the FastPack you could try the following
a) create a new System Profile
b) import the FastPack
c) Copy Sensors and BTs from the Imported System Profile over to your new one -> that ensures that you have a System Profile that contains the correct default/OOTB settings
That is exactly what I did.
My question was more about the fact that the measures had no threshold set, are these required to populate the BT correctly?
The BTs do not require these thresholds. They are splitting by specific URL patterns to extract view and list names of SharePoint
We tried to use this FastPack with our new SharePoint 2013, but the SharePoint Adam claims that DynaTrace caused the SharePoint's Microsoft usage statistics feature to stop working.
Do we have some clue on why this would have caused, can this be tested in 2013 version.
Identifying the issue will help us ensuring that this is only SharePoint issue and nothing to do with DynaTrace and other .net applications.
I cant really think of anything that would cause some of our instrumentation to cause this problem. Do we know how that feature in SharePoint works? I assume they just keep their own internal metrics and expose it through a web ui or through a performance counter? What exactly is it that doesnt work any longer?
Not sure on how that feature works on SharePoint, but we are going to give it another try, we had to remove DT agents due to this issue sometime back.
This time we are prepared to spend more time in troubleshooting and getting this fixed.
Could this be that the the SharePoint feature works as profiler and DynaTrace wins.
Let me know if you need me to check anything on the SharePoint side while we work on this.
Could be that they are also using the same intereface - but I doubt it. Check for any suspiscious exceptions - maybe there is some indication on why that feature doesnt work
This time it worked and no issues reported. We are in dynaTrace v5.6 this time.We are now monitoring SharePoint 2013.
Thanks for the update. Odd though that it failed in the beginning - but good to know that it probably isnt us.
If you make any modifications to the Sensors or Dashboards for SP 2013 let me know. I would be happy to update this FastPack to better support the latest versions of SP
Has this FastPack been tested on dynaTrace 6?
Not officially tested but nothing has changed in terms of FastPacks from 5.x to 6. Please give it a try and let us know if it works. I am 100% sure it will
In dT 6.0 we have imported the plugin with out errors - we don't see the "Sharepoint" system profile however we do see the dashboards.
Hi. I've uploaded a new package that works with dynaTrace 6. Thanks for letting us know
Thanks! I see the system profile now.
Andreas, need some clarification. have dT5.5 imported plugin. on agent side defined the app pool the application group specified as Sharepoint_UAT_00?. That picked up 3-4 extra worker proceses which is the first time I have seen that. Secondly the profile loaded will capture what I defined in the SharePoint agent group but not sure about the webserver_sharepoint agent group . Just want to make sure we are capturing everything. Cant tell anything yet the need to restart
What process do I go after for the webserver_sharepoint pieces. This is web server as well.
Is there a stored session file using the SharePoint Plugin anywhere?
Devin, There is now a stored session in the APM Demo system titled "SharePoint 30Mins".
Thank you, Joe!
What populates the Sharepoint List and View monitoring? It says that no measures are selected. Is it driven my UEM?
Hi. It is driven by two Business Transctions that split by a common SharePoint URL Pattern for Lists and Views. If it doesnt work for you I would be interested in looking at your SharePoint PurePaths. We could then update these BTs to also work with your URL patterns. Feel free to share your session with me through my Share your PurePath program
I am looking at it now, the business transactions actually are under a different profile. We added the sharepoint sensors to our main profile but the business transactions are under the default sharepoint profile. It also shows that I do not have permission to edit the system profile or copy the business transactions. I am going to try opening a second window and manually create the business transactions, should this fix the dashboard?
You can copy/paste these Business transactions. Simply edit the "SharePoint Profile" and copy hte BT there. Then edit your System Profile and PASTE it in there. The DAshboard that comes with the FastPack rely on the existance of these BTs in your System Profile where you capture the SharePoint PurePaths
It is telling me that I have no permission to change this profile. When I select a bt they are greyed out.
Then I hope you find somebody that has the privileges. Thats required to make that change
thanks for the great fastpack.
Just a quick question: isn't the API Definition missing in the contained System profile? E.g. there are some API measures pointing e.g. to ASP.NET WebPart. Also, there is a filter used on that API in the dashlet "Critical Webparts" of dashboard "SharePoint Performance". This filter is not available since no APIs are defined within the system profile, pointing to what are the webparts. I observed this in the latest fastpack version for DT 6.1. I think this is why I dont have data in "Critical webparts".
The API definitions in the profile are not required in order to see Critical Webparts on the dashboard. If you don't see any, I would guess there are no such items running in your system, or possibly you don't have the ASP.NET Events sensor placed and active.
An example of this sensor working correctly can be confirmed by opening the SharePoint Performance dashboard in the APM Demo system and observing the data from the saved session "SharePoint" that is located on the APM Demo system. In this situation, you can observe several Critical WebParts and confirm that session does not have any user defined APIs specified.
The "ASP.NET WebPart" API definition comes from the ASP.NET Events Sensor where it has a rule for System.Web.UI.WebControls.WebParts.IWebPart namespace where it has rules for methods such as Render*, On* and more which are defined to be associated with the "ASP.NET WebPart" API definition.
alright, thanks for the input. I will check on this.
I guess it is the ASP.NET Event sensor. It is currently deactivated and I am in the process of activating it. Thanks for that hint!
Suppose I have 5 servers running on share point and I have 100 number of applications. So I have some 70 applications on IIS and 30 applications on .NET. How many license is required for monitoring these 100 applications?
.NET licensing is based up on the number of WOSIs (Windows Operating System Instances). So in this situation you need 5 .NET agent licenses. The number of apps is not relavent when considering licensing. But you also have IIS, so you'll need a WebServer license to cover IIS instances.
I suggest you discuss this with your local Dynatrace sales executive to ensure a proper fit for your needs.