>>
>>I want to thank everyone for their responsses so far - keep 'em 
>>coming though.
>>
>>First of all let me respond to Jeff's inquiry, "Is there something 
>>in particular that's got you irritated enough to migrate an entire 
>>enterprise to a different software?"
>>
>>A lot of things.  Here's a list of just a few (from the Sun side of things):
>>
>>1. With over 200 clients, updating them from one release to the next requires
>>     going to each client (via login of some kind) and doing an interactive
>>     pkgadd.  I'm told that NBU allows client updates to be "pushed 
>>out."  This
>>     would save a lot of time, and be version reliable.
>>
>
>True to some degree, my company disabled rsh everywhere so we can't 
>take advantage of this so if you are not running rsh you may end up 
>with the same issues. I am looking to using a package deployment to 
>the UNIX systems. Windows hosts can be upgraded via an install from 
>one host (during the install it asks if you want to install to the 
>local host or remote hosts) I have not used the option much so can 
>speak about it.

It's important to differentiate between a "new NBU client" install 
and "refreshing the binaries on an existing NBU client".  Your 
comments above relate to a new client install, whereas Deb's original 
words seemed to relate more to updating existing clients...

new client install = only officially possible via rsh/ftp/local-cdrom 
(and only possible using a cdrom for the windows folk :-/).  It's 
possible to use ssh, but it's got to be non-interactive ssh, i.e. 
host key authentication.

update = the update_clients command on your unix master server (or 
the patch install wizard on an NT client) uses the NBU bpcd protocol 
to push out the changes.  e.g. your Unix master can push out all the 
updated binaries to ALL the unix clients.  Pure noninteractive NBU 
activity, no reliance on rsh whatsoever.  Doesn't matter if it's a 
solaris master updating a MacOSX client, as long as both ends are 
"Unix" it will work.


>>2. Version control is an issue with LGTO - if you get a patch for something,
>>     there is not centrally located way to track which box has what patch, and
>>     it is usually not in pkg format.  LGTO just doesn't track 
>>version changes,
>>     such as date and time and version.

NBU is maybe a little better than what you describe.  There's no easy 
way to view the patch level that a particular remote client is 
running.  ("bpgetconfig -g <clientname>" comes tantalizingly 
close...)  But if you have access to said client, the 
netbackup/bin/version file contains that info.

I feel that this very mailing list should be cited as a significant 
"plus" in the NetBackup column.  Lots of helpful folks with a good 
knowledge of the product.

HTH
rob