The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
Moving the entire environment to a new server
Posted: 13 Jun 07 9:22 AM
|
We are planning to move the entire SLX env. (App server and 2 Syncs) to new servers.
I am thinking the best way to reroute the network users to the new servers is through SMS (to modifiy the connection settings in registry).
What I am not that sure about is how to reroute the remotes. I know the path to sync locations is stored in their local DB, so maybe a simple SQL command should do.
But then what about the files they sync to an old location BEFORE the receive the update command? And knowing my users, they will not sync right away, some of them sync once a week 
And any other suggestions about relocation of SLX Environement from experienced people will be highly appreciated (if you live close to where I am, I'll buy the beer  ) |
|
|
|
Re: Moving the entire environment to a new server
Posted: 13 Jun 07 9:44 AM
|
What I am not that sure about is how to reroute the remotes. I know the path to sync locations is stored in their local DB, so maybe a simple SQL command should do.
But then what about the files they sync to an old location BEFORE the receive the update command? And knowing my users, they will not sync right away, some of them sync once a week |
|
When you change the logging path in the WorkGroup Admin the outgoing TEF files to remotes will be put in new location. Since the remotes are still looking at the old location they will not get the change.
So what you need to do is...
1. change the location
2. cycle the syncserver
3. place a copy of all the outfiles create in the new location by the step2 into the existing outfiles folder.
This way when the remotes go to the old location they will pick up the outfile with the information about the new location. After processing the change the remote will go to the new location. |
|
|
|
Re: Moving the entire environment to a new server
Posted: 13 Jun 07 10:02 AM
|
| What about the files that will be coming from the remotes to an old location right before the receive the files with updates path? SHould I move those manually to a new location? |
|
|
|
Re: Moving the entire environment to a new server
Posted: 13 Jun 07 10:16 AM
|
You will need to capture those files also. What I did is create a BAT file that I attached to the "run befor sync" action of the syncserver to copy the files from the old folders to the new folders.
You could also explore doing a network level redirect so the users requesting a connection to oldserver\share get connected to newserver\share. I don't know how to do this but I am told it is diable via DNS/Windows settings. |
|
|
| |
|
Re: Moving the entire environment to a new server
Posted: 13 Jun 07 12:40 PM
|
While I have used these techniques before, and the process worked for me, I would strongly advise you to test the process before you execute it to make sure that everything works the way you expect in your environment.
**I have been burnt by unexpected environmental differences.
**Make sure you setup a remote for yourself. |
|
|
|
Re: Moving the entire environment to a new server
Posted: 13 Jun 07 12:56 PM
|
Frank is correct on all of his responses. Test your processes thoroughly!!!
Basically,
*Shutdown the SLX Server and sync server(s) services.
*Shutdown the sync shares.
*Rename the old server so no one can connect to it.
*Add a DNS CNAME record to redirect clients from the old server to the new. Make sure the path remotes use for syncing is the same except for the old server name, so clients will be able to access it the same when the DNS CNAME record begins its magic for the remotes. The DNS CNAME record will NOT redirect your network users.
*Move your SalesLogix database if you need to.
*Send out a SMS script to your network users to change the ADOLogin connection string(s) pointing at the old server and redirect to the new. You ONLY need to change the "Data Source" value - nothing else.
*Bring your SLX Server and sync server(s) back up.
*If you need to remove the DNS CNAME record eventually you will need to update the server, attachment, library and etc entries in your SLX DB. Wait until all remotes have recieved the update before removing the DNS CNAME record.
Good luck! Don't forget about your scripts and processes that are external to SLX!
|
|
|
|
Re: Moving the entire environment to a new server
Posted: 18 Jun 07 10:50 AM
|
Another question:
I'm trying to come up with a backout plan in case something goes wrong (we all know Murphy's laws)
Let's say the remotes already received the update to be rerouted to a new SyncServer. What would be the backout plan to reroute them back (assuming that the new sync is not allowing to send out another update)? SMS to run an update command on their local DB to change the Sync folder Path?
And again, any other backup plan suggestions? It's happening today so I'm trying to get as much data as possible to try and cover all situations.
P.S. And what I said about me bying the beer - it's still valid. If any of you guys are in MD, let me know |
|
|
|
Re: Moving the entire environment to a new server
Posted: 18 Jun 07 11:13 AM
|
I would send out executeSQL statements through the WGAdmin to update the remotes. Use SMS/vbs for your Citrix and Network clients.
Also, I would attempt to migrate a test environment first with a test remote database to sync/test your processes.
Your backout plan to undo the procecsses/changes should be reverse of the changes that have already been performed.
|
|
|
|
Re: Moving the entire environment to a new server
Posted: 19 Jun 07 9:26 AM
|
Got a very odd situation.
The new DB is the EXACT replica of an existing one. However, after my test remote machine got rerouted to the new sync folder, only the CMD files are applied. All others I get a message "The file ####-#######.#### was ignored because it is older than your database."
Opened the file in TranViever - the date it 6/19/2007. The RemoteDB creation date is 5/30/2007.
Created a new RemoteDB for the test machine - works flawlessly. Now that would be a terrible way to go for me - cutting 160+ remoteDBs and having them to reattach the DB.
Unless there's is a way to automate it? I asked the SAGE tech for some documentation about Remote Tasks or Agents - apparently they do not have any documentation on that  |
|
|
|
Re: Moving the entire environment to a new server
Posted: 19 Jun 07 9:44 AM
|
The sync componnets are not looking at the date they are looking at KeyBase of the remote and/or the last applied TEF sequence.
Ignoring a file because it is older could mean the the remote thinks is has already applied the file. Can you provide some more details of the steps you took in your testing?
Questions:
- Are you sure this remote was working properly before the switch over?
- Did you copy any TEF files from the old server to the new server?
- Did you try creating a new contact for a new account on the host database and see if it showed up in the remote. |
|
|
| |
|
Re: Moving the entire environment to a new server
Posted: 19 Jun 07 10:12 AM
|
We are runnning 7.0.1
The remote was working properly. And it was using the same RemoteDB.
As was suggested above, I have created a batch file that copies all incoming files from the old syncpath to the new syncpath.
A new Accont and Contact were created and I can see them in the new DB if I connect as a Network user. However I cannot see them if I use the remoteDB (I can still see the new contact listed in the "Latest Contacts" group but when I select it I get an "Invalid Record")
What confuses me is if indeed the keybase was wrong - it would not apply SOME files, right? However it is the case. Some files are applied fine - some are ignored  |
|
|
|
Re: Moving the entire environment to a new server
Posted: 19 Jun 07 10:30 AM
|
| As was suggested above, I have created a batch file that copies all incoming files from the old syncpath to the new syncpath. |
|
What about the outfiles?
| A new Accont and Contact were created and I can see them in the new DB if I connect as a Network user. However I cannot see them if I use the remoteDB (I can still see the new contact listed in the "Latest Contacts" group but when I select it I get an "Invalid Record") |
|
This indicates that the WhatsNew information was sent.
| What confuses me is if indeed the keybase was wrong - it would not apply SOME files, right? However it is the case. Some files are applied fine - some are ignored |
|
CMD files are sequenced. Outgoing and Incoming TEFs are sequenced.
It sounds to me like the remote was waiting for a missing outfile. Are you sure you copied the needed outfiles for the remote?
|
|
|
|
Re: Moving the entire environment to a new server
Posted: 19 Jun 07 12:31 PM
|
Aren't all outgoing files are picked up from a new location together with a file that reroutes to new SyncPath?
Anyway, I just tried copying the files for the TestRemote again - some changes were applied, but still lot's of "ignored" messages Some say "older than your database" and some say "newer"
And still no Contact that was created in the test account. |
|
|
|
Re: Moving the entire environment to a new server
Posted: 19 Jun 07 12:57 PM
|
Just noticed. Some incoming files are A3 keybase and my current DB is A2 base.
Incoming files that are A2 base - "Older than your database" message
Incoming files that are A3 base - "Newer than your database" message
SLX has A2.5 base? 
Where can I find the current KeyBase for a specific user in DB? Is it in user profile? Is it a good idea to try and modify/reset the Keybase? |
|
|
|
Re: Moving the entire environment to a new server
Posted: 19 Jun 07 2:29 PM
|
When you recreated the test user remote database, it would have incremented from A2 to A3. Ha, no there is not A2.5 keybase. The keybase is found on the user profile on the SYNC tab. It is always a whole number.
Did you move your SLXData directory contents?
Sorry to hear you are having these problems in production. This is why Frank and I tried to stress to you to test your processes in a test environment, first. There is a lot of detail work involved in a successful move.
|
|
|
|
Re: Moving the entire environment to a new server
Posted: 19 Jun 07 2:47 PM
|
Yeah, I wanted to create and run the test envirnoment first, but all the managers wanted it done "yesterday". You probably know how it is...
The good news is that in the worst case scenario, where I'd have to cut new DBs for all remotes - I found a way to completely automate it.
I'm still thinking about the "resetting" the keybase... should I even consider this option? |
|
|
|
Re: Moving the entire environment to a new server
Posted: 19 Jun 07 2:55 PM
|
The good news is that in the worst case scenario, where I'd have to cut new DBs for all remotes - I found a way to completely automate it.
I'm still thinking about the "resetting" the keybase... should I even consider this option? |
|
I would not reset the KeyBase. |
|
|
| |
| |
|
Re: Moving the entire environment to a new server
Posted: 21 Jun 07 4:14 PM
|
Originally posted by Frank Chaffin
Sounds like you did something out of sequence on your test machine. Oh well. In any event the approach that I outlined should work (I have used it several times). |
|
Confirmed!
I used your approach and it worked flawlessly!
The only thing is: IMHO - David Henry's idea about changing the sync path for remotes thorugh WGAdmin is less messy. No need to transfer the outgoing files from new server to old one.
Thanks everybody for helping me out with the move. |
|
|
|
Re: Moving the entire environment to a new server
Posted: 21 Jun 07 4:35 PM
|
Dave's suggestion will also work if you have control over the PCs at the level needed to force them to run a script. Note: you will need to copy the Slx log files from the old folder to the new folder.
PS I also know this works because I tested it in house a few years ago. |
|
|
|