Method, system, and program for executing operations on a client in a network environment

[0002] 1. Field of the Invention

[0003] The present invention relates to a method, system, and program for executing operations on a client in a network environment and, in particular to an enterprise computing environment wherein ultimate control rests with a centralied server authority.

[0004] 2. Description of the Related Art

[0005] In a client/server environment managed by a central authority, such as a corporate network administrator, the network administrator may perform various system management functions at the client machines used by employees, customers, or other users of corporate resources operating at client computers. Such network management functions may include providing program updates, monitoring and scanning files to determine the clients configuration, using the client as a console, etc. The Tivoli Systems Inc. (Tivoli) Tivoli Management Agent (TMA) provides a framework to allow a network administrator to perform network management operations such as software distribution, inventory scanning, user administration and distributed monitoring. The TMA software is installed on a client to allow the client to function as part of a larger computing enterprise managed by the network administrator. The TMA software executes a TMA daemon in the client, which is activated to provide the central administrator certain levels of control over client operations.

[0006] For instance, Tivoli Inventory allows the network administrator to automatically scan clients to collect hardware and software configuration information from client systems. Tivoli Inventory is used with Tivoli Software Distribution to determine the updates the clients need to conform to system configuration requirements and allow a technical support consultant to better diagnose problems at the client by reviewing the clients configuration. Tivoli Remote Control allows a network administrator complete real-time remote control and the ability to quickly establish connections, control desktop systems, and distribute applications executing across multiple clients.

[0007] There is a need in the art for an improved method, system, and program for performing enterprise wide operations.

[0008] Preferred embodiments disclose a system, method, and program for executing operations on a client computer transmitted from a server over a network. A server operation is received indicating actions to perform on the client. A determination is made as to whether the requested operation is permitted according to a set of rules. The requested operation is executed on the client if there is no rule that prohibits the requested operation. The server is then notified that the requested action completed or that the requested action was not executed because of one rule prohibiting execution of the operation.

[0009] In further embodiments, an override code associated with the requested operation is processed. The requested operation that is prohibited because of at least one rule is executed after processing the override code.

[0010] In still further embodiments, a client program executes a server program on the client that is transferred from the server to the client. The server program performs the steps of providing the requested operation to the client program and notifying the server of one of the results. The client program performs the steps of determining whether the requested operation is permitted according to the rules and executing the requested operation if there is no rule that prohibits the action.

[0011] Preferred embodiments provide a mechanism to allow client computers in a network/client environment a certain degree of control over the execution of network operations transmitted from a central server. With preferred embodiments, the centralized server authority is notified as to the client's execution of server initiated operations. Further, the server may provide an override code with the operation to cause the client to execute the server initiated operation notwithstanding the effort by the client to set a rule to block such operations. In this way, in an enterprise computing environment ultimately managed by a central authority, users at clients have a certain degree of control to block or limit server actions attempting to affect the client, with the caveat that the ultimate control and determiner of whether the client may block operations lies with the centralized server authority.

[0012] Referring now to the drawings in which like reference numbers represents corresponding parts throughout:

[0013] FIG. 1 illustrates a computing environment in which preferred embodiments in accordance with the present invention are implemented;

[0014] FIG. 2 illustrates software components within a client in a network environment in accordance with preferred embodiments of the present invention;

[0015] FIGS, 3a, billustrates logic to allow a client to determine whether to perform program actions provided from a server program; and

[0016] FIG. 4 illustrates logic implemented by the server program to determine how to respond to the client's processing of the program actions provided by the server program.

[0017] In the following description, reference is made to the accompanying drawings which form a part hereof, and which illustrate several embodiments of the present invention. It is understood that other embodiments may be utilized and structural and operational changes may be made without departing from the scope of the present invention.

