Re: Client install id
2005-09-09 18:51:40
Ah, I see... but using serialization SHRSTATIC (which is infinitely more
desirable than *DYNAMIC) should also circumvent the problem. I wouldn't
recommend using *DYNAMIC.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-09-09
15:20:52:
> APAR IC41440. Another alternative recommended by tivoli support was to
> backlevel the client to version 5.2.4.0
>
>
>
> Andrew Raibeck
> <storman AT US DOT IBM.C
> OM> To
> Sent by: "ADSM: ADSM-L AT vm.marist DOT edu
> Dist Stor cc
> Manager"
> <[email protected] Subject
> .edu> Re: [ADSM-L] Client install id
>
>
> 09/09/2005 06:03
> PM
>
>
> Please respond to
> "ADSM: Dist Stor
> Manager"
> <[email protected]
> .edu>
>
>
>
>
>
>
> David, do you happen to know to which APAR you are referring, or do you
> have a PMR on this?
>
> The closest match I know of is IC46809, but that describes the opposite
> problem you mention: that when you DO use dynamic serialization, the
> system state or system object backups are no good. But DYNAMIC and
> SHRDYNAMIC should only be used on an exception basis, when you know that
> the application that uses the files can tolerate a restored file that
came
> from a fuzzy backup.
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Development
> Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> Internet e-mail: storman AT us.ibm DOT com
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-09-09
> 13:48:12:
>
> > Larry,
> >
> > There are problems with Domain Controllers running 5.3 client, that
are
> > supposed to be addressed by the 5.3.1 release, where system objects
> don't
> > get backed up unless the copy group they are using is set to Dynamic
> > serialization.
> >
> > As long as the ID you are using has local admin rights on the client
> > machines you should not run into any problems with the install. Local
> admin
> > is required in order to give you update rights to the registry. Any of
> the
> > ID's you've mentioned will work as long as they are in the local
> > administrators group on the client machines.
> >
> > I have seen problems with other software installs if the built-in,
local
> > Administrator ID is not used. But, I have not seen any issues when
> > installing TSM with any id within the local Administrators group.
> >
> > david
> >
> >
> >
> >
> > Larry Peifer
> > <[email protected]
> > CE.COM> To
> > Sent by: "ADSM: ADSM-L AT vm.marist DOT edu
> > Dist Stor cc
> > Manager"
> > <[email protected] Subject
> > .edu> [ADSM-L] Client install id
> >
> >
> > 09/09/2005 04:35
> > PM
> >
> >
> > Please respond to
> > "ADSM: Dist Stor
> > Manager"
> > <[email protected]
> > .edu>
> >
> >
> >
> >
> >
> >
> > We're installing 90 TSM 5.3 clients on a mix of W2K and W2K3 servers.
> > These are all new - 1st time installs. Several are domain controllers
> and
> > several are clustered for failover. Looks to me like we have
several
> > choices for ID's to use for installs: Local Administrator ID, Domain
> > Administrator ID, and members of the Administrator group. We run
> Journal,
> > Schedule, and Web services. All passwords for all IDs mentioned above
> get
> > changed every 90 days per Corporate IT Security mandate. What pros /
> cons
> > are there for using a particular ID to install with?
|
|
|