US7941814B1 - Device driver processing for automated system restores - Google Patents

Device driver processing for automated system restores Download PDF

Info

Publication number
US7941814B1
US7941814B1 US11/859,982 US85998207A US7941814B1 US 7941814 B1 US7941814 B1 US 7941814B1 US 85998207 A US85998207 A US 85998207A US 7941814 B1 US7941814 B1 US 7941814B1
Authority
US
United States
Prior art keywords
hardware device
computer system
device
recited
virtual
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US11/859,982
Inventor
Okan Okcu
Nicholas R. Graf
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Veritas Technologies LLC
Original Assignee
Symantec Operating Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US10/788,120 priority Critical patent/US7293272B1/en
Application filed by Symantec Operating Corp filed Critical Symantec Operating Corp
Priority to US11/859,982 priority patent/US7941814B1/en
Application granted granted Critical
Publication of US7941814B1 publication Critical patent/US7941814B1/en
Assigned to VERITAS US IP HOLDINGS LLC reassignment VERITAS US IP HOLDINGS LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SYMANTEC CORPORATION
Assigned to BANK OF AMERICA, N.A., AS COLLATERAL AGENT reassignment BANK OF AMERICA, N.A., AS COLLATERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: VERITAS US IP HOLDINGS LLC
Assigned to WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT reassignment WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATERAL AGENT SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: VERITAS US IP HOLDINGS LLC
Assigned to VERITAS TECHNOLOGIES LLC reassignment VERITAS TECHNOLOGIES LLC MERGER AND CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: VERITAS TECHNOLOGIES LLC, VERITAS US IP HOLDINGS LLC
Application status is Active legal-status Critical
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10Program control for peripheral devices
    • G06F13/102Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver

Abstract

In one embodiment, a computer accessible medium comprises a plurality of instructions which, when executed and if a computer system comprises at least one virtual hardware device, identify the virtual hardware device and a corresponding physical hardware device. The plurality of instructions also capture a device driver associated with the physical hardware device for use as the device driver in an install of an operating system on a second computer system having a same type of physical hardware device. Corresponding computer systems and methods are also described.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a divisional of U.S. application Ser. No. 10/788,120, filed Feb. 26, 2004, now U.S. Pat. No. 7,293,272, entitled “Device Driver Processing for Automated System Restores” by inventors Okan Okcu and Nicholas R. Graf.

BACKGROUND

1. Field of the Invention

This invention is related to the field of restoring computer system data from backup and, more particularly, to providing device drivers for restoring to a system.

2. Description of the Related Art

Unattended, or automated, installs of operating systems may be used in a variety of situations. For example, various backup and restore products are used to safeguard software and data state on a computer system. When a failure occurs on the computer system, the failure may be corrected and the computer system state may be restored. Alternatively, a new computer system may replace the failing computer system, and the state may be restored to the new computer system. In either case, so called “bare metal” backup and restore products may begin the restore process with “bare metal” (that is, no software installed on the computer system yet, including operating system software). It may be desirable to install the operating system in an automated/unattended fashion in such circumstances since the restore may be initiated by an administrator/user who is not physically near the computer system to which the restore is being performed. Additionally, it may be desirable to perform the install in an automated/unattended fashion to simplify the restore process and reduce the opportunity for administrator/user error in the process. Other software products may also use automated operating system installs. For example, provisioning software products outfit a computer system with the software resources and configuration needed to perform one or more tasks. Provisioning software may make use of an automated operating system installation to provision a computer system with the desired operating system.

To properly perform an unattended operating system installation, the device drivers used by at least some of the hardware devices in the computer system on which the installation is to occur (the “target computer system”) are required. Device drivers may be more briefly referred to herein as drivers. In some cases, the operating system installation media may include drivers for the hardware devices, but in other cases the drivers must be provided from another source.

Of particular concern are the drivers for any mass storage device (MSD) controllers in the computer system. The operating system is to be installed on the MSDs in the system, and thus the MSDs need to be accessible during the installation process. Accordingly, drivers for the MSD controllers are needed during the installation process.

For some operating systems, such as the Windows™ operating system family from Microsoft Corporation (Redmond, Wash.), a file is used to identify the drivers for installation during a text-mode portion of the installation, prior to starting the operating system itself. For example, Windows expects a file having the name “txtsetup.oem” to identify such drivers. Drivers may be identified using driver information files (“inf” files in Windows) for the graphical-mode portion of the installation (e.g. after the operating system has been started). Various MSD controller manufacturers identify drivers by listing them in either the txtsetup.oem file, in various inf files, or both. Some MSD controller manufacturers do not include a txtsetup.oem file on their installation media, or include a txtsetup.oem file that lists one or more inf files that include the desired drivers. Additionally, if drivers are gathered from another source than a manufacturer's installation medium, there may be no txtsetup.oem file. In some target computer systems, more than one MSD controller is included and the MSD controllers use different drivers. However, Windows expects a single txtsetup.oem file to identify the drivers for each MSD controller.

The VERITAS Bare Metal Restore™ (BMR) product available from VERITAS Software Corporation (Mountain View, Calif.) is one example of a backup/restore product which uses automated operating system installation. Accordingly, BMR creates a txtsetup.oem file for use in a given installation. If the target computer system has more the one MSD controller, information from more than one source may need to be merged into the txtsetup.oem file. Additionally, if no txtsetup.oem file exists, BMR creates one. In previous versions of BMR, the product attempted to process the txtsetup.oem file provided by an MSD manufacturer to identify installation drivers for the text phase. However, in some cases, there is no txtsetup.oem file to process or the txtsetup.oem file does not properly identify the driver. In other previous versions of BMR, the product attempted to process the driver information files instead of the txtsetup.oem file to identify installation drivers for the text phase. However, in some cases, an MSD uses a different driver for the text phase and for the graphical phase (when the inf files are used). The inf files do not specify the correct drivers in such cases.

Another issue encountered in identifying drivers for automated operating system installations occurs when gathering drivers from a running computer system (such as the computer system from which the backup is made). Some computer systems make use of virtual hardware devices. For example, virtual network interface cards (NICs) are often used for fault tolerance and/or load balancing purposes. When in use, a virtual NIC is mapped to a corresponding physical NIC (i.e. a NIC that is physically present in the computer system). Application software and even some operating system software uses the virtual NICs for network communications, and the virtual NICs may pass the communications to and from the physical NICs.

When virtual hardware devices are used, querying the running computer system to identified drivers is more complicated. The virtual hardware devices and physical hardware devices may both be indicated by the system (e.g. using various operating system application programming interfaces (APIs) and/or operating system files such as the Registry in Windows). However, the drivers for the devices may only be associated with the physical hardware devices. Drivers indicated for the virtual hardware devices, in some cases, cannot control the physical hardware devices. Accordingly, if a driver is selected from a virtual hardware device in the running computer system, the correct driver for the physical hardware device may not be identified. Additionally, in some cases, a virtual hardware device includes properties needed for installation and configuration. For example, transport control protocol/internet protocol (TCP/IP) properties may be including in the virtual NICs, in Windows systems.

SUMMARY OF THE INVENTION

In one embodiment, a computer accessible medium comprises a plurality of instructions which, when executed, parse at least a section of an input file to identify: (i) one or more driver information files, if at least one driver information file is listed in the section, and (ii) one or more first device drivers, if at least one device driver is listed in the section. The section corresponds to a hardware device. The plurality of instructions, when executed and if at least one driver information file is listed in the section, parse each of the one or more driver information files to identify: (i) one or more second device drivers, if at least one device driver is included in the driver information file, and (ii) one or more miniport drivers, if at least one miniport driver is included in the driver information file. The plurality of instructions, when executed, select a selected device driver from the first device drivers, the second device drivers, and the miniport drivers. The selected device driver is to be listed in an output file that is used in a text phase of an operating system installation on a computer system that includes the hardware device. A computer system including the computer accessible medium and a processor configured to execute the plurality of instructions is contemplated. A corresponding method is also contemplated.

In another embodiment, a computer accessible medium comprises a plurality of instructions which, when executed and if a computer system comprises at least one virtual hardware device, identify the virtual hardware device and a corresponding physical hardware device. The plurality of instructions also capture a device driver associated with the physical hardware device for use as the device driver in an install of an operating system on a second computer system having a same type of physical hardware device. A computer system including the computer accessible medium and a processor configured to execute the plurality of instructions is contemplated. A corresponding method is also contemplated.

BRIEF DESCRIPTION OF THE DRAWINGS

The following detailed description makes reference to the accompanying drawings, which are now briefly described.

FIG. 1 is a block diagram of one embodiment of a set of servers and clients.

FIG. 2 is a flowchart illustrating one embodiment of installing an operating system.

FIG. 3 is a block diagram of one embodiment of components used to create a txtsetup.oem file for an operating system installation.

FIG. 4 is a flowchart illustrating operation of one embodiment of software to create the txtsetup.oem file.

FIG. 5 is a block diagram of one embodiment of a computer system including hardware devices and corresponding device drivers.

FIG. 6 is a block diagram of one embodiment of a computer system including virtual network interface cards (NICs) and corresponding physical NICs having device drivers.

FIG. 7 a flowchart illustrating detection of devices in a computer system that includes virtual devices.

FIG. 8 is a flowchart illustrating one embodiment of detecting virtual and physical NICs in greater detail.

FIG. 9 is a flowchart illustrating another embodiment of detecting virtual and physical NICs in greater detail.

