Hero Banner

Microsoft AppSource and Azure Marketplace

Learn how to grow your business by publishing your cloud solution on Microsoft AppSource and Azure Marketplace

Level 1 Contributor

How to Deploy VM for Remote App that needs Office

We currently have Windows applications deployed in a Remote Desktop or Remote App scenario with on-premise servers and VMs. We'd like to do the same using VMs on Azure. We are having trouble understanding what is necessary to handle:

  1. User licensing for CALs (they may or may not already own this)
  2. User licenses for Office 365 (users may or may not own this). Just needed to show an export of an Excel or Word file)
  3. Manage users in our application (we may want to offer the VM to a customer but not manage their individual users)
  4. Deployment of a VM to our Azure subscription or the customer's subscription

Are there Best Practices that we can adopt to simplify the licensing and deployment of a VM we create in the marketplace so that licensing and user counts are handled by Azure/Microsoft? Thanks.


I thought you have build those applications that need to run in Remote Desktop? If it is the applications of the customer, then it is no longer (only)  a marketplace topic, then the right venue is to act as CSP Reseller and then build RDS or better WVD-based environments for each customer reselling the azure subscriptions + your managed solution on top. 

However, if each customer gets their own tenant/environment then also WVD with Windows 10 Multi-Session can be used which allows for additional licensing scenarios.


1.1. There is no SPLA feature in Azure. SPLA is a separate license agreement you sign to be able to obtain SPLA licenses for hosting scenarios. Then, if you build RDS or WVD with Windows Server you enter the RDS SALs that might be obtained in the RD licensing role, just like a normal RDS CAL (like it is done currently when the customers already an on-premise RDS) .

1.2. If you provide a hosted solution (again - if those are applications you have developed and you provide this as a hosted solution to end customers) Getting the SPLA agreement is your burden. If you sell an RDS solution for a customer via CSP the customer is responsible for getting the required licenses, you can of course help them (and sell some of the licenses).

1.3. In SPLA (Partner-owned scenario)  you have a monthly usage reporting you need to send to Microsoft and license reassignment rules documented in the SPLA agreement. When customer has his own environment/tenant, e.g. sold to them by you via CSP, the customer has not really an option to scale the number down when Windows Server RDS (or WVD with Windows Server) is used - minimum term for RDS CALs is one year. However, when using WVD with Windows 10 Multi-Session you could sell Windows 10 user-based licenses in CSP where you can adjust license count on a daily basis.

1.4. Licensed are assigned to users (=persons), not concurrently  - this does not change with Azure, this si the same schema as you have currently with the on-premsies solution.

1.5. Number of VMs/Session host has no influence on the number of access licenses or Windows 10 per user licenses since those license are assigned to the user (same as how Windows CAL licensing works since ever).

2. As mentioned - if your plan is that users want to use their own O365 licenses, then the right solution is to sell Azure subscriptions via CSP in each of the customers account, so your RDS7WVD solution is deployed n the customer tenant and customer can then also apply their own O365 licenses.

3.1. Correct - unless you share an AzureAD tenant and local AD between multiple end customers, you would need to build a tenant & AD per customer.

3.2. If you host this as complete solution you  do not want to give customer to give control over that - again I think the CSP reseller option would be better because then the customer can integrate the solution in their own AD as needed.



If you open a request via https://aka.ms/tpdmsform  and add in the description that you want to this request to be assigned to me I'm sure I can help you - I'm not sure in which time zone you are (I'm in Germany UTC+2) so we need to check if we can find a meeting time that suits us both. Agree that the combination of licensing & technical options in this area are complicated, but this is one of my specialities 🙂 - and while the TP&D team is usually more focused on the technical areas I'm happy to have this conversation since I have quite some experience in this area. This discussion is not really suited for the communities, there are just to much things to write down 😉





Kind regards, Janosch (OutOfOffice 8/12/22-9/5/22)
Receive consultations via Technical Presales and Deployment Services team

@LukeChung :


1. For accessing Windows Server VMs in Azure you don't need Windows CALs, but RDS CAL are required.

If you deploy the solution to the customer tenant (e.g. publish as IaaS solution/VM templates in Marketplace) the customer can use RDS CALs he obtained separately (With active SA), or if you become a CSP you might be able to sell him RDS CAL Subscriptions separately.

