What Server Roles to know for small business

Tech bud

Active Member
Reaction score
27
Location
Oshkosh, WI
I want to start targeting small business more in my marketing. I'm always nervous to do so because I'm not that great on servers. In my home I have Server 2012, it has Active Directory on it, DNS, DHCP, I have a network drive set up for backups of my desktop and laptop.

I'm assuming a small office of like 10 people don't have it much more complicated than this? Maybe more network drives for storage?

I'm solid on repairing computers, I do internet tech support, been doing that for 5 years. So a lot of experience troubleshooting networks.


What would you say I would need to know in order to be more confident for small business stuff.
 
I want to start targeting small business more in my marketing. I'm always nervous to do so because I'm not that great on servers. In my home I have Server 2012, it has Active Directory on it, DNS, DHCP, I have a network drive set up for backups of my desktop and laptop.

I'm assuming a small office of like 10 people don't have it much more complicated than this? Maybe more network drives for storage?

I'm solid on repairing computers, I do internet tech support, been doing that for 5 years. So a lot of experience troubleshooting networks.


What would you say I would need to know in order to be more confident for small business stuff.
Those items are pretty much what we run into for our clients. Are you doing the shared drives via group policy? That's the preferred method so you can control access via groups. Also check out deploying printers via group policy.
 
Critical items mentioned above by yourself (AD/DNS/DHCP), and Slaters added other good ones to know...GPOs for stuff like mapping, I'll add folder redirection, and he mentioned the print deploy tool.

Just ensure DNS and DHCP is setup correct.
On the server, it must only look at itself as the primary DNS server. For example, if the server has an IP of 192.168.10.10, its primary DNS server should be 192.168.10.10 (or 127.0.0.1..loopback address...meaning "yourself"...which is essentially 192.168.10.10).

There are situations where you can use another member servers IP for secondary DNS, in certain WAN situations or when doing upgrades...but generally that's not needed either, as DNS will replicate through AD sites 'n services bindings.

And DHCP should ONLY hand out the servers IP for the primary DNS server for the clients. I see too many cases where the ISPs DNS servers are put here, or the routers LAN IP. No no no no no! This will lead to problems..both short term and long term. Active directory is built on top of DNS. DHCP should hand out the DCs IP for primary DNS, and for secondary DNS..if you have multiple DCs on your network that's fine. But never an external DNS server.

I also encourage you to learn hyper-visors. Hyper-V for one.
And also learn remote desktop services (formerly known as terminal server)..and the TSGateway role. This allows clients to securely access terminal server, via port 443. Or their workstations. No risk of exposing port 3389.

Learn the "Essentials Dashboard" role..not just on Essentials server but you can add it to standard server also. It's a great tool for binding local active directory to the clients Office 365 tenant. Also learn its bigger brother...Azure DirSync. (directory sync).

Learn OUs (organizational units)...comes in two parts, computers and users.
 
  • GPOs for stuff like mapping
  • folder redirection
  • print deploy tool
  • hyper-visors. Hyper-V for one
  • remote desktop services (formerly known as terminal server)..and the TSGateway role
  • "Essentials Dashboard" role
  • Azure DirSync. (directory sync)
  • (organizational units)...comes in two parts, computers and users.
It's a deep pool as you can see - but that doesn't mean you shouldn't get your feet wet. Find another tech in your area that has the expertise you lack so you can have a (paid) backup in case you run into something over your head. I know, easier said than done, but not impossible. Then, start taking "easy" server clients and use them to build your comfort level.

Not mentioned are the things to keep an eye on to make sure everything is working ok, maintenance procedures, updates, backups, best practices, etc. - lots of fun ahead!

Use your own office setup as a lab (or build a lab setup) so you can test things out. Also, when I first started, I had a rule that I never charged clients for what I would call "education" time. I was up front about it with them, told them I had to research because I hadn't run into "X" before, but wouldn't charge them for research time. This made me feel better about it, and most all of those clients are still with me today, so I think they felt good about that approach as well.

Then.......let time pass - you'll run into more and more things, post the questions that come up here, most folks are very willing to help you out without putting you down. Everyone has to start somewhere. 5 years from now, you'll be quoting and installing servers, and answering your own questions here. I use Evernote in my company, and I must have created hundred of how-to notes for common and not-so-common tasks. It helps to assure you only have to learn something once. :D Then, when I started hiring employees, those notes were useful to them as well.

