Microsoft Dynamics CRM 2013 Development Environments

What options do we have?

 

There are a number of options that we have, we can simply add a CRM Application Server to our main network, connect up to a SQL Server and Active Directory, and then use our laptop which is also connected up to the same domain to develop on. With this approach a number of developers can use the same instance of the CRM Application and we get a pseudo continuous integration going on means each developer is working on an up to date copy of the system. The problem here is that if we want to debug a Plugin the process it’s hosted in will halt on any breakpoints.

So in my opinion the only other option we have is to develop locally using Hyper-V or VirtualBox.

 

So what’s the simplest Virtual setup?

 

Well that would be a single VM with Active Directory along with SQL Server 2012, CRM 2013, and Visual Studio 2013. The great thing about this set up is that it’s a single virtual machine, you can snapshot the image meaning you can do some work on it e.g. upgrade it to the latest rollup, and roll back to your clean state easily for the whole environment. A developer can work in a self-contained sandbox without affecting other developers work, and use TFS to check in his changes.

 

Note: With Visual Studio 2013 your settings are stored in the cloud, so that means that you can customise your set up to how you like it, and get that same setup on each virtual or physical machine you work on.

 

The problem here is that it doesn’t represent a real world environment… This is always important when developing on because developing on a single virtual machine will mask any connectivity and firewall issues that you might encounter, with say an external application connecting up to CRM.

So to overcome (and using Hyper-V on Windows 8/8.1 makes this easy) we can set up a complete virtual network. We create a core Active Directory Server, and add in Routing and Remote Access as one of the features to install, create a SQL Server 2012 virtual machine, a CRM 2013 virtual machine with Visual Studio Remote Debugging on it, and a workstation virtual machine which has Visual Studio on it plus any other tools we might need.

 

The reason we would put routing and remote access on to the core AD server, is that we can set up all of the images to use an internal Hyper-V virtual switch and assign each of them static IP addresses. Because we use an internal network, it means that multiple people can have the same set of virtual machines and the IP addresses won’t clash. With routing and remote access and an additional external virtual switch we can set up NAT (Network Address Translation) and assign the default gateway of all of the internal virtual machines to the core server. The Core AD Server would have its external interface as DHCP, so it would an IP address on our normal network, be able to access the internet and route any traffic from say the workstation virtual machine out on to the internet as well.

We can also set up any VPN connections that we may need on to the core AD server and again everything would get routed out correctly.

 

So how do we set this up?

 

Well first we need to create two Virtual Switches by going to Hyper-V manager, and going to the Virtual Switch Manager.

We create one connected to the external network interface on the host machine, and create one which is an internal network.

Next we create four virtual machines.

 

The exact hardware settings and location etc. will depend on your Hyper-V host, but generally I find the following a good set up for each server role:

 

 

Of course you do need a virtual host that can handle this, but a decent laptop with 32Gb RAM isn’t that expensive now.

On to each of the server roles you would install Windows Server 2012 R2 and Windows Server 2012 R2 or Windows 8.1 on the workstation, give each virtual machine an appropriate computer name and an IP address, say as follows, on their internal network interface:

 

 

The reason we don’t provide a default gateway on the Core AD Server, is that it has an external network interface which we will route out of. The external network interface should be set to DHCP.

 

Next we promote the Core AD Server to be a domain controller, by adding the Active Directory Domain Service feature through Server Manager, and using the promote server wizard after the installation has complete.

 

We then add the Routing and Remote Access service, through Server Manager, installing the service as NAT and selecting our external network interface as the external interface in the wizard. Once this is installed we can then go into Routing and Remote Access, and ensure we have Enable IPv4 Forwarding ticked in the local server properties. Then we must also make sure that a NAT interface has been created with Public Interface selected and enable NAT on this Interface ticked.

 

We can also allow services and ports to be allowed through from the Core AD Servers external DHCP IP address, so say e.g. we want to access CRM from our local virtual host, we just add a new port redirection in to forward any 5555 traffic to the CRM Application server on e.g. 172.16.0.3.

 

Now we should be able to ping public IP addresses from each of the internal servers and workstation.

 

Next we can install SQL Server on the SQL Server virtual machine. It is Microsoft’s best practice to have separate Data and Log file disk drives, so we would use the 146Gb VHDX drive we created for the SQL Data and the 72Gb VHDX drive for SQL Logs. The reason I chose these sizes was purely that that used to be the typical size of a HP Server Disks, and the ratio is about what you would want.

It’s always good practice to have the servers using the Windows firewall, as it means you pick up any ports that you need to open as part of the development process, and document this as you go. So you would need to create the following firewall rules:

 

 

We can install Microsoft Dynamics CRM 2013 on the CRM Application Server as would do normally, and can also install the Visual Studio 2013 Remote Debugger. We also need to install the CRM 2013 SSRS Connector on to the SQL Server virtual machine so that the reports run correctly.

In my experience it is better to put SSRS on a separate server or on the CRM Applications Server in a production environment, as when we come around to upgrading Microsoft Dynamics to a new version of CRM, we can use the same SQL Server with a different SQL instance, and of course we can only have one SSRS instance installed on a SQL Server. That said, having SSRS on the same server as SQL Server makes it easier to install for development use.

As with the SQL Server virtual machine, the key thing to note is that we also need to create some inbound firewall rules to allow everything to communicate correctly.

 

 

Note: Port 808 is needed for SSRS to communicate to the CRM Server Asynchronous and Sandbox Services, for some reporting scenarios.

 

The final thing to do, is to install Visual Studio 2013 on the Workstation virtual machine. We just install this as we would do normally.

 

So how do we debug?

 

Well in a self-contained development environment we can simply click debug, then attach to one of following processes

 

CrmAsyncService.exe
Microsoft.CRM.Sandbox.HostService.exe
w3wp.exe

  

With Remote debugging enabled on the CRM Applications virtual machine, we can do the same thing, but rather than connecting to the local computer, we click on Find in the Attach to Process window, then we should see our CRM Application Server listed and click select.

 

One of the advantages of having separate server roles is of course that we can quite easily add on a SharePoint 2013 or Dynamics NAV 2013 R2 server to the development environment.

 

Obviously this isn’t a definitive step-by-step instructional guide on how to set up a development environment, but should give you a good understanding of the key elements and best practices.

 

Until next time…

 

@simonjen1