Tip #228: He knows when you are sleeping

All sort of interesting things happen when we are asleep: Santa Clause, tooth fairies, and, lately, CRM errors. If you are running production on premises system, enabling blanket tracing needs to be done with a great care as server disks will overflow very fast. It’s OK during the day to enable trace, reproduce the error and disable trace, but if your errors happen in the middle of the night, who’s there to flip the lights on and off?

Immense power of Windows scheduling to the rescue – schedule your traces to sleep well at night.

Couple points from Tipp Jarr:

  • Multiple servers in deployment are like a box of chocolate, so if you have more than one of those, run the job on each one of them.
  • Enabling script in the article misses TraceRefresh flag. Without it, your script will work only once.
  • KB writers seems to have a dislike for carriage returns. Here is the content lined up and ready to be pasted
    To enable:

    Windows Registry Editor Version 5.00 
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM] 
    "TraceEnabled"=dword:00000001 
    "TraceRefresh"=dword:00000002
    

    To disable:

    Windows Registry Editor Version 5.00 
    
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM] 
    "TraceEnabled"=dword:00000000 
    "TraceRefresh"=dword:00000003
    
  • When scheduling the job, make sure it runs under account with sufficient privileges. Muggles do not have permissions to modify HKLM keys.
Tweet about this on TwitterShare on Facebook0Share on Google+0

One thought on “Tip #228: He knows when you are sleeping

  1. Henrik says:

    Might I suggest an alternative to changing the registry? Use the PowerShell commands for enabling tracing and schedule that instead, see link 1. The changes made through PowerShell do not update the registry, but instead updates the DeploymentProperties and ServerSettingsProperties tables in the MSCRM_CONFIG database (meaning across your app servers). I realize your method is the suggested MS way in link 2 below, but it only affects a single app server, and depending on your need you could select the best way forward. At least the PS way offers an alternative approach that DevOps guys are happy and comfortable to work with.

    1. http://support.microsoft.com/kb/907490/en-us
    2. http://support.microsoft.com/kb/2862025/en-us

Leave a Reply

Your email address will not be published. Required fields are marked *