30 day trial
Ayaz Ahmad is a CRM MVP, developer, and blogger. We welcome him to the growing ranks of MVPs who have shared their insights on the CRM Team blog.
After the collapse of my test (QA) server, I have been searching for various developments environment options for Microsoft Dynamics CRM 3.0 projects. From discussions with some peer developers, I have found that most of them are using Virtual PC images for their development tasks. This is also recommended by Microsoft and a download at Microsoft web site regarding VPC image is also available. This will benefit us in various ways:
If you have any issues regarding VPC please do comment. Thanks!
I've been using Virtual PC's for development on Dynamics CRM. And yes it works. But some things aren't very nice.
We can export customizations
We can export workflow
We can xcopy dll's and config for workflow and callouts
We can't export settings like: roles, your product catalog, topic tree etc...
We also use VPC's for developing with CRM implementations. This seems to be working fine for the last 2 years now. But mainly when it is a single project implementation.
How would you (or Microsoft) approach a multiple project scenario. What I mean with this is the following.
For one of our customers we have 5 different projects running simultainiously on the same CRM installation. Each of the projects addresses a different process in their organisation. However al ot of entities are used in all of the projects and all have their own customizations.
When this happens the VPC scenario will not be sufficient. Because if I roll out one of the projects to production I will need to roll out all of them. At least that's our experience until now. In a cusom development prject we would be using Team Systems Foundation and all of the source control that is available in there.
Is there a way to customize the projects seperately on different VPC's and then merge the XML files into the one that needs to be rolled out to production? Like it is done with custom development projects.
This is something we are struggling with for a long time now. And so far we could only get this to work by rebuilding a lot of the functionality in the production envrionment. Which of course should be a no go.
I would love to hear from anybody how this can be addressed.
I use the following setup for dev:
Use a development domain with its own domain controller, exchange server and users. This seems to run ok as a VM.
Use a dedicated SQL Server\Reporting Server which is not virtualized and is a member of the dev domain.
Create a VM and install Win2K3, .Net patches etc and then do a basic sysprep on it.
Now you are ready to quickly roll out a VPC image - copy the sysprep'd VPC to your VM server or desktop virtualpc, start it up and run through setup joining it to the dev domain etc.
For a test VPC just go ahead and install CRM from scratch creating databases on the dev sql server and using the reporting services on the dev sql server. Its best to create your own Org Unit in AD for each install.
For a client CRM VPC first grab copies of their CRM databases and restore them to the SQL Server. Create one or two users that match their prod environment inside a Org Unit called CompanyName in the AD. Install the redeployment tool to the VPC and run it selecting the restored customer databases then map the users. Install the CRM Server and point it to the existing databases. Install any patches etc.
The inability to export roles, subject tree is actually a current Microsoft CRM product limitation and is not caused by the use of virtual servers.
Microsoft CRM MVP
I need to setup a CRM project with a team of 3 CRM developers and I thought this blog would help me in using best practices for the team development environment. From reading this blog, this is how I understand it:
- Each developer maintains a VPC with CRM and Exchange on it.
- There is a common SQL Server (each developer maintains his own DB in the server for his CRM VPC)
- There is one AD tree for all developers
- There is one Exchange server for all developers
- Each customization requires an XML file which is maintained in source control.
The questions I have are:
1 - I don't understand how each developer would have his own Exchange instance if all developers are sharing the single AD tree. But how else could I ensure they don't step on each other's toes?
2 - If I am developing a software product based on c#, then I have an IDE which uses source code files maintained in source control which makes team development much easier. However, CRM does not give me this, it allows a developer to make customizations and then publish them into the system without using a 'source file'. The only way I can think of to manage this is to make a policy to always export customizations to an XML file and maintain that file in source control. Is this how you would approach team development in CRM?
Thank you for your insights
There is a tool you can download from CodeProject about Importing and Exporting CRM Roles
Well the new VPC image released recently for CRM 4.0 requires a PartnerSource login, and I was using the previous VPC image for development, both during my tenure at a Dynamics Partner and now here at a global investment firm. The previous VPC was freely available.
I don't understand this change - it's senseless.
It's disappointing that as an MSDN subscriber, I'm now forced to build a development environment from scratch.
Quite annoying - please make it publicly available, as not all CRM Developers have a partner source login!