Patent Grant
7024471
The present application is related to co-pending U.S. patent applications Ser. No. 09/714,761 filed Nov. 16, 2000, and Ser. No. 09/714,760 filed Nov. 16, 2000. The above mentioned patent applications are assigned to the assignee of the present invention. The content of the cross referenced co-pending applications is hereby incorporated herein by reference.
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.
1. Technical Field
The present invention relates to computer network environments. More specifically, the present invention relates to sharing software applications over a server.
2. Description of Related Art
In some computer network environments, system administrators will install applications on a server's shared file system for use by all users, rather than have the application installed on each client's hard drive. By sharing the application on a server, the administrator can improve overall manageability of the environment. The administrator can control which users have access to this application via access control to the shared file system. In addition, the administrator can control and easily upgrade the application with fixes or new support. When the shared application is updated, all users in the environment will be immediately affected by this change. Since all users execute the same level of the application, end user support is greatly improved.
However, many Windows applications cannot just be run from a shared file system. Many applications, when installed, require changes to the base operating system configuration. These changes can be updates to the system registry, files installed in an OS-specific location (e.g. Fonts) or updates to existing system files (e.g. Visual Basic Runtime DLL). Since the user does not install the application on their local system, for they are just executing the application from a share file system, these required operating system configuration changes are not made on the client being used. Thus, when the administrator provides a user access to an application on a server's share file system, the user will be unable to execute this application unless the client base system has the appropriate support installed, i.e. the modifications to the system files that the application requires.
Some applications have tried to address this problem by providing some form of a node install for a shared application. With this support, the user must perform a minimal install on the client prior to using the shared application. Even if the node install support is provided, this support is not satisfactory in some environments. In a restricted end-user environment, the user might not have the appropriate access to install the client node support. In a roaming user environment, when a user logs onto a client machine that has not had the application's client node support installed, the user must install this support for each machine that he or she logs onto, prior to using this application. Lastly, the end user's skills might not be satisfactory to install the node support without error.
Other solutions have been provided to try to address the problems noted above. Management software is provided that will enable an administrator to distribute software updates to the client. This approach is defined by the administrator and controlled when the updates are sent to the client. Not only does this solution require setup and planning on the system administrator's part, all client machines have the software distributed potentially at different times, based on the parameter(s) defined by the administrator. In this case, when a user roams to a machine that has not yet been updated by the administrator, the user will be unable to use the server-based application until such a time as the administrator updates that machine.
In some cases, application loaders were defined that would perform the appropriate client-side modifications upon instantiation of the application. In this case, if a reboot was necessary, large amounts of data must be transferred to the client machine. The user could potentially experience this productivity degradation for each application being launched.
Therefore, it would be advantageous to have a process and mechanism to dynamically update a Windows system with user specific application enablement support. This process would work such that when a user logs into a heterogeneous server from a Windows client, a mechanism would dynamically update the client operating system configuration to provide the necessary application enablement support for the suite of applications assigned by the system administrator. Thus, by the time the desktop program presented the user with the user's specific desktop configuration, the client would be enabled to run all assigned server-based applications.
The present invention provides a method and apparatus for updating client computers with user specific application enablement. The invention involves creating a component control file on a network server, which defines the actions to be performed to install an enablement component needed to run an application on a client and creating an installation control file which contains a list of the enablement components needed to run the set of applications that have been assigned to a user. The enablement components are changes to the operating system's configuration.
When a user logs onto a client computer, a mechanism in the client reads the user's installation control file and then installs the necessary enablement components on the client operating system, if those components are not already installed. In one embodiment, the user receives a prompt before the components are installed, in case the user does not want to use the entire set of assigned applications.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
With reference now to the figures,
In the depicted example, a server 104 is connected to network 102 along with storage unit 106. In addition, clients 108, 110, and 112 also are connected to network 102. These clients 108, 110, and 112 may be, for example, personal computers or network computers. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108-112. Clients 108, 110, and 112 are clients to server 104. Network data processing system 100 may include additional servers, clients, and other devices not shown.
In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the TCP/IP suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN).
Referring to
Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to network computers 108–112 in
Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, data processing system 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.
Those of ordinary skill in the art will appreciate that the hardware depicted in
The data processing system depicted in
With reference now to
An operating system runs on processor 302 and is used to coordinate and provide control of various components within data processing system 300 in
Those of ordinary skill in the art will appreciate that the hardware in
As another example, data processing system 300 may be a stand-alone system configured to be bootable without relying on some type of network communication interface, whether or not data processing system 300 comprises some type of network communication interface. As a further example, data processing system 300 may be a Personal Digital Assistant (PDA) device, which is configured with ROM and/or flash ROM in order to provide non-volatile memory for storing operating system files and/or user-generated data.
The depicted example in
In order for a Windows application to execute from a shared file server, in most cases, the local client operating system must be updated with some application-specific changes. Applications might require changes to the system registry that is not user-specific, HKEY_LOCAL_MACHINE, or files installed to an operating specific location, e.g. fonts.
The present invention requires that this set of changes to the Windows System, required by the application, be available on the server. Since there can be multiple types of changes (e.g. copy a file to the system image versus update the registry with a specific key), this invention defines control information to be defined for each application. Since server-based applications can be served from various server architectures (e.g. Windows, Linux, etc.), the structures defined by this invention allow for portability to the other server types and do not extend/exploit server-specific interfaces or support. This control file can be defined to handle file copies (with level checking and “in use” handling), directory copies (with level checking and “in use” handling) and registry updates (both .REG and .INF formats). This control file is defined on an application by application basis. The format of the control file can be extended to handle other system updates.
Referring now to
Next, the Server Management Support checks if a Component Control File exists for the application being added (step 402). For each server-based application, in which client operating system configuration changes are to occur dynamically for a user, a Component Control File must be defined. If a Component Control File does not exist then the application is assumed to not have any client side changes required (step 403). The design of this control file is such that it can be provided by the application vendor, written by the administrator or created automatically by a utility program. The changes to the client operating system required by an application are referred to as “components”. The format of the Component Control File is as follows:
As a means of maintaining what Component Control Files a user requires, the present invention also defines a user-specific control file, the Installation Control File. This control file contains all of the components required by the set of applications that have been assigned to the user and is maintained in the user's profile area in the server. With this information, a client-side check can be performed to determine what application component(s) must be installed. To enable roaming user support, this control file is maintained on the server in a user-specific location. Thus, when a user roams between client machines, the user-specific control file is accessed to determine what components are required on the client machine that is currently being used.
The following describes the format of the Installation Control File. The format of the Installation Control File can be extended to handle other control information.
When the application is added to a specific user through some interface available to the administrator (or some other appropriate user) at the server, the Installation Control File defining the system changes is appended to contain the component information defined for this application. If an Installation Control File does not exist for the user, one is created with the ComponentID information (step 404). As applications are added to or removed from the user, the contents of this control file are modified to reflect these changes.
For persistence, the control files are maintained on the server. In case of a re-installation of the client, the next time the user logs on, the client will be updated with the user's defined changes. The client will now be able to execute the user's applications that were assigned.
Referring now to
If a component needs to be installed, the mechanism checks if a user prompt is specified (step 505). A mechanism to prompt the user for each application update would be provided to avoid large changes not required by the user on a specific machine. Thus, the user will not need to wait for a large update to a client where they do not plan to execute that application. For example, if a user logs onto a client to check something on the web, the user does not want to wait until the client is enabled for a complete office suite. If prompting is specified, the user will be prompted to install the necessary component (steps 506 and 507). If the user chooses not to install, the process ends and the application is not installed on the client (step 508).
If the user does choose to install the necessary component, or if user prompting is not specified, the client-side mechanism will apply the necessary changes (step 509). This process runs locally on the client and applies the changes dynamically for the user. Client updates, with version information, are maintained in the general system information portion of the client's registry. This process checks the current level of the client and applies only the changes required for the user's defined environment.
After the necessary component is installed, the mechanism returns to step 504 and repeats the process until there are no more entries. Once all necessary components for the loaded applications are installed, the client continues the logon process (step 510). Since some system changes require a re-boot to take effect, this agent will determine the state and dynamically reboot the client if required (after all updates are applied). Upon completion, the user will be able to execute the applications on the client where they just authenticated (step 511).
The following provides a more technical description of the Installation Control processing flow:
It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions in a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5497463 | Stein et al. | Mar 1996 | A |
| 5627886 | Bowman | May 1997 | A |
| 5724521 | Dedrick | Mar 1998 | A |
| 5784563 | Marshall et al. | Jul 1998 | A |
| 5794052 | Harding | Aug 1998 | A |
| 5828887 | Yeager et al. | Oct 1998 | A |
| 5832505 | Kasso et al. | Nov 1998 | A |
| 5920725 | Ma et al. | Jul 1999 | A |
| 5960204 | Yinger et al. | Sep 1999 | A |
| 5974547 | Klimenko | Oct 1999 | A |
| 5999740 | Rowley | Dec 1999 | A |
| 6026438 | Piazza et al. | Feb 2000 | A |
| 6029196 | Lenz | Feb 2000 | A |
| 6044465 | Dutcher et al. | Mar 2000 | A |
| 6066182 | Wilde et al. | May 2000 | A |
| 6074434 | Cole et al. | Jun 2000 | A |
| 6091411 | Straub et al. | Jul 2000 | A |
| 6105063 | Hayes, Jr. | Aug 2000 | A |
| 6151643 | Cheng et al. | Nov 2000 | A |
| 6212564 | Harter et al. | Apr 2001 | B1 |
| 6272545 | Flanagin et al. | Aug 2001 | B1 |
| 6389589 | Mishra et al. | May 2002 | B1 |
| 6418466 | Bertram et al. | Jul 2002 | B1 |
| 6421777 | Pierre-Louis et al. | Jul 2002 | B1 |
| 6446260 | Wilde et al. | Sep 2002 | B1 |
| 6496865 | Sumsion et al. | Dec 2002 | B1 |
| 6510466 | Cox et al. | Jan 2003 | B1 |
| 6523166 | Mishra et al. | Feb 2003 | B1 |
| 6574618 | Eylon et al. | Jun 2003 | B1 |
| 6584568 | Dircks et al. | Jun 2003 | B1 |
| 6654032 | Zhu et al. | Nov 2003 | B1 |
| 6691176 | Narin et al. | Feb 2004 | B1 |
| 6757720 | Weschler, Jr. | Jun 2004 | B1 |
| 6947974 | Mosbarger et al. | Sep 2005 | B1 |
| 20020123984 | Prakash | Sep 2002 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20020107945 A1 | Aug 2002 | US |
