Veritas-bu

Re: [Veritas-bu] What's LiveUpdate like these days?

2015-02-11 17:53:53
Subject: Re: [Veritas-bu] What's LiveUpdate like these days?
From: Dean <dean.deano AT gmail DOT com>
To: "Martin, Jonathan" <JMARTI05 AT intersil DOT com>
Date: Thu, 12 Feb 2015 09:53:47 +1100
Thanks everyone. I'm meeting with the client today, so will see what they think.

Cheers
Dean

On Thu, Feb 12, 2015 at 6:20 AM, Martin, Jonathan <JMARTI05 AT intersil DOT com> wrote:
If your clients are Windows based, I would use psexec to remotely push an msiexec command. Msiexec includes switches to suppress the reboot if required. I don't have the software in front of me, but I now some versions included a "silentpatch.cmd" file you could use for this purpose.

-Jonathan

Jonathan Martin
Intersil
Desk: 321-724-7314

-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Neil Conner
Sent: Wednesday, February 11, 2015 1:18 PM
To: Dean
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] What's LiveUpdate like these days?

Hi Dean,

If the master is running a Unix/Linux variant, the simplest and most reliable method to update Unix/Linux clients is to run the update_clients script.  Run it once to build a list of updateable clients, then edit that list as needed (you'll want to remove the master and media servers for instance), then run it again and supply the revised list of clients with the -ClientList <filename>  flag.

For your number of clients, I would definitely try using LiveUpdate for the Windows clients.  I have a Linux master so I've never used it for Linux clients...

Things to be aware of:

1. Symantec Endpoint Protection (antivirus) software used to interfere when NetBackup client installations would try and update LiveUpdate configuration file.  The default action was to block it.  The workaround was to modify tamper protection settings on the SEP server (Change Settings -> Client Management -> Tamper Protection and change action to Logged). That may have been fixed in the 12.1.5 release of SEP but I haven't tested it.

2. In former versions of NetBackup, the LiveUpdate web server was embedded in the LiveUpdate configuration file and you had to update that value in the LU_Install.bat file in the NetBackup installation package before running the initial client installation.  Now you can supply the LiveUpdate web server in the LiveUpdate policy attribute.

3. If a LiveUpdate policy runs successfully but the NetBackup version is not updated, the LiveUpdate registration may be corrupt, or SEP Tamper Protection blocked it during client installation.  To fix the LiveUpdate registration, run the LU_Install.bat file (with the updated LiveUpdate web server entry) manually on affected clients.

4. I only had success using a web server.  If the LiveUpdate web server is running IIS, you have to add the mime extension .flg type application/octet-stream to the web server properties and restart IIS.

5. You still have to build the list of clients in the LiveUpdate policy.

6. Make sure clients have at least 1GB free space in the system partition.  The LiveUpdate method has a much bigger footprint than running a regular client installation.


The alternative to LiveUpdate for Windows clients is the remote install method.  I'd use a few Windows 2008 servers for the task and divide up the clients.  Login with domain admin credentials, then run the NetBackup client installation as administrator and choose the option to install to multiple clients.  Here too, you have to build a client list file.  But for a small set of clients, I found this method to be a lot faster than LiveUpdate, and you don't have to worry about the bigger footprint.  The only problem I ran into is that the remote installation was blocked on some of my clients.  I was able to reproduce the problem by trying to run the installation on the affected clients directly from a UNC path (I think the problem has to do with Internet Explorer Enhanced Security Configuration), but the number is few enough that I just copy the installation files locally and then delete them when I'm finished.

Hope this helps!
Neil





On Feb 11, 2015, at 2:18 AM, Dean <dean.deano AT gmail DOT com> wrote:

> Hello folks,
>
> I've never used LiveUpdate, partly because I've never had to do a mass update of many hosts, and partly because of some negative comments about it on this mailing list.
>
> But my current engagement is to update 800+ clients to NBU 7.6.1. All of the clients that are in scope for me are already at NBU 7.x, which I believe means they will already have the LiveUpdate agent component installed as part of the base client.
>
> The master and media servers will have been previously updated by someone else before I start the client upgrades.
>
> The clients are your standard mix of Windows, Linux and Solaris hosts.
>
> So is it really as simple as the documentation makes it out to be? Or is it still a pain to get working properly, as a few posts to this list mentioned a few years ago.
>
> Put another way, if you had 800+ clients to upgrade, would you use LiveUpdate, push it out from the master/media servers, or do local installs??
>
> Also, the NBU install guide says clients "may" need to be rebooted. How does LiveUpdate handle this? Is it going to automatically reboot clients if it deems it is necessary?
>
> Thanks for any input!
>
> Dean
> _______________________________________________
> Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu