- What's new in Smart Tools
- Known issues
- About Citrix Cloud and Citrix Smart Tools
- Technical Security Overview for Citrix Smart Tools
- Open source attribution
- System Requirements
- Get Started
- Smart Tools Agent
- About blueprints and the Blueprint Designer
- About blueprint steps
- About scripts
- Add a new script
- Use named parameters in scripts
- Reference attachments in scripts
- Create a blueprint
- Provision VMs for your blueprint with the Server step
- Use Amazon EC2 APIs in your blueprint with the EC2 Generic Step
- Add conditional actions to your blueprint with the Conditional step
- Add server volumes to your blueprint with the Mount Volume step
- Register or unregister DNS subdomains
- Chain blueprint step outputs and inputs
- Create references to scripts and blueprints
- View and modify blueprints and scripts
- Publish a blueprint
- Clone a blueprint
- Share a blueprint or script
- About Smart Check
- About health checks
- Add a Site to Smart Check
- Discover a Site in Smart Check
- Perform health checks for your XenApp and XenDesktop Site
- Use custom checks and alerts with Smart Check
- View reports from health checks
- Manage Smart Check alerts and notifications
- Upload Site diagnostics to Citrix Technical Support
- View or modify a Site in Smart Check
- JSON format objects reference
- Smart Scale
- Smart Migrate
- Resource Locations
- Prepare Windows Server VM templates for deploying blueprints
- About the Checks and Blueprints catalog and Library
- About deployment profiles
- About the Pre-deployment Checklist
- Deploy a blueprint using existing machines
- Deploy a blueprint to a Citrix XenServer resource location
- Set static IP addresses for XenServer VM templates
- Deploy a blueprint to a Citrix CloudPlatform resource location
- Deploy a blueprint to a VMware vSphere resource location
- Set a static IP address for OVA files using VMware vSphere
- Deploy a blueprint to a Microsoft Hyper-V Server resource location
- Hyper-V VM prerequisite configurations
- Deploy a blueprint to Microsoft Azure Classic resource location
- Deploy a blueprint to an Amazon Web Services resource location
- Preparing Windows-based custom AMIs for Smart Tools
- Rerun a blueprint step during a deployment error
- Pause or cancel a deployment
- Deploy a script
Deploy Citrix Solutions Blueprints
- Deploy Citrix Solutions blueprints using existing machines
- Create a XenApp and XenDesktop production deployment on Microsoft Azure Classic
- Create a XenApp and XenDesktop production deployment on AWS
- Create a XenApp and XenDesktop production deployment with Provisioning Services on Citrix XenServer and VMware vSphere
- Deploy the Simple XenApp and XenDesktop Proof of Concept blueprint on Microsoft Azure Classic
- Deploy the Simple XenApp and XenDesktop Proof of Concept blueprint to AWS
- Deploy the XenApp and XenDesktop Proof of Concept blueprint on Citrix XenServer
- Deploy the XenApp and XenDesktop Proof of Concept blueprint on Microsoft Azure Classic
- Deploy the XenApp and XenDesktop Proof of Concept blueprint with NetScaler to AWS
- Deploy XenApp with the Secure Browser Service
- Deploy the XenMobile Enterprise or Advanced Edition blueprint
- Deploy the XenMobile MDM Edition blueprint
Deploy Resource Locations for Citrix Cloud
- Deploy the XenApp and XenDesktop Resource Location Setup blueprint on Citrix XenServer
- Deploy the XenApp and XenDesktop Resource Location Setup blueprint on Microsoft Azure Classic
- Deploy the XenApp and XenDesktop Resource Location Setup blueprint on AWS
- Deploy the XenApp and XenDesktop Resource Location Setup blueprint with an existing domain on AWS
- Manage Deployments
- Accounts and users
- REST API
- Troubleshoot agent connectivity issues
- Troubleshoot agent download and installation issues
- Troubleshoot blueprint creation issues
- Troubleshoot blueprint deployment issues
- Troubleshoot Site onboarding issues
- Troubleshoot removing Sites from Smart Tools
- Troubleshoot Smart Scale events
- Troubleshoot XenApp 6.x farm migration issues
About blueprint steps
A step is a building block of a blueprint. Each step performs a distinct action, such as launching a server, installing an application, rebooting a server, and so on. You can use any blueprint or script in your library as a step for building a blueprint. You can also use a variety of built-in steps to perform common actions.
This topic describes the built-in steps included in Smart Tools.
The EC2 Generic Step lets you specify an EC2 API whose output can then be used as input for steps in a blueprint. This enables you to pre-configure processes in Smart Tools that perform automated IT tasks based on data passed from your EC2 accounts via API.
For example, you may wish to chain outputs from the DescribeVolumes API to a configuration step that requires as input a specific attribute value, such as volumeID, size, snapshotID, etc.
For more information about using this step in a blueprint, see Use Amazon EC2 APIs in your blueprint with the EC2 Generic Step.
The Server step launches a server in your target resource location. Typically, this step is used as a reference point for subsequent steps in your blueprint. For example, you might include scripts that rename and reboot the server or create a domain controller. The steps for these scripts would point to the Server step as the target for execution.
The Mount Volume step lets you to create a new empty volume on a server or create a new volume from a snapshot that you specify.
The Create Snapshot step enables you to create a snapshot of a server that is launched from the blueprint. When the snapshot is created, all disks on the machine are included.
The Terminate Machine step removes servers that have been scaled down or decommissioned. For more information about using this step, see Manage teardown.
The Manual Step allows you to specify custom inputs that can be used in subsequent steps in your blueprint. You can supply values for the keys you define when you deploy the blueprint.
The Conditional Step enables you to insert conditions into your blueprint, and specify actions to take when those conditions are met. For example, you can use blueprint inputs that you supply or the output of another step to trigger actions such as sending a notification or approval, running a script, or executing another blueprint.
The conditions and actions you specify are grouped into paths (for example, Path A, Path B, and so on). All conditions in a path must be satisfied for the specified action to occur. You can configure multiple paths to ensure alternative actions are taken if the conditions in a particular path are not met. If the conditions in any path are not met, no actions in the step occur.
For an example of how to configure this step, see Add conditional actions to your blueprint with the Conditional step.
The Alert/Notify/Approve step lets you add a notification and approval mechanism to your blueprint deployment process. You can use this step to notify specified recipients based on trigger conditions that you define, and to require approval before a process or sub-process can run. By adding Alert/Notify/Approve steps to your blueprint, you can keep key individuals informed on the status of a deployment and you can build policy controls that help you manage resources and contain costs.
You can configure the Alert/Notify/Approve step for a wide range of use cases, including:
- Require Approval Before Process Runs: Use the Alert/Notify/Approve step to require approval from specified recipients before a process can run.
- Notify on Multiple Conditions:Define multiple trigger conditions for an alert, then set the alert to notify on Any or All conditions—if ALL conditions are met, a notification is sent; or, if ANY conditions are met, a notification is sent.
- Notify on Inverse Conditions: Configure alerts to notify based on inverse conditions (e.g. “instancecount” equals 1 ; or “instancecount” not equal to 1)
The Reboot step enables you to reboot a target server. When using this step, you can set the “Runs On” tab to point to a Server step in your blueprint.
The Wait step enables you to pause blueprint execution for a predefined period. For example, you can use this step to allow additional time for a server reboot to complete after installing an application.
The Register DNS step allows you to register a specified subdomain with Smart Tools’ public DNS (clm-poc.com) as part of your blueprint deployment. This allows you to set up your own registered subdomain that you can use with the application or environment you deploy with your blueprint.
The Unregister DNS step allows you to remove your previously-registered subdomain. Typically, you add this step to your blueprint’s Tear Down process.
For more information about using these steps in your blueprint, see Register or unregister DNS subdomains.