R is considered the predominant language for data scientist and statisticians. Learn how to use R for your own data science projects.
There are many roles and features a server can have. In larger businesses, the best practice is to separate each and every one on a separate server. Why? In those businesses, downtime is everything… a company with 5000 people who have to wait 5 or 10 minutes for a server to reboot may mean up to a month's worth of lost productivity if all those users cannot access, for example, their files. But for a business of 20, separating File Services, Print Services, Active Directory, DHCP services, DNS services and so on can prove very costly in terms of server hardware and licenses. For the smaller shops, a 5 to 10 minute outage is not a major problem provided it’s at most an occasional occurrence; combining services can be done to save hundreds or more likely a few thousand dollars that would be necessary for the multiple servers to run separate services.
While many services can be safely combined, some should never be. Security, business interruption, licensing, or technological reasons can all play a role in what should and should not be combined. Let’s look at some of the more common things a server can do and if it can be combined with other roles and features with relatively minimal concern.
NEVER combine with any other roles. The Hyper-V host server should be completely standalone from other roles. It’s job is to run multiple other servers. You want to restart this as infrequently as possible and adding other services to it would increase the odds that you have to restart it. Further, Microsoft’s licensing allows you to install the host without it counting towards your more functional licensed VMs. “2+1” licensing of Windows Server 2012 and 2016 means you can install 2 VMs that can run anything server is typically capable of running AND ONE physical install to the host that permits ONLY Hyper-V.
Another consideration is that Microsoft offers a free version of Hyper-V server. This version is, in essence, a Windows Server Core install with only the Hyper-V role available. For most smaller environments managing a Core based install of Hyper-V is tricky at best, at least in setup as it is managed with PowerShell and potentially through remote connections from a compatible Windows client computer with the Hyper-V Management tool installed. To get the graphical management tools on the host, such as Hyper-V Manager, you need the full install (which is not available on the free product). As an alternative, there are third party tools such as 5Nine Manager (free with limitations or paid) and VT Utilities (short trial or paid) that can be installed on the free version and used to manage your VMs graphically.
The free Hyper-V server, being a Core-only install means you have a smaller attack surface and fewer components taking resources. This is often cited as another major reason for use instead of using the Windows Server "+1" aspect of the license.
To remain in licensing compliance, should you ever need to move your VMs from one server to another (which non-OEM licenses permit1 once every 90 days except in case of catastrophic failure), using the free Hyper-V server makes the transfer of the license easier than if you used the regular Server "2+1" licensing since you don't have to worry about the host license.
While from a strict best practices standpoint, using Core makes sense, from a management standpoint for small businesses, it usually is more of a headache than a benefit. Even if you're an expert in Core management in general and Hyper-V Core management in particular, you need to keep in mind (unless you also happen to be the organization owner), that one day you may not be the one managing the system and it should be managable by the next person saddled with the responsibility. For this reason, in small shops that need to have servers sharing services, in almost all cases, I recommend using the "2+1" licensing with a full Windows Server install.
While you should generally strive to keep these from doing anything other than Active Directory (AD) and it’s directly related support role (DNS), most smaller shops are fine combining DCs with DHCP and File and Print Services. If you have multiple DCs and no on-site Exchange server, you might be able to support a service like Windows Deployment Services (WDS) with little concern. NEVER add Remote Desktop Services / Terminal Services to DCs - users operating on a DC are a huge security risk. Some versions of Windows don’t even allow you to combine RDS/TS and AD services on the same server. Additionally, you want to avoid putting Exchange on a DC. While it is a supported configuration, it is not recommended and it can cause issues. (For more information, see this Technet article: https://technet.microsoft.com/en-us/library/ms.exch.setupreadiness.warninginstallexchangerolesondomaincontroller(v=exchg.160).aspx). You should also be wary of adding database services to your DCs - some database products might not care (examples MAY be databases based on Oracle, Pervasive, or MySQL - I have limited experience with their requirements - CHECK FIRST!), but others actively warn against, such as Microsoft SQL. Security and system changes implemented by the Database Services could cause problems with your server - and of course, you should pay attention to how you configure the server as performance of both DC functions and the database itself could suffer without careful planning.
Though a little beyond the scope of this article, it’s common for IT Professionals to recommend multiple DCs for any environment that has Active Directory. A few years ago, I heard a great argument for NOT having multiple DCs and so my recommendation has changed somewhat. Consider most people’s skill level – quite likely yours, if you’re reading this article and the information is new to you – you almost certainly don’t understand in the way that you should Active Directory backup and restore. It’s likely easier for you to perform an image backup of your server. This is fine. But if you had multiple DCs, you can put yourself at risk of corrupting your active directory if you restore that image backup of a failed DC. Active Directory has specific requirements for how restores are performed to ensure corruption is not a problem. If you aren’t familiar with the process, stick with a single DC. If you are familiar, by all means, consider multiple DCs – it IS a good idea… so long as you understand Active Directory.
In most cases, these can go on anything. From a technological and licensing standpoint, there are no restrictions (other than not on Hyper-V). In addition, almost all servers will have file sharing at least minimally enabled. However, you have to think about what they do and how important they are to your company and how important the host server’s other services are to your company. File servers can put a high load on the network bandwidth so accessing other things – like e-mail if you combined Exchange or a Database could prove intermittently slow. Also, you should consider the disk subsystem – placing the shared folders on a disk set that also contains other disk intensive services can slow the other services as well as the file access. For smaller organizations, I usually don’t have any major issue with combining File services on an DC. It’s quite common and while not ideal, widely accepted in small environments. Indeed, if you have other needs for server licenses, it’s the first set of services I’d consider combining.
Typical office printers don’t put much of a load on the server. The spool directory should be on a drive with enough free space (most people don’t change the default of C:\windows\system32\spool) and in general, printers are well behaved. In instances where they prove not to be, it may warrant sharing an individual printer or few off a less critical server or even a workstation. However, in most cases, Print Services can be combined with anything (again, except Hyper-V). And it’s quite common to put them on the same server as file sharing services. While they are lightweight and require few resources, placing them on web servers, database servers, mail servers, or Remote Desktop servers, for example, make them subject to the reboot requirements of those servers. Depending on how important printing is to your organization, this may not be a huge concern, however, most professionals would at least find it odd if not outright question why you would put Print Services on these systems and not the AD/File server.
This is often a vital service that can be down for a short period of time. As such, the server that hosts it doesn’t typically need to have an extremely high up-time. Most commonly, the DHCP service is added to a DC, in part because without it, machines cannot get on the network and without the DC, users can’t login. It’s also a very lightweight service in just about every respect. Unless you had a really good, specific reason, place this on one of your DCs. Or consider a split-scope DHCP implementation on multiple DCs, if you have them.
People often ask about combining Remote Desktop Services / Terminal Services and other roles. Don’t do it. Indeed, in some cases, Microsoft has made it impossible to do. Remote Desktop Services allows multiple end users (often without real strong computer skills) to remotely connect to the server and work. In many ways, it can be cheaper than using full desktop computers or it can provide secure ways of working remotely. In either case, considering there could be many users simultaneously working on the system, or that a misbehaved application could require occasional or even frequent reboots, RDS should be on a server by itself in ALL environments. From my perspective, the only possible other services one could add to it are File and Print – but only if the RDS server is the ONLY means of end users working. (Some environments may have a mix of desktops and thin clients to access RDS servers – those environments should never mix even the file and print roles with an RDS server).
Exchange servers are beasts. They require lots of resources and it seems with each new version, resource requirements grow. They are major services and email, to most organizations, is a VITAL service. You don’t want to be rebooting these systems unnecessarily. As such, keep exchange on a dedicated server. Don’t mix other roles with it. Never put it on a Hyper-V server for multiple reasons. And NEVER put it or mix another database service with it. The disk and memory requirements make that a potential performance nightmare. There are also documented issues when placing on an DC that, among other things, can cause security issues. In theory, other services can be placed on them, but you will degrade the performance of both Exchange and the other services (such as file, print, DHCP, non-Exchange web sites, etc.) Just don’t do it. Leave Exchange on a dedicated server. Always. Yes, Small Business Server used to, but IT Professionals often complained about it and now Small Business Server isn’t even an offering – hasn’t been since 2011.
Realistically, database services in smaller environments rarely tax a server. You don’t need 50 transactions per second – you might be lucky to have 50 in an hour. That said, you should be aware of the technology requirements for the database you intend to use. Older versions of Microsoft SQL ran fine on Domain Controllers, but newer versions do not support it nearly as well - and it can't be installed on a Read-only Domain Controller. You may be able to combine other services on the SQL or Database servers, such as file or print services, but be aware of the potential impact they can have on the performance and availability of your server. If you're using a SQL Express database I wouldn't be worried about running this on other servers. SQL Express, in my opinion, is intended for use just about everywhere a SQL database is preferred and when the database itself is not heavily used. Full SQL Server and other database engines like Oracle could require and generally should be run on their own server instances.
NEVER combine external accessible web service with internally necessary server roles. Databases, Remote Desktop, Active Directory – these should NEVER be on an externally accessible web server when they also allow your staff to work internally. This is a HUGE security issue. Web services in general are not terribly resource intensive on smaller networks. These days, it’s not uncommon to find web-based apps that provides services to your users. In some cases, using their own built in web servers, in others using IIS. Your biggest concern may be how to access multiple internal web applications through one IP address. The good news is you can assign multiple IP addresses to make this easier. In general, it’s not terrible for a company’s INTERNAL web services to also be hosted on the file server, but not if the file server is also an AD DC. There are potential security issues with unpatched vulnerabilities leaving a system open to attack, but in a smaller organization using the web server for internal purposes only, it’s generally acceptable to most. And don’t forget, you shouldn’t even think of adding the role to a Hyper-V host!
Fantastic for deploying Windows installations, most of the smaller small businesses won’t have a practical need for WDS servers. If you’re a larger small business, they can make it easy to reload Windows onto computers or setup new PCs. For smaller environments that may not use often, WDS can be added to a DC or an internal web server. It doesn’t have much to do with these services, but given their typical loads, should not place an unusual performance burden on those systems and shouldn’t require reboots often or have emergency requirements to reboot. They can saturate the network though, so be aware that when in use, the AD DCs responses could be slowed and on a web server, could make web sites unresponsive due to network congestion and abnormal disk access. Because they are disk intensive and network intensive when in use, you should not place WDS on file servers, database servers, or exchange servers. And as mentioned with everything else, NEVER on a Hyper-V host.
If you’ve decided to try to control your Windows updates using a WSUS server, you can feel reasonably confident placing this on your internal web server – especially since it requires web services to work. It’s a generally low resource, though the update repository may require a large amount of disk space. Never put it on a public facing web server and try to avoid placing it on an AD DC (since it will install IIS web services).
The combination of roles discussed above assumes that all your services are behind firewalls and not exposed publicly for anything that isn’t absolutely necessary for that service. (For example, the appropriate ports open to provide mail transfer on an Exchange server). The discussions of Web servers assume that the web server is for internal use only without exposure to the internet. With rare exceptions, all services that need to be exposed to the internet should be on a separate physical server in a DMZ to protect your network. Most businesses don’t have a need for these kinds of systems, but if you do, make sure they are as SEPARATE and SECURE as possible!
Most of the common roles businesses need in their servers have been discussed above. Again, it’s ideal to separate services on their own Windows operating system installations, but sometimes licensing costs and management costs can require you to combine roles. Even then, there are certain things that should NEVER be combined and others that a more commonly accepted. And if you find yourself installing or needing to install a new role or service or third party application, always ask yourself how it might impact your services – will they conflict for resources in a way that could cause problems? Will they potentially cause a problem due to incompatibilities with another service or program you are using? Will they allow the server and themselves to remain in a supported state? If you are not 110% certain of the answers, ask the professionals! That’s what we do!
Thanks to Larry G (DragonsRule) for providing additional feedback to improve this article.
1. Licensing Disclaimer: License information provided here is "best efforts". The comments related to licensing in this article are based on interpretation of the license agreements and the author's knowledge of the particular laws and regulations. Laws in your location may invalidate certain aspects of the license and/or licenses can change. "I read it in an article on Experts-Exchange" will not be a valid excuse in an audit. You need to contact the license granting authority to confirm any advice offered here.