[THIN] Re: pc anywhere
- From: Rick Mack <ulrich.mack@xxxxxxxxx>
- To: thin@xxxxxxxxxxxxx
- Date: Sat, 28 Aug 2010 20:13:03 +1000
Hi Berny,
I've been kind of busy, involved in R&D, support and pre-sales stuff. All
good fun though. because I feel like I matter.
If we ignore all the hype and often times inaccurate claims about the
benefits of VDI, it does have some pretty justifiable usage cases.
I guess the first and somewhat sad usage case was outlined by Ron Oglesby at
Briforum back in 2005. He had a customer that wanted remote access etc, but
after a series of TS implemetation disasters, TS was simply not going to be
considered by upper management and VDI was the only other viable solution.
There are any number of people out there that think TS is more than uncool
because "If I can't set up TS successfully then the technology is crap".
These are the people that see VDI as the white knight that will solve all
the problems they think are associated with TS. The joke here is that VDI is
largely single-user terminal services and many of the TS issues (printing,
protocol performance etc) remain. We're the people that know how to fix
those issues but we're the TS troglodytes.
Then there are the customers that have a helpdesk and IT staff that just
don't get multi-user. They are the ones that reboot a TS server with 50
people logged on because there's a problem with the spooler. If their skill
set is limited to managing single user desktops, it doesn't matter how good
a job the systems integrator does giving them a perfect TS solution, 6
months later it's going to be a mess. I'm sure you've come across customers
like that. So give them what they can manage. A badly managed TS
implementation is ultimately going to cost a lot more than a well-managed
VDI implementation.
VDI is expensive, the technology from VMware and Citrix is still pretty
immature and the scalability issues can be downright challenging. But one
operating system instance per user is something that most helpdesks can
manage. After all, that's what they've been doing, and for some that's all
they can do.
Then there's that application that just won't or shouldn't run on TS. It
needs administrator rights, has single instance components (eg hooks to MAC
address of host, special drivers etc), or is just so ugly that it shouldn't
even be on a computer. If you only need to run a few instances of that
application then VDI or even blade PCs offer a perfect answer to keeping
that application off TS, particularly if you can publish it as a seamless
app into a TS session. Of course if everyone needs to run that application,
you've got problem if TS is your only option.
My experience with application deployment into TS has been that you can
roughly expect maybe 80% of most apps to be easy to deploy. 15% will
need massaging with compatibility fixes, file/registry redirection or
virtualization and 5% will be stinkers that will take a huge effort and a
lot of time to deploy and you may simply not get them all going. The
"traditional" approach to this lgroup of applications has been to give the
user a fat PC, or if you're lucky you can have a separate silo that supports
isolated instances of these applications. Or maybe that application is one
the CEO uses and your TS deployment project has just failed.
VDI and blade PCs are the system integrators insurance that regardless of
the application set, you *will *deliver a successful virtual desktop
solution. It might not be totally TS, but provided everything is integrated,
it really doesn't matter. Embrace VDI where it makes sense, because it's
just another form of TS.
regards,
Rick
On Sat, Aug 28, 2010 at 7:33 PM, Berny Stapleton <berny@xxxxxxxxxxxxxxxxx>wrote:
> *gasp* welcome back Rick. :-)
>
> He's dead right too. I've never been sold on VDI, but this does sound like
> the perfect solution.
>
> On 28 Aug 2010 09:21, "Rick Mack" <ulrich.mack@xxxxxxxxx> wrote:
> > Hi Andrew,
> >
> > This is a perfect case for VDI; that application that you don't want on a
> TS
> > that is used by only a few users. Admittedly the degree of integration
> > between XenApp and XenDesktop at the moment makes things more than a bit
> > awkward, but once the technology catches up to the marketting [?] it
> ought to
> > be dead simple.
> >
> > My first foray into VDI was nearly 4 years ago when we'd done a full TS
> > implementation with thin clients on almost everyone's desk. Then they
> were
> > sold a Cisco VOIP solution and Cisco presence didn't run on TS. There
> were a
> > bunch of senior personal assistants in the company that gave the IT
> manager
> > hell because they couldn't even tell if their bosss was on the phone. We
> > didn't want to give them PCs instead of their thin clients so the answer
> was
> > to run up a bunch of XP virtual machines on one of their ESX host, and
> hard
> > codes the thin clients to connect to the Windows XP VMs. A bit of magic
> with
> > the shell to make XP look just like 2003 TS and nobody was the wiser. But
> > the PAs had what they wanted and we had a quiet life.
> >
> > You don't need to give your users fat PCs just because you can't run an
> > application on TS. Give them access to published applications hosted on
> > Windows XP/7 instead.
> >
> > regards,
> >
> > Rick
> >
> >
> >
> > On Tue, Aug 24, 2010 at 12:53 AM, Andrew Wood
> > <andrew.wood@xxxxxxxxxxxxxxxx>wrote:
> >
> >> True – but sometimes the punter wants to use PCAnywhere to go to another
> >> site to allow support for instance (maybe they’re a software house and
> >> they’re doing some update maintenance) – because that’s **always** how
> >> they’ve done remote support . They don’t want PCAnywhere to be supported
> on
> >> a standalone desktop for a whole host of reasons (they don’t want to buy
> a
> >> PC, they’ve already got a TS services running on the box, they want
> their
> >> developers to work from home and be able to moderate from a single
> instance
> >> etc.etc.etc)
> >>
> >>
> >>
> >> Ideally you look to re-evaluate how remote support is provisioned and
> >> managed – but that all takes time – and in the meantime you’re left with
> >> sorting something else.
> >>
> >>
> >>
> >>
> >>
> >> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]
> *On
> >> Behalf Of *Joe Shonk
> >> *Sent:* 23 August 2010 15:40
> >> *To:* thin@xxxxxxxxxxxxx
> >> *Subject:* [THIN] Re: pc anywhere
> >>
> >>
> >>
> >> Why would you need PC anywhere? RDP works fine.
> >>
> >>
> >>
> >> Joe
> >>
> >>
> >>
> >> *From:* thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx]
> *On
> >> Behalf Of *Hamilton, Ronnie
> >> *Sent:* Tuesday, August 17, 2010 8:31 AM
> >> *To:* thin@xxxxxxxxxxxxx
> >> *Subject:* [THIN] pc anywhere
> >>
> >>
> >>
> >> Hi
> >>
> >>
> >>
> >> I have been trying to avoid this one on the new implementation of XenApp
> >> 4.5 on 2k3, but I am getting overruled.
> >>
> >>
> >>
> >> We do have been running PcAnywhere on our old farm but it is very grainy
> >> and I was hoping that the one person in the company that actually uses
> it
> >> would be just given a Vista PC but I'm being pushed to Install and test
> it
> >> in our new environment.
> >>
> >>
> >>
> >> Has anyone had any good experiences?
> >>
> >>
> >>
> >> Or pointers to documents to say that it shouldn't be done.
> >>
> >>
> >>
> >> thanks
> >>
> >>
> >>
> >> Ronnie
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Visit our website : www.ltai.ie
> >>
> >> __________________________________________
> >>
> >> Lufthansa Technik Airmotive Ireland Limited. Registered in Ireland. Reg.
> >> No. 45999. Registered Office: Naas Road, Rathcoole, Co.Dublin.
> >>
> >> Lufthansa Technik Airmotive Ireland Leasing Limited. Registered in
> Ireland.
> >> Reg. No. 140891. Registered Office: Naas Road, Rathcoole, Co.Dublin.
> >>
> >> __________________________________________
> >>
> >> The information in this email and in any attachments is confidential and
> >> may be privileged. If you are not the intended recipient, please destroy
> >> this message, delete any copies held on your systems and notify the
> sender
> >> by return email. You should not read, retain, copy, disseminate,
> distribute,
> >> disclose or use this email or its contents in any way. Any such action
> is
> >> strictly prohibited. Thank you.
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> > Ulrich Mack
> > Quest Software
> > Provision Networks Division
>
--
Ulrich Mack
Quest Software
Provision Networks Division
Other related posts:
