IntelliTrace Standalone Collector and Application Pools running under Active Directory accounts
You will often configure an ASP.NET web site to run as an Active Directory (AD) user so that the site can access that user’s network resources (e.g. a file share). This is accomplished by changing the identity of the IIS Application Pool the web site runs under.
If you try to use the IntelliTrace Standalone Collector with such an application pool while you are logged in with a local user account (i.e. a non-AD user account) you will get this error message:
User <domainusername> does not have permissions to read collection plan file “C:WindowsTempDefaultAppPool_collection_plan.ASP.NET.default.xml”
This error message is deceiving because the AD user may in fact have the necessary permissions to access the file in question. The actual problem is that you are using a PowerShell prompt to launch the collector and that PowerShell prompt is running under a non-AD account. Non-AD accounts cannot query the AD, so the permissions check altogether fails and you get this message.
At this point in time you have the following two options:
- Add the AD user account used by the application pool to the machine’s local admin group, log in with that user and then run the collector. Some people don’t like this option because it means that, even temporarily, the application pool user is a local admin on the machine.
- Alternatively, you can add a different Active Directory user to the local admin group on the machine and run the PowerShell prompt as that user.
In the future we are considering making the permissions check optional. When the collector is unable to verify permissions of an Active Directory account, we will simply warn you about it and ask if you would like to continue anyway.
Is this important to you? Do you want us to work on something different instead? We are always looking for feedback and comments for our features. Please send us a tweet or visit the MSDN Diagnostics forums.
Light
Dark
0 comments