I have been developing for SharePoint lately, working on timer jobs. This resulted in tons of deployments and job runs, and before I knew it my SharePoint_Config database was huge! I was working in a virtual machine with disk partitions, and my data disk ran out of space. At least it was on a partition and I didn’t hose my OS….
So it seems to be a simple problem to solve. Backup the database, shrink the log file. Not so fast partner, this is SharePoint. The database is not in Simple recovery mode, it’s in Full recovery mode (for a reason I am sure, I just don’t know what it is). You can truncate the log file and remove the data, but the physical file won’t shrink. My colleague J Wolfgang Goerlich pointed out one of his old blog posts that was just the ticket. Essentially you are changing the mode, shrinking the file and changing the mode back all in one operation, which won’t upset SharePoint. The log file went from about 9 gigs to 600k. Nice.
As noted in the blog post, this is not a good thing to do to a production system, there are consequences. But for a dev system I wouldn’t worry about it.
I’m sure the first question someone would ask me is why do this, if installing the SRS Connector does the job just fine? And I would answer that it does work, and that’s what we did. For the first install. We were creating two instances of CRM, one for a production environment, and one for a test environment. Each instance of the CRM application was on its own virtual web server, and the databases were to be housed in a single physical SQL Server. In this situation, we wanted both the sets of the CRM databases on the same database server. CRM always names the config database MSCRM_Config, so you can’t install a second instance in the same database server because unlike SharePoint, the configuration database name is always the same, and the second install just simply fails. So the initial solution to the problem was to use a second instance of SQL Server on the same physical server. This worked great, until we had to install the SRS Connector on the SQL Server. During the install of the SRS Connector you configure the URL to Reporting Services. The connector only works for one instance of SSRS on the physical box where it is installed. This left us out in the cold for the other instance in terms of the SRS Connector. Since CRM 3.0 didn’t have the SRS Connector, it’s pretty well-known how to configure Kerberos trusts so that SSRS can work from inside CRM without the SRS Connector, so that’s what we needed to do.
There are two ways to accomplish this:
Run the CRM site IIS application pool under a domain account
Set the SPN for that account
Set up trust for delegation to that account
Run the CRM site IIS application pool under a local account
Set a trust for the machine hosting CRM
Since it seemed to be fewer steps and less to maintain, we went with the second option, setting up an Active Directory trust for the web server hosting CRM.
It was not difficult to set the trust:
On your domain controller (Server 2008 for me), open Active Directory Users and Computers.
Navigate to (or find) the computer hosting CRM
Open the properties of the computer
Choose the Delegation tab
Select Trust this computer for delegation to specified services only
Select Kerberos only
Click the Add button
Click the Users or Computers button
Enter the name of the CRM web server
In the resulting list, choose http in the Service Type Column.
Click a couple of OK buttons
Reset IIS on the CRM server
It should look something like this when you are done:
Any other DC’s may have to sync, but at this point you should be all set.
Sometimes when copying databases, for instance from production down to development, the user accounts become dysfunctional. The database login no longer matches the overall server login. To re-synchronize them use: