Discussion:
Duplicating One MSCRM DB to a New Installation
(too old to reply)
zinck74
2010-03-08 23:16:01 UTC
Permalink
Hi,
We have an MSCRM 4.0 instance running in our Live environment. We
want to be able to use that data/database for a new preproduction
environment. I have some concerns over the suggested guidelines we
were given to do this. At a high level:

Backup Live databases (Org and config)
Restore Live databases onto the new preproduction db server
Install MSCRM onto a new preproduction web server, connecting to an
existing instance (new preproduction db server)
Update ConnectionString and SQLServerName in Config database

Note that the Live environment will be up the whole time, we are
duplicating the live environment data to put into our preproduction
environment, not just moving the database for the live environment.

Any obvious pitfalls with doing it this way? Frankly it sounds a
little sketchy to me. Would there be a more sound way of doing this,
like by using actual MSCRM tools? My one concern that I don't see
addressed here are the OUs and security groups therein. It seems this
new instance will essentially be using the existing OUs and security
group and not a new OU and security group. I'd prefer to have these
things segregated.

Thoughts?

TIA,
Bill
Dave Ireland
2010-03-09 13:53:58 UTC
Permalink
Hi zinck74,

NO - don't do this!

What you want to do is install CRM 4 fresh on your new pre-prod hardware.
During installation, when you are asked for the Organization Name, type
in "deletemelater" or something, because you will end up deleting this org.
Also during isntallation, choose a different AD OU to house your CRM AD
objects for pre-prod. This is just a housekeeping suggestion, so that you
can keep them separate.
Once CRM is installed and patched to the same level as PROD, you can then
restore ONLY your Org_MSCRM database to the new database server.
Then run the Deployment Manager's Import Organization wizard, and point it
to your restored database. If you're using CRM Professional, you will be
warned that importing a new org will delete the existing org - which is fine.
If you're using Enterprise, it will create a second Org, and you can delete
the "deletemelater" org afterwards.

The problem with your original approach is that both CRMs would have been
using the same AD security groups and that your restored 'mscrm_config' database
would have connection strings that pointed to your PROD Org_mscrm database.

Hope this helps.

Dave
Post by zinck74
Hi,
We have an MSCRM 4.0 instance running in our Live environment. We
want to be able to use that data/database for a new preproduction
environment. I have some concerns over the suggested guidelines we
Backup Live databases (Org and config)
Restore Live databases onto the new preproduction db server
Install MSCRM onto a new preproduction web server, connecting to an
existing instance (new preproduction db server)
Update ConnectionString and SQLServerName in Config database
Note that the Live environment will be up the whole time, we are
duplicating the live environment data to put into our preproduction
environment, not just moving the database for the live environment.
Any obvious pitfalls with doing it this way? Frankly it sounds a
little sketchy to me. Would there be a more sound way of doing this,
like by using actual MSCRM tools? My one concern that I don't see
addressed here are the OUs and security groups therein. It seems this
new instance will essentially be using the existing OUs and security
group and not a new OU and security group. I'd prefer to have these
things segregated.
Thoughts?
TIA,
Bil
zinck74
2010-03-09 19:11:56 UTC
Permalink
Thanks Dave. I had suspected there would be some other more supported
option. I also saw this on the CRM Team's blog on MSDN. So I'll have
to straighten out some people on this. :)

Thanks,
Bill
Post by Dave Ireland
Hi zinck74,
NO - don't do this!  
What you want to do is install CRM 4 fresh on your new pre-prod hardware.
 During installation, when you are asked for the Organization Name, type
in "deletemelater" or something, because you will end up deleting this org.
 Also during isntallation, choose a different AD OU to house your CRM AD
objects for pre-prod.  This is just a housekeeping suggestion, so that you
can keep them separate.
Once CRM is installed and patched to the same level as PROD, you can then
restore ONLY your Org_MSCRM database to the new database server.
Then run the Deployment Manager's Import Organization wizard, and point it
to your restored database.  If you're using CRM Professional, you will be
warned that importing a new org will delete the existing org - which is fine.
 If you're using Enterprise, it will create a second Org, and you can delete
the "deletemelater" org afterwards.
The problem with your original approach is that both CRMs would have been
using the same AD security groups and that your restored 'mscrm_config' database
would have connection strings that pointed to your PROD Org_mscrm database.
Hope this helps.
Dave
Hi,
We have an MSCRM 4.0 instance running in our Live environment.  We
want to be able to use that data/database for a new preproduction
environment.  I have some concerns over the suggested guidelines we
Backup Live databases (Org and config)
Restore Live databases onto the new preproduction db server
Install MSCRM onto a new preproduction web server, connecting to an
existing instance (new preproduction db server)
Update ConnectionString and SQLServerName in Config database
Note that the Live environment will be up the whole time, we are
duplicating the live environment data to put into our preproduction
environment, not just moving the database for the live environment.
Any obvious pitfalls with doing it this way?  Frankly it sounds a
little sketchy to me.  Would there be a more sound way of doing this,
like by using actual MSCRM tools?  My one concern that I don't see
addressed here are the OUs and security groups therein.  It seems this
new instance will essentially be using the existing OUs and security
group and not a new OU and security group.  I'd prefer to have these
things segregated.
Thoughts?
TIA,
Bill
Loading...