Abstract: A secondary location is configured as a recovery service for a primary location of the service. The secondary location is maintained in a warm state that is configured to replace the primary location in a case of a failover. During normal operation, the secondary location is automatically updated to reflect a current state of the primary location that is actively servicing user load. Content changes to the primary location are automatically reflected to the secondary location. System changes applied to the primary location are automatically applied to the secondary location. For example, removing/adding machines, updating machine/role assignments, removing adding/database are automatically applied to the secondary location such that the secondary location substantially mirrors the primary location. After a failover to the secondary location, the secondary location becomes the primary location and begins to actively service the user load.

Abstract: A secondary location is configured as a recovery service for a primary location of the service. The secondary location is maintained in a warm state that is configured to replace the primary location in a case of a failover. During normal operation, the secondary location is automatically updated to reflect a current state of the primary location that is actively servicing user load. Content changes to the primary location are automatically reflected to the secondary location. System changes applied to the primary location are automatically applied to the secondary location. For example, removing/adding machines, updating machine/role assignments, removing adding/database are automatically applied to the secondary location such that the secondary location substantially mirrors the primary location. After a failover to the secondary location, the secondary location becomes the primary location and begins to actively service the user load.

Abstract: A secondary location is configured as a recovery service for a primary location of the service. The secondary location is maintained in a warm state that is configured to replace the primary location in a case of a failover. During normal operation, the secondary location is automatically updated to reflect a current state of the primary location that is actively servicing user load. Content changes to the primary location are automatically reflected to the secondary location. System changes applied to the primary location are automatically applied to the secondary location. For example, removing/adding machines, updating machine/role assignments, removing adding/database are automatically applied to the secondary location such that the secondary location substantially mirrors the primary location. After a failover to the secondary location, the secondary location becomes the primary location and begins to actively service the user load.

Abstract: A cloud manager controls the deployment and management of machines for an online service. A build system creates deployment-ready virtual hard disks (VHDs) that are installed on machines that are spread across one or more networks in farms that each may include different configurations. The build system is configured to build VHDs of differing configurations that depend on a role of the virtual machine (VM) for which the VHD will be used. The build system uses the VHDs to create virtual machines (VMs) in both test and production environments for the online service. The cloud manager system automatically provisions machines with the created virtual hard disks (VHDs). Identical VHDs can be installed directly on the machines that have already been tested.

Abstract: A secondary location is configured as a recovery service for a primary location of the service. The secondary location is maintained in a warm state that is configured to replace the primary location in a case of a failover. During normal operation, the secondary location is automatically updated to reflect a current state of the primary location that is actively servicing user load. Content changes to the primary location are automatically reflected to the secondary location. System changes applied to the primary location are automatically applied to the secondary location. For example, removing/adding machines, updating machine/role assignments, removing adding/database are automatically applied to the secondary location such that the secondary location substantially mirrors the primary location. After a failover to the secondary location, the secondary location becomes the primary location and begins to actively service the user load.

Abstract: A secondary location is configured as a recovery service for a primary location of the service. The secondary location is maintained in a warm state that is configured to replace the primary location in a case of a failover. During normal operation, the secondary location is automatically updated to reflect a current state of the primary location that is actively servicing user load. Content changes to the primary location are automatically reflected to the secondary location. System changes applied to the primary location are automatically applied to the secondary location. For example, removing/adding machines, updating machine/role assignments, removing adding/database are automatically applied to the secondary location such that the secondary location substantially mirrors the primary location. After a failover to the secondary location, the secondary location becomes the primary location and begins to actively service the user load.

Abstract: A cloud manager controls the deployment and management of machines for an online service. A build system creates deployment-ready virtual hard disks (VHDs) that are installed on machines that are spread across one or more networks in farms that each may include different configurations. The build system is configured to build VHDs of differing configurations that depend on a role of the virtual machine (VM) for which the VHD will be used. The build system uses the VHDs to create virtual machines (VMs) in both test and production environments for the online service. The cloud manager system automatically provisions machines with the created virtual hard disks (VHDs). Identical VHDs can be installed directly on the machines that have already been tested.

Abstract: A cloud manager controls the deployment and management of machines for an online service. A build system creates deployment-ready virtual hard disks (VHDs) that are installed on machines that are spread across one or more networks in farms that each may include different configurations. The build system is configured to build VHDs of differing configurations that depend on a role of the virtual machine (VM) for which the VHD will be used. The build system uses the VHDs to create virtual machines (VMs) in both test and production environments for the online service. The cloud manager system automatically provisions machines with the created virtual hard disks (VHDs). Identical VHDs can be installed directly on the machines that have already been tested.

