Multiplexing—Overview_March 2021

Multiplexing – Details – Servers

Multiplexing does not reduce the number of Microsoft licenses required. Users and devices are always required to
have the appropriate licenses, regardless of their direct or indirect connection to a product. For example, any user
or device that accesses the server, files, data or content provided by the server that is made available through an
automated process requires a Client Access License (CAL). Certain circumstances do not require CALs, and they are
detailed later in this document. Generally, if files, data, or content are available because of a manual activity (a
person uploading a file onto a server or emailing the file), a CAL is not required for users or devices accessing those
manually transmitted files.

The following examples address specific products, but the same theory applies to other Microsoft services. Assume
that the Windows Server operating system and Microsoft Exchange Server are the networking and messaging
platforms, respectively.

Microsoft SQL Server

Figures 1, 2, and 3 illustrate representative Multiplexing scenarios and example licensing requirements for Microsoft
SQL Server database software. (Note: Windows Server and Exchange Server CAL requirements apply for any access
either direct or indirect to these servers.)

SQL Server CALs are required for users who directly input into, query, or view data from a SQL Server database (left
side of Figure 1). Similarly, SQL Server CALs are required for users or devices that input data into, query, or view
data from a SQL Server database through a pooling device (right side of Figure 1). This includes users who view
data through web-based applications or enter information into a database through an intermediary product. (Note:
Customers can also license SQL Server on a per-core basis, thus negating any need for SQL Server CALs.)

If a user (User 1 in Figure 2 above) retrieves data from SQL Server, that user requires a SQL Server CAL. If User 1
actively sends that data by email or other messaging technology to User 2; then User 2 does not require a SQL
Server CAL. With Multiplexing, these rules do not change. User 3, who receives data through a pooling application,
must similarly have a SQL Server CAL. If User 3 actively sends that data by email or other messaging technology to
User 4, then User 4 does not require a SQL Server CAL.

The paper distribution of data does not require SQL Server CALs for the recipients of the paper report. However,
both User 1 and User 3 in the figure above receive data (directly or indirectly) from SQL Server and both require
CALs. If each user prints the data and delivers it to another user (Users 2 and 4), these latter recipient users do not
require a SQL Server CAL.
A printer connected directly to the server does not require a license to print data from the server, nor is a printer
considered a Multiplexing device.

Project Server

Figure 4 illustrates some Multiplexing scenarios and licensing requirements for Project Server. (Note: Windows
Server and SQL Server [if licensed Server/CAL] CAL requirements apply for any access either direct or indirect to
these servers.)

Viewing or querying data from or entering data into Project Server through an intermediary Multiplexing application, which could include a web-based application, requires CALs for Project Server. Like SQL Server, the same CAL requirements apply for the messaging of data through email or paper distribution shown in the examples above.

Microsoft Azure DevOps Server

As with SQL Server and other products in the Microsoft server/CAL licensing model, applying Multiplexing rules to CAL requirements for Microsoft Azure DevOps Server depends on the degree of automation involved in content, file, or data accessibility and distribution. Any device/user that accesses or deploys files, content, and data that is made available in an automated way (for example, directly from a server or automatically posted to a server) requires a CAL. However, if the availability results from manual activity, such as a person loading files onto a server or emailing the files, a CAL is not required for users and/or devices accessing those manually posted or emailed files. The following examples illustrate the Azure DevOps Server CALs required. (The CAL requirements for other server products used with Azure DevOps Server still apply for any access either direct or indirect to the server.)

Example 1
An automated process is set up to load files from a server running Azure DevOps Server to a server farm, and then
that server farm automatically loads those files onto desktops. Azure DevOps Server CALs requirement: Each server
in the farm and each desktop/user require an Azure DevOps Server CAL because of a continuous automatic link
back to Azure DevOps Server.

Example 2
A business decision maker (BDM) downloads a report generated by Azure DevOps Server that was posted
automatically to a server. Azure DevOps Server CALs requirement: Each BDM requires an Azure DevOps Server CAL
because he or she is receiving the direct benefit of the automation of Azure DevOps Server. Even though the BDM
is reviewing a report posted to another server, he or she needs a CAL due to the directly realized benefit of the
server’s automatic posting.

