Ok, thanks David and Matthew.
The reply from David would be indicate a 'no go' since I would need a spoke
to also be a hub for this to work I guess. (spoke from an HQ perspective
and a hub from a BO local perspective)

Or is an OC instance only a real hub when it receives data from spokes, In
that case it might not be a problem.

>I decided to give it whirl and added one of my satellite TSM servers to my
head office OC about ten minutes ago.  I'll let you know how it goes.

Great, I hope it doesn't mess stuff up for you but yes, please let us know
how that goes. :-)


On Wed, Sep 9, 2015 at 4:06 PM, Matthew McGeary <
Matthew.McGeary AT potashcorp DOT com> wrote:

> Hello Stefan,
>
> I've been wanting to do the exact same thing myself but haven't tried it
> because I thought that the documentation for the OC stated it was not
> possible.  Your email prompted me to look again and now I can't find
> anything to indicate it isn't possible.
>
> As I understand it, adding a server into the OC does the following:
> - defines the spoke server on the hub server just like doing a
> server-server communication setup for config or virtual volumes
> - defines an administrative account on the hub server to perform commands
> for the OC
>    - this account is unique to each hub server, which means you can
> potentially have more than one account running on a spoke
> - sets server alerts and triggers on the spoke based on the hub config
>
> The issue I can see is that if the OC settings and alerts for a spoke are
> stored on the spoke, rather than on the hub, conflicts will arise between
> the hub server in your central location and the OC running on the spoke.
> Both will attempt to set certain flags and override each other based on the
> whichever one did the last operation.  This could get confusing.  If,
> however, things like 'At Risk' settings and the like are stored within the
> hub server itself, there should be no conflicts.
>
> I decided to give it whirl and added one of my satellite TSM servers to my
> head office OC about ten minutes ago.
>
> I'll let you know how it goes.
> __________________________
>
> *Matthew McGeary*
> Technical Specialist - Infrastructure
> PotashCorp
> T: (306) 933-8921
> *www.potashcorp.com* <http://www.potashcorp.com>
>
>
>
>
>
> From:        Stefan Folkerts <stefan.folkerts AT GMAIL DOT COM>
> To:        ADSM-L AT VM.MARIST DOT EDU
> Date:        09/09/2015 06:42 AM
> Subject:        Re: [ADSM-L] A few questions about managing multiple
> Spectrum Protect servers with the Operations Center
> Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> ------------------------------
>
>
>
> Hi David, thanks for your reply.
>
> >I believe that the OC will want to create a named account (default name)
> on each TSM server it monitors (it's ok to say TSM, I'm not IBM).  This
> password would need to be the same across all the TSM servers.  I think
> that's going to be the problem for you but I could be wrong.
>
> But the admin picks the name. Couldn't I create one account for the HQ OC
> instance that connects to all the servers and one account per branch office
> that connects only to the local branch office instance?
>
> I don't know why that would not work.
>
>
>
>
>
>
> On Wed, Sep 9, 2015 at 2:10 PM, Nixon, Charles D. (David) <
> cdnixon AT carilionclinic DOT org> wrote:
>
> > I believe that the OC will want to create a named account (default name)
> > on each TSM server it monitors (it's ok to say TSM, I'm not IBM).  This
> > password would need to be the same across all the TSM servers.  I think
> > that's going to be the problem for you but I could be wrong.
> >
> > ---------------------------------------------------
> > David Nixon
> > System Programmer II, Enterprise Storage Team
> > Carilion Clinic | 451 Kimball Avenue | Roanoke, VA 24016
> > 540.224.3903 (Work)
> > 540.525.8000 (Mobile)
> >
> > ________________________________________
> > From: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] on behalf of 
> > Stefan
> > Folkerts [stefan.folkerts AT GMAIL DOT COM]
> > Sent: Wednesday, September 09, 2015 6:03 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: [ADSM-L] A few questions about managing multiple Spectrum
> Protect
> > servers with the Operations Center
> >
> > Hi all,
> >
> > I am looking into some things regarding the managing/monitoring of
> multiple
> > TSM (sorry, Spectrum Protect) servers using the Operations Center.
> >
> > I can build a test setup to look into it but that is not worth the effort
> > if somebody here can tell me it's not going to work. :-)
> >
> > Let's asume I have a HQ and 5 branch offices.
> >
> > I configure the branch offices to use Spectrum Protect replication to the
> > HQ location.
> >
> > I want the branch offices to be able to monitor and administer their
> local
> > Spectrum Protect server using a local OC setup on the BO server (version
> > 7.1.3) but not see the server in the HQ.
> >
> > Next I want the OC install on the Spectrum Protect server in the HQ to
> have
> > a connection with the server in HQ but also al 5 of the branch offices.
> >
> > I can use seperate Spectrum Protect admin accounts.
> > VPN access is all configured.
> > It's just about being able to connect a Spectrum Protect server to
> multiple
> > instances of the Operations Center basically and creating something that
> > looks like multi tiering this way.
> >
> > Any feedback is welcome, thanks in advance!
> >
> > Regards,
> >    Stefan
> >
> > ________________________________
> >
> > Notice: The information and attachment(s) contained in this communication
> > are intended for the addressee only, and may be confidential and/or
> legally
> > privileged. If you have received this communication in error, please
> > contact the sender immediately, and delete this communication from any
> > computer or network system. Any interception, review, printing, copying,
> > re-transmission, dissemination, or other use of, or taking of any action
> > upon this information by persons or entities other than the intended
> > recipient is strictly prohibited by law and may subject them to criminal
> or
> > civil liability. Carilion Clinic shall not be liable for the improper
> > and/or incomplete transmission of the information contained in this
> > communication or for any delay in its receipt.
> >
>
>