Update documentation links to D2iQ url and changed pathes (#7018)

docs/docs/auth-access-ctrl.md

@@ -6,4 +6,4 @@ title: Authorization and Access Control
 
 If you are using Marathon on DC/OS, you can define fine-grained access to applications by creating advanced ACL groups in your native Marathon instance. Advanced ACL groups provide multi-tenancy by isolating application teams as well as individual users. You can also control customized access to applications, for example, to provide read-only access.
 
-This feature is only available in Marathon deployed with DC/OS. See [the DC/OS docs](https://docs.mesosphere.com/latest/security/ent/iam-api/) for this feature.
+This feature is only available in Marathon deployed with DC/OS. See [the DC/OS docs](https://docs.d2iq.com/mesosphere/dcos/latest/security/ent/iam-api/) for this feature.

docs/docs/fault-domain-awareness.md

@@ -95,6 +95,6 @@ Suppose we have a Mesos cluster that spans 3 regions: `aws-us-east1`, `aws-us-ea
 
 ### Increase Cluster Capacity
 
-To increase capacity, [add new agents](https://docs.mesosphere.com/latest/administering-clusters/add-a-node/) to a remote region or regions of your cluster, and then update your services to launch instances in that region or those regions appropriately.
+To increase capacity, [add new agents](https://docs.d2iq.com/mesosphere/dcos/latest/administering-clusters/add-a-node/) to a remote region or regions of your cluster, and then update your services to launch instances in that region or those regions appropriately.
 
 **Note:** You cannot configure your service to run in more than one region.

docs/docs/native-docker-private-registry.md

@@ -37,7 +37,7 @@ As of Marathon 1.5, you can upload your private Docker registry credentials to a
     }
     ```
 
-1.  Add the `config.json` file to a secret store. If you are using Enterprise DC/OS, [follow these instructions to add the file to the DC/OS secret store](https://docs.mesosphere.com/latest/security/ent/secrets/create-secrets/#creating-secrets).
+1.  Add the `config.json` file to a secret store. If you are using Enterprise DC/OS, [follow these instructions to add the file to the DC/OS secret store](https://docs.d2iq.com/mesosphere/dcos/latest/security/ent/secrets/create-secrets/#creating-secrets).
 
 ### Step 2: Add the Secret to your App or Pod Definition
 

docs/docs/networking.md

@@ -12,7 +12,7 @@ See the [Migrating to the 1.5 Networking API](upgrade/network-api-for-apps.html)
 
 ### VIPs
 
-If you are running Marathon within a [DC/OS cluster](https://dcos.io/get-started), you can use [virtual addresses (VIPs)](https://docs.mesosphere.com/latest/networking/load-balancing-vips/) to make ports management easier.
+If you are running Marathon within a [DC/OS cluster](https://dcos.io/get-started), you can use [virtual addresses (VIPs)](https://docs.d2iq.com/mesosphere/dcos/latest/networking/load-balancing-vips/) to make ports management easier.
 VIPs simplify inter-app communication and implement a reliable service-oriented architecture.
 VIPs map traffic from a single virtual address to multiple IP addresses and ports.
 
@@ -122,7 +122,7 @@ In Marathon, this is referred to as the service port. The service port is specif
 
 The service port is metadata; Marathon does not do anything with this information except track it and provide it to a load balancer. The DevOps team setting up this service is expected to create a script or provide a means to read the `servicePort` and configure the load balancer to route calls to that port (port `8080` in this case) to each of the instances of the application. All metadata is queryable from Marathon.
 
-The [Marathon-LB service](https://docs.mesosphere.com/latest/networking/marathon-lb/), when configured, does exactly this.  Marathon-LB will register all instances of an app and route to its configured `servicePort`. Marathon-LB is an HAProxy service with scripts that will register all instances of an app and route to its configured `servicePort`. In the configuration in this example, a client will connect to a load balancer at port `8080` (`servicePort`), which will route (with an algorithm) to `10.0.0.2:31000` (`hostPort`), which will in turn route to `8080` (`containerPort`) of the internal application.
+The [Marathon-LB service](https://docs.d2iq.com/mesosphere/dcos/latest/networking/marathon-lb/), when configured, does exactly this.  Marathon-LB will register all instances of an app and route to its configured `servicePort`. Marathon-LB is an HAProxy service with scripts that will register all instances of an app and route to its configured `servicePort`. In the configuration in this example, a client will connect to a load balancer at port `8080` (`servicePort`), which will route (with an algorithm) to `10.0.0.2:31000` (`hostPort`), which will in turn route to `8080` (`containerPort`) of the internal application.
 
 #### The `VIP_0` Label Use Case
 
@@ -226,7 +226,7 @@ Additional [per-task enviroment variables](task-environment-vars.html) are also
 
 #### Virtual addresses
 
-See the DC/OS documentation for [virtual addresses (VIPs)](https://docs.mesosphere.com/latest/networking/load-balancing-vips/).
+See the DC/OS documentation for [virtual addresses (VIPs)](https://docs.d2iq.com/mesosphere/dcos/latest/networking/load-balancing-vips/).
 
 ## Examples
 

docs/docs/pods.md

@@ -865,7 +865,7 @@ The following pod definition specifies an ephemeral volume called `v1`. <!-- Val
 
 ### IP-per-Pod Networking
 
-The following pod definition specifies a virtual (user) network named `dcos`. The `networks:mode:container` field creates the virtual network. The `name` field is optional. If you have installed DC/OS using [our AWS templates](https://docs.mesosphere.com/latest/installing/oss/cloud/aws/), the default virtual network name is `dcos`. <!-- Validated by suzanne 6-23-17 -->
+The following pod definition specifies a virtual (user) network named `dcos`. The `networks:mode:container` field creates the virtual network. The `name` field is optional. If you have installed DC/OS using [our AWS templates](https://docs.d2iq.com/mesosphere/dcos/latest/installing/oss/cloud/aws/), the default virtual network name is `dcos`. <!-- Validated by suzanne 6-23-17 -->
 
 ```json
 {

docs/docs/waiting.md

@@ -25,7 +25,7 @@ Apps or pods often fail to deploy because the resource offers from Mesos do not
 There are several reasons why your app or pod may fail to deploy. Some possibilities include:
 
 - Marathon isn't getting the resource offers it needs to launch the app.
-  If you are using DC/OS, use the [CLI](https://docs.mesosphere.com/latest/monitoring/debugging/cli-debugging/) debug subcommands or the [debugging page in the DC/OS web interface](https://docs.mesosphere.com/latest/monitoring/debugging/gui-debugging/) to troubleshoot unmatched or unaccepted resource offers from Mesos. You can also [consult the service and task logs](https://docs.mesosphere.com/latest/monitoring/logging/).
+  If you are using DC/OS, use the [CLI](https://docs.d2iq.com/mesosphere/dcos/latest/monitoring/debugging/cli-debugging/) debug subcommands or the [debugging page in the DC/OS web interface](https://docs.d2iq.com/mesosphere/dcos/latest/monitoring/debugging/gui-debugging/) to troubleshoot unmatched or unaccepted resource offers from Mesos. You can also [consult the service and task logs](https://docs.d2iq.com/mesosphere/dcos/latest/monitoring/logging/).
 
   Otherwise, consult the Marathon UI and the Mesos UI to see the health and resource use of your app or pod.