That sounds like a reasonable plan. I'll work on the proposal. Thanks as always,
Kurt On Tue, May 3, 2016 at 7:04 AM, Andrew S. Baker <asbz...@gmail.com> wrote: > 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> > > > > On Mon, May 2, 2016 8:21 PM, Kurt Buff 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> >> 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] >> >> > On Behalf Of Micheal Espinola Jr >> >> > Sent: Monday, May 2, 2016 7:12 PM >> >> > To: 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> 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 >> >> > >> >> > >> >> >> >> >>
