diff --git a/README.md b/README.md
index f88d52f..cd87565 100644
--- a/README.md
+++ b/README.md
@@ -1,31 +1,89 @@
+# Deploy and Manage a Scalable Moodle Cluster on Azure
 
-# Contributing
+This repo contains guides on how to deploy and manage a scalable
+[Moodle](https://moodle.com) cluster on Azure.
 
-This project welcomes contributions and suggestions.  Most contributions require you to agree to a
-Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us
-the rights to use your contribution. For details, visit https://cla.microsoft.com.
+This document is designed to be "executed" by Simdem to produce an
+interactive tutorial or a demo environment. However, it can also be
+read as standard documentation.
 
-When you submit a pull request, a CLA-bot will automatically determine whether you need to provide
-a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions
-provided by the bot. You will only need to do this once across all repos using our CLA.
+## What this stack will give you
 
-This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
-For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or
-contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
+This template set deploys the following infrastructure:
+- Autoscaling web frontend layer (Nginx, php-fpm, Varnish)
+- Private virtual network for frontend instances
+- Controller instance running cron and handling syslog for the autoscaled site
+- Load balancer to balance across the autoscaled instances
+- Postgres or MySQL database
+- Azure Redis instance for Moodle caching
+- ObjectFS in Azure blobs (Moodle sitedata)
+- Three Elasticsearch VMs for search indexing in Moodle
+- Dual gluster nodes for high availability access to Moodle files
 
-# Legal Notices
+![network_diagram](images/stack_diagram.jpg "Diagram of deployed stack")
 
-Microsoft and any contributors grant you a license to the Microsoft documentation and other content
-in this repository under the [Creative Commons Attribution 4.0 International Public License](https://creativecommons.org/licenses/by/4.0/legalcode),
-see the [LICENSE](LICENSE) file, and grant you a license to any code in the repository under the [MIT License](https://opensource.org/licenses/MIT), see the
+## Configuration
+
+We will use a number of environment variables to configure our
+deployment. To customize them for your environment copy `env.json`
+into `env.local.json` and edit the contents accordingly. The values
+set within that file are:
+
+``` shell
+echo "Resource Group Name : $MOODLE_RG_NAME"
+echo "Resource Group Location : $MOODLE_RG_LOCATION"
+echo "Deployment Name : $MOODLE_DEPLOYMENT_NAME"
+```
+
+## Contributing
+
+This project welcomes contributions and suggestions. Most
+contributions require you to agree to a Contributor License Agreement
+(CLA) declaring that you have the right to, and actually do, grant us
+the rights to use your contribution. For details, visit
+https://cla.microsoft.com.
+
+When you submit a pull request, a CLA-bot will automatically determine
+whether you need to provide a CLA and decorate the PR appropriately
+(e.g., label, comment). Simply follow the instructions provided by the
+bot. You will only need to do this once across all repos using our
+CLA.
+
+This project has adopted the [Microsoft Open Source Code of
+Conduct](https://opensource.microsoft.com/codeofconduct/). For more
+information see the [Code of Conduct
+FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact
+[opencode@microsoft.com](mailto:opencode@microsoft.com) with any
+additional questions or comments.
+
+## Legal Notices
+
+Microsoft and any contributors grant you a license to the Microsoft
+documentation and other content in this repository under the [Creative
+Commons Attribution 4.0 International Public
+License](https://creativecommons.org/licenses/by/4.0/legalcode), see
+the [LICENSE](LICENSE) file, and grant you a license to any code in
+the repository under the [MIT
+License](https://opensource.org/licenses/MIT), see the
 [LICENSE-CODE](LICENSE-CODE) file.
 
-Microsoft, Windows, Microsoft Azure and/or other Microsoft products and services referenced in the documentation
-may be either trademarks or registered trademarks of Microsoft in the United States and/or other countries.
-The licenses for this project do not grant you rights to use any Microsoft names, logos, or trademarks.
-Microsoft's general trademark guidelines can be found at http://go.microsoft.com/fwlink/?LinkID=254653.
+Microsoft, Windows, Microsoft Azure and/or other Microsoft products
+and services referenced in the documentation may be either trademarks
+or registered trademarks of Microsoft in the United States and/or
+other countries. The licenses for this project do not grant you rights
+to use any Microsoft names, logos, or trademarks. Microsoft's general
+trademark guidelines can be found at
+http://go.microsoft.com/fwlink/?LinkID=254653.
 
 Privacy information can be found at https://privacy.microsoft.com/en-us/
 
-Microsoft and any contributors reserve all others rights, whether under their respective copyrights, patents,
-or trademarks, whether by implication, estoppel or otherwise.
+Microsoft and any contributors reserve all others rights, whether
+under their respective copyrights, patents, or trademarks, whether by
+implication, estoppel or otherwise.
+
+## Next Steps
+
+  1. [Deploy a Moodle Cluster](docs/Deploy.md)
+  1. [Obtain Deployment Details about a Moodle Cluster](docs/Get-Install-Data.md)
+  1. [Delete a Moodle Cluster](docs/Delete.md)
+
diff --git a/README.md.quickstarts b/README.md.quickstarts
deleted file mode 100644
index 8d88fd0..0000000
--- a/README.md.quickstarts
+++ /dev/null
@@ -1,172 +0,0 @@
-# *Autoscaling Moodle stack for Postgres or MySQL databases*
-
-After deploying, these templates will provide you with a new Moodle site with caching for speed and scaling frontends to handle PHP load. The filesystem behind it is mirrored for high availability and optionally backed up through Azure. Filesystem permissions and options have also been tuned to make Moodle more secure than a default install.
-
-[![Deploy to Azure](http://azuredeploy.net/deploybutton.png)](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-quickstart-templates%2Fmaster%2Fmoodle-scalable-cluster-ubuntu%2Fazuredeploy.json)  [![Visualize](https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/1-CONTRIBUTION-GUIDE/images/visualizebutton.png)](http://armviz.io/#/?load=https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-quickstart-templates%2Fmaster%2Fmoodle-scalable-cluster-ubuntu%2Fazuredeploy.json)
-
-`Tags: cluster, ha, moodle, autoscale, linux, ubuntu`
-
-## *What this stack will give you*
-
-This template set deploys the following infrastructure:
-- Autoscaling web frontend layer (Nginx, php-fpm, Varnish)
-- Private virtual network for frontend instances
-- Controller instance running cron and handling syslog for the autoscaled site
-- Load balancer to balance across the autoscaled instances
-- Postgres or MySQL database
-- Azure Redis instance for Moodle caching
-- ObjectFS in Azure blobs (Moodle sitedata)
-- Three Elasticsearch VMs for search indexing in Moodle
-- Dual gluster nodes for high availability access to Moodle files
-
-![network_diagram](images/stack_diagram.jpg "Diagram of deployed stack")
-
-## *Deployment steps*
-
-You can click the "deploy to Azure" button at the beginning of this document or alternatively perform a deploy from the command line:
-
-### *Command line deploys*
-Once you've checked out the templates from git, you'll want to use the [Azure CLI tool](https://docs.microsoft.com/en-us/cli/azure/overview?view=azure-cli-latest) to deploy them. First off you'll want to create a group with these:
-
-`az group create --name <stackname> --location <location>`
-
-Note that some locations in Azure might not support features or certain VM tiers.
-
-Next you'll want to either deploy and enter in all parameters manually:
-
-`az group deployment create --name moodle-autoscale --resource-group <stackname> --template-file azuredeploy.json`
-
-Alternatively, you can configure all your variables in the "azuredeploy.parameters.json" file and run:
-
-`az group deployment create --name moodle-autoscale --resource-group <stackname> --template-file azuredeploy.json --parameters azuredeploy.parameters.json`
-
-Note that `siteURL` is a special case in the `azuredeploy.parameters.json` files. If you do not define a value for `siteURL` or if you leave it as the default "www.example.org" this value will be overwritten by the template to be a calculated value for the public load balancers of your deployment. This allows you to experiment with this Moodle template without configuring a new domain name whilst still enabling Moodle to be configured with a production URL when appropriate. See the next section for instructions on retrieving the generated DNS name if necesary.
-
-Depending on what tiers you selected for VMs and the database you will be looking at roughly 1-2 hours for a full deploy. See below for selectable parameters.
-
-## *Using the created stack*
-
-In testing, stacks typically took between 1 and 2 hours to finish,
-depending on spec. Once this is done you will receive a JSON with
-outputs needed to continue setup. You can also retrieve these from the
-portal or the CLI, more information below. The available parameters
-are:
-
-- siteURL: If you provided a `siteURL` parameter when deploying this
-  will be set to the supplied value. Otherwise it will be the same as
-  the loadBalancerDNS, see below.
-- loadBalancerDNS: This is the address of your load balancer. If you
-  provided a `siteURL` parameter when deploying you'll need to add a
-  DNS entry CNAMEs to this.
-- moodleAdminPassword: The password for the "admin" user in your
-  Moodle install.
-- controllerInstanceIP: This is the address of the controller. You
-  will need to SSH into this to make changes to your moodle code or
-  view logs.
-- databaseDNS: This is the public DNS of your database instance. If
-  you wish to set up local backups or access the db directly, you'll
-  need to use this.
-- databaseAdminUsername: The master account (not Moodle) username for
-  your database.
-- databaseAdminPassword: The master account password for your
-  database.
-
-Once Moodle has been created, and (if necessary) with your custom
-`siteURL` DNS pointing to the load balancer, you should be able to
-load the `siteURL` and login with "admin" and the password supplied in
-the moodleAdminPassword.
-
-#### Retrieving Deployment Configuration
-
-The outputs provided by your deployment should include everytyrhing
-you need to manage your Moodle deployment. These are available in the
-portal by clicking on the deployment for your resource group. They are
-also available in via the Azure CLI. For example:
-
-Retrieve all the outputs in JSON format:
-
-```
-az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out json --query *.outputs
-```
-
-Retrieve just the database password
-
-```
-az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.databaseAdminPassword.value
-```
-
-Assign the database password to a variable (BASH):
-
-```
-MOODLE_DATABASE_DNS="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.databaseDNS.value)"
-```
-
-### *Updating Moodle code/settings*
-
-Your controller VM has Moodle code and data stored on /moodle. The code is stored in /moodle/html/moodle/. This is also mounted to your autoscaled frontends so all changes are instant. Depending on how large your Gluster disks are sized, it may be helpful to keep multiple older versions (/moodle/html1, /moodle/html2, etc) to roll back if needed.
-
-### *Getting an SQL dump*
-
-A daily sql dump of your database is taken at 02:22 and saved to /moodle/db-backup.sql(.gz). If your database is small enough to fit, you may be able to get a more current SQL dump of your Moodle db by dumping it to /moodle/. Otherwise, you'll want to do this remotely by connecting to the hostname shown in the database-dns output using the database-admin-username and database-admin-password.
-
-While Azure does not currently back up Postgres/MySQL databases, by dumping it to /moodle it is included in the Gluster VM backups should you enable Recovery Services in your parameters.
-
-### *Azure Recovery Services*
-
-If you have set azureBackupSwitch to 1 then Azure will provide VM backups of your Gluster node. This is recommended as it contains both your Moodle code and your sitedata. Restoring a backed up VM is outside the scope of this doc, but Azure's documentation on Recovery Services can be found here: https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-first-look-arm
-
-### *Resizing your Database*
-
-Note: This involves a lengthy site downtime.
-
-As mentioned above, Azure does not currently support resizing databases. You can, however, create a new database instance and change your config to point to that. To get a different size database you'll need to:
-
-1. Place your Moodle site into maintenance mode. You can do this either via the web interface or the command line on the controller VM.
-2. Perform an SQL dump of your database, either to /moodle or remotely to your machine.
-3. Create a new Azure database of the size you want inside your existing resource group.
-4. Using the details in your /moodle/html/moodle/config.php create a new user and database matching the details in config.php. Make sure to grant all rights on the db to the user.
-5. On the controller instance, change the db setting in /moodle/html/moodle/config.php to point to the new database.
-6. Take Moodle site out of maintenance mode.
-7. Once confirmed working, delete the previous database instance.
-
-How long this takes depends entirely on the size of your database and the speed of your VM tier. It will always be a large enough window to make a noticeable outage.
-
-### *Changing the SSL cert*
-
-The self-signed cert generated by the template is suitable for very basic testing, but a public website will want a real cert. After purchasing a trusted certificate, it can be copied to the following files to be ready immediately:
-
-- /moodle/certs/nginx.key: Your certificate's private key
-- /moodle/certs/nginx.crt: Your combined signed certificate and trust chain certificate(s).
-
-Once replaced these changes become effective immediately.
-
-
-## *Sizing Considerations and Limitations*
-
-Depending on what you're doing with Moodle, there are several considerations to make when configuring. The defaults included produce a cluster that is inexpensive but probably too low spec to use beyond single-user Moodle testing.
-
-It should be noted that as of the time of this writing both Postgres and MySQL databases are in preview at Azure. In the future larger DB sizes or different VM sizes will be available. The templates will allow you to select whatever size you want, but there are restrictions in place (VMs with certain storage types, disk size for database tiers, etc) that may prevent certains selections from working together.
-
-### *Database Sizing*
-
-As of the time of this writing, Azure supports "Basic" and "Standard" tiers for database instances. In addition the skuCapacityDTU defines Compute Units, and the number of those you can use is limited by database tier:
-
-- Basic: 50, 100
-- Standard: 100, 200, 400, 800
-
-This value also limits the maximum number of connections, as defined here: https://docs.microsoft.com/en-us/azure/mysql/concepts-limits
-
-As the Moodle database will handle cron processes as well as the website, any public facing website with more than 10 users will likely require upgrading to 100. Once the site reaches 30+ users it will require upgrading to Standard for more compute units. This depends entirely on the individual site. As MySQL databases cannot change (or be restored to a different tier) once deployed it is a good idea to slightly overspec your database.
-
-Standard instances have a minimum storage requirement of 128000MB. All database storage, regardless of tier, has a hard upper limit of 1 terrabyte. After 128GB you gain additional iops for each GB, so if you're expecting a heavy amount of traffic you will want to oversize your storage. The current maximum iops with a 1TB disk is 3000.
-
-### *Controller instance sizing*
-
-The controller handles both syslog and cron duties. Depending on how big your Moodle cron runs are this may not be sufficient. If cron jobs are very delayed and cron processes are building up on the controller then an upgrade in tier is needed.
-
-### *Frontend instances*
-
-In general the frontend instances will not be the source of any bottlenecks unless they are severely undersized versus the rest of the cluster. More powerful instances will be needed should fpm processes spawn and exhaust memory during periods of heavy site load. This can also be mitigated against by increasing the number of VMs but spawning new VMs is slower (and potentially more expensive) than having that capacity already available.
-
-It is worth noting that the memory allowances on these instances allow for more memory than they may be able to provide with lower instance tiers. This is intentional as you can opt to run larger VMs with more memory and not require manual configuration. FPM also allows for a very large number of threads which prevents the system from failing during many small jobs.
-
diff --git a/docs/Delete.md b/docs/Delete.md
new file mode 100644
index 0000000..9220c9a
--- /dev/null
+++ b/docs/Delete.md
@@ -0,0 +1,8 @@
+# Delete a Moodle Cluster
+
+If you want to remove all resources associated with a Moodle Cluster
+simply delete the assocaited resource group as follows:
+
+```
+az group delete --name $MOODLE_RG_NAME
+```
diff --git a/docs/Deploy.md b/docs/Deploy.md
new file mode 100644
index 0000000..cefe9ad
--- /dev/null
+++ b/docs/Deploy.md
@@ -0,0 +1,165 @@
+# Deploy Autoscaling Moodle Stack to Azure
+
+After following the steps in this this document you with awill have a
+new Moodle site with caching for speed and scaling frontends to handle
+load. The filesystem behind it is mirrored for high availability and
+optionally backed up through Azure. Filesystem permissions and options
+have also been tuned to make Moodle more secure than a default
+install.
+
+## Prerequisites
+
+You will need a local copy of the Moodle ARM templates. These are
+published on GitHub so you should clone them locally (possibly after
+forking them on GitHub).
+
+## Create Resource Group
+
+When you create the Moodle cluster you will create many resources. On
+Azure it is a best practice to collect such resources together in a
+Resource Group. The first thing we need to do, therefore, is create a
+resource group:
+
+```
+az group create --name $MOODLE_RG_NAME --location $MOODLE_RG_LOCATION
+```
+
+Results:
+
+```expected_similarity=0.4
+{
+  "id": "/subscriptions/325e7c34-99fb-4190-aa87-1df746c67705/resourceGroups/rgmoodlearm3",
+  "location": "westus2",
+  "managedBy": null,
+  "name": "rgmoodlearm3",
+  "properties": {
+    "provisioningState": "Succeeded"
+  },
+  "tags": null
+}
+```
+
+## Create Azure Deployment Paramaters
+
+Your deployment will be configured using an
+`azuredeploy.parameters.json` file. It is possible to provide these
+parameters interactively via the command line by simply omitting the
+paramaters file in the command in the next section. However, it is
+more reproducible if we use a paramaters file.
+
+A good set of defaults are provided in the git repository. These
+defaults create a scalable cluster that is suitable for low volume
+testing. If you are building out a production service you should
+review the section below on sizing considerations. For now we will
+proceed with the defaults, but there is one value, the `sshPublicKey`
+that **must** be provided. To automatically add your default SSH key
+(in Bash) use the following command:
+
+```
+FIXME: sed command to add SSH key
+```
+
+## Deploy cluster
+
+Now that we have a resource group and a configuration file we can
+create the cluster itself. This is done with a single command:
+
+```
+az group deployment create --name $MOODLE_DEPLOYMENT_NAME --resource-group $MOODLE_RG_NAME --template-file ~/projects/azure-quickstart-templates/moodle-scalable-cluster-ubuntu/azuredeploy.json --parameters azuredeploy.parameters.json
+```
+
+## Using the created stack
+
+In testing, stacks typically took between 1 and 2 hours to finish,
+depending on spec. Once complete you will receive a JSON output
+containing information needed to manage your Moodle install (see
+`outputs`). You can also retrieve this infromation from the portal or
+the CLI.
+                      
+Once Moodle has been created, and (where necessary) you have
+configured your custom `siteURL` DNS to point to the
+`loadBalancerDNS`, you should be able to load the `siteURL` in a
+browser and login with the username "admin" and the
+`moodleAdminPassword`. Note that the values for each of these
+parameters are avialble in the portal or the `outputs` section of the
+JSON response from the previous deploy command. See [documentation on
+how to retrieve configuration data](./Get-Install-Data.md) along
+with full details of all the output parameters avialble to you.
+
+Note that by default the deployment uses a self-signed certificate,
+consequently you will recieve a warning when accessing the site. To
+add a genuine certificate see the documentation on [managing your
+cluster](./Manage.md).
+
+## Sizing Considerations and Limitations
+
+Depending on what you're doing with Moodle you will want to configure
+your deployment appropriately.The defaults included produce a cluster
+that is inexpensive but probably too low spec to use beyond simple
+testing scenarios. This section includes an overview of how to size
+the database and VM instances for your use case.
+
+It should be noted that as of the time of this writing both Postgres
+and MySQL databases are in preview at Azure. In the future larger DB
+sizes or different VM sizes will be available. The templates will
+allow you to select whatever size you want, but there are restrictions
+in place (VMs with certain storage types, disk size for database
+tiers, etc) that may prevent certains selections from working
+together.
+
+### Database Sizing
+
+As of the time of this writing, Azure supports "Basic" and "Standard"
+tiers for database instances. In addition the skuCapacityDTU defines
+Compute Units, and the number of those you can use is limited by
+database tier:
+
+- Basic: 50, 100
+- Standard: 100, 200, 400, 800
+
+This value also limits the maximum number of connections, as defined
+here: https://docs.microsoft.com/en-us/azure/mysql/concepts-limits
+
+As the Moodle database will handle cron processes as well as the
+website, any public facing website with more than 10 users will likely
+require upgrading to 100. Once the site reaches 30+ users it will
+require upgrading to Standard for more compute units. This depends
+entirely on the individual site. As MySQL databases cannot change (or
+be restored to a different tier) once deployed it is a good idea to
+slightly overspec your database.
+
+Standard instances have a minimum storage requirement of 128000MB. All
+database storage, regardless of tier, has a hard upper limit of 1
+terrabyte. After 128GB you gain additional iops for each GB, so if
+you're expecting a heavy amount of traffic you will want to oversize
+your storage. The current maximum iops with a 1TB disk is 3000.
+
+### Controller instance sizing
+
+The controller handles both syslog and cron duties. Depending on how
+big your Moodle cron runs are this may not be sufficient. If cron jobs
+are very delayed and cron processes are building up on the controller
+then an upgrade in tier is needed.
+
+### Frontend instances
+
+In general the frontend instances will not be the source of any
+bottlenecks unless they are severely undersized versus the rest of the
+cluster. More powerful instances will be needed should fpm processes
+spawn and exhaust memory during periods of heavy site load. This can
+also be mitigated against by increasing the number of VMs but spawning
+new VMs is slower (and potentially more expensive) than having that
+capacity already available.
+
+It is worth noting that the memory allowances on these instances allow
+for more memory than they may be able to provide with lower instance
+tiers. This is intentional as you can opt to run larger VMs with more
+memory and not require manual configuration. FPM also allows for a
+very large number of threads which prevents the system from failing
+during many small jobs.
+
+
+## Next Steps
+
+  1. [Retrieve configuration details using CLI](./Get-Install-Data.md)
+  1. [Manage the Moodle cluster](./Manage.md)
diff --git a/docs/Get-Intasll-Data.md b/docs/Get-Intasll-Data.md
new file mode 100644
index 0000000..51e3a05
--- /dev/null
+++ b/docs/Get-Intasll-Data.md
@@ -0,0 +1,149 @@
+# Retrieve essential install details
+
+Once a deployment has completed the ARM template will output some
+values that you will need for managing your Moodle instalation. These
+are available in the portal, but in this document we will retrieve
+them using the AZ command line tools and through the AZ CLI tool. This
+document describes the available parameters and how to retrieve them.
+
+## Output Paramater Overview
+
+The available output parameters are:
+
+  - **siteURL**: If you provided a `siteURL` parameter when deploying this
+    will be set to the supplied value. Otherwise it will be the same as
+    the loadBalancerDNS, see below.
+  - **loadBalancerDNS**: This is the DNS name of your application load
+    balancer. If you provided a `siteURL` parameter when deploying
+    you'll need to add a DNS entry to its CNAMEs pointing to this address.
+  - **moodleAdminPassword**: The generated password for the "admin" user
+    in your Moodle install.
+  - **controllerInstanceIP**: This is the IP address of the controller
+    Virtual Machine. You will need to SSH into this to make changes to
+    your Moodle code or view logs.
+  - **databaseDNS**: This is the public DNS of your database instance. If
+    you wish to set up local backups or access the DB directly, you'll
+    need to use this.
+  - **databaseAdminUsername**: The admin username for your database
+    (this is not the same as your Moodle username).
+  - **databaseAdminPassword**: The admin password for your
+    database (this is not the same as your Moodle password).
+
+## Retrieving Output Parameters Using the CLI
+
+To get a complete list of outputs in json format use:
+
+```bash
+az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out json --query *.outputs
+```
+
+Individual outputs can be retrieved by filtering, for example, to get
+just the value of the `siteURL` use:
+
+``` bash
+az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out json --query *.outputs.siteURL.value
+```
+
+However, since we are reqeusting JSON output (the default) the value
+is enclosed in quotes. In order to remove these we can output as a tab
+separated list (TSV):
+
+``` bash
+az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.siteURL
+```
+
+Now we can assign individual values to environment variables, for example:
+
+``` bash
+MOODLE_SITE_URL="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.siteURL.value)"
+```
+
+### Retrieving Moodle Site URL
+
+The Site URL is the value used to configure Moodle's base URL. The
+site URL can be provided as an input to the template via the parameter
+`siteURL`, in which case you will not need to retrieve this from the
+outputs. However, if you do not define this, or if you leave it as the
+default "www.example.org" you will need to retrieve this value from
+Azure using the following command:
+
+```bash
+MOODLE_SITE_URL="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.siteURL.value)"
+```
+
+#### Retrieving Moodle Site Load Balancer URL
+
+The load balancer DNS is the publicly registered DNS name for your
+Moodle DNS. If this is different from the site URL it is important to
+ensure that you configure your DNS entry for site URL to point at the
+load balancer.
+
+```bash
+MOODLE_LOAD_BALANCER_DNS="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.loadBalancerDNS.value)"
+```
+
+### Retrieving Moodle Administrator Password
+
+Moodle admin password (username is "admin"):
+
+```bash
+MOODLE_ADMIN_PASSWORD="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.moodleAdminPassword.value)"
+```
+
+### Retriving Controller Virtual Machine Details
+
+The controller VM runs management tasks for the cluster, such as cron jobs and syslog.
+
+```bash
+MOODLE_CONTROLLER_INSTANCE_IP="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.controllerInstanceIP.value)"
+```
+
+There is no username and password for this VM since a username and SSH
+key are provided as input parameters to the template.
+
+### Retreiving Database Information
+
+#### Database URL
+
+``` bash
+MOODLE_DATABASE_DNS="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.databaseDNS.value)"
+```
+#### Database admin username
+
+``` bash
+MOODLE_DATABASE_ADMIN_USERNAME="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.databaseAdminUsername.value)"
+```
+
+#### Database admin password
+
+``` bash
+MOODLE_DATABASE_ADMIN_PASSWORD="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.databaseAdminPassword.value)"
+```
+
+### Retrieving Moodle Application VNET Information
+
+First frontend VM IP:
+
+``` bash
+MOODLE_FIRST_FRONTEND_VM_IP="$(az group deployment show --resource-group $MOODLE_RG_NAME --name $MOODLE_DEPLOYMENT_NAME --out tsv --query *.outputs.firstFrontendVmIP.value)"
+```
+
+# Validation
+
+After having run each of the commands in this document you should have
+each of the output parameters available in environment variable:
+
+``` bash
+echo $MOODLE_SITE_URL
+echo $MOODLE_LOAD_BALANCER_DNS
+echo $MOODLE_ADMIN_PASSWORD
+echo $MOODLE_CONTROLLER_INSTANCE_IP
+echo $MOODLE_DATABASE_DNS
+echo $MOODLE_DATABASE_ADMIN_USERNAME
+echo $MOODLE_DATABASE_ADMIN_PASSWORD
+echo $MOODLE_FIRST_FRONTEND_VM_IP
+```
+
+## Next Steps
+
+  1. [Manage the Moodle cluster](./Manage.md)
diff --git a/docs/Manage.md b/docs/Manage.md
new file mode 100644
index 0000000..954749c
--- /dev/null
+++ b/docs/Manage.md
@@ -0,0 +1,144 @@
+# Managing a Scalable Moodle Cluster in Azure
+
+This document provides an overview of how to perform various
+management tasks on a scalable Moodle cluster on Azure.
+
+## Prerequisites
+
+In order to manage a cluster it is clearly necessary to first [deploy
+a scalable Moodle cluster on Azure](../Deploy/README.md).
+
+For convenience and readability this document also assumes that essential [deployment details for your cluster have been assigned to environment variables](../GetInstallData/README.md).
+
+## Updating Moodle code/settings
+
+Your controller Virtual Machine has Moodle code and data stored in
+`/moodle`. The site code is stored in `/moodle/html/moodle/`. This
+data is replicated across dual gluster nodes to provide high
+availability. This directory is also mounted to your autoscaled
+frontends so all changes to files on the controller VM are immediately
+available to all frontend machines.
+
+Depending on how large your Gluster disks are sized, it may be helpful
+to keep multiple older versions (/moodle/html1, /moodle/html2, etc) to
+roll back if needed.
+
+To connect to your Controller VM use SSH with a username of
+'azureuser' and the SSH provided in the `sshPublicKey` input
+parameter. For example, to retrieve a listing of files and directories
+in the `/moodle` directory use:
+
+```
+ssh -o StrictHostKeyChecking=no azureadmin@$MOODLE_CONTROLLER_INSTANCE_IP ls -l /moodle
+```
+
+Results:
+
+```
+Warning: Permanently added '52.228.45.38' (ECDSA) to the list of known hosts.
+total 12
+drwxr-xr-x  2 www-data www-data 4096 Jan 17 00:59 certs
+-rw-r--r--  1 root     root        0 Jan 17 02:22 db-backup.sql
+drwxr-xr-x  3 www-data www-data 4096 Jan 17 00:54 html
+drwxrwx--- 10 www-data www-data 4096 Jan 17 06:55 moodledata
+```
+
+**IMPORTANT NOTE**
+
+It is important to realize that the `-o StrictHostKeyChecking=no`
+option in the above SSH command presents a security risk. It is
+included here to facilitate automated validation of these commands. It
+is not recommended to use this option in production environments,
+instead run the command mannually and validate the host key.
+Subsequent executions of an SSH command will not require this
+validation step. For more information there is an excellent
+[superuser.com
+Q&A](https://superuser.com/questions/421074/ssh-the-authenticity-of-host-host-cant-be-established/421084#421084).
+
+## Getting an SQL dump
+
+By default a daily sql dump of your database is taken at 02:22 and
+saved to `/moodle/db-backup.sql`(.gz). This file can be retrieved
+using SCP or similar. For example:
+
+``` bash
+scp azureadmin@$MOODLE_CONTROLLER_INSTANCE_IP:/moodle/db-backup.sql /tmp/moodle-db-backup.sql
+```
+
+To obtain a more recent SQL dump you run the commands appropriate for
+your chosen database on the Controller VM. The following sections will
+help with this task.
+
+#### Postgres
+
+Postgress provides a `pg_dump` command that can be used to take a
+snapshot of the database via SSH. For example, use the following
+command:
+
+``` bash
+ssh azureadmin@$MOODLE_CONTROLLER_INSTANCE_IP 'pg_dump -Fc -h $MOODLE_DATABASE_DNS -U $MOODLE_DATABASE_ADMIN_USERNAME moodle > /moodle/db-snapshot.sql'
+```
+
+See the Postgres documentation for full details of the [`pg_dump`](https://www.postgresql.org/docs/9.5/static/backup-dump.html) command.
+
+#### MySQL
+
+MySQL provides a `mysql_dump` command that can be used to take a
+snapshot of the database via SSH. For example, use the following
+command:
+
+``` bash
+ssh azureadmin@$MOODLE_CONTROLLER_INSTANCE_IP 'mysqldump -h $mysqlIP -u ${azuremoodledbuser} -p'${moodledbpass}' --databases ${moodledbname} | gzip > /moodle/db-backup.sql.gz'
+```
+
+## Backup and Recovery
+
+If you have set the `azureBackupSwitch` in the input parameters to `1`
+then Azure will provide VM backups of your Gluster node. This is
+recommended as it contains both your Moodle code and your sitedata.
+Restoring a backed up VM is outside the scope of this doc, but Azure's
+documentation on Recovery Services can be found here:
+https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-first-look-arm
+
+## Resizing your Database
+
+Note: This process involves site downtime and should therefore only be
+carried out during a planned maintenance window.
+
+At the time of writing Azure does not support resizing MySQL or
+Postgres databases. You can, however, create a new database instance,
+with a different size, and change your config to point to that. To get
+a different size database you'll need to:
+
+  1. [Place your Moodle site into maintenance
+     mode](https://docs.moodle.org/34/en/Maintenance_mode). You can do
+     this either via the web interface or the command line on the
+     controller VM.
+  2. Perform an SQL dump of your database. See above for more details.
+  3. Create a new Azure database of the size you want inside your
+     existing resource group.
+  4. Using the details in your /moodle/html/moodle/config.php create a
+     new user and database matching the details in config.php. Make
+     sure to grant all rights on the db to the user.
+  5. On the controller instance, change the db setting in
+     /moodle/html/moodle/config.php to point to the new database.
+  6. Take Moodle site out of maintenance mode.
+  7. Once confirmed working, delete the previous database instance.
+
+How long this takes depends entirely on the size of your database and
+the speed of your VM tier. It will always be a large enough window to
+make a noticeable outage.
+
+## Changing the SSL cert
+
+The self-signed cert generated by the template is suitable for very
+basic testing, but a public website will want a real cert. After
+purchasing a trusted certificate, it can be copied to the following
+files to be ready immediately:
+
+  - /moodle/certs/nginx.key: Your certificate's private key
+  - /moodle/certs/nginx.crt: Your combined signed certificate and trust chain certificate(s).
+
+## Next Steps
+
+  1. [Retrieve configuration details using CLI](./Get-Install-Data.md)
diff --git a/env.json b/env.json
new file mode 100644
index 0000000..838d537
--- /dev/null
+++ b/env.json
@@ -0,0 +1,5 @@
+{
+    "MOODLE_RG_NAME": "rgmoodlearm12",
+    "MOODLE_RG_LOCATION": "canadacentral",
+    "MOODLE_DEPLOYMENT_NAME": "MainDeployment"
+}