Unable to upgrade clients via "NT Client Install"

[jkupski]

All,

I've been having this issue since 7.6 -> 8.0 and have never gotten anywhere with it. Having gotten my hands on 9.0 today, I once again tried it as part of my migration testing.

When I attempt to upgrade clients via the "NT Client Install" option from SSC, I am led to believe that the installation is successful. However, on checking (and rebooting) the client, I find that there was no change.

I know others have had this issue before, and others still have never seen this, but I was wondering if anyone has found a definitive explanation as to why this is happening and what causes it.

 

[LawnBoy]

We have this problem with 7.5, it is related to User rights. We don't run an NT domain, so if the user doesn't have admin rights the install fails, just like it would if installed locally.

 

[jkupski]

I tried this on a machine with a user logged in who had domain admin (and hence, local machine admin) privs.

Also, if attempted on a machine without any previous version of NAV/SAV installed, it works fine (and doesn't seem to require admin pribs) while only upgrading bombs.

 

[jrjuiliano]

Just as a check, can you navigate to the antivirus server from a client you wish to upgrade and run the setup file?

This will be %servername%/vphome/CLT-INSTL/Win32/setup.exe.

See if this will install on a local computer.

Remember also that if you're pushing an installation to another computer, you need to have the priveleges on the installing computer match that of the client. In other words -- LocalAdmin does not necessarily equal DomainAdmin.

J.R.

 

[nevermore7777]

One thing I have seen in the past, is if the partition that the install is being directed to does not have enough disk space, the appearance of a successful install will be shown. Once the install completes and you go into the SSC the machine(s) is not there.

This shouldn't be as much of a problem with v9 since the client install is smaller. Just wanted to throw it out there as I have experienced it in the past.

nevermore7777
CCNA, Server+, Network+, A+

 

[jkupski]

Answers to questions:

Both logged in user and user attempting to do the push install are domain admins, and domain admins is a member of the local admins group.

Test machine has several GB free, so disk space is not an issue.

When running setup from the vphome share, the client machine (previously 8.0) upgraded perfectly. One odd thing (maybe this is new for 9.0?) is that the client ran live update to update its virus defs after installation, instead of simply getting them from the parent server.

 

[jrjuiliano]

That liveupdate thing after upgrading is part of the new version. I think that if you have Live Update Administrator up and running it would connect to that instead of going straight to Symantec's Live Update Server.

Well, we got that one fixed, so it DOES install. Sounds kind of like when you run the NT client installation it doesn't try to push the program through VPHOME, but somewhere else. I only have this problem when I'm trying to run the NT install from a computer I use to monitor (with Symantec Console), but isn't an AV server. It doesn't have the files needed to push the installation and will show it was done really fast.

J.R.

 

[jkupski]

jrjuiliano,

It's worth noting that this is, in fact, my monitoring workstation and is not an AV Server. I guess this may be the problem, or at least part of it.

The one thing that bothers me about this scenario is that this only bombs on upgrades--new installs go perfectly.

Still this is worth trying, thanks for the idea.

 

[jrjuiliano]

do you set the path for the primary server when you do your push installations?

It should come up with "default path" and then a place to put in some other location?

If you haven't done that, try it! should be the same path as I gave to you earlier, just add the "\\%servername%\ part of it at the beginning!

Everything works for me so far, EXCEPT Live Update Administration Utility. I put in a request to Symantec, and they have yet to answer me.

J.R.