Patent Application
20110302576
Information technology (IT) administrators need to monitor the deployment of software, including programs and patches, with respect to the deployment's state and progress. This includes checking whether a given deployment is on track or out of control, and/or is proceeding efficiently or not. In general, this is accomplished by the administrator analyzing the status messages reported by client machines, and is based upon the administrator's experience.
In a large enterprise, typically there are many computing machines, of various types, including desktops, laptops and mobile devices. Each of these machines typically reports to a central configuration server (e.g., a System Center Configuration Manager, or SCCM server) or the like through log streams (e.g. status messages or status events). As a result, in order to determine the progress of deployment and/or the significant events that occurred or are occurring with respect to that deployment, the administrator needs to manually analyze a substantial amount of raw data.
This Summary is provided to introduce a selection of representative 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 in any way that would limit the scope of the claimed subject matter.
Briefly, various aspects of the subject matter described herein are directed towards a technology by which network components and/or user interface interaction automatically generate bookmarks that maintain information regarding events and/or triggers with respect to a network software deployment operation. The bookmarks are maintained in a data store, and are accessible and useable for evaluating the progress and state of the network software deployment operation as well as for use in troubleshooting and diagnosing various issues.
Examples of bookmarks that may be generated include a bookmark corresponding to when a software deployment package is created, a bookmark corresponding to when a software deployment package is distributed to a distribution point, a bookmark corresponding to when a distribution policy is generated or changed, and/or a bookmark corresponding to an object change that affects deployment task status. Other examples include a bookmark corresponding to when a network component starts, stops or restarts, a bookmark corresponding to when membership of a collection of network members changes, a bookmark corresponding to when a network component is added, removed, updated or refreshed, and/or a bookmark corresponding to information regarding a maintenance task.
In one aspect, the set the bookmarks, which each record data regarding a network software deployment operation, may be accessed and used to generate a visual representation (e.g., a curve) indicative of progress over time of deploying network software to client computer systems. Performance history data related to one or more previous network software deployment operations may be accessed and used to generate a visual representation indicative of previous progress of deploying other network software to client computer systems.
Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings.
The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
Various aspects of the technology described herein are generally directed towards automatically recording network software deployment-related (e.g., events and trigger) information, in data referred to as bookmarks, throughout a network software deployment operation. In general, the bookmarks record and save the significant events and/or triggered information that affect the deployment, and bind the events with the time that they happened. Via the bookmarks, an administrator is able to evaluate (e.g., monitor and check) what happened and/or is happening in the deployment process, and thereby efficiently find any deployment-related issues, as well as help troubleshoot those issues.
Another aspect is related to performance history, which in general collects the raw data as the history of a deployment, and automatically generates performance reports and/or graphs via data aggregation and calculation. The automatic collection and analysis of the history helps an administrator to easily and efficiently evaluate a deployment progress, including the deployment progress relative to previous, similar deployments.
It should be understood that any of the examples herein are non-limiting. Indeed, an architecture is described as one example of how the various aspects of bookmarks and performance data history may be implemented, but this is only one suitable example architecture, and bookmarks and/or performance data history are not limited to any particular implementation/architecture. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computing and networking in general.
An activity generally corresponds to information of a distribution task, including package, advertisement of the package to clients, and deployment information. Various factors related to distribution may include package size, number of distribution points, whether the deployment is mandatory or optional, and whether the deployment is scheduled or not (as well as scheduled in UTC time or local time). Other information may specify whether the deployment is to run from a distribution point or from the local machine, and retry behavior.
Each activity is an instance that maintains an association with the actual distribution task instance, as well as maintaining a historical summary of a distribution task's progress in a consistent manner for various types of distribution tasks. An activity also may be used to associate the administrator's expectation with a checkpoint of the progress, and evaluate the on-track or late status, and/or healthy or unhealthy status with the checkpoint. An activity also may track the progress of each step of the distribution process, as long as the status message provides information about which step resulted in the message.
Once created, the software deployment package is then distributed to a distribution point 113, which is typically a file share server used for client machines 1141-114n to get the package. The management point 116 generates new policy (e.g., an offer or advertisement) that describes the related information, such as to inform the clients that the new software package is ready, and thus may alternatively be referred to as (or work with) a policy provider, which may be implemented as a systems management server (SMS) executive. At some point thereafter, the client machines 1141-114n connect to the management point 116 to obtain the policy and know that there is a new patch/software program package update available for installation.
After retrieving the information from the policy, each client machine (e.g., 1141) connects to get the deployed software for installation. Each client machine sends a status message to a status manager 118 of the distribution point 113 to report the results, namely success or failure.
In general, a bookmark operation adds a bookmark 120 (e.g., a record in the database 112) to save the information for every significant step, such as when the package is created, when the package is distributed to the distribution point 113, when the policy is generated, when the components start, stop or restart, the success or failure, and so forth. Whenever an administrator changes an object (e.g., a package, advertisement, software update deployment) via the UI 106, and the change affects the deployment task status, an appropriate bookmark will be logged via the provider 104.
By way of example, consider that the administrator creates a package and attempts deployment to ten-thousand machines, and finds that thirty-five percent failed. After checking the bookmarks, the administrator may determine that the package was successfully created, and distributed to seven distribution point servers, with failure reported on three of the distribution point servers. The administrator may then check and fix the failed distribution point servers and redistribute the software to these three servers. The client machines coupled to those distribution point servers may then load and install the software at a later appropriate time.
Other components represented in
Thus, one of the steps that results in a bookmark being recorded include content distribution, from a site server to the distribution points. Others include the policy distribution of the target policy to the clients, retrieval of the policy by a client from the site server, starting the service/content download from the distribution points to a client, and installation/execution of the program on a client. With some or all of these bookmarks, and possibly others, a checkpoint model may be built, e.g., to determine whether a deployment is on track or late with respect to the final execution result for policy distribution, and/or with respect to the final copy result for content distribution.
The distribution manager 122 copies a package source to a distribution point, and updates and refreshes the distribution point. Its status affects package activity status.
The offer summarizer 124 is an existing component (e.g., thread) that captures distribution status messages in order to accumulate a real time summary 123, e.g., for maintaining in the database 112. The offer summarizer 124 also captures distribution status messages to populate details as to the per client, per advertisement statuses into the database 112. The offer summarizer 124 may integrate client health data 126 with the real time summary, e.g., by periodically synchronizing the real time summary with the state system summary; the client health summary 127 may be maintained in the database 112. The healthy or unhealthy state of deployment may be based on the error messages received during the distribution.
The state system 128 is an existing component (e.g., thread) that parses, replicates and executes state messages, as well as executes scheduled summary tasks (e.g., 240,
The administrator may set one or more checkpoints, e.g., to set one or more expected execution success ratios and/or dates for on-track/late evaluation. The administrator may also set an error message threshold. The delivery scope evaluator 130 is a thread component that may be triggered by a summarization task in the state system. In general, the delivery scope evaluator 130 evaluates the distribution status from the summary against the checkpoints, associates bookmarks with activities, and raise notifications of distribution status changes. There may be an evaluation as to when new facts 244 have been copied, and/or to raise a warning or error when the latest actual progress is beyond a baseline.
A database notification monitor 246 (
Also shown for completeness in
A bookmark library may be provided that enables other components to generate a bookmark. For example, a “GenerateBookmark( . . . )” function call or the like may be provided for this purpose.
As can be seen, a bookmark captures information including change events, and operates to associate those events with one, several or all activities. Bookmarks provide an administrator with awareness of context/environment changes of given distribution, and may be used to find a potential root cause of a deployment issue.
A bookmark may be maintained with respect to changing the members of a collection, a policy change, or adding, removing updating or refreshing a distribution point with respect to a package. A bookmark also may be maintained for updating an advertisement schedule, retargeting an advertisement to a collection, or updating a schedule. Still other bookmarks record a distribution point management component change, a management and monitor components of inbox change, a database monitor component change, a status message component change, an SMSEXEC main thread change, or a management point component change, for example.
Further, bookmarks can be prioritized, may be grouped and may be marked as being positive or negative with respect to a result. The user interface may filter the set of bookmarks into a subset based on priority, based on groups and/or based on their results.
The performance history aspects are directed towards obtaining the current deployment data, such as package size, the number of clients to which deployment is needed, and so forth. During the deployment process, the performance history component collects the current data (e.g., in real time) and compares that data to the historical data.
The black line is a curve representing the actual deployment progress. If this curve is in the lightly shaded area, deployment is on track, while if in the darker shaded area, something wrong has happened, suggesting troubleshooting is needed. For example, around 6:00 PM on 1/16, the deployment curve enters the darker area, and there are two bookmarks around that timestamp. The administrator may select the time range, e.g., the medium-shaded area selected by using a mouse/pointer, to view the bookmark information in this time range. For example, as can be seen in the description of the two bookmarks, the administrator finds that the SCCM executive was paused at that time, which is the root cause of the problem. When the SCCM executive was later restarted, deployment resumed normally.
Bookmarks along with performance history thus help the administrator focus on the main/significant events, troubleshoot issues with high efficiency, and/or automatically evaluate the health of the entire deployment process. Automatic computations and the like help the administrator to estimate when the current deployment will complete, as well as to evaluate the current deployment progress, such as whether it is on track or delayed relative to the history of similar past deployments.
As can be seen, with the bookmark information, an administrator does not have to check the status messages reported by the client machines and/or analyze the raw data manually, which are inefficient operations. With the performance history, the administrator has an estimate of the time usage and progress, and can easily determine whether a deployment task is on track or delayed, without relying on personal experience. Bookmarking and performance history thereby significantly assist with any needed troubleshooting.
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to: personal computers, server computers, hand-held or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in local and/or remote computer storage media including memory storage devices.
With reference to
The computer 710 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer 710 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes 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. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, 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 which can be used to store the desired information and which can accessed by the computer 710. 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 of 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 the any of the above may also be included within the scope of computer-readable media.
The system memory 730 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 731 and random access memory (RAM) 732. A basic input/output system 733 (BIOS), containing the basic routines that help to transfer information between elements within computer 710, such as during start-up, is typically stored in ROM 731. RAM 732 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 720. By way of example, and not limitation,
The computer 710 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media, described above and illustrated in
The computer 710 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 780. The remote computer 780 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 710, although only a memory storage device 781 has been illustrated in
When used in a LAN networking environment, the computer 710 is connected to the LAN 771 through a network interface or adapter 770. When used in a WAN networking environment, the computer 710 typically includes a modem 772 or other means for establishing communications over the WAN 773, such as the Internet. The modem 772, which may be internal or external, may be connected to the system bus 721 via the user input interface 760 or other appropriate mechanism. A wireless networking component such as comprising an interface and antenna may be coupled through a suitable device such as an access point or peer computer to a WAN or LAN. In a networked environment, program modules depicted relative to the computer 710, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
An auxiliary subsystem 799 (e.g., for auxiliary display of content) may be connected via the user interface 760 to allow data such as program content, system status and event notifications to be provided to the user, even if the main portions of the computer system are in a low power state. The auxiliary subsystem 799 may be connected to the modem 772 and/or network interface 770 to allow communication between these systems while the main processing unit 720 is in a low power state.
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
