This video is about the most common licensing options available when buying a PowerEdge server with a Microsoft Windows Server Operating System. Relevant topics I’ll be discussing today are the per-core licensing model, per-user and per-device CALs, RDS CALs, licensing Microsoft SQL Server, licensing Windows Server Essentials, and the Secondary OS option. A quick note here is that the policies and procedures that govern Microsoft software licensing vary, so it’s always important to refer to the applicable end user license agreement.
I will simulate the purchase of a PowerEdge server on dell.com to talk about the different options. Recent versions of Windows Server use the per- core licensing model. What this basically means is that there has to be one license for each CPU core on the target server to meet compliance. There are two important notes here. First, you must license at least eight cores on each processor, even if you have fewer cores than that. Second, you must license at least 16 cores on each server, again even if you have fewer total cores than 16. To illustrate how this affects the order, I’ll simulate a server built on dell.com.
I’ll start by selecting two processors with just eight cores each. If I scroll down to the 'Operating System' section and click Windows Server, it doesn’t matter if it’s Datacenter or Standard, I can see that this item will suffice to obtain 16 core licenses. That’s just enough to license the two processors I selected for this server. There’s no warning about the licensing option being invalid. This table here, showing the number of cores on the most common CPUs available from Dell, validates that for a two-processor server with eight cores on each CPU, a total of 16 core licenses are required. Back in the configuration page, if I change to two physical processors with 16 cores each, there’s a warning indicating that the licensing options need to be reviewed.
That’s because, according to the table, with this new selection I will be needing a total of 32 licenses to comply with the per core requirement. To do so, back in the configuration page, I need to buy more licenses, and those are only sold in packs of two or 16. This is why further down the build options under 'Licenses', I see the option of buying the remaining 16 that I need to be compliant. I can buy one pack containing the 16 licenses or eight packs of two to total the 16 I need. Once I do that, there’s no longer a warning in the configuration. Let’s change the processors one more time, this time to four physical CPUs of 20 cores each. The reference table tells us that such a server would need 80 core licenses.
This is why the warning is back for the selected operating system. So, if in addition to the eight packs of two licenses that I added earlier, I select three packs of 16, I will be getting in total 80 licenses for my 80 cores, and therefore the warning is again gone and the configuration is valid. Notice that the additional licenses include the label 'NO MEDIA/KEY'. This is because the server ships with just one product key printed on the COA sticker. The product key is tied to the number of cores allowed for the installation.
A common question here is what happens if the server configuration changes and it ends up with more physical cores than the licensed amount. Will it power down? No, in such a case, the server will continue to run regardless of being out of compliance, but Microsoft may conduct audits to verify compliance and take enforcement actions such as requiring the purchase of additional licenses or imposing penalties. Two more things to note about core licenses.
First, per-core licensing applies to both Standard and Datacenter editions of Windows Server. And second, in addition to licensing the server with a per-core model, each user or device accessing that server’s services requires a Client Access License, which takes us into our next topic. Again, every user or device that connects to a server to access its services, for example, to access a file located on a shared folder on the server or to print on a shared printer configured on that server or for Active Directory Domain Services, should be licensed to do so with a corresponding Client Access License or CAL. Let’s go back for a moment to our sample configuration web page. Under 'Client Access Licenses', I see the multiple options for purchasing these CALs.
These are sold in packs of 1, 5, 10, or 50, for instance, and there are two types: User CALs and Device CALs, depending on whether the server’s services will be accessed by a large number of users sharing a small number of computers or by just a few users sharing a large number of computers, phones, or other devices. A key difference is that CALs are not enforced through product keys in the same way that the server licenses are. Instead, CALs are managed through documentation and records of purchase. There will be no product key for these CALs, and there’s no need to activate them.
This means that the server in this simulation would ship with a printed document that certifies that 10 user CALs were purchased. Once again, a question that sometimes is asked is 'What happens if there's less CALs than the amount needed by the number of users and devices accessing a server?'. Will the server refuse the connections? No, everything will continue to work, but again, the server will be non-compliant, and this can lead to legal and financial consequences if discovered during an audit. This is why it’s important to keep good records of the documentation provided during the purchase.
If this documentation is received and later lost or misplaced, neither Dell nor Microsoft have any method to replace it. A special type of CALs are Remote Desktop Services Client Access Licenses, or RDS CALs. These are needed when the users need to connect to a server not just for printing or file sharing or Active Directory, etc., but exclusively when they need to connect by using the Remote Desktop Protocol. You can see here in the sample server configuration that these appear in a different section and are also sold in packs. These are the main differences between regular CALs and RDS CALs. First, RDS CALs are enforced.
That means that if there isn’t the right number of RDS CALs to cover the number of users or devices accessing the Remote Desktop Services, the server will restrict or deny altogether connections using the RDP protocol. Second, the RDS CAL packs that are available for purchase here in the sample configuration we are using ship with a product key. This product key is tied to the number of licenses that are being purchased. These RDS CALs need to be installed on a license server, and this license server needs to be activated in the Microsoft clearinghouse as well. You can find more details about this process in this knowledge base article. Another Microsoft product that can be purchased along with the server is SQL Server.
There are several SKUs related to it in the sample configuration web page. All of these refer to the on-premises deployments and to the Standard Edition of SQL Server. Under 'Microsoft SQL Server', there are three sections: 'Core', 'User', and 'Device'. This is because recent versions of Microsoft SQL Server Standard have two different licensing options. These two here, per-user and per-device, are part of the Server + CAL licensing model. With this model, you install a Microsoft SQL Server license on the server, whether it’s physical or virtual, and you don’t have to worry about the number of CPU cores present on that server.
However, in addition to that server license, you need to purchase a CAL for each user or device that connects to this SQL Server. You can see that the SKUs available here include the server license plus five per-user or per-device CALs. Further down under client access licenses, there’s a separate SKU to order more SQL Server CALs in packs of five. Another option for licensing SQL Server is the per-core license, visible here. With this option, you license the physical or virtual server where SQL is installed and running. You need to purchase the right number of SQL per-core licenses to cover all the cores in the server.
However, you do not need to purchase SQL Server CALs for users or devices. You get unlimited access for internal and external users. Here in the sample order configuration is an SKU for purchasing SQL Server with this per-core licensing model and enough licenses to cover four cores. Under 'Client Access Licenses', one can select further packs of two SQL per-core licenses. In both licensing models, it is worth noting that first, a server ordered with SQL Server properly licensed ships with a product key for use exclusively with SQL during installation or activation.
This key is different than the Windows Server product key and it may be on its own COA sticker. Second, SQL Server itself does not actively enforce licensing compliance by refusing connections based on the number of SQL CALs or the number of per-core licenses available. Instead, compliance is enforced through licensing audits conducted by Microsoft. On the SQL topic, one last item I’d like to talk about is this SKU, 'Microsoft SQL Server Standard OEM Additional Server'.
This SKU is sometimes selected thinking that it is a scaled-down version of SQL Server because of the lower price listed. Well, it is not. What this item does is that it allows you to license an additional instance of SQL on a server that already has a licensed SQL Server installation. You can run multiple instances of SQL on a single computer. If you do that, each of those instances of SQL Server requires its own separate license. I can customize the number of additional server SKUs depending on how many instances I will have running on the server. But these SKUs do not come with a product key. Activation of these additional instances is managed using the same key as the primary server instance. Windows Server Essentials 2022.
This is an OEM-only option, meaning that it has to be purchased along with server hardware. It is available for servers that have a single CPU with 10 cores or less. You do not need to purchase per user or per device CALs for users connecting to the server’s services, but there’s a maximum of users you can have - 25. When a server is ordered with Windows Server Essentials 2022, it will arrive with a COA sticker that has a product key.
To activate the operating system you can use this product key in a DISM command that looks like this. Notice that you need to specify the Standard Edition even though the product key is for the Essentials Edition. This is because there’s no specialized installation media for Windows Server Essentials. Licensing compliance is enforced by the product key.
The server shuts down if it detects that there are more users or devices than what’s permitted by the end user license agreement. Purchasing Windows Server as a Secondary OS is an option when selecting the software for some Dell hardware. This allows you to install and license Windows Server on the same hardware that will run another third-party operating system. The secondary OS SKUs are almost invariably used in virtualization scenarios. In this example here, the physical server will run a VMware operating system to host Windows virtual machines.
In such a scenario, the same licensing points we’ve discussed today pertaining to per core licensing, virtualization rights, etc., are applicable to the Windows virtual machines, completely independent from the third-party OS licensing requirements. Okay, so this has been a brief introduction to some Microsoft licensing concepts related to the operating system and other software that may be ordered along with Dell hardware. I hope you find this useful, and I’d like to thank you very much for watching.
