US20050027846A1

US20050027846A1 - Automated electronic software distribution and management method and system

Info

Publication number: US20050027846A1
Application number: US10/831,323
Authority: US
Inventors: Alex Wolfe; Andrew Cirillo; Ray Krueger
Original assignee: Individual
Current assignee: Individual
Priority date: 2003-04-24
Filing date: 2004-04-26
Publication date: 2005-02-03
Also published as: WO2004097566A2; WO2004097565A2; CA2523279A1; US20050055357A1; CA2523283A1; US7340491B2; EP1671200A4; EP1671200A2; WO2004097566A3; EP1671199A2; WO2004097565A3

Abstract

Embodiments of the present invention provide a method and system for electronic software distribution and management. A request for instructions may be received from a managed client machine. The request for instructions may be analyzed. and may include asset inventory data. One or more instructions may be generated based on the request for instructions and the asset inventory data. The one or more instructions may include an instruction to install an application on the managed client machine. An acknowledgment may be received from the managed client machine if the instruction has been processed.

Description

RELATED APPLICATIONS

The present application incorporates by reference and claims the priority of U.S. Provisional Application No. 60/465,118, entitled “Automated Electronic Software Distribution Method,” U.S. Provisional Application No. 60/465,122, entitled “Software Distribution Management System,” and U.S. Provisional Application No. 60/465,121, entitled “Method, System and Article of Manufacture for Data Preservation and Automated Electronic Software Distribution Across an Enterprise System,” all filed Apr. 24, 2003. The present application also incorporates by reference co-pending U.S. application Ser. No. ______, entitled “Method, System and Article of Manufacture for Data Preservation and Automated Electronic Software Distribution Across an Enterprise System,” and filed herewith.

TECHNICAL FIELD

The present invention relates to computer systems. In particular, embodiments of the present invention provide an automated electronic software distribution and/or management system.

BACKGROUND OF THE INVENTION

Electronic Software Distribution (ESD) is the automated delivery of software to remote computer systems. This can be accomplished without human administration and/or intervention. ESD systems are important components of information technology environments, such as a corporate networks, that have a large number of computer systems and devices. These computers and/or networks are usually managed, supported and maintained by a small staff, and in environments where the administrating personnel may be physically distant or isolated from the systems they are responsible for managing.
Further, ESD systems are also important to Independent Software Vendors (ISVs) and Original Equipment Manufacturers (OEMs). ISVs utilize ESD systems to facilitate the distribution of updates, “hot patches” and “bug fixes.” These systems provide for greater customer support and service to the ISV's end users. Additionally, OEMs whose equipment contains software can better manage and monitor their equipment, as well as provide better service and support to their customers through ESD systems.
Conventional ESD systems are capable of distributing software from a remote system and may include the ability to concurrently distribute identical software to groups of computers based on existing attributes of those systems, or a pre-defined mapping. Other systems include some degree of asset discovery, which is the act of collecting and storing data on the existing software and hardware assets present on a given computer. However, asset discovery is usually accomplished through the use of a separate, dedicated system.
Using one type of ESD system, an administrator creates a “job” by specifying what software package they want to distribute, which targets are to be run, and when the job is to run. The job is executed on the specified targets at the specified time, after which the job is removed from the system. This type of system is highly “action” oriented, that is, the administrator decides what action to take, and instructs the system to initiate that action. Once the action is complete, the system returns to an idle state, and does not initiate any more activity until specifically told to do so by an administrator.
With another type of ESD system, certain targets, such as network user objects, computers or other device containing embedded software, are “entitled” (referred to herein as an entitlement) to have a certain package. The system keeps track of whether the package has been applied to a given system, and installs the package if it is needed. This type of system may not take action immediately or any automated actions whatsoever. If the entitlement is made to a user, for example, the system may not take any action until that user logs on to a system. After the user has logged on, the system may deploy the entitled package.
The conventional job-based ESD system is limited since it has no way of reacting to the current state of a machine. To accomplish state management, the administrator must know what the state of the managed computers is ahead of time, either by maintaining a strict, detailed and cumbersome history of the computers, or by monitoring the data returned by an asset discovery system.
Conventional ESD systems are unable to effectively determine if the software that is associated with the package is actually installed or not. For example, the existing entitlement-based systems only track whether their proprietary package was applied to the system or not. As these packages are typically used to wrap the install programs from the software vendor, if the software is removed later, either by the user or by another package, the system will not know to reapply it. Similarly, if the software already existed on the system, either because it was installed before the ESD system was in place, or because it was part of the initial image of the computer, these ESD systems would not be able to recognize that the software was already in place and would attempt to re-install it.
Additionally, conventional ESD systems do not offer the flexibility and/or the features as described below in accordance with embodiments of the present invention.

SUMMARY OF THE INVENTION

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention are illustrated by way of example, and not limitation, in the accompanying figures in which like references denote similar elements, and in which:
FIG. 1 is a system diagram in accordance with an embodiment of the present invention;
FIG. 2 illustrates a block diagram of an agent in accordance with an embodiment of the present invention;
FIG. 3 is a block diagram of a server in accordance with an embodiment of the present invention;
FIG. 4 is flowchart illustrating a method in accordance with an embodiment of the present invention; and
FIG. 5 is flowchart illustrating a method in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

