Is device-based licensing of O365 Apps for Enterprise support in PVS e.g. Non-persistent VDI solutions?

[Andrew Meneguz1709154345]

I’m in the process of building some new VDAs with XA/XD version 2112 on Windows Server 2019. The target devices are being deployed using PVS.

 

We’re at the stage of installing and testing all our business applications and hoping to start UAT soon, however we’ve hit a bit of a roadblock with Microsoft 365 Apps for Enterprise (O365ProPlus as its sometimes referred).

 

We just now discovering that the required licensing feature of shared computer activation requires an O365 E3 license, when the vast majority of our Citrix users are only licensed with the much cheaper E2 license.

 

My manager did account for this when dealing with Microsoft earlier in the year and has paid for some additional device-based licensing. This comes with some other requirements that we need to investigate internally, such as getting our new VDA’s hybrid domain joined in AzureAD.

 

Before we spend too much time working on this, I wanted to see if anyone has been able to successfully implement this licensing model for non-persistent VDI solutions that use multi-session OS (Windows Server 2019). I just don’t want to spend significant effort researching and implementing hybrid AzureAD and device-based licensing to discover it’s not applicable in a non-persistent Citrix VDA scenario.

 

Absolutely nothing that I've found online talks about licensing O365 Apps in Citrix with anything other than shared computer activation, yet Microsoft licensing teams are telling me it'll work.

 

In case it helps, relevant versions below:

 

Apps and Desktops 2112 on Windows Server 2019 Datacenter

WEM 2112 on Window Server 2019

Licensing, StoreFront, Controller, PVS Server (and target device software) are all 2106 or the version packaged with that ISO on Windows Server 2016 Datacenter

 

[James Kindon]

watching this out of curiosity more than anything

 

Device based activation is an "or" to shared computer activation

 

SCA was in the user context, and simply (to the best of my knowledge) did two small things  - reduce the lifetime of the activation validity to 3 days (or something similar) and removed the registration from the users "devices" on the user object

 

Device based activation takes this away from the user side of things entirely, and the machine itself does the check on itself - so with a technical lens, I cannot see why it wouldn't work as long as you have your hybrid join done right

[Kasper Johansen1709159522]

Hi,

 

I am by no means an expert in Microsoft licensing, however from what I can find the E2 subscription no longer "exist" it seems like MS at some point discontinued that subscription type. Maybe something to look into?

You are right about the shared computer activation feature being available with Office 365 E3 and it is actually also available with the E5 subscription. There is another subscription which also has the shared computer activation feature, the Office 365 Business Premium. As Microsoft states in the article below, these are the only subscription types which include the shared computer activation feature:
https://docs.microsoft.com/en-us/deployoffice/overview-shared-computer-activation#how-to-enable-shared-computer-activation-for-microsoft-365-apps

It doesn't really matter if the VDA is non-persistent or persistent, as long as you have a shared device, like a terminal server or a VDI, the shared computer activation feature is recommended. This goes for all supported operating systems and Citrix Virtual Apps and Desktops versions.

[Andrew Meneguz1709154345]

Cheers for both the replies on this.

 

After doing some more extensive reading on the subject, I can absolutely see where you're coming from James, I think you're right that device-based licensing would work in theory, but there's absolutely no documentation or guides demonstrating or recommending this for a multi-session OS environment, whether RDSH or Citrix. And since my Citrix contacts are telling me that Shared Computer Activation is the only supported method that they are aware of, I'd expect very little support from them if I encounter any issues.

 

I'd love to just go ahead and test it, if it wasn't for the requirement of the device being Hybrid Azure AD joined, as this is something we're not doing at all and again requires further research on my part. This article provides steps on how to hybrid join a non-persistent VM (e.g. PVS target device) to Azure AD where the underlying hybrid Azure AD environment already exists.

 

https://support.citrix.com/article/CTX284738

 

Does anyone know if group membership of the device persists upon reboot? as the device-based licensing would need to be tried to a group object.

 

Edit: further reading suggests that you can do a targeted rollout of hybrid Azure AD joined devices, so there's potential for me to test this specifically on my new VDA's without exposing my entire org to a hybrid Azure AD. I'm going to look further into this and and if I end up proceeding I'll let you all know what I discover.

 

 

[James Kindon]