[0018] Although large scale enterprise client/server environments may allow a centralized administrator to insure a certain level of control and commonality among all enterprise clients, certain server operations intended to be performed on all clients may produce certain undesirable results with respect to specific client machines. For instance, an enterprise wide removal of an application, or update, may interfere with a user at a client running the program that is subject to the enterprise wide action for a critical or important purpose. A user at a client may determine that certain enterprise wide operations, such as updates, inventory scans, etc., may adversely impact the user's computing. Current enterprise systems do not provide the user a certain level of control over such enterprise wide operations to allow client users to optimize their particular and unique computing situation.

[0019] Current firewall and security products allow a client connected to a network, such as the Internet, absolute control to determine whether to filter or block network requests and transmissions from other computers based on rules the client specified. For instance, ATGUARD** software from WRQ Inc. runs on a personal computer and monitors network traffic at the computer. The user may define a rule to cause the AtGuard software to intervene in network connections and block data requests from other computers in the network communicating over a network connection. Such firewall software is intended to respond to every request from another computer. In particular, such firewall software can, according to user specified rules, block images, block requests for field information and cookies to reduce the amount of targeted advertising received, block others from retrieving configuration information, and prevent the local web browser from running Java applets, JavaScript, and ActiveX controls to increase protection from potentially invasive programs.

[0020] **ATGUARD is a trademark of WRQ Inc.; WINDOWS and NT are registered trademarks of Microsoft Corporation; POWERPC, AIX, and RS/6000 are registered trademarks of International Business Machines Corporation; PENTIUM is a registered trademark of Intel Corporation; SPARCSTATION and SOLARIS OPERATING ENVIRONMENT are trademarks of Sun Microsystems, Inc.; TIVOLI is a trademark of Tivoli Systems Inc.

[0021] However, such current firewall programs are not suitable for an enterprise computing environment where it would be unacceptable to allow the client total control over network administrator communications and enterprise wide operations.

[0022] Thus, there is a need in the art to provide an improved program for performing network administrator functions on clients in an enterprise wide computing environments that would allow client users a certain degree of control over network administrator actions without necessarily usurping total control form the centralized authority.

[0023] FIG. 1 illustrates a hardware and software environment in which preferred embodiments are implemented. A computing environment 2 may comprise thousands of resources, i.e., clients, that are geographically dispersed. These resources may be organized into coupled Tivoli Management Regions (TMR). A TMR server 4 includes the software components, libraries, binaries, data files, and graphical user interfaces (GUIs) needed to install and manage a TMR. The TMR server 4 may be comprised of a server system, such as an IBM RS/6000 OR POWERPC SYSTEMS running AIX, an INTEL PENTIUM system running WINDOWS NT, a SUN SPARCSTATION running the SOLARIS OPERATING ENVIRONMENT, etc.** In preferred embodiments, the TMR server includes the Tivoli Endpoint Manager that maintains information related to the endpoints, i.e., the clients, and to assign an endpoint gateway when the client 6a, b, cperforms the initial login. The Tivoli endpoint gateway provides the primary interface between a set of clients 6a, b, c(endpoints) and the TMR server 4 and may be implemented in servers separate from the TMR server 4. TMA clients 6a, b, cmay be any computer system known in the art that includes the Tivoli Management Agent (TMA) software that causes the computer to submit a certain degree of control to the TMR server 4 in order to function as part of an enterprise wide computing system. Further details of the Tivoli client/network system and the TMA components are described in the IBM publication “All About Tivoli Management Agents,” IBM publication no. SG24-5134-00 (IBM Copyright, September, 1998), which publication is incorporated herein by reference in its entirety.

[0024] The network 10 provides communication between the TMR server 4 and the clients 6a, b, c.The network 10 may be a TCP/IP network, such as an Intranet, the Internet, World Wide Web, or any other network system known in the art, e.g., LAN, Ethernet, WAN, System Area Network (SAN), Token Ring, LocalTalk, TCP/IP, the Internet, etc. Alternatively, there may be separate and different networks between the TMR server 4 and clients 6a, b, c.In preferred embodiments, the network may interconnect thousands of enterprise resources. As discussed, the TMR server 4 may perform numerous network management functions with respect to the TMA clients 6a, b, csuch as software inventory scanning, remote control of client 6a, b, c,security management, software distribution, etc. The TMA software enables the client 6a, b, cto be managed by the TMR server 4.