Embodiments of the present invention provide an automated electronic software distribution and/or management ESDM system and method that provides, for example, effective state management across a disparate environment. Embodiments of the present invention may provide an ESDM that may use asset discovery data to execute software delivery, installation, removal and/or management. In one embodiment of the present invention, the automated ESDM system may explicitly query the managed device(s) prior to installation and/or removal of software. Embodiments of the present invention may provide scripts that may be run on one or more devices. The scripts when processed, by a managed client may download, remove and/or otherwise process software programs, for example.
Embodiments of the present invention, may provide a platform including integrated asset discovery (inventory, discovery, tracking and reporting), software distribution (application deployment, license management, self healing, disaster recovery), software migration (OS migration, validation, data back up), detailed real time analytical reporting and/or optimized ESDM planning and scheduling. Embodiments of the present invention may provide a license distribution and/or management system.
Embodiments of the present invention may provide a web-based tool that may allow, for example, management of software updates for managed computers. For example, embodiments of the present invention may permit control of how and/or when the updates to managed computers are installed. Additional features that may be provided include but are not limited to repair and/or removal of software as well as hardware devices, deployment of mandatory updates, and/or provisioning of scripts on remote devices. A script may be macro or batch file including a list of commands and/or instructions that may be executed on a managed client without user interaction, for example. The script may be written in any suitable language.
FIG. 1 is an automated ESDM system 10 in accordance with an embodiment of the present invention. As shown in FIG. 1, ESDM system 10 may include one or more enterprise systems (ES) 14 that may be coupled to one or more master servers (MS) 12 via a transit network 16. The MS 12 may include and/or may be coupled to a database (DB) 18. The ES 14 may include one or more on-site servers (OSS) 24 coupled to one or more databases (DB) 28. The OSS 24 may be coupled to one or more remote site servers (RSS) 22. In embodiments of the present invention, the RSS 22 may be coupled to one or more managed clients 20. The clients 20 may be one or managed computers, servers, communications devices (e.g., routers, switches, etc.), consumer appliances, vehicles, and/or any other device or item.
In an embodiment of the present invention, the transit network 16 may be a communications network that may include, for example, a public switched telephone network (PSTN), an Integrated Services Digital Network (ISDN), a cellular network, a digital mobile network, a Personal Communication Systems (PCS) network, an Internet, an intranet, a signaling system 7 (SS7) network, a local area network (LAN), a satellite network, an advance intelligent network (AIN), any suitable digital or analog network, a broadband network such as a cable network, any other public and/or private network, any other suitable national and/or international communications network or any combination thereof.
In embodiments of the present invention, the various components shown in ESDM system 10 may be coupled by wired (e.g., optical, electrical, etc.) and/or wireless means. For example, the MS 12 may be coupled to the transit network 16 by a optical and/or a wireless connection. The managed clients 20 may be coupled to the RSS 22 and/or the OSS 24 by wired and/or wireless means. Although, the managed clients 20 are shown coupled to the RSS 22, it is understood that the managed clients 20 may be coupled directly to the OSS 24 and/or to the master server 12. Therefore, the RSS 22 and/or the OSS 24 may be bypassed. In addition, the functionality of any component in ESDM 10 may be provided in any other component. It is further recognized that the OSS 24, RSS 22 and/or the MS 12 may be provided in a single device. Although not shown, the MS 12 can be connected to more than one ES 14. In such a configuration, each ES 14 may be a separate campus within a larger organization, such as a geographically diverse corporation or government entity.
In embodiments of the present invention, the automated ESDM 10 including the transit network 16, MS 12, DB 18 and/or ES 14 may include one or more switches, communication interfaces, and/or other components that are not shown for convenience. It is recognized that the various types of communications that may be provided in these systems may include hard-line, wireless, RF, optical, and/or any other type of communications or any combination thereof. The various devices, systems, networks, etc. may be appropriately configured or equipped with hardware and/or software to operate in such environments.
In embodiments of the present invention, the ESDM 10 architecture may include multiple levels including the MS 12, the OSS 24, the RSS 22, and managed clients 20. However, it is recognized that the ESDM 10 architecture may be provided by fewer levels by combining the features of one or more levels, for example. By the same token, the ESDM 10 architecture may include more levels by distributing the features throughout additional components and/or devices.
In embodiments of the present invention, the MS 12, OSS 24 and/or RSS 22 may provide a centralized location where software updates, scripts or the like may be available. Software updates and instructions on how to distribute the updates may be published to the MS 12. The updates, instructions, scripts, etc. may be passed to one or OSSs 24 for distribution, for example. The remote MS 12 may act as a redundant backup system to the OSS 24 located within the ES 14. Connected to the maser server 12 is a database 18 for storing information and data files relevant to the process of preserving data stored on managed computers within ES 14. The updates, scripts, programs, etc. may be stored in a central repository such as DB 18 and/or DB 28.
The DB 28 coupled to OSS 24 may additionally contain information about individual managed client 20 such as their disk size, memory, last user, IP address, and the like. In addition, the DB 28 may contain “entitlements” which are associations between clients 20 and application software that is permitted to be loaded on the clients 20. The entitlements may be represented as database records that associate application software program(s) with the computers 20 based on a device identifier and a user login identifier. The entitlements for a particular managed device may be set by a user via the console 30. If a client 20 is entitled to a software product, as indicated by the OSS 24, for example, the agent 32 may poll one or more of the other components (e.g., RSS 22, OSS 24, MS 12 and/or DB 28, in FIG. 1), and may retrieve its entitlement. The software package indicated by the entitlement, which may stored on the RSS 22, for example, may be downloaded directly from the RSS 22 to the client 20.
In embodiments of the present invention, one or more of the servers (e.g., MS 12, OSS 24, and/or RSS 22) may provide remote access (e.g., web access) where users can log-in to check on installation status, program status, health and/or other information related to clients 32. In one embodiment of the present invention, the MS 12 may receive replication information from the OSS 24 and/or RSS 22 for reporting purposes, for example.
In embodiments of the present invention, the OSS 24 may resides at an operational center and/or may be the repository for all customer activity. The OSS 24 may communicate all activity with each RSS 22 which may be located at customer sites, for example. The OSS may also provide reporting services as well as replicating all its information to for example, the MS 12. Embodiments of the present invention may include an alternate OSS 24 that may serve as a backup and/or alternative monitoring and/or access point. In some cases, some information from an alternate OSS 24 may be restricted to certain functions or information. For example, the alternate OSS 24 may be restricted only to entitlement information or the like.
In an embodiment of the invention, the OSS 24 may include a management console 30. The console 30 may provide an ESDM administrator with the ability to view and/or manipulate data in an ESDM hierarchical directory. The directory may provide the listing of all customers and/or clients assigned to the OSS 24. Customer and/or clients may include other on-site servers, remote site servers and/or clients. Customers and/or clients may be organized in cluster or other arrangement. A cluster may be a grouping of servers, computers or other devices with an order defined in the cluster. It is recognized that the servers, computers, etc. can be dynamically grouped into the proper cluster container, for example. The console 30 may permit administrators to, for example, control, monitor and preserve inventory, and/or schedule, audit or deploy the managed computer systems and software operations.
In embodiments of the present invention, the RSS 22, like the OSS 24, the RSS 22 may exist as a stand alone computer and/or may co-exist with another server on the same physical computer, for example. The RSS 22 may be coupled to and/or may serve a network or the like that may include one or more clients 20. Optionally or additionally, the RSS 22 may replicate with its associate OSS 24 over, for example, the Internet via HTTPS or other protocol. In some cases, RSS 22 may be a client that hosts an agent (to be described below in more detail) that points to itself for entitlement and monitoring purposes. It is recognized that multiple servers 22 may be connected to a single OSS 24.
As indicated above, the clients 20 may be one or managed computers, servers, communications devices (e.g., routers, switches, etc.), consumer appliances, vehicles, and/or any other device or item. The clients 20 may be coupled to the RSS 22, OSS 24 and/or MS 12 by any type of wired and/or wireless connection. One or more of the clients 20 may include a managed agent 32. The agent 32 may be a hardware and/or software component that may periodically contact the RSS 22, for example, for a request for an instruction. Once the instruction is received, the agent 32 may process the instruction in accordance with embodiments of the present invention. The server may provide a polling interval for the agent to poll the RSS 22, OSS 24 and/or MS 12. Optionally and/or additionally, the polling interval may be a pre-determined periodic interval. In embodiments of the present invention, agent 20 may be incorporated into an RSS 22, MS 12 and/or OSS 24. If the agent 20 runs on one or more of these servers, the agent 32 may be used to update deployment system software on these servers, for example.
Clients 20 may include various types of computers, such as conventional desktop personal computers (PCs), portable computers (notebooks, laptops), workstations, computer network servers or any other device that has embedded software and is capable of networked communication. Each device 20 may include conventional computer components, such as a processor, random access memory (RAM), one or more local hard drives, OS software, application software, data files, network interface hardware and software, and the like. In an embodiment of the invention, one or more clients 20 may runs a Windows® OS available from Microsoft® Corporation of Redmond, Wash.
In embodiments of the present invention, the managed client 20 may be an incorporated into an computer, automobile, consumer appliance, cell phone or other type of communication device (pager, satellite phone, etc.), personal digital assistant (PDS), and/or any other device that processes a software program, application and/or data.
In an embodiment of the present invention, the clients 20 may be organized into groups, with each group being networked to a corresponding RSS 22, for example. The RSS 22 and its corresponding clients 20 may be connected together by a conventional local area network (LAN), such as Ethernet or a wide area network (WAN), to permit communication and transfer of data files. The grouping of the clients 20 and hierarchical structure of the ES 14 may permit parallel execution of the migration process or software deployment among the computers. If the RSS 22, OSS 24 and/or MS 12 provide a license distribution and/or management system, the server(s) may manage and/or distribute licenses to one or more clients 20 that may be part of a group such as a LAN, WAN or the like.
In embodiments of the present invention, the RSS's 22 may be networked to an OSS 24 using a commercially-available LAN or WAN. The OSS 24 may be a centralized server that is configured to initiate and control program deployment to the managed clients 20 across the ES 14. To accomplish this, the OSS 24 may include, among other things, a browser console 30 and is connected to an onsite DB 28.
The browser console 30 may be a web browser application that permits a user to enter commands that control the data preservation and/or application deployment process. The console 30 may also provide processing status and reports to the user, and permits the user to set entitlements, foe example.
In an embodiment of the present invention, the agent 32 may include a system management program written in, for example, C++ and/or may run as a Windows® system service. The agent 32 may poll the RSS 22, OSS 24 and/or MS 12 (e.g., via HTTPS or other protocol) for any requests or instructions, for example. In response, the server(s) may provide entitlement programs, scripts, install and/or un-install instructions, and or other operations, for example, to be processed by the managed client 20. Moreover, these operations may include, for example, the installation, removal and/or repair of software, installation, removal or repair of scripts and/or the installation, repair and/or removal of hardware. The agent 32 may accept Microsoft® Installer packages, for example, as content from the RSS 22. The RSS 22 which the agent 32 is to poll may be predetermined during agent installation and/or may be dynamically determined by the agent 32 and/or by the RSS 22, OSS 24 and/or MS 12, for example. This setting may be stored in a registry located in the agent 32 or in an external registry, for example.
In embodiments of the present invention, it is recognized, that the agent 32 may receive instructions from OSS 24 and/or MS 12 as well as RSS 22. Moreover, in embodiments of the present invention, the RSS 22, OSS 24 and/or MS 12 may contact the agent 32 and request information and/or may instruct the agent to perform one or more operation or task.
In embodiments of the present invention, the agent 32 including the system management program may collect hardware and/or software information from the client 20 system that it is installed on. For example, the agent 32 may collect system, status, and/or health information from the hard drive, the random access memory (RAM), the processing unit such as the CPU, the basic input-output system (BIOS), etc. This information may be part of the asset inventory of the system. The agent 32 may use any type of interface or tool such as the Windows WMI and/or Win32 APIs or the like to get the desired information. For example. to collect software information, the agent 32 may use the Microsoft Windows® Installer database APIs (contained and populated on Windows 2000 systems by MSI based content) along with the uninstall key of the Windows® registry. The information collected by the agent 32 may be formatted in, for example, extensible markup language (XML) and may be posted to the RSS 22 and/or the OSS 24.
In one embodiment of the present invention, the ESDM system may only permit a pre-determined number of clients to be monitored by the RSS 22, for example. Thus, the RSS 22 may maintain count of the number of licensed systems for any given customer that are being monitored by the RSS 22. If the number of licensed connections is exceeded, the RSS 22 may not allow additional connections and an error will be logged. The RSS 22, depending on configuration, may seek permission to allow additional connections and may report the additional connections to the OSS 24 and/or MS 12, for billing purposes or the like.
In embodiments of the present invention, the agent 32 and/or the RSS 22, for example, may monitor the number of, for example, licensed program applications that are present on one or more managed clients, and/or one or more networks. For example, the RSS 22 may receive license keys or other licensing related information related to the program applications from clients 20. The RSS 22 may validate the information to determine if, for example, the provided keys are authentic. Once the information is validated, the RSS 22 may determine if, for example, the client has an authorized version of the program. If the client is determined to have an unauthorized version of a program, the RSS 22 may warn the user and/or may offer to provide and/or purchase the client 20 with an authorized version of the application program. If the client agrees to purchase a valid version of the program, a install script may be sent to the manages client by the server. The client may arrange to make payments for the purchased program by appropriate means (credit card, debit card, check, etc.). On the install script is processed by the managed client, the purchased program may be downloaded and/or installed in the managed client. If however, the client does not wish to purchase the program, an remove script may be sent to the managed client from the server. The remove script may be processed by the agent to un-install and/or delete the unauthorized version of the program. In embodiments of the present invention, if an unauthorized version of the program is present on the managed client, a trial version of the program may be provided by the server or an offer interface to retrieve a valid version of the program, as described herein, may be provided to the managed client.
In embodiments of the present invention, when the agent 32 is installed, the fingerprint for the X.509 certificate, for example, of the RSS 22 to which the agent is to communicate with may be imported and/or declared valid. The agent 32 may utilize the Microsoft Windows 2000 WinINet APIs (a standard Win32 Library) for HTTPS and SSL V3 communications, for example, for communications. The agent 32 may communicate with its designated RSS 22 over the suitable port such as HTTPS port 8443 and 443. It is recognized that the ports 8443 and 443 are given by example only and that the server can be configured to communicate over any port.
In an embodiment of the present invention, an agent 32 may, for example, contact the OSS 24 and/or RSS 22 at regular intervals and may request instructions from the OSS 24 and/or RSS 22. Once the instructions are received, the agent 32 may process the received instructions. For example, these instructions may direct the agent 32 to gather and return asset inventory data, and/or may direct the agent 32 to install or remove a software package from client 20.
In embodiments of the present invention, inside the OSS 24 and/or RSS 24, a task processor may receive requests from agents 32, and based on the request may compare the current state of the managed client 20 (based on the data returned from asset discovery) against the entitlements stored in an directory. If there is a discrepancy between what is entitled and what is currently installed in the managed client 20, the task processor may automatically generate the instructions to either add and/or remove programs necessary to bring the system to the desired state. Optionally or additionally, the task processor of the OSS 24 or RSS 22 may also send instructions at regular intervals to cause the agent to resend its asset inventory data.
In one embodiment of the invention, the servers (e.g., MS 12, OSS 24 and/or RSS 22) may use a hierarchical directory that may provide the listing and/or access to, for example, all customers and/or clients assigned to the respective server. The directory, usually referred to as a serviceability directory, may be based on based on, for example, the IEEE X.500 standard. See, International Organization for Standardization/International Electrotechnical Commission 9594-1 (1993). As an X.500 based directory, this system may have three types of container objects. The highest level container type is referred to as the “country”. Underneath the country, it is possible to have zero or more “organization” containers, and under the organization, it is possible to have zero or more “organizational unit” containers. The organizational unit can contain both leaf objects and other organizational units. Leaf objects include “system” objects, such as Networks and Servers, “targets”, such as Users, Computers, Groups and Containers, and “products”. It is recognized that the directory standard is given by way of example only and that any type of directory format may be employed in embodiments of the present invention.
When used in a multi-server environment, the directory may be stored in a decentralized structure. All servers 22 and/or 25 may have a full copy of the portion of the directory that they need. Servers that share parts of the directory may keep the data consistent across servers by using a replication process.
In embodiments of the present invention, the concept of an entitlement involves the interaction of three objects, a target, a product and an entitlement. Targets may be objects in the directory, and include users, computers, devices, applications, groups and/or containers. The relationship between these objects can be explained in that targets are entitled to products. In other words, entitlement objects represent a many-to-many relationship between targets and products. While an entitlement may be made to a single target, it may ultimately be applied to many computers if it is made to a group or container.
In embodiments of the present invention, when a computer is being analyzed for new tasks, the following process, for example, may used to find entitlements. All entitlements made directly to the computer target may be considered. Entitlements made to the computer's parent container are considered, followed by its grandparent and so on to the root. Entitlements made to any groups that the computer belongs to are considered. The groups may be processed in alphabetical order, and each group's containers may also be considered. Next, entitlements made to the primary user target for the computer are considered and again, containers are also processed. Finally, groups that the user is a member of may be considered. This process may provide provides the system administrator with more flexibility in delivering, managing, monitoring, migrating, and/or inventorying software.
In embodiments of the present invention, a server such as RSS 22 may be designated as a “local server” for one or more clients 20. An installation may also have other server objects that represent peer installations. The other servers can be used to send polling agents to other installations that may be physically closer, or otherwise more appropriate for a particular client 20.
A network object may represent an IP subnet, or other range of IP addresses. The network may be used in a multi-server installation to approximate a physical location for a given agent or client. For example, when an agent 32 polls a server 22, the server 22 may first attempts to match the requesting IP address to a network object that it has in its directory. If a network is found, the server list that may be mapped to the network is examined. If the current server 22 is in the list, then the poll is passed on to the task processor of server 22, for example. If the current server 22 is not in the list, the list may be sent to the agent 32, along with a command to reset, so that the agent can redirect itself to another more appropriate server. The agent may examine the received list, identify an appropriate server from the list and may poll that server for a request for instructions.
In embodiments of the present invention, the agent 32 may include a system management program that is run on the managed client 20. The program may be designed to be run continuously, as long as the system is on or the program may only operate for certain periods of time. For example, on Windows® NT based systems (e.g. Windows® NT, 2000 and XP), this means that the agent 32 may normally run as a system service. On other platforms, for example, the agent 32 may be executed at system startup, and allowed to run continuously as a daemon until system shutdown.
FIG. 2 is a diagrammatic representation of an agent 32, in accordance with an embodiment of the present invention. It is recognized that agent 32 may be a software program, a hardware device and/or any combination thereof. The agent 32 may be part of the hardware and/or software that exists in the managed client 20 or may be a separate unit and/or may be a combination thereof. In embodiments of the present invention, the agent 32 may be modular, and may include, for example, a polling module 27, an inventory module 29, and/or a one or more instruction handlers 25. It is recognized that the agent may include other components which have been omitted from this description for simplicity. The polling module 27 may be responsible for making, for example, an HTTP call to the server 22 on a regular interval, downloading an instruction from the server 22, using the appropriate instruction handler 25 to process the instruction, and/or for sending the results back to the server 22.
In embodiments of the present invention, the instruction handler 25 may process the one or more instructions received by the polling module 27. The instruction handler 25 may work query the inventory module 29 for the status of existing software and/or hardware to fulfill the received instructions. In one example, the inventory module 29 may include inventory data is broken up into groupings called “catalogs.” Each catalog may include a collection of related data, for example, a list of installed peripheral component interconnect (PCI) devices, for example. In one case, the data for the catalog may be collected by the agent 32 in XML format. However, it is recognized that the data may be collected in any other format. The catalogs may be serialized using standard Java® serialization mechanisms, for example. The catalogs may be stored on the servers file system as individual binary files or may be stored in a database, for example. Catalogs may also be converted to and from XML using “Castor” technology, for example. Because a catalog may be represented as XML, other views can be generated using extensible style language (XSL) transforms, including hyper text markup language (HTML) and structured query language (SQL), for example.
FIG. 3 is a diagrammatic representation of a server 50, in accordance with an embodiment of the present invention. Server 50 may be any of the servers (or part of any of the servers) of the ESDM system 10. For example, server 50 may be part of MS 12, OSS 24 and/or RSS 22. It is recognized that server 50 may be represented as a software program, a hardware device and/or any combination thereof. The server 50 may include a task processor 51, task queue 53 and/or a license manager 59, for example. Server 50 may include other components that are omitted for simplicity.
In embodiments of the present invention, the server 50 pay process the polling requests, for example, received from agent 32. For example, when an agent 32 polls a server 50 for the first time, the server 50 may set up a number of initialization tasks to execute in a task queue 53 for that agent. At each agent poll, the server 50 may return one or more instructions for each task to the agent for it to process. As the agent 32 executes those instructions and returns the results, the tasks are removed from the task queue 53.
In embodiments of the present invention, the task processor 51 may process the installation of a software package and/or executing an inventory package. The task processor 51 may generate a list of software that is either directly (e.g., made to the computer itself) or indirectly (e.g., made to containers, groups or users) made to the computer. The software on the list may be sorted by product version so that later versions are processed first. The task processor 51 may examine each version of the software on the list and may compare the expected action with the current state of the managed client 20 based on its agent 32. For example, if the current state of the managed client 20 is compatible with (or the same as) the corresponding software on the list being examined, then the software is ignored and there is no updated needed. For example, if a product X, version Y is currently installed on the client 20, then the process to install product X, version Y may be ignored. If however, product X, version Y is not currently installed, then the process to install the product may be used to create one or more tasks that may be added to the task queue 53 for processing. In one example, once one or more tasks corresponding to a software installation is scheduled in the queue 53, the server 50 may discontinue further installations associated with that agent and/or client until the current installation is complete. This action may be take to maintain compatibility. However, it is recognized that the server 50 may continue to process other installations even if a current installation is pending. The server may use parallel processing techniques, for example, to process additional instructions and/or processes.
In embodiments of the present invention, the server 50 may use, for example, a compatibility criteria to determine if a particular software product should be installed and/or removed, for example. For example, a software product is compatible and no further installation associated with that product may occur if, for example, the product is installed or if any later version of the product is installed. If, for example, a lower version of the software product is installed, an updated version of the program may be installed or scheduled to be installed. But, if the latest version of the program or a higher version of the program is installed, then the program may not need to be updated. It is recognized that even if an updated or later version is installed, the same program may be re-installed in the managed client. Moreover, even if the entire program is not installed, additional setting, upgrades, fonts, or other data may be installed.
In an embodiment of the present invention, the server 50 may forward a un-installation instruction or un-installation entitlement associated with a software product. If for example, it is determined that a software or program needs to be partially or completely un-installed and/or deleted from the managed client, the server may send an un-installation and/or delete instruction (and/or script) to the managed client to un-install and/or delete the program. If a program tom be deleted and/or un-installed exists in the managed client with the same or lesser version, then the proper instruction and/or script may be sent to the managed client for processing. The managed client may receive the instruction and/or script and process the instruction and/or script to un-install and/or delete the program. This process can be done at any time and indicated by the server or as determined by the managed client, administrator, and/or user. It is recognized that preconditions may be set before a program can be un-installed and/or deleted from the machine. If, for example, a proper license exists for an upgraded program, the old program may not me un-installed and/or deleted until the upgrade is scheduled and/or completed. Of course, other checks may also be made before programs are removed. For example, data associated with the program to be un-installed and/or removed may be backed up by the client and/or server so that the data is not lost and can be available at a later time.
Embodiments of the present invention may provide a license authorization script or instruction that provides an offer interface (e.g., an offer icon) on, for example, a managed client's computer. The offer interface may provide a program offer to install a valid program in the managed client, for example. If the offer icon is selected and/or a valid license is authorized to the managed client, a program associated with the offer icon and/or license may be downloaded by the managed client. In embodiments of the present invention, once the program has been exited and/or use otherwise terminated, the program may be automatically deleted and/or un-installed, and the program license may be available to others if requested via offer interface located on other machines. Accordingly, an authorized license can be validly used by several users under the terms of the license.
In embodiments of the present invention, the offer interface may be compatible if the same software of any version is not yet installed, or if the same software with any version is already installed. An offer interface associated with any program may be installed on a client's machine. This could be a new program or a program that is already installed. In the latter case, an administrator or user may want to change status of the program from actually having a copy of the program loaded on the machine at all times to having “access” to the program when needed and allowing others to used the program when not needed or when “use limits” are passed, for example. In embodiments of the present invention, “use limits” may, for example, indicate a predetermined number of uses for the program, a predetermined time the program may be used and/or any combination thereof. Once the use limit has been reached, the program may be un-installed and/or may be deleted. It is recognized that use limits can be set for programs downloaded via the offer interface as well as other programs, as described herein.
In embodiments of the present invention, an install entitlement for an offer interface may be designed to be compatible twice, with different behaviors. For example, first, an offer interface installation with use limits may follow the same compatibility rules as a normal install entitlement. In other words, an offer interface may be installed for any existing or new programs. Then, when the product catalog indicates that the time since the software has been used on the client machine has surpassed the use limit specified in the entitlement, the entitlement becomes compatible again, this time to change the installation to an offer interface state. In other words, when the offer limit has been passed, the associated program may be un-installed and/or deleted. However, the offer interface may remain or may be re-installed on the client's machine for future selection. If the use limit is never reached, then the second behavior may never be realized by the system and the installed product remains installed.
In embodiments of the present invention, installation, removal, and/or the offer interface, for example, may be provided by scripts or other instructions that may be sent from the server to one or more managed clients. The scripts may be processed by the managed client to complete the operation. For example, if the instruction is an instruction to install an updated program, the managed client may process such script to download the program at any time. In some cases the download may be immediate and/or in other cases the download may be delayed. This concept may be applied when programs are un-installed, removed and/or when offer interfaces are processed, for example.
FIG. 4 is a flowchart illustrating a method 400 in accordance with embodiments of the present invention. In an embodiment of the present invention, an agent may poll one or more servers in the ESDM system, as shown in box 410. The poll may include identification data associated with the agent. In other cases, the poll may also include a request for instructions. Once the server receives the poll, the server may verify whether the agent is part of a system that the server is responsible for, as shown in box 415. If the agent is part of the system, then the server may process the agent. If however, the agent is not part of a system the server is responsible, the server and/or a master server may identify and forward the agent to the correct server.
Once the appropriate server is identified for the agent, processing in accordance with an embodiment of the present invention may begin. The server may transmit an asset inventory instruction including a request for the agent to collect and return inventory asset data to the server. As described herein, the inventory asset data may include information related to hardware, software, licensing, etc. installed in the managed client associated with the agent. It is recognized that the agent may be associated with more than one managed client. In addition, the server may provide a polling interval to the agent. The polling interval may provide, for example, an indication when the subsequent polls to the server should occur.
In embodiments of the present invention, the server may receive the asset inventory data from the agent, as shown in box 420. The server may process the asset inventory data received from the agent, as shown in box 430. Based on the asset inventory data, the server may determine if an program is to be installed on the managed client, un-installed and/or deleted from the managed client, and/or if an offer interface is to be provided to the managed client. In addition, the server may provide license management services for one or more agents as described herein. The server may place one of more instructions to be sent to the agent in a queue. As subsequent polls are received, one or more instructions may be sent to the agent for processing.
In embodiments of the present invention, the asset inventory data may be used by the server to established a base-line for the one or more managed clients associated with the agent. The asset inventory data and/or other information may be stored in a database for future use. In embodiments of the present invention, the server may provide the default tasks to those managed clients that have designated hardware and/or software configurations. The default tasks may provide all the managed clients with compatible hardware and/or software. For example, the default tasks may request removal of certain programs while the installation of other programs, for example.
In embodiments of the present invention, the asset inventory data may be processed by the server to determine which programs the managed client is entitled to. If it is determined that a managed client is entitled to a program, the server may transmit an installation script to be sent to the agent so that the entitled program can be downloaded by the agent, as shown in boxes 440 and 443. The installation script may be placed in a queue to be sent to the agent and/or may be sent directly to the agent. Once the agent receives, for example, the installation script, the agent may process the installation script to down load the program, as shown in box 445.
In embodiments of the present invention, the asset inventory data may be processed by the server to determine if a program(s) should be removed (e.g., un-installed and/or deleted) from the managed client, as shown in box 450. If it is determined that a program is to be removed from a managed client, the server may transmit a remove script to be sent to the agent so that the identified program can be un-installed and/or removed from the managed client, as shown in box 453. The remove script may be placed in a queue to be sent to the agent and/or may be sent directly to the agent. Once the agent receives, for example, the remove script, the agent may process the remove script to un-install and/or delete the identified program(s) from the managed client(s), as shown in box 455.
In embodiments of the present invention, the asset inventory data including, for example, licensing data associated with one or more managed clients may be processed by the server to determine if an offer icon may be removed from or installed in a managed client, as shown in box 460. As described herein, the server may perform license management functions to manage program licenses associated with the one or more managed clients. Thus, for example, the server may provide offer icons to the agent so that programs can be installed and/or removed so that valid and licensed programs are available. If it is determined that an offer icon should be installed or removed from the managed client, the server may transmit a offer script to be sent to the agent so that the identified program can be installed or removed from the managed client, as shown in box 463. The offer script may be placed in a queue to be sent to the agent and/or may be sent directly to the agent. Once the agent receives, for example, the offer script, the agent may process the offer script to install or remove an offer icon from the managed client(s), as shown in box 465.
In embodiments of the present invention, the agent may send an acknowledgement to the server when one or more scripts are processed. The acknowledgment may indicate the status of the agent and/or managed client. In embodiments of the present invention, the agent may forward updated asset inventory data to the server. The server may update its stored asset inventory data, as shown in box 470. In embodiments of the present invention, the server may transmit a poll interval to the agent, as shown in box 480. The poll interval may indicate when the server may need additional information from the agent, for example. It is recognized that the agent may poll the server as needed, for example, if there is a status change, other event, or the like, for example.
In embodiments of the present invention, the server may provide a script, file name and/or product code associated the install, remove and/or offer icon data, for example, to the agent.
Embodiments of the present invention may provide a license management system, as part of the ESDM system, which may permit a client such as an independent software vendor (ISV) and/or an Original Equipment Manufacturer (OEM) to maintain an inventory of and/or maximize the efficient use of their software licenses. This license management system may incorporate and/or provide embodiments of the “offer interface” feature described above. The license manager 59 (FIG. 3) may provide a license management service that may for example, detect and/or remove unused or unapproved software from managed systems. The license manager may permit a user to mange and/or update licenses automatically. The license manager may provide a “use limit” value associated with one or more programs, for example, installed on client machines. The “use limit” may indicate when the manager 59, for example, may remove a particular software from the managed client 20 if the inventory indicates, for example, that it has not been used in a specified number of days or if the existing number of copies has exceeded an authorized number of copies.
For example, if the license manager 59 determines that a software is eligible for removal, the task processor may schedule a removal task (e.g., remove script) in task queue 53, for example. The server 50 may send the agent 32 an uninstall script for the software product. The software instruction may be followed by, for example, an offer interface to permit the user to re-install and/or re-activate the software product. The offer interface may provide a offer icon that may allow a program to appear to be installed on a client machine without actually having the binaries in place to run the software. When the user wishes to use the software (indicated by double clicking the offer icon), it is automatically installed. The offer interface may provide one or more programs that do not require a user license until the program is actually installed.
In embodiments of the present invention, any type of technique may be utilized, for example, to inventory the installed software at and/or collect data from the managed client 20. Such techniques may be platform dependant. For example, if the managed client is running the Microsoft Windows® operating system, it may be possible to quickly query the system for a list of installed software using the “Add/Remove Programs” function from the control panel and the contents of the Windows registry. Optionally or additionally, the Microsoft Windows Installer program may be used to obtain a list of installed programs and/or other data associated with the managed client 20. It is recognized that if a different operating system (OS) is used, appropriate interfaces may be available to retrieve the desired information.
In embodiments of the present invention, it may also be possible to determine if a program/application is installed using a concept commonly known as a “signature.” A signature is a collection of attributes of a system that indicate with a high probability that a particular software product is installed. Signatures are usually based on the existence of at least one specific program file, but may also be based on directories, registry entries and/or values from configuration files.
FIG. 5 is a flowchart illustrating a method 500 in accordance with embodiments of the present invention. Initially, the software agent 32 is distributed across the enterprise network to one or more clients 20, as shown in box 510. Agent 32 may be downloaded to the managed client 20 from a networked server in response to a network login script executed by each computer. The login script may include a path designating the location of the agent software to be downloaded. Optionally or additionally, an e-mail attachment or URL link, remote scripting, or other ESD system may be used to distribute the agent 32. An indication may be provided when the agent 32 has been successfully installed. Moreover, additional information may further be provided if the agent 32 is idle, is performing a task and/or has failed to complete a task.
As shown in box 520, the agent 32 may commence an asset discovery and/or inventory process to collect asset information for each client 20. This information may be reported to the RSS 22, OSS 24, MS 12 and/or database 28. The agent 32 may conduct the asset inventory process on its own or based on an instruction received from RSS 22, OSS 24, or the like. In one example, an agent may generate and transmit a request for instructions to a server, as shown in box 530. In response, the server may generate one or more instructions to the agent, as shown in box 540. The asset data may include end-user computer hardware and software characteristics, such as memory size, processor type and speed, resident software, software versions, and the like. The instructions that are received from the server may include instructions to, for example, install software, remove software, repair software, and/or any combination thereof. The instructions may be based on, for example, the asset data collected.
As shown in boxes 550 and 560, the agent may process the appropriate instruction(s) from the server and/or may transmit an acknowledgement to indicate that the instruction was processed to the server, for example.
In embodiments of the present invention, agent 32 may conduct a polling routine in which the agent 32 may periodically poll the OSS 24 via an RSS 22 to check, for example, for programs or its entitlement. The polling may be accomplished using, for example, a hypertext transfer protocol (HTTP) GET command sent to the OSS 24 via the RSS 22 from the client 20. The command may provide provides a device identifier and/or a user login identifier to the OSS 24. The polling period may be parameterized and can be set by a user at the console 30. The period may be set to poll every few minutes, hours, days, etc. The agent 32 may begin a polling routine based on a predetermined event such as of a user manually installs a program and/or the managed client 20 is otherwise modified, for example.
As asset information is collected globally (perhaps over a period of several weeks), a validation routine may run by the OSS 24. This routine may compare the list of supported hardware and minimum computer requirements to the individual asset inventory information gathered by the agents 32 about the clients 20. As a result of this comparison, the agent 32 may identify software and/or hardware that maybe needed. In the case of software, the software may be downloaded as described herein. If hardware is missing, the RSS 22 and/or OSS 24 may determine whether the hardware exists and if it does, may attempt to run the appropriate utility to install the hardware in client 20. If the hardware does not exist, a notice such as via e-mail may be sent to an administrator and/or user to indicate that such hardware is needed. As new hardware and/or software is installed, the DB 28 and/or 18 may be updated.
In response to one or more poll, the agent 32 may receive a response indicating, for example, a location of its entitlement. The response may include a Java® wrapper having a script that gives a path as to where, for example, a Microsoft Windows® Installer (MSI) file may reside on the RSS 22. The Java® wrapper may be in XML and may contain JavaScript. The client 20 may then download the MSI from the RSS 22, and may begin down loading the entitlement.
Embodiments of the present invention may provide for a method, system and apparatus that may repair an existing application on the client 20 through a process known as self-healing whereby the application repairs its own defects, it may install entitled applications and/or scripts, it may uninstall applications and/or it may provide an offer icon.
Embodiments of the present invention describe an ESD system which may provide “state management” or software operations management. In one embodiment, the invention provides for management of software products that are installed on a system or device, and the versions of those software products, conform to “approved” and optimal operating parameters. State management is desirable for a number of reasons, including but not limited to, system stability, standardization, accurate reporting, data and asset management, efficient software distribution and migration, information technology, project scheduling and license management.
Because the number of permutations of different versions of the multiplicity of software products is practically infinite, and because these software products commonly cause conflicts in common components that can render the system unusable causing significant barriers to systems integration and software distribution, it is advantageous from a system stability perspective to limit the amount of diversity in computer systems as much as possible.
In an embodiment of the invention, by controlling the number of different versions of software in a company's environment or customer base, the support staff can more easily test the common scenarios, proactively prevent user problems and react more effectively and efficiently to user dilemmas. For example, in an environment having a limited versions of tested software products, the occurrence of software conflicts may be significantly reduced, and thereby the number of unique configurations that have to be supported may also be reduced. Among other benefits, this leads to better monitoring, tracking, support and/or service to end users.
In addition to system stability, embodiments of the present invention may also provide monitoring of the number of versions of a given software product for license optimization and/or management. If a corporation has a software with “bulk” or “site-wide” licenses which may cover only one version of the software, it is desirable to track software so that only the licensed versions are installed in their environment for license compliance reasons. It may also be desirable for both the manufacturer and purchaser to track that they have too many or too few of any type of software license. Embodiments of the present invention provide many of the various features as described herein.
It is recognized that embodiments of the invention may include, for example, components such as processors, computer readable memories, data ports or other interfaces, network ports or other interfaces, data buses and/or other hardware and/or software components (all not shown). The data ports or other interfaces may permit the various devices to communicate with other devices and/or with the transit network and/or information info-structure. The data buses may connect the processor, the computer readable memory, the data port or other interface and/or the network port or other interface and may permit communications between the various components in embodiments of the invention.
Several embodiments of the present invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.