FIG. 10 is a block diagram of one embodiment of a computer accessible medium.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 is an overview of a backup/restore system that may employ features described herein to identify a driver for a txtsetup.oem file and/or to identify drivers (and optionally other properties) for hardware devices for which the system includes virtual devices as well as physical devices. Other embodiments may use other backup/restore systems. Still further, other embodiments may perform automated operating system installs as part of other systems (e.g. provisioning systems).

Turning now to FIG. 1, a block diagram of one embodiment of a system comprising several servers and clients is shown. In the illustrated embodiment, a BMR server 10, a boot server 12, a file server 14, a backup server 16, and a set of clients 18A-18N are shown. Any number of clients 18A-18N may be included in various embodiments. The BMR server 10 is coupled to the boot server 12, the file server 14 and the backup server 16. The clients 18A-18N are generally configured to interact with the servers 10, 12, 14, and 16, and may be coupled to the servers 10, 12, 14, and 16. FIG. 1 is illustrative of logical relationships between the servers and clients. Physical connection may be established in any desired fashion (e.g. any type of network, combinations of networks, shared memory, etc.).

Each of the clients 18A-18N comprises a computer system that may be backed up and restored using the servers 10, 12, 14, and 16. Data corresponding to each client 18A-18N is backed-up in a respective backup image 20A-20N on the backup server 16. The backup images 20A-20N may be the most recent backup image of each client 18A-18N. Other, preceding backup images corresponding to various clients may also be retained on the backup server 16 or other storage. In some cases when a restore is to be performed, the data in a given backup image 20A-20N may have been backed up from the corresponding client 18A-18N previously, and may be restored due to a failure in the corresponding client 18A-18N (either hardware, software, or a combination thereof) or other loss of the data in the corresponding client 18A-18N. In some cases of a hardware failure in the corresponding client 18A-18N, the failing hardware may be replaced with different hardware. Alternatively, if a restore is to be performed, the data may have been backed up from another computer system (not shown) that subsequently experienced an irreparable failure or is otherwise being replaced by the corresponding client 18A-18N. The backup server 16 may implement any backup solution (e.g. the VERITAS NetBackup™ product from VERITAS Software Corporation, or any other VERITAS backup product or backup product from any other vendor).

At the time that a backup is performed from a client 18A-18N, a record is made of the system configuration of that client 18A-18N. The record is illustrated as the client configuration files 26A-26N in the configuration database 32 on the BMR server 10 in FIG. 1, although the record may be stored in any form. In some embodiments, the client configuration files 26A-26N may be part of the respective backup images 20A-20N as well, or the client configuration files 26A-26N may be stored only as part of the respective backup images 20A-20N and may be retrieved by the BMR server 10 when a client restore is to be performed. In one embodiment, each of the clients 18A-18N may have a config save tool 34A-34N installed to generate the corresponding client configuration files 26A-26N. The config save tool may comprise software (that is, a plurality of instructions) which, when executed, generates the client configuration file.

The client configuration files 26A-26N may store various information describing the corresponding client system 18A-18N configuration. For example, the system configuration may identify the device drivers (or more briefly, “drivers”) used by the corresponding client system. As used herein, a “device driver” or “driver” may comprise any software that is used to control a hardware device included in a computer system and that may provide a higher level (more abstract) interface for other software to use in order to interact with the hardware device. Hardware devices controlled by device drivers may include MSD controllers such as small computer systems interface (SCSI) controllers, integrated device electronics (IDE) controllers, etc. Generally, an MSD controller may be any controller that is capable of interfacing to one or more mass storage devices such as disk drives, tape drives, compact disk (CD) drives, digital versatile disk (DVD) drives, etc. Hardware devices controlled by device drivers may further include NICs or on board circuitry that implements the same function as a NIC. Generally, NICs or corresponding on board circuitry, or any combination thereof, may be referred to as “network interface hardware”. Still further, hardware devices controlled by device drivers may include video controllers/displays, audio controllers, peripheral bus controllers (also referred to as host bus adapters, or HBAs), and any other peripheral devices that may be included in or coupled to a computer system. The client configuration file 26A-26N may further include any other desired information (e.g. the number, type, and size of storage devices in the client system, the volumes on the storage devices, including the layout of volumes on the storage devices and the attributes of the volumes, the number and type of processors, the amount of memory, information on other peripheral devices, etc.).

The file server 14 may provide the clients 18A-18N with various software (reference numerals 22A-22N, respectively) used during the restore process, which may include the operating system software (e.g. operating system commands and libraries), BMR client software, backup client software, etc. The file server 14 may implement any file system usable over a network (e.g. network file system (NFS), Server Message Block (SMB) for Microsoft Windows™ or Samba for Unix-like implementations, etc.). The boot server 12 may be used to provide respective boot images 24A-24N to the clients 18A-18N. When a client 18A-18N is booted to perform a restore, the client 18A-18N may use standard network boot protocols to boot using the respective boot image 24A-24N. The boot images 24A-24N may include a customized restore procedure created by a restore tool 30 on the BMR server 10, to restore the client 18A-18N to the state corresponding to the respective backup image 20A-20N. In some embodiments, a media boot is supported in which the boot image 24A-24N and software 22A-22N are stored on a computer accessible medium such as a compact disc, and the disc is used to boot the client 18A-18N. In such embodiments, the boot server 12 and the file server 14 may be eliminated. In the present embodiment, a client 18A-18N at the beginning of the restore process to that client may be “bare metal”. That is, no operating system software or other software may yet be installed (although firmware may be included in the client). A client 18A-18N that is being restored is referred to herein as the “target client”.

Part of the restore procedure generated by the restore tool 30 includes performing an automated install of the operating system on the target client. If the Windows operating system is to be restored, a txtsetup.oem file is used to identify the drivers that are to be used during the text phase of the installation. In some embodiments, the txtsetup.oem file may be created by the restore tool 30. In other embodiments, the txtsetup.oem file may be created by the config save tools 34A-34N when a configuration save is made. In still other embodiments, the create package tools 40A-40N may create a txtsetup.oem file when creating a driver package 28A-28M. In various embodiments, the txtsetup.oem file may be created at any desired time. The txtsetup.oem file may be included in the files 22A-22N on the file server 14, in the boot image 24A-24N, or may be created and stored onto the target client, in various embodiments. Additional details regarding the creation of a txtsetup.oem file are provided below.

In some embodiments, a driver may be collected from a client system 18A-18N that is using at least one virtual hardware device corresponding to the physical hardware device that the driver controls. For example, the config save tool 34A-34N may be attempting to collect drivers for a configuration save into a client configuration file 26A-26N. Alternatively, the restore tool 30 may attempt to collect a driver from a running system that has the same type of hardware device (that would use the same driver) as the target client has for restoring to the target client. The config edit tool 36 may attempt to collect a driver to list in the client configuration file 26A-26N of the target client. Additional details regarding one embodiment of identifying a driver for a hardware device on a computer system that has at least one virtual hardware device are provided below.

If a backup image 20A-20N is to be restored to a target client that includes different hardware than the computer system from which the backup image 20A-20N was made (referred to more briefly as the “saved client”), the backup image 20A-20N may be modified to execute properly on the target client. For example, if the hardware differences between the saved client and the target client include one or more hardware devices on the target client that use different drivers than the hardware devices on the saved client, the drivers used on the target client are added to the backup image 20A-20N. In some cases, the differing hardware devices may replace hardware functionality of hardware devices that were included in the saved client. In other cases, the differing hardware devices may provide new hardware functionality not included in the saved client. Adding the drivers may involve inserting the driver file (or files) into an appropriate directory in the backup image 20A-20N, and may also include updating one or more operating system files that map drivers to devices (e.g. the registry in the Microsoft Windows™ operating system). The hardware differences between the saved client and the target client may also necessitate a different hardware abstraction layer (HAL) and/or different kernel. The HAL may generally provide a consistent, device independent interface for applications to use, abstracting out various hardware differences across hardware platforms. The kernel may be the central module of the operating system, providing various services to other parts of the operating system (e.g. memory management, disk management, process and task management, etc.). The HAL and kernel may be modified by changing the files containing the HAL and kernel code in the backup image 20A-20N.

In other embodiments, data files in the backup image 20A-20N may be modified. For example, various configuration files used by the operating system software within the backup image 20A-20N may be modified. Particularly, the media access controller (MAC) address of the NIC or NICs in various configuration files may be changed to match the target client.

In one embodiment, the restore tool 30 uses the client configuration file 26A-26N corresponding to the saved client to perform the restore. Particularly, the restore procedure may boot the client using drivers indicated in the client configuration file 26A-26N. In order to restore to different hardware in this embodiment, the client configuration file 26A-26N may be edited to change the driver information for the client, the HAL information for the client, and/or the kernel information for the client. The config edit tool 36 may be used to edit the client configuration file. Generally, the config edit tool 36 may comprise software that, when executed, permits a user to change the features of the client configuration file and either save the changed file as a new client configuration file or overwrite the original client configuration file.

In one embodiment, each of the BMR server 10, the boot server 12, the file server 14, and the backup server 16 may comprise computer systems configured to execute the corresponding server software. In some embodiments, one or more of the servers 10, 12, 14, and 16 may be combined onto the same physical computer system, as desired. Each computer system (including the client computer systems 18A-18N as well) may comprise at least one processor configured to execute the instructions comprising the software illustrated in FIG. 1, memory to store the instructions for execution by the processor, a computer accessible medium to store the instructions, etc.