If you want to deploy it to your own tenant and publish like a SaaS offering, you will need to license RDS via SPLA licensing - the same way as you currently have to when providing this hosted solution to your end customers. Windows license will be billed via Azure (integrated license in Azure VMs), RDS SALS are added via SPLA.


2. Similar to 1 - if the solution is deployed to the customers tenant, customer can use O365 licenses he has or you sell to him separately. If the solution is deployed to your tenant, only Office 2019 SALs via SPLA are an option, the same way as you do it now on-premises.


3. If you publish the offer as an IaaS solution, it will be deployed in the customers tenant - you could design your solution that it can be integrated into customers Active Directory so the customer can use his users. If it is not integrated with the customers AD you would need to either manage the users or aks the customer to add users himself asl local users or build up his own DC. 

generally the SaaS solution publishing option addresses this issue since the services runs in your tenant, and since you have will need to integrate AZureAD in your app and allow for multi-tenant usage user authentication is handled on customer side, the solution wpuld perfectly integrate into th customers Azure AD. However, you do not have a "real" SaaS solution when you are leveraging Remote Desktop, so I see no other way then to manage the user accounts on your side.


4 - see comments above. 


Overall - I would strongly encourage you to rethink the approach using Remote Desktop Services - it will make your solution much more expensive for the end customer and it is much more complicated to scale economically. If you were building a real (web-based) SaaS solution the customers would benefit. I as a customer would prefer any vendor that offers a SaaS app that I can integrated into my AzureAD easily instead of a Rich Client Windows App where a full fledged RDS environment is needed - for which I have to pay for directly or indirectly.

Same goes for Office Client - if it is just to display an export of an office files, the cost of having an office license is just not economically feasible. Why not render exported files in a different way - even exporting as PDF would be much easier because it can be displayed in most browsers. Building Office files can be done using OpenXML SDK etc...


You can also request to get a consultation for Marketplace publishing via Technical PreSales & Deployment Services if you are MAPS, Silver or Gold Partner - just open a ticket here: https://aka.ms/tpdmsform.




Kind regards, Janosch (OutOfOffice 8/12/22-9/5/22)
Receive consultations via Technical Presales and Deployment Services team
Level 1 Contributor

Thank you for the detailed response.


Let me first address the suggestion of rethinking the use Remote Desktop Services. For the scenarios envisioned, that makes no business sense. Organizations have lots of Windows applications they've already purchased or custom built that would cost millions of dollars to replicate, just to get what they already have. This is especially impractical when the original authors are long gone or the number of users are internal and few in number (say under 20). So assuming that Remote Desktop and Remote App are the appropriate platform to avoid the issues of managing those applications on each user's machine, let's focus on whether Azure can support this efficiently.


  1. If we need to get RDS CALs on Azure, how do have customers use the CALs they already own, or purchase them on their behalf?
    1. Where is the SPLA feature in Azure? Is that an option as part of the VM's Windows license when we create the VM?
    2. Can customers take care of this or is this our burden?
    3. How do we apply and manage them over time as users rise and fall?
    4. Are these licenses per user or for the maximum number of simultaneous users?
    5. If we have multiple VMs, to each support a different set of applications, is a separate CAL required for each user or user count, or can it be combined as one? This is an architectural question of whether all applications should be put into one VM vs. a separate VM for different sets of applications.
  2. So if we want to support the ability to open Office files, we have to get into the Office licensing mess and there's no easy way for users to login with their existing Office 365 licenses? I don't think we can have a Remote App export a file to the user's desktop. If so, this problem may go away since the users already have the Office products installed locally.
  3. Thank you for the suggestion on how to integrate the VM into the customer's existing AD.
    1. If we host it, it seems a separate VM would need to be created for each client. I presume we can't support this in a multi-tenant scenario since each customer would see other customer's users.
    2. Would we be able to give them the ability to set the AD settings for just their VM so we don't need to be involved at that level?

Thanks. We are a Silver Partner, so we can open up a ticket to help with this. We've been struggling with migrating these VMs to Azure from internal network servers over the last few years but the licensing questions, rather than technical issues, are so overwhelming that it's stopped us each time.