We have installed the TFS Beta-3R on server and our dev team is working on that for the couple of months. Know we want to move this to license version which we brought.

As per the documents available i have followed the steps in migration to new server which is on a same domain. but this has a different server name.

I am able to restore exactly releating to TFS but unable to restore the same with Sharepoint2.0. on new server we are using sahrepoint2.0 the same available on existing server. i get lot of errors tough i followed many documents available online. i was doing this for nearly 2months and still unable to restore the share point.

The steps i followed to restore the share point

1) Backup the STS_Config, STS_Contenet_STS

2) Restored the same database in new server with the same old database existing on the old server.

Ex:new server path://C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data

3) As per the documents available i went to "Add Content Database" in sharepoint central administration and try to give the new server name and old database name, that gives me an error saying that "Database with the same name already exist"

what do i need now from u

1) Clear steps for migrating the sahrepoint in TFS

2) Any pre-cautions to be taken

3) And in some documents they say only take the backup for only STS_Contenet_STS not from STS_Config.. is this true.

4) Clear configuration steps on this activity.

we have lot of documents already exisitng on the TFS Server. Is there any alternative to retrive these documets to the new sahrepoint configured on TFS Server, so that i dont need to take the backup of sharepoint. By doing this activity i can create a new sharepoint site and upload all the documents available on existing server to new server.

we use share point on the old TFS server for just working with documents only..



Re: Team Foundation Server - Administration Restoring the sharepoint 2.0 on new TFS server

James Manning - MSFT

It sounds like you're trying to move the Beta3-Refresh databases to a new RTM install Unfortunately, there are known problems with that kind of configuration - for instance, the schemas don't match.

What I would recommend, if this is acceptable for you, is: