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: Rules, such as condition-action rules, are configured at different levels of a hierarchy. For example, a top level site administrator may configure rules, lower level administrators may configure rules and end users may configure rules. Rules created at a higher hierarchical level are automatically inherited by lower hierarchical levels in the same branch of the hierarchy. The source of the inherited rule is indicated with its display such that the hierarchical level of creation can readily be determined. The inherited rule(s) may be toggled on/off at the lower hierarchical levels but edits to inherited rule(s) are restricted. Instead, a copy of any inherited rule may be made to create a local copy of the rule that is editable. Rules may be ordered and when a lower hierarchical level inherits the rules, the ordering is preserved. While the ordering of any rules remains constant when inherited at the lower levels, the lower level may toggle on/off the execution of each rule within the ordering.

Abstract: A set of user interfaces is provided to an administrator of a website. The user interfaces enable the administrator to configure search functionality of the website to present different types of search results differently. For instance, the administrator can use the user interfaces to configure the search functionality to present different properties for search results belonging to different result types.

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: Rules, such as condition-action rules, are configured at different levels of a hierarchy. For example, a top level site administrator may configure rules, lower level administrators may configure rules and end users may configure rules. Rules created at a higher hierarchical level are automatically inherited by lower hierarchical levels in the same branch of the hierarchy. The source of the inherited rule is indicated with its display such that the hierarchical level of creation can readily be determined. The inherited rule(s) may be toggled on/off at the lower hierarchical levels but edits to inherited rule(s) are restricted. Instead, a copy of any inherited rule may be made to create a local copy of the rule that is editable. Rules may be ordered and when a lower hierarchical level inherits the rules, the ordering is preserved. While the ordering of any rules remains constant when inherited at the lower levels, the lower level may toggle on/off the execution of each rule within the ordering.

Abstract: A query pipeline for an enterprise search system is configurable by a user of the system. A user may create rules for custom query transformation and parallel query generation, federation of queries, mixing of results and application of display layouts to the received search results. A user interface (UI) assists a user in configuring the search pipeline. For example, a user may enter condition action rules for queries that affect how a query is transformed, how parallel queries are generated, how queries are federated, how search results are ranked and displayed, how rules are ordered and the like.

Abstract: A set of user interfaces is provided to an administrator of a website. The user interfaces enable the administrator to configure search functionality of the website to present different types of search results differently. For instance, the administrator can use the user interfaces to configure the search functionality to present different properties for search results belonging to different result types.

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: 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 query pipeline for an enterprise search system is configurable by a user of the system. A user may create rules for custom query transformation and parallel query generation, federation of queries, mixing of results and application of display layouts to the received search results. A user interface (UI) assists a user in configuring the search pipeline. For example, a user may enter condition action rules for queries that affect how a query is transformed, how parallel queries are generated, how queries are federated, how search results are ranked and displayed, how rules are ordered and the like.

Abstract: Rules, such as condition-action rules, are configured at different levels of a hierarchy. For example, a top level site administrator may configure rules, lower level administrators may configure rules and end users may configure rules. Rules created at a higher hierarchical level are automatically inherited by lower hierarchical levels in the same branch of the hierarchy. The source of the inherited rule is indicated with its display such that the hierarchical level of creation can readily be determined The inherited rule(s) may be toggled on/off at the lower hierarchical levels but edits to inherited rule(s) are restricted. Instead, a copy of any inherited rule may be made to create a local copy of the rule that is editable. Rules may be ordered and when a lower hierarchical level inherits the rules, the ordering is preserved. While the ordering of any rules remains constant when inherited at the lower levels, the lower level may toggle on/off the execution of each rule within the ordering.

Abstract: Systems and method for routing search query results in a networked computing environment. An initial search query is reformulated into at least one sub-query in accordance with one or more configurable rules. The sub-query is sent to at least one information system or source, and any potential hits associated with the same are optionally combined and then rendered for viewing.

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: Content that is stored at a secondary location for a service is crawled before it is placed in operation to assist in maintaining an up to date search index. The content that is crawled at the secondary location includes content that is obtained from the primary location of the service. When a crawler at the secondary location attempts to access content that is stored at the primary location, the crawler is directed to access the corresponding copy of the content that is stored at the secondary location instead of accessing the content at the primary location. The content may be crawled at the secondary location at different times, such as when the information is updated, according to a schedule, and the like.

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: During an outage at a primary location for an online service that is temporary in duration (e.g. a “temporary outage”), requests are temporarily switched from the primary location to a secondary location for the online service. The temporary outage may be caused by many different reasons (e.g. power outage, planned maintenance, and the like). The secondary location may be configured as read only during the temporary outage such that users are still able to access their data during the temporary without causing changes to be made to the data. The requests to the primary location of the online service are automatically redirected to be handled by the secondary location. When the temporary outage ends, the requests are automatically switched back to the primary location.

Abstract: A history of locations of tenant data is maintained. The tenant data comprises data that is currently being used by the tenant and the corresponding backup data. When a tenant's data is changed from one location to another, a location and a time is stored within the history that may be accessed to determine a location of the tenant's data at a specified time. Different operations trigger a storing of a location/time within the history. Generally, an operation that changes a location of the tenant's data triggers the storing of the location within the history (e.g. upgrade of farm, move of tenant, adding a tenant, load balancing of the data, and the like). When tenant data is needed for an operation (e.g. restore), the history may be accessed to determine the location of the data.

Abstract: A set of user interfaces is provided to an administrator of a website. The user interfaces enable the administrator to configure search functionality of the website to present different types of search results differently. For instance, the administrator can use the user interfaces to configure the search functionality to present different properties for search results belonging to different result types.