Work out what the heck the Timer service is doing…

Ahh the SharePoint timer service. Where would we be without it? It’s been there since the beginning, making sure things just tick along in the background. But what happens when it goes rogue? How do you look at the actual tasks that the timer service is performing or the messages it is sending via HTTPS?

As part of troubleshooting a problem with the SMS Alerting service we could see that the service was sending a set of web service messages to the service provider, then bombing out with a 500 error. We could see the exception being thrown in the ULS (SharePoint) logs but we could not determine what message / parameters were being sent because the comms were over HTTPS and the tools that you normally use to decrypt the messages (Fiddler) will only hook into the iexplore.exe threads.

The way to get the raw unencrypted data spat out is to enable logging on the timer service and then restart it. To do so:

• Find the file owstimer.exe.config in the “%CommonProgramFiles%\Microsoft Shared\web server extensions\14\BIN” folder (If it does not exist, you may need to create it).
• Add lines 5 to 41 inclusive of the following text into the config file…

   1:  <?xml version="1.0" encoding="utf-8" ?>

   2:  <configuration>

   3:    <runtime>

   4:    </runtime>

   5:    <system.diagnostics>

   6:      <trace autoflush="true" />

   7:      <sources>

   8:        <source name="System.Net">

   9:          <listeners>

  10:            <add name="System.Net"/>

  11:          </listeners>

  12:        </source>

  13:        <source name="System.Net.HttpListener"> 

  14:          <listeners>

  15:            <add name="System.Net"/>

  16:          </listeners>

  17:        </source>

  18:        <source name="System.Net.Sockets">

  19:          <listeners>

  20:            <add name="System.Net"/>

  21:          </listeners>

  22:        </source>

  23:        <source name="System.Net.Cache">

  24:          <listeners>

  25:            <add name="System.Net"/>

  26:          </listeners>

  27:        </source>

  28:      </sources> 

  29:    <sharedListeners>

  30:      <add

  31:      name="System.Net"

  32:      type="System.Diagnostics.TextWriterTraceListener"

  33:      initializeData="C:\\Tracing\\OWSTimer_SNtrace.log" traceOutputOptions = "DateTime" />

  34:    </sharedListeners>

  35:    <switches>

  36:      <add name="System.Net" value="Verbose" />

  37:      <add name="System.Net.Sockets" value="Verbose" />

  38:      <add name="System.Net.Cache" value="Verbose" />

  39:      <add name="System.Net.HttpListener" value="Verbose" />

  40:    </switches>

  41:    </system.diagnostics>

  42:  </configuration>

 

• Save and restart the timer service



• A file will be created in the following location - C:\Tracing\OWSTimer_SNtrace.log (if not, try adding in the folder).



• Execute the bug you want to look at and roll back the owstimer.exe.config changes so the logging stops.



• Open the relevant log file and look at the contents – you can see the hex representation of the Web Service calls, as well as the english translation

Now you can compare the web service comms or operations the timer service is undertaking and work out where it is not set up correctly. In our case, there was a value we were expecting back from the service provider which SharePoint was not receiving and as such, the call was failing. Once the service was fixed, it worked.

Cheers!

Brad