It is not uncommon for an enterprise to have hundreds, if not thousands of computer systems. These computer systems typically operate under the control of software, including systems software (i.e., operating systems, drivers, etc.) and application software.
For these enterprises, proper management of software distribution and software updates on their computer systems can be a complex, expensive, daunting and time-consuming task. For example, an enterprise may need to track the software installed on each of the computer systems, including the version and release of the software, as well as the other resources that are on the computer systems. Tracking the software installed on each of the computer systems enables the enterprise to determine where to deploy additional software, software updates, and other resources as required, as well as to determine whether it is in compliance with the applicable software licenses.
Many enterprises utilize commercially available software management products to manage the distribution of software on their computer systems. While these software management products provide adequate software distribution and software update management features that allow scheduling program (e.g., software program) execution on a specific date and time, the software management products are not able to guarantee a time when a program is actually executed on a computer system. This becomes a problem for the enterprises that rely on time-sensitive applications and, thus, do not allow or permit changes to be made to their computer systems outside of designated periods of time.
Techniques for guaranteeing that a software program is executed on a machine only during designated periods of time are provided. Service windows define time periods during which software programs targeted to execute on a machine are allowed to execute on the machine. On the machine, the service windows work in conjunction with a client process that is executing on the machine to guarantee execution of the software programs by the client process only during available service windows.
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.
Various techniques for guaranteeing that a software program is executed on a computer system (also referred to herein as a “machine”) only during designated periods of time are provided. Service windows define time periods during which software programs (e.g., operating system, anti-virus programs, administrative programs, updates to software programs, updates to software programs, and other types of content) targeted to a particular group of one or more machines (also referred to herein as a “collection”) are allowed to execute. On each of the machines, the service windows work in conjunction with a client process, such as an update client, that is executing on the machine to guarantee execution of software programs by the update client only during available service windows. In this manner, service windows provide administrators the ability to control when a program is allowed to execute on the machines (i.e., client and/or server machines) in their environment. For example, an administrator can define a service window or multiple service windows for deployment on each of the machines in a collection of machines in his/her environment. When deployed, the service windows allow the software programs and updates targeted to each of these machines to execute only in one of the specified service windows.
In some embodiments, a service window specifies a time window with a start and end time that may span across days. The specified time window indicates the time period during which a program is allowed to execute. For example, an administrator can use a service window to specify certain hours of the week during which the update client on the machines can execute the targeted software programs and software updates. A software program may be executed during a service window when the service window becomes available. In the context of a software program, a service window is considered available when (1) the current time is within the time window specified in the service window, and (2) there is sufficient time remaining in the service window (i.e., the length of time from the current time to the end of the time window) for the software program to execute. An administrator can assign an approximate execution time to the software program. This enables the update client to determine whether there is sufficient time for the software program to execute. If an approximate execution time is not provided for a software program, the update client may assign a default value to the approximate execution time. For example, the default value may be based on factors such as, by way of example, the time of day, the size of the software program, the current load on the machine, etc.
In some embodiments, a software program that is running while a service window is available (i.e., the software program is running during the service window) and which continues to run beyond the time the service window ends, will be allowed to run until the software program finishes running or until a predetermined maximum runtime is reached. In the instance where the predetermined runtime is reached without the software program having completed, the software program can be “orphaned.” Alternatively, in other embodiments, the software program that continues to execute beyond the service window can be terminated, for example, by the update client. In some embodiments, a software program that continues to run beyond the time an available service window ends is not permitted to reboot the machine. For example, a software program may include an instruction to perform a reboot of the machine. If this software program starts to run while a service window is available and attempts to execute this instruction (i.e., perform the reboot) after the service window ends, the software program will be stopped from executing the reboot instruction (e.g., the reboot operation will be intercepted and not performed). In some embodiments, the software program may have associated an indication to override the reboot restriction. For example, an administrator may be able to set an override reboot flag to indicate that the software program is to be allowed to reboot the machine even if the software program attempts the reboot after a service window ends. If the override reboot flag is set for a software program, the software program will not be stopped from executing a reboot instruction after the service window ends.
In some embodiments, a service window may specify an impact level. For example, the impact level may be specified as a range between “1” (low) to “10” (high). An administrator is able to specify an impact level for a service window. Likewise, the administrator can assign an impact level to a software program, where the impact level is an indication of the impact the software program has on the machine. When an impact level is specified for a service window, only the software programs that are of equal or lower impact level of the service window can be executed in the service window. If an impact level is not provided for a software program, the update client may assign the software program a default impact level. For example, the update client may assign the software program the highest impact level.
In some embodiments, a service window may specify a priority level. For example, the priority level may be specified as a range between “1” (low) to “10” (high). An administrator is able to specify a priority level for a service window. Likewise, the administrator can assign a priority to a software program, where the priority is an indication of the importance of the software program. For example, a virus attack fix program is more important than a simple program feature enhancement, and the virus attack fix is likely to be assigned a higher priority than the feature enhancement. When a priority level is specified for a service window, only the software programs that are of the same or higher priority than the priority level of the service window can be executed in the service window. If an impact level is not provided for a software program, the update client may assign the software program a default priority. For example, the update client may assign the software program the lowest priority. In some embodiments, the software programs are executed based on their priority order during an available service window. For example, when multiple software programs can be executed in a service window, the software programs are executed based on the priority assigned to each of the programs, from the higher priority program to the lower priority program.
In some embodiments, a service window may specify whether or not the service window is enabled (i.e., whether or not the service window is active). For example, a service window may include an enable/disable flag that may be used to indicate whether the service window is enabled. An administrator can use the enable/disable flag to indicate that the service window is either enabled or disabled. If the service window is enabled, the service window is considered by the update client when executing software programs. Conversely, if the service window is disabled, the service window is not considered by the update client when executing software programs.
In some embodiments, the service window or windows on a machine may be overridden. A software program may have associated a service window override indicator that is used to override the application of the service windows to this software program. If the service window override indicator is set or present, then the update client executes the software program without applying the service window. Stated differently, if the service window override indicator is set, the software program is executed without checking for an available service window. This feature provides administrators an option to override service windows, for example, to run critical software programs, such as security software programs or updates, based on critical business needs.
In some embodiments, the service windows and software programs may be deployed to the machines using a software distribution infrastructure, such as that provided by MICROSOFT's System Management Server (SMS). The SMS architecture provides a comprehensive solution for change and configuration management of large groups of WINDOWS-based machines. SMS provides administrators the ability to manage the machines on a network, distribute software to the machines from a central location, detect the machines on the network, track software and hardware configurations, and perform other tasks on the machines from a remote location.
The SMS infrastructure constitutes but one suitable paradigm with which the service windows and software programs may be deployed to the machines. One skilled in the art will appreciate that other paradigms provided by any of a variety of well-known software configuration and release management systems may be utilized to deploy the service windows and software programs to the machines. One skilled in the art will also appreciate that the service windows and software programs may be deployed to the machines without utilizing the services provided by a software configuration and release management system.
In general terms, the management server facilitates configuration management and release management of the collection of machines. The management server provides a management console with which an administrator can create policies for the deployment of service windows and content images (i.e., the software program images) on the collection of machines. In some embodiments, the management console may provide a wizard, a graphical user interface, and/or other suitable editor that provides the administrator the capability to create policies, such as a content distribution policy, a content image policy, and a service window policy. For example, the wizard may ask the administrator a number of simple questions, and using the responses to the asked questions, the wizard may build the appropriate policies for the administrator. The content distribution policy contains the properties for distributing a content image to a targeted collection of machines. The content image policy is associated with a content image, and contains the properties of the associated content image. The service window policy is targeted to a collection of machines, and contains one or more service windows, including the properties of each of the contained service windows. The management server may maintain the policies and the content images in a persistent data store, such as a database.
In general terms, the distribution server serves as a distribution point where the machines can obtain the content images. For example, the management server can distribute the content images to the distribution server or multiple distribution servers, and the individual machines can obtain the content images from the distribution server.
In general terms, a collection defines a group of one or more machines. For example, all machines that are “data centers” may be defined to be in one collection. Similarly, all machines that are in a certain locale (e.g., all machines in building 4, floors 1-3) may be defined to be in one collection.
In a typical scenario, an administrator uses the management server's administrator console to create the policies (e.g., the content distribution policies, the content image policies, and the service window policy) and to specify the targeted collection of machines to which the policies apply. For example, the administrator can create a content distribution policy for each content image that is to be deployed to the collection of machines. For each content image, the administrator can create/update/modify a content image policy to specify the properties of the content image. The administrator can also create/update/modify a service window policy, including the service windows specified in the policy, which is to be deployed on the collection of machines. Once the policies are created, the administrator can use the management server to distribute the content images to appropriate distribution servers. On each of the machines, a client process, such as an update client, periodically queries the management server for new policies that are targeted to the machine. In response, the machine receives from the management server any new content distribution policies and service window policy. The client process on each machine then processes the newly received policies. For example, the client process obtains from the appropriate distribution server the content images and their associated content image policies based on the new content distribution policies received from the management server. The client process on each machine then executes the obtained content images based on their associated content image policies and the service window policy.
In general terms, the network is a communications link that facilitates the transfer of electronic content between, for example, the attached collection of machines, management server and distribution server. In some embodiments, the network includes the Internet. It will be appreciated that the network may be comprised of one or more other types of networks, such as a local area network, a wide area network, a point-to-point dial-up connection, and the like.
The computing device on which the service window deployment system, including the target machines, management server and distribution server, is implemented may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives). The memory and storage devices are computer-readable media that may contain instructions that implement the service window deployment system. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communications link. Various communication links may be used, such as the Internet, a local area network, a wide area network, a point-to-point dial-up connection, a cell phone network, and so on.
Embodiments of the system may be implemented in various operating environments that include personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and so on. The computer systems may be cell phones, personal digital assistants, smart phones, personal computers, programmable consumer electronics, digital cameras, and so on.
The system may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
One skilled in the art will appreciate that, for this and other processes and methods disclosed herein, the functions performed in the processes and methods may be implemented in differing order. Furthermore, the outlined steps are only exemplary, and some of the steps may be optional, combined with fewer steps, or expanded into additional steps.
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 above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
This application is a continuation application of U.S. patent application Ser. No. 11/317,645, filed on Dec. 22, 2005, now U.S. Pat. No. 8,495,613, which is incorporated herein in its entirety by reference.
Number | Name | Date | Kind |
---|---|---|---|
5155847 | Kirouac et al. | Oct 1992 | A |
5210872 | Ferguson et al. | May 1993 | A |
5392430 | Chen et al. | Feb 1995 | A |
5465354 | Hirosawa et al. | Nov 1995 | A |
5473772 | Halliwell et al. | Dec 1995 | A |
5479601 | Matheny et al. | Dec 1995 | A |
5606695 | Dworzecki | Feb 1997 | A |
5680548 | Trugman | Oct 1997 | A |
5708812 | Van Dyke et al. | Jan 1998 | A |
5742829 | Davis et al. | Apr 1998 | A |
5764992 | Kullick et al. | Jun 1998 | A |
5826080 | Dworzecki | Oct 1998 | A |
6023586 | Gaisford et al. | Feb 2000 | A |
6049868 | Panwar | Apr 2000 | A |
6182238 | Cooper | Jan 2001 | B1 |
6263358 | Lee et al. | Jul 2001 | B1 |
6263359 | Fong et al. | Jul 2001 | B1 |
6272536 | van Hoff et al. | Aug 2001 | B1 |
6279153 | Bi et al. | Aug 2001 | B1 |
6317774 | Jones et al. | Nov 2001 | B1 |
6323882 | Jerome et al. | Nov 2001 | B1 |
6345386 | Delo et al. | Feb 2002 | B1 |
6546554 | Schmidt et al. | Apr 2003 | B1 |
6557054 | Reisman | Apr 2003 | B2 |
6571389 | Spyker et al. | May 2003 | B1 |
6625636 | Skovira | Sep 2003 | B1 |
6667810 | Jeyachandran et al. | Dec 2003 | B1 |
6745222 | Jones et al. | Jun 2004 | B1 |
6782302 | Barto et al. | Aug 2004 | B1 |
6801819 | Barto et al. | Oct 2004 | B1 |
6810503 | David et al. | Oct 2004 | B1 |
6813777 | Weinberger et al. | Nov 2004 | B1 |
6993763 | Hayes, Jr. | Jan 2006 | B2 |
7093004 | Bernardin et al. | Aug 2006 | B2 |
7533384 | Chan et al. | May 2009 | B2 |
7865888 | Qureshi et al. | Jan 2011 | B1 |
7979859 | Li et al. | Jul 2011 | B2 |
20020002578 | Yamashita | Jan 2002 | A1 |
20020056079 | Sato et al. | May 2002 | A1 |
20020147974 | Wookey | Oct 2002 | A1 |
20020156889 | Crudele et al. | Oct 2002 | A1 |
20020194584 | Suorsa et al. | Dec 2002 | A1 |
20020198923 | Hayes, Jr. | Dec 2002 | A1 |
20030046682 | Crespo et al. | Mar 2003 | A1 |
20030070162 | Oshima et al. | Apr 2003 | A1 |
20030135643 | Chiu et al. | Jul 2003 | A1 |
20030149717 | Heinzman | Aug 2003 | A1 |
20030163469 | Garth et al. | Aug 2003 | A1 |
20030204547 | Davis et al. | Oct 2003 | A1 |
20040060044 | Das et al. | Mar 2004 | A1 |
20040093595 | Bilange | May 2004 | A1 |
20040123297 | Flautner et al. | Jun 2004 | A1 |
20040187103 | Wickham et al. | Sep 2004 | A1 |
20040187104 | Sardesai et al. | Sep 2004 | A1 |
20040255287 | Zhang et al. | Dec 2004 | A1 |
20050114868 | Conroy et al. | May 2005 | A1 |
20050120106 | Albertao | Jun 2005 | A1 |
20050278520 | Hirai et al. | Dec 2005 | A1 |
20060107268 | Chrabieh | May 2006 | A1 |
20060190943 | Haeri | Aug 2006 | A1 |
20070150815 | Smith et al. | Jun 2007 | A1 |
20070157192 | Hoefler et al. | Jul 2007 | A1 |
20070171921 | Wookey et al. | Jul 2007 | A1 |
20070174410 | Croft et al. | Jul 2007 | A1 |
20070174429 | Mazzaferri et al. | Jul 2007 | A1 |
20080134175 | Fitzgerald et al. | Jun 2008 | A1 |
20090083651 | Kim et al. | Mar 2009 | A1 |
20120331476 | Saffre | Dec 2012 | A1 |
Entry |
---|
“Planning and Installation Guide”, IBM , 2003 , <http://publib.boulder.ibm.com/tividd/td/TWS/SH19-4555-01/en—US/PDF/plan—ins.pdf> , pp. 1-144. |
Wenzhang Zhu et al. , “Lightweight Transparent Java Thread Migration for Distributed JVM”, IEEE , 2003 , http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1240611> , pp. 1-8. |
Gokhan Metan et al. “A Simulation Based Learning Meachanism for Scheduling Systems With Continuous Control and Update Structure”, ACM , 2005 , <http://delivery.acm.org/10.1145/1170000/1163083/p2148-metan.pdf> , pp. 1-9. |
Number | Date | Country | |
---|---|---|---|
20140165051 A1 | Jun 2014 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11317645 | Dec 2005 | US |
Child | 13948065 | US |