If I still ran my small business and I wanted to go cloud, I'd spin up
business clients on Azure AD DS with AD Connect, giving them each their own
space, but federating with my Azure space for management with SCCM,
Kaseya, or some such. VMware has a similar solution as well.
Costs for that are better managed over the short term, but you could do the
same thing for more profit by investing in your own hardware and spinning
off VDI's with Azure DS and AD Connect with O365, then renting thin or zero
clients.
Kris
On Fri, Jan 15, 2016 at 11:11 AM, JP <jp@jptechnical.com> wrote:
> Forgive me if I make/made assumptions or infer anything from what you have
> (helpfully) commented Damien.
>
> I am a predominantly windows shop. The difference in our experiences might
> be in how our servers are used. I maintain networks for small business
> clients, most around 10 workstations and one server, no SQL servers and
> only simple file sharing. I am very selective with my clientele and don't
> like to spread myself thin, I also don't like employees :)
>
> In those cases there's no redundancy for servers, it isn't practical and
> the downtime of a single server is acceptable. When you have 50 locations
> with a single server, of varying OS versions, all needing AV, patches and
> regular (monthly) reboots that is what I refer to as babysitting. That is
> why I offload file storage to NAS devices wherever possible, reducing the
> load on the windows server, not for the servers sake but for my piece of
> mind, because I know if a NAS box dies on me it is a simple matter of
> pulling the drive and copying the files. I realize you can do this with a
> windows server, but there are a lot more moving parts to contend with.
> Every office I maintain has at least 2 *nix devices, NAS and firewall. No
> location has more that 500 GB of real data either, we leverage the cloud
> heavily. And a new $500 NAS box every year or three means the storage
> backbone is never more than 3 years old. Meanwhile the domain controller
> silently chugs along doing the sole job it is required, authenticating
> users.
>
> If I could figure out how to authenticate local machines to a cloud based
> directory service, considering Alaska's sometimes flaky data, I would
> replace every single directory server.
>
> On Fri, Jan 15, 2016, 10:05 AM Damien Hull <dhull@section9.us> wrote:
>
>> All good points.
>>
>> I do feel the need to point out that I work in a Windows environment. We
>> have about 8 or so Windows servers. I don't understand why people think you
>> have to babysit a Windows server. I don't.
>>
>> We do have Linux systems for a few things. I do love Linux when it is the
>> right solution for the job.
>>
>> On Fri, Jan 15, 2016 at 9:12 AM, JP <jp@jptechnical.com> wrote:
>>
>>> Valid questions...
>>>
>>> First, the registry hack, 3 keys modified (bit flipped), one to reduce
>>> the voracity with which windows searches DNS for the domain controller, and
>>> the second relaxes the functional level it is looking for in the domain
>>> controller, the third I believe prevents you from doing something stupid if
>>> you enable roaming profiles.
>>>
>>> The reason is two-fold...
>>>
>>> 1st, the SME server, and linux implementation of NT domain (not full AD,
>>> think older but reliable tech, like SSH) has been unchanged for a really
>>> long time. It is rock solid... dead simple, and there just aren't many
>>> moving parts to go wrong. Since the OS also has the bare minimum running
>>> necessary (albeit there is a pop/smtp/imap service I don't need), it is
>>> lean and requires very little maintenance. It is VERY rare to have to
>>> reboot the SME server, from experience.
>>>
>>> 2nd, the all mighty dollar... All said and done, installing an SME takes
>>> about a 1/4 the time to install and configure, it costs nothing and has
>>> greatly reduced operating costs. Plus the upfront costs of licensing are
>>> eliminated. Windows servers need constant babysitting. Even with a good
>>> RMM, which I have, you still have to manually reboot the things, and we all
>>> know the longer between reboots the more painful the reboot will be. On
>>> the flip-side, SME is Linux and to a large degree, compared to Windows, it
>>> is a 'set it and forget it' affair. This means wayyyyy less maintenance
>>> time for the client to keep the most basic need of central stored
>>> usernames and passwords working. So total cost of ownership is a
>>> fraction of what a windows domain will cost to maintain.
>>>
>>> Bonus 3rd reason, backups are ridiculously simple. plug in a
>>> thumb-drive, choose to backup to removable media, watch as tar does it's
>>> work. Move removable drive to a new install, choose to restore backup,
>>> watch tar do it's job, you have now migrated your DC to new hardware.
>>> Backup time is the only factor, no architecture concerns, etc.
>>>
>>>
>>>
>>> On Fri, Jan 15, 2016 at 8:53 AM Damien Hull <dhull@section9.us> wrote:
>>>
>>>> JP,
>>>>
>>>> I hate to dump on your Linux server, but what's wrong with Windows?
>>>>
>>>> I know I'm going to get hate mail and a few death threats for this.
>>>> However, having been in the IT world for a few years I would take the needs
>>>> of the business into consideration. Trying to get Windows to work with
>>>> Linux servers can be a bit tricky. As you pointed out, you need to hack the
>>>> registry. I'm not a fan of registry hacks. If the business can't find
>>>> support when you're gone they're SOL.
>>>>
>>>> Server 2012 R2 or Server 2012 essentials would be my pick. In a Windows
>>>> environment like this one, it just works.
>>>>
>>>>
>>>> If the network had 10 or so workstations I might consider your Linux
>>>> option. This is just my 2 cents.
>>>>
>>>>
>>>> On Thu, Jan 14, 2016 at 3:07 PM, JP <jp@jptechnical.com> wrote:
>>>>
>>>>> Yes, Peter is right.
>>>>>
>>>>> It is based on CentOS with many pre-configured packages based on
>>>>> official releases. During install, and anytime later, you choose which
>>>>> features you want, similar to Roles in Windows Server, it grabs the
>>>>> necessary components and installs them. You can still get to the yum
>>>>> package manager and install direct releases with no modifications, the real
>>>>> tweaking is in the config files of course. It really is very reliable, I
>>>>> have never had an install fail on me, but I have had a much smaller set of
>>>>> installs to base reliability on.
>>>>>
>>>>> http://wiki.contribs.org/Main_Page
>>>>>
>>>>> The history of SME server is pretty interesting, it has changed hands
>>>>> A LOT but seems to have retained the contributors over the years. The
>>>>> addon-packages were called contribs, hence the domain name hosting the
>>>>> documentation.
>>>>>
>>>>>
>>>>> On Thu, Jan 14, 2016 at 2:39 PM Peter Barclay PCNI <admin@pcni.us>
>>>>> wrote:
>>>>>
>>>>>> It's an all in one small to medium enterprise Linux server akin to
>>>>>> the roll up Microsoft did with sbs...
>>>>>>
>>>>>> Sent from Outlook Mobile <https://aka.ms/blhgte>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 14, 2016 at 3:01 PM -0800, "Lee Brumbaugh" <
>>>>>> lbrumbaugh@gmail.com> wrote:
>>>>>>
>>>>>> I've never used SME before, but how off the beaten Linux path is it?
>>>>>> I mean is it just a gui on top of standard tools or heavily modified
>>>>>> craziness?
>>>>>>
>>>>>> *Lee Brumbaugh*
>>>>>>
>>>>>> On Thu, Jan 14, 2016 at 11:25 AM, Tim Johnson <tim@akwebsoft.com>
>>>>>> wrote:
>>>>>>
>>>>>>> :) Coding not networking is my forte and I am quasi retired -
>>>>>>> you're over my head here, but I'm sure Jamie can grok. Good luck.
>>>>>>>
>>>>>>> * JP <jp@jptechnical.com> [160114 11:22]:
>>>>>>> > Thanks TJ
>>>>>>> >
>>>>>>> > One thing to add... I am likely going to run this on top of
>>>>>>> Hyper-V 2012,
>>>>>>> > it is free, and the replication is awesome. I previously was
>>>>>>> XenServer all
>>>>>>> > the way (after many years of ESXi)... but I have had some support
>>>>>>> issues
>>>>>>> > from Citrix on the XenServer in the past... costly support issues,
>>>>>>> whereas
>>>>>>> > the hyper-v is becoming so ubiquitous that tracking down an issue
>>>>>>> is pretty
>>>>>>> > simple.
>>>>>>> >
>>>>>>> > On Thu, Jan 14, 2016 at 11:12 AM Tim Johnson <tim@akwebsoft.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > > Hello JP :
>>>>>>> > >
>>>>>>> > > You might want to run this by Jamie Hushower at Rent-a-Geek in
>>>>>>> > > Palmer (I believe that he does a lot of business in Anchorage).
>>>>>>> > > He used to be on SLUG (Susitna Valley Linux Users Group)
>>>>>>> before it
>>>>>>> > > died.
>>>>>>> > >
>>>>>>> > > His phone number is 907 745-5060 and the website is at
>>>>>>> > > http://www.geeksalaska.com/
>>>>>>> > >
>>>>>>> > > I've known him for at least 15 years. I believe he's been doing
>>>>>>> > > networking all of that time.
>>>>>>> > >
>>>>>>> > > - tj -
>>>>>>> > >
>>>>>>> > > * JP <jp@jptechnical.com> [160114 10:57]:
>>>>>>> > > > I have a client with a windows network of about 40
>>>>>>> workstations, the file
>>>>>>> > > > shares are (will be shortly) on a simple NAS, and the rest of
>>>>>>> their work
>>>>>>> > > is
>>>>>>> > > > on the cloud. At present, the only feature of Active Directory
>>>>>>> they need
>>>>>>> > > is
>>>>>>> > > > the ability to login to different computers, they jump around
>>>>>>> a lot, but
>>>>>>> > > > they DO NOT need roaming profiles, just mapped drives.
>>>>>>> > > >
>>>>>>> > > > I have, on half a dozen occasions, setup an SME server to
>>>>>>> replace SBS
>>>>>>> > > 2000
>>>>>>> > > > and SBS 2003 servers. I know that there is Win 7,8,10 support
>>>>>>> in SME
>>>>>>> > > with a
>>>>>>> > > > registry patch, and I am testing it in a lab with Win 10 as I
>>>>>>> have
>>>>>>> > > already
>>>>>>> > > > had good success with Win 8 and 7 in past labs. So,
>>>>>>> technically I know it
>>>>>>> > > > is possible and reliable.
>>>>>>> > > >
>>>>>>> > > > Here is my quandary... the only negative I can come up with
>>>>>>> from the last
>>>>>>> > > > 15yrs of IT work and running both Windows and Linux emulated
>>>>>>> domains is
>>>>>>> > > > that I have in the past built something only I can maintain.
>>>>>>> This is a
>>>>>>> > > risk
>>>>>>> > > > for the client, and it causes unnecessarily stress for me.
>>>>>>> So... are
>>>>>>> > > there
>>>>>>> > > > any techs in Anchorage that have used SME server, so that if I
>>>>>>> am hit by
>>>>>>> > > a
>>>>>>> > > > bus they could pick it up and run with it? Or does this risk
>>>>>>> outweigh the
>>>>>>> > > > savings on M$ licensing (about $4500), as I estimate the labor
>>>>>>> to rebuild
>>>>>>> > > > the domain to be a wash either way.
>>>>>>> > > > --
>>>>>>> > > >
>>>>>>> > > > *JP (Jesse Perry)*
>>>>>>> > > > voice/txt: 907-748-2200
>>>>>>> > > > email: jp@jptechnical.com
>>>>>>> > > > web: http://jptechnical.com
>>>>>>> > > > support: helpdesk@jptechnical.com
>>>>>>> > >
>>>>>>> > > --
>>>>>>> > > Tim
>>>>>>> > > http://www.akwebsoft.com, http://www.tj49.com
>>>>>>> > > ---------
>>>>>>> > > To unsubscribe, send email to <aklug-request@aklug.org>
>>>>>>> > > with 'unsubscribe' in the message body.
>>>>>>> > >
>>>>>>> > > --
>>>>>>> >
>>>>>>> > *JP (Jesse Perry)*
>>>>>>> > voice/txt: 907-748-2200
>>>>>>> > email: jp@jptechnical.com
>>>>>>> > web: http://jptechnical.com
>>>>>>> > support: helpdesk@jptechnical.com
>>>>>>>
>>>>>>> --
>>>>>>> Tim
>>>>>>> http://www.akwebsoft.com, http://www.tj49.com
>>>>>>> ---------
>>>>>>> To unsubscribe, send email to <aklug-request@aklug.org>
>>>>>>> with 'unsubscribe' in the message body.
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>
>>>>> *JP (Jesse Perry)*
>>>>> voice/txt: 907-748-2200
>>>>> email: jp@jptechnical.com
>>>>> web: http://jptechnical.com
>>>>> support: helpdesk@jptechnical.com
>>>>>
>>>>
>>>> --
>>>
>>> *JP (Jesse Perry)*
>>> voice/txt: 907-748-2200
>>> email: jp@jptechnical.com
>>> web: http://jptechnical.com
>>> support: helpdesk@jptechnical.com
>>>
>>
>> --
>
> *JP (Jesse Perry)*
> voice/txt: 907-748-2200
> email: jp@jptechnical.com
> web: http://jptechnical.com
> support: helpdesk@jptechnical.com
>
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Fri Jan 15 12:38:33 2016
This archive was generated by hypermail 2.1.8 : Fri Jan 15 2016 - 12:38:33 AKST