As a a part of the Artifactory Migration of one product from a group of products , we are decided to go with Pull Replication from New server to Old server .
What is the best way of making Remote Repositories (which are pulled from Old server ) to Local repositories in the New Art instance to have the same configuration as Old server (which are Local)
Or We have another plan to go i.e We are keeping the migrated Remote repositories , and creating a local repository for each remote and then accessing these two with same url by creating a virtual Repository which includes the local and remote. (is this works good )
Please let us know if any best approaches here for my case
As a a part of the Artifactory Migration of one product from a group of products , we are decided to go with Pull Replication from New server to Old server .
What is the best way of making Remote Repositories (which are pulled from Old server ) to Local repositories in the New Art instance to have the same configuration as Old server (which are Local)
Or We have another plan to go i.e We are keeping the migrated Remote repositories , and creating a local repository for each remote and then accessing these two with same url by creating a virtual Repository which includes the local and remote. (is this works good )
Please let us know if any best approaches here for my case
Related
What's the best practice of migrating pentaho job/transformations from one server to another?
We've set up DEV, QA, UAT, Production PDI server with carte running on AWS. And developers in our team are using community edition to program and test locally with local carte service.
The servers are using database repository and local pcs are using file based repository.
Typically, when we migrate a transformation we will have to export xml and find those xml piece for that transformation/job and import into target servers.
I don't think this is a good practice, considering we are moving on CI/CD along with other java/js code.
Please advice a better way to do migration.
Thanks,
Martin
I think your issue is less about migrating from one server to another, and more about migrating from one repository type to another. Do you have a compelling reason to use different repository types?
We use file-based repositories for all environments, and a directory synchronization tool for migrations. We went with file-based repositories so our source control system could be used with it.
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.
We have a purchased commercial app that accesses a named, locally installed SQL server instance.
Is there any way for us to transparently move the DB to a remote shared SQL Server host, but still have things configured within SQL Server so that the local software can access as it it were a local instance?
Keep in mind, since it's a purchased software package, I don't have the ability to modify the queries it's running, so if tables have to change into fully qualified, or other special T-SQL syntax to make this work, it's not an option.
Effectively, we need to "trick" the app to use a remote database, but access as if it's a local instance (though configuration, some sort of proxy, or perhaps dark magic).
The total extent of the application DB configuration settings is to select the name of the local instance to connect, as shown in this image: .
SQL server is installed on the local machine (Win2012R2x64), and has a couple instances running. I have complete control of both local & remote SQL servers, so can make unrestricted config changes to them. Current DB version is SQL2014, but could upgrade to newer if newer version features are needed to do this.
You can try creating an alias to the remote sqlserver from the local sql server. (Via Sql Server Configuration Manager | Aliases | Add a new Alias name)
Your local instance alias should be the name server name that the connection string is using to connect.
I've used this method in the past to change the sql instance that I was connecting to without changing any connection string info.
More info here
It depends what sort of access the commercial app needs in the locally installed database once the app has set up and created its database.
You will probably invalidate any support agreements in the attempt. Worse still, if a commercial app insists on a local instance then I dread to think what security horrors it will insist upon in your shared instance.
You need to profile the database while the functionality of the application is used to find out what it does and how it does it. Even if you determine that the security permissions could be greatly restricted you may find that the app checks to see if it has a higher permission level.
I've no way to hand of testing this approach but....
Install the app as usual which will be on your local instance
Back up the DB on your local instance and restore the DB to your remote instance. Remember to set up what logins are necessary.
Set up a linked server to on your local instance to your remote instance.
Delete all objects in your local DB instance
Create sysnonyms for all objects pointing at the remote instance.
If it is an application that simply requires direct table access this might work. It is however an ABOMINATION.
We have a remote repository (Which has .repo and multiple git projects in it)
We want to replicate the same to local server.
With the existing replication.config file
url = gerrit2#15.145.25.168:/home/gerrit2/gerrit_testsite/git/${name}.git
Only the git projects are replicated to local server.
How to replicate .repo . We need the exact replication of the code which is present in the remote server.
.repo cannot be replicated. Replication works only with .git
So make a mirror of the complete repo and then enable replication.
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