I need to migrate from Safeboot 220.127.116.11 to 18.104.22.168. Apart from the technical limitation that i need to first migrate from 4.2.12 to a higher version, of 4.2 and then 5.1.x, the following are the problems in my client management:
1. Deleted machines from my Safeboot console. 2. Duplicate entries of machines in my database.
As the operation team is undergoing with the cleaning up task and getting the things back on track, i am just curious to know whether the above activities are really dependent on migrating my platform (both Server and client).
What can be blocking from the above two rectification activities and must be completed / stopped before i get to migrate the server as well as the client.
none of the conditions you mention should really matter as long as you test properly first.
deleted machine entries (with still-live physical installs) won't connect regardless of what you do, so their operation does not depend on anything.
duplicated machines, there won't be a physical counterpart to the duplicates, again not a problem
4.2.12>4.2.17 should not be needed, though we don't test upgrade from earlier versions. In theory, 4.2.7 onwards should behave the same.
do you really need to upgrade the clients though? why not just upgrade the back end and deploy new clients at 5.x, leaving the existing machines alone to phase out naturally over time as they get refreshed?
"do you really need to upgrade the clients though? why not just upgrade the back end and deploy new clients at 5.x, leaving the existing machines alone to phase out naturally over time as they get refreshed? "
What a management nightmare? SafeBoot, this comment disturbs me. First off, anytime we contact the "helpdesk" the first thing McAfee says on ANY product is "are you using the latest version?". Secondly, supporting two versions of the same product is just a nightmare waiting to happen. I know that inherently the product works the same regardless of version, but a lot of the verbiage our helpdesk uses is "look in the lower right hand corner" type of directions.
Sorry for the flame, SafeBoot, everything else in your comment is accurate. Matrix, I would recommend upgrading everything to the same version.
hey, it's a comment for thought, and, based on experience, I can't think of a single customer who's gone through an aggressive wide scale migration. We're not talking about a revision upgrade here, v4 and v5 are completely different products.
I can't understand why someone would want to upgrade 10,000+ machines to a new product if they were working fine. If they only had a few hundred though, perhaps so.
Of course we want you to be using the latest version of any product, but, there's a big difference between "latest version of v4" and "migrate to v5".
We upgraded 5000+ machines from 4.x to 5.x to stay current, correct some issues, and to have a single client version. It took about four months, but mostly because of political barriers (not technical).
At least for build 4770, there is a significant client-side security issue. If you use SBNP.DLL, any user can reset the password of another user assigned to that machine. Once the client syncs, the first user could logoff and then back in as the second user. If SSO is current and enabled for that account, a user could use that to elevate their local/domain privileges or impersonate the other account.
I believe that it is more painful to support multiple concurrent versions than to do the one-time upgrade to 5.x. The user documentation/instructions differs too much, the behavior and feature differences are too great, and your admins would need access to both console versions (5.x console can't force a 4.x client to sync). If you have users that use multiple machines, they could have one at 4.x and another at 5.x. If the user had 5.x specific settings in their user object (i.e. local recovery), this could create problems. This could also cause problems for service/maintenance accounts that span 4.x/5.x machines, as it could corrupt the account. There are also some things that are not fixed in 4.x, like the issue we had with $autoboot$ corrupting machine audits.