I am currently building Non Production TFS 2015 environment. I am restoring database including DBs from production to the new QA DB instance. I performed DB restore using TFSRestore.exe. The restore work successfully.
In TFS QA then I install Application Tier and configure to TFS QA and TFS QA service account.
Then I did RemapDBs, Reset Owner, RegisterDB then start the service. Then I change the Notification URL to point to QA TFS Url.
What is strange is that I can see that in Applications Tiers, I can see 2 machine names display. One is TFS Prod machine and TFS QA Machine Name. How I can remove Production TFS machine name under Application Tier section.
I check the checkbox "Filter out machines that have not connected in more than 3 days"
After 3 days the TFS Prod machine is remove from the Application Tier section. Since I want to do inplace upgrade to the next version therefore is it safe to do this?, how do I know this would not impact the TFS Prod?
I did run the
TFSConfig ChangeServerID /SQLInstance:SPTEST\Contoso /DatabaseName:Tfs_Configuration /ProjectCollectionsOnly
as result, it created new hostID (Guid Number) inside TFS_configuration.tbl_ServiceHost. However, when I select a project in Team Foundation Server I receive an error TF31001: Cannot connect to Team Foundation Server at Project1. The server returned the following error. Value cannot be null. Parameter name: service Definition
Resolve this by delete anything under cache folder
c:\users[username]\Appdata\Local\Microsoft\Team Foundation\5.0\Cache
This is similar post
https://social.msdn.microsoft.com/Forums/vstudio/en-US/0ba7caad-4210-4991-b6f0-d4f1dd8c409b/removing-application-tier-server
According to your description, your scenario should be Move or Clone Team Foundation Server from one hardware to another
(Clone option) Reconfigure server IDs and remap databases:
Perform the next set of steps on the new application-tier server if
you intend to continue using the original TFS instance. These steps
are necessary to avoid the risk of corruption of one or both
deployments. If both servers are live, you could end up with
corruption, particularly if they are pointing to the same SharePoint
or reporting resources.
So, please try to Reconfigure server IDs and remap databases. If that still not work, I'm afriad that you have to remove the DB instance and reconfigure the QA envrionment step by step following the instruction mentioned here.
UPDATE:
Seems you just restored an application-tier server but not Move or Clone Team Foundation Server from one hardware to another
For restoring an application-tier server, the name of the old application-tier server remains there is expected (See the end of this article.).
Note: The name of the old application-tier server will still appear in
the list of application-tier servers in the administration console for
Team Foundation. If you select the Filter out machines that have not
connected in more than 3 days check box, the old server will disappear
from the list within three days.
So, to avoid showing the old App Tier machine name you need to follow the steps to Move or Clone Team Foundation Server from one hardware to another as I mentioned in the original answer.
Note: You must install but not configure TFS on the new data-tier
server, and then use the restore function in the Scheduled Backups
node
I am also getting this issue. I followed all the cloning steps to move to my new TFS boxes, and I got it up and running, after running the command TFSConfig ChangeServerID.
But on the new server, under Application Tier > Application Tiers, I see two servers.
The new SQL box, and the old TFS box!
This is on TFS 2017.
Related
I have already set up my clustered environment. But now, there is a requirement came for reporting service for only one instance.
When I try to add it using the "Add feature to the existing environment" option in setup. However, I can't see Reporting Service on there.
So how I install and set up reporting service to the required instance.
As you may know, SSRS is not a cluster aware feature, so the install requires some extra steps. Also, if you want high availability for SQL Server Reporting Services you should deploy it in a farm which provides both availability and load balancing.
Adding SSRS on an installed SQL Server Cluster Instance is not so straight forward. When we try to add SSRS on an existing SQL Server cluster instance, the install does not allow us to proceed after the Installation rule check page because one of the rules fails during the rule check process. One solution is to install SSRS as a separate instance, but since this configuration was already a multi-instance cluster I was not in favor of increasing the number of instances by installing SSRS as a separate instance. Below I will explain the step by step method to configure SSRS on an existing SQL Server cluster instance without deploying a farm
Step 1
To add/install SSRS on an installed SQL Server Instance, we need to run setup again on each cluster node. First run SQL Server setup on your active node (Node 1). Follow all necessary steps in the setup windows. Make sure to run this setup to add SSRS on your existing instance rather than creating a new instance. Choose Reporting Services on the feature selection page of the setup window. After we start the install, we will get an error because one of the rules will fail as shown below.
Step 2
When you get the above error, you cannot proceed with the install because the "Next" button will be disabled due to this failed rule.
To get a detailed report about this failed rule, click on "view detailed report" shown in the above screenshot and you will get details about this rule as shown below.
Step 3
As we already saw that we cannot add SSRS to an existing SQL Server cluster, the solution is to run setup and skip the installation rules to install SQL Server Reporting Services in an existing clustered instance.
Run the below command at the Windows command prompt to start SQL Server setup on the active node. Make sure to run this command after changing the root directory of the command prompt to the location where you have placed the SQL Server setup files.
Setup.exe /SkipRules=StandaloneInstall_HasClusteredOrPreparedInstanceCheck /Action=Install
Once you press enter to run the command, the SQL Server product version will display on the command prompt, as shown above, and an installation window named "Program Compatibility Assistant" will appear. Now click on "Run program" to proceed with this installation.
Step 4
Now follow the same process which you normally do in an installation. Again choose the existing instance to add SSRS and select Reporting Services in the feature selection page which we need to install.
Now this time you can see the installation rule check passes without an error, because we skipped the installation rule process to make this installation possible.
Step 5
Here we can see the "Next" button is enabled, so click on Next to install SQL Server Reporting services on the active node.
Step 6
Once you are done with the installation on the active node (Node 1), follow the same process on each of the other nodes in the cluster.
Step 7
Now that each of the nodes has Reporting Services installed, it is time to configure Reporting Services on each node using "Reporting Services Configuration Manager" which can be found under configuration tools.
Here the configurations would be the same as you would have for any Reporting Services configuration. One thing will change though, we will use the SQL Server failover cluster network/virtual name while making a connection to the report database server. If we use node names in place of the failover cluster network name, the report server will be unable to connect to the report server database in case failover occurs.
Configure Reporting Services on each node in the same way with SQL Server failover cluster network name otherwise you will get the below Report Manager error after failover when an instance is online from another node.
Step 8
Now you are done with your SSRS configuration. Go ahead and launch Report Manager to check whether SSRS is configured properly. You can also test your Report Manager accessibility after failover and failback to verify whether it's providing the necessary failover functionality.
At my company we are currently using TFS 2010 which has installed on-premise and we are developing application on it that it is contiouusly being deployed on Microsoft Azure platform.
Our plan is to upgrade our TFS 2010 to version TFS 2015 and host it on a VM on our Azure subscription since this will ease our continuous deployment speed very much by removing network latency, in addition we will be able to use TFS new features.
Question I have is,
What do we have to do to move all TFS project work items, user stories and source code to successfully finish this move and upgrade process.
Before you give your answers, please take into account that we also want to create a local users on new TFS server and map domain users which they are created on the company's active directory server, on Azure VM and during TFS movement we would like to be able to show moved changesets, workitems... everything have been created in TFS database with the newly created local users on the Azure VM.
Firstly, please have a check on this blog for the details on how to do migration upgrade for TFS: http://blogs.msdn.com/b/tfssetup/archive/2013/12/19/migration-upgrade-from-tfs-2012-to-tfs-2013-with-reporting-and-sharepoint.aspx (This blog is about how to upgrade from TFS2012 to TFS2013, it applies to TFS2010 to TFS2015 as well)
Then after the TFS server is moved/upgraded successfully, create a user on Azure.
We are developing a small application that needs to have a local database installed on each users computer that will then sync up to the main database, via web services etc...
Anyways when we deploy the application on the users computer we want to use clickonce deployment. Now I have used this before but not attaching a SQL Server database. I know you can go to prerequisites in clickonce properties and click SQL Server Express.
Now the question is, when you have created your .mdf database file including stored procedures and all - how do you get this attached and setup automatically in the local database that is just installed through clickonce?
Also once this is finished in the future we may want to run updates to the database on the clients machines. We would like to use clickonce for this to publish database updates. Obviously we don't want to overwrite the database and just publish the latest updates based on if they already have the database or not and what version they have.
How could this be achieved using clickonce? Thanks
I am working on DW with SSAS cube. While development, my Cube is hosted on SQL SERVer 2008R2 on a development Server (Windows Server 2003).
Now, post to development phase I need to host the cube on test Server which would be on a remote location to which I do not have the access.
What are the possible ways I can host it on the server keeping in mind that If needed I need to re-deploy on server from BIDS Studio (when some bug arises).
What credentials I'll be needing (Will it do If I have a SQL sys rights or a windows account in that domain is a must)?
Thanks in advance!!1
In theory you shouldn't worry about it, taking into consideration of course, you have someone with access to the destination server.
You should never use BIDS to deploy your cube, it cant deal with partitions or security for example. Every deployment would overwrites these management settings of the target server.
Instead, you should use the Deployment Wizard to create your script and the you would send it to the person responsible for the deployment.
If you need more info about the deployment wizar, check my answer on this post
I had a SharePoint server, now i want to move this from one machine to another machine.
This is what i did for the migration.
I have just installed sharepoint server in my new machine and i have removed the Sharepoint_config and wss_content databased from the new server. and i have restored both the databases from the old server. Then i tried to run the Central Admin and i got Unable to connect to content database error.
Is replacing the DB is wrong. is there any other way to migrate SP server from one machine to another. I have tried my taking Farm backup and restore i had many problem with that. so i feel replacing DB would be better for me. any suggestions please?
Move SharePoint between servers is a huge effort.
Data in databases are very depends on the SharePoint install and its environments. So, I suggest just re-install the SharePoint on the new server, and then restore site collection backups to the new install.
Install SharePoint Server on the new server machine
Backup site collections from the old server, follow this guide: http://technet.microsoft.com/en-us/library/cc263441(v=office.12).aspx
Create Web Applications on the new server
Restore site collections from the prev. backups, follow this guide: http://technet.microsoft.com/en-us/library/cc262087(v=office.12).aspx
Be aware, if you have farm level customize solutions (developed by Visual Studio) or css files deployed in the LAYOUT folder, don't forget to re-deploy them on the new server.
I guess this question is too old and my answer will not help topicstarter... However, I was looking to refresh my own knowledge on this topic and I feel it will be useful to share it here.
This solution is not good for every SharePoint deployments, of course, it's just a general idea.
And I don't think it suits production environments well... but if you are brave and foolish as myself, you can do it there as well, with some additional precautions like backups and so on.
Here are prerequisites:
SharePoint was initially installed in Farm mode (not in Single Server mode)
Both old and new servers are in the same domain
You know Farm Passphrase used for initial installation
Old server is still intact and accessible from the new server
Steps to do
Skip steps 2-6 if you don't want to move databases to new location
Install SharePoint on the new server and join to existing farm. See
https://technet.microsoft.com/en-us/library/cc261752.aspx for details on joining procedure.
Ensure that the SharePoint is read-only. You can just shut down MS SQL DBEngine service if it's ok for your users.
Install MSSQL Server on the new server or other location you want. Remember, that it's not a good idea to keep SharePoint and MSSQL on the same server if it's not a demo/dev environment
Move all SharePoint databases to the new MSSQL Server. You can simply copy all DB files and attach it to the new SQL, or go full backup and restore way.
Important: Create an SQL client alias on the new server with cliconfg tool. See blogs.msdn.com/b/priyo/archive/2013/09/13/sql-alias-for-sharepoint.aspx for details.
Use your old SQL instance name as alias name. E.g. if your old server had SQL installed alongside with SharePoint on SharePoint.mydomain.com, alias name should be "SharePoint.mydomain.com"
Set Server name for alias to the new SQL location. Something like "NewServer.mydomain.com"
Ensure that you specify correct port number for SQL connection or configure network for default dynamic port. It is not necessary only if you have local SQL server on the same machine.
Create identical SQL client alias on the old server (this is needed to correctly remove old server from farm)
Remove old server from the farm. See this technet article for details
Update DNS settings or whatever you use to point users to the new server.
That's it. Hope it will help someone