cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

What exactly to instrument for SharePoint and CRM?

sgreenshield
Inactive

I haven't done any Dynatrace deployments
for Sharepoint or CRM before, but I know they are both supported (SharePoint
with fastpack) and I have seen other forum posts regarding both apps.

I am about to do a couple of Dynatrace
deployments for them and I have some general questions on instrumentation:

Deployment
1

1st tier - SharePoint 2013 Web front end
tier

a)
IIS websites for:-

  • The main "SharePoint"
    App
  • SharePoint Web Services

b)
5 .NET App Pools for:- (I think for Search, Crawl ,User session and Application
search)

  • The main "SharePoint"
    App
  • Topology
  • SearchServices
  • SubscriptionService
  • SecurityTokenAuthentification

2nd Tier - SharePoint 2013 Back End App
tier

a)
IIS website for:-

  • SharePoint Web Services

b)
4 .NET App Pools for:- (I think Search, Crawl ,User session and Application
search)

  • Topology
  • SearchServices
  • SubscriptionService
  • SecurityTokenAuthentification

3rd Tier - Embedded Application Web
server Tier

a)
6 different Embedded websites

b)
6 .NET IIS App Pool worker process coupled to the websites

4th Tier - Embedded Application App
server (for Web services)

a)
6 different Embedded web service websites

b)
6 .NET IIS App Pool worker process coupled to the web service web site


Deployment
2

1st tier - SharePoint 2013 Web frontend
tier

a)
IIS websites for:-

  • SharePoint Web Services
  • The main "SharePoint
    App"

b)
3 .NET App Pools for

  • OWSTIMER:- SharePoint Timer
    Service
  • WSSADMIN:- SharePoint Admin
    Service
  • WSSTRACING SharePoint Tracing
    Service

2nd Tier - SharePoint 2013 backend App
tier

a)
IIS website for:-

  • SharePoint Web Services
  • SharePoint Central
    Administration v4

b)
3 .NET App Pools for

  • OWSTIMER:- SharePoint Timer
    Service
  • WSSADMIN:- SharePoint Admin
    Service
  • WSSTRACING SharePoint Tracing
    Service

3rd Tier - CRM Web server front end tier

a)
IIS websites for:-

  • WebAppExternal
  • WebAppInternal
  • MS Dynamics CRM

b)
6 .NET App Pools for

  • CrmAsyncService
  • MSCRMAsyncServicemaintenance
  • MSCRMMonitoringService
  • Microsoft.Crm.Sandbox.HostService
  • CrmUnzipService
  • Microsoft.Crm.VSSWriterService

4th Tier - CRM backend App Tier

a)
4 .NET Processes:-

  • CrmAsyncService
  • MSCRMAsyncServicemaintenance
  • MSCRMMonitoringService
  • Microsoft.Crm.Sandbox.HostService

For SharePoint what are the best practices,
should we only instrument the main app website and it's coupled app pool (like
in the Dynatrace Sharepoint you tube example by Andreas) or should we be doing
the other SharePoint web services and .NET process? I guess its knowing if they
are critical to the SharePoint application, which I am not sure? I know the
Embedded application tiers in Deployment 1 is key to be monitored, but we are
not sure about all the SharePoint Web service, etc.

What about the CRM in the second deployment....
is this a similar thing to SharePoint, as in do we have to monitor all their .NET
processes?

Can anyone provide any best practices/recommendations
on what we should look to instrument on both SharePoint and CRM implementations?

10 REPLIES 10

andreas_grabner
Dynatrace Guru
Dynatrace Guru

Hi

I think the more you can instrument the better. But - if that is too much for the beginning I would start with IIS and the SharePoint related AppPools. Simply start by deploying the .NET Agents. If you want you can also use the FastPack which comes with some extra sensors and some dashboards. In general you should however already get great visiblity just with the default set of .NET Sensors placed when you setup a new Dynatrace System PRofile.

As for CRM. Same thing: definitley start with IIS and the Web AppPools. also check out this blog. It is quite old -but hopefully still useful: http://apmblog.dynatrace.com/2010/09/02/top-3-perf...

Andi

sgreenshield
Inactive

Hi Andi,

I was thinking just to inject everything as an evaluation/test within the application PreProd environment to see what traffic we see and then re-review what is needed moving forward in Prod and licensing.

With the SP FastPack, I saw in your youtube overview you just injected the main application website and .NET process, but if we inject all the additional SP website and .NET processes I guess I'll need the extra SP sensors also enabled on them.

The CRM blog link is an interesting read, and gives me a brilliant insight in what maybe to look out for with the CRM App.

Thank you for your advice.

Stuart

You will get some additional visibility by also applying the SharePoint FastPack to these other components - however - these SharePoint Sensors I built are specifically intended for the SharePoint Web Apps. These Sensors capture CAML queries and some interaction with the SharePoint Object API. Keep me posted in case you find some interesting purepaths.

sgreenshield
Inactive

Hi Andi,

Thanks.

We have deployed on CRM backend nodes.... but don't see any purepath traffic. The CRM back end app server has .NET window service processes although we see in the process health data we can't see any purepaths.

e.g the Non IIS .NET:-

Microsoft.Crm.VssWriterService.exe

Microsoft.Crm.Sandbox.HostService.exe

Microsoft.Crm.Sandbox.WorkerProcess.exe

CrmAsyncService.exe

WF.InterfacesHostService.exe

So for example we know that the WF.InterfacesHostService.exe Windows service receives web request direct (not via IIS or the IIS CRM APP Pool direct on the App Server) and then it s code deal with it and then creates web requests that follow back to the CRM Frontend web servers, which we can see?

Is it normal for the non IIS .NET processes that are injected not see any purepaths but only the process health? Or am I complete missing something and we need to add more sensors?

I believe these CRM backend in the app deals with plugin that then query thing like MQ Rabbit.... but I see that is effectively a plugin

Thanks Stuart

Hi Stuart

I suggest you double check your System Profile and the settings for your .NET Specific Sensor Packs that would start a PurePath. The following Sensor Packs can be configured with "Active and start PurePath": .NET Remoting, .NET WCF, ASP.NET, .NET Web Services, MSMQ, MQSeries. Make sure that these sensors are placed for your agent group and also set to "active and start purepath". that shold do the trick.

If you still dont see PurePaths it means that these .exe are using non-standard web request frameworks. In that case I typically do a CPU Sampling to figure out which methods are called. Feel free to share such a CPU Sample with me. happy to look at it

andi

sgreenshield
Inactive

Ok, thanks, I had configured yesterday all the possible sensors to be "active and start purepaths".... and we still don't ever see the purepaths or web requests on the node in the transactions flow.

I will attempt to get a CPU sampling of with the .NET interface process running with a load.

sgreenshield
Inactive

Hi Andreas,

I have a validate CPU sampling file which seems to show the method which pertains to the Interface and the method stack.

Where can I upload it to or can I sent it to you direct?

Stuart

Follow these instructions: http://bit.ly/sharepurepath

jose_iglesias
Dynatrace Organizer
Dynatrace Organizer

Hi, guys.

I've an opportunity that involves MS Dynamics CRM and I'd like to know if finally you could find a sensors that bring useful information and purepaths.

Thanks!

JMI

Hello Jose,

The dynaTrace FastPack for the Microsoft SharePoint (both Windows SharePoint Services and Microsoft Office Share Server) enables faster analysis of SharePoint Applications by providing specific Sensor Packs and Dashboards to identify problems in custom WebParts, SharePoint Lists & Views, usage of CAML, ...

https://community.dynatrace.com/community/display/DL/SharePoint+FastPack

Regards,

Babar