The drivers provided when the target client has different hardware than the saved client may be drawn from different sources. For example, drivers may be published into a driver database 38 on the BMR server 10. The driver database 38 may comprise various driver packages 28A-28M, each containing driver files and various other driver configuration information (e.g. inf files used in the Microsoft Windows™ operating system). The clients 18A-18N may include a create package tool 40A-40N that may be used to publish drivers into the driver database 38. The user may select drivers from the driver database 38 when editing the client configuration file 26A-26N. Alternatively, drivers may be provided from other sources (e.g. another client configuration file, drivers shipped by the manufacturer of a device on a storage media, drivers downloaded from a network source such as the Internet, etc.).

In the illustrated embodiment, there is a boot image 24A-24N and a software image 22A-22N for each backup image 20A-20N (and for each client 18A-18N). In other embodiments, one boot image 24A-24N may be used for multiple backup images 20A-20N (and for multiple clients 18A-18N). Thus there may not be a one-to-one relationship between boot images 24A-24N and backup images 20A-20N (and clients 18A-18N). Similarly, in some embodiments, one software image 22A-22N may be used for multiple backup images 20A-20N (and for multiple clients 18A-18N). Thus there may not be a one-to-one relationship between software images 22A-22N and backup images 20A-20N (and clients 18A-18N).

Creating a txtsetup.oem File

One embodiment for creating a txtsetup.oem file for a target client is next described. The txtsetup.oem file is used in embodiments in which the Windows operating system is to be installed on the target client. Other embodiments may implement similar features for creating a file used by the operating system to locate the drivers during a text phase of the operating system installation.

Turning now to FIG. 2, a flowchart is shown illustrating one embodiment of the process of installing an operating system, where the process includes both a text phase and a graphical phase. Generally, the text phase includes copying at least a portion of the operating system onto the target client (e.g. onto the MSDs on the target client). The portion of the operating system copied during the text phase comprises at least enough of the core of the operating system to permit the operating system to be started. In some cases, the entirety of the operating system may be copied during the text phase. In other embodiments, the kernel of the operating system and related operating system modules used to start the operating system may be copied, and the remainder of the operating system modules may be copied during the graphical phase. The graphical phase may include the operating system discovering the hardware devices and configuration of the target client. For example, the Windows operating system may install information into the registry in the graphical phase. Among the information installed into the registry is the drivers to be used for the hardware devices in the target client. As mentioned previously, the drivers used in the operating system, installed during the graphical phase, may differ from the drivers used during the text phase in some cases.

During the text phase (block 50), the operating system installation uses the txtsetup.oem file to identify drivers for use on the hardware devices in the target client (reference numeral 52). Particularly, the txtsetup.oem file may identify a driver for the MSD controller in the target client, so that operating system files may be copied to the MSDs on the target client. If more than one MSD controller is included, more than one driver may be identified in the txtsetup.oem file in some embodiments.

During the graphical phase (block 54), drivers are identified for hardware devices using driver information files (e.g. oemsetup.inf in FIG. 2, reference numeral 56). In Windows operating system embodiments, driver information files may also be referred to as “inf” files, after the file extension of the files. Generally, a driver information file may identify drivers to be used for various hardware devices. While one txtsetup.oem file is expected during Windows operating system installs, many inf files may be provided if desired. In some embodiments, the driver information files may also provide additional information regarding the hardware devices.

In Windows operating system embodiments, both the txtsetup.oem file and the inf files may have multiple sections. Each section may correspond to a different hardware device and/or a different driver.

Turning now to FIG. 3, a block diagram is shown illustrating one embodiment of some possible sources of txtsetup.oem files and oemsetup.inf files. Also shown in FIG. 3 is a create txtsetup tool 60, which may comprise software configured to generate an output txtsetup.oem file 62 for use in installing the Windows operating system on the target client. In different cases, one or more of the sources may be used to generate the txtsetup.oem file 62.

For example, one source may be a manufacturer's CD (or other computer accessible media) 64. The manufacturer's CD 64 may be shipped with the hardware device, and may include the drivers and other configuration files that are used with the hardware devices in a client. Particularly, as shown in FIG. 3, the manufacturer's CD 64 may include one or both of a txtsetup.oem file 66 and an oemsetup.inf 68. In other cases, the manufacturer's web site may be a source of drivers and corresponding txtsetup.oem and oemsetup.inf files.

Another source may be a driver package from the driver database 38 (e.g. the driver package 28A shown in FIG. 3). The driver package 28A may include one or both of a txtsetup.oem file 70 and an oemsetup.inf file 72. A third source illustrated in FIG. 3 may be a running client (e.g. client 18A). The client may include one or both of a txtsetup file 74 and an oemsetup.inf file 76.

In some embodiments, the user may identify which source or sources to use for locating input txtsetup.oem and/or oemsetup.inf files to be used to create the txtsetup.oem file 62. In other embodiments, the create txtsetup tool 60 may automatically search a set of sources for the correct files.

The create txtsetup tool 60 may be included in various other software shown in FIG. 1, in various embodiments. For example, as mentioned above with regard to FIG. 1, various embodiments may create a txtsetup.oem file 62 as part of the restore tool 30, the config save tools 34A-34N, or the create package tools 40A-40N. In such embodiments, the create txtsetup tool 60 may be part of any of the above software.

The create txtsetup tool 60 may search both input txtsetup files (e.g. reference numerals 66, 70, and 74) and oemsetup.inf files (e.g. reference numerals 68, 72, and 76) to locate the correct drivers for listing in the output txtsetup.oem file 62. For example, FIG. 4 is a flowchart illustrating one embodiment of the create txtsetup tool 60. That is, the create txtsetup tool 60 may comprise a plurality of instructions which, when executed, implement the operation shown in FIG. 4.

