CRM Reporting Extensions Installation Error - Microsoft.CRM.Setup.SRSdataconnector.restart Services action failed. Cannot start service report server on computer

While installing Microsoft Dynamics CRM 2011 Reporting Extensions to the SQL 2008 R2 server in my lab, I kept getting the following error snippet... "Microsoft.CRM.Setup.SRSdataconnector.restart Reporting Services action failed. Cannot start service report server on computer'".  During the installation of CRM reporting extensions, the SQL Server Reporting Services service stops, and on restart fails.  I tried this in service manager manually (start... same error), and even after rebooting the error was present when manually attempting to start the SQL Server Reporting service.  It appears that this occurs because the service manager doesn't wait around long enough for the service to start.  There are some good resources on how to do this already, including Microsoft KB article 2745448 (method 4)... but in short, use regedit and navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control, right-click Control and create a new DWORD named ServicesPipeTimeout, then modify it such that the decimal value is 60000 (1 minute wait).  Then restart the service.

Network Administration: SQL Server 2000 backups; Things to Consider

So you read my last post, and now you’re sitting there wondering… “What’s the backup strategy for our SQL servers?” Maybe you assumed that the DBA or a SQL developer was responsible for this. Or maybe, like me, you’re assessing a new customer’s infrastructure. Whatever the case might be, your next step is to determine how you want to approach the SQL database backups.

Important Factors to Consider:

1) How much data can I afford to loose, and how critical is the information in the database?
2) What is an acceptable time period to perform maintenance when a disaster happens?
3) How large is the database, and is this a 24x7 database?

If your answers look anything like “all of the data is business critical, we don’t have a maintenance window”. Then you might have a good argument for getting some training, or potentially bringing in a DBA. However, if you’re organization is like many small to mid-sized organizations, you’ll need to figure this out on your own.

Best Practices:

1) Perform regular restores of databases to verify restorability
2) Schedule time for a simulated disaster
3) Document the recovery procedures
4) Review event logs for potential hardware problems
5) Perform a complete database backup weekly or monthly
6) Perform a differential backup nightly
7) Perform transaction log backups every 30 minutes

In a follow-up post, I’ll add some technical details on the backup/restore model, including what options are available, as well as what I recommend.

Network Administration: You are backing up those SQL boxes, aren’t you?

I was doing an architecture assessment for a new customer, and noticed that their last netadmin/IT provider had neglected to run backups of their SQL server databases. Had in fact, never run any type of database backup.

Surprising, you might think? Amazed that they have never needed to restore anything? You’d think I would be… but no, not really. At this point, I’ve met with enough business owners and decision makers to realize that this type of thing is really par for the course among many small to mid-sized organizations.

Why this is, and what can be done about it, are topics for another day. But I just thought it might be worth mentioning here.

If this hits home for you, or if you don’t know if your IT group is doing backups of your SQL server databases, now might be a good time to bring it up. While you’re at it, find out what type of backups are being done, what the loss exposure is, if the restore procedure is documented, and determine if/when the last test recovery was performed.