I have 800+ managed systems. Some months ago I setup a new 5.0 ePo, which I upgraded to 5.1 when it was available.
In past two months I've tried to transfer systems from 4.6.5 ePo to 5.1.0, but about 18 systems out of 800+ won't transfer to new ePo for some reason.
When I try to transfer them again, I get an error saying that marked systems have already marked for transfer, but it has been so for a very long time.
I tried once to delete all the systems and looked which ones would came back, in case some machines have been removed from work. Those 18
came back, so they can communicate with ePo. Over half of them haven't check to ePo, but some are actively communicating with ePo, yet still they
refuse to be transferred.
18 out of 800? I envy you mightily.
Do you have VSE on the problem systems? Do they have Access Protection enabled? What verion of agent do they have?
As I said in my first post, I deleted all systems that wouldn't transfer to see which systems are still existing.
It was 18 before, systems are slowly coming back.. 26 now.
I have VSE on all of my systems. Turned Access Protection off in old server now. I'll see if that helps anything. Agents are ranging from 220.127.116.119 (very old, have to upgrade that before transfer) to 18.104.22.1687 (newest, no reason to not to work)
My experience with this stuff suggests that just because you've turned off Access Protection on the server policy doesn't necessarily mean it's actually turned off on the client.
Check the properties for VSE in the ePO on those individual hosts and see if AP Enabled's value is 1 or not on the properties of the individual hosts. or if you have access to the client hosts, open the VSE console and see if AP is still enabled. There's a registry key you can check too and I think it's APEnabled. In my experience, you can have the policy set one way, and current communication times from the agent, but it doesn't mean the agent on the host necessarily make that happen for some reason. My experience with 4.5 agents is that it's pretty good about it with a 4.6.6 ePO at least, but 4.0 agents.... not so much. They seem to ignore the policy setting with respect to AP...so for those I've had to upgrade 4.0 to 4.5 on the agent, check and enforce policy, and only then can push a 4.8 agent from the new ePO with any degree of success. For what it's worth, on the hosts in question, I'm transferring them to the new ePO by running the new epo's 4.8 agent installer package on them and not able to push or automatically transfer them to the new ePO, which is completely separate from the old epo w/o any keys shared.
If you open a case with mcafee they can provide you a "disable AP" tool .exe that we are playing with for some of these stubborn hosts.
It's a big giant flying pain in my butt to be honest. If I had just 26 systems left I'd be dancing a jig! Good luck!Message was edited by: Regis (clarified method of transfer) on 1/29/14 9:46:42 AM CST
Not really, since at this point in time we don't have a central management solution for handling desktops across the country. Therefore I can't access problematic installations.
Update is that total amount has grown by 2 to 28 systems.
I was, out of curiosity, checking if the systems, marked to transfer from old server, had perhaps already gone to new server. Turned out, some were. They were listed in old server and new server, which shouldn't happen.
I deleted transferred systems from old server and got 16 systems now which I have to manually transfer.Message was edited by: ramil on 2/7/14 2:27:27 PM EET