Details – Dynamics 365, Power Platform, & Dataverse

As stated above, Multiplexing does not reduce the number of Microsoft licenses required.
Like server data, access to Dynamics 365 data through Dataverse typically requires the appropriate product license.
There are, however, certain situations that do not require full licenses. Users that access or receive information from
the server, files, data, or content provided by an automated process must always be appropriately licensed. There is
no such thing as “unlicensed user access” and a Multiplexing setup does not reduce the number of licenses required
to access a Dynamics 365 service, regardless of the pooling connection created. Any user or device that accesses
the Dynamics 365 service—whether directly or indirectly—must be properly licensed.
Dynamics 365 licenses are required for users or devices that directly input, query, or view data from the Dynamics
365 service. Similarly, Dynamics 365 licenses are required for users or devices that input data into, query, or view
data from the Dynamics 365 service through a pooling device.
Pooled connections use a non-interactive user account in Dynamics 365 that can access the system but only via the
web service layer. Internal users and devices accessing Dynamics 365 data indirectly through a portal or via an API
to a separate service such Microsoft Outlook must also be properly licensed, regardless of if they are set up as a
Dynamics 365 user in the service, for example:
• Internal users and devices accessing Dynamics 365 restricted data indirectly through a Power Apps must still be properly licensed for Dynamics 365.
• Any user or device that accesses the service, files, data, or content provided by the service that is made available through an automated process requires a Dynamics 365 service license.
• The number of tiers of hardware or software between the Dynamics 365 service and the user or devices that ultimately use its data, services, or functionality does not affect the number of licenses required.
Note: Licensed users may manually rekey information (when coming from non-licensed users) into the Dynamics 365 service.

Multiplexing needs to be considered if you are moving data within Dynamics 365 through Power Automate or other
automated means.

• If the data is within Dataverse, and as long as it is standard entity data, it can be accessed by any user with
appropriate Dataverse licensing (either a Dynamics license or a Power Platform user license).
• If the data is in Dataverse and it is restricted entity data, then Multiplexing applies and the end users would
need an appropriate Dynamics user license.
• If data is moved outside Dataverse via Power Automate, then users accessing the data would also need a
Dynamics license.

The above applies because Power Automate is an automated process. E.g., End users accessing said data would
need the appropriate licenses, whether the automated process moves restricted data outside Dataverse or if the
data was never moved outside Dataverse.

How does Dynamics 365 leverage Dataverse & Power Apps?How does Dynamics 365 leverage Dataverse & Power Apps?

Dynamics 365 customer engagement (CE) transactional apps (e.g. Dynamics 365 Marketing, Sales, Customer Service,
Field Service) are natively built on the Power Platform, extensively leveraging Dataverse, Power Apps, and Power
Automate. Therefore, each of these apps has the following features:
• Automatically deployed into a Power Platform environment
• The data from these apps are stored directly in Dataverse
• The app business logic exists in the Power Platform environment and is implemented directly into Dataverse
• The user interface is surfaced via Power Apps

Dynamics 365 ERP transactional apps (e.g. Dynamics 365 Finance, SCM, Talent) are not deployed natively in Dataverse and reside at least in part on other platforms (not Power Platform), which means the data, business logic, and user interface do not leverage Power Platform out of the box.

Common Scenarios

General Multiplexing
Scenario: User A is appropriately licensed and wants to distribute data to colleagues (unlicensed) and import the
modified data back to the originating service.

Example 1
User A manually exports data from Dataverse and uploads to external storage location or sends data via email to
colleagues. The colleagues consume/edit data. User A manually imports the data back to Dataverse.
Not Multiplexing: Since User A is manually performing all steps in the distribution of data, and they have the
appropriate licenses, it does not matter of who they are sending data to.

