Question:

Could you provide guidance on an issue where multiple new 2022 RDS servers running Office 2021 LTSC are experiencing intermittent license deactivation? Despite successful activation with a RETAIL(MAK) key via the ospp.vbs tool, they sporadically revert to an unlicensed VOLUME_KMSCLIENT state, prompting users with an “Office is not activated” warning. Reactivation temporarily resolves the issue, but it recurs without apparent cause. The ospp.vbs /dstatus command indicates a successful license status post-reactivation, yet the problem persists. Notably, an application log event coincides with each deactivation instance. The environment precludes the use of Office 365 due to generic restricted logins for medical purposes without M365 accounts. Any insights or solutions to prevent these random deactivations would be greatly appreciated.

Answer:

System administrators managing new 2022 Remote Desktop Services (RDS) servers with Office 2021 Long Term Servicing Channel (LTSC) are encountering a perplexing issue: licenses are randomly deactivating. Despite successful activations with a Retail Multiple Activation Key (MAK) using the `ospp.vbs` tool, the servers revert to an unlicensed state, indicated by the VOLUME_KMSCLIENT channel. This results in users receiving an “Office is not activated” warning when attempting to use Office applications.

The Symptoms:

The `ospp.vbs /dstatus` command shows that the license status is normal after reactivation, but the problem unpredictably recurs. An event in the application log, specifically an Event ID 1016 from the Microsoft-Windows-Security-SPP source, is logged each time Office loses its activation.

The Environment:

The affected environment is unique in that it uses generic restricted logins for medical purposes, without individual Microsoft 365 (M365) accounts, ruling out the use of user-licensed Office 365 as a solution.

Possible Causes and Solutions:

1.

Conflicting KMS Configuration:

The presence of a VOLUME_KMSCLIENT configuration suggests that there might be a residual Key Management Service (KMS) setup that conflicts with the MAK activation. To resolve this, check for any Group Policy Objects (GPOs) or scripts that might be inadvertently setting KMS options and remove them.

2.

Scheduled Tasks:

Investigate any scheduled tasks that might be running the `ospp.vbs` script with parameters that could trigger a switch to KMS client mode.

3.

Network Issues:

Ensure that the servers have a stable connection to the activation servers. Network disruptions could cause the servers to attempt KMS activation, which fails due to the lack of a KMS infrastructure.

4.

License State Scripts:

Implement a script that regularly checks the license state and automatically attempts reactivation if it detects an unlicensed state. This can serve as a temporary workaround while investigating the root cause.

5.

Contact Microsoft Support:

Since this issue involves a RETAIL(MAK) key and a volume license channel, reaching out to Microsoft Support for guidance tailored to your specific environment and licensing setup would be advisable.

6.

Office Deployment Tool (ODT):

Use the Office Deployment Tool to explicitly define the licensing channel and prevent it from defaulting to KMS client mode.

7.

Registry Tweaks:

Examine the registry for any entries related to KMS activation and remove them. Be cautious with registry edits and ensure you have backups before making changes.

Conclusion:

Intermittent license deactivation issues can be disruptive and challenging to diagnose. A systematic approach to eliminating potential causes, combined with vigilant monitoring, can help identify the underlying problem. In environments where traditional solutions are not applicable, creativity and persistence in troubleshooting are key to finding a resolution. Remember, when dealing with licensing issues, always ensure compliance with Microsoft’s licensing terms and conditions.