Uninstall
Removing a Citrix SecurSpaces™ Community Edition deployment deletes everything it stored. Nothing is backed up, and nothing can be recovered afterwards.
The order on this page matters: delete the DNS records first, then the managed application. Doing it the other way round can let someone else take over your hostname.
What you lose
| Backed up | |
|---|---|
| The platform database: organizations, projects, users, settings and activity | No |
| Workspace files | No |
| Images built inside a workspace | No |
The platform configuration export and the compliance events export contain neither the database nor any workspace files.
Before you start, make sure developers have pushed their work to a Git remote or copied it elsewhere, and take any exports you need. Once the DNS records are deleted, the portal and the exports are no longer reachable by name.
Record the deployment details
The details you need are stored on the managed application, which you are about to delete. Save them first:
az login
az account set --subscription <subscription-id>
az managedapp list --query "[].{name:name, resourceGroup:resourceGroup, plan:plan.product}" -o table
APP_RG=<resource-group>; APP_NAME=<name>
az managedapp show -g "$APP_RG" -n "$APP_NAME" -o json > securspaces-deployment.json
If the subscription has several managed applications, use the
plan column to identify this one.
Then record the managed resource group and the AKS node resource group, which begins with
MC_. The node resource group holds the load balancer, the public IP address and the disks:
MRG=<last segment of managedResourceGroupId in securspaces-deployment.json>
CLUSTER=$(az aks list -g "$MRG" --query "[0].name" -o tsv)
NODE_RG=$(az aks show -g "$MRG" -n "$CLUSTER" --query nodeResourceGroup -o tsv)
echo "MRG=$MRG CLUSTER=$CLUSTER NODE_RG=$NODE_RG" | tee securspaces-deployment.txt
None of the values can be empty. Keep both files outside the subscription.
Delete the DNS records
Delete the records you created after the deployment, in your own zone:
-
Owner path: the
NSrecord set named after your hostname. -
Contributor path: the two
CNAMErecords,<hostname>and*.proxy.<hostname>, and any leftover_acme-challengeTXTrecords.
Why first: your records point at Azure resources whose names are released when the deployment is deleted. While your records still point at them, anyone who claims those names can serve content under your hostname.
Do not change anything inside the cluster before this step. Removing the load balancer Service, for example, releases its DNS name while your records still point at it.
Confirm the deletion at the zone's own name servers. A recursive lookup can keep returning the old answer for the record's TTL, which is expected:
dig +short NS apps.example.com
dig +short +norecurse @<one-of-those-name-servers> securspaces.apps.example.com NS
dig +short +norecurse @<one-of-those-name-servers> securspaces.apps.example.com CNAME
No output means the record is gone.
Delete the managed application
az managedapp delete -g "$APP_RG" -n "$APP_NAME"
The command runs until Azure finishes and does not accept
--yes or --no-wait. Delete the application, not the resource groups beneath it: they are removed with the application.
If the command fails, run it again. If it fails a second time, check for a lock and for the reason in the activity log:
az lock list -g "$APP_RG" -o table
az monitor activity-log list -g "$APP_RG" --status Failed -o table
Confirm that everything is gone
az group exists -n "$MRG"
az group exists -n "$NODE_RG"
Both must print
false. A resource group that still exists is still billed.
What is not affected
-
Your license entitlement. It is registered to your portal hostname and is not released. Whether a new deployment on the same hostname receives a Community Edition license again is not guaranteed. Ask in the SecurSpaces community forum before you plan a rebuild.
-
Your certificate and private key, on the Contributor path. Revoking the certificate is a task for your certificate authority.