Solved

Creating replica of production farm on a different domain

Posted on 2011-03-25
7
399 Views
Last Modified: 2012-05-11
We're trying to create a replica of our production 2007 farm in our Dev domain.  We did a P2V process where we virtualized the WFE servers, and then put those WFE VMs in the Dev Domain.

We ran new sid, joined them to the domain and what not and all was well to that point.

We also installed an SQL server from scratch in the Dev Domain, and copied over all of the databases (Content, Config, Admin, Search, etc).

THis is where we're on shaky ground....
Then we ran the config wizard to get the farm back up and running.  The wizard runs all the way to Step 8 of 9 and fails with the following error message:


"Failed to start service SPSearchServiceInstance on this server after completing upgrade.  Please start it manually."

Looking in the config wizard log file, it seems the config wizard having an issue with getting search to start up.  We've gone in an manually started the search before.  Since these are VMs we do have the luxury of wiping the WFE out and doing a point in time restore to start the process over again with a fresh snapshot.  However, we've tried this 6 times and get the same result everytime (ie. failing on starting search).

Any thoughts?


0
Comment
Question by:crmsharepoint
  • 4
  • 2
7 Comments
 
LVL 38

Expert Comment

by:Justin Smith
ID: 35214777
What you did is deffinately not the prescribed/recommended/supported way of doing it.  Which is why you have issues.

1. Did you install the EXACT same version of SharePoint (including patches) in the Dev farm?
2. You can't copy the config and admin databases to a different SQL box and just join the farm.
3.  You need to get SQL and SP up and running in Dev.  Run the config wizard to create a NEW farm.
4. I would then manually create your web applications to match production.  Create them with a dummy db name (because you will eventually delete this db).
5. At this point you can copy over your content db's from the Prod box to the Dev SQL box.  Transfer/modify SQL permissions on the db's.
6. Attach the restored db's to the Dev web applications in Central Admin.  Remove the dummy db's.
7. Then you have to worry about SSP and other services.  SSP can only be restored via Central Admin
0
 
LVL 1

Author Comment

by:crmsharepoint
ID: 35215075
So one important point is that we did a P2V (Physical to Virtual) of the web front ends to capture them as Virtual Machines.  So no we did not install SharePoint in Dev.  It's already installed on the Dev WFE, because the Dev WFE are Virtualized images of production.  We actually took the Production WFEs and "fork lifted" (if you will) them to the Development domain as Virtual Machines.
 
We want replicas of the production environment in development.  P2V is the best way to achieve that.  SharePoint has too many surprises as it is, and the thinking was that if we could P2V the production WFE into Development that we would have the closest possible replica.

At the beginning of the effort we acknowledge that this would be the tricky part of this project (making the connection to the DB to get the farm up and running), but we figured we'd give it a try as our Plan A anyhow.  Plan B is to do what you laid out, and forget about doing a P2V.  

The problem with Plan B, ***HOWEVER****, and the reason why it is a "Plan B" is that we won't then have an actual duplicate of the Production Environment.  Instead, plan B (what you laid out) would give us a second farm that happens to have the Production Content DBs (which is actually a pseudo-copy of production).  Those are 2 entirely different things.

The reason why having something that as closely mimics production is that we're doing this so we can legitimately test the 2007->2010 upgrade process with a replica of (not a pseudo-copy) of production farm.





0
 
LVL 38

Accepted Solution

by:
Justin Smith earned 400 total points
ID: 35215202
SharePoint (SQL really) doesn't like domain changes.  That's why it's never recommended to do what you did in order to replicate a farm.

I don't fully agree with your statement about the pseudo copy.  Almost everything in SHarePoint resides in the SQL db's.  If you have a standard farm with no custom code, then replicating the db's only WILL give you an exact copy.

If you do have custom code, as long as you deploy it to your dev farm, just like prod, you will pretty much  have an exact copy.
0
The Eight Noble Truths of Backup and Recovery

How can IT departments tackle the challenges of a Big Data world? This white paper provides a roadmap to success and helps companies ensure that all their data is safe and secure, no matter if it resides on-premise with physical or virtual machines or in the cloud.

 
LVL 1

Author Comment

by:crmsharepoint
ID: 35215250
Hi Achhilles, thanks for the reply again.  Well on of the concerns is that it's not just about SharePoint.  It's also about the servers.  

We're upgrading from Win2003 to Win2008 as a part of the process.  If all else fails an noone else chimes in, I may try a modified version of your solution starting at step 3 since SP is, in effect, already installed on the servers being that they are VMs of production.  We would then end of with a replica of production WFEs from the OS-level all the way through SP EXCEPT for the admin and config.  

On the SQL side, we actually DID install the server from scratch as opposed to doing a VM of of the production SQL.

0
 
LVL 38

Expert Comment

by:Justin Smith
ID: 35215276
I understand your concern about wanting to make everything exactly the same.  But in honestly in my real world experience, the OS has little to do with upgrade performance when going to 2010.  As long as you are testing on the same version/patch level, little to wory about.  In my experience :)
0
 
LVL 38

Expert Comment

by:Justin Smith
ID: 35215291
If possible, I would get your 2007 farm on Server 2008 and stable, first.  Then worry about going to SP 2010.  Not always an option, I understand.
0
 
LVL 14

Assisted Solution

by:KoenVosters
KoenVosters earned 100 total points
ID: 35215405
Supporting Achilles here. Moving servers from one domain to another is requiring quite some steps. You cannot speak of "Identical" situation any way as you are modifying SIDS on a live system, you joined them to a new domain, you used a new SQL. There is not a lot "left" of your original configuration. Personally I see this kind of action happen a lot in environments where there is no documentation about the production environment, how it was installed, which solutions were deployed, ...

The only way I would consider this viable would be to bring your SharePoint servers down. P2V them, P2V the SQL Box, P2V the Domain Controller and then set them up in a seperate LAN so they won't interphere with the domain.

Secondly, if you are doing all of this to decrease the risk of an upgrade, I would suggest you do not take the in-place upgrade route and do a content database attach upgrade. That  way you can put up your new sharepoint 2010 environment (P or V, whatever you like) and then snapshot (or use P2V and bring the P's down afterwards while you use the V machines and snapshot to test). That way, while your production farm is still up and running you can do user acceptance tests, load tests, whatever tests you deem necessary while your production environment is still up.

0

Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
SharePoint JSOM error 7 68
SharePoint 2013 Document Library Newsletter View Count 3 57
sharepoint 2013 calculated column error 5 31
Sharepoint Online 5 32
Note:  There are two main ways to deploy InfoPath forms:  Server-side and directly through the SharePoint site.  Deploying a server-side InfoPath form means the form is approved by the Administrator, thus allowing greater functionality in the form. …
Pimping Sharepoint 2007 without Server-Side Code Part 1 One of my biggest frustrations with Sharepoint 2007 in the corporate world is that while good-intentioned managers lock down the more interesting capabilities of Sharepoint programming in…
Two types of users will appreciate AOMEI Backupper Pro: 1 - Those with PCIe drives (and haven't found cloning software that works on them). 2 - Those who want a fast clone of their boot drive (no re-boots needed) and it can clone your drive wh…

809 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question