Abstract: Described is a technology by which a remote network (or local) service is monitored for failure, e.g., by determining whether data corresponding to operation of the service achieves a threshold. When a threshold is achieved that indicates that the service has failed, the service is automatically deactivated for use with a local workload, and the workload switched to use a second service or system having functionality similar to that of the failed service. The second service may be monitored for failure, as may the failed service to determine when it is again operational. In this manner, a remote primary service may have another local or remote secondary service/system automatically substituted for it when it fails, and be restored for use when it returns to acceptable operation.

Abstract: A computer environment analysis tool may have a modular architecture that comprises data collection modules and data analysis modules. The data collection modules may populate multiple data sets defined by a schema, and the data analysis modules may analyze or interpret the data from the database to produce report output. A reporting module may generate information that may be consumed by a user or other service. The data collection modules may be specialized modules that collect specific types of data from local and remote devices, and the data analysis modules may analyze the data for specific business logic, such as determining if a computer environment is capable of upgrading or deploying various changes.

Abstract: Provided is a system to automatically recover a computer system after a failed attempt, or failed attempts, to boot a target operating system on the computer system.

Abstract: A security management system uses several security scenarios that have rules defining the configuration of system and security components in order to meet a specific security scenario. The rules may include an evaluation of multiple components to give a summary statistic or evaluation, as well as rules that may be used to configure the various components to achieve a desired level of security. A management console may aggregate multiple security scenarios together for administration.

Abstract: A license management system may include a license analyzer that is capable of evaluating different licensing strategies for software products or services on a single device or a group of devices. Rules for licensing options are coupled with actual usage data and forecasts to determine various licensing options. The options may be implemented by an automated system for renewing licenses or changing licenses and installing updated licenses.

Abstract: A security manager aggregates various security components into a unified user interface. For each security component, the security manager may obtain an updated policy description that defines specific groups of settings for the component in terms of several threat conditions. Using the groups of settings, the security manager may classify a current state of a security component into a category. Some embodiments may use a standardized schema for an interface between a security component and the security manager. The schema may be implemented with an adapter that translates the specific settings of a security component into data for the security manager. In some embodiments, the adapter may also receive updated policy descriptions and perform a classification of the current settings.

Abstract: A traffic manager may monitor network performance, detect that the network performance has changed, and may prioritize network traffic based on which application or function is associated with the traffic. Each packet of network traffic may be analyzed to determine a source application or source function and allowed or disallowed along the network based on a set of predetermined priorities. Several sets of priorities may be established for various network performance conditions. In some embodiments, traffic may be routed along different paths using the sets of priorities and the source application or function. The traffic manager is adaptable for web-based services, applications, or other functions provided over a network connection.

Abstract: A setup workflow may be defined in a complex workflow manner that may have branching, error compensation, and relationships defined between a software product to be installed and previously installed or future products that may be installed. As a setup workflow operates, a remote device may be contacted for an updated setup step that may also include relationship definitions between the new setup step and other steps or installed components. The new step may be for a remotely provided service that may be used in lieu of a locally installed product. The setup workflow may include dependencies and coordinate setup workflows across multiple devices.

Abstract: A license management system may have an adapter or interface that enables any type of licensed software or service to be managed through a common administrative view. The adapters may use a common schema that includes various parameters about a license as well as information that may enable a license management system to interact with a license vendor or license provider. The licenses may include locally operating software, software operating over a local area network, and various services that may be provided over a network including the Internet. The license management system may support many types of licenses and may be able to consolidate license management of many different devices and types of devices. The license management system may display the various licenses, as well as provide some other functions including alerting, usage monitoring, and managing licenses.

Abstract: Aspects of the subject matter described herein relate to setting up nodes. In aspects, a setup process is started to install software components to provide services to other nodes. The setup process asks for a product key and maps the product key to a product definition that indicates a number of nodes upon which the software is allowed to be installed. The product definition may also indicate what services are allowed to be installed by the setup process. The user indicates the number of nodes on which he wishes to install the software. The user may then indicate which nodes the user wishes to provide which services. This setup data is stored and may be used to determine what services to install when the setup process is executed on each of the nodes.

Abstract: Described is a technology by which a remote network (or local) service is monitored for failure, e.g., by determining whether data corresponding to operation of the service achieves a threshold. When a threshold is achieved that indicates that the service has failed, the service is automatically deactivated for use with a local workload, and the workload switched to use a second service or system having functionality similar to that of the failed service. The second service may be monitored for failure, as may the failed service to determine when it is again operational. In this manner, a remote primary service may have another local or remote secondary service/system automatically substituted for it when it fails, and be restored for use when it returns to acceptable operation.

Abstract: A method and a system for obtaining shutdown information for a computer allows a user to indicate a reason or reasons for the shutdown. The states of the user mode processes that are running on the computer are saved for later analysis. The state information as well as the shutdown reason entered by the user is stored in a computer-readable memory, such as in the form of a log file. A user may report a shutdown reason by selecting a reason from a predefined reason list and/or by typing a reason in a comment area.

Abstract: A method and a system for obtaining shutdown information for a computer allows a user to indicate a reason or reasons for the shutdown. The states of the user mode processes that are running on the computer are saved for later analysis. The state information as well as the shutdown reason entered by the user is stored in a computer-readable memory, such as in the form of a log file. A user may report a shutdown reason by selecting a reason from a predefined reason list and/or by typing a reason in a comment area.