Sunday, 23 February 2014

Enterprise Development Part 2 - ALM Framework for Dynamics CRM

The ALM Framework for Dynamics CRM is a C# console application designed to support an automated scheduled build. It's primary purpose is to enable the following process to be executed from a command line or windows schedule:

1. Get the latest version of the visual studio web resources project (VSProj1) from Team Foundation Server (TFS).
2. Deploy the web resources to the "master" CRM Server and publish all.
3. Increment the version of the target CRM solution on the master server.
4. Export the target CRM solution as a zip file to a temporary location on disk.
5. Check out the workspace folder containing the unpacked/extracted CRM solution files in the local workspace (VSProj2).
6. Unpack the CRM solution exported from the master server to disk - overwriting the existing files in VSProj2.
7. Modify the Visual Studio project that contains the unpacked solution files (VSProj2) - new files are added to the .csproj and deleted files are removed.
8. Check in the TFS workspace. 

Pre-Reqs and Assumptions

1. You are using Team Foundation Server for Source Control.
2. You are using an existing CRM Developer SDK Visual Studio project to source control and develop your web resources (VSProj1).
3. You have an existing Visual Studio project to store the unpacked CRM solution for source control purposes. (VSProj2)

Under the Hood

The Build Automation tool is simply a mechanism for automating calls to a number of other tools that actually do the work. They are as follows:


This is a commandline tool for interacting with and automating Team Foundation Server operations. Build Automation calls TF.exe to "Get Latest", "Checkout", "Checkin", "Delete" and "Label" the CRM Solution files.

Solution Packager

This is a command line tool included in the CRM SDK. It is used for unpacking CRM solutions to disk as individual files so that they can then be source controlled. It is also used for packaging the individual files back into a zip file CRM solution that can be imported into a target CRM server.

Solution Manager 

A command line tool to provide xRM solution management. This tools is used to export, import and version CRM solutions. In the process above it exports the CRM solution file that is then unpacked by the Solution Packager.

Build Automation for Dynamics CRM provides the glue that binds these three components together to support the process outlined for source controlling a CRM solution. 

Wednesday, 29 January 2014

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:

Sunday, 5 January 2014

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:

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.

Friday, 3 January 2014

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.

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>;
sp_addserver <new_name>, local;
b. Restart SQL Server Services.
c. Run SELECT @@SERVERNAME to confirm the rename has succeeded.
See 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 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:

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.