Claims

1. A method comprising:

receiving a request for instructions from a managed client machine;

analyzing the request for instructions, wherein the request for instructions includes asset inventory data;

generating one or more instructions based on the request for instructions and the asset inventory data, wherein the one or more instructions include an instruction to install an application on the managed client machine; and

receiving an acknowledgment from the managed client machine if the instruction has been processed.

2. The method of claim 1, further comprising:

queuing the one or more generated instructions in a task queue;

transmitting the queued one or more instructions to the managed client machine;

if the acknowledgment from the managed client has been received, removing the instruction from the queue.

3. The method of claim 2, wherein the application is a script.

4. The method of claim 1, further comprising:

establishing a priority associated with each of the one or more instructions; and

queuing the one or more generated instructions based on priority.

5. The method of claim 1, wherein the one or more instructions include an instruction to remove an application on the managed client machine.

6. The method of claim 1, wherein the one or more instructions include an instruction to repair an application on the managed client machine.

7. A system for automated software distribution comprising:

an agent associated with a managed client to generate a request for instructions; and

a server coupled to the agent, wherein the server is to:

receive the request for instructions from the agent;

analyze the request for instructions;

generate one or more instructions based on the request for instructions;

transmit the one or more instructions to the agent, wherein the agent is to process the one or more instructions; and

