We are going to upgrade our servers to be able to use SW2024 so archive, sql and license servers will be installed from scratch with latest supported OS etc.
We are thinking to put the new servers online and copy the archive just to be able to sync only a small portion of data before we put the old servers offline. new machine name, new ip etc.
I was wondering if it would be possible to replicate archive and sql to make them run in parallel with the current servers and then shut them down leaving the new machine only or it would be a unnecessary complication...I think we need to remake all the vault views on our PDM clients (100+ machines) in any case so it is probably not worth, but I would like to ask the forum opinion anyway.
server renewal
Re: server renewal
I may be misunderstanding by you mentioning replication, but if you mean what I think then that seems like an unnecessary complication. The only thing that would be doing for you is to replicate some files from the main archive as you've defined in your replication settings. Then when you want to use it as your main server, you're still going to have to go and reconfigure the SQL table and point all the existing clients to the new server/database.
No need to remake any vault views. You can simply edit the registry and tell it what the new archive and database server host names are.
Edit:
My recommendation would be to recreate your vault in parallel with your production vault (without any replication in place). This may be what you're actually intending to do. Then verify that the new server allows all of your add-ins, workflows, etc. to function with existing files.
Once everything is working the way you want, restore the SQL from the latest backup of the production server and copy the remaining archive files to the new server. A quick solution would be to rename the new server(s) the same as the existing one(s) so you won't have to mess with client vault views at all. Otherwise, a registry edit to point to the new host names would be the last step.
No need to remake any vault views. You can simply edit the registry and tell it what the new archive and database server host names are.
Edit:
My recommendation would be to recreate your vault in parallel with your production vault (without any replication in place). This may be what you're actually intending to do. Then verify that the new server allows all of your add-ins, workflows, etc. to function with existing files.
Once everything is working the way you want, restore the SQL from the latest backup of the production server and copy the remaining archive files to the new server. A quick solution would be to rename the new server(s) the same as the existing one(s) so you won't have to mess with client vault views at all. Otherwise, a registry edit to point to the new host names would be the last step.
Re: server renewal
The replication thing was more a curiosity of mine, I was wondering how big organization could handle In a smooth manner the transitions from a server to another minimizing the down time. Having multiple server in parallel and retiring one of them seemed the smoothest option, but I agree that is only a complication for us.
The initial plan was to remake both sql and archive servers from scratch as you suggested.
It is not so different from making a test server from our backups and I do it periodically. I have a batch file to create vault views and I could modify it to check the registry, but iirc the desktop.ini hidden inside the vault root must be changed as well (I cannot check it as I am not in the office right now) .
I prefer to avoid making all the users to manually recreate or modify the vault view and if I can do it automatically with a batch file or similar.
we need to setup the new servers in parallel with the current production and register them on our domain. Since IT is in control of that I do not know if I am allowed to rename the machines.
The previous server replacement the person in charge changed the server name and rebuilt all the client vault views.
The initial plan was to remake both sql and archive servers from scratch as you suggested.
It is not so different from making a test server from our backups and I do it periodically. I have a batch file to create vault views and I could modify it to check the registry, but iirc the desktop.ini hidden inside the vault root must be changed as well (I cannot check it as I am not in the office right now) .
I prefer to avoid making all the users to manually recreate or modify the vault view and if I can do it automatically with a batch file or similar.
we need to setup the new servers in parallel with the current production and register them on our domain. Since IT is in control of that I do not know if I am allowed to rename the machines.
The previous server replacement the person in charge changed the server name and rebuilt all the client vault views.
AlexB wrote: ↑Tue Aug 20, 2024 1:22 pm I may be misunderstanding by you mentioning replication, but if you mean what I think then that seems like an unnecessary complication. The only thing that would be doing for you is to replicate some files from the main archive as you've defined in your replication settings. Then when you want to use it as your main server, you're still going to have to go and reconfigure the SQL table and point all the existing clients to the new server/database.
No need to remake any vault views. You can simply edit the registry and tell it what the new archive and database server host names are.
Edit:
My recommendation would be to recreate your vault in parallel with your production vault (without any replication in place). This may be what you're actually intending to do. Then verify that the new server allows all of your add-ins, workflows, etc. to function with existing files.
Once everything is working the way you want, restore the SQL from the latest backup of the production server and copy the remaining archive files to the new server. A quick solution would be to rename the new server(s) the same as the existing one(s) so you won't have to mess with client vault views at all. Otherwise, a registry edit to point to the new host names would be the last step.
Re: server renewal
The replication thing was more a curiosity of mine, I was wondering how big organization could handle In a smooth manner the transitions from a server to another minimizing the down time. Having multiple server in parallel and retiring one of them seemed the smoothest option, but I agree that is only a complication for us.
The initial plan was to remake both sql and archive servers from scratch as you suggested.
It is not so different from making a test server from our backups and I do it periodically. I have a batch file to create vault views and I could modify it to check the registry, but iirc the desktop.ini hidden inside the vault root must be changed as well (I cannot check it as I am not in the office right now) .
I prefer to avoid making all the users to manually recreate or modify the vault view and if I can do it automatically with a batch file or similar.
we need to setup the new servers in parallel with the current production and register them on our domain. Since IT is in control of that I do not know if I am allowed to rename the machines.
The previous server replacement the person in charge changed the server name and rebuilt all the client vault views.
The initial plan was to remake both sql and archive servers from scratch as you suggested.
It is not so different from making a test server from our backups and I do it periodically. I have a batch file to create vault views and I could modify it to check the registry, but iirc the desktop.ini hidden inside the vault root must be changed as well (I cannot check it as I am not in the office right now) .
I prefer to avoid making all the users to manually recreate or modify the vault view and if I can do it automatically with a batch file or similar.
we need to setup the new servers in parallel with the current production and register them on our domain. Since IT is in control of that I do not know if I am allowed to rename the machines.
The previous server replacement the person in charge changed the server name and rebuilt all the client vault views.
AlexB wrote: ↑Tue Aug 20, 2024 1:22 pm I may be misunderstanding by you mentioning replication, but if you mean what I think then that seems like an unnecessary complication. The only thing that would be doing for you is to replicate some files from the main archive as you've defined in your replication settings. Then when you want to use it as your main server, you're still going to have to go and reconfigure the SQL table and point all the existing clients to the new server/database.
No need to remake any vault views. You can simply edit the registry and tell it what the new archive and database server host names are.
Edit:
My recommendation would be to recreate your vault in parallel with your production vault (without any replication in place). This may be what you're actually intending to do. Then verify that the new server allows all of your add-ins, workflows, etc. to function with existing files.
Once everything is working the way you want, restore the SQL from the latest backup of the production server and copy the remaining archive files to the new server. A quick solution would be to rename the new server(s) the same as the existing one(s) so you won't have to mess with client vault views at all. Otherwise, a registry edit to point to the new host names would be the last step.
-
AlexLachance
- Posts: 2184
- Joined: Thu Mar 11, 2021 8:14 am
- Location: Quebec
- x 2364
- x 2013
Re: server renewal
I can't guarantee 100% that is the case but I am pretty sure that is how we transitioned from our old server to our new one. Something also ensured the synchronization.mp3-250 wrote: ↑Wed Aug 21, 2024 8:30 am The replication thing was more a curiosity of mine, I was wondering how big organization could handle In a smooth manner the transitions from a server to another minimizing the down time. Having multiple server in parallel and retiring one of them seemed the smoothest option, but I agree that is only a complication for us.
The initial plan was to remake both sql and archive servers from scratch as you suggested.
It is not so different from making a test server from our backups and I do it periodically. I have a batch file to create vault views and I could modify it to check the registry, but iirc the desktop.ini hidden inside the vault root must be changed as well (I cannot check it as I am not in the office right now) .
I prefer to avoid making all the users to manually recreate or modify the vault view and if I can do it automatically with a batch file or similar.
we need to setup the new servers in parallel with the current production and register them on our domain. Since IT is in control of that I do not know if I am allowed to rename the machines.
The previous server replacement the person in charge changed the server name and rebuilt all the client vault views.
Re: server renewal
The way that we brought our new servers online was to install everything fresh on them (SQL, PDM, etc.)
I installed a blank vault view and then restored the SQL database from a production copy to the new server onto the blank vault view's table structure. This required that I modify a few tables in the SQL database after the fact to get things to match the new vault on the new server.
Finally, I made a robocopy script to copy the full archive from the old archive server to the new archive server.
That allowed the new server to function as a copy of the old server with workflows, files, data, etc. Once everything was tested and ready to go online, the SQL database needs to be restored from the current state of the old database and then the robocopy script needed to be ran again. Verify connection and replication to any replicated archive servers and you should be good.
The very last step is updating the client vault views by modifying the archive and database server host names in the registry.
This was a very helpful resource: https://www.goengineer.com/blog/move-so ... components
I installed a blank vault view and then restored the SQL database from a production copy to the new server onto the blank vault view's table structure. This required that I modify a few tables in the SQL database after the fact to get things to match the new vault on the new server.
Finally, I made a robocopy script to copy the full archive from the old archive server to the new archive server.
That allowed the new server to function as a copy of the old server with workflows, files, data, etc. Once everything was tested and ready to go online, the SQL database needs to be restored from the current state of the old database and then the robocopy script needed to be ran again. Verify connection and replication to any replicated archive servers and you should be good.
The very last step is updating the client vault views by modifying the archive and database server host names in the registry.
This was a very helpful resource: https://www.goengineer.com/blog/move-so ... components
Re: server renewal
It seems we are using the same method.AlexB wrote: ↑Wed Aug 21, 2024 9:18 am The way that we brought our new servers online was to install everything fresh on them (SQL, PDM, etc.)
I installed a blank vault view and then restored the SQL database from a production copy to the new server onto the blank vault view's table structure. This required that I modify a few tables in the SQL database after the fact to get things to match the new vault on the new server.
Finally, I made a robocopy script to copy the full archive from the old archive server to the new archive server.
That allowed the new server to function as a copy of the old server with workflows, files, data, etc. Once everything was tested and ready to go online, the SQL database needs to be restored from the current state of the old database and then the robocopy script needed to be ran again. Verify connection and replication to any replicated archive servers and you should be good.
The very last step is updating the client vault views by modifying the archive and database server host names in the registry.
This was a very helpful resource: https://www.goengineer.com/blog/move-so ... components
I use to do it for our test server that periodically is deleted and rebuild from scratch using the production backups.
Re: server renewal
What you could theoretically do is:
0. Install PDM archive server on the new server (B) but do not replicate the vault to it
1. put the system into maintenance, disconnect all users, block logins etc.
2. copy the archive folder from old server (A) onto B
3. Make a copy of archive server settings on A and restore them on B, manual tweaks in registry may be required
4. Edit the server name in ArchiveServers table in the SQL database from A to B*
5. Perform your SQL migration as described, take a backup of database, bring it back up on the new server.
6. Modify client registry keys with new server names or recreate vault views*
*there is a DNS workaround for this where you can create a C record that points to server B, with the same name as server A. Thus any vault view attempting to connect to the server A is redirected to server B and no modifications are needed on the client side. Server A must be removed from the domain simultaenously.
All that being said, this is not what we do in our replicated environment (for archive servers):
1. Add the new server and replicate the vault to it
2. Remove the old server from the vault
0. Install PDM archive server on the new server (B) but do not replicate the vault to it
1. put the system into maintenance, disconnect all users, block logins etc.
2. copy the archive folder from old server (A) onto B
3. Make a copy of archive server settings on A and restore them on B, manual tweaks in registry may be required
4. Edit the server name in ArchiveServers table in the SQL database from A to B*
5. Perform your SQL migration as described, take a backup of database, bring it back up on the new server.
6. Modify client registry keys with new server names or recreate vault views*
*there is a DNS workaround for this where you can create a C record that points to server B, with the same name as server A. Thus any vault view attempting to connect to the server A is redirected to server B and no modifications are needed on the client side. Server A must be removed from the domain simultaenously.
All that being said, this is not what we do in our replicated environment (for archive servers):
1. Add the new server and replicate the vault to it
2. Remove the old server from the vault