amcgovern on Mon, 05 Nov 2012 11:39:35
I've been tasked with creating a CRM test Environment and im fairly new to the wonderful world of CRM. Ive been asked to make sure that this test Environment is an indentical copy of our current production Environment in CRM. We are currently running CRM4, Update Release 21 on a physical server as our production system. However im not sure what the best method would be to create a test CRM system.
My thinking is to create a new isolated test system away from production on a hyper-v virtual Environment. To do this i was thinking of creating a fresh blank copy of CRM on a virtual server and then exporting the .dlls and customizations from our production Environment to the new test one. Then taking a copy of the SQL databases and setting up a new Virtual SQL test server and importing the copied databases into the test system.... in essence this should mirror our production Environment. Id need to take a copy of our AD Environment also and setup a test DC too but thats not an issue.
Id like to know is the method i suggested above a viable method to make an exact copy of our production Environment. Or is there a better, easier and fast way of copying our production Environment into test?
I'd be most grateful for any assistance you can provide.
Neil McD on Mon, 05 Nov 2012 12:44:44
I normally take a copy of a live database and move it to a test server. It's quite straightforward and there is a support article here which explains how to move a deployment.
- Install new instance of CRM and SQL
- Patch up to the same level as your live server
- Backup your live Org_MSCRM database
- Restore it to the dev SQL server
- Run deployment manager on the dev CRM server and import the database
If you're using a different domain, there is a step to map the CRM user accounts to AD Accounts in the new domain.
As long as your customizations etc are stored in the DB, they will already be imported. If you have created customizations outside of the database e.g. ISV config and plugins stored on the server rather than DB, they will need to be copied over manually.
You may also want to 'anonymize' the data in the test environment.
Hope this helps!
amcgovern on Mon, 05 Nov 2012 14:00:05
Excellant thats great news thank you Neil. I kind of thought that would be the case. As far as i know all the customizations are stored externally from SQL so i'll need to copy over those I know Microsoft has a few articles on that i can look through.
Im unfamiliar with 'anonymize' the data in the test environment Sorry for my ignorance would you mind clarifying this?
Neil McD on Mon, 05 Nov 2012 14:08:14
You're welcome. By 'anonymize', I just mean changing email addresses, telephone numbers etc of any contacts/accounts/leads in the test system. I do it so that I don't accidentally email contacts when working in the test system.
I usually run the below SQL on the test database to change the email addresses to email@example.com
update ContactBase set EMailAddress1 = convert(nvarchar(36),contactid) + '@dev.test' where EMailAddress1 is not NULL update ContactBase set EMailAddress2 = convert(nvarchar(36),contactid) + '@dev.test' where EMailAddress2 is not NULL
amcgovern on Tue, 06 Nov 2012 09:10:42
Perfect thanks, I wouldnt have actually thought of that, I'll do that once i have my test system up and running, again thank you very much for all you help.
Rakeshshanmughan on Tue, 14 Mar 2017 18:10:04
I am also looking to anonymize the data. Thank you explaining Neil.
But my case is slightly different. We are moving from a 'notoriously' customised 2011 On prem to 2016 on prem. We are trying to stick to OOB as much as possible so we wont be having many custom entities from 2011. Therefore we can't restore the live database to dev. We will need to copy the records (say, Accounts and contacts) from live to dev and then anonymize a few fields (say, first name, lastname, phone numbers etc). Any suggestion on how to do this?