System and method for custom installation of an operating system on a remote client

FIELD OF THE INVENTION

The invention relates to the field of computing, and more particular to techniques for interrogating a remote client device to install a customized operating system, such as on a diskless or other computer.

BACKGROUND OF THE INVENTION

Computer networks of increasing size and complexity have resulted in corresponding challenges to network installation and maintenance. For instance, a company may deploy a large collection, from dozens to thousands or more, of personal computers or other client machines to support database, email or other services. Some of those machines may be thin network clients, lacking a hard drive or other mass storage medium. Others may contain a hard drive or other storage, but be prone to random hardware failures. In these cases and others, it may become difficult for a systems administrator or others to get a machine to boot into an operating system, such as the Microsoft Windows™ NT™, Windows™ 2000, Windows™ XP™ or other operating systems.

Remote installers designed to inject an operating system into a diskless or failed machine are commercially available. Those platforms typically transmit a small kernel of relatively primitive operating code, such as Microsoft DOSTM, to a target machine to instigate file access and other operation. However, such platforms are not capable of installing a relatively comprehensive operating system, such as the aforementioned varieties of Microsoft WindowsTM, nor are they capable of detecting various types of installed hardware on the target machine, to customize the transmitted operating system accordingly. Other problems exist.

SUMMARY OF THE INVENTION

The invention overcoming these and other problems in the art relates in one regard to a system and method for custom installation of an operating system on a remote device, involving in one regard a support server equipped with a builder engine to interrogate and respond to a remote client machine to transmit an executable image of an operating system, for instance over a network. In embodiments, the builder engine may receive a machine state image from the remote client, indicating for instance the presence, absence or malfunction of a hard drive or other storage, available electronic memory and other resources. The builder engine may then assemble an appropriate image of an operating system, to transmit over the network to the client. The invention in this regard may thus generate a hardware-independent boot of the client device, which in embodiments may be carried out without a need for a separate setup phase for the operating system. In embodiments, the remote client may subsequently generate a local file system, for instance in electronic memory, under control of the operating system image. Once that and other necessary elements are installed and executing the client may perform operations such as running application software or performing other tasks. In embodiments, once the operating system image has been initiated on the remote client, the client may for instance link to another network resource, for instance to install a complete image of an operating system to replace the initial image, or to perform other tasks.

BRIEF DESCRIPTION OF THE DRAWINGS

<ul id="ul0001" list-style="none" compact="compact"><li>Fig. 1 illustrates an architecture in which an embodiment of the invention may operate.</li><li>Fig. 2 illustrates a data construct for an operating system request packet, according to an embodiment of the invention.</li><li>Fig. 3 illustrates a data construct for a product settings record, according to an embodiment of the invention.</li><li>Fig. 4 illustrates a data construct for a response packet delivered to a client, according to an embodiment of the invention.</li><li>Fig. 5 illustrates a flow diagram of initialization and loading of an operating system kernel, according to an embodiment of the invention.</li></ul>

DETAILED DESCRIPTION OF EMBODIMENTS

Fig. 1 illustrates an architecture in which an embodiment of the system and method for installation of an operating system on a remote device may operate. In this environment as shown, a client 102 may communicate with a support server 112 via a communications link 110 to exchange machine-specific information to prepare the generation and transmission of a customized operating system kernel 136 to initialize or operate the client 102. The delivery and initiation of the operating system kernel 136 may in embodiments may be executed without a need for a separate setup phase.

In embodiments, the client 102 may be or include, for instance, a personal computer running the Microsoft Windows™ 95, 98, Millenium™, NT™, 2000 or XP™, Windows™CE™, MacOS™, PalmOS™, Unix, Linux, Solaris™, OS/2™, BeOS™, MacOS™, VAX VMS or other operating system or platform. Client 102 may include a processor 108, for instance a microprocessor such as an Intel x86-based or Advanced Micro Devices x86-compatible device, a Motorola 68K or PowerPC™ device, a MIPS, Hewlett-Packard Precision™, or Digital Equipment Corp. Alpha™ RISC processor, a microcontroller or other general or special purpose device operating under programmed control. Client 102 may furthermore include a basic input output system (BIOS) 104, which may for instance be stored on flashable EPROM (electronically programmable read only memory electronic memory) or other electronic or other media. Client 102 may likewise contain electronic memory 106 such as random access memory (RAM) or EPROM (electronically programmable read only memory), and other associated components connected over an electronic bus, as will be appreciated by persons skilled in the art. Client 102 may be equipped with an integral or connectable cathode ray tube (CRT), liquid crystal display (LCD), electroluminescent display, light emitting diode (LED) or other display screen, panel or device for viewing and manipulating files, data and other resources, for instance using a graphical user interface (GUI) or command line interface (CLI). Client 102 may also be or include a network-enabled appliance such as a WebTV™ unit, radio-enabled Palm™ Pilot or similar unit, a set-top box, a networkable game-playing console such as Microsoft XbOx™, Sony Playstation™, Sega Dreamcast™ or a browser-equipped or other network-enabled cellular telephone, or other TCP/IP client or other device.

In embodiments, the client 102 may for instance be a diskless machine, that is, a computer or other client which is not equipped with a hard drive or other comparatively permanent storage medium. In that configuration client 102 may lack a stored copy of a functioning operating system, or a stored copy of an installer for an operating system, so that client 102 must be initialized with a functioning operating system or kernel before productive use. In other embodiments, client 102 may contain storage such as a hard drive, CDROM or rewritable CDROM or other magnetic, optical or other media, but that media may be disabled or malfunctioning to an extent that prevents the client 102 from booting into an operating system, or continuing to operate under the control of a functioning operating system. In all cases, the client 102 may communicate with the support server 112 to receive an operating system kernel 136 which contains selected application programming interfaces (APIs), drivers, information (INF) files and other resources tailored to the installed hardware of client 102, to initiate and operate that machine.

Client 102 may for instance be powered on, detect and begin to load BIOS 104. In embodiments, the BIOS 104 may contain network-enabled code, such as the Intel Corp. Pre-Boot Execution Environment (PXETM) protocol which may automatically identify the client 102 to communications link 110, prior to or without a successfully booted operating system. This may permit client 102 to communicate with support server 112 over communications link 110, without the necessity of a loaded operating system. Client 102 may, for instance, in embodiments transmit data in the dynamic host configuration protocol (DHCP) to the support server 112. The BIOS 104 may identify the client 102 to the communications link 110, for instance, by automatically communicating a network address to the communications link 110, for example a media access control (MAC) or other address or data.

The BIOS 104 or associated code may likewise transmit a request to initiate a process to generate and download an operating system kernel 136 via communications link 110. In embodiments, the client 102 may have booted through BIOS 104 but been unable to load an operating system or other resources from a hard drive or other media, or encountered other hardware or software faults. In such cases, the client 102 may communicate a network address or other data to the communications link 110 via an operating system which traps a fault, network utility or other module or interface, to request the generation of an operating system kernel 136 for repair, maintenance or other purposes.

Whether generated from BIOS 104 or otherwise, client 102 may transmit a request packet 132 to initiate the generation and downloading of operating system kernel 136 when heeded. An exemplary data structure for request packet 132 is illustrated in Fig. 3. As shown in the figure, the request packet 132 may contain data elements representing or related to the hardware and software state of the client 102, and other information. For instance, the request packet 132 may include information regarding the hardware architecture of the client 102, indicating for instance that the processor 108 is an Intel Corp. x86TM- based device, or other part. The request packet 132 may include information regarding the presence of add-in devices, such as network card, video or sounds cards or other peripherals, detected for example via a peripheral component interconnect (PCI) bus or Plug-and-Play (PnP) enumeration.

Request packet 132 may furthermore include one or more flags to alter the configuration of operating system kernel 136, as well as specific values for MAC or other addressing information. Other data fields and constructs are possible.

The request packet 132 may be transmitted over communications link 10 to support server 112. Communications link 110 may be, include or interface to any one or more of, for instance, the Internet, the World Wide Web, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network) or a MAN (Metropolitan Area Network), a storage area network (SAN), a frame relay connection, an Advanced Intelligent Network (AIN) connection, a synchronous optical network (SONET) connection, a digital T1, T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, an Ethernet connection, an ISDN (Integrated Services Digital Network) line, a dial-up port such as a V.92, V.90, V.34 or V.34bis analog modem connection, a cable modem, an ATM (Asynchronous Transfer Mode) connection, or an FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connection. Communications link 110 may furthermore be, include or interface to any one or more of a WAP (Wireless Application Protocol) link, a GPRS (General Packet Radio Service) link, a GSM (Global System for Mobile Communication) link, a CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access) link such as a cellular phone channel, a GPS (Global Positioning System) link, CDPD (cellular digital packet data), a RIM (Research in Motion, Limited) duplex paging type device, a Bluetooth, BlueTeeth or WhiteTooth radio link, or an IEEE 802.11 (Wi-Fi)-based radio frequency link such as 802.11a, 802.11b, 802.11g or other protocol. Communications link 110 may yet further be, include or interface to any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, a Fibre Channel connection, an IRDA (infrared) port, a SCSI (Small Computer Systems Interface) connection, a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection.

The support server 112 may receive the request packet 132 to process an operating system kernel 136 to transmit to client 102, or take other action. In embodiments, the support server 112 may contain database, network interface and other resources to evaluate request packet 132 and respond with an appropriate operating system kernel 136. The support server 112 may be or include, for instance, a workstation running the Microsoft Windows™ NT™, Windows™ 2000, MacOS™, Unix, Linux, Xenix, IBM AIX™, Hewlett-Packard UX™, Novell Netware™, Sun Microsystems Solaris™, OS/2™, BeOS™, Mach, Apache, OpenStep™ or other operating system or platform. As illustrated, the support server 112 may contain a dispatcher module 114, communicating with communications link 110 to receive and transmit TCP/IP or other data packets to client 102 or other nodes. The dispatcher module 114 may likewise communicate with builder engine 116 which may manage the construction of operating system kernel 136, and perform other tasks. Builder engine 136 may consist of one or more software modules or other routines or resources to extract appropriate components for operating system kernel 136, and perform other tasks.

As illustrated, builder engine 116 may communicate with one or more storage resources, including image store 128 and product store 118. Product store 118 may contain a collection of product identifiers, software components and other resources needed to build an instance of a given requested product. For instance, in embodiments the request packet 132 may contain a request to build an instance of the Microsoft Windows 2000TM operating system to install into the electronic memory 106 of client 102. In that case, the builder engine 116 may select components for an operating system kernel 136 based upon that product, such as for instance registry files and structures, APIs, drivers, INF (information) files, other file or directory structures, utilities, program shells, user interfaces, graphical or rendering engines, or other system resources or services.

Product processor 120 may likewise interact with product store 118 to populate product store 118 with appropriate components for response to request packet 132. Product processor 120 may for instance contain an INF parser 122 to generate appropriate INF files by communicating with INF set 126 and product settings 124, which may include data or routines to specialize or tune drivers or other resources, depending on the machine configuration of client 102 or other factors.

Product settings 124 may contain data structures and other information as for example illustrated in Fig. 3. As shown in that figure, the product settings 124 may contain settings to be inserted in various keys or other sections of an operating system registry or other resource. In embodiments, individual products, such as client, workstation, cluster, enterprise or other versions or classes of an operating system such as Microsoft Windows 2000TM or other operating systems, may be identified by a GUID field or other data. In embodiments, that field may be stored under a registry key, such as "HKLM\System\CurrentControlSet\Services\Binlbig\Products", or other keys. As shown in Fig. 3, the settings for a given product identified by GUID or other fields may include settings listed under that field in a registry or other system store. The product settings 124 may include for example an architecture specifier, such as x86 or other processors or chipsets. The product settings 124 may likewise contain an indicator for a default startup module to execute, such as "startbm.com" for x86 machines or other modules or routines.

