Enterprise Development Part 1 - Source Controlling CRM Solutions in the Real World

So here is the first in a series of posts regarding Enterprise Development and Dynamics CRM. Our first requirement was to automate the source controlling of our CRM customisations. However, before I get stuck into the detail, a bit of context:

1. Our development is based on the following:

• Dynamics CRM 2011
• Visual Studio 2010
• Team Foundation Server 2012

2. Our development environment is split between a data centre and office network. Although there is a VPN connecting them there is no routing from the data centre network to the office network. This will become a critical factor when determining our approach.

3. We have a single instance of Dynamics CRM that we treat as our Master for CRM customisations and this server is hosted on the office network. The TFS server is hosted on the data centre network.

4. Developers work on standalone instances of CRM and can work on all aspects of CRM including customisations. However, as there is a single server acting as the master for customisations any changes to anything but web resources must be made either directly on this server or exported as unmanaged customisations and imported into this server.
NB. We generally make these changes directly on the server as exporting and importing can prove problematic when multiple developers make changes to the same entity.

ALM Frameworks for Dynamics CRM

Considering Dynamics CRM is itching to increase it's footprint in the Enterprise sector the support for Enterprise Level development within the product is a bit limited. However, there are a some existing frameworks and some open source tools that step into the breach:

Visual Studio xRM CI Framework

A great suite of components including a custom TFS Build template definition that supports exporting and source controlling your customisations. In almost every scenario this would be answer.... 
However, in our case this was not suitable as the TFS Build Agent requires a network port accepting inbound connections (by default this is 9191) from the build server and the network restrictions meant our TFS server could not communicate with our build agent. Furthermore if your build agent is on a different domain this can also cause complications but there is at least a workaround for this issue here.
For those development environments that aren't constrained by the network restrictions we encountered though this would be the recommended approach and you can find it here.

Adx Studio ALM for Dynamics CRM

A collection of powershell cmdlets for supporting Continuous Integration and automated deployments. Powerful but there's a licensing cost and you'll need a reasonable understanding of powershell. There's a bit of a learning curve in getting your head round the framework as well. Unfortunately in our case the cost proved prohibitive and so we went with a different approach....

ALM Framework for Dynamics CRM

A console application for automating the extraction, source control, packaging and deployment of Dynamics CRM solutions. It's a lightweight and open source approach to build automation.  You can find it here: http://crmbuildautomation.codeplex.com.

Enterprise Development Best Practice for Dynamics CRM

As part of our quality assurance review process we're currently in the process of aligning our CRM development practices with the guidance published by Microsoft - you can find the white paper here: http://www.microsoft.com/en-us/download/confirmation.aspx?id=39044

As part of that process we identified some areas around source control and Continuous Integration we needed to improve on:

1. Source Code Integration

Enable an automated extract of an unmanged solution from a local dev CRM server to disk for check-in to TFS.

2. Daily Automated Builds

Create a CRM deployment package based on a daily schedule using the latest source code in TFS.

3. Automate Build CRM Solution Package and Deploy to Target Server 

Create an automated pack CRM Solution from TFS and import to target CRM.

4. Web Resource editing in Visual Studio

Enable a developer to work on a web resource in VS and have the resource publish to CRM from the IDE.

5. Source Control Plugin Registration Settings

Enable a developer to source control plugin registration settings.

6. Automated Import and Publishing

Update deployment process to automate import and publish process.

We're currently working through the resolution for each of these issues with a combination of the Solution Packager, the xRM Framework for Continuous Integration and custom code but I'll write a post on each as we resolve them.

Renaming a standalone instance of Dynamics CRM 2011

As part of our development environment setup we recently needed to rename a stand alone instance of a CRM server and wanted to avoid re-installing. It's not the kind of thing you do very often so I figured I'd document it here for future reference.

NB. My instance was hosted on SQL Server 2012 but the steps should be the same in earlier versions.

*** HEALTH WARNING ***
This is unsupported: do not attempt this in any environment you can not afford to trash.
*****************************************************************************

The steps are as follows:

1. Rename the server and Reboot

If you are cloning your server you will need to remove it from the domain and rename it whilst it has no network connection to the domain controller. This will ensure the original server you are cloning from remains attached to the domain and working. You will also need to allocate this server a new IP address if it currently has a static one. You can then add this new server back onto the domain.

2. Fix SQL Server and Restart Services

a. In SQL Server Management Studio run the following SQL:

sp_dropserver <old_name>;
GO
sp_addserver <new_name>, local;
GO

b. Restart SQL Server Services.
c. Run SELECT @@SERVERNAME to confirm the rename has succeeded.
See http://technet.microsoft.com/en-us/library/ms143799.aspx for further details on 
renaming instances of SQL Server.

3. Fix Reporting Services

a. Open up Reporting Services configuration Manager
b. Ensure the server name in the connection dialogue points to your new server name.
c. Ensure Web Service URL is correct (it should be but there's no harm checking).
d. Click Database > Change Database > Choose an existing report server...
e. Enter your new server name into the connection dialogue
f. Choose ReportServer database and complete wizard.

See http://techontip.wordpress.com/2010/01/05/rename-sql-server-2008-single-server-senario/#more-253 for further details.

4. Update MS CRM Registry Entries

a. Run Regedit (Start > Run > Regedit)
b. Navigate to the MSCRM registry hive (HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSCRM)
c. Update the configdb and ServerUrl settings with your new server name.

5. Update MS CRM Configuration Database Settings

Open up SQL Server management studio and run the following script:

USE [MSCRM_CONFIG]

GO

UPDATE [Server] 

SET [Name] = '<NewServerName>';

UPDATE ConfigSettings 

SET [HelpServerUrl] = REPLACE([HelpServerUrl], '<OldServerName>','<NewServerName>');

UPDATE Organization 

SET [ConnectionString] = REPLACE([ConnectionString],'<OldServerName>','<NewServerName>'),

[SqlServerName] = '<NewServerName>', 

[SrsUrl] = REPLACE([SrsUrl],'<OldServerName>', LOWER('<NewServerName>'));

6. Update CRM Security Group Membership in Active Directory 

If you renamed your server whilst it was connected to the Domain Controller this step is not necessary (you might want to check though just to be sure).
a. Log onto your Domain Controller as a Domain Admin
b. Open up Active Directory Users and Computers and navigate to the Security Groups created by the original CRM installation process for your server. Eg. PriveReportingGroup, PrivUserGroup, SQLAccessGroup.
c. Open each group and add your new server as a member to each.
NB. You will need to select "Computers" as an Object Type.

7. Update Deployment Manager Web Address Properties

Open up CRM Deployment manager on your CRM server. Right click the root node "Microsoft Dynamics CRM" and choose properties. Click the Web Address tab and update the urls with the new server name.

8. Reboot your CRM Server

Navigate to CRM in your browser to confirm it's up and running. Choose and run a report to confirm SSRS is working too.