Know what you know, and what you don't know - don't promise something you can't deliver confidently. That line changes every day sometimes, especially when you are learning.
 
Have some basic knowledge of SQL setup and best practices. Plenty of LOB apps are out there that require SQL but whose tech support provides NO support for the SQL server. From there point of view, It just needs to be working with a login they can use. Managing Transaction Logs, Backups, security, etc all fall on you.
 
To add to all the suggestions so far, something else worth mentioning is DFS and Namespaces. Even if you don't plan to install multiple servers, it's worthwhile configuring DFS, especially for growing businesses. It's a little extra work to add and configure the role but you'll thank yourself later if you have to replace the server or add additional servers.

Using DFS namespaces and replication for file-shares reduces the single server reliance by enabling multiple servers to store the same data. Enabling DFS and using namespaces (even when you only have a single member server) makes adding member servers later much simpler, whether you're adding a server to share the load/roles or migrating everything to a new server. Because the network share's UNC will be in the form of \\organisation\userdata, rather than \\server01\userdata, the data path remains the same regardless of which member server delivers it, meaning that you don't need to reconfigure the client machines.

It's worth noting however that some devices and software (such as Sage 50 Accounts, for example) won't work with namespace UNCs. In such cases you'll have to use the server-centric UNC but at least the data will still be replicated should you add another server.

For similar reasons I would highly recommend virtualising EVERYTHING you can too. When all servers are virtual, it's a simple matter to migrate them later to new/faster server hardware if/when the need arises (even while they're still running, resulting in zero downtime).
 
Last edited:
When all servers are virtual, it's a simple matter to migrate them later to new/faster server hardware if/when the need arises (even while they're still running, resulting in zero downtime).

Now that I *am* virtualizing all new servers, I've been thinking about this. I think, while a benefit, the actually incidence of needing to move a server to newer/faster hardware has got to be low for most small businesses (unless you didn't get the right hardware when you built the server). The more persuasive argument is disaster recovery. When you are backing up VMs, you can restore that VM to any host and be back up and running much faster than building/configuring/restoring data to a non-virtualized server. My 2 cents anyway.
 
Would be worth watching some of the training videos for MCSA Server 2016 on cbtnuggets or pluralsight. Sure you can get free 14-day trials of each.
 
Now that I *am* virtualizing all new servers, I've been thinking about this. I think, while a benefit, the actually incidence of needing to move a server to newer/faster hardware has got to be low for most small businesses (unless you didn't get the right hardware when you built the server). The more persuasive argument is disaster recovery. When you are backing up VMs, you can restore that VM to any host and be back up and running much faster than building/configuring/restoring data to a non-virtualized server. My 2 cents anyway.
I agree, DR is certainly the most persuasive argument but you'd be surprised how many small businesses choose to add more physical servers a year or so down the line, once they've absorbed the initial investment and they've come to realise the benefits additional physical servers bring.

I would say that a close second to DR is business continuity, and I'd put the performance argument in third place. Help them to understand that not only would an additional physical server increase performance but it would eliminate a major single point of failure. Using virtualisation and DFS it's possible to configure the servers such that, in most applications, a single server failure will have zero impact on business continuity (except for maybe a small performance hit). Ensuring that everything is duplicated/replicated (Data, Virtual Servers, Domain Controllers, RD Session Hosts, etc) means that there is no urgency in the event of a failure.

My larger business customers have several physical servers, all acting as Hypervisors for numerous replicated virtual servers. The users would be oblivious to any single server failure. In fact I frequently take servers down for planned maintenance and updates, even while the systems are in use. Most of my smaller business customers have, at some point (and before I took over), persevered with a terrible desktop-based 'server' setup and fully understand the impact a server outage can have on their businesses. After a year or so of owning a 'proper' server, and getting a taste for greater performance and reliability, I find it quite easy to persuade them to take it up a level and purchase a second server, especially when I explain that everything is already in-place (DFS, virtualisation, etc) and that there will be little or no disruption involved. With that in mind, I always configure any single server setup with DFS and full virtualisation.
 
I think the real benefit these days is client management. Many functions, file sharing, email, etc have been in the cloud for some time. Even LoB apps have been moving in that direction. With all of the potential security pitfalls, even with W10, being able to push, maintain and monitor the clients automatically is a huge profit machine in the M$ ecosystem.
 
Back
Top