Overview
On Azure App Service, DNN/Evoq may intermittently register an unexpected new “Web Server” entry in Persona Bar → Settings → About (for example, the licensed server changes from <server_id_old> to <server_id_new>). When this happens, licensing can appear inactive on the newly-detected server entry until you manually re-activate.
A common mitigation is to configure a fixed ASP.NET <machineKey> in web.config. If the site then fails with “Padding is invalid and cannot be removed.” (often referencing DotNetNuke.Security.FIPSCompliant.DecryptAES / ProApplication.CheckLicense), clearing the stored licensing hash and re-activating the license typically resolves the issue.
Applies to: Azure-hosted Evoq Content (example reported on Evoq Content v. 09.10.04). This is not a product defect fix tied to a specific DNN version; it is a hosting/platform-driven behavior with a configuration-based mitigation.
Contents
- Symptoms
- Why this happens (root cause)
- Recommended mitigation: Use a fixed ASP.NET machineKey
- Fix: “Padding is invalid and cannot be removed.” after changing machineKey
- Verification
- Frequently Asked Questions
Solution
Symptoms
- DNN/Evoq intermittently registers a new “Web Server” entry under Persona Bar → Settings → About (Web Servers / License area).
- When the new server entry becomes active, the license is not active on that new entry until you re-activate.
- After setting a fixed
<machineKey>inweb.config, the site may throw:
Exception: “Padding is invalid and cannot be removed.”
The stack trace often includes entries similar to:
DotNetNuke.Security.FIPSCompliant.DecryptAES(...)DotNetNuke.Professional.Application.ProApplication.CheckLicense()ProApplication.get_HasActiveLicenseOrIsTrial()
Why this happens (root cause)
Azure App Service can rotate the underlying worker instance due to platform maintenance/health operations (even when scaling is manual and instance count is 1). This can change environment characteristics used by DNN to identify a server (the server “fingerprint”), leading DNN to treat the runtime as a new server and require license re-activation.
There is no DNN setting that fully prevents Azure worker rotation or guarantees that a new server entry will never appear. The practical approach is to stabilize key fingerprint inputs and use a repeatable recovery procedure when platform events occur.
Recommended mitigation: Use a fixed ASP.NET machineKey
A fixed <machineKey> is not the DNN license key. It is an ASP.NET setting used for encryption/hashing (for example, auth cookies and protected data) and can help keep environment behavior consistent across deployments and slots.
1) Plan and prerequisites
- Schedule a maintenance window. Changing
<machineKey>logs users out and can invalidate existing cookies. - Back up the database and take a copy of
web.config.
2) Generate strong keys (example: PowerShell on Windows)
Generate:
- 64-byte validation key (128 hex characters) for
HMACSHA256 - 32-byte decryption key (64 hex characters) for
AES
$valBytes = New-Object byte[] 64
[System.Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($valBytes)
$decBytes = New-Object byte[] 32
[System.Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($decBytes)
$validationKey = ($valBytes | ForEach-Object { $_.ToString('X2') }) -join ''
$decryptionKey = ($decBytes | ForEach-Object { $_.ToString('X2') }) -join ''
$validationKey
$decryptionKey
3) Add the machineKey to web.config
Place the following under <system.web>:
<machineKey
validationKey="<validation_key_hex>"
decryptionKey="<decryption_key_hex>"
validation="HMACSHA256"
decryption="AES"
compatibilityMode="Framework45" />
Important:
- Keep the
<machineKey>consistent for the same environment (for example, staging) across deployments and any deployment slots used for that same app. - Ensure build/deploy transforms do not overwrite or regenerate the
<machineKey>.
4) Azure operational settings that help reduce disruption
- Keep Always On enabled.
- Avoid slot swaps/redeploys/restores during critical windows when possible.
- If you intentionally move/replace an instance, deactivate the license on the old server entry before activating on the new one.
Fix: “Padding is invalid and cannot be removed.” after changing machineKey
If the site throws “Padding is invalid and cannot be removed.” immediately after applying the fixed <machineKey>, the stored licensing hash/encrypted data may still be tied to the previous <machineKey> and can no longer be decrypted under the new key.
Step-by-step remediation
- Do not regenerate the machineKey again. Keep the fixed one in place.
- Run the following SQL against the DNN site database:
DELETE FROM HostSettings WHERE SettingName = 'hash';
- Restart the application (Azure App Service restart).
- Re-activate the license in Persona Bar → Settings → About (Licensing section).
If still failing
As a secondary cleanup step, clear stored Pro license data, then restart and re-activate again:
DELETE FROM DNNPRO_License;
Verification
- Confirm the site loads and the exception “Padding is invalid and cannot be removed.” is gone.
- In Persona Bar → Settings → About:
- Confirm the license shows Activated.
- Confirm the intended server entry is listed/active.
- Monitor over time (especially after restarts/platform events) to confirm reduced frequency of “new server” entries and reduced need for manual re-activation.
Frequently Asked Questions
- 1. How can I tell this is the same issue?
-
You see DNN/Evoq create a new Web Server entry in Persona Bar → Settings → About (for example, it changes from
<server_id_old>to<server_id_new>), and licensing is not active on the new entry until you re-activate. If you changed<machineKey>and the site fails, the exact error is: “Padding is invalid and cannot be removed.” - 2. Is there a DNN/Evoq setting to prevent new server entries from being created?
-
No. On Azure App Service, underlying worker rotation can change the server “fingerprint.” The practical mitigation is stabilizing configuration inputs (notably a fixed ASP.NET
<machineKey>) and minimizing disruptive operations (slot swaps/redeploys/restores) during critical windows. - 3. Is the ASP.NET machineKey the same as the DNN license key?
-
No. The
<machineKey>is an ASP.NET encryption/hashing configuration inweb.config. The DNN license key is separate and is activated in Persona Bar → Settings → About. - 4. After adding a fixed machineKey, I get “Padding is invalid and cannot be removed.” What do I do?
-
Keep the fixed
<machineKey>in place, then clear the old licensing hash and re-activate:- SQL:
DELETE FROM HostSettings WHERE SettingName = 'hash'; - Restart the app
- Re-activate in Persona Bar → Settings → About
If it persists, run:
DELETE FROM DNNPRO_License;then restart and re-activate. - SQL:
- 5. How do I verify the change worked?
-
Confirm (1) the site loads without the padding/decrypt exception, (2) Persona Bar → Settings → About shows the license as Activated, and (3) after restarts/platform events you no longer see frequent new server entries requiring manual license moves.
- 6. What should I do during a blackout/freeze window when I can’t change web.config?
-
Avoid slot swaps/redeploys/restores/restarts where possible and keep Always On enabled. If Azure rotation still causes a new server entry, re-activate the license on the new server entry. Plan the fixed
<machineKey>change for a maintenance window after the blackout ends.
Priyanka Bhotika
Comments