Update links from /support/documentation to /docs

BuildMaster/administration/agents-and-infrastructure/agents.md

@@ -10,19 +10,19 @@ To deploy releases to your servers, BuildMaster needs to be able to communicate
 
 ## Windows Servers {#windows data-title="Windows Servers"}
 
-The [Inedo Agent](/support/documentation/inedoagent/overview) is generally the best way to communicate with a Windows server. It's light-weight, and uses a highly-optimized and resilient protocol built solely for this purpose, and is [quite easy to install](/support/documentation/buildmaster/installation-and-maintenance/installation-guide/agent-installation-guide).
+The [Inedo Agent](/docs/inedoagent/overview) is generally the best way to communicate with a Windows server. It's light-weight, and uses a highly-optimized and resilient protocol built solely for this purpose, and is [quite easy to install](/docs/buildmaster/installation-and-maintenance/installation-guide/agent-installation-guide).
 
 ## Agentless Windows Servers {#agentless data-title="Agentless Windows Servers"}
 
-Alternatively, BuildMaster can use PowerShell Remoting to communicate with Windows servers; however, this is generally slower and less resilient than the Inedo Agent protocol. You can connect using integrated authentication (i.e. whatever account the service is running under), or with a username & password [resource credential](/support/documentation/buildmaster/administration/resource-credentials). See [Enable-PSRemoting](https://technet.microsoft.com/en-us/library/hh849694.aspx) to configures a server to receive remote commands.
+Alternatively, BuildMaster can use PowerShell Remoting to communicate with Windows servers; however, this is generally slower and less resilient than the Inedo Agent protocol. You can connect using integrated authentication (i.e. whatever account the service is running under), or with a username & password [resource credential](/docs/buildmaster/administration/resource-credentials). See [Enable-PSRemoting](https://technet.microsoft.com/en-us/library/hh849694.aspx) to configures a server to receive remote commands.
 
 ## Linux Servers {#linux data-title="Linux Servers"}
 
-To communicate with Linux servers, BuildMaster uses the lightweight, highly-optimized, and resilient protocol already enabled on nearly every Linux box: SSH and SFTP. You can connect with a private key or username & password [resource credential](/support/documentation/buildmaster/administration/resource-credentials).
+To communicate with Linux servers, BuildMaster uses the lightweight, highly-optimized, and resilient protocol already enabled on nearly every Linux box: SSH and SFTP. You can connect with a private key or username & password [resource credential](/docs/buildmaster/administration/resource-credentials).
 
 ## Local Agents {#local data-title="Local Agents"}
 
-If you're using BuildMaster to interact with the server it's installed on, you can just set it up using a local agent. This uses the same process/identity that the [service](/support/documentation/buildmaster/installation-and-maintenance/architecture/service) is hosted as, and doesn't have very many privileges by default.
+If you're using BuildMaster to interact with the server it's installed on, you can just set it up using a local agent. This uses the same process/identity that the [service](/docs/buildmaster/installation-and-maintenance/architecture/service) is hosted as, and doesn't have very many privileges by default.
 
 ## Automatic Inedo Agent Updates {#automatic-updates data-title="Automatic Inedo Agent Updates"}
 

BuildMaster/administration/agents-and-infrastructure/environments.htm

@@ -14,7 +14,7 @@
 
     </p>
     <p>
-        Environments are also used in <a href="/support/documentation/buildmaster/administration/users-and-security">security and access controls</a> to permit and restrict users from performing various tasks. For example, you could permit “QA Users” to deploy applications to the Testing environment, while restricting them from deploying to the Production environment.
+        Environments are also used in <a href="/docs/buildmaster/administration/users-and-security">security and access controls</a> to permit and restrict users from performing various tasks. For example, you could permit “QA Users” to deploy applications to the Testing environment, while restricting them from deploying to the Production environment.
     </p>
     <p>
         BuildMaster comes with three, built-in environments that represent a very simple deployment pipeline: Integration, Testing, and Production. You can create, rename, and delete environments as needed.    
@@ -27,7 +27,7 @@ <h2 id="nested-environmnets" data-title="Nested Environments"> Nested Environmen
         This not only helps with visualization, but it can simplify the access controls you define. For example, if you restricted access to Production, then Prod-Main and Prod-Backup would also be restricted unless you define a more granular access control on one of the child environments.    
     </p>
     <p>
-        <a href="/support/documentation/buildmaster/administration/configuration-variables">Configuration variables</a> will also cascade from a parent to a child environment, which means that deployments to a child environment will have access to the parent environment’s variables if they are not defined on the child environment.
+        <a href="/docs/buildmaster/administration/configuration-variables">Configuration variables</a> will also cascade from a parent to a child environment, which means that deployments to a child environment will have access to the parent environment’s variables if they are not defined on the child environment.
     </p>
      <h2 id="multiple-per-server" data-title="Multiple Environments per server">Multiple Environments per server</h2>
      <p>

BuildMaster/administration/agents-and-infrastructure/server-roles.htm

@@ -20,7 +20,7 @@
     </p>
     <h2 id="creating-assigning-roles" data-title="Creating and Assigning Server Roles"> Creating and Assigning Server Roles</h2>
    <p>
-        You can create, edit, and delete server roles using the web-based interface (Admin > Infrastructure > Roles), or programmatically with the <a href="/support/documentation/buildmaster/reference/api/infrastructure">Infrastructure API.</a> 
+        You can create, edit, and delete server roles using the web-based interface (Admin > Infrastructure > Roles), or programmatically with the <a href="/docs/buildmaster/reference/api/infrastructure">Infrastructure API.</a> 
     </p> 
 
    <p>
@@ -32,11 +32,11 @@ <h2 id="deploying-to-server-roles" data-title="Deploying to Server Roles"> Deplo
    </p>
    <h3 id="pipeline-stage-target" data-title="Pipeline Stage Target">Pipeline Stage Target</h3>
    <p>
-        You can specify a role name instead of a list of servers as a stage target in a <a href="/support/documentation/buildmaster/core-concepts/pipelines#Pipeline-stages">pipeline stage</a>. When the build is deployed to that stage, the stage target's deployment plan will be run against all servers with that role and in that environment.   
+        You can specify a role name instead of a list of servers as a stage target in a <a href="/docs/buildmaster/core-concepts/pipelines#Pipeline-stages">pipeline stage</a>. When the build is deployed to that stage, the stage target's deployment plan will be run against all servers with that role and in that environment.   
    </p>
    <h3 id="server-roles-otterscript" data-title="Server Roles and OtterScript">Server Roles and OtterScript</h3>
    <p>
-        You can deploy to servers in a role using the <code>@ServersInRole</code> function within a <a href="/support/documentation/buildmaster/execution-engine/statements-and-blocks/loop">loop block</a>. 
+        You can deploy to servers in a role using the <code>@ServersInRole</code> function within a <a href="/docs/buildmaster/execution-engine/statements-and-blocks/loop">loop block</a>. 
    </p>
    <pre>
         foreach server in @ServersInRole(hdars-api-host)
@@ -52,7 +52,7 @@ <h2 id="role-dependencies" data-title="Role Dependencies">Role Dependencies</h2>
         Role dependencies are used by <a href="/otter">Otter</a> to model complex server and application configuration through hierarchical sets of simple roles with dependencies. This makes it much easier to share common configuration and define smaller (but related) roles. 
 </p>
 <p>
-        While you can define a role's dependencies (i.e. the other roles which are required) on the role overview page, BuildMaster won't behave any differently if a role has dependencies. They are included only so that you can <a href="/support/documentation/buildmaster/administration/configuration">synchronize your infrastructure</a> across products.
+        While you can define a role's dependencies (i.e. the other roles which are required) on the role overview page, BuildMaster won't behave any differently if a role has dependencies. They are included only so that you can <a href="/docs/buildmaster/administration/configuration">synchronize your infrastructure</a> across products.
 </p>
 <h2 id="multiple-server-roles" data-title="Multiple Server Roles"> Example: Multiple Server Roles</h2>
 <p>

BuildMaster/administration/agents-and-infrastructure/servers.md

@@ -13,21 +13,21 @@ A server can be physical (bare metal), virtual, or even nonexistent (i.e. one th
 
 ### Adding Servers to BuildMaster {#adding-servers data-title="Adding Servers to BuildMaster"}
 
-You can add a server using the web-based user interface (`Servers` > `Add Server`), or programmatically with the [infrastructure API](/support/documentation/buildmaster/reference/api/infrastructure).
+You can add a server using the web-based user interface (`Servers` > `Add Server`), or programmatically with the [infrastructure API](/docs/buildmaster/reference/api/infrastructure).
 
-BuildMaster communicates with servers using the [Inedo Agent](/support/documentation/inedoagent/overview) (for Windows) or [SSH/SFTP](https://www.ssh.com/ssh/sftp) (for Windows and Linux).
+BuildMaster communicates with servers using the [Inedo Agent](/docs/inedoagent/overview) (for Windows) or [SSH/SFTP](https://www.ssh.com/ssh/sftp) (for Windows and Linux).
 
 ## Deploying to Servers {#deploying-to-servers data-title="Deploying to Servers"}
 
 In addition to using [Server Roles](server-roles), there are two ways to deploy to a server:
 
 ### Pipeline Stage Target {#pipeline-target data-title="Pipeline Stage Target"}
 
-You can specify a list of servers as a stage target in a [pipeline stage](/support/documentation/buildmaster/verification/pipelines#pipeline-stages). When the build is deployed to that stage, the stage target's deployment plan will be run against all those servers.
+You can specify a list of servers as a stage target in a [pipeline stage](/docs/buildmaster/verification/pipelines#pipeline-stages). When the build is deployed to that stage, the stage target's deployment plan will be run against all those servers.
 
 ### Servers and OtterScript {#servers-otter data-title="Servers and OtterScript"}
 
-You can deploy to a server using a [general block](/support/documentation/executionengine/otterscript/statements-and-blocks/general-blocks)
+You can deploy to a server using a [general block](/docs/executionengine/otterscript/statements-and-blocks/general-blocks)
 
 ```
 for server prod-hdars-sv1
@@ -49,4 +49,4 @@ However, if your application has always been deployed to a specific server, and
 
 A resource pool is a set of servers that are used as a single, load-balanced resource. You may acquire an unused server from a resource pool, and then release it back into the pool once the needed tasks have been performed.
 
-Visit the [Resource Pools](/support/documentation/executionengine/components/resource-pools) documentation of the Inedo Execution Engine for more information on how to configure a resource pool.
+Visit the [Resource Pools](/docs/executionengine/components/resource-pools) documentation of the Inedo Execution Engine for more information on how to configure a resource pool.

BuildMaster/administration/applications/import-export.md

@@ -24,7 +24,7 @@ You will also select how to publish the package, from one of two options:
 - **Publish to Universal Feed** - a feed on a ProGet instance
 - **Save to Disk Path** - a local or network path that the BuildMaster service can write to
 
-Before publishing to a feed, you will need to setup an Inedo Product [resource credential](/support/documentation/buildmaster/administration/resource-credentials) with the URL and optionally an API key to your ProGet server.
+Before publishing to a feed, you will need to setup an Inedo Product [resource credential](/docs/buildmaster/administration/resource-credentials) with the URL and optionally an API key to your ProGet server.
 
 ## Importing Applications {#importing data-title="Importing Applications"}
 
@@ -44,7 +44,7 @@ Before importing from a feed, you will need to setup an Inedo Product resource c
 
 ## Package File Format {#package-file-formate data-title="Package File Format"}
 
-Applications will be exported as a standard [universal package](/support/documentation/proget/core-concepts/packages) which is essentially a zip file containing application configuration and history, along with a JSON-based manifest file (`upack.json`) that describes the contents of the package.
+Applications will be exported as a standard [universal package](/docs/proget/core-concepts/packages) which is essentially a zip file containing application configuration and history, along with a JSON-based manifest file (`upack.json`) that describes the contents of the package.
 
 In addition to the standard name and version properties, BuildMaster will include `a _exportDate` and `_bmVersion` property in `upack.json`. The package contents will be a collection of JSON-formatted files:
 

BuildMaster/administration/configuration-variables.htm

@@ -8,15 +8,15 @@
 </head>
 <body>
     <p>
-        <a href="/support/documentation/executionengine/components/runtime-variables"> Variables</a> allow for extreme flexibility when modeling your deployment plans, and
-        configuration variables allow you to have the same plan run differently across different servers and <a href="/support/documentation/buildmaster/administration/agents-and-infrastructure/environments">environments</a>.
+        <a href="/docs/executionengine/components/runtime-variables"> Variables</a> allow for extreme flexibility when modeling your deployment plans, and
+        configuration variables allow you to have the same plan run differently across different servers and <a href="/docs/buildmaster/administration/agents-and-infrastructure/environments">environments</a>.
     </p>
 
     <p>
         You can define configuration variables at different scopes (release, server, environment, global, etc), and then reference those variables in your plan when using
-        Operations, <a href="/support/documentation/executionengine/otterscript/statements-and-blocks/if-else">If/Else Blocks</a>,
-        <a href="/support/documentation/executionengine/otterscript/statements-and-blocks/loop">Loop Blocks</a>, etc.
-        You can also create a <a href="/support/documentation/executionengine/components/runtime-variables">runtime variable</a> in a plan itself.
+        Operations, <a href="/docs/executionengine/otterscript/statements-and-blocks/if-else">If/Else Blocks</a>,
+        <a href="/docs/executionengine/otterscript/statements-and-blocks/loop">Loop Blocks</a>, etc.
+        You can also create a <a href="/docs/executionengine/components/runtime-variables">runtime variable</a> in a plan itself.
     </p>
 
     <h2 id="cascading" data-title="Cascading Variables">Cascading Variables</h2>
@@ -38,7 +38,7 @@ <h2 id="cascading" data-title="Cascading Variables">Cascading Variables</h2>
     <h3 id="resolution-rules" data-title="Resolution Rules">Resolution Rules</h3>
     <p>The variable definition that's the "closest" match to the current context is used. This is determined as follows:</p>
     <ul class="docs">
-        <li>Runtime Variables (<i><a href="/support/documentation/executionengine/components/runtime-variables">more info</a></i>)</li>
+        <li>Runtime Variables (<i><a href="/docs/executionengine/components/runtime-variables">more info</a></i>)</li>
         <li>Deployment</li>
         <li>Build</li>
         <li>Release</li>
@@ -103,7 +103,7 @@ <h2 id="sensitive" data-title="Sensitive Variables">Sensitive Variables</h2>
     </p>
     <p>
         The secure option for storing passwords, connection strings, or other values intended to be encrypted is
-        <a href="/support/documentation/buildmaster/administration/resource-credentials">Resource Credentials</a>, as they require special permissions to manage,
+        <a href="/docs/buildmaster/administration/resource-credentials">Resource Credentials</a>, as they require special permissions to manage,
         and (as per Inedo Extensibility guidelines) should <i>never</i> be written to any logs.
     </p>
 
@@ -128,7 +128,7 @@ <h4>Full JSON Example</h4>
 
     <h2 id="api" data-title="Variables API">Variables API</h2>
     <p>
-        Variables are configurable using the <a href="/support/documentation/buildmaster/reference/api/variables">Variables Management API</a>.
+        Variables are configurable using the <a href="/docs/buildmaster/reference/api/variables">Variables Management API</a>.
     </p>
 
     <h2 id="value-renderers" data-title="Custom Value Renderers">Custom Value Renderers</h2>

BuildMaster/administration/notifications.htm

@@ -16,7 +16,7 @@
     </p>
     <p> <img class="screenshot" src="/resources/documentation/buildmaster/event-listeners.png" alt="Built-in Event Listeners" /></p>
     <p>
-        Event listeners can be added either as a post deployment step in a <a href="/support/documentation/buildmaster/verification/pipelines">pipeline</a> or specific to user via the <em>My Event Listener</em> user drop down.
+        Event listeners can be added either as a post deployment step in a <a href="/docs/buildmaster/verification/pipelines">pipeline</a> or specific to user via the <em>My Event Listener</em> user drop down.
     </p>
     <p>
         <img class="screenshot" src="/resources/documentation/buildmaster/myevent-listeners.png" alt="My Event Listener" />