Product settings 124 may also include an indicator for a loader module to load operating system kernel 136, identified by a directory path or other data. Product settings 124 may furthermore include a cache period value, to indicate the lifetime of cached images of loader or other modules, for instance as stored on disk in support server 112, to maintain currency. When used, a default of 30 minutes or other values may be applied, while a value of zero may indicate that no images are to be cached.

Product settings 124 may further include an indicator for a base system registry key to be used. Product settings may similarly include an indicator for boot parameters to apply, such as kernel boot programs to be set in a "boot.ini" or other file., for which a default may be set to "/FASTDETECT" or other values. Product settings 124 may moreover include an indicator for one or more binary directories which will contain binary images of the operating system kernel 136 or modules thereof, or other modules or resources. In embodiments, the directories may be used in the order specified in this key. If a duplicate file appears in different directories, it may be copied from the first directory in this field.

Product settings 124 may likewise include an indicator for INF directories, that is, one or more directories to contain INF files to install operating system kernel 136. Every file having an ".inf" extension may be parsed in each of the specified directories, and in embodiments it may be valid to have the same INF file appear in multiple directories and have different content. For example, one INF directory may be directed to professional stock keeping units (SKUs) reflecting a validly purchased operating system package, while another may be directed to enterprise class SKUs for that same package, and contain INF files with different values in each location, accordingly. In embodiments, the delivery of the operating system kernel 136 may be based upon a subscription service, for instance a paying or non-paying subscription for operating system or other support.

Product settings 124 may yet further contain an indicator for INF classes, identifying one or more INF class strings which may be used, for example, to filter INF files to be parsed in directories. If no INF class is specified, then all INF files may be parsed in the operating system installation process. According to the illustrated settings for this field, the BMonitor (Boot Monitor), System, Network and disk-related INF files may be parsed, and other INF classes may be omitted. Other combinations are possible.

INF set 126 itself may likewise contain one or more INF files for build purposes. The INF files may generally be configured as text files, which in one regard may describe driver files and other data related to devices and resources installed on a client machine. Builder engine 116 may select appropriate drivers and other data from INF set 126 to permit installed peripherals and other parts or resources to be appropriately recognized by an instance of operating system kernel 136 or other software.

Builder engine 116 may likewise communicate with image store 128, which may store images of previously built or modified instances of operating system kernel 136. In embodiments, the builder engine 116 may query the image store 128 after receipt of a request packet 132 to determine if an image of an operating system kernel 136 has already been built and stored for a machine matching or nearly matching the client 102. Image store 128 may contain a hardware image table 130 against which data identifying client 102 may be compared, for instance by way of a hash of hardware component data or other techniques.

Builder engine 116 may retrieve an image of an operating system kernel 136 when a match is found, in order to transmit a responsive build to client 102. Likewise, if a near-match in image store 128 is found, builder engine 116 may retrieve that build and modify that image using product store 118 and other resources to match the specifications of client 102. In instances where little or no overlap exists between the hardware profile of client 102 and the versions stored in image store 128, builder engine 116 may execute a comprehensive build of operating system kernel 136 via product store 118 and other resources.

Before, during or after the build of operating system kernel 136 is complete, the builder engine 116 may communicate a response packet 134 to the client 102 via communications link 110. An exemplary data structure for response packet 134 is illustrated in Fig. 4. As shown in the figure, the response packet 134 may contain data elements representing or related to the status of the response to request packet 132, and other information. For instance, as illustrated the response packet 134 may include information regarding the success or failure of the request, in a flag format or other indicator. The response packet 134 may further contain information regarding the wait time of a pending request, for instance to indicate a period of time before another attempted request packet 132 may be transmitted.

