Manage Expired Services Through Policies

An Expiry Policy allows you to identify and control services based on their expiry date, to ensure that you're not paying for unused services. For example, you can automatically decommission expired services.

Set up steps

The steps to setting up an Expiry Policy are:

1. Set expiry information for existing services, as explained in Manage Service Expirations.
2. Create expiry groups. Expiry groups are used as targets for the Expiry Policy.

   If you don't create additional expiry groups, the Expiry Policy automatically applies to the default group, which contains all services.

3. Assign existing services to the expiry groups.
4. Set the expiry group for new services.
5. Configure the Expiry Policy for each expiry group.
6. Configure who receives email alerts about service expiry.

How an Expiry Policy affects templates

An Expiry Policy changes the expiry state for templates, but policy actions (for example, deletion) aren't performed for templates.

Create an expiry group for templates and ensure that this expiry group isn't affected by the Expiry Policy. In this way, when you convert a template to a VM to apply a patch, for example, the VM won't be deleted by the Expiry Policy.

If you attempt to deploy a VM from a template in the Expired state, the deployment will fail.

Create expiry groups

You can create your own expiry groups, so that you can configure different expiry policy actions for different sets of services. All services are automatically a member of the Default Expiry Group until you reassign them to another group.

1. On the Expiry Groups page, click Add.
2. In the Add Group dialog, enter a name for the expiry group.

   Give the group a descriptive name so that it makes sense to service owners viewing the service's Expiry Group property, and so that administrators can easily set the proper group when required.

3. In the Description field, enter details about the expiry group.
4. Click OK.

Add existing services to expiry groups

In Commander, services are automatically assigned to a default expiry group. You can easily add one or more services to your own predefined expiry group. Expiry groups apply to all service types — VMs, virtual services, application stacks, databases, load balancers and auto scaling groups.

If you move a service from one infrastructure element to another, any group name and any expiry information you assigned to that service remain with it, so check the service and make any changes that are appropriate.

All VMs in a virtual service should belong to the same expiry group.

1. Select the service from the tree or the Virtual Machines tab.
2. Right-click and choose Lifecycle Management (or Policy Enforcement) > Set Expiry Group.
3. Select the appropriate expiry group and click OK.

   The group name is displayed on the Infrastructure pane of the service's Summary tab.

Set expiry groups for new services

There are three ways to set the expiry group when a service is deployed:

• the service catalog
• completion workflows
• policies

To learn which method is best for your situation, see Guidance for assigning groups to new services.

Configure Expiry Policies

1. On the Configuration page, click Add.
2. On the Choose a Policy page of the Policy configuration wizard, select Expiry from the list of policies.
3. On the Policy Name/Description page, enter a name, for example, "Expiry Policy for Production", and an optional description.
4. On the Choose a Target page, select the expiry group from the list of group names.
• If you want the policy to run on all services that haven't been assigned to another expiry group, select Default Expiry Group.
• If required, expand the Infrastructure tree in the dialog and select the infrastructure element to which you want to apply this Expiry Policy.
5. On the Configure the Policy page, to enable the policy as soon as you've completed this wizard, make sure Enabled is checked.
6. Specify actions to take place before, on, or after the expiry date, and specify how long before the expiry date, or how long after the expiry date, these actions should occur.
7. From each of the Take Action menus, select from the options. Note that not all actions are valid for all service types.

   Option:	Result:
   Quarantine	The VM is quarantined. Note: If you include this action in a policy targeting services in a cloud account other than vCenter, the action will fail.
   Suspend	The VM is suspended (saved in its current state). Not supported for VMs in public cloud accounts. If you include this action in a policy targeting services in a public cloud account, the action will fail.
   Stop	The Guest OS is shut down. You can set the service to stop on all three instances. However, the first instance that you choose is the one on which the service stops.
   Remove from Inventory	The VM is removed from inventory. Note that the file remains in the datastore. When all VMs are deleted from a virtual service through a policy action (that is, when VMs are deleted by a policy action or by a command workflow attached to the Expiry Policy), the empty virtual service isn't automatically deleted unless it too is targeted by policy. If you include this action in a policy targeting services in a cloud account other than vCenter, the action will fail.
   Set State as EOL	The End of Life option for the VM and its associated files is set to True. If an End of Life Policy is enabled for the VM, the End of Life policy will be triggered. Affects only VMs and virtual services.
   Delete from Disk	The service and its associated files are deleted permanently from disk. No other options can be carried out on this service after it's deleted. When you delete a VM or template from the disk, the files are permanently deleted. They can't be recovered unless you have a backup copy. When all VMs are deleted from a virtual service through a policy action (that is, when VMs are deleted by a policy action or by a command workflow attached to the Expiry Policy), the empty virtual service isn't automatically deleted unless it too is targeted by policy.
   Run [Workflow]	Existing command workflows appear for selection, organized by target type. If the policy is triggered, the selected workflow is run. You must choose a workflow with a target type that matches the target of the policy; otherwise, the workflow will fail. For example, if the selected workflow's target type is "VM", the workflow will fail if the policy targets a database. A workflow with a target type of "Any Inventory Type" can be run on all service types.

8. Click Add Workflow to set up a new command workflow.
9. Specify a number of days before the expiry date (default: 7) and after the expiry date (default: 30) when the selected action will be triggered.

   A service has the Expired state between the expiry date and the last trigger date you configure. A service has the Post Expiry state if it continues to exist after the last trigger date. For example, if you keep the default setting of 30 days after the expiry date, a service that continues to exist after 30 days has the Post Expiry state.

10. On the Expiry Extension page, you can allow primary owners to extend the expiry date of a service.

    When you enable this feature, if a service has a primary owner with an email address, the expiry email that the primary owner receives will contain an Extend Expiry Date section, with a link:

    

    As soon as the user clicks the link in the email, the expiry date is automatically extended by the number of days you specify in this step:

    

    Another way to allow service expiry extension is through a change request. If you add the Expiry Date element to the Service Change Request form, users can submit a change request to extend the expiry date. The benefit of change requests is that you can configure an approval process. For more information, see Change Request Form Elements.

    When you enable expiry extension:

    • Specify the number of days that the expiry date will be extended. The default is 90.
    • Specify the maximum number of extensions that the user is allowed. If you don't specify a value, the user will be able to extend the expiry date an unlimited number of times. The default is unlimited.
    • If you want to change the service's approval state when the expiry date is extended, select Set to unapproved from the Approval state will be drop-down menu. By default, the approval state will be Unchanged.

      You can view and reset the number of expiry extensions remaining for a service. See Managing Service Expiry.

11. On the Notifications page:
    1. Select the owners to whom notification emails should be sent when the Expiry policy is triggered.

       Owners receive emails about the Expiry Policy only if their email address has been configured. For more information about setting up owners, see Resource and Service Ownership.

       Configure service owners to receive expiry alerts by email for their services.

    2. Customize the email subject and body.

       In any text field that supports variables, click  to open the script editor and select variables for the current context.

12. On the Summary page, if you've enabled the policy and as a result, any services will be immediately affected by it, Commander displays the number of affected services.

    To see what services are affected by the policy actions you selected, click Review, then click OK to return to the summary.

13. Click Finish.

Delete expiry groups

To delete an expiry group, select the expiry group you want to delete, click Delete, and confirm the deletion.

When you delete an expiry group, all services in the group are automatically reassigned to the Default Expiry group. Any policy actions that are set for the default group affect the services in that group. Before deleting an expiry group, check to see what policy actions you've assigned to the Default Expiry group.