You're welcome, Kurt. It will be interesting to hear how this ends up.
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 On Wed, May 4, 2016 at 11:38 AM, Kurt Buff <kurt.b...@gmail.com> wrote: > 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 >>> >>> > >>> >>> > >>> >>> >>> >>> >>> >