[0025] The TRM server 4 control applications are classified into either upeall or downcall applications. An upcall application involves placing a daemon or other program in the TMA clients 6a, b, cto perform various actions such as distributed monitoring and console applications. One such upcall daemon running in clients 6a, b, cis the sentry engine, which sends the TMR server 4 messages, displays pop-up messages, sends e-mail runs programs, etc. The messages the sentry engine daemon executing in the client 6a, b, csends to the TMR server 4 are referred to as upcalls.

[0026] Downcall applications involve the TMR server 4 transmitting the downcall application to the TMA clients 6a, b, c.For instance, a software distribution program allows the TMR server 4 to distribute file packets to the TMA clients 6a, b, c.A TMA client 6a, b, cdaemon program, referred to as the Lightweight Client Framework daemon (Icfd) receives a downcall application from the TMR server 4 to execute in the client 6a, b, csystem. The executed downcall application communicates with the lcfd daemon to perform the TMR server 4 requested operations. For the software distribution program, the executing downcall application and lcfd daemon together apply file packets communicated with the downcall application to the TMA client 6a, b, c.

[0027] FIG. 2 illustrates further detail of the software components within a TMA client 6a,which may also be included in other clients in the enterprise such as clients 6b, cand numerous other resources. The TMA client 6aincludes a network daemon 12 which allows the TMR server 4 to communicate downcalls 14 to the client 6aover the network. A network daemon 12 is a process that runs in the background of the client 6aoperations and is designed to handle and process operations related to the downcall application sent from the TMR server 4. The network daemon 12 executes the downcall application 16 and communicates with the downcall application 16 to carry out the operations specified within the downcall application 16, e.g., software distribution, inventory scanning, etc. Also included in the client 6ais a rules database 18 that the network daemon 12 processes upon receiving requests from the downcall application 16 to determine whether to execute the downcall application's 16 request.

[0028] The user of the client 6amay specify through a GUI at the client 6acertain downcall operations that the user does not want performed on the client 6a.However, in preferred embodiments, the extent of the client's 6apower to block downcall operations is determined by the network administrator and is not solely the prerogative of a user at the client 6a.In this way, the rules database 18 can block downcall operations from proceeding. The rules database 18 may further provide more fine-grained control over downcall operations, such as specifying a time period during which the client 6ashould block a specified downcall operation. For instance if a user at the client 6ais running a program as part of a customer presentation for a few hours, the client 6awould probably not want a downcall application 16 to impact the system by updating or removing the program the client 6ais running as part of the presentation. Further, performing inventory scanning and program management functions in general could interfere with the client 6a's performance during such presentations or critical operations. Inventory scanning involves the TMR server 4 sending downcalls to the clients 6a, b, cto determine client system configuration information and store such information on the client configurations in a database for network administrators to access and use to better monitor the clients 6a, b, c.In such case, the user may specify through the client 6aGUI that certain or all downcall operations are not to be performed at all, or just for a limited time period.

[0029] The rules database 18 can provide any level of detail over the control of downcall operations. For instance, the rules database 18 can specify a particular name of a downcall operation to monitor and then specify to block only a subset of operations performed by the downcall operation. For instance, the rules database 18 can indicate monitoring of the software distribution program and then indicate certain specific programs or files that the network daemon 12 should attempt to block. Further, the user of client 6acan specify to only shield such files for a limited period of time. Basically, the client 6acan attempt to manage downcall operations at any level of detail.

[0030] Because preferred embodiments are implemented in an enterprise client/server system where a network administrator is entitled to ultimate control over the clients 6a, b, c,the TMR server 4 may specify that the downcall application 16 should override any blocking efforts by the network daemon 12 during operation.