The create txtsetup tool 60 may receive, as input, a section name for a section to parse in an input txtsetup.oem file (reference numeral 80). In the case that a driver has been captured from a client, the input txtsetup.oem file may contain only one section. In other cases (e.g. from the manufacturer's CD 64), the txtsetup.oem file may have several sections. The user may be requested to select the section that is to be processed. Alternatively, each section may be processed, in some implementations. The input txtsetup.oem file may be obtained from any source (e.g. any of the sources shown in FIG. 3).

Each section of the txtsetup.oem file may list zero or more drivers and zero or more inf files, although at least one driver or inf file may generally be listed. For example, the driver files and inf files may be listed by filename and file extension. In some embodiments, a path name may also be supplied if needed. Similarly, inf files may have sections listing one or more drivers.

The create txtsetup tool 60 parses the section of the input txtsetup.oem file to identify any drivers indicated in the section and to identify any inf files in the section. The create txtsetup tool 60 may create a first driver list and a list of inf files, respectively, as a result of parsing the section of the txtsetup.oem file (block 82). That is, the first driver list may be the list of driver file names (and extensions, if applicable) parsed from the section of the input txtsetup.oem file. The list of inf files may be the list of inf file names (and the extension inf, if applicable) parsed from the section of the input txtsetup.oem file.

The create txtsetup tool 60 may parse each inf file in the list of inf files parsed from the input txtsetup.oem file (block 84). Drivers listed in the inf files may be added to a second driver list. Additionally, drivers indicated as miniport drivers may be added to a miniport driver list. As used herein, a miniport driver may be the “main” device driver for a hardware device. Other device drivers may be identified for the device as well. For example, a “driver stack” may be used in which the miniport driver is surrounded by one or more filter drivers. Filter drivers may include upper drivers which reside between the miniport driver and the applications, and lower drivers which reside between the miniport driver and the hardware device. Additionally, “helper” drivers may be defined to perform specific functions. In the case of an MSD controller, the miniport driver may be a SCSI miniport driver.

The first driver list may have the drivers listed in the order that the drivers were found in the section of the input txtsetup.oem file. The initial driver identified in a section of the txtsetup.oem file is supposed to be the miniport driver for the hardware device, but not all manufacturers follow this rule. In some cases, the second driver list and the miniport driver list may also have the drivers listed in the order that they were found in the inf files.

The create txtsetup tool 60 selects a driver to be listed in the output txtsetup.oem file 62 from the drivers listed in the first driver list, the second driver list, and the miniport driver list. To make the selection, the create txtsetup tool 60 selects the initial driver from the first driver list (that is, the driver that was listed in the input txtsetup.oem file before any other driver, if any) and compares the driver to the drivers listed in the second driver list and the miniport driver list. That is, the create txtsetup tool 60 may compare the filenames and extensions of the drivers.

If the initial driver from the first driver list is not listed in either the second driver list or the miniport driver list (decision block 86, “no” leg), the create txtsetup tool 60 uses the initial driver as the initial file listed in the output txtsetup file 62 (block 88). This case may occur, for example, if the hardware device uses one driver during the text phase 50, and another driver during the graphical phase 54.

If the initial driver is listed in at least one of the second driver list or the miniport driver list (decision block 86, “yes” leg), the initial driver is still selected as the initial file listed in the output txtsetup file 62 if the initial driver is listed in the miniport driver list (decision block 90, “yes” leg). In this case, the initial driver from the input txtsetup.oem file has been verified to be a miniport driver, and thus may be suitable for use during the text phase. If the initial driver is not listed in the miniport driver list (decision block 90, “no” leg), the create txtsetup tool 60 selects the initial file from the miniport driver list as the initial file for the output txtsetup.oem file 62 (block 92).

In addition to listing the driver as selected above, the create txtsetup tool 60 may add to the output txtsetup.oem file 62 the list of inf files specified in the input txtsetup.oem file (block 94). However, other drivers may not be listed in the output txtsetup.oem file 62. These other drivers are excluded from the output txtsetup.oem file 62 because the inventors have observed that having additional drivers in the output txtsetup.oem file 62 has created problems for the automated installation. That is, the automated installation did not work in some cases. However, the other drivers may be included in the driver package with the selected driver, so that the other drivers are available on the target client (e.g. for Plug 'n Play installations of the drivers).

FIG. 5 is a block diagram illustrating one embodiment of a client 18A having hardware 100 and one or more device drivers 102, illustrating the relationship of device drivers to hardware devices 104 in the hardware 100. As mentioned above with respect to FIG. 1, a variety of hardware devices may be controlled by device drivers. The hardware 100 may also include other hardware (e.g. a processor 106 configured to execute instructions, including the instructions forming the device drivers 102, a memory 108 configured to store the instructions for execution, data for access by the processor 106, etc.).

Identifying Drivers when Virtual Hardware Devices are Used

FIG. 6 is a block diagram illustrating another embodiment of a client 18A including virtual hardware devices (e.g. virtual NICs, in this embodiment).

In the embodiment of FIG. 6, one or more virtual NICs 110A-110L and one or more physical NICs 112A-112P may be included. Any number of virtual NICs 110A-110L and any number of physical NICs 112A-112P may be included. The number of virtual NICs 110A-110L may be greater than, equal to, or less than the number of physical NICs 112A-112P.

The virtual NICs 110A-110L may be mapped to the physical NICs 112A-112P in any desired fashion. For example, virtual NICs may share a physical NIC (e.g. lines 114 and 116 in FIG. 6). Alternatively, virtual NICs may be mapped to different physical NICs (e.g. lines 114 and 118 in FIG. 6).

A device driver 120A-120P may be included for each physical NIC 112A-112P. Separate physical NICs 112A-112P may use the same device driver 120A-120P in some embodiments, so there may be fewer device drivers than there are physical NICs 112A-112P. The device drivers 120A-120P are associated with the physical NICs 112A-112P (illustrated by the arrows from the device drivers 120A-120P to the physical NICs 112A-112P in FIG. 6), but may not have any direct connection to the virtual NICs 112A-112P. On the other hand, other properties of the NICs may be included in the virtual NICs 110A-110L (e.g. TCP/IP settings in FIG. 6). Such properties may also be used in restoring to a target client, and thus may be captured along with identifying the drivers.

Also shown in the embodiment of FIG. 6 is the hardware 100, including a processor 106 and memory 108, similar to the embodiment of FIG. 5 described above. While virtual NICs are used as an example in FIG. 6, and in the detailed examples of FIGS. 8 and 9, any virtual hardware devices may be used in other embodiments. As used herein, a virtual hardware device may comprise a software-created construct that is used by application programs and/or operating system modules as if it were the hardware device. The virtual hardware device may comprise any combination of data structures and/or software. Each virtual hardware device that is in use is mapped to a physical hardware device. The physical hardware device is the hardware device that is physically present in the computer system. The physical hardware device provides the hardware function for the virtual hardware device.

FIG. 7 is a flowchart illustrating operation of one embodiment of software that may be used to identify the device drivers (e.g. device drivers 120A-120P) that may be used for physical hardware devices when corresponding virtual hardware devices are also in use. For example, the software may be executed on the client 18A shown in FIG. 6 (e.g. by the processor 106). Generally, the software may comprise instructions which, when executed, implement the operation shown in FIG. 7.

The software may identify all devices of the type for which corresponding device drivers are to be identified (block 130). That is, both the virtual hardware devices and the physical hardware devices are in the list of identified devices. Various mechanisms may be used to identify the devices. For example, some operating systems may provide an API for requesting information on the devices in the system. In other cases, operating system databases/configuration files may be consulted (e.g. the Windows operating system's Registry). In still other cases, a combination of APIs and databases/configuration files may be used.

The software may determine if there are virtual hardware devices (decision block 132). A variety of mechanisms may be used to determine if there are virtual hardware devices. For example, if the hardware devices are Plug 'n Play devices, the Plug 'n Play identifiers (PnP IDs) may be used to detect virtual hardware devices. The PnP IDs identify the manufacturer, model number, etc. of the hardware devices, but there are also PnP IDs for legacy devices. The legacy PnP IDs do not identify a specific manufacturer, etc. Since virtual hardware devices are not real hardware devices, they may use the legacy PnP IDs. Another mechanism may be used for NICs. NICs have a MAC address, and the MAC addresses may be compared to detect a duplicate or duplicates. If a duplicate is detected, one of the devices having the duplicate is virtual and the other is physical. More than one duplicate of a given MAC address may be detected if more than one virtual NIC is mapped to the same physical NIC. Other hardware devices may similarly have an address that may be duplicated between a virtual hardware device and the corresponding physical hardware device. Any unique value duplicated between the virtual hardware device and the corresponding physical hardware device may be used to detect duplication and thus to detect virtual hardware devices.

If there are no virtual hardware devices (decision block 132, “no” leg), the software may capture the driver for the physical hardware device or devices (block 134). Also, the software may capture any other properties of the device that may be used for the install, if any (e.g. the TCP/IP settings of a NIC).

If there are virtual hardware devices (decision block 132, “yes” leg), the software may identify the virtual devices and the corresponding physical devices (block 136). Optionally, the software may associate the properties from the virtual device with the physical device, if one or more properties are found in the virtual device instead of the physical device (block 138). For example, for virtual NICs, the TCP/IP settings are found in the virtual NICs rather than the physical NICs, in some embodiments. The software may then capture the driver (and optionally other properties) of the physical device or devices (block 134).

FIGS. 8 and 9 are more detailed examples of a portion of the software illustrated in FIG. 7 that detects the virtual NICs, identifies them, and optionally captures any properties from the virtual NICs into the physical NICs (blocks 130, 132, 136, and 138), for embodiments used with the Windows operating system and for handling virtual NICs. Each of FIGS. 8 and 9 may exit to block 134 in FIG. 7. More particularly, the embodiment of FIG. 8 may be used for the Windows2000™ operating system (and later versions, such as Windows XP™ or Windows 2003™). The embodiment of FIG. 9 may be used for the WindowsNT™ operating system. Other operating systems may use other mechanisms. The software in each embodiment (of FIG. 8 and FIG. 9) may comprise a plurality of instructions which, when executed, perform the operation shown in the respective flowchart.

Beginning with the embodiment of FIG. 8, the software may obtain the service name, the PnP IDs, and the TCP/IP settings for each NIC (block 140). As illustrated at reference numeral 142, the software may use the GetAdaptersInfo API in Windows2000 as well as the Registry to gather the information. In this embodiment, if virtual NICs are included, only information related to the virtual NICs is returned in the GetAdaptersInfo API. If virtual NICs are not used, then physical NIC information is returned.

The software may analyze the PnP IDs to determine if any of them are legacy PnP IDs. For example, in the present embodiment, legacy PnP IDs may all start with Root\\. If none of the NICs are indicated as legacy (decision block 144, “no” leg), then there are no virtual NICs and the flowchart of FIG. 8 may exit to block 134 in FIG. 7. The information obtained from the GetAdaptersInfo and the Registry includes the correct drivers as well as TCP/IP properties in this case.

On the other hand, if at least one NIC is virtual (decision block 144, “yes” leg), the software may obtain the physical adapter information, including the drivers used for each NIC, from the Registry (block 146). The key in the Registry that provides this information is shown at reference numeral 148. If the number of virtual NIC adapters identified in block 140 is greater than the number of physical NIC adapters identified from the Registry (decision block 150, “yes” leg), then at least some NICs have invalid (internal use) IP addresses (e.g. IP addresses of 0.0.0.0 or autoconfigured IP addresses such as 169.256.xxx.xxx). The invalid adapters are eliminated (block 152). With the remaining NIC adapters after the elimination represented by block 152 (or all NIC adapters if the number of virtual adapters is the same as the number of physical adapters—decision block 150, “no” leg), the software compares the MAC addresses to identify virtual/physical NIC pairs (block 154). That is, the virtual NIC and its corresponding physical NIC have the same MAC address. The software updates the TCP/IP settings in the physical adapter information from the TCP/IP settings in the virtual adapter information (block 156). In this fashion, the driver for the NIC and the TCP/IP settings for the NIC are found in the physical adapter's information. The virtual adapter is replaced with the physical adapter (block 158), and the flowchart exits to block 134 to capture the driver and properties of the physical device.

FIG. 9 begins with the software obtaining the adapter info for each NIC adapter from the Registry (block 160, using the key illustrated at reference numeral 162). Both physical and virtual adapters are identified in the Registry in WindowsNT. The software obtains the MAC address of each NIC adapter (block 164) and compares the MAC addresses. If no duplicate MAC addresses are detected (decision block 166, “no” leg), then no virtual NICs are included and the physical NIC information from the Registry correctly identifies the drivers for the NICs and the TCP/IP settings for the NICs.

On the other hand, if at least one virtual NIC is detected via a duplicate MAC address (decision block 166, “yes” leg), the software may, for each adapter that has a duplicated MAC address, obtain the BusNumber from the Registry entry for that adapter (block 168). Physical NIC adapters have a BusNumber in their Registry entries, while virtual NIC adapters do not. Thus, the software identifies the adapter having a duplicate MAC address and no BusNumber as the virtual NIC, and identifies the adapter having that MAC address and having a BusNumber as the corresponding physical NIC (block 170). The software updates the TCP/IP settings of the physical NIC adapter with the settings from the virtual NIC adapter (block 172) and eliminates the virtual NIC adapter 174. The flowchart then exits to block 134 (FIG. 7) capture the driver and properties of the physical device.

As mentioned above with regard to FIG. 1, other embodiments may implement the network interface functionality on board, rather than as a card. Thus, while a NIC was used as an example in FIGS. 6-9, other embodiments may use any type of network interface hardware as an example.

Turning now to FIG. 10, a block diagram of a computer accessible medium 200 is shown. Generally speaking, a computer accessible medium may include any media accessible by a computer during use to provide instructions and/or data to the computer. For example, a computer accessible medium may include storage media such as magnetic or optical media, e.g., disk (fixed or removable), CD-ROM, or DVD-ROM, CD-R, CD-RW, DVD-R, DVD-RW, volatile or non-volatile memory media such as RAM (e.g. synchronous dynamic RAM (SDRAM), Rambus DRAM (RDRAM), static RAM (SRAM), etc.), ROM, Flash memory, non-volatile memory (e.g. Flash memory) accessible via a peripheral interface such as the Universal Serial Bus (USB) interface, etc., as well as media accessible via transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network and/or a wireless link. The computer accessible medium 200 in FIG. 10 may be encoded with one or more of the restore tool 30, the config edit tool 36, one or more config save tools 34A-34N, one or more client configuration files 26A-26N, one or more backup images 20A-20N, one or more create package tools 40A-40N, one or more driver packages 28A-28M, the output txtsetup.oem file 62, the create txtsetup tool 60, and/or other software 202 (e.g. the software illustrated in one or more of FIGS. 7-9). The restore tool 30, the config edit tool 36, the config save tools 34A-34N, the create package tools 40A-40N, the create txtsetup tool 60, and the software 202 may each comprise instructions which, when executed, implement the operation described herein for the software. Generally, the computer accessible medium 200 may store any set of instructions which, when executed, implement a portion or all of the flowcharts shown in one or more of FIGS. 2, 4, and 7-9. In some embodiments, a computer accessible medium similar to the computer accessible medium 200 may be included in a client 18A-18N, the BMR server 10, the boot server 12, the file server 14, and/or the backup server 16.

Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims (21)

1. A computer accessible storage medium storing a plurality of instructions which, when executed:
determine that a computer system comprises at least one virtual hardware device;
responsive to determining that the computer system includes the virtual hardware device, identify the virtual hardware device and a corresponding physical hardware device; and
capture a device driver associated with the physical hardware device to be the device driver in an install of an operating system on a second computer system having a same type of physical hardware device.
2. A computer accessible storage medium as recited in claim 1 wherein the plurality of instructions, when executed, associate one or more properties of the virtual hardware device with the physical hardware device.
3. A computer accessible storage medium as recited in claim 2 wherein the plurality of instructions, when executed, capture the one or more properties for the install of the operating system on the second computer system.
4. A computer accessible storage medium as recited in claim 1 wherein the physical hardware device comprises an input/output (I/O) device.
5. A computer accessible storage medium as recited in claim 3 wherein the I/O device comprises a network interface device.
6. A computer accessible storage medium as recited in claim 4 wherein identifying the virtual hardware device and the corresponding physical hardware device comprises comparing media access controller (MAC) addresses of the network interface devices indicated by the computer system.
7. A computer accessible storage medium as recited in claim 5 wherein the plurality of instructions, when executed, if the number of virtual hardware devices is greater than the number of physical hardware devices, eliminate one or more of the virtual hardware devices by detecting invalid IP addresses for the virtual hardware devices.
8. A computer accessible storage medium as recited in claim 1 wherein the plurality of instructions, when executed, determine if the computer system comprises at least one virtual hardware device.
9. A computer accessible storage medium as recited in claim 8 wherein determining if the computer system comprises at least one virtual hardware device includes determining if at least one hardware device has a plug 'n play identifier indicating a legacy device.
10. A computer accessible storage medium as recited in claim 7 determining if the computer system comprises at least one virtual hardware device includes comparing media access controller (MAC) addresses of the hardware devices indicated in the computer system to detect duplicates.
11. A computer system comprising hardware to execute the plurality of instructions and the computer accessible storage medium as recited in claim 1 coupled to the hardware to supply the plurality of instructions for execution.
12. A method comprising:
determining, by a computer system, that the computer system comprises at least one virtual hardware device;
responsive to determining that the computer system includes the virtual hardware device, identifying, by the computer system, the virtual hardware device and a corresponding physical hardware device; and
capturing, by the computer system, a device driver associated with the physical hardware device to be the device driver in an install of an operating system on a second computer system having a same type of physical hardware device.
13. The method as recited in claim 12 further comprising associating one or more properties of the virtual hardware device with the physical hardware device.
14. The method as recited in claim 13 further comprising capturing the one or more properties for the install of the operating system on the second computer system.
15. The method as recited in claim 12 wherein the physical hardware device comprises an input/output (I/O) device.
16. The method as recited in claim 15 wherein the I/O device comprises a network interface device.
17. The method as recited in claim 16 wherein identifying the virtual hardware device and the corresponding physical hardware device comprises comparing media access controller (MAC) addresses of the network interface devices indicated by the computer system.
18. The method as recited in claim 17 further comprising, if the number of virtual hardware devices is greater than the number of physical hardware devices, eliminating one or more of the virtual hardware devices by detecting invalid IP addresses for the virtual hardware devices.
19. The method as recited in claim 12 further comprising determining if the computer system comprises at least one virtual hardware device.
20. The method as recited in claim 19 wherein determining if the computer system comprises at least one virtual hardware device includes determining if at least one hardware device has a plug 'n play identifier indicating a legacy device.
21. The method as recited in claim 19 wherein determining if the computer system comprises at least one virtual hardware device includes comparing media access controller (MAC) addresses of the hardware devices indicated in the computer system to detect duplicates.
US11/859,982 2004-02-26 2007-09-24 Device driver processing for automated system restores Active 2026-08-11 US7941814B1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/788,120 US7293272B1 (en) 2004-02-26 2004-02-26 Device driver processing for automated system restores
US11/859,982 US7941814B1 (en) 2004-02-26 2007-09-24 Device driver processing for automated system restores

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/859,982 US7941814B1 (en) 2004-02-26 2007-09-24 Device driver processing for automated system restores

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/788,120 Division US7293272B1 (en) 2004-02-26 2004-02-26 Device driver processing for automated system restores

Publications (1)

Publication Number Publication Date
US7941814B1 true US7941814B1 (en) 2011-05-10

Family

ID=38653554

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/788,120 Active 2026-01-22 US7293272B1 (en) 2004-02-26 2004-02-26 Device driver processing for automated system restores
US11/859,982 Active 2026-08-11 US7941814B1 (en) 2004-02-26 2007-09-24 Device driver processing for automated system restores

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US10/788,120 Active 2026-01-22 US7293272B1 (en) 2004-02-26 2004-02-26 Device driver processing for automated system restores

Country Status (1)

Country Link
US (2) US7293272B1 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120005472A1 (en) * 2009-03-30 2012-01-05 Fujitsu Limited Management server, boot server, network boot system, and network boot method
CN103309771A (en) * 2013-06-14 2013-09-18 厦门雅迅网络股份有限公司 Method for realizing boot quick recovery of application program based on Android system
US8677023B2 (en) * 2004-07-22 2014-03-18 Oracle International Corporation High availability and I/O aggregation for server environments
US9083550B2 (en) 2012-10-29 2015-07-14 Oracle International Corporation Network virtualization over infiniband
US20160070557A1 (en) * 2014-09-09 2016-03-10 Tsuyoshi Yamada Information processing apparatus, information processing method, and information processing system
US9331963B2 (en) 2010-09-24 2016-05-03 Oracle International Corporation Wireless host I/O using virtualized I/O controllers
US9813283B2 (en) 2005-08-09 2017-11-07 Oracle International Corporation Efficient data transfer between servers and remote peripherals
US9973446B2 (en) 2009-08-20 2018-05-15 Oracle International Corporation Remote shared server peripherals over an Ethernet network for resource virtualization

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7680957B1 (en) 2003-05-09 2010-03-16 Symantec Operating Corporation Computer system configuration representation and transfer
JP4319105B2 (en) * 2004-02-18 2009-08-26 三菱電機株式会社 Manufacturing system, gateway device, gateway program, and control method of controlled device
US7293272B1 (en) 2004-02-26 2007-11-06 Veritas Operating Corporation Device driver processing for automated system restores
US7660847B2 (en) * 2004-03-14 2010-02-09 International Business Machines Corporation Unattended installation of drivers for devices that are not automatically found and installed during operating system installation
US8065689B2 (en) * 2005-02-03 2011-11-22 Kyocera Mita Corporation Release-dependant filenames for device drivers
GB2426839B (en) * 2005-06-03 2011-02-23 Jacobs Rimell Ltd Automated provisioning system
US20070239672A1 (en) * 2006-03-29 2007-10-11 Microsoft Corporation Client Category Configuration
US8375418B2 (en) * 2006-09-07 2013-02-12 Cw International, Llc Method of performing software updates (installations), on networked 32/64-bit microsoft computers in an automated environment without introducing a possible security threat
US7959677B2 (en) 2007-01-19 2011-06-14 Flexuspine, Inc. Artificial functional spinal unit system and method for use
US8132186B1 (en) 2007-03-23 2012-03-06 Symantec Corporation Automatic detection of hardware and device drivers during restore operations
US7769990B1 (en) 2007-03-23 2010-08-03 Symantec Corporation Using a monitoring process to update system configuration settings during restore operations
US8150801B2 (en) 2008-08-20 2012-04-03 Microsoft Corporation Recovery of a computer that includes virtual disks
US20120150809A1 (en) * 2010-12-08 2012-06-14 Computer Associates Think, Inc. Disaster recovery services
US8774213B2 (en) * 2011-03-30 2014-07-08 Amazon Technologies, Inc. Frameworks and interfaces for offload device-based packet processing
CN102841825B (en) * 2011-06-23 2014-11-05 珠海市君天电子科技有限公司 Driver backup method, device and driver restoring method and device
US20130139183A1 (en) * 2011-11-28 2013-05-30 Wyse Technology Inc. Creation or installation of a disk image for a target device having one of a plurality of hardware platforms
US8606892B2 (en) 2011-11-28 2013-12-10 Wyse Technology Inc. Deployment and updating of applications and drivers on a client device using an extensible markup language (XML) configuration file
US8612516B2 (en) 2011-11-28 2013-12-17 Wyse Technology Inc. Deployment of a driver or an application on a client device having a write-filter
US9122711B1 (en) 2012-05-24 2015-09-01 Symantec Corporation Simplified system backup protection and recovery
US9804855B1 (en) 2015-10-08 2017-10-31 Veritas Technologies Llc Modification of temporary file system for booting on target hardware
US10127029B1 (en) * 2016-12-30 2018-11-13 Veritas Technologies Llc Operating system installation using logical volumes

Citations (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5339432A (en) 1992-10-13 1994-08-16 Microsoft Corporation Method and system for providing user control of device driver configuration
US5598563A (en) 1992-11-16 1997-01-28 Microsoft Corporation Method of loading device drivers from ROM without requirement of system to have any harddisks or floppy drives and without using config.sys file
US5708604A (en) 1996-02-05 1998-01-13 Sgs-Thomson Microelectronics S.R.L. Dynamic selection control in a memory
US5715456A (en) 1995-02-13 1998-02-03 International Business Machines Corporation Method and apparatus for booting a computer system without pre-installing an operating system
US5732282A (en) 1995-06-30 1998-03-24 Sun Microsystems, Inc. Virtual device driver registry having a globally unique identifier supplying virtual driver call information to the requesting program
US5802365A (en) 1995-05-05 1998-09-01 Apple Computer, Inc. Dynamic device matching using driver candidate lists
US5819107A (en) 1994-05-27 1998-10-06 Microsoft Corporation Method for managing the assignment of device drivers in a computer system
US5890204A (en) 1996-06-03 1999-03-30 Emc Corporation User controlled storage configuration using graphical user interface
US5974474A (en) 1996-03-15 1999-10-26 Novell, Inc. System for automatic hardware identification and configuration where instance values are unique within the computer system and resource requirement conflicts are resolved by modifying resource settings
US6023585A (en) 1997-05-02 2000-02-08 Webtv Networks, Inc. Automatically selecting and downloading device drivers from a server system to a client system that includes one or more devices
US6078990A (en) 1998-02-06 2000-06-20 Ncr Corporation Volume set configuration using a single operational view
US6170055B1 (en) 1997-11-03 2001-01-02 Iomega Corporation System for computer recovery using removable high capacity media
US6185686B1 (en) 1996-09-12 2001-02-06 Open Security Solutions, Llc Computer system and process for accessing an encrypted and self-decrypting digital information product while restricting access to decrypted digital information
US6346954B1 (en) 1998-12-21 2002-02-12 International Business Machines Corporation User interface for configuring and managing a multi-drive data storage system
US20020019908A1 (en) 2000-06-02 2002-02-14 Reuter James M. System and method for managing virtual storage
US6535998B1 (en) 1999-07-26 2003-03-18 Microsoft Corporation System recovery by restoring hardware state on non-identical systems
US20030074527A1 (en) 2001-10-15 2003-04-17 International Business Machines Corporation Method, system, and program for determining a configuration of a logical array including a plurality of storage devices
US6567860B1 (en) 1998-10-30 2003-05-20 Computer Associates Think, Inc. Method and apparatus for new device driver installation by an operating system
US20030120624A1 (en) 2001-12-10 2003-06-26 Poppenga Burton H. System and method for efficiently installing and configuring device drivers in managed environments
US6594690B2 (en) 1999-02-24 2003-07-15 Hewlett-Packard Development Company, L.P. Network peripheral device driver installer
US20030159070A1 (en) 2001-05-28 2003-08-21 Yaron Mayer System and method for comprehensive general generic protection for computers against malicious programs that may steal information and/or cause damages
US20030195951A1 (en) 2002-04-12 2003-10-16 Wittel Walter I. Method and system to dynamically detect, download and install drivers from an online service
US20030195995A1 (en) 2002-04-15 2003-10-16 Bassam Tabbara System and method for custom installation of an operating system on a remote client
US6640291B2 (en) 2001-08-10 2003-10-28 Hitachi, Ltd. Apparatus and method for online data migration with remote copy
US6654830B1 (en) 1999-03-25 2003-11-25 Dell Products L.P. Method and system for managing data migration for a storage system
US6671749B2 (en) 2001-03-07 2003-12-30 Hewlett-Packard Development Company, L.P. Peripheral driver installation method and system
US20040003135A1 (en) 2002-06-27 2004-01-01 Moore Terrill M. Technique for driver installation
US6681323B1 (en) 1999-11-29 2004-01-20 Toshiba America Information Systems, Inc. Method and system for automatically installing an initial software configuration including an operating system module from a library containing at least two operating system modules based on retrieved computer identification data
US6725715B2 (en) 1996-07-25 2004-04-27 Hitachi, Ltd. Characteristics adjusting apparatus of physical quantity sensing device and a thermal type air flow measuring instrument, and associated adjusting method
US20040091175A1 (en) 2002-11-12 2004-05-13 Fadi Beyrouti Image processing
US20040111250A1 (en) 2002-12-10 2004-06-10 Hensley John Alan Emulated read-write disk drive using a protected medium
US6804774B1 (en) 2000-05-12 2004-10-12 Hewlett-Packard Development Company, L.P. Software image transition aid comprising building a disk image based on identified hardware
US20040221146A1 (en) 2003-04-30 2004-11-04 International Business Machines Corporation Build time dynamic installation of drivers on cloned systems
US6820214B1 (en) 1999-07-26 2004-11-16 Microsoft Corporation Automated system recovery via backup and restoration of system state
US6820035B1 (en) 2001-09-27 2004-11-16 Emc Corporation System and method for determining workload characteristics for one or more applications operating in a data storage environment
US20040267973A1 (en) 2002-01-28 2004-12-30 Fujitsu Limited Device and host machine
US20050125460A1 (en) 2003-12-04 2005-06-09 Lindeng Yu [method for resotoring backup data]
US20050223386A1 (en) 2004-04-01 2005-10-06 Microsoft Corporation Comprehensive collection of hardware device information for diagnostics
US20060059327A1 (en) 2004-09-13 2006-03-16 Brown Norman P Method to reset an image to a known state
US7065769B1 (en) 2000-06-30 2006-06-20 Intel Corporation Method for automatically installing and updating drivers
US7107534B1 (en) 1998-03-24 2006-09-12 Adaptec, Inc. Storage area network administration
US20060221370A1 (en) 2005-03-29 2006-10-05 Canon Kabushiki Kaisha Information processing apparatus capable of customizing device driver, information processing method, and control program
US7185336B2 (en) 2002-04-03 2007-02-27 Hewlett-Packard Development Company, L.P. System and method for selecting and installing a device driver
US7213060B2 (en) 2002-04-23 2007-05-01 Canon Kabushiki Kaisha Web based creation of printer instances on a workstation
US20070101342A1 (en) 2005-10-31 2007-05-03 Microsoft Corporation Automated device driver management
US7216344B2 (en) 2004-03-02 2007-05-08 Microsoft Corporation Side-by-side drivers
US20070106984A1 (en) 2005-11-09 2007-05-10 Microsoft Corporation Application suite installer with automatic detection of content and configurable options
US20070168478A1 (en) 2006-01-17 2007-07-19 Crosbie David B System and method for transferring a computing environment between computers of dissimilar configurations
US20070214198A1 (en) 2006-03-10 2007-09-13 Nathan Fontenot Allowing state restoration using differential backing objects
US7287257B2 (en) 2000-10-27 2007-10-23 Oxford Semiconductor, Inc. Automatic embedded host configuration system and method
US7293272B1 (en) 2004-02-26 2007-11-06 Veritas Operating Corporation Device driver processing for automated system restores
US20080016387A1 (en) 2006-06-29 2008-01-17 Dssdr, Llc Data transfer and recovery process
US7334227B2 (en) 2001-04-25 2008-02-19 Lg Electronics Inc. Device driver installing method
US7334157B1 (en) 2004-02-26 2008-02-19 Symantec Operating Corporation Restore of data to a computer system having different hardware
US7356679B1 (en) * 2003-04-11 2008-04-08 Vmware, Inc. Computer image capture, customization and deployment
US20080091929A1 (en) 2006-10-16 2008-04-17 Scalent Systems, Inc. Method and system for automatic generation of operating system boot images
US20080126444A1 (en) 2006-11-27 2008-05-29 Microsoft Corporation Hybrid computer restore using network service
US7392423B2 (en) 2004-08-13 2008-06-24 Microsoft Corporation Combined computer backup, disaster recovery and migration in a shared environment
US20080155302A1 (en) 2006-10-26 2008-06-26 Lawton Chun-Hing Mue Method and system for storing recovery related information on a computer memory
US7401113B1 (en) 1999-12-09 2008-07-15 Microsoft Corporations Printer driver identification for a remote printer
US7424719B2 (en) 2004-08-02 2008-09-09 Hewlett-Packard Development Company, L.P. Application with multiple embedded drivers
US7448034B2 (en) 2003-07-30 2008-11-04 International Business Machines Corporation Build time determination and installation of drivers on cloned systems
US7457831B2 (en) 2003-03-31 2008-11-25 Microsoft Corporation Peripheral device driver maintenance scheme for networked peripheral device clients
US7529920B2 (en) 2004-06-11 2009-05-05 Canon Kabushiki Kaisha Apparatus and method capable of executing plug and play installation processing operation upon acquiring one piece of device identification information including both printer and facsimile identification information
US7600227B2 (en) 1999-12-09 2009-10-06 Microsoft Corporation Automatic detection and installation of client peripheral devices by a server
US7631054B2 (en) 2000-12-07 2009-12-08 International Business Machines Corporation Method and system for generating list of operating systems for a target device
US7716382B2 (en) 2005-01-11 2010-05-11 Microsoft Corporation Rich targeting criteria for selection of driver packages

Patent Citations (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5339432A (en) 1992-10-13 1994-08-16 Microsoft Corporation Method and system for providing user control of device driver configuration
US5598563A (en) 1992-11-16 1997-01-28 Microsoft Corporation Method of loading device drivers from ROM without requirement of system to have any harddisks or floppy drives and without using config.sys file
US5819107A (en) 1994-05-27 1998-10-06 Microsoft Corporation Method for managing the assignment of device drivers in a computer system
US5715456A (en) 1995-02-13 1998-02-03 International Business Machines Corporation Method and apparatus for booting a computer system without pre-installing an operating system
US5802365A (en) 1995-05-05 1998-09-01 Apple Computer, Inc. Dynamic device matching using driver candidate lists
US5732282A (en) 1995-06-30 1998-03-24 Sun Microsystems, Inc. Virtual device driver registry having a globally unique identifier supplying virtual driver call information to the requesting program
US5708604A (en) 1996-02-05 1998-01-13 Sgs-Thomson Microelectronics S.R.L. Dynamic selection control in a memory
US5974474A (en) 1996-03-15 1999-10-26 Novell, Inc. System for automatic hardware identification and configuration where instance values are unique within the computer system and resource requirement conflicts are resolved by modifying resource settings
US5890204A (en) 1996-06-03 1999-03-30 Emc Corporation User controlled storage configuration using graphical user interface
US6725715B2 (en) 1996-07-25 2004-04-27 Hitachi, Ltd. Characteristics adjusting apparatus of physical quantity sensing device and a thermal type air flow measuring instrument, and associated adjusting method
US6185686B1 (en) 1996-09-12 2001-02-06 Open Security Solutions, Llc Computer system and process for accessing an encrypted and self-decrypting digital information product while restricting access to decrypted digital information
US6023585A (en) 1997-05-02 2000-02-08 Webtv Networks, Inc. Automatically selecting and downloading device drivers from a server system to a client system that includes one or more devices
US6170055B1 (en) 1997-11-03 2001-01-02 Iomega Corporation System for computer recovery using removable high capacity media
US6078990A (en) 1998-02-06 2000-06-20 Ncr Corporation Volume set configuration using a single operational view
US7107534B1 (en) 1998-03-24 2006-09-12 Adaptec, Inc. Storage area network administration
US6567860B1 (en) 1998-10-30 2003-05-20 Computer Associates Think, Inc. Method and apparatus for new device driver installation by an operating system
US6346954B1 (en) 1998-12-21 2002-02-12 International Business Machines Corporation User interface for configuring and managing a multi-drive data storage system
US6594690B2 (en) 1999-02-24 2003-07-15 Hewlett-Packard Development Company, L.P. Network peripheral device driver installer
US6654830B1 (en) 1999-03-25 2003-11-25 Dell Products L.P. Method and system for managing data migration for a storage system
US6535998B1 (en) 1999-07-26 2003-03-18 Microsoft Corporation System recovery by restoring hardware state on non-identical systems
US6820214B1 (en) 1999-07-26 2004-11-16 Microsoft Corporation Automated system recovery via backup and restoration of system state
US6681323B1 (en) 1999-11-29 2004-01-20 Toshiba America Information Systems, Inc. Method and system for automatically installing an initial software configuration including an operating system module from a library containing at least two operating system modules based on retrieved computer identification data
US7600227B2 (en) 1999-12-09 2009-10-06 Microsoft Corporation Automatic detection and installation of client peripheral devices by a server
US7401113B1 (en) 1999-12-09 2008-07-15 Microsoft Corporations Printer driver identification for a remote printer
US6804774B1 (en) 2000-05-12 2004-10-12 Hewlett-Packard Development Company, L.P. Software image transition aid comprising building a disk image based on identified hardware
US20020019908A1 (en) 2000-06-02 2002-02-14 Reuter James M. System and method for managing virtual storage
US7065769B1 (en) 2000-06-30 2006-06-20 Intel Corporation Method for automatically installing and updating drivers
US7287257B2 (en) 2000-10-27 2007-10-23 Oxford Semiconductor, Inc. Automatic embedded host configuration system and method
US7631054B2 (en) 2000-12-07 2009-12-08 International Business Machines Corporation Method and system for generating list of operating systems for a target device
US6671749B2 (en) 2001-03-07 2003-12-30 Hewlett-Packard Development Company, L.P. Peripheral driver installation method and system
US7334227B2 (en) 2001-04-25 2008-02-19 Lg Electronics Inc. Device driver installing method
US20030159070A1 (en) 2001-05-28 2003-08-21 Yaron Mayer System and method for comprehensive general generic protection for computers against malicious programs that may steal information and/or cause damages
US6640291B2 (en) 2001-08-10 2003-10-28 Hitachi, Ltd. Apparatus and method for online data migration with remote copy
US6820035B1 (en) 2001-09-27 2004-11-16 Emc Corporation System and method for determining workload characteristics for one or more applications operating in a data storage environment
US20030074527A1 (en) 2001-10-15 2003-04-17 International Business Machines Corporation Method, system, and program for determining a configuration of a logical array including a plurality of storage devices
US20030120624A1 (en) 2001-12-10 2003-06-26 Poppenga Burton H. System and method for efficiently installing and configuring device drivers in managed environments
US20040267973A1 (en) 2002-01-28 2004-12-30 Fujitsu Limited Device and host machine
US7185336B2 (en) 2002-04-03 2007-02-27 Hewlett-Packard Development Company, L.P. System and method for selecting and installing a device driver
US20030195951A1 (en) 2002-04-12 2003-10-16 Wittel Walter I. Method and system to dynamically detect, download and install drivers from an online service
US20030195995A1 (en) 2002-04-15 2003-10-16 Bassam Tabbara System and method for custom installation of an operating system on a remote client
US7213060B2 (en) 2002-04-23 2007-05-01 Canon Kabushiki Kaisha Web based creation of printer instances on a workstation
US20040003135A1 (en) 2002-06-27 2004-01-01 Moore Terrill M. Technique for driver installation
US20040091175A1 (en) 2002-11-12 2004-05-13 Fadi Beyrouti Image processing
US20040111250A1 (en) 2002-12-10 2004-06-10 Hensley John Alan Emulated read-write disk drive using a protected medium
US7457831B2 (en) 2003-03-31 2008-11-25 Microsoft Corporation Peripheral device driver maintenance scheme for networked peripheral device clients
US7356679B1 (en) * 2003-04-11 2008-04-08 Vmware, Inc. Computer image capture, customization and deployment
US20040221146A1 (en) 2003-04-30 2004-11-04 International Business Machines Corporation Build time dynamic installation of drivers on cloned systems
US7448034B2 (en) 2003-07-30 2008-11-04 International Business Machines Corporation Build time determination and installation of drivers on cloned systems
US20050125460A1 (en) 2003-12-04 2005-06-09 Lindeng Yu [method for resotoring backup data]
US7293272B1 (en) 2004-02-26 2007-11-06 Veritas Operating Corporation Device driver processing for automated system restores
US7334157B1 (en) 2004-02-26 2008-02-19 Symantec Operating Corporation Restore of data to a computer system having different hardware
US7216344B2 (en) 2004-03-02 2007-05-08 Microsoft Corporation Side-by-side drivers
US20050223386A1 (en) 2004-04-01 2005-10-06 Microsoft Corporation Comprehensive collection of hardware device information for diagnostics
US7529920B2 (en) 2004-06-11 2009-05-05 Canon Kabushiki Kaisha Apparatus and method capable of executing plug and play installation processing operation upon acquiring one piece of device identification information including both printer and facsimile identification information
US7424719B2 (en) 2004-08-02 2008-09-09 Hewlett-Packard Development Company, L.P. Application with multiple embedded drivers
US7392423B2 (en) 2004-08-13 2008-06-24 Microsoft Corporation Combined computer backup, disaster recovery and migration in a shared environment
US20060059327A1 (en) 2004-09-13 2006-03-16 Brown Norman P Method to reset an image to a known state
US7716382B2 (en) 2005-01-11 2010-05-11 Microsoft Corporation Rich targeting criteria for selection of driver packages
US20060221370A1 (en) 2005-03-29 2006-10-05 Canon Kabushiki Kaisha Information processing apparatus capable of customizing device driver, information processing method, and control program
US20070101342A1 (en) 2005-10-31 2007-05-03 Microsoft Corporation Automated device driver management
US20070106984A1 (en) 2005-11-09 2007-05-10 Microsoft Corporation Application suite installer with automatic detection of content and configurable options
US20070168478A1 (en) 2006-01-17 2007-07-19 Crosbie David B System and method for transferring a computing environment between computers of dissimilar configurations
US20070214198A1 (en) 2006-03-10 2007-09-13 Nathan Fontenot Allowing state restoration using differential backing objects
US20080016387A1 (en) 2006-06-29 2008-01-17 Dssdr, Llc Data transfer and recovery process
US20080091929A1 (en) 2006-10-16 2008-04-17 Scalent Systems, Inc. Method and system for automatic generation of operating system boot images
US7743242B2 (en) 2006-10-16 2010-06-22 Scalent Systems Inc. Method and system for automatic generation of operating system boot images
US20080155302A1 (en) 2006-10-26 2008-06-26 Lawton Chun-Hing Mue Method and system for storing recovery related information on a computer memory
US20080126444A1 (en) 2006-11-27 2008-05-29 Microsoft Corporation Hybrid computer restore using network service

Non-Patent Citations (24)

* Cited by examiner, † Cited by third party
Title
"Automated Deployment Services Technical Overview," Microsoft Corporation, Aug. 2003, pp. 1-25.
"Automated System Recovery with VERITAS Netbackup(TM)," VERITAS Bare Metal Restore, White Paper, VERITAS Software Corp. 2002, pp. 1-10.
"Automated System Recovery with VERITAS Netbackup™," VERITAS Bare Metal Restore, White Paper, VERITAS Software Corp. 2002, pp. 1-10.
"CBMR-Dissimilar Hardware Recovery," CBMR Support, Jun. 2005, 9 pages.
"Differences Between Dissimilar System Restore and Dissimilar Disk Restore in VERITAS Bare Metal Restore (tm), 4.6", by Symantec Corp. Sep. 24, 2003, retrieved Jul. 31, 2008 from http://seer/entsupport.symantec.com/docs/262295.htm.
"VERITAS Bare Metal Restore 4.6 for VERITAS NetBackup, System Administrator's Guide for UNIX and Windows," by VERITAS Software Corp. Ch, 7, pp. 167-186, copyright 2002-2003.
"Windows Architecture," Steven Roman, Chapter 9 from Win32 API Programming with Visual Basic, published by O'Reilly and Associates, Inc., 2004 Microsoft Corporation, 6 pages.
Eric Szewxayk, "Sample Syspre.inf file for Microsoft Windows Server 2003 using Altiris Deployment Solution tokens," Feb. 2007, Dell Power Solutions, pp. 1-6.
http://www.melbpc.org.au/pcupdate/2003/2003article8.htm Reprinted from the Mar. 2000 issue of PC Update, the magazine of Melborne PC User Group, Australia, 2003, 4 pages.
Mark Russinovich, "Multi-Platform Images," May 2005, http://blogs.technet.com/markrussinovich/archive/2005/09/19/multi-platform-images.aspx, pp. 1-14.
Michael F. Spear, et al., "Solving the Starting Problem: Device Drivers as Self-Describing Artifacts," Apr. 2006, EuroSys'06, pp. 1-13.
Microsoft, "Windows Resource Kit: Complete Technical Information for the Support Professional for the Microsoft Windows Operating System," 1992, microsoft Press, pp. 1-8, 85-155.
Office Action from U.S. Appl. No. 10/351,778 mailed Aug. 7, 2008.
Office Action from U.S. Appl. No. 10/774,039, mailed Apr. 19, 2007.
Office Action from U.S. Appl. No. 10/789,901 mailed Mar. 11, 2008.
Office Action from U.S. Appl. No. 11/690,592 mailed Jan. 5, 2011, 9 pages.
Office Action from U.S. Appl. No. 11/690,634 mailed Jan. 3, 2011, 33 pages.
Office Action from U.S. Appl. No. 11/690,653 mailed Jan. 22, 2011, 10 pages.
Response to Office Action from U.S. Appl. No. 10/351,778 mailed Oct. 17, 2008.
U.S. Appl. No. 11/351,778, filed Feb. 10, 2006.
Veritas, "Veritas netBackup Bare Metal Restore 6.0-System Administrator's Guide for UNIX, Windows, and Linux," Sep. 2005, pp. 1-234.
Veritas, "Veritas netBackup Bare Metal Restore 6.0—System Administrator's Guide for UNIX, Windows, and Linux," Sep. 2005, pp. 1-234.
Vernalex.com, "Tools: SysPrep Driver scanner," Feb. 2007, http://www.vernalex.com/tools/spdrvscn, pp. 1-6.
Windows Hardware Developer Central, "Credating Windows INF Files," Dec. 2001, http://www.microsoft.com/whdc/archive/w2inf.mspx, pp. 1-4.

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8677023B2 (en) * 2004-07-22 2014-03-18 Oracle International Corporation High availability and I/O aggregation for server environments
US9264384B1 (en) 2004-07-22 2016-02-16 Oracle International Corporation Resource virtualization mechanism including virtual host bus adapters
US9813283B2 (en) 2005-08-09 2017-11-07 Oracle International Corporation Efficient data transfer between servers and remote peripherals
US20120005472A1 (en) * 2009-03-30 2012-01-05 Fujitsu Limited Management server, boot server, network boot system, and network boot method
US8468226B2 (en) * 2009-03-30 2013-06-18 Fujitsu Limited Management server, boot server, network boot system, and network boot method
US9973446B2 (en) 2009-08-20 2018-05-15 Oracle International Corporation Remote shared server peripherals over an Ethernet network for resource virtualization
US9331963B2 (en) 2010-09-24 2016-05-03 Oracle International Corporation Wireless host I/O using virtualized I/O controllers
US9083550B2 (en) 2012-10-29 2015-07-14 Oracle International Corporation Network virtualization over infiniband
CN103309771A (en) * 2013-06-14 2013-09-18 厦门雅迅网络股份有限公司 Method for realizing boot quick recovery of application program based on Android system
CN103309771B (en) * 2013-06-14 2018-04-20 厦门雅迅网络股份有限公司 The method that the fast quick-recovery of application program start is realized based on android system
US20160070557A1 (en) * 2014-09-09 2016-03-10 Tsuyoshi Yamada Information processing apparatus, information processing method, and information processing system

Also Published As

Publication number Publication date
US7293272B1 (en) 2007-11-06

Similar Documents

Publication Publication Date Title
US8108456B2 (en) Method and apparatus for migrating the system environment on which the applications depend
US7711983B2 (en) Fail over method for computer system
US8347263B1 (en) Repository including installation metadata for executable applications
US7594219B2 (en) Method and apparatus for monitoring compatibility of software combinations
US8601466B2 (en) Software deployment method and system, software deployment server and user server
US5995757A (en) Software installation and testing for a build-to order computer system
KR100596298B1 (en) System and method for the automatic installation and configuration of an operating system
RU2436150C2 (en) Creating templates of switched off resources
US8244841B2 (en) Method and system for implementing group policy operations
RU2446450C2 (en) Converting machines to virtual machines
US6301710B1 (en) System and method for creating a substitute registry when automatically installing an update program
US6189051B1 (en) System and method for manufacturing hard disk master by downloading selected programs and drivers from a host through a network
RU2429529C2 (en) Dynamic configuration, allocation and deployment of computer systems
US20060064474A1 (en) System and method for automated migration from Linux to Windows
US5963743A (en) Database for facilitating software installation and testing for a build-to-order computer system
JP2004038964A (en) Automated system setup method
CN104487960B (en) Automated disaster recovery and Data Migration
JP4195209B2 (en) Method and system for automating storage area network configuration
US8577845B2 (en) Remote, granular restore from full virtual machine backup
AU765542B2 (en) Method and apparatus for new device driver installation by an operating system
US8364638B2 (en) Automated filer technique for use in virtualized appliances and applications
JP5142678B2 (en) Deployment method and system
US7373643B2 (en) Apparatus, methods and articles of manufacture for data transmission
US6978363B2 (en) System and method to enable a legacy BIOS system to boot from a disk that includes EFI GPT partitions
US6317880B1 (en) Patch source list management

Legal Events

Date Code Title Description
STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: VERITAS US IP HOLDINGS LLC, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SYMANTEC CORPORATION;REEL/FRAME:037697/0412

Effective date: 20160129

AS Assignment

Owner name: BANK OF AMERICA, N.A., AS COLLATERAL AGENT, NORTH

Free format text: SECURITY INTEREST;ASSIGNOR:VERITAS US IP HOLDINGS LLC;REEL/FRAME:037891/0001

Effective date: 20160129

Owner name: WILMINGTON TRUST, NATIONAL ASSOCIATION, AS COLLATE

Free format text: SECURITY INTEREST;ASSIGNOR:VERITAS US IP HOLDINGS LLC;REEL/FRAME:037891/0726

Effective date: 20160129

AS Assignment

Owner name: VERITAS TECHNOLOGIES LLC, CALIFORNIA

Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:VERITAS US IP HOLDINGS LLC;VERITAS TECHNOLOGIES LLC;REEL/FRAME:038455/0752

Effective date: 20160329

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8