// removed jquery ui css and js

Policy Management

About Policies 

A policy causes the CloudCenter platform to perform configured activities when certain events or conditions occur. For example, a policy could cause the CloudCenter platform to send an email alert message to a designated administrator if a cloud goes down. You use the Policies window to configure the following types of policies:

  • Event Policy– Causes the CloudCenter platform to send an email message, invoke a web service, execute a command or script, or perform any number and combination of these activities when a designated event occurs

  • Scaling Policy – Causes the CloudCenter platform to increase or decrease VM resources for each application deployment tier that is associated with the policy when one or more designated conditions occur

  • Aging Policy – Causes the CloudCenter platform to suspend and optionally terminate each application deployment that is associated with the policy after the deployment has been running for a designated period of time term

  • Suspension Policy – Specifies a schedule for when a deployment should be in Running stat

Custom Actions are now defined in a new Actions Library tab.

Event Policies

An event policy causes the CloudCenter platform to perform one or more configured activities when a designated event occurs for the designated resource. These activities can be:

  • Email–Sends an email message with the designated subject and body text to the designated recipient or recipients

  • Invoke a web service–Executes the designated web service request

  • Execute a command–Executes the designated command or script on an application VM

To manage event policies, click Policies in the CCM UI main menu and then click the Event link to display the Events Policies page.

The Events Policies page lists configured event policies and lets you perform the following tasks:

TaskDescription
Add a new event policy.

Click the New Event Policy link.

See Configuring an Event Policy for details.

View configurations for an existing event policy.

Click the policy name in the Name column.

The View page for the policy displays. See Configuring an Event Policy for details.

Enable or disable an event policy.

Click the ON/OFF toggle button in the Enable Column for the policy.

When a policy is enabled, it executes when the configured event occurs.

Set permissions for an event policy.

Choose Share from the dropdown list in the Actions column for the policy.

See Policy Permissions for details.

Update configurations for an existing event policy.

Choose Edit from the dropdown list in the Actions column for the policy.

The Edit page for the policy displays. See Configuring an Event Policy for a description of the fields that you can update. If you make updates, click the Save button on the Edit page to save your changes.

Delete an event policy.

Choose Delete from the dropdown list in the Actions column for the policy.

See a history of event policy executions.

Click the Execution History link to the right of the list of policies.

The User Defined Policy Executions page displays. This page lists in reverse chronological order each policy that has executed. For each policy, the page displays the local date and time of execution, the name of the policy, and the name of the resource against which the policy was enforced. You can see details about a policy or resource by clicking the name of the policy or entity.

Configuring an Event Policy

When you add an event policy, you create a new policy based on configuration settings that you make. To add an event policy, click New Event Policy on the Event Policy page and then configure the settings that the following table describes. Click the Save button after you complete the configuration.

The policy must be enabled before it can execute.

SettingDescription
Name fieldEnter a brief and unique descriptive name for the policy.
Description fieldOptionally enter a brief description of the policy
Execute For dropdown listChoose the resource against which the policy is enforced with the configured event occurs
On Event dropdown listChoose the event that, when it affects the configured resource, causes the policy to execute. See eventName for additional details.
Action Type dropdown list

Enter information in the fields that appear for the action type that you choose as follows. When entering information, you can include variables that are described in the Available Variables section at the top right of the page to customize an email message, web service request, command, or script with dynamic information.

  • Email action type – Enter information in the To, Bcc, Subject, and Body fields that appear, as appropriate.
  • Invoke a web service action type – Enter information in the Web Service URLHttp Request TypeContent Type, Command Params, and Body fields that appear, as appropriate. See Using Parameters > Parameter Type for additional context.
  • Execute a Command action type – Enter the desired command or script in the command/script field.

When you specify the script or command action type globally, these global policies are executed on all jobs/deployments. You can also configure these global policies to be executed on specific state changes – for example, if a job/deployment goes to a Resumed or Deployed state. On reaching those states, all the VMs for this job/deployment are executed.

  • Launch a new deployment action type – Set the cloud-specific default in the destination deployment environment for the cloud burst configuration.

    Be aware that the instance types and network defaults are used from the Deployment Environment in the destination job when using a cloud bursting policy. This action type allows other choices as well, however, a cloud bursting policy is only applicable if you use the following settings:

    • Execute for = Application Deployment:
    • On Event = Maximum cluster size limit 
    • Action Type = Launch a new deployment

    If you configure multiple instance types in the destination Deployment Environment Defaults, the CloudCenter platform selects the first instance type.

