We have 2 server with version 5.2.6 on the both of them. One of them is test the other one producive.
I have some PCs which are installed on test Server. Cam I migrate these PCs to to the other server without first decryption of client on the original test server.
Or I don´t have other way. First decryption, then export of configuration, then import of configuration onthe destinantion server and new encryption?
not really unless the two servers are fragments of each other - you need to completely remove the product and start again. Don't export/import anything, just start fresh.
It is theoretically possible to move machines, but you need to recreate and refresh the whole configuration, it's more likely you'll get a BSOD than success unless you have prof services in to help you.
I have also test the same thing in Virtual environment with 5.2.5 version, when I was testing the database splitting......& it seems to be fine...
The DB id is diffrent in both the server, have edit SDMCFG file with both the DB ID & export the machine from first DB & import the same machine in 2nd DB.....so machine entry is on 2nd DB & also set the priority on 2nd DB....
it worked by luck rather than design - especially with file sync. Unless the object ID of each file matches between the DB's things can get very convoluted when the machine tries to sync, and suddenly a critical driver has the same ID as a language on-screen keyboard...
I can confirm SafeBoot's comments about this not working. I tried moving a machine from one 5.2.5 server to another (different DB IDs) via export + import and INI file edit. The result was the client destroyed itself on first sync on the new server by deleting several of its files!
to get it working either you should have same file group and while exporting configuration check "all file group in configuration"
also check when you import machine on new DB "which file groups are selected in files TAB" if there is no same file group in DB2 than there should be none of file groups selected... this cause the system down. if you have same file group in DB2 as it was in DB1 then it should not be problem...
either export with "all files in group configuarion
check the file group in machines properties before synch
That's very interesting indeed (moving object to a DB with different ID). Shouldn't that fail to work by design?