cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Migrating with Carried Baggage

Salut,

I need to migrate from Safeboot 4.2.12.0 to 5.1.9.0. 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.

Thanks..

Matrix!
4 Replies
SafeBoot
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 2 of 5

RE: Migrating with Carried Baggage

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?

RE: Migrating with Carried Baggage

"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.
SafeBoot
Reliable Contributor
Reliable Contributor
Report Inappropriate Content
Message 4 of 5

RE: Migrating with Carried Baggage

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".
mrgui
Level 7
Report Inappropriate Content
Message 5 of 5

RE: Migrating with Carried Baggage

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.
You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community