[0031] FIGS. 3a, billustrate logic executed in the network daemon 12 to determine whether to carry out the operations specified by the downcall application 16. Control begins at block 100 with the network daemon 12 receiving a downcall application 16 from the TMR server 4 over the network. The network daemon 12 executes (at block 102) the downcall operation 16 within the client 6aand then waits (at block 104) to receive a request to perform an operation from the downcall application 16. Upon receiving a requested operation, the network daemon 12 determines (at block 106) whether the rules database 18 includes a rule for the type of downcall operation provided by the downcall application 16. If not, the network daemon 12 performs (at block 108) the operation requested by the downcall application 16. The network daemon 12 then notifies the user at client 6a(at block 110) of the downcall operation performed, e.g., software distribution, inventory scanning, console control, etc., and also notifies (at block 112) the downcall application 16 of the completion or failure of the requested operation.

[0032] If the rules database 18 includes an entry for the requested downcall operation, then the network daemon 12 determines (at block 114) whether the rules database 18 indicates that the specific requested downcall operation should be blocked. For instance, the rules database 18 may include a rule for software distribution, but only specify that the removal, updating and/or installation of specific application programs are to be blocked, not all applications. If the rules database 18 does not specify to block the specific requested operation, then control proceeds to block 108 to perform the requested operation. Otherwise, if the rule database 18 specifies blocking, then the network daemon 12 determines (at block 116) whether the rules database 18 indicates that the specific downcall operation is only to be blocked during a specific time period; operations performed outside of this range are allowed. If a time period is specified in the rules database 18 for the specific downcall operation, then the network daemon 12 checks (at block 118) the system clock to determine whether the current time is within the specified time range. If not, then the downcall operation is allowed and control proceeds to block 108 to perform the requested operation.

[0033] If the specified downcall operation is requested within the blocking time range, then the network daemon 12 determines (at block 120) whether the downcall application 16 provided an override code with the requested operation to cause the network daemon 12 to perform the requested operation notwithstanding any blocking rule set in the rules database 18. In preferred embodiments, the override code is provided with the requested operation. Alternatively, the network daemon 12 may request the downcall application 16 for an override code if there is a blocking rule. If no override code is provided, then the network daemon 12 notifies (at block 128) the user at the client 6athrough a message displayed on a monitor attached to the client 6aof the downcall operation that was blocked according to the user specified rule. The network daemon 12 further notifies (at block 130) the downcall application 16 that the requested operation was blocked as a result of a user specified rule.

[0034] If an override code is provided, then the network daemon 12 (at block 122) executes the previously rejected downcall operation and then sends (at block 124) a notification message to the user at the client 6aindicating that a downcall operation that the user had requested to block was performed notwithstanding the specified blocking indicated in the rules database 18. The network daemon 12 then notifies (at block 126) the downcall application 16 of the completion or failure of the requested operation and that a rule rejecting the operation was disregarded due to the override code. By providing such information, the downcall application 16 may inform the TMR server, and network administrator, about a user's reliance and use of the blocking rule feature to determine the usefulness of such options in the enterprise.

[0035] FIG. 4 illustrates logic executed in the downcall application 16 to request specific downcall operations, such as software distribution, inventory scanning, configuration setting, etc, and handle responses from the network daemon 12. Control begins at block 200 with the network daemon 12 executing the downcall application 16 within the client 6a.The downcall application 16 determines (at block 202) a downcall operation to perform on the client 6aand transmits the downcall operation to the network daemon 12 to execute on the client 6a.At block 204, the downcall application 16 waits for a response from the network daemon 12. Upon receiving the response, the downcall application 16 logs the result of the operation as indicated by the network daemon 12. Such logged result may indicate that the operation was attempted but did not complete due to some system failure or failed operation, that the operation was not attempted due to a blocking rule, that the operation completed, and/or that the operation was attempted after the override code was used to override a blocking rule. The downcall application 16 then determines (at block 210) whether there are further downcall operations to perform, specified within the downcall application's 16 code. If so, the downcall application 16 returns to block 202 to process the next downcall application 16. Otherwise, upon completion of the last downcall operation, the downcall application notifies (at block 212) the TMR server 4 over the network of the status of all operations included in the downcall application 16 as indicated in the log of the results, e.g., whether the operation completed, was blocked and not overridden, was completed after the override was presented, failed to complete due to system failure, etc.