The response packet 134 may furthermore indicate a source address to which the client 102 may go to download the operating system kernel 136, if the operating system kernel 136 is not transmitted directly from support server 112. For instance, in embodiments a remote server may be accessed using the trivial file transfer protocol (TFTP) server at a TFTP address. Other protocols or sources of the file may be used. An image file name of the operating system kernel 136 may also be contained in response packet 134, so that the operating system kernel 136 may retrieved from support server 112, a TFTP server or another server or resource. Other delivery mechanisms are possible.

Upon receipt of the operating system kernel 136, the client 102 may store that kernel in electronic memory 106 to execute file, network and other system functions. For instance, under control of the operating system kernel 136 a directory structure may be built in electronic memory 106, so that data and other files may be separated, stored and worked on. In embodiments, for instance where client 102 contains functional hard drive or other storage, operating system kernel 136 may link to a network site or other resource to perform a full setup and installation of an operating system, followed by a reboot or other actions.

Processing for the generation of a customized operating system according to an embodiment of the invention is illustrated in Fig. 5. In step 502, client 102 may transmit request packet 132 to the support server 112, using the PXE or other resources in BIOS 104, communicated using the DHCP or other protocol. In step 504, the support server 112 may respond with an initial data packet, for instance a TCP/IP or other packet, acknowledging the request packet and containing other data, such as confirming details about the target client 102 or other information.

In step 506, the client 102 may request a network boot program (NBP), or other "sniffer" or initialization module to facilitate further exchange of data for to generate operating system kernel 136. In step 508, the support server 112 may communicate a NBP or other compact or temporary initialization module to the client 102 via communications link 110. In step 510, the client 102 may execute an NBP or other module to request a loader module from support server 112. In step 512, the support server 112 may transmit a loader module to client 102, to facilitate receipt of operating system kernel 136. In step 514, the client 102 may communicate hardware profile information to the support server 112, for instance processor, memory, PnP, PCI enumeration and other data regarding the hardware image of the client 102.

In step 516, the support server 112 may interpret the hardware profile of the client 102 to transmit a hardware image to client 102, such as hardware abstraction layer (HAL), registry or other information for receipt and verification. In step 518, the client 102 may request an image or build or an operating system, for instance via request packet 132 or other structures. During step 518, the support server may access builder engine 116 and generate an operating system kernel 136. In step 520, the support server 112 may communicate the operating system kernel 136 to client rl02. In step 522, the client 102 may perform an operating system boot based on the operating system kernel 136, for instance out of electronic memory 106. After the boot operation of step 522, the client 102 may begin such file, processing, network and other functions as may be supported in operating system kernel 136. In this an other embodiments, the invention may thus complete the installation of a customized operating system kernel 136, without prior knowledge of the particular hardware of client 102.

The foregoing description of the invention is illustrative, and modifications in configuration and implementation will occur to persons skilled in the art. For instance, while the invention has generally been described in terms of delivery of an operating system kernel 136, in embodiments a complete or more comprehensive build of an operating system may be performed, and delivered. Likewise, the builder engine 116 may in embodiments retrieve and build additional software or components, such as selected applications, along with the operating system kernel 136 or other resources.

Likewise, while the invention has generally been described in terms of the analysis of an individual client 102 to which a customized operating system kernel 136 is targeted, in embodiments the hardware receiving the operating system kernel 136 may consist of one or more machines. For instance, a LAN or other facility may contain a number of identical or near-identical machines, only one of which need exchange hardware profile or other request data to trigger the delivery of operating system kernel to multiple machines.

Similarly, while the invention has generally been described in terms of a single support server 112, in embodiments one or more servers may host and respond to various parts of a build requests, and perform other actions. The database or other stores used to house the image store 128, product store 118, product settings 124, INF files 126 and other resources may be similarly distributed. The scope of the invention is accordingly intended to be limited only by the following claims.