I want to perform the data migration between two SharePoint farms located on the same active directory. I don't know on how to migrate the data from one SharePoint from to another new SharePoint Farm
Several ways of doing this:
1) Backup content database on source farm and restore in target farm, then attach to a web application.
2) Create (i.e. export) a content migration package on the source farm and import on the target farm
3) Set up a content deployment path between the source and target farms (probably not appropriate in this case)
All of these are documented extensively on Technet. If you have custom or third-party code you will need to deploy these to the target server also.
The fundamental processes will be like this:
Create a new web application in your new WSS server.
Follow the instructions in Move content databases between instances of SQL Server.
However you may not be able to perform all of the steps exactly as written if your previous server farm is not available. The main thing is that you get the most recent backup of the databases restored on your SQL Server, then follow these steps from the linked article:
In Central Administration, on the Application Management page, in the SharePoint Web Application Management section, click Content databases.
On the Manage Content Databases page, click Add a content database.
On the Add Content Database page, type the exact name of the transferred content database, and then click OK.
Repeat steps 14 and 15 for each database you are adding. Be sure that you select the correct Web application from the Web Application menu for each database.
I don't know your farm topology but if you are sharing the same SQL Server used for the dead server farm, make sure that the dead farm is completely powered off. You don't want two different SharePoint farms accessing the same data (especially if one is in an inconsistent state).
If the old farm is alive and not in inconsistent state then you will be better off using a migration tool even if the versions of new and old are same.
The reason is that service packs, patches as well as order of their installation causes differences in SharePoint instances which can mess backup-recovery mechanism.
Migration is much more forgiving as it pre-assumes that differences exist between source and destination.
Several migration tools are available with Sharegate being my favourite.
Related
I'm trying to migrate content from one MOSS farm to another. Specifically a web application. The web application data is fully contained within a single content database. My process for doing this is as follows.
SQL backup content db from source sql server
Copy bak file over to destination sql server
Restore database from bak file on destination sql server - WSS_Content_DB
Create new web application on dest MOSS farm (http://newmoss:1234/)
Create root site collection
Via central admin remove the content database from new web app
Via stsadm add the content db (WSS_Content_DB) to http://newmoss:1234
As far as I can gather from online guides this process should work and result in the content from my source MOSS web app duplicated on the new MOSS web app.
The problem is, when I now browse to http://newmoss:1234 there is no content. If I manually add /_layouts/viewlsts.aspx to see the "View all content" page I see a few core libraries but nothing from the source web app. If I query the database though the content is there, it's just not wired up correctly.
Can anyone tell me where I am going wrong or offer me some guidance.
The database is around 600GB so fairly large. I've tried doing this backup/restore via STSADM as well but that failed during the restore process.
EDIT
I think I can see something strange when looking at the actual contents in the content database. The number of sites reported by central admin in the content database is 1. That matches what I see in the site collection list for this web app - one single root site collection.
When snooping around in the content database I can see several records in the "sites" table. This is strange as I would only expect to see a single site as per what Central Admin is telling me. Also when looking at the site ids in the database, and the site id of my broken restored site, it actually looks like the site that has restored is not the site I want! There are 5 records in the sites table and the restored site id matches the first record. The site I actually want (based on the column "Disk Used") is the third.
Any ideas what these other sites are and how I can restore a specific site?
According to https://sharepoint.stackexchange.com/questions/22150/content-db-restore-returns-0-sites, you cannot restore a content database from a site to a different site on the same farm.
If I use an existing web application's content database for a new web application, Will that import all lists,sites and libraries into the new web application being created ?
Or
The normal backup and restore is required ?
A content database contains one or more site collections and all the websites, documents etc inside that database.
This means you can take a copy of a content database from your production environment and use it in your dev environment. However you will not be able to attach two copies of the same content database to a web application.
It may be possible to use it again for a second web application on the same SharePoint farm, but I strongly recommend against doing that in a production environment.
A content database does not store custom code and other customisations, these have to be installed before the restored sites will work correctly.
For more:
http://community.bamboosolutions.com/blogs/sharepoint-2010/archive/2010/11/02/sharepoint-2010-cookbook-migrate-a-sharepoint-2007-site-to-sharepoint-2010.aspx
I need to create clone for particular web application on my MOSS server. I have taken full backup for my existing web application from
Central Administration > Operations > Perform a Backup. I just want to know how can I use this backup file and restore it on newly created web application.
Please note that my webapplication has more than 10 different site collections.
Thanks,
Ashish Chotalia
best way to do this is using the Backup/Restore feature in Sharepoint Designer as described on this site.
You can use Backup/Restore to move a site as well.
If you use Infopath forms on your site, carefully check where the forms are stored after moving the site. It can happen that they point to the "old" lists or databases.
So, my client wants a customer dashboard integrating all information related to a project in a common sharepoint site.
So we have something like this
http://tdg-srv-006/ <------- Sharepoint site (SP)
http://tdg-srv-006/PWA/ <--- Project Web Access site (PWA)
http://tdg-srv-tfs2/ <------ Team foundation Server (TFS)
He wants the following requirements:
Burn down Chart: this one is located in the TFS server inside the company.
Total count of bugs: this one is located in TFS too
Open Issues and Risks: This one is located in PWA
Team names and roles: this one in TFS.
My question is, how do I communicate Sharepoint with TFS database and with PWA information? any comments, suggestions or clues?
There are two ways to do this. Use the project dashboard site created from Project Server, or the one created by Team Foundation Server.
Project Server
The standard way of setting up such a dashboard with Project Server is to enable project workspaces. This means that when a project is first published it would have a URL such as http://tdg-srv-006/PWA/My%20Project. This is where the project 'dashboard' site will reside, containing both your integration with Project Server and with TFS.
These workspaces are created from templates. They can be extended with your own design and web parts so they will always be created exactly as you'd like. For example, integration with Reporting Services reports that query the Project Server reporting database or Team Foundation Server is a popular idea.
Note that project workspaces already come out of the box with risks and issues. (These can also be linked to tasks and other risks and issues for a richer experience.)
For aggregation, within Project Web Access it is possible to create a view which sums the risks and issues from across all project workspaces and displays them in Project Center. When connecting to PWA, users are also prompted with the risks and issues outstanding that are assigned to them.
Team Foundation Server
Team Foundation Server also creates its own SharePoint site which you may prefer to use. This article on SharePoint Magazine should give you all you need to know. Again, you can set up Reporting Services reports that point to a TFS data source and display the results in your workspace. It just depends on whether you prefer to start with a TFS workspace or a Project Server workspace.
Caution
Both Project Server and TFS only install the free Windows SharePoint Services (WSS) by default. This means functionality such as the content query web part provided in SharePoint 2007 (MOSS) is not there. You can add SharePoint 2007 without any issues but it will cost you more.
The template approach that Project Server uses to create workspaces (and perhaps TFS as well) has problems. Firstly, Project Server will allow you to change columns and fields on the Risks and Issues lists but this will cause errors. There is a safe method outlined in the link earlier on my blog. Secondly, assuming you decide to change the template you will need to programmatically update every workspace within Project Server, including the template to make the changes. Not a big deal but a hassle nonetheless.
Other integration
Finally add the Project Server / Team Foundation Server connector into the mix. This will ensure work item data in TFS is kept in sync with project plan data in Project Server. Note that it has nothing to do with creating a dashboard/workspace.
Whats the best way to deploy a webpart in WSS3 or MOSS2007 which has a database dependency? Should the .wsp include code to create the database, should I encapsulate the .wsp in another installer which handles the database creation, or should I supply two different packages to allow the admin to handle the backend creation?
Well, I prefer the SharePoint way where you create the databases from a SharePoint admin page in Central Administration. Just take a look at how SharePoint handles the creation of new Web Applications where you are asked to name the database server and the name for the SharePoint content database.
In other words, I would opt for a WSP only deployment. The WSP should include a database configuration page (an ASPX page) plus a farm level feature for installing a custom action link to the page inside Central Administration. The beauty of doing it from Central Admin is that it runs in a context with privileges to create new databases on the SQL server. Hence, you do not need to ask the user for login and password to the database server.
The configuration page should upon successful creation of the database persist the connection info in the SharePoint configuration page, using a custom derivative of the SPPersistedObject class. Web Parts can in turn read these settings to connect to the database.
MSI installers should in my opinion be avoided when designing SharePoint apps.
What sort of client is your webpart aimed at?
I imagine it might be worth being slightly flexible in your approach and considering multiple methods of installing your webpart.
So for someone without a dedicated DBA it might be best to have one .wsp.
(Although this should be robust enough to handle superuser's installing it.)
Alternatively go for a .wsp and a msi (or even scripts), which will give the installer
more control over exactly how it is installed.
(I'd prefer this approach, over the .wsp only approach.)