You would think.  However, many times the users "buy" some product, and
IT is only involved after the fact and left trying to reverse engineer a
solution.  I've been in this boat, complained about and the whole nine
yards, but it does little good.  So far I've only had 1 vendor that had
an "appliance" that would not allow me to install TSM, however, they
piped their db backups to a share I created on another server and I back
that up.  I did, however, as stated earlier, insist that they give me a
server to use for this purpose.  

See Ya'
Howard


> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Richard Sims
> Sent: Saturday, December 06, 2008 6:49 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Backup of share will not work with schedule
> 
> On Dec 5, 2008, at 5:21 PM, Schneider, John wrote:
> 
> >  Tim,
> >     In the world of healthcare, it is not unusual for the
> > application vendor to provide the server and application and
> > support the
> > whole shootin' match themselves.  Sometimes the customer can talk
the
> > vendor into allowing modifications to "their" server, as in a TSM
> > client, but sometimes they won't do it.  Sometimes they won't even
> let
> > you log in to "their" server. So the vendor will configure shares or
> > some such method to allow you access from outside, and you have to
> > roll
> > your own solution.
> >
> 
> Following that vendor logic, it would seem that the contract
> involving their participation in the site should stipulate
> comprehensive details of data privacy, data integrity (i.e., backup
> and restoral), and all other legal aspects of such data.  Something's
> missing in the whole arrangement if the contractee has to try to
> invent some way of backing up and restoring data which circumvents
> restrictions.  If the vendor supports the whole thing themselves,
> then they should be taking care of all this.
> 
>     observing from afar,  Richard Sims