Patent Application
20090007096
Modern enterprises, especially those having a relatively large number of computer assets, typically use a management structure that allows an administrator to manage the various computer assets from a central location. Centralized management activities may include deploying applications to the host computers, maintaining and upgrading applications, and removing other applications, as well as other functions. The administrator may perform these management functions using scripts or other suitable batch processes from a management server having network connectivity to the various host computers.
Deployment of applications to the host computers can be a cumbersome and problematic process, even for centralized management structures. For protection technologies such as anti-virus and anti-spyware, existing software deployment mechanisms typically require targeting of individual “packages,” and may result in frequent package updates based on, for example, the breadth of hosts targeted. In addition, multiple packages may be required in a particular enterprise, such as a package targeted to host desktops, another package targeted to servers, and so on.
For some managed software, where there is a service that configures or monitors the host software, there may also be an issue (a so-called “chicken and egg” problem) with getting the configuration and settings installed on the host device before the host software installation is activated. In particular, there may be a need for the newly installed hosts to “know” what their reporting server configuration is at the time of installation of the monitored software. Deployment of security and protection technology software may be exasperated by the fact that network access is frequently limited to a restricted set of machines unless (or until) the security software is installed and activated. Concerns about standard software licensing and end-user license agreement (EULA) acceptance for the deployed host software also need to be addressed.
Techniques for secure software deployments are described. In one implementation, a method includes preparing a software package for installation on a host device of a networked environment, and publishing the software package to an installation portion of the networked environment. The software package is then stored in the installation portion. Similarly, an applicability rule (or policy) associated with the software package is prepared and published to the installation portion. The publication of the applicability rule may be decoupled from the publication of the software package. The applicability rule may then be stored in the installation portion. During a periodic synchronization between the host device and the installation portion, the applicability rule is communicated, and a determination is made whether the host device is intended to receive the software package based on the applicability rule communicated during the periodic synchronization. If the applicability rule is satisfied, the software package is installed on the host device.
In a further aspect, if the host device is policy-restricted (or quarantined) from routine communications with other components of the networked environment, the software package may be installed on the host device via a communication channel that is designated for non-routine communications. In some embodiments, the communication channel may be a channel normally reserved for security packet updates and other administrative functions.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
The detailed description is described with reference to the accompanying figures. In the figures, the use of the same reference numbers in different figures indicates similar or identical components.
The current disclosure teaches techniques for secure deployment of software to host devices. Techniques in accordance with the present disclosure may provide persistent, automated host deployments that reduce or eliminate hands-on involvement by an administrator, even for host devices having limited connectivity. The disclosed techniques may also properly address software licensing and End User License Agreement (EULA) concerns.
In general, processes for deployment of software in accordance with the present disclosure may include three phases. A first phase publishes the software to a publishing site. A second phase targets and deploys configuration and installation information to host computers (or hosts) requiring the software. In a third phase, the host computers acquire the software from the publishing site and install the software in accordance with the configuration information.
The administrative portion 110 includes an administrative server 112 configured to enable an administrator to perform administrative functions associated with deployment of a software throughout the environment 100, and more specifically, to the host device portion 130. The administrative functions include publication of a host software (or package) 114 that is intended to be deployed throughout the environment 100. The administrator may also accept an EULA (or other suitable license) 115 as needed. Similarly, a policy and configuration deployment information 116 may be promulgated by the administrator, and any other EULA (or other required licenses) 117 may be accepted, as part of the administrative functions performed within the administrative portion 110.
In an installation portion 120 of the exemplary environment 100, an update server 122 receives the published software (or package) 114 provided by the administrative portion 110. The update server 122 may store the published software 114 into an update database 124 for repeated access as needed. Similarly, an authentication server 126 of the installation portion 120 receives the policy and configuration deployment information 116, and may store this information 116 into a policies database 128. The authentication server 126 provides central authentication and authorization services for the host devices 132, 134, 136 of the environment 100, allowing the administrator to assign policies and apply critical updates to the entire environment 100 from the administrative server 112. The authentication server 126 may store information and settings relating to an organization in a central, organized, accessible database (e.g. the policies database 128). In some particular embodiments, for example, the authentication server 126 may be an Active Directory Server that implements Lightweight Directory Access Protocol (LDAP) directory services for use primarily in environments that employ a Windows® operating system by Microsoft. Additional details regarding the structure and operation of the update server 122 and the authentication server 126 are described below with reference to
As further shown in
During an installation process, a policy synchronization 140 is performed between the installation portion 120 and the host device portion 130. Based on the policy synchronization 140, an update installation 142 of the published software and packages is provided by the installation portion 120 to the host device portion 130.
It will be appreciated that the environment 100 shown in
An exemplary environment 100 in which techniques for secure software deployment may be implemented has been described above with reference to
For example,
The system memory 210 may include any suitable type of memory. More specifically, the system memory 210 may include computer-readable media configured to store data and/or program modules for implementing the techniques disclosed herein that are immediately accessible to and/or presently operated on by the processor(s) 202. For example, in the embodiment shown in
As further shown in
For example, for the administrative server 112, the software deployment component 220 may be configured to create a suitable installation package for installing a particular software on one or more various host devices. For the update server 122, the software deployment component 220 is configured to perform functions associated with managing and distributing published software and package updates 114 to the host device portion 130 of the environment 100 (
The computer-readable media included in the system memory 210 can be any available media that can be accessed by the device 200, including computer storage media and communication media. Computer storage media include both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. More specifically, suitable computer storage media include random access memory (RAM), read only memory (ROM), electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, compact disk ROM (CD-ROM), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium, including paper, punch cards and the like, which can be used to store the desired information.
Similarly, communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more if its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
Generally, program modules executed on the exemplary server 200 (
In some embodiments, the different channels 304 of the network connection 300 are used for different purposes. For example, some channels, such as channels 304a, 304b, may be dedicated to normal, routine communications, while other channels (e.g. channel 304n) may be reserved for select administrative functions or security-related communications. Conventionally, the channels earmarked for routine communications (e.g. channels 304a, 304b) are the channels used to deploy software to various host devices within a network.
In further embodiments, various components of a network environment may be policy-limited such that connectivity with other components of the environment is limited or barred. Typically, such policy-limited components are barred from communications over the channels earmarked for routine communications (e.g. channels 304a, 304b). In such limited or “quarantined” environments, however, communications between the administrative server 112 and the various quarantined components (servers or host devices) may still be performed via the reserved channels (e.g. channel 304n). For example, in some embodiments, the administrative server 112 may provide policy updates, or update packets to anti-virus or anti-malware scanning software installed on the quarantined components by means of the one or more reserved channels 304n. In particular embodiments, the channels reserved for such non-routine communications may be determined by the respective operating systems used by the servers and the host devices, an example of which is the Background Intelligent Transfer Service of the Windows® operating system available from Microsoft.
The system bus 406 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. The system memory 404 includes read only memory (ROM) 408 and random access memory (RAM) 410. A basic input/output system (BIOS) 412, containing the basic routines that help to transfer information between elements within the host device 400, such as during start-up, is stored in ROM 408.
The exemplary host device 400 further includes a hard disk drive 414 for reading from and writing to a hard disk (not shown), and is connected to the system bus 406 via a hard disk driver interface 416 (e.g., a SCSI, ATA, or other type of interface). A magnetic disk drive 418 for reading from and writing to a removable magnetic disk 420, is connected to the system bus 406 via a magnetic disk drive interface 422. Similarly, an optical disk drive 424 for reading from or writing to a removable optical disk 426 such as a CD ROM, DVD, or other optical media, connected to the system bus 406 via an optical drive interface 428. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the host device 400. Although the exemplary host device 400 described herein employs a hard disk, a removable magnetic disk 420 and a removable optical disk 426, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs) read only memories (ROM), and the like, may also be used in the host device 400.
As further shown in
A deployment and registry component 480 is also stored in the system memory 404. The deployment and registry component 480 is configured to communicate with the software deployment component 220 of the exemplary server 200 (i.e. the update and authentication servers 122, 126), and may also store policy values associated with the installation of the software. Additional aspects of the deployment and registry component 480 are described more fully below with reference to
A user may enter commands and information into the host device 400 through input devices such as a keyboard 438 and a pointing device 440. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are connected to the processing unit 402 through an interface 442 that is coupled to the system bus. A monitor 444 or other type of display device is also connected to the system bus 406 via an interface, such as a video adapter 446. In addition to the monitor, personal computers typically include other peripheral output devices (not shown) such as speakers and printers.
The host device 400 operates in a networked environment using logical connections to one or more remote computers (or servers) 458, such as the update server 122 and the active directory server 126. Such remote computers (or servers) 458 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and may include many or all of the elements described above relative to host device 400. The logical connections depicted in
When used in a LAN networking environment, the host device 400 is connected to the local network 448 through a network interface (or adapter) 452 When used in a WAN networking environment, the host device 400 typically includes a modem 454 or other means for establishing communications over the wide area network 450, such as the Internet. The modem 454, which may be internal or external, may be connected to the system bus 406 via the serial port interface 442. In a networked environment (e.g. environment 100 of
The network connections shown in
Finally, it will be appreciated that the exemplary embodiments of the server 200, the multi-channel network connection 300, and the host device 400 represent possible embodiments that may be used to implement the techniques for secure software deployment disclosed herein. Such techniques may, of course, be implemented using alternate embodiments of such components.
Exemplary processes for secure deployment of software to host devices will now be described. For convenience, and to facilitate an understanding of these processes, the exemplary processes will be described with reference to the exemplary environment 100 and exemplary components described above and shown in
As noted above, processes for deployment of software may generally include three phases. A first phase publishes the host software to a publishing site. A second phase targets and deploys configuration and installation information to host computers requiring the host software. In a third phase, the host computers acquire the host software from the publishing site and install the host software in accordance with the configuration information. Additional details of these three general phases are described more fully below.
Once the software package is created, the software package is published at 516. In some embodiments, for example, an application programming interface (API) may be used to publish the software package by transmitting the software package to the update server 122. In particular embodiments wherein the software deployment component 220 of the administrative and update servers 112, 122 includes the WSUS software package, the publication at 516 may include using public WSUS 3.x APIs to add the software package to the update server 122 for subsequent distribution.
At 518, the administrative server 112 provides an applicability rule (or policy) associated with the software package. As used in this application, the terms “applicability rule” and “policy” may be used interchangeably in a general sense to refer to one or more rules established by an administrator of an environment. However, in particular embodiments, an applicability rule may be used to refer to something related to the publishing of a package during the publication phase of the process, while the term “policy” may be used to refer to something that expresses an administrative intent of the administrator. Whether the general meaning or specific meaning of these terms is intended will be apparent to the reader from the context in which these terms are used.
In some embodiments, the applicability rule may designate that the software package is targeted to “all” host devices and are only applicable to host devices that have certain policy values in a local registry (e.g. the deployment and registry component 480 of
As further shown in
The policy (or applicability rule) may desirably include all the information required to install and configure the host software on the one or more host devices. Also embedded in the policy may be a key (or marker) that indicates the host device needs to receive the software and have it installed. Such a key can be as simple as a registry value (of the deployment and registry component 480) that has a non-empty value. The deployment and registry component 480 may be desirably configured to use the same server that provides the published software package (i.e. the update server 112) as its source for updates and patch management. Once the policy deployed (at 524), the targeted host devices are prepared and ready to receive the software package. [00501 During an installation phase 530 of the process 500, each of the targeted host devices performs a periodic synchronization at 532 with the installation portion 120 (e.g. the update server 122 and the authentication server 126). At 534, the targeted host devices identify that the host software package applies to them. In some embodiments, the identification at 534 includes determining that a key is present in the deployment and registry component 480 in accordance with the applicability rule (or policy) provided by the authentication server 126, and the host software is not yet installed on the host device.
At 536, the software package is brought into each of the targeted host devices from the update server 122, and is installed in the targeted host devices at 538. In some embodiments, such as when the targeted host devices are in a quarantined area such that connectivity to the installation portion 120 of the environment 100 over the channels 304a, 304b designated for routine communications, the software package may be received by the targeted host devices over one or more channels 304n that are normally reserved for non-routine communications. More specifically, in particular embodiments, the policy and software package may be received by the host device over a channel 304n that is formerly restricted to security package updates, such for anti-virus and anti-malware scanning software.
It may be appreciated that since the same “set” of policy and configuration information 116 (
Techniques for deployment of host software to targeted host devices in accordance with the present disclosure may provide significant advantages over the prior art. For example, because the provision of the key (or marker) is decoupled from the software package deployment, the deployment of the key may be persistent and may reside within the system at all times. Thus, a hands-on action is not required to push a software package to each and every host device. This means that any host device that “joins” the system after the publication and policy deployment have been completed will automatically receive the host software package at the next sync with the installation portion 120 (e.g. the update server 122 and the authentication server 126). Using a persisted object in the policies database 128, anytime a host device joins the environment in such a way that the applicability rule or policy applies to the new device, it will receive the marker from the authentication server 126, and ultimately the software package from the update server 122.
Similarly, because the software package is persistent and resides within the system (e.g. with the update database 124) at all times. Since the applicability rule triggers the deployment, there is no need for a hands-on action by an administrator or user to deploy the host software. Furthermore, this also means that if a host device's user uninstalls a certain host software, on the next sync with the installation portion 120, the relevant host software will be automatically reinstalled. This aspect may be particularly important for security and protection software, such as anti-virus and anti-malware scanning software. This persistence serves as a desirable deterrent to tampering and may be an important issue with secure deployment of software.
Finally, techniques in accordance with the present disclosure may require that direct action be taken on the part of the administrator in two separate phases that allow for the proper presentation and acknowledgement of applicant software licenses and End-User Licensing Agreements (EULA). As shown in
In summary, processes for deployment of host software in accordance with the present disclosure may provide persistent, automated host deployments that reduce or eliminate hands-on involvement by an administrator, even for host devices having limited connectivity. The disclosed techniques may also properly address software licensing and EULA concerns.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claims.
