nobeastsofierce - Fotolia
One way around Microsoft's licensing restrictions is to bring your own Windows licenses to a DaaS provider. The challenge is for the DaaS provider, which may only use your licenses if they dedicate physical servers to you.
This approach is an attractive choice if you already have a license agreement with Microsoft -- particularly a favorable agreement like those made with educational institutions or charities. But the provider may not run any other customer's virtual machines (VMs) on that hardware.
This setup breaks one of the core principles of cloud computing: multi-tenant pooling. This dedicated hardware for one client creates a relatively small pool, so the cloud provider will need to charge more than it would when using shared hardware. Since this pool contains a finite amount of hardware and computing resources, there is also limited elasticity.
Doubling your user count will probably require the provider to provision more hardware, resulting in a delay. One of the benefits of desktop as a service (DaaS) is instant scalability, which can't happen in this scenario. Elasticity in cloud services doesn't just mean getting bigger when you need, but also getting smaller. But once the hardware is bought and installed, the DaaS provider may want you to keep paying for this extra capacity, even after you need it.
Another option is to have servers you own in the provider's data center, which is usually referred to as a colocation arrangement. The provider has server racks with power and Internet connectivity. The customer puts its servers in those racks and builds the environment. Colo may not quite qualify as DaaS, but it may deliver the benefits you want from DaaS while allowing you to use your own Windows licenses.
You still won't get multi-tenant pooling or elasticity, but you do get far more certainty, because you own almost all of the set-up. If the hardware is all yours, there is no risk of so-called noisy neighbors -- other customers of the service provider using your computing resources.
Windows desktops vs. Windows Server desktops
To get the best economics, DaaS providers need to run their desktop VMs in large, multi-tenant resource pools, which requires using server operating systems covered by Microsoft's Service Provider License Agreement (SPLA). Luckily, some years ago, Microsoft decided to merge the code base of Windows' server and desktop versions. Because of that, Windows Server 2008 can be set up to look and behave almost exactly like a Windows 7 desktop. The same is true for Windows Server 2012 and Windows 8. Many DaaS providers offer a separate Windows Server VM for every user of their services. Clever DaaS providers even make over the visual elements of Windows Server to mimic desktop versions of Windows.
Since we know that server and desktop versions of Windows share the same code base, you might expect their applications to run happily on either OS. That is not always the case. The vast majority of Windows applications run just as well on a Windows Server OS as they do on a Windows desktop OS. Almost any application that is written to Microsoft's standards, including Office, will run on Windows Server.
Not every application, however, is written according to Microsoft's standards. Some software will refuse to install if the installer sees a server operating system. In other cases, there are Windows components that are normally installed on desktops but not on servers. An example is scanner support, which is not usually present on servers. These issues are usually not insurmountable -- it is possible to trick the installer into seeing a desktop operating system, or to install those additional components -- but they do complicate matters.
Challenges sometimes come from applications that are very old or that have been custom-written for a specific business. A lot of custom-written software has no issues running on a Windows Server pretending to be a desktop, but there is also a lot of software that was written in a hurry for the lowest price and without clear future requirements in mind.
Most DaaS desktops run 64-bit OSes that support large amounts of RAM and provide excellent application performance for recent applications. But 64-bit Windows cannot run 16-bit applications. Any application written in the last 15 years should be 32-bit, which will run on a 64-bit OS. If your organization still depends on 16-bit applications, now is the time to invest in replacing them. Either put users of 16-bit applications out of scope for DaaS or come back and look at DaaS when these applications are gone.
Inside cloud multi-tenancy
One of the keys to making cloud services economically viable is creating a large pool of resources and sharing it amongst a number of tenants. To keep their costs low, cloud providers want the largest pools possible. These pools are usually far larger than the average customer requires, so many customers will share a single large pool.
Isolating the customers (tenants) in a pool is a core feature of every cloud service. Security isolation -- hiding each customer's data from the other customers -- is usually the first priority. Another kind of isolation relates to performance and noisy neighbors. A noisy neighbor is another customer that uses resources (including CPU, RAM, disk and network) to the point where your desktops do not get enough resources and their performance suffers.
In general, the more you pay for a certain level of multi-tenant cloud service, the more isolation you can expect.
Using RDSH for DaaS
If you have been following the delivery of Windows desktops from the data center for enough years, then you will remember Application Service Provider, which involves providing a Windows Terminal Server-based desktop. This is a very viable DaaS model now. Rather than dedicating a Windows Server OS to each user, there are options to use Remote Desktop Session Host (RDSH) to host multiple users' desktop sessions on a single Windows Server. Having several of your employees share an RDSH server requires less hardware from the DaaS provider, which should cost you less than dedicated VMs.
On the other hand, RDSH provides less isolation between users. All the users on one RDSH host share its system drive and applications. Also, the users sharing an RDSH host can be noisy neighbors. One extremely complex Excel spreadsheet can bring a whole RDSH server to a crawl. Application compatibility with RDSH has always been a potential challenge as well.
Most applications are just fine; again, the ones written to Microsoft's standards are usually happy. There are applications that run just fine on Windows servers as desktops, until another user tries to launch the same application in another Remote Desktop session. These tend to be the specialized line-of-business applications used by a small number of organizations. Often, you can talk directly to the company that developed the software and find out whether they have customers using the software on RDSH. I've seen applications that have a special install process or even a separate installer for RDSH. There is some care required to run applications in RDSH, but most can be accommodated.
You may need to use several approaches to DaaS in order to accommodate your requirements. Some users may be best served by multi-tenant Windows Server desktops while others can use cheaper RDSH desktops. You may find that building your own VDI in a cloud provider's colocation facility gives you all that you wanted from DaaS. Some of these choices would be simpler if Microsoft offered SPLA licensing for its desktop operating systems, but much of it would be exactly the same -- just maybe a little cheaper.
Microsoft introduces per-user Windows licensing
Not all cloud licensing models are created equal
You could be paying too much for Windows Server licensing