Solved

MOSS 2007 - Changing SP Server Name and Domain

Posted on 2010-08-30
5
872 Views
Last Modified: 2012-06-22
Greetings!

I am currently trying to move my SP servers to another domain, in order to test an upgrade.  Currently, I don't have a testbed for testing an upgrade to SP2010, etc.  So what I did was, make a clone of each virtual machine, and then move it to another domain.  I have three servers total:  SQL, Application Server, and Web Front End.

The tricky part is that, I want to keep the "real" servers online.  That way, I will have, essentially, two sharepoint farms with the same content on them.

However, whenever I try to get to central administration on the "clone", it goes directly to the original server for Central Administration...which is understandable because that's what SharePoint has been told to do.  I want to change that, though, so that they're two separate farms!

Original:
Domain: Domain1
SQL: sqlserver
APP: centraladminserver
WFE: webfrontendserver

I made copies of those, and would like to rename them to:
Domain: Domain2
SQL: SPSql
App: SPCAdmin
WFE: SPWfe

I went scouring the internet for answers, or a step by step guide...but I know that it was going to be hard because I'm not only changing the server name, and the domain, but this domain is missing the accounts that were used to service SharePoint in the first place.  domain1\spadmin won't exist, etc.

Here is what I have found so far, and what hasn't worked:
http://vspug.com/nrdev/2008/07/15/tip-how-to-rename-a-sharepoint-server-machine-name/
Changing the server name worked, however when trying to set an Alternate Access Mapping, it returned an "Object Reference not set to an instance of an object." error message.  Not to mention, I wasn't sure if I should be doing this on the server that hosts Central Admin, or the Web Front End.

I've tried going into Central Administration, but unfortunately it tries to open CA for the "real" server (remember, this is a clone that I've added to a different domain).  Because the URLs within SharePoint are the same, I think that's why it's trying to go to the "old" server.  

I've also tried http://moss-exchange.blogspot.com/2007/12/renaming-sharepoint-server.html to the same effect.

Apparently I'm unable to change the AAMs on the server due to that error that I listed above.


I wonder what would happen if I just uninstalled SharePoint completely, rebooted all three servers (SQL, Central Admin, WFE), changed the computer names, and then recreated the farm using the Products and Technology wizard?  Would I be able to point the new SharePoint farm at the already-existing configuratoin/content databases on the SQL server?


Any info would be appreciated, as this is a high priority, high visibility task...but unfortunately, I'm kind of stuck, since something is keeping me from changing the AAMs on the cloned servers.
0
Comment
Question by:ThatSharepointGuy
  • 3
  • 2
5 Comments
 
LVL 4

Expert Comment

by:djpileggi
ID: 33562157
Renaming servers is one thing, but trying to draw a farm with specific configurations to a different farm is going to be more painful and problematic than it is worth. I have been working with SharePoint almost seven years now and I would never take a client through the path you have chosen. Here is what I would do.
  • Run the SharePoint Configuration Wizard on the new boxes and select remove from farm
  • Once they are all completely off the servers, delete all the databases in the SQL database EXCEPT for the content Databases for the web applications (you can use those later)
  • ReRun the SharePoint configuration Wizard on the new boxes, the first one you run select create new farm
    • use your new domain accounts for this from soup to nuts (fixes one of your problems.  I am assuming you have the computers attached to the new domain :) )
    • If you dont like to have your configuration db with that long GUID use PSConfig to create a new config DB And Central Admin Content DB before you run the wizard.
  • Build your farm up and make your configurations you desire
  • When you build your web applications you can build your point to the content DB's you did not erase back in step 2 (if the Content DB's are too big and makes the process time out create an empty DB and then connect to the DB afterwards)
This should get you to the point where you want to be.  And you get to keep your sanity at the same time.  Hope this helps point you in the right direction.
0
 
LVL 6

Author Comment

by:ThatSharepointGuy
ID: 33563717
Dipileggi:

Wow, thanks!  I have my own personal installation of MOSS 2007 that I have used to build VMs up at home (received through the MSDNAA);  However, I don't have a copy of SP2010 (only Foundation is available, which is free anyway).  So the Powers That Be at work decided that this would be an excellent opportunity for me to be able to take the production servers, and do an in-place upgrade to SP2010 to ensure that everything works correctly.  

Reading documents online (like the links that I posted above) hinted at it being difficult, but not as difficult as it is GOING to be, I'm sure.  That's why I got worried and posted this question!

I've done those steps before, just in re-installing SharePoint on test VMs.  

What I've not done before, was using the databases, etc.

I'm leery of touching anything with the words "data" and "base" in the same sentence :-)

Just to be certain, when building the Web Applications...should I point them to the already-existing content database for the web application that exists in SQL?  Or should I create a new content database for the Web Application, and only use the existing content databases for the site collections, etc?  And all of this is on Step #10 here (MS Create Web Application KB), correct?

I've only been a SharePoint administrator for almost exactly 5 months, but I'm very worried about the procedure that I documented in the first part of the question.

Luckily, the customers will never touch these servers.  They'll be destroyed (VMs) as soon as the in-place upgrade to SP2010 looks like it's working.  They wanted to clone the servers so that they had "current" data, to show if any web parts on any pages had problems.

My original thought was just to wipe everything, mimic the settings from the production server, and just import all the sites via stsadm -o export/import.  

But since all the data is on the SQL server for this second farm, your method should be best, right?

Thanks for the help, and sorry for asking a ton of questions.  it's very interesting, this path that has been chosen for me, so I'm a tad bit worried, but either way it beckons to the 'geek' in me to spend all day on it.

Cheers,

TSG
0
 
LVL 4

Accepted Solution

by:
djpileggi earned 500 total points
ID: 33590024
Foreward:
Totally understand your trepidation! I learned how to do this in a trial by fire when I was doing a side by side migration back in 2007. I was migrating by hand specific stuff out of my companies 2003 environment into the 2007 environment. Then something when seriously wrong. The 2003 sites didnt exist anymore as i deleted the sites as I finished migrating it so I didnt do same sites over again. (not Recomended) Burning bridges is a bad idea. But even worse when the configuration and ssp db's got corrupted somehow. (read as me pulling a bonehead manuver) I deleted every single DB except for the content databases. I held onto those with my life... and job depended on it. So it worked. That being said lets warp to today where you are standing. Unlike me, the databases you are using is in a production enviornment. Cant be touching those per se. You can however put those in another SQL server (if you have it) ore restore them from backups as a different name (if you dont have another SQL server available to you for this test)
Your questions Answered in order (I hope)
Just to be certain, when building the Web Applications...should I point them to the already-existing content database for the web application that exists in SQL?  Or should I create a new content database for the Web Application, and only use the existing content databases for the site collections, etc?  And all of this is on Step #10 here (MS Create Web Application KB), correct?
 Do not point the new SharePoint environment to your current production content databases.  If you dont have a SQL server set to the side for the test environment then make sure you create copies of the content databases you are going to attach to the test environment.  When you get to step #10 as you in the Database name point it to the copy database using the exact name you called it. (Cut and paste is your friend)  This will work just fine unless the database is absolutly mondo massive or is a different version than the binaries or the test environment. (if you production environment is SharePoint 2007 SP2, be sure your test enviornment is the exact same)
My original thought was just to wipe everything, mimic the settings from the production server, and just import all the sites via stsadm -o export/import.  
There is one caveat (spelling?) using the stsadm tool.  Its good for small import exports, but anything over 750MB~1GB in size tend to be iffy at best at working.  Its best to use the export/import that is native to SQL server to copy/replicate the content databases you want to try and test on.  The PowerShell export/import tool is a bit more reliable, but I have not tried it on a 2007 environment. (yet...)
But since all the data is on the SQL server for this second farm, your method should be best, right?
Yes, there is no worry about loosing production data as I have peppered this answer post with.  Greatest thing about test environments, you can blow them up and a mushroom cloud wont appear over the horizon.
Hope this was helpful,
David J Pileggi Jr.
0
 
LVL 6

Author Comment

by:ThatSharepointGuy
ID: 33622472
My apologies for not posting back - I didn't have access to my email, and never got the notification of your reply!  Sorry!

That was very helpful and great information, David.  I appreciate it!

Nobody has told me, but I'm pretty sure my job depends on this as well, so I understand where you're coming from.  I was supposed to have the upgrade to SP 2010 done last week, which I did (although, I have another question open about an issue with having the server that hosts Central Admin showing "upgrade needed" in the "manage servers in farm" page...odd).

I ended up totally rebuilding the test farm and did the export/import to migrate sites from production to the test farm...most of which worked.  There were a few issues regarding Application Pools that were running as service accounts from the old domain, Application Pools that didn't get removed when I uninstalled/reinstalled IIS and SharePoint, etc.  Heck, even one issue that came up with content that was deployed to the GAC hiding in C:\windows\assembly!

Yikes!

I know what you mean about stsadm export/import being iffy....at times it seems like it works fine, but at other times it's like shooting yourself in the foot to unlace your shoes...you know it's going to work eventually, but it hurts while you do it (yet you have no other choice).

One of the primary sites that I need to migrate often has a document library with over 2000 documents in it!  I haven't checked the size yet, but I'm betting it's at least around 20Gb or greater (Power Point, Word, and Excel documents galore!).  I *always* have issues migrating this site.  And this time around was no exception, but I figure that I didn't need to bring them over for the test, since that site collection is pretty sparce, with very few minor customizations.  The error I got this time was something about a content type called "Owner" existing in more than once place within the Site Collection....another can of worms, so I ignored that site since I needed to get the Test farm up and running with SP2010.

So far, everything seems to be working fine with the servers themselves, except for this error in SP 2010 that I'm currently researching.

Thanks again for your advice, I wish I had seen it before I went through with the rebuild, heh.

I just wish there was a reliable way to export/import a site collection, no matter the size, without having a ton of issues on either side of the operation.  

Where'd I leave my genie lamp?
0
 
LVL 6

Author Closing Comment

by:ThatSharepointGuy
ID: 33622479
Great advice!  

Your experience speaks volumes about the quality of the advice given, thanks David!
0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

Lync server 2013 Backup Service Error ID 4049 – After File Share Migration
A safe way to clean winsxs folder from your windows server 2008 R2 editions
This tutorial will walk an individual through locating and launching the BEUtility application and how to execute it on the appropriate database. Log onto the server running the Backup Exec database. In a larger environment, this would generally be …
This tutorial will walk an individual through locating and launching the BEUtility application to properly change the service account username and\or password in situation where it may be necessary or where the password has been inadvertently change…

746 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

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now