Thursday, February 20, 2014

SQL Server Reporting Services Service Start Timeout

SSRS will often timeout when starting under Windows Server:
The error is:  Windows could not start the SQL Server Reporting Services (MSSQLSERVER) service on local computer.  Error 1053:  The service did not respond to the start or control request in a timely fashion.

This problem is detailed here: http://support.microsoft.com/kb/2745448, and it's a result of the SSRS service checking for certificate revocation lists (CRL).  If you're like most people, you've got a firewall blocking Internet access from your server, so each call for a CRL has to time out before SSRS will start.

The above KB article mentions a handful of ways of dealing with this problem; the most-frequently used method is to increase the service start timeout in the registry.  This works, but it requires a server reboot.  And it doesn't really get to the root of the problem, that SSRS is taking a long time to start.

Now, generally a CRL is a good thing, even if only in theory.  But if your server can't get to the Internet, anyway, there's precious little danger of it getting to a revoked certificate.  After all, you're not using the server to browse the web.  Right?

So:  disable CRL checking within SSRS.  This is done with the generatePublisherEvidence element in the ReportingServicesService.exe.config file.

By default, this file is in the <drive>:\Program Files\Microsoft SQL Server\MSRSxxx.MSSQLSERVER\Reporting Services\ReportServer\bin directory.

To disable CRL checking, add the following just before the </runtime> tag at the bottom of the ReportingServicesService.exe.config file:
<generatePublisherEvidence enabled="false"/>

If SSRS is slow to start as a result of CRL checking, this will dramatically speed the service startup.  One benefit to doing this, too, is that it doesn't require a server reboot or anything to take effect:  it'll work at the next SSRS start.

