An obvious question in itself. But, moving ePO 4.0 on win2K to ePO 4.5 on win2K3 and replicating host (all virtual), so removing most issues.
So, 100% correct route is:
But, what would happen if someone did the following:
Granted, not the recommended route - yet all appears 'okay'?
Unfortunately this will fail at step 3 - you can't restore an ePO 4 config to a 4.5 server. (It must be done to exactly the same environment that it was taken from.)
But, what if when I said "Bring up win2k3, install ePO 4.5 restoring previous config." that this merely translated to:
You see the things is, that what did occur was as follows:
All fine, but no agents registering in new ePO 4.5 install.
So, I brought up the old server and exported the key's, then imported them into the new server. Hey-presto, all the agents now calling home fine. Now, we are missing the DR's et cetera, but these can be added back in again.
Am I missing something else obvious? Or might this just work (though messily)?
You may well have problems down the line as a consequence step 3.
Restoring policies from ePO 4.0 to an ePO 4.5 server is going across some major schema version changes that could generate unpredictable results to the applied policies.
As Joe suggests, you should bring the new server on at the same version and patch level as the old server, migrate the data and then make the upgrade of the new server to ePO 4.5 so the installer can migrate all the settings automatically.
It's really not a good idea to try and cut corners on this i'm afraid.
Joe, Rob - my thanks.
I'm in agreement, if I were looking at a long-term implementation. I'll elaborate.....
The scenario outlined is only to be a 'temporary' solution to bring the ePO install up to ePO 4.5 on win2k3 (from ePO4.0 on win2k), in order to allow the organisational site be redirected to a parent ePO 4.5 master server (new organisational architecture). Then, relegating the local organisational site's ePO server to merely being an agent handler (AH server currently sitting in readiness).
As the new target architecture was/will be making the existing policies (repositories, exclusions - everything really) etc cetera redundant, it was felt that inconsistincies in the schema's causing potential policy issues were unimportant - as they would be blown away anyway?. The new build of ePO 4.5 on win2k3 was/is only to act as an intermediary step, to migrating all nodes to a new parent/master server on a higher tier in a new organisational model.
Again, and as usual from you folks, thanks for the clarity. Much appreciated.
My worry here is that you could wind up unable to perform certain functions in a hurry. Purely as a hypothetical example, imagine a scenario where you have an infection and are sent an extra dat, and you configure an emergency update task to update dats, engines and extra dats - but because of a mismatch between the two environments the "apply extra dat" switch never makes it to the client machines. Obviously this is a hypothetical worst-case scenario, but you get my point, I'm sure.
The risk, I believe, is really quite small - but crucially it's non-zero. If it's only temporary, and you're prepared to live with the risk, then I think you'll be OK. You'd have to be pretty unlucky.
I still don't like it though
I know, I know.......
And obviously you're 100% right. But, time and resource constraints dictate the risk.
Besides, I can alway's do a panic rebuild from scratch if needs be:-)
Thanks again folks.