Why Syntax Errors in Edge SWG (ex ProxySG) Exception Pages Can Break UPE Sync
Article ID: 436679
Updated On:
Products
Issue/Introduction
When a customer attempts to push policy from an Edge SWG to a Cloud SWG using UPE within the Management Center, the operation fails. The error message received indicates an inability to create a new exception form, specifically citing: "Could not create new exception form: exception. User-defined.my_exception’ tenant xxxx."
When the push fails due to an exception page error, the Cloud SWG rejects the configuration bundle. Ordinarily, you would simply fix the code and push again. However, a specific failure state occurs where:
- The Edge SWG marks the policy as "In-Transition."
- The Cloud SWG API returns a generic 400 Bad Request or a validation timeout.
- Subsequent attempts to modify or delete the offending exception page result in a Management Console hang or an "Entry in Use" error.
In this state, the database synchronization between the local CPL engine and the UPE export module becomes de-synchronized. The Edge SWG "thinks" the broken code is active and locked, preventing any edits that would fix the very error causing the lock.
Cause
When you use UPE, the Edge SWG packages its configuration—including Visual Policy Manager (VPM) tables, Content Policy Language (CPL), and Exception Pages—into a bundle for the Cloud SWG to ingest.
The Cloud SWG's validation engine is significantly more rigid than the local Edge SWG parser. While a local appliance might ignore a minor HTML tag mismatch or a stray character in an exception page, the UPE synchronization process treats these as "Fatal Validation Errors."
Common Syntax Culprits:
- Unclosed Tags: Failing to close a $(exception.helptext) or custom <div>.
- Illegal Characters: Using reserved characters or incorrect encoding within the HTML body.
- Corrupted Substitutions: Mis-typing Edge SWG variables (e.g., using $(user.nam) instead of $(user.name)).
Resolution
While technical support can sometimes intervene via the Command Line Interface (CLI) to manually prune the configuration (using conf t and exceptions sub-modes), a deep corruption in the UPE state machine often makes the appliance unresponsive to these changes.
The Factory Reset becomes necessary because:
- Policy Locking: The UPE module may lock the policy database, preventing the deletion of the corrupted exception page.
- Validation Loops: The appliance continues to attempt to validate the broken HTML against the Cloud SWG schema every time a change is initiated.
- Database Purge: A factory reset is the only way to completely wipe the local management database and the failed UPE state, allowing for a clean re-enrollment.
Best Practices to Avoid the Reset
To prevent a minor typo from escalating into a full day of appliance re-configuration, follow these safety protocols:
Step | Action | Why? |
1 | External Validation | Draft your HTML exception pages in a dedicated code editor with syntax highlighting before pasting them into the ProxySG. |
2 | Backup Before Push | Always take a configuration archive (expanded-config) before initiating a UPE sync after modifying exceptions. |
3 | Staged Deployment | Create a "Test" exception page first. If it pushes successfully, apply the logic to your production pages. |
4 | Use Default Pages | Whenever possible, use the Cloud SWG’s native error pages rather than pushing custom HTML from the on-premise ProxySG. |
Additional Information
Feedback
