This content has been marked as final. Show 8 replies
you can't move things between unique databases - if you could that would be a simple exploit indeed.
but, there's nothing to stop you duplicating the production DB in a test environment. Unlike SQL server etc, the SafeBoot database can be simply copied to another server.
So, if we just do a restore of our production DB onto the server server, we could then repoint the clients to the test server and they'd be none the wiser? Sounds easy enough! Any idea how the license would work in that situation? Does that come over with the database, or would we buy licenses for the test server as well?
sure they would be none the wiser, but then you could not move them back again - moving them to what is essentially a backup is a one way process. To move back to production, you'd need to copy the (current) master back to the production hardware first. If you didn't, all the property revision info would strangely go back in time, not something we support.
For test machines, sure it would be OK as it would be a one-time process.
re licensing, you need to get approval from your account manager for a test environment, but your current license would remain. You simply need to put in writing that this is a test environment, not one being used to protect data.
If you need to actually protect the extra test machines, then of course you need to acquire licenses for those copies of the software.
I see what you're saying and understand the one-time thing, and I definately wouldn't ever copy the test database back over to production! grin . I'll have to ping my account manager sometime next year and look into it. The test systems would be used for testing upgrades, new ePO stuff next year, little integration tweaks with other systems, etc.
The fact that the systems attached to this server (test systems) would be protected would be a byproduct of the fact that the client was installed, and we'd have actual licenses for them on the production server since they wouldn't "live" in test all the time (even if we had to decrypt them to move them) so I can't imagine it'd be a problem.
Thanks for the tips!
If Test is an older copy of Production, then you should be able to move machines without issue. Just make sure the object either already exists in Test, or you import it with a name matching the client hostname (to allow for object ID renegotiation). We do this for testing SB patches and updates to make sure they don't blow anything up.
Another thing to consider, is whether or not you want initial registration to occur in the Test DB. If it does, you would have duplicate object IDs in Test and Production with different keys. I dump a fresh copy from Prod to Test every couple months (or prior to a major upgrade) so that my Test DB is as close to production as possible (machines, groups, users, files, etc).
I also use my Test DB to restore machines that were accidentally deleted from the production database. If you need to issue machine codes for a reimported objects, you can manipulate the next available object ID prior to importing the machine (so the code matches).
Test would always be an older copy of Prod, but when we repointed a machine there for testing then there would be data on Test that would make that record newer than Prod. SafeBoot implied that this means you could not point the client back to Prod, is this your experience as well?
If we wanted the systems back in Prod without having to decrypt/encrypt again could we follow the procedure you've discussed where we create a new registration on the server with the same hostname as the client?
you can always change the object creation range on the test DB to be outside the scope of production, then you'll never get any overlaps and will simply be able to copy the database structure for the machines you want to move between the two.
Machines though are not a problem, you can export/import them between databases without problems AS LONG AS USERS AND FILE OBJECTS MATCH UP. Users however cannot be migrated.
Yes, we have moved them back into production after testing an update. The only thing we noticed was that it would re-push some of the new client files from Production. Just make sure you delete out any old registrations of that machine out, then re-import into production.