Select the Auto Enable for shared users check box

Check this check box to automatically enable this policy for all shared users and sub-tenants.


If you share this policy with another user, the shared user can only turn off this policy if assigned manage privileges (see Policy Permissions).

When you select the Auto Enable check box, you also have the option to select the Restrict users from disabling this Policy check box to determine if this policy must also be enforced for all shared users and sub-tenants.

Event Policy Guidelines

Do not use your system admin (see People > System Administrator) credentials to change the user's event policy. This change adversely affects the CloudCenter platform and does not notify the user.

Adhere to the following event policy guidelines:

  • If you use a group email and you don't want to disable all email notifications for this policy, all users who enabled that policy in the CloudCenter platform must disable it for the group to no longer receive emails.

  • If you use a token (for example, %myemail%) and this token is replaced with a user email, then the user with this email must disable the policy in the CloudCenter platform.

  • If you create custom email policies, only the default email policy is triggered.

Scaling Policies

A scaling policy causes the CloudCenter platform to increase or decrease VMs for each application deployment tier that is associated with the policy. You can configure the VM scaling to occur once or daily, or when one or more designated conditions relating to system metrics such as CPU, memory, or network usage occur at a specified polling interval. 

VM Metrics Frequency

The frequency of updates for VM metrics depends on the polling interval configured in your scaling policy. Two schedulers are used for each VM:

  • The first scheduler fetches the metrics from the operating system (for example, CPU, memory, and so forth at a polling interval frequency defined by user. If the user defines a polling interval at 15-second intervals CloudCenter provides the metrics from the OS at 5-second intervals.

  • The second scheduler calculates the average of all values provided by the first scheduler and uploads the metrics to the CCO. This upload to the CCO occurs at the user-defined, polling interval frequency. The CCO does not poll each VM.

CPU Calculation

The CPU threshold is calculated based on the first VM – assuming that all balanced servers have a similar usage. Once the scaling (up or down) is executed, the CloudCenter platform waits for the breach period to re-evaluate the policy.

You can associate an application deployment tier with a scaling policy by associating system tags with the application deployment or deployment tier (if corresponding system tag matching rules are configured for the policy and rules-based governance  is enabled) or by associating the application deployment with the name of the policy to use (if rules-governance is disabled). See Governance Rules for details.

You can add a scaling policy to a deployment when you launch the deployment. If Governance Rules are turned on you create a system tag, associate the tag to a scaling policy and define rules when you create the policy, and then associate the tags with an application deployment tier.

You can add a scaling policy to a deployment when you launch the deployment or after the deployment is complete. If Governance Rules are turned on, you can add a scaling policy to a deployment at launch time by using tags. To do so, you create a system tag, associate the tag to an aging policy and define rules when you create the policy, and then associate the tags with an application deployment tier.

To manage scaling policies, click Policies in the CCM UI main menu and then click the Scaling link to display the Scaling Policies page.

The Scaling Policies page lists configured scaling policies and lets you perform the following tasks:

TaskDescription
Add a new scaling policy.

Click the New Scaling Policy link.

See Configuring a Scaling Policy for details.

Change the priority for a scaling policy.

Available only if Governance Rules are turned on. Choose a value from the PRIORITY drop-down menu to assign a unique priority to the policy. A value of 1 represents the highest priority.

When you associate system tags with an application deployment tier, the system evaluates all rules that are mapped to the system tags to choose the scaling policy. If more than one scaling policy is available, the rule evaluation chooses the scaling policy with the highest priority.

Only policies that the tenant administrator creates are used in governance mode and only the tenant administrator can change the priority of these policies. Standard users and co-admin users do not see policies that they created before governance rules were turned on because such a system does not permit use of these policies. Standard users and co-admin users see policies that the tenant administrator creates if the tenant administrator has shared these policies with these users.

View or update configurations for an existing scaling policy.

Choose Edit from the dropdown list in the Actions column for the policy.

The Edit page for the policy displays. See Configuring a Scaling Policy for a description of the fields that you can update. If you make updates, click the Save button on the Edit page to save your changes.

Set permissions for a scaling policy.

Choose Share from the dropdown list in the Actions column for the policy.

See Policy Permissions for details.

Add tag matching rules to a scaling policy.

Available only if Governance Rules are turned on. Choose Associate Rules from the dropdown list in the Actions column for the policy.

See System Tags for details.

Delete a scaling policy.

Choose Delete from the dropdown list in the Actions column for the policy.

Configuring a Scaling Policy

When you add a scaling policy, you create a new policy based on configuration settings that you make. To add a scaling policy, click New Scaling Policy on the Scaling Policy page and then configure the settings that the following table describes. Click the Save button after you complete the configuration.

SettingDescription
Name fieldEnter a brief and unique descriptive name for the policy
Description fieldOptionally enter a brief description of the policy.
Type of scaling radio button

Choose Scheduled Scaling or Elastic Scaling.

Scheduled scaling causes the policy to increase and then decrease the number of VMs to the values that you designate according to the schedule that you designate. The schedule can cause the scaling cycle to occur once at the designated dates and times, or it can cause scaling cycle to occur every day at designated times.

Elastic scaling causes the policy to increase or decrease the number of VMs as needed based on configured conditions that the system detects at a specified polling interval and breach period.

The breach period refers to the period of time that the CloudCenter platform waits after one scale up or scale down action, before stabilizing the load.

Ideally, the breach period should be greater than (or equal to) the time taken by the scaling operation to launch a VM.

For example, if the time taken to:

  • Launch and configure a node = 5 to 7 minutes
  • Polling interval = 30 seconds
  • Breach period should be = 8 to 10 minutes
Add Scaling Schedule fieldsAppears if you choose scheduled scaling. Configure how often this policy runs, when it runs, and the number of VMs to which to increase and decrease.
Poling Interval fields

Appear if you choose elastic scaling. Choose a time length in the left field and choose a time unit in the right field. The system polls system metrics at this interval to determine if the conditions that this policy requires to execute are met.

Poling Interval

For example, if you configure a 6-second polling interval, your metrics collected in this time is divided by 3 to obtain the average value. The average value is sent to the CCO at the polling interval frequency. So in this example, the CPU data is collected every 2 seconds, and automatically sent to the CCO at 6-second intervals.

Breach Period fields

Appear if you choose elastic scaling. Choose a time length in the left field and choose a time unit in the right field. If the policy executes, it will not execute again for this period of time. In this way, the system can stabilize after a condition occurs without the policy continually adjusting the system.

Breach Period

If any VM meets the specified criteria, CloudCenter executes the policy. In a load balanced cluster if one VM's metrics crosses the threshold, it is most likely that the other VM will reach that threshold. If CloudCenter detects any VM crossing the threshold, the policy is executed and the breach period is set. Once the breach period is set, the other VMs cannot execute the policy.

Scale out condition fieldsAppear if you choose elastic scaling and cause the policy to increase the number VMs per the designated rule or rules. The Scale in condition fields cause the policy to decrease the number VMs per the designated rule or rules.
For each condition, you configure one or more rule sets. Within each rule set, you configure one or more rules. 
  • From the Match dropdown list for each rule set: 
    • Choose All to cause the scaling to execute when the situations that are defined by all rules in the rule set occur
      or 
    • Choose Any to cause the scaling to execute when a situation that is defined by any rule in the set occurs.
  • To add a rule set, click the ... icon.
  • To add a rule to a rule set, click the + icon within the rule set.
  • To remove a rule, click the Trash Can icon under the rule, and then click the yes link.

Aging Policies

An aging policy causes the CloudCenter platform to suspend and optionally terminate each application deployment that is associated with the policy after the application deployment has been running for a designated period or reaches a designated deployment cost.

An aging policy and the prevent termination feature cannot be used simultaneously for a deployment because both items control the terminate and suspend behavior of VMs that are mapped to a deployment.

The Prevent Termination feature is only applicable to N-tier jobs.

You can configure a grace period for an aging policy, which allows you to keep deployments in suspended state before the automated termination takes place. A grace period is particularly useful when approvals via ServiceNow are set up for extensions. You also can add  extensions to a policy, which allows deployments to keep running as needed.

If an aging policy is configured to terminate a deployment when the time or cost limit is reached, you optionally can configure a grace period, which allows you to keep deployments in suspended state before the automated termination takes place. A grace period is particularly useful if approvals via ServiceNow are set up for extensions. You also can add extensions to a policy, which allows deployments to keep running by adding more time/cost to permit runtime.

An aging policy can include notifications. A notification is an e-mail message to a deployment owner that informs the owner that the deployment is going to terminate or suspend or that a grace period for a deployment is going to expire. You can configure how far in advance of a termination or grace period expiration the system sends the message, and you can send additional messages as reminders.

You can associate an application deployment with an aging policy by associating system tags with the application deployment (if corresponding system tag matching rules are configured for the policy and rules-based governance is enabled)  or by associating the application deployment with the name of the policy to use (if rules-based governance is disabled). See Governance Rules for details.

You can add an aging policy to a deployment when you launch the deployment or after the deployment is complete. If Governance Rules are turned on, you can add an aging policy to a deployment at launch time by using tags. To do so, you create a system tag, associate the tag to an aging policy and define rules when you create the policy, and then associate the tags with an application deployment tier.

You cannot modify duration, extension, or grace period settings for an Aging policy if a deployment is running with the policy enforced. You can modify notification options, which apply to future policy executions. If you need to modify duration, extension, or grace period settings, you can do so only when deployments that use the policy are no longer running or if you first manually remove the policy from all deployments that are using it. Post deployment, if Governance Mode is on, only the tenant administrator can change the aging policy.

The Aging Policy field in the Deploy form differs based on the following choices:


  • Off = A dropdown for selecting an aging policy

  • On = Displays the aging policies associated with tags that are assigned to the deployment

The Deployment Details page contains an Aging Policy dropdown with the following choices:

  • Change Policy lets you replace the current aging policy with another one that you pick from a list. If a policy specifies a time or cost that is less that what has accrued for the deployment, the policy is not available. 

  • Add Policy lets you add one from a list if one is not associated.

  • Remove Policy

To manage aging policies, click Policies in the CCM UI main menu and then click the Aging link to display the Aging Policies page.

The Aging Policies page lists configured aging policies and lets you perform the following tasks:

TaskDescription
Add a new aging policy.

Click the New Aging Policy link.

See Configuring an Aging Policy for details.

Change the priority for an aging policy.

Available only if Governance Rules are turned on. Choose a value from the PRIORITY drop-down menu to assign a unique priority to the policy. A value of 1 represents the highest priority.

When you associate system tags with an application deployment tier, the system evaluates all rules that are mapped to the system tags to choose the aging policy. If more than one aging policy is available, the rule evaluation chooses the aging policy with the highest priority.

Only policies that the tenant administrator creates are used in governance mode and only the tenant administrator can change the priority of these policies. Standard users and co-admin users do not see policies that they created before governance rules were turned on because such a system does not permit use of these policies. Standard users and co-admin users see policies that the tenant administrator creates if the tenant administrator has shared these policies with these users.

Set permissions for an aging policy.

Choose Share from the dropdown list in the Actions column for the policy.

See Policy Permissions for details.

View information about an aging policy.

You can view the following information for each policy:

  • DESCRIPTION–Optional description that was configured for the policy
  • LAST UPDATED–Date and time that the policy was last updated
  • EXTENSIONS–If one or more extensions are configured for the policy, the number of extensions appears, followed by the time length or cost limit of each extension, in parentheses
  • NOTIFY–Indicates whether email notification is configured for the policy
View or update configurations for an existing aging policy.

Choose Edit from the dropdown list in the Actions column for the policy.

The Edit page for the policy displays. See Configuring an Aging Policy for a description of the fields that you can update. If you make updates, click the Save button on the Edit page to save your changes.

Delete an aging policy.Choose Delete from the dropdown list in the Actions column for the policy
Add tag matching rules to an aging policy.

Available only if Governance Rules are turned on. Choose Associate Rules from the dropdown list in the Actions column for the policy.

See System Tags for details.

Enable or disable an aging policy.

Turn on or off the Enable switch for the policy.

When a policy is disabled, future deployments cannot use it. The policy remains in effect for existing deployments.

Configuring an Aging Policy

When you add an aging policy, you create a new policy based on configuration settings that you make. To add an aging policy, click New Aging Policy on the Aging Policy page and then configure the settings that the following table describes. Click the Save button after you complete the configuration.

To edit a numerical value field that contains a single digit, take either of these actions:

  • Change the single digit number to a two digit number, then delete the unneeded digit. For example, if the field contains the number 8 and you want to change that number to 2, type a 2 following the 8 in the field to make the number 82, then move your cursor to the left and delete the 8.

  • Change the single digit number to a two digit number, select the entire number, and then type the new number.

SettingDescription
Age By buttonsClick Time Duration if you want to suspend and optionally terminate an application deployment after it has been running for a designated period, or click Cost Limit if you want to suspend or terminate a deployment when it reaches a designated deployment cost.
Policy Name fieldEnter a brief and unique descriptive name for the policy
Policy Description fieldOptionally enter a brief description of the policy.
Policy Duration fieldAppears if you choose a time duration policy type. Enter the duration as a number of units, such as 15 days.
Policy Cost Limit fieldAppears if you choose a cost limit policy type. Enter the cost amount.
Terminate Deployment after Policy Duration switch

Turn on if you want the deployments that are associated with the policy to terminate when the configured time duration or cost limit is reached.

By default, this switch is turned off and policies suspend but do not terminate when a duration or limit is reached.

Allow a Grace Period before Terminating switch

Appears if you choose to terminate deployments after the configured time duration or cost limit. Turn on this switch if you want to provide a grace period before a deployment is terminated.

A grace period is designated amount of months, days, or hours after configured time duration or cost limit is reached that deployments remain suspended before terminating. Enter the grace period as a number of units, such as 5 days, in the Grace Period fields. For example, if you choose to terminate deployments after 10 days and configure a grace period of 5 days, deployments become suspended when the 10 day duration is reached, remain suspended for 5 days, and then terminate.

Allow Extensions to this Policy switchTurn on if you want to provide the option of extending the time that the policy is in effect beyond the originally configured time duration or cost limit or a grace period
No. of Extensions fieldAppears if you allow extensions for the policy. For a policy that is to terminate a deployment after a designated period, enter duration of each extension as a number of units in the Length of Each Extension field. For a policy that is to terminate a deployment after a designated deployment cost, enter the additional cost that is allowed for each extension in the Cost Limit of Each Extension field. See Extensions for additional context.
Notify Deployment Owner of Policy Expiry switch

Turn on if you want the system to send an email message to a deployment owner notifying the owner that the deployment is going to terminate. In the Notify fields that appear, enter, as a number of units, how long before a deployment terminates the emails should be sent.

For example, you could enter 3 days. If you want to configure multiple messages regarding deployment termination, click Notification Alert and enter the number of units for each additional message. For example, in this way, you can configure the system to send messages 3 days, 2 days, and 1 day before termination. Edit text in the email body field, if needed, and optionally click View Sample E-Mail to see how the email message will appear to recipients.

Notify before Grace Period Ends switch

Turn on if you want the system to send an email message to a deployment owner notifying the owner that a grace period for a deployment is going to expire. In the Notify fields that appear, enter, as a number of units, how long before the grace period expires the emails should be sent. The period that you configure cannot be longer than the configured grace period so that the system does not send messages after the grace period expires.

For example, you could enter 3 days. Edit text in the email body field, if needed, and optionally click View Sample E-Mail to see how the email message will appear to recipients.

Suspension Policies

A suspension policy specifies a schedule for when a deployment should be in Running state. At other times, the deployment is suspended. You can use a suspension policy to put a deployment in Running state every day during a certain time period, or on specific days during a certain time period. For example, you could configure the policy to put a deployment in Running state every day from 8:00 a.m. through 9:00 p.m., or on Mondays, Wednesdays, and Fridays from 10:00 a.m. through 6:00 p.m. You also can specify one or more blackout dates, during which the deployment is suspended all day.

This policy can be useful for conserving resources by taking a deployment out of Running state when it is not needed, or for preventing a deployment from running during times that it should not be accessed. It also can be useful for keeping a deployment in suspended state during a holiday or a holiday period.

You can associate an application deployment with a suspension policy by associating system tags with the application deployment (if corresponding system tag matching rules are configured for the policy and rules-based governance is enabled)  or by associating the application deployment with the name of the policy to use (if rules-based governance is disabled). See Governance Rules for details.

You can add a suspension policy to a deployment when you launch the deployment or after the deployment is complete. If Governance Rules are turned on, you can add a suspension policy to a deployment at launch time by using tags. To do so, you create a system tag, associate the tag to an aging policy and define rules when you create the policy, and then associate the tags with an application deployment tier.

The Suspension Policy field in Deploy page is a drop-down for choosing a suspension policy if Governance mode is off, or displays the aging policies that are associated with tags that are assigned to the deployment if Governance mode is on?)