43 comments:

  1. Wow. This was exactly solved our SSRS production Issue. Fix was just Awesome.

    ReplyDelete
    Replies
    1. I'm really pleased it helped. It took us awhile to recognize the problem before we nailed it down, so I hope it'll short-circuit some troubleshooting for some.

      Delete
  2. Mucha gracias . Me ayudo en el problema

    ReplyDelete
  3. i've done what was explained here. no luck
    i really need this problem to be fixed. what else can i give you so you can help me out if you have time. dead line with the new report, and can't test what i've developed in the extensions because my local RS stopped working. what a bummer.

    thanks in advance

    ReplyDelete
  4. Hi, Buga, what kind of symptoms are you seeing? Is RS just not starting at all? If that's the case, it's certainly a different problem than described above. The Windows event log ought to have some hints as to what's up, if that's the case (check the application event log for errors).

    There's also the RS logs, which by default are at \Program Files\Microsoft SQL Server\MSRSxx.MSSQLSERVER\Reporting Services\LogFiles where the "xx" is a version of SQL (11 for SQL 2012, 12 for SQL 2014, etc.)

    If you haven't already worked out the problem, let us know, and maybe we can help.

    ReplyDelete
  5. Awesome Lane...It worked like charm. Thanks Buddy.

    ReplyDelete
  6. Thank you very much Lane..!!! it helps me A lot :)

    ReplyDelete
  7. Hi - I am having the same error (1053) after some Windows updates were applied over the weekend. I added the to the config file like indicated but still not working. I also set the ServicesPipeTimeout to 60000 and then to 120000 and nothing. Any ideas? Thank you!!

    ReplyDelete
    Replies
    1. Hi, Core,
      Is this a consistent problem, as in SSRS won't start manually, ever? Or is it something where SSRS won't start in a timely manner after a reboot? Are you seeing any errors or timeouts in the SSRS log files (\program files\microsoft sql server\MSRSxx.mssqlserver\reporting services\logfiles)?
      Those probably will help us figure out what's happening.

      Delete
  8. Thank you so much!!!!! Your solution nailed it!

    ReplyDelete
    Replies
    1. Nice. I'm pleased it worked; thanks for leaving a note!

      Delete
  9. super its worked for me too

    ReplyDelete
  10. It worked for me too!!!! Thank you :)

    ReplyDelete
  11. Thanx hey, it worked forme!

    ReplyDelete
  12. Thanks a lot, Lane! It worked for me too.

    ReplyDelete
  13. Thanks. That was driving me around the bend.

    ReplyDelete
  14. Worked like a charm!! thanks for sharing :)

    ReplyDelete
  15. Awesome! Thanks so much - Saved the day in production

    ReplyDelete
  16. Worked like a charm!!! Thanks Lane!!

    ReplyDelete
  17. Had the same problem and after trying your workaround, RS started successfully. The issue is now in accessing the report server using web URL (http://servername/Reports)...it comes back with the error "HTTP error 503 Services Unavailable"....any idea what might be causing this. FYI : I am running the browser as administrator.

    ReplyDelete
  18. Great! Worked like a charm. Thanks

    ReplyDelete
  19. Another person right here who was just blessed by this solution post.
    Thanks!!!

    ReplyDelete
  20. Tnx alot....it works as a charm

    ReplyDelete
  21. Thanks for this, saved me a production server reboot!

    ReplyDelete
  22. Lane,

    Thanks for explaining this. I've dealt with that issue many times in the past using the ServicesPipeTimeout workaround (https://support.microsoft.com/en-us/kb/922918, or Method 4 in https://support.microsoft.com/en-us/kb/2745448), but never knew why it had to be done.

    It is still a mystery why all of the sudden SSRS would timeout to start. Recently we had this issue after a Windows Update to SQL Server 2008R2 (KB3020370) along with a security update (KB3045312). Perhaps one of them triggered it. Any insight?

    Thanks again,

    Aldo Gonzalez

    ReplyDelete
    Replies
    1. Hey, Aldo, I haven't seen anything about the latest round of patches to suggest they'd be affecting RS service startup times, or changing the way RS does its CRL check at startup.

      However, I *do* know there have been a variety of security recommendations lately (particularly from PCI) that have affected which web encryption technologies are considered secure and whatnot; this has led to some significant changes in the way vendors (and perhaps MS?) have started dealing with SSL certs and encryption protocols (SSLV3, TLS1.0, etc.). So: it's possible that something has changed in the way a particular cert is read or supported, and this, I suppose, could result in something similar.

      Does disabling CRL in RS clear up the error? That'd help narrow things down.

      Delete
  23. I've just hit this issue as well - will see if the updates you see are the same as what was just recently installed. thanks

    ReplyDelete
  24. I have checked the updates on my affected server and only only the first update you mention is installed. In my case it was installed in May so I can rule that one out. Perhaps some non SQL related update is affecting it?

    ReplyDelete
    Replies
    1. That's certainly possible: there have been a lot of updates (and SQL updates, specifically) from Microsoft recently. Another thing to check is firewall and networking changes in your environment: if something is affecting outbound internet access from your server, that'd cause this 100% of the time.

      Does disabling CRL checking make a difference?

      Delete
    2. disabling CRL just made the timeout error appear heaps faster as the OP mentioned. I have applied the pipes timeout reg key and just need a window to restart the server. Apparently there was an patch that killed SSRS KB2990214 - this was installed in April, but it is possible that one of the newer patches plus this one could have undone the fix.

      Delete
  25. Thanks for taking the time to share this. Most helpful.

    ReplyDelete
  26. This worked for me:
    http://blogs.msdn.com/b/mariae/archive/2012/11/12/reporting-services-service-doesn-t-start-after-the-installation-of-ms12-070-security-patch.aspx

    ReplyDelete
  27. Try these. Worked for me.
    http://sqldbworld.blogspot.com/2015/11/sql-server-reporting-services-fails-to.html

    ReplyDelete
  28. Your solution is the best! Thank you for sharing with public! You are great!

    ReplyDelete
  29. Thankls a lot. You saved my day !!!

    ReplyDelete
  30. Unlike so many published fixes, yours worked easily and simply. I had tried other published ideas and they failed. Yours worked. Thanks so much.

    ReplyDelete
  31. Vowww !!!
    That's superb. You saved my Sunday sir !!
    It worked like a charm for me.

    ReplyDelete
  32. Worked for me, thank you

    ReplyDelete
  33. Worked for us - thanks for the post

    ReplyDelete
  34. my oh my. What a great article and well explained. Helped to get the service backup. I still haven't figured the downside of disabling the CRL check :-) There is a drawback or not?

    Anyways, Appreciate the article

    ReplyDelete

Thanks for leaving a comment!