+1 screenconnect ... we use it for almost exactly the same thing, supporting a mishmash of equipment across the hemisphere. On-demand remote control under a single pane of glass for my techs.
From: listsadmin@lists.myitforum.com [mailto:listsadmin@lists.myitforum.com] On Behalf Of J- P Sent: Tuesday, May 3, 2016 10:25 AM To: NT <ntsys...@lists.myitforum.com> Subject: RE: [NTSysADM] Looking for some ideas Ive had success with screenconnect https://www.screenconnect.com/ Jean-Paul Natola ________________________________ From: asbz...@gmail.com<mailto:asbz...@gmail.com> To: ntsys...@lists.myitforum.com<mailto:ntsys...@lists.myitforum.com> Subject: Re: [NTSysADM] Looking for some ideas Date: Tue, 3 May 2016 14:04:35 +0000 While it will likely be impossible to get down to a single standard access configuration that you support, I think you should aim for 4 or 5, based on the most popular methods you support today. Grandfather all of the existing folks in (to some point), or maybe just grandfather all the existing configurations in, but move towards something you could build redundancy for on the back-end. If you want support for providing a set of standard, supported configs (let's say 5 of them), then simply price out two options: A -- Building redundant VMs that can support 5 different remote access configurations (possible 10-15 VMs in total), and keep them live all at once. B -- Building single or redundant VMs to cover all the various configurations and keep them online for patching, etc. Show management plan B, indicating the need for security, etc. When they push back, suggest plan A, with some approach to moving to a steady state with each client. What you are looking to do will be manpower intensive and then require lots of custom automation to facilitate, making the whole process somewhat fragile. Having a smaller number of supported configurations will allow for greater redundancy on your end, and facilitate patching and integration testing when new versions of components and devices come online. Regards, ASB http://XeeMe.com/AndrewBaker<http://xeeme.com/AndrewBaker> Providing Expert Technology Consulting Services for the SMB market... GPG: 1AF3 EEC3 7C3C E88E B0EF 4319 8F28 A483 A182 EF3A Sent with Mixmax<https://mixmax.com/s/WMB47Rd39yDNPFfWo?utm_source=mixmax&utm_medium=email&utm_campaign=signature_link&utm_content=sent_with_mixmax> [https://app.mixmax.com/api/track/v2/WWKODxhUa4b1sDTWm/gIt92YuwWah12ZAVmbvpnYzFmI/i02bj5Sb1J3bmRXa51mLzR3cpxGQtRWYzl3c05mI] On Mon, May 2, 2016 8:21 PM, Kurt Buff kurt.b...@gmail.com<mailto:kurt.b...@gmail.com> wrote: The access (again, AFAIK) is pretty much all SSL VPN. But each rev of each vendor's device introduces incompatibility, as does the customer's requirements for AV on our support desktops. This isn't a problem that's going to go away. Kurt On Mon, May 2, 2016 at 4:25 PM, Michael B. Smith <mich...@smithcons.com<mailto:mich...@smithcons.com>> wrote: > I know that this won't be popular - but at some point you have to establish > SOME set of supported environments. > > > > I like clients - and when I was in my early days, I would extend myself to > do almost anything to retain a client - but now, it just isn't worth it. > > > > PPTP, L2TP (IPSec), SSL VPN, and DirectAccess - I support all these. If a > client says they want something else, I say "I'm sorry, but this is what I > support"... > > > > From: listsadmin@lists.myitforum.com<mailto:listsadmin@lists.myitforum.com> > [mailto:listsadmin@lists.myitforum.com] > On Behalf Of Micheal Espinola Jr > Sent: Monday, May 2, 2016 7:12 PM > To: ntsys...@lists.myitforum.com<mailto:ntsys...@lists.myitforum.com> > Subject: Re: [NTSysADM] Looking for some ideas > > > > I hope for and look forward to a healthy discussion about this! I've never > come across one that comes to a conclusion. > > > -- > Espi > > > > > > On Mon, May 2, 2016 at 3:01 PM, Kurt Buff > <kurt.b...@gmail.com<mailto:kurt.b...@gmail.com>> wrote: > > All, > > $Company has a set of support engineers whose job it is to connect > with customer sites which run our product. There are over 50 of these > customer sites, and of course we hope to get more. > > Our systems at the customer sites are not normally the customers' main > set of IT resources, but are usually critical to their operations, so > their IT staffs have their own opinions on how to grant access for us > to their environments. > > Therefore, each site has different requirements for remote access, > having a multitude of different VPN units (Sonicwall, Juniper, Cisco, > etc.) and requirements for different brands of Antivirus installation, > and whether or not split tunneling is allowed, etc. > > Currently our support engineers are using 3 desktop machines with > varied OSes, and using a set of VMs running in VMware player, but not > nearly enough of them, so that there are frequent conflicts in the > configurations of the VMs, what with different versions of VPN and AV > software. > > I expect normally no more than 4 or 5 VMs to be in use at a time - and > usually only 1 or 2. > > My thought currently is to have a set of VMs (one per customer) on a > small cluster in a DMZ - our support engineers would be able to access > the host, start the required VM, and be on their way. > > My solution starts to run into conceptual problems, however, when I > think about how to power down VMs that aren't in use, and also how to > wake up VMs periodically so that they keep patches and antivirus > updates. Are there products our there for a given platform that will > detect VMs not in use and shut them down, and that will also wake > those not running, to let them get patches and AV updates, then shut > them down? I'm platform agnostic - we run both VMware (production) and > Hyper-V (DMZ) here, and I don't care which one I implement. > > Of course, whatever solution is proposed should detect machines in > use, and not shut them down. > > Thoughts, input, suggestions? > > Thanks, > > Kurt > >