On the Deployment Details page:

  • The Suspension Policy field contains an Add button to associate a suspension policy. If a suspension policy is already associated, then you see a dropdown menu with the Change Policy and Remove Policy options.

  • Other new fields on the Deployment Details page include Start Time, Action History (new actions per new policies), and so forth.

To manage Suspension policies, click Policies in the CCM UI main menu and then click the Suspension link to display the Suspension Policies page.

The Suspension Policies page lists configured suspension policies and lets you perform the following tasks:

TaskDescription
Add a new suspension  policy.

Click the New Suspension Policy link.

See Configuring a Suspension Policy for details.

Change the priority for a suspension policy.

Available only if Governance Rules are turned on. Choose a value from the PRIORITY drop-down menu to assign a unique priority to the policy. A value of 1 represents the highest priority.

When you associate system tags with an application deployment tier, the system evaluates all rules that are mapped to the system tags to choose the suspension policy. If more than one suspension policy is available, the rule evaluation chooses the aging policy with the highest priority.

Only policies that the tenant administrator creates are used in governance mode and only the tenant administrator can change the priority of these policies. Standard users and co-admin users do not see policies that they created before governance rules were turned on because such a system does not permit use of these policies. Standard users and co-admin users see policies that the tenant administrator creates if the tenant administrator has shared these policies with these users.

Set permissions for a suspension  policy.

Choose Share from the dropdown list in the Actions column for the policy.

See Policy Permissions for details.

View information about a suspension  policy.

You can view the following information for each policy:

  • DESCRIPTION–Optional description that was configured for the policy
  • LAST UPDATED–Date and time that the policy was last updated
  • SCHEDULE–Runtime schedule and blockout dates that are configured for the policy
View or update configurations for an existing suspension  policy.


Choose Edit from the dropdown list in the Actions column for the policy.

The Edit page for the policy displays. See Configuring a Suspension Policy for a description of the fields that you can update. If you make updates, click the Save button on the Edit page to save your changes.

Delete an aging policy.

Choose Delete from the dropdown list in the Actions column for the policy.

Add tag matching rules to a suspension  policy.

Available only if Governance Rules are turned on. Choose Associate Rules from the dropdown list in the Actions column for the policy.

See System Tags for details.

Enable or disable a suspension  policy.

Turn on or off the Enable switch for the policy.

When a policy is disabled, future deployments cannot use it. The policy remains in effect for existing deployments.

Configuring a Suspension Policy

When you add a suspension policy, you create a new policy based on configuration settings that you make. To add a  suspension policy, click New Suspension Policy on the Suspension Policy page and then configure the settings that the following table describes. Click the Save button after you complete the configuration.

SettingDescription
Policy Name fieldEnter a brief and unique descriptive name for the policy
Policy Description fieldOptionally enter a brief description of the policy.
Runtime Schedule fieldsEnter the start time and end time during which a deployment is to be in Running state on the designated days.
Repeats fieldChoose Daily if the policy should put the deployment in Running state every during the designated start time through end time period. Choose Weekly and then choose specific days if the policy should put the deployment in Running state only on certain days during this time period.
Blackout Dates fields

Optionally configure blackout dates as follows, which are individual dates or date ranges on which the deployment remains suspended for 24 hours beginning at 12:00 a.m., regardless of the runtime schedule that you configured.

To add an individual blackout date, click DATE and then choose the date.

To add a date range, click Date Range and then choose the start date and end date of the range.

You can enter as many dates and date ranges as needed. To delete a date or date range entry, click the trash can icon in its Actions column.

Suspension Policy Guidelines

  • A suspension policy does not prevent you from performing manual suspend and resume operations on a deployment. For example, if a policy sets a deployment to suspend a 9:00 a.m. and resume at 5:00 p.m., you could manually resume the policy at 4:00 p.m.

  • A suspension policy uses the time zone that is configured for a deployment that it affects. In this way, you can use one policy for deployments that are in different time zones.


  • No labels
© 2017-2018 Cisco Systems, Inc. All rights reserved