// Add any tips or answers to anticipated questions.

== FAQ

*Q.* I encountered a *CREATE_FAILED* error when I launched the Quick Start.

*A.* If AWS CloudFormation fails to create the stack, relaunch the template with *Rollback on failure* set to *Disabled*. This setting is under *Advanced* in the AWS CloudFormation console on the *Configure stack options* page. With this setting, the stack’s state is retained, and the instance keeps running so that you can troubleshoot the issue. (For Windows, look at the log files in `%ProgramFiles%\Amazon\EC2ConfigService` and `C:\cfn\log`.)
// Customize this answer if needed. For example, if you’re deploying on Linux instances, either provide the location for log files on Linux or omit the final sentence. If the Quick Start has no EC2 instances, revise accordingly (something like "and the assets keep running").

WARNING: When you set *Rollback on failure* to *Disabled*, you continue to incur AWS charges for this stack. Delete the stack when you finish troubleshooting.

For more information, see https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html[Troubleshooting AWS CloudFormation^].

*Q.* I encountered a size-limitation error when I deployed the AWS CloudFormation templates.

*A.* Launch the Quick Start templates from the links in this guide or from another S3 bucket. If you deploy the templates from a local copy on your computer or from a location other than an S3 bucket, you might encounter template-size limitations. For more information, see http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cloudformation-limits.html[AWS CloudFormation quotas^].

*Q.* I forgot which passwords I entered in the CloudFormation template.

*A.* In the AWS Management Console, navigate to *Secrets Manager*. The passwords entered in the CloudFormation template are stored under *<stackname>-SECRETSSTACK...-DomainControllerSecrets*. Choose *Retrieve secret value* to locate the user names and passwords for the Active Directory server.

== Troubleshooting

Confirm that the provisioner node successfully shut down by inspecting the EC2 instances and filtering on the stack name in the AWS Management Console. Make sure to clear the *running instances* filter. The provisioner instance should automatically shut down soon after the main stack completes.

Even if the stack deploys successfully, if the provisioner instance cannot successfully complete the post-deployment steps, several issues might occur:

* The SMB file share might not exist, which means that you cannot use the Q drive.
* The cluster might not be joined to the Active Directory domain.
* The EBS volumes might not be tagged with the stack name.
* The link to Qumulo UI on the workstation desktop might not work.

Another cause of failure is with the local DNS resolution or the ability to reach public IP addresses. However, these issues are unlikely if you deployed the template into a new VPC. If the template was deployed into an existing VPC, causes of failure might include:

* The existing VPC does not have a functioning NAT gateway, and the provisioning node is unable to reach public IP addresses for AWS services.
* The existing VPC does not have route tables correctly configured for public and private subnets in relation to an internet gateway and NAT gateway.
* The existing VPC has network access control lists (ACLs) that are blocking traffic.
* The existing VPC has DHCP options that are misconfigured for the Active Directory server that the stack deployed, causing DNS resolution issues. Review the *DHCP Options* section to review and resolve the options created by the stack and other option sets in the VPC.
* The existing VPC already had an Active Directory server, and now a conflict exists.