i attempt to backup and restore tfs database to a auther server
Any idea about risk ?
and How i can manage TFS Server to change the new location of TFS database ?
You could move Azure DevOps Server/TFS from one machine to another by restoring it to new hardware (called a restoration-based move).
When you move to a new server you do not lose any of your project history.
One risk
In some situations you might want to change the domain of a Azure
DevOps Server deployment as well as its hardware. Changing the domain
is an environment-based move, and you should never combine the two
move types. First complete the hardware move, and then change the
environment.
Besides, another place need to pay attention to. You must have a complete set of data backups for the SQL Server databases. If the data was encrypted, you must also have the encryption key and its password.
For more information, see Back up Azure DevOps Server
You must back up the TFS_Warehouse and TFS_Analysis databases if your deployment is configured to use SQL Server Reporting Services and you want to restore those databases to a different server. You cannot just rebuild the warehouse, as you can when you restore to the same server or instance.
Once the backup completes, verify that the backup is available on the storage device or network share, and that you can access this backup from the new hardware.
Actually, we do have a detail step-by-step official tutorial, you could kindly refer and follow it-- Move or clone from one hardware to another for Azure DevOps on-premises
Related
I am working on a project to replicate an application that currently runs on premises to an Azure SQL Database. For the foreseeable future, the application will have to run both on site and on Azure. The project is stored in TFS, and multiple filegroups are specified. Development is ongoing. Is there a way I can maintain this as one project in source control, given that Azure SQL databases only have a primary filegroup? I feel like I can't be the first person in this situation, but I haven't found a decent solution yet.
I'm fine with the Azure database only running on primary, but that is not an option for the local database. This is not for a single deployment, I would like to continue to deploy changes both locally and to Azure from source control. I may be asking for too much here, I just really really want to avoid dual maintenance, when there are a number of teams involved.
Thank you!
You have two options:
Add manual SQL Statements to setup Filegroups on your on-premises SQL Server that don't run against SQL Azure
Use a new feature of Azure named SQL Managed Instances. This is fully managed SQL Server instance running in Azure that supports all features of SQL Server such as filegroups. Don't go installing your own SQL Server on IaaS. That's not necessary anymore with this new feature.
There is no way to use multiple filegroups in Azure SQL Database. If you want to move your database to the cloud and keep the ability to use multiple filegroups, please consider setting an Azure VM with SQL Server on it. Another option would be to change your application so that it does not use SQL filegroups.
As for the replication, please consider SQL Server replication or Azure Data Sync. Azure Data Sync requires an Azure SQL database. It is slower than SQL Server replication but it can handle conflicts.
We are moving our installation from a hosted server to a VM on our local network. We have a mix of local users and Domain users. I am concerned about the local users that were created on the existing server. What will happen to them in the new environment?
For example
Server1\JohnDoe will not exist on the new server. What is the best practice for this?
What you are effectively doing is a domain change from the perspective of TFS. You need to merge two procedures. First is the environment move:
http://msdn.microsoft.com/en-us/library/ms404883.aspx
And the second is the hardware move:
http://msdn.microsoft.com/en-us/library/ms404869.aspx
What you are doing is both at once. This can be done safely and you need to be very careful with the accounts issue.
I have done this a whole bunch and documented it:
http://nakedalm.com/in-place-upgrade-of-tfs-2008-to-tfs-2010-with-move-to-new-domain/
Thats for an older version but the principals are the same.
We are four developers in different locations (in a 100 km radius of each other) tryint o collaborate on a software development project.
We would like to install Team Foundation Server 2010 on one of our machines (we are all using Windows 7) and use that as our central source code repository and work items management.
However we cannot seem to be able to configure TFS to accept remove connections (through Visual Studio). Is it possible to use TFS in this manner?
TFS is just a bunch of web services and should be set up for remote access out of the box.
Things you'll probably need to configure.
Make sure that the windows firewall is allowing TFS to accept incoming requests on port 8080 (the TFS install may do this for you)
Configure your router to use "Port Forwarding" so that requests from the internet to port 8080 are routed to the machine with TFS installed.
Your ISP probably allocates IP addresses dynamically so you might need to sign up for a Dynamic DNS service such as NO-IP.com. (check which ones are supported by your router)
Once you've done this then you should be up and running.
I'm sure others will suggest that you ditch TFS and use a DVCS such as GIT or Mercurial, they have a point! You should consider if it's worth the effort of getting TFS to work in this way when another system might be easier to get up and running.
TFS works just fine for this type of scenario and whether you use a DVCS or not you're still going to have to configure access. You don't need to set up proxies. TFS is extremely fast even over a slow connection. The 3 things you need to remember if you're not on the same domain as the TFS are:
Have the TFS administrator set up your TFS rights using a domain account set up for you. If you don't have a domain account set one up and use it. If there's no domain then create a workgroup account or a local TFS server account.
Add your domain (or workgroup or local TFS server) account credentials manually to the Windows credential store or TFS will keep bugging you to login and that's a pain. Make sure you include the domain (or workgroup or local machine name) in the user name in this format: MyDomainOrMachineOrWorkgroup\MyUserName. No backslash at the beginning, no backslash at the end.
You need to either use the IP directly to connect or add an entry to your hosts file (C:\Windows\System32\drivers\etc\hosts). For those that haven't ever gone into this file the "etc" is actually the directory name not just me saying "and so on". The entries there tell you that when you type an address like mytfs.mydomain.com it should go to IP such and such. That's all.
#Nigel We have TFS on a remote server with local proxy at my workplace. Our internet connection is quite slow relative to the number of developers on site. TFS has extremely poor performance in this configuration compared to having the server local. Our solutions can be several hundred MB to download (of which there are a few branches). Checking version history is slow and painful. Retrieving shelvesets is slow and painful. Checking in on VS2010 or VS2008 is slow and painful. Fortunately VS2012 does this asynchronously so checking in is not so bad but you will eventually get a modal dialog when the op is complete.
All in all, I would say a poor experience compared to SVN let alone DVCS.
you can use AnyDesk (version 5.2+) which allow you to set up TCP connection between clients.
I used it for connecting my client PC to a Team Foundation Server (TFS) over the internet. The server and client are behind NAT. I set the local and remote ports to '8080' and I can connect to server from client using this address on client: 'http://localhost:8080/tfs/'
Reference: TCP-Tunneling-AnyDesk
I don't know squat about TFS, other than as a user who has performed simple check in/outs.
I just installed it locally and would like to do joint development with a friend.
I was having trouble making my TFS web site on port 8080 visible (the whole scoop is here if your interested) and I wonder if it could be related to the fact that TFS is probably using Windows Authentication to identify the user.
Can TFS be set up to use forms authentication?
We probably need to set up a VPN, though that's a learning curve too.
To use TFS, do our machines have to belong to a domain?
We're not admin types, though he is better than me, though I would be interested in any feedback or advice on which path is likely to pan out the best. I already got AxoSoft OneTime working in this type of an environment and it suits us well, but I am tempted at all the bells & whistles with TFS and the ability to tie tracked bug items to code changes.
As far as finding a good way to share code, do sites like SourceForge allow one to keep code secure among members only?
It does not need to be installed in a domain. I'm running TFS at home within a workgroup on a virtual machine.
Create a user on the machine that hosts TFS. Let's assume this machine is named TFS-MACHINE. Grant that user appropriate Team and Project rights.
When connecting to TFS from the remote machine, the user should be prompted for a user ID and password. They should use a User ID of TFS-MACHINE\username and the appropriate password.
Regarding external spots to host code. If you're looking for cheap/free, you can look at something like Unfuddle, which supports SVN and Git.
If you're looking for hosted TFS, the only place I've been able to find thus far is SaaS Made Easy, but they can start getting a bit expensive, depending on the number of users you have.
Keep in mind if you're going to host locally that you'll still need to do things like periodic backups, etc.
I'm currently tasked with setting up a TFS server for a client. The TFS will mainly be accessed by local (on-site) users through the internal network... Easy!
But what about the few remote users we have? Should they connect via VPN or is it better to make the TFS server public and have the users connect over SSL and provide username and password to the TFS?
Do you have any suggestions on how these solutions will perform compared to each other?
VPN is the way to go if you want the optimal TFS experience with TFS 2005 or TFS 2008. While TFS mainly uses web service based protocols that can all go over SSL, there are a few small things that will not work unless you have proper network access. For example:
Viewing the Build Log (unless worked around)
Access Team Build drops
Publishing Test Results
As well as a few other little niggles. Going the VPN route will also mean that your TFS installation will vary less from a standard base TFS installation which gives you some peace of mind that you won't run into any problems when it comes to upgrading to a new version, applying service packs etc. (or at least any problems you run into will have been run into by many before :-) ). Going the SSL route you are treading a less worn path - though obviously plenty of people do run it that way including CodePlex and all the commercial companies that provide a hosted TFS installation.
The downside of VPN is that usually you are granting users to an entire section of your network (unless you are running TFS in it's own mini private network or something). If you go down the SSL route then be sure to properly test the new team projects as this is easy to break and you might not realise until you try and create one either inside or outside the network.
For additional information, see Chapter 17 of the TFS Guide.
I'd start with a few questions: does the client have a VPN? And are the remote consumers on this VPN already? How secure does this need to be?
(In our case, we have lots of outside vendors we don't want on our VPN, so our source control is publicly accessible with SSL)
When I did it, I used a VPN. Was easier to setup, and made sure that no-one could even see the machine with out being authenticated via the VPN - this was obviously way better from a security standpoint, which trumped any performance benefit we would have got from using SSL, if there even was one...
My previous experience with TFS was in an environment where we had a team of developers staffed out at client sites all over the city. In many situations we still accessed our TFS instance instead of something at the client site. We used SSL with public access to TFS. It worked very well for us.