I was tasked to research migrating a 2007 MOSS to ShrePoint 2010. Got two servers, one is runing a SQL 2008, and the other has SharePoint 2010 already installed. I need to migrate several publishing and team sites and their corresponding databases. I started reading this article on Upgrade and Migration for SharePoint Server 2010
, then another at Migrate an existing server farm to a 64-bit environment but have a little confusion about wheather I'm migrating, upgrading, or moving the system, as each article defines steps to do this.
Current 2007 MOSS and SQL 2005 are on Windows 2003 32-bit OSs. The new system which at this point in not part of the farm but is in the same domain, are a 64-bit blades running Win 2008 OS with SQL 2008 and SharePoint 2010 - all already instaled / Central Admin site already running. The whole farm consists of 2 severs I just described.
Thanks for reading my post and appreciate any pointers!
Risho.
I just went through this exact scenario. The documentation on the various methods can get confusing. Note, for simple farms (no BDC, etc.), all you really need is the content databases. Here's a simple way to accomplish your goal:
On existing, 2007 farm, make sure it's Service Pack 2
On existing 2007 farm, run stsadm -o preupgradecheck
Fix any errors identified by the upgrade checker
Backup the Content database(s) you want to migrate (old 2007 farm)
Restore Content database(s) to new SQL server
Create a new Web Application on the new 2010 farm. A new WebApp will need to create a Content DB, so name it something like WSS_Content_Temp. This will be the WebApp that you will restore your Content to, so name the WebApp appropriately. You'll remove the content DB, so name it whatever you want.
From PowerShell, run: Test-SPContentDatabase -name <NameOfMovedContentDB> -webapplication http://yourNewWebApp
Fix any errors identified
From PowerShell, mount the newly restored/moved database. Run Mount-SPContentDatabases -name <NameOfRestoredContentDB> -webapplication http://yourNewWebApp. You should see a progress % number that is incrementing. Depending on how big your content databases are, this could take a while (30+ minutes)
From Central Admin -> Application Management, select/highlight your new Web Application.
The go back to Central Admin -> Manage Content Databases, and remove the original, temp Content DB (WSS_Content_Temp)
At this point, if all went well, you should be able to browse to http://yourNewWebApp and see all your content.
Rinse and repeat as needed.
Related
we got TFS 2013 install, it was successful install and working fine, until we need change the data tier database, so how could config TFS app server pointing to new named database,
the database instance is same one, just changed it name
You can use the tfsconfig registerdb and remapdbs command to achieve this rename/move scenario
tfsconfig.exe remapdbs /DatabaseName:data.tfs.contoso.local;Tfs_Configuration /SQLInstances:data.tfs.contoso.local
Ed has a blog on this too.
This might be wrong place to ask this question.
I spent effort in setting up thr sharepoint 2010 2 tier farm. I have settled up the sql server databases required for sharepoint, installed on different machine. and sharepoint on another machine. it took around 6 days, but at the end i noticed that i have computer name with something "win43453-676" like this. where as my manager wants to to keep relavant name like "CentralAdminMachine" of central admin pc. if i changed the name of machine , i am unable to open even central administration site. is there any remedy to change this name in configuration database and all....?
There is both a PowerShell cmdlet and an STSADM command that allow you to change the server name. Both require that you first change the name through the standard Windows System control panel. After that (and a restart) you can use:
Rename-SPServer [-Identity] <OriginalServerName> -Name <NewServerName>
http://technet.microsoft.com/en-us/library/cc263117(office.12).aspx
or
Rename-SPServer [-Identity] <SPServerPipeBind> -Name <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
http://technet.microsoft.com/en-us/library/ff607556.aspx
There are some people who seem to recommend the STSADM (even though PowerShell is the Microsoft recommend way on SharePoint 2010) because it seems to work and not the give error that the PowerShell command does about feature dependency, but it looks like you can try either one.
And you may need to update your alternate access mappings to enable any custom URLs to work as well.
I am trying to migrate MOSS 2007 to sharepoint 2010 and I got the error while restoring the backup. The steps I followed are
I have the back up file and all solution pakcages from MOSS 2007.
I have a brand new server setup with sharepoint 2010 and Sql server 2008(64 bit) and windows server 2008 (64 bit).
3.I have created a new web application and new site collection.
4.Successfully Deployed the solution packages using powershell command.
5.trying to restore the backup and got the error
Restore-SPSite: THe site collection could not be restored, If this problem persists please make sure the content databases are available and have sufficient free space.
CAn anyone help me how to resolve this. I tried following some suggestions I got through google, but nothing worked for me.
Thanks
You can't directly restore the moss2007 backup to sharepoint 2010. You need to restore it back to SharePoint 2007 and then migrate it. If you have a database backup of the content database, then you could follow the steps given:
Take the backup of the content database from the SharePoint 2007
database server.
restore it to the database server of the 2010 environment.
Run the cmdlet Test-SPContentDatabase –Name -WebApplication using powershell to make sure that all the required dependencies are available on the 2010 server.
create a new web application on the 2010 server and add the content
database to it. upgrade the visual look of the web application by
doing to the site settings.
I hope this will help you out.
This is my first try of Visual Basic 2010 Express, though I have 10 yrs+ experience in VBA.
I'm running Windows XP SP2 on a desktop pc with following installed:
Visual Basic 2010 Express... just installed!
SQL Server 205 Express ... been running on pc for 12 months
I've created a new DB in SQL for my test application, but have not added any users or permissions to it as I'm using Windows authentication.
I've created a new Windows Forms Solution in VB2010EXP and tried adding a new Data Source for my new SQL DB, but it keeps giving error message about not having rights ot the db.
2 days of searching on the web has confirmed many others with similar issues, but no obvious solution. Eventually I find a few threads about permissions and moving the mdf into the root of the HDD, so try moving my mdf file up closer to the root of the Hard Drive
msf was in C:\Documents and Settings\_SharedData\Application_Data\MSSQL2005\Data\
now in C:\SQL2005\Data\
Now I can finally add a data source to my Db and start to use VS.
Problem is now occasionally when I am workng in VB and then go to the SQL Management Studio and try and view/change my DB, it gives an error and I cant access my DB. I then have to detach and re attach to my DB before I can work on it.
So my questions are:
Surely the location of my MDF file
should not be critical???
Do I need to add a user and
permission to my DB or should VB be
able to deal with this automatically
as I'm using windows authentication
Are then any known issues with
VB/VS causing errors in SQL
Managment Studio?
Thanks in advance
Grant
SQL Server runs on a different Windows Account to the one you use. You can check this by going to services (Run > Services.msc) and under SQL Server, go to properties and the Log On tab. I think by default 2005 uses the 'Network Service' system account. Now the reason you can't attach an MDF sat inside your documents folder is that account doesn't have access to your documents. You could give it permission, but you're much better off having the databases closer to the root as you have done.
Your connection to the database is driven by the connection strings you use. My personal preference is to create SQL Login accounts for my applications, and give them the least possible permissions they require. You could do the same using a Windows Account if you prefer.
I'm sure there are a couple. What is the error you are getting that prevents you accessing the Db? If we can see this error we may be able to help better.
Hope that helps.
We're trying to get rid of all of our SQL Server 2000 databases to re purpose our old DB server... Sharepoint 3.0 is being a showstopper.
I've looked at a lot of guides from Microsoft and tried the instructions in those. I've also just tried the good ol' exec sp_detach_db / sp_attach_db with no luck. Has anyone actually done this?
my boss has. it was a real pain. permissions issues. he used the built in sharepoint backup tool. I can more details tomorrow if need. I'll check back.
I'm back. Here's the steps he used.
install an instance of sql server
2005 on the sql 2000 box
(side-by-side)
back up the sharepoint site using the sharepoint admin tools. This will create a one mother of a large xml file w/ the whole kit and kaboodle (the site & all it's content)
delete the old-n-busted sharepoint site
create a new hotness sharepoint site using the sql server 2005 as the database.
do a restore from the xml backup using the admin tools - this will take hours to run (thank you xml ...)
Bingo!
P.S. I forgot, the account you use to do the restore must be an 'sa' account.