receive an acknowledgment from the agent if the one or more instructions have been processed.

8. The system of claim 7, wherein the request for instructions includes asset inventory data associated with a managed client.

9. The system of claim 8, wherein the one or more instructions is based on the request for instructions and the asset inventory data.

10. The system of claim 7, wherein the one or more instructions include an instruction to install an application on the managed client.

11. The system of claim 7, wherein the one or more instructions include an instruction to install an offer icon on the managed client.

12. The system of claim 7, wherein the one or more instructions include an instruction to remove an application on the managed client.

13. The system of claim 7, wherein the one or more instructions include an instruction to repair an application on the managed client.

14. A method implemented on a computer for automatic software distribution, comprising:

receiving a request for instructions from a managed client machine;

15. The method of claim 14, further comprising:

queuing the one or more generated instructions in a task queue;

transmitting the queued one or more instructions to the managed client machine;

16. The method of claim 15, wherein the application is a script.

17. The method of claim 14, further comprising:

queuing the one or more generated instructions based on priority.

18. The method of claim 14, wherein the one or more instructions include an instruction to remove an application on the managed client machine.

19. The method of claim 14, wherein the one or more instructions include an instruction to repair an application on the managed client machine.

20. A license management method comprising:

receiving a request for instructions from a managed client;

analyzing the request for instructions, wherein the request for instructions includes licensing data;