[0036] In preferred embodiments steps 100 and 104 in FIG. 3aand steps 200 and 204 in FIG. 4 may be performed asynchronously of each other, thereby allowing the network daemon and downcall application to concurrently process multiple operations.

[0037] With preferred embodiments, a certain degree of control over how a network administrator may monitor and alter the configuration of the client computers 6a, b, cis devolved to the client 6a, b, cto allow the client 6a, b, cto specify in a rules database 18 that certain network operations are to be blocked. In preferred embodiments, the user is only allowed to block a certain set of network operations, and not all operations. Further, the network administrator may provide an override code with the downcall operations to override any attempt of the client 6a, b, cto block the operation. Thus, preferred embodiments are suitable for controlled client/server environments, such as an enterprise or corporate environment, where a clients are ultimately controlled entities that operate to further the enterprise goals, not individualistic users. In such systems, the clients 6a, b, crelinquish a certain level of control to the network administrator to insure that clients operate effectively as part of a larger enterprise. The preferred embodiments allow the network administrators to provide the clients 6a, b, csome degree of control to optimize their performance and tailor operations for their specific needs. However, at all times, the network administrator can override or limit a client's 6a, b, cability to interfere or block the TMR server 4 client management, monitoring, and control operations.

[0038] This concludes the description of the preferred embodiments of the invention. The following describes some alternative embodiments for accomplishing the present invention.

[0039] The preferred embodiments may be implemented as a method, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. The tern “article of manufacture” (or alternatively, “computer program product”) as used herein is intended to encompass one or more computer programs and data files accessible from one or more computer-readable devices, carriers, or media, such as a magnetic storage media, “floppy disk,” CD-ROM, a file server providing access to the programs via a network transmission line, holographic unit, etc. Of course, those skilled in the art will recognize that many modifications may be made to this configuration without departing from the scope of the present invention.

[0040] Preferred embodiments were descried as implemented with Tivoli client/server software. However, the client and servers may be implemented using any vendor client/server architecture known in the art.

[0041] Preferred embodiments were described with respect to an enterprise system in which there are perhaps thousands of resources managed by one or more servers. However, in alternative embodiments, the preferred embodiments may be utilized with client/server environments including far fewer network resources.

[0042] Preferred embodiments were described with respect to a system in which the network administrator or server performs operations on the client 6a, b, cby executing a downcall application inside the client managed by a client daemon. However, those skilled in the art will appreciate that there are many ways the server can communicate commands and operations to the client, such as sending the commands over the network to cause the client to perform specific actions, thereby avoiding the need to have a separate program executing on the client. The advantage of the downcall application is that it distributes processing to the client, thereby making more resources available to the server.

[0043] In preferred embodiments, a daemon program interacted with the downcall application to perform actions with respect to requests from the downcall operation. In alternative embodiments, the functions performed by the network daemon 12 may be performed by any type of program running on the computer, including daemon programs and/or application programs.

[0044] Preferred embodiments were described with respect to a private centralized authority, such as a corporation or other commercial interest managing the network to accomplish a commercial purpose. However, the preferred embodiments could be applied to centralized managed systems that are not especially commercial in nature, such as governments and other entities that seek to exercise control over network users.

[0045] In summary, the present invention provides a system, method, and program for executing operations on a client computer transmitted from a server over a network. A server operation is received indicating actions to perform on the client. A determination is made as to whether the requested operation is permitted according to a set of rules. The requested operation is executed on the client if there is no rule that prohibits the requested operation. The server is then notified that the requested action completed or that the requested action was not executed because of one rule prohibiting execution of the operation. The foregoing description of the preferred embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.