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 security token service generates a security token for a user that is associated with a client and stores the full security token within a memory. The security token includes an identity claim that represents the identity of the generated security token. Instead of passing the entire security token back to the client, the identity claim is returned to the client. For each request the client makes to the service, the client passes the identity claim in the request instead of the full security token having all of the claims. The identity claim is much smaller then the full security token. When a computing device receives the identity claim within the request from the user, the identity claim is used to access the full security token that is stored in memory.

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.

Abstract: A machine manager controls the deployment and management of machines for an online service. The machine manager is configured to manually/automatically deploy farms, upgrade farms, add machines, remove machines, start machines, stop machines, and the like. The machine manager keeps track of the locations of the machines, the roles of the machines within the networks, as well as other characteristics relating to the machines (e.g. health of the machines). Instead of upgrading software on the machines in a farm that are currently handling requests, one or more machines are configured in a new farm with the selected disk images and then the requests are moved from the old farm to the new farm.

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 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 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 machine manager controls the deployment and management of machines (physical and virtual) for an online service. Multi-tier server groups are arranged in farms that each may include different configurations. For example, their may be content farms, federated services farms and SQL farms that are arranged to perform operations for the online service. When the multiple farms are upgraded, new farms are deployed and the associated content databases from the old farms are moved to the newly deployed farms. During the upgrade of the farms, requests may continue to be processed by the farms. The farms may be automatically load balanced during an upgrade. As content becomes available on the new farm, requests for the content may be automatically redirected to the new farm.

Abstract: A security token service generates a security token for a user that is associated with a client and stores the full security token within a memory. The security token includes an identity claim that represents the identity of the generated security token. Instead of passing the entire security token back to the client, the identity claim is returned to the client. For each request the client makes to the service, the client passes the identity claim in the request instead of the full security token having all of the claims. The identity claim is much smaller then the full security token. When a computing device receives the identity claim within the request from the user, the identity claim is used to access the full security token that is stored in memory.

Abstract: Web request routers are used to route requests to content within a network. The web request routers run on general purpose computing devices that are configured to receive requests, parse the requests and route the requests to the appropriate destination. The web request routers may be configured to perform different routing methods and operations. For example, the web request routers may route requests based on: a type of network traffic (e.g. user/machine); application specific logic, URL patterns and/or other programmed logic. The web request routers may be configured to route the request based on a determined affinity (e.g. document, Uniform Resource Locator (URL), directory path, site collection) of the request. The web request routers may also be configured to perform QOS operations such as auditing, logging, metering, throttling network traffic, prohibiting network traffic and the like.

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.

Abstract: Web request routers in a cloud management system are used to route requests to content within the networks that are associated with an online service. The web request routers receive requests, parse the requests and forward the requests to the appropriate destination. The web request routers may use application specific logic for routing the requests. For example, the requests may be routed based on a document identifier and/or user information that is included within the received request. A look up table may be used in determining a destination for the request. When a location of content changes within the online service, the look up table may be updated such that the web request routers automatically direct content to the updated location. A user may also specify where their requests are to be routed.

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: Software that would not normally be able to be installed on a machine through a remote process is installed by a high privilege installer running on the machine. A request is received from a remote machine to install software on the machine using the high privilege installer. The high privilege installer determines when software that was requested remotely is to be installed. For example, the high privilege installer may monitor an install queue for software to be installed. When there are entries in the install queue, the high privilege installer is used to install the software. When there are no entries in the install queue, the high privilege installer may sleep until there is more software that is identified to be installed.

Abstract: A cloud manager is utilized in the patching of physical machines and virtual machines that are used within an online service, such as an online content management service. The cloud manager assists in the scheduling of the application of software patches to the machines (physical and virtual) within the network such that the availability of the online service is maintained while machines are being patched. The machines to be patched are partitioned into groups that are patched at different times. Generally, the groups are partitioned into a highly available independent groups of machines such that one or more of the groups that are not currently being patched continue to provide the service(s) of the group that is being patched. The machines (physical and virtual) within each of the groups may be patched in parallel.

Abstract: A machine manager controls the deployment and management of machines for an online service. The machine manager is configured to manually/automatically deploy farms, upgrade farms, add machines, remove machines, start machines, stop machines, and the like. The machine manager keeps track of the locations of the machines, the roles of the machines within the networks, as well as other characteristics relating to the machines (e.g. health of the machines). Instead of upgrading software on the machines in a farm that are currently handling requests, one or more machines are configured in a new farm with the selected disk images and then the requests are moved from the old farm to the new farm.

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: 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.