determining whether the licensing data associated with a program installed on the managed client is valid;

if the licensing data is not valid, sending an offer to purchase a valid version of the program to the managed client; and

if the offer to purchase is not accepted, sending a remove instruction to the managed client to remove the program.

21. The method of claim 20, further comprising:

if the offer to purchase is accepted, sending the valid version of the program to the managed client.

22. The method of claim 21, sending the valid version of the program comprising:

sending an install script to download the valid version of the program to the managed client.

23. The method of claim 20, further comprising:

if the offer to purchase is not accepted, sending an offer interface to the managed client, wherein the offer interface providing an offer icon to purchase a valid version of the program to the managed client.

24. A method for managing a computer software program license, the method comprising:

providing an offer icon to a managed client device, wherein the offer icon is associated with a program;

in response to a selection of the offer icon, transmitting an install script to the managed client device, wherein the install script permitting a download and installation of the program to the managed client device;

receiving an exit indication that the managed client device has terminated use of the downloaded program; and

in response to the indication, transmitting an remove script to the managed client, wherein the remove script permitting removal of the program from the managed client device.

25. The method of claim 24, wherein removal of the program comprising:

un-installing the program from the managed client.

26. The method of claim 24, wherein removal of the program comprising:

deleting files associated with the program from the managed client.

