locked
CRM 2011 - Trace Settings using PowerShell RRS feed

  • Question

  • Hi All,

    I've been playing with Powershell to set the tracing levels on our CRM 2011 Rollup 4 server by following this Microsoft article:

    http://support.microsoft.com/kb/907490

    For some time I've had problems disabling tracing that has been enabled by PowerShell but this topic is being dealt with by another poster here:

    http://social.microsoft.com/Forums/en-US/crm/thread/0f44dddc-311a-4a35-bbdc-84a492976588

     I am finding issues with trying to set different logging levels on different categories.

    According to the support article this should be a valid category list:

    • Application:Warning;Application_Outlook:Warning;Exception:Warning;ObjectModel:Warning;Platform_Sql:Warning

    When I set this using:

    Add-PSSnapin Microsoft.Crm.Powershell
    $setting = Get-CRMSetting TraceSettings
    $setting.Categories = "Application:Warning;Application_Outlook:Warning;"
    Set-CRMSetting $setting

    I get lots of errors raised in the server's application logs similar to this:

    Log Name:      Application
    Source:        MSCRMTracing
    Date:          27/01/2012 13:34:16
    Event ID:      17153
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      *************
    Description:
    The following string is not a valid trace category pair: . (Reporting Process:Microsoft.Crm.Sandbox.HostService, AppDomain:C:\PROGRA~1\MICROS~3\Server\bin\)
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="MSCRMTracing" />
        <EventID Qualifiers="49152">17153</EventID>
        <Level>2</Level>
        <Task>0</Task>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2012-01-27T12:34:16.000000000Z" />
        <EventRecordID>74525</EventRecordID>
        <Channel>Application</Channel>
        <Computer>*************</Computer>
        <Security />
      </System>
      <EventData>
        <Data>
        </Data>
        <Data>Microsoft.Crm.Sandbox.HostService</Data>
        <Data>C:\PROGRA~1\MICROS~3\Server\bin\</Data>
      </EventData>
    </Event>

    Can anyone shed some light on how to use trace settings via PowerShell please? 

    Friday, January 27, 2012 1:45 PM

Answers

  • Mark,

    Please remove the ending ";" in your $setting.Categories string.  It should be "Application:Warning;Application_Outlook:Warning"
    not "Application:Warning;Application_Outlook:Warning;".

    Please also restart services and do an iisreset. You should no longer see “The following string is not a valid trace category pair: . “ in your application log, butyou may see something like “The category specified (Application_Outlook) does not exist.” error one time since some process doesn’t have that categories you specified. That should be fine.

    Thanks,

    Mike

    $setting = Get-CRMSetting TraceSettings
    $setting.Categories = "Application:Warning;Application_Outlook:Warning"
    Set-CRMSetting $setting


    Thursday, February 23, 2012 8:48 PM