Example 2
User A has Power Platform (or other automation) export data from Dataverse and uploads to external storage
location or sends data via email to colleagues. The colleagues consume/edit data. Power Platform (or other
automation) imports the modified data back to Dataverse.
Multiplexing: Since Power Platform (or other automation) is performing all the steps in data distribution, the end
users should have the appropriate license to access the original data and import back the modified data.

Example 3
User A has Power Platform (or other automation) export data from Dataverse and uploads to external storage
location or sends data via email to colleagues. Before the distribution of data, User A decides “Go/No-Go” and
manually hits send/perform on Power Platform (or other automation) to complete task. The colleagues
consume/edit data. Power Platform (or other automation) import data to Dataverse, before finalizing, User A
decides “Go/No-Go” and manually hits send/perform on Power Platform (or other automation) to import the data
back to Dataverse.
Multiplexing: Even though User A is performing a manual step in the process, they are not performing all steps
and there is an automation step. Since there is an automation step, the end users accessing data need the
appropriate licenses.

Dynamics Data & Dataverse

Example 1 – First party application and service access to data within Dataverse
There are many scenarios where Dynamics data in Dataverse is created with application business logic, or where
updates to Dataverse data will cause business logic in applications to execute. Customers must enable both cross-
Dynamics application access to data and Power Platform access to data while still ensuring the proper licensing of
application or user access is maintained.

Example 2 – Exporting of business application data outside of Dataverse
Customers can export data outside Dataverse. However, Multiplexing policies state that customers who are accessing Dataverse data, even when it is outside of Microsoft products, still require appropriate Microsoft licensing.
If the data exported is through an automated means, CALs will be required for appropriate access.

Example 3 – Third party integrations into Microsoft applications and services
Third party services can integrate into Microsoft services, creating significant value for customers, however, this can
potentially cause significant workloads onto Microsoft systems. Multiplexing policies state that all users of the
integrating service must also be licensed for the Microsoft service that they are integrated with, even if those users
never use the Microsoft service directly.

Example 4 – Using first party non-user-based services to avoid first party user licensing
Multiplexing only applies to access-based licensing, which is a significant benefit that metered, core-based and
other non-user-aligned licensing models offer. When user-based licensing models and non-user-aligned models
co-exist, their interactions can be complex and can introduce additional licensing challenges for customers.

Microsoft Dynamics 365 & Power Platform

Example 1: Customer uses Power Platform to solve a pain point, then buys Dynamics 365 and wants to deploy it in the same environment.
Power Platform can create significant advantages in productivity for customers. Occasionally customers prefer to
“lock down” their Dynamics 365 environment to scenarios directly related to it – and therefore deploy more standalone scenarios in a different environment.
When deploying in the same environment, Multiplexing rules will still apply even with the Power Platform solution
deployed and it’s critical that each user or device has the proper Dynamics 365 access licenses.

Example 2: Customer wants to extend their Dynamics 365 scenarios via Power Platform in the same environment.
This scenario is extremely common for customers who want to use PowerApps to extend Dynamics 365 for “light”
Dynamics scenarios that may have traditionally been covered in a Team Member scenario. For example, Firstline
workers may want to use Power Platform for lead generation or customer support. With the added complexity of
this workforce historically being unlicensed, introducing new automated solutions often causes additional licensing
and scenario questions.
Multiplexing rules will still apply, and it is critical that each user or solution has the proper Power Platform license
and Dynamics 365 access license depending on the solution deployed.

Example 3: Customer wants to extend their Dynamics 365 scenarios via Power Platform in the same environment and they want to create a separate Power Platform environment for standalone scenarios.
This is also a very common scenario – Dynamics 365 customers who want to do Example 2 usually (often model-
driven apps) also want to create non-related solutions (often canvas-driven apps) that they’d like to keep separate
for a variety of reasons (e.g. clean data, security/access control, etc.).
As with Examples 1 and 2, the same Multiplexing rules will still apply depending on the Power Platform solution
deployed and each user or device must have the proper Dynamics 365 access licenses.

Download the document:

(© Microsoft Corporation. All rights reserved.)