27. The method of claim 24, further comprising:

determining if licensing information associated with the program is valid;

if the license information is valid, determining if the managed client has exceeded an use limit associated with the program; and

if the use limit has been exceeded, sending an offer to purchase an additional license associated with program to the managed client.

28. A method comprising:

receiving a poll from an agent;

receiving asset inventory data from the agent if the agent is verified;

based on the asset inventory data, determining if a managed client associated with the agent is entitled to a program;

if the managed client is entitled to a program, transmitting an install script to download the program to the agent;

based on the asset inventory data, determining if an existing program, installed on the managed client, should be removed from the managed client; and

if the existing program should be removed, transmitting a remove script to un-install the existing program from the managed client.

29. The method of claim 28, further comprising:

transmitting a poll interval to the agent.

30. The method of claim 28, wherein the remove script to delete the existing program from the managed client.

31. The method of claim 28, further comprising:

receiving updated asset inventory data from the agent, wherein the updated asset inventory data based on the downloaded program and the n-installed existing program.

32. The method of claim 31, further comprising:

storing the received asset inventory and the updated asset inventory data in a memory.

33. The method of claim 28, further comprising:

receiving an acknowledgment from the managed client if the install script has been processed.

34. The method of claim 28, further comprising:

receiving an acknowledgment from the managed client if the remove script has been processed.

35. The method of claim 28, further comprising:

based on the asset inventory data, determining if an offer icon should be installed on the managed client;

if the offer icon should be installed, transmitting an install offer icon script to the agent.

36. The method of claim 28, further comprising:

based on the asset inventory data, determining if an offer icon should be removed from the managed client;

if the offer icon should be removed, transmitting a remove offer icon script to the agent.

37. A system for providing automated software distribution and management, comprising:

an agent associated with a managed client to generate a poll;

a server coupled to the agent, wherein the server is to:

receive asset inventory data from the agent;

based on the asset inventory data, determine if the managed client is entitled to a program;

if the managed client is entitled to a program, transmit an install script to the agent, wherein the agent to process the install script and based on the install script, the agent is to download the program to the managed client.

38. The system of claim 37, wherein based on the asset inventory data, the server is to:

determine if an existing program, installed on the managed client, should be removed from the managed client; and

if the existing program should be removed, transmit a remove script to remove the existing program from the managed client.

39. The system of claim 38, wherein based on the remove script, the agent is to:

un-install the existing program from the managed client.

40. The system of claim 39, wherein if the existing program is in-installed from the managed client, the server is to:

send an offer interface to the agent and the offer interface to provide an offer icon to purchase the program to the managed client.