On 1/31/2022 at 6:47 PM, Andrew Meneguz1709154345 said:

And since my Citrix contacts are telling me that Shared Computer Activation is the only supported method that they are aware of, I'd expect very little support from them if I encounter any issues.

This is likely a grey area so i wouldn't expect many would know the difference yet (you are trailblazing :))

 

On 1/31/2022 at 6:47 PM, Andrew Meneguz1709154345 said:

Does anyone know if group membership of the device persists upon reboot

Yes, your AD objects populate these groups

 

On 1/31/2022 at 6:47 PM, Andrew Meneguz1709154345 said:

further reading suggests that you can do a targeted rollout of hybrid Azure AD joined devices, so there's potential for me to test this specifically on my new VDA's without exposing my entire org to a hybrid Azure AD

This is becoming pretty common place now - we do it in most projects, you won't break yourself

 

On 1/31/2022 at 6:47 PM, Andrew Meneguz1709154345 said:

I'm going to look further into this and and if I end up proceeding I'll let you all know what I discover

Community Power

[Andrew Meneguz1709154345]

For those still interested in this. The environment is still in internal testing, so nothing concrete just yet, however it's looking to be a successful solution as below.

 

- VDA's have been Hybrid Azure AD Joined

- Device-based licenses have been allocated to a group object containing the VDA's

- Group Policy has been used to switch Office from SCA to device-based activation

 

In my early testing I can see that

- Office reports that the license belongs to "this device" which indicates successful device-based activation.

- Office E2 licensed users can now launch Office 365 apps and rely on the device license

- Multiple users/sessions on the same VDA can launch Office with the device license

- No issues related to FSLogix profiles discovered so far

 

My only lingering issue at this stage is that upon reboot of my VDA's they can take an hour or so to report a successful Azure AD join state, my understanding is that they should re-use the existing device record and that rejoining Azure AD should be immediate. Raising a ticket for this one with Microsoft.

 

I do stress that I haven't thoroughly tested yet. I'll update if I discover any deal breakers that the community should be aware of.

 

Edit: An update on the issue of re-joining AzureAD after reboot.

It would appear that the userCertificate computer object attribute cleared and repopulated on reboot, I believe this is due to the self-signed certificate which is created by the device machine not being found as it's a non-persistent device. Therefore the following sequence needs to occur on every system start-up

 

1) Device boots and attempts to rejoin Azure AD

2) Joining fails with authentication error similar to the below

Diagnostics Reference : www.microsoft.com/aadjerrors User Context : SYSTEM Client Time : 2022-02-16 01:13:43.000 UTC AD Connectivity Test : PASS AD Configuration Test : PASS DRS Discovery Test : PASS DRS Connectivity Test : PASS Token acquisition Test : FAIL [0xcaa20003/0xcaa1000e] Correlation-id: {D9BF2100-7DF1-400E-B436-1AEA4B08EB61} Fallback to Sync-Join : ENABLED Previous Registration : 2022-02-16 01:01:51.000 UTC Registration Type : fallback_sync Error Phase : join Client ErrorCode : 0x801c0002 Server ErrorCode : AuthenticationError Server Message : The verification of the target computer's SID <removed> signature failed. Device id: <removed>. Https Status : 400 Request Id : f6ebcce2-c5e2-4977-aaf6-42920b557792

 

3) userCertificate attribute of the non-persistent device is cleared and repopulated after the self-signed cert is automatically generated

4) Azure AD Connect updates the devices userCertificate property when the scheduled synchronization is run

5) AzureAD join completes successfully either via manual 'dsregcmd /join' or by waiting for the recurring scheduled task to run

 

[James Kindon]

i use BIS-F on all my deployments and get it to run the dsregcmd /join on machine boot

 

also have customer doing this by scripts as a standard

[Andrew Meneguz1709154345]

1 hour ago, James Kindon said:

i use BIS-F on all my deployments and get it to run the dsregcmd /join on machine boot

 

also have customer doing this by scripts as a standard

Yep I'm doing the same with a start-up script, the problem was that it'll fail until an AADC sync updates the userCertificate property of the computer object with the newly generated self-signed cert. Fortunately it appears to retry often and since my reboot schedule is early AM and AADC syncs hourly it'll mostly go unnoticed to end users, by the time they login it would have sorted itself out.

 

I think this only applies if you're not using ADFS.