Troubleshooting cloud licensing

1. You are here:
2. Troubleshooting cloud licensing

---

Scenario

Customer was opted into cloud licensing because of a bug and their instance activated cloud licensing, an entity change happened and the new subscription was not on cloud licensing

Troubleshooting workflow

1. Determine whether the customer shoud be on cloud licensing
2. If no, proceed with:
   1. Removing the current cloud license by asking the customer to run these commands via rails console: l = License.find 123 and then l.destroy. You need to provide the license number for the first command. You can find this number in the URL of the cloud license in the customersdot license menu (example: https://customers.gitlab.com/admin/license/123123123)
   2. Once the license has been removed, the customer should have the ability to upload a standard license file on their instance.
3. If yes, proceed with:
   1. Switching the new subscription to cloud license features
   2. Removing the current cloud license by asking the customer to run these commands via rails console: l = License.find 123 and then l.destroy. You need to provide the license number for the first command. You can find this number in the URL of the cloud license in the customersdot license menu (example: https://customers.gitlab.com/admin/license/123123123)
   3. Once the license has been removed, the customer should be able to input the new activation code that was generated and emailed to them when you switched the subscription to cloud features.
   4. See example ticket where customer did want to be on cloud licensing

How to switch a subscription to cloud license features

1. Go to the customer's Zuora Subscriptions tab in customersdot (URL example: https://customers.gitlab.com/admin/customer/123123/zuora_subscriptions)
2. Tick the relevant feature boxes. DO NOT tick the Cloud Licensing checkbox. Click the Update button.
3. Click on the cloud icon next to the update button to generate an activation code for the subscription and email it to the customer.
4. Check that a code has been generated by viewing the Cloud Activations tab. Ensure that the code was generated for the correct subscription.
5. Impersonate the customer's portal account to ensure that the activation code is available for the subscription.
6. Once the customer has used the activation code on their instance, a cloud license should have been generated (check the licenses section) and the Cloud Licensing checkbox from step 2 should now be checked.

General Tips

1. You can resend an activation code via email by clicking on the envelope button on the customer's Cloud Activations tab.

Tracking the impact of Strict Cloud Licensing on customers

As part of embracing the GitLab value of iteration, we plan on monitoring the impact that Strict Cloud Licensing will have on the GitLab customer base. With this in mind, moving forward we request that L&R support engineers add the applicable tags listed below to every Zendesk ticket whenever a customer contacts support requesting an offline/legacy license file.

Tag	Reason
cloud-could-selfserve	Customer has access to Customer Portal and could have self-served, for example customers who have an EoA, multi-year or a ramp-up subscription
cloud-could-not-selfserve	Customer does not have access to the Customer Portal and therefore support had to provide a legacy/offline license file
cloud-pre-14.1	Customer requires legacy/offline license because they are not able to upgrade to 14.1+
cloud-airgapped	Customer needs legacy/offline license because they must keep their instance offline