All replies

  • Maybe i'm reading the documentation wrong but if I was going to do this I would use the following which is similar but slightly different than yours(notice the .*).

    Add-PSSnapin Microsoft.Crm.Powershell
    $setting = Get-CRMSetting TraceSettings
    $setting.Categories = "Application.*:Warning;Application_Outlook.*:Warning"
    Set-CRMSetting $setting


    Visit my Blog: http://matthewchurilla.blogspot.com/
    Friday, January 27, 2012 3:21 PM
  • Hi Matthew, thanks for the reply.

    Iwas going to reply with this

    "I must admit that I wasn't sure about that either. I read it that the Application. and Application.Outlook catergories were for CRM 4.0 only and that they had been replaced in CRM 2011 with Application and Application_Outlook respectively. This was the only way I could explain the different sections in the article."

    But after double checking your reply and the article it made me think that perhaps the examples were using CRM 4.0 categories but perhaps the .* is required in both 4.0 and 2011. Anyway to cut a long story short I tried:

    Application.*:Warning;Application_Outlook.*:Warning;Exception.*:Warning;ObjectModel.*:Warning;Platform_Sql.*:Warning

    And still got errors in the application log:

    Log Name:      Application
    Source:        MSCRMTracing
    Date:          1/27/2012 4:26:53 PM
    Event ID:      17155
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:      ***********
    Description:
    The category specified (Application_Outlook) does not exist. (Reporting Process:CrmAsyncService, AppDomain:C:\PROGRA~1\MICROS~3\Server\bin\)
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="MSCRMTracing" />
        <EventID Qualifiers="49152">17155</EventID>
        <Level>2</Level>
        <Task>0</Task>
        <Keywords>0x80000000000000</Keywords>
        <TimeCreated SystemTime="2012-01-27T16:26:53.000000000Z" />
        <EventRecordID>12467</EventRecordID>
        <Channel>Application</Channel>
        <Computer>**********</Computer>
        <Security />
      </System>
      <EventData>
        <Data>Application_Outlook</Data>
        <Data>CrmAsyncService</Data>
        <Data>C:\PROGRA~1\MICROS~3\Server\bin\</Data>
      </EventData>
    </Event>

    I dropped the Application_Outlook entry and the error moved to the Platform_Sql entry. I then used the CRM 4.0 entries (Application.Outlook.* and Platform.Sql.*) and got back to my orriginal error posted at the top of this thread.

    Friday, January 27, 2012 4:40 PM
  • Ok, I just read it again and it looks like the specs say that categories should be a string or multi-string. I am wondering if you should use a multi-string for setting categories instead of a ; seperated string. How about trying:


    $setting.Categories = "Application:Warning", "Application_Outlook:Warning", "Exception:Warning", "ObjectModel:Warning", "Platform_Sql:Warning"

     

    Also something weird I noticed is that I turned on tracing using the CRM Diagonstics Tool for CRM2011 and it still showed tracing as off in powershell. I'll mess with it a bit more right now but I wanted to have you try out this new item before I spend a lot of time messing with powershell in our environment.

     


    Visit my Blog: http://matthewchurilla.blogspot.com/
    Friday, January 27, 2012 5:11 PM
  • I tried the separate strings but still the same results.

    There appears to be two separate implementations of the tracing in CRM 2011. This was confirmed to me in this post:

    http://social.microsoft.com/Forums/en/crmdevelopment/thread/9b68a9ce-d356-4039-84d3-b4ae2199e652

    Does anybody know how the PowerShell tracing should be used?

    Friday, February 3, 2012 8:32 AM
  • Hi Mark,

    I feel your pain!

    I avoid using the PowerShell trace due to the problems you've outlined - I've always found that once it's been enabled, it's very difficult to disable it or change the settings.

    The Powershell command is a completely different trace listener to the Registry trace settings - but the registry one takes precedence on a per-server basis - and is the one used by Microsoft Support.

    On systems that it's been enabled already, I delete the powershell directory and then use the Registry tracing.  Incrementing the TraceRefresh flag in the registry always updates the settings without fail and I've never had any problems.

    It's a shame because a way of enabling tracing across all servers at once would be very useful.

    hth,

    Scott

     


    www.develop1.net
    If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"
    Friday, February 3, 2012 8:46 AM
    Answerer
  • Hi Scott,

    Thanks for the reply, the point about removing the PowerShell directory is interesting. If we ever manage to get the system stable enough to completly turn of tracing I will have to give that a try.

    I completly agree with you on the other points. The PowerShell tracing is so buggy that I will try to avoid using it on any new systems. I see that a new version of CRM is due out in Q2 2012, I wonder if they have fixed the issues in that version.

    Regards,

    Mark

    Tuesday, February 7, 2012 11:19 AM
  • Having looked at the CRM powershell stuff compared to the SharePoint powershell stuff it is night and day.  The CRM powershell commands/object structure seem a little wonky and aren't quite as optimized as the SP2010 commands/object structure. 

    If you find big problems (and it sounds like tracing is one of them) you should post a bug report on connect: http://connect.microsoft.com/dynamicssuggestions


    Visit my Blog: http://matthewchurilla.blogspot.com/

    Tuesday, February 7, 2012 1:55 PM
  • Hi Mark:
    Do you have any tracing registry keys(If yes, please delete all of them)? And can you tell me what are the values of TraceCategories if you have access to your config database?

    SELECT NVarCharColumn FROM [mscrm_config].[dbo].[ServerSettingsProperties] where ColumnName = 'TraceCategories'
    SELECT NVarCharColumn FROM [mscrm_config].[dbo].[DeploymentProperties] where ColumnName = 'TraceCategories'
    SELECT NVarCharColumn FROM [mscrm_config].[dbo].[OrganizationProperties] where ColumnName = 'TraceCategories'

    Thanks,
    Mike


    Thursday, February 9, 2012 11:59 PM
  • Hi Matt,

    Thanks for the link, I will raise a bug report if I exhaust all other options.

    Hi Mike,

    Thanks for the reply. We have just updated the CRM system to Rollup 6.

    Just for clarity I trust that this is the correct list format:

    • $setting.Categories = "Application:Warning;Application_Outlook:Warning;"

    The registry settings I had (but have now deleted) were:

    • "TraceEnabled"=dword:00000000
    • "TraceCallStack"=dword:00000000
    • "TraceRefresh"=dword:00000002

    After setting the categories the results of the SQL queries are:

    • ServerSettingsProperties: Application:Warning;Application_Outlook:Warning;
    • DeploymentProperties: Application:Warning;Application_Outlook:Warning;
    • OrganizationProperties: *:Error

    SQL query results from MSCRM_CONFIG table

    I still got errors in the application log when I changed the categories and after restarting the services. There isn't a lot of information in them and they are repeated several times. The descriptions are:

    • The following string is not a valid trace category pair: . (Reporting Process:w3wp, AppDomain:C:\Program Files\Microsoft Dynamics CRM\CRMWeb\)
    • The following string is not a valid trace category pair: . (Reporting Process:CrmAsyncService, AppDomain:C:\PROGRA~1\MICROS~3\Server\bin\)
    • The following string is not a valid trace category pair: . (Reporting Process:Microsoft.Crm.Sandbox.WorkerProcess, AppDomain:c:\program files\microsoft dynamics crm\Server\bin\)
    • The following string is not a valid trace category pair: . (Reporting Process:Microsoft.Crm.Sandbox.HostService, AppDomain:C:\PROGRA~1\MICROS~3\Server\bin\)

    The log files appear very empty at the moment. I will post back when they have had a chance to fill up a bit.

    Friday, February 10, 2012 10:00 AM
  • Mark,

    Please remove the ending ";" in your $setting.Categories string.  It should be "Application:Warning;Application_Outlook:Warning"
    not "Application:Warning;Application_Outlook:Warning;".

    Please also restart services and do an iisreset. You should no longer see “The following string is not a valid trace category pair: . “ in your application log, butyou may see something like “The category specified (Application_Outlook) does not exist.” error one time since some process doesn’t have that categories you specified. That should be fine.

    Thanks,

    Mike

    $setting = Get-CRMSetting TraceSettings
    $setting.Categories = "Application:Warning;Application_Outlook:Warning"
    Set-CRMSetting $setting


    Thursday, February 23, 2012 8:48 PM
  • Hi Mike,

    Sorry for the long delay in my reply. After reading your reply I tried to prove that this resolved the issues but I was bumped onto another project and couldn't get back to this until now.

    As I said, I tried to prove that your answer fixed the issues and indeed it did get rid of the “The following string is not a valid trace category pair: . “ errors so I'm going to accept this as an answer.

    However I still do not see any change in the information logged.
    To simplify the test I changed the categories to "Application:Info"
    I then restarted all the CRM services and did an iisreset.

    The result is that I am still seeing the following entries in the log and no additional entries.

    • Category: Platform Level:Error
    • Category: Platform.Async Level:Error
    • Category: Exception Level: Error

    I accept that there may not have been any information to log for Application:Info but why are the other entries still appearing?
    The logs do not have the annoying claims authentication token renewal information any more but I suspect that this is due to removing the registry trace settings rather than the changes to the PowerShell settings.

    Anyway, at the moment I can't spend any more time on this. I have raised a bug report for this.


    Friday, March 9, 2012 9:39 AM