Abstract: Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Abstract: Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Abstract: A cloud manager controls the deployment and management of machines for an online service. A build system creates deployment-ready virtual hard disks (VHDs) that are installed on machines that are spread across one or more networks in farms that each may include different configurations. The build system is configured to build VHDs of differing configurations that depend on a role of the virtual machine (VM) for which the VHD will be used. The build system uses the VHDs to create virtual machines (VMs) in both test and production environments for the online service. The cloud manager system automatically provisions machines with the created virtual hard disks (VHDs). Identical VHDs can be installed directly on the machines that have already been tested.

Abstract: Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Abstract: Objects are placed on hosts using hard constraints and soft constraints. The objects to be placed on the host may be many different types of objects. For example, the objects to place may include tenants in a database, virtual machines on a physical machine, databases on a virtual machine, tenants in directory forests, tenants in farms, and the like. When determining a host for an object, a pool of hosts is filtered through a series of hard constraints. The remaining pool of hosts is further filtered through soft constraints to help in selection of a host. A host is then chosen from the remaining hosts.

Abstract: Objects are placed on hosts using hard constraints and soft constraints. The objects to be placed on the host may be many different types of objects. For example, the objects to place may include tenants in a database, virtual machines on a physical machine, databases on a virtual machine, tenants in directory forests, tenants in farms, and the like. When determining a host for an object, a pool of hosts is filtered through a series of hard constraints. The remaining pool of hosts is further filtered through soft constraints to help in selection of a host. A host is then chosen from the remaining hosts.

Abstract: A cloud manager controls the deployment and management of machines for an online service. A build system creates deployment-ready virtual hard disks (VHDs) that are installed on machines that are spread across one or more networks in farms that each may include different configurations. The build system is configured to build VHDs of differing configurations that depend on a role of the virtual machine (VM) for which the VHD will be used. The build system uses the VHDs to create virtual machines (VMs) in both test and production environments for the online service. The cloud manager system automatically provisions machines with the created virtual hard disks (VHDs). Identical VHDs can be installed directly on the machines that have already been tested.

Abstract: An online service includes databases that are upgraded while still processing requests. For example, web servers continue to request operations on the database while it is being upgraded. The schema of the database is upgraded before the web servers are upgraded to utilize the upgraded schema. Changes that are made to the upgraded schema are backwards compatible with the schema being used during the upgrade process. Restrictions are placed on the operations performed on the database during the upgrade process. After upgrading the schema, the web servers of the online service are upgraded to use the upgraded schema.

Abstract: An online service includes managed databases that include one or more tenants (e.g. customers, users). A multi-tenant database may be split between two or more databases while the database being split continues processing requests. For example, web servers continue to request operations on the database while content is being moved. After moving the content, tenant traffic is automatically redirected to the database that contains the tenant's content.

Abstract: Jobs submitted to a primary location of a service within a period of time before and/or after a fail-over event are determined and are resubmitted to a secondary location of the service. For example, jobs that are submitted fifteen minutes before the fail-over event and jobs that are submitted to the primary network before the fail-over to the second location is completed are resubmitted at the secondary location. After the fail-over event occurs, the jobs are updated with the secondary network that is taking the place of the primary location of the service. A mapping of job input parameters (e.g. identifiers and/or secrets) from the primary location to the secondary location are used by the jobs when they are resubmitted to the secondary location. Each job determines what changes are to be made to the job request based on the job being resubmitted.

Abstract: A secondary location of a network acts as a recovery network for a primary location of the service. The secondary location is maintained in a warm state that is configured to replace the primary location in a case of a failover. During normal operation, the primary location actively services user load and performs backups that include full backups, incremental backups and transaction logs that are automatically replicated to the secondary location. Information is stored (e.g. time, retry count) that may be used to assist in determining when the backups are restored correctly at the secondary location. The backups are restored and the transaction logs are replayed at the secondary location to reflect changes (content and administrative) that are made to the primary location. After failover to the secondary location, the secondary location becomes the primary location and begins to actively service the user load.

Abstract: A cloud manager assists in deploying and managing networks for an online service. The cloud manager system receives requests to perform operations relating to configuring, updating and performing tasks in networks that are used in providing the online service. The management of the assets may comprise deploying machines, updating machines, removing machines, performing configuration changes on servers, Virtual Machines (VMs), as well as performing other tasks relating to the management. The cloud manager is configured to receive requests through an idempotent and asynchronous application programming interface (API) that can not rely on a reliable network.