Microsoft Technology Licensing, LLC

Bruce Gordon Payette

Jeffrey P Snover

James W Truher

Rahim Maknojia

Kenneth M Hansen

Narayanan Lakshmanan

Bhalchandra Pandit

Sameer S Mutatkar

James G Robertson

Daryl W Wray

Hemant Mahawar

Liu Hong

Lee Holmes

Xiaoyong Zhou

Mark Gray

Christine Moeller

Jeffrey Dick Jones

Jonathan Marshall Rowlett

Jason J Shirk

Miriam Rosenberg

Nitin Gupta

Constantin Sorin Oprea

Xuejian Pan

Sharath Gopalappa

George Xie

Jim Truher

Dana Jin Huang

Technologies are provided for non-monotonic eventual convergence for desired state configuration ('DSC'). In some situations DSC cannot move toward a desired state without first moving further from that state. For example, a file that needs to be replaced with a newer version but that is currently executing (desired state of 'operating') cannot be replaced without first being stopped. But stopping moves in the wrong direction relative to the desired state, which is to have the service operating. This moving away so as to be able to move forward is a problem for conventional DSC systems that results in failures. The solution to this problem is non-monotonic eventual convergence (&#x201c;NMEC&#x201d;) which enables a DSC system to configure a target system for a desired state by moving further away from a desired state if that is needed to eventually reach the desired state.

Non-monotonic eventual convergence for desired state configuration

Systems and methods for desired state configuration (DSC) are disclosed. DSC provides the ability to perform declarative configuration natively within a shell language and to use early-bound schematized data constructs embedded in a late-bound shell language. This allows declarative programming elements to be incorporated into imperative languages, such as scripts for configuration management. Script may combine the power of an imperative shell language with the ease of use of a declarative language and may use both imperative and declarative syntax in the same language.

Declarative configuration elements

A configuration management system provides a partitioned data model for collecting and representing configuration information from a diverse set of sources to allow easier modeling of very large, highly redundant sets of enterprise configuration information. The system partitions large configuration schema into logical subcomponents that can be combined, shared, and reused. The system also partitions instantiated data models into logical sub-models that can be combined, shared, reused, and incrementally updated. Each product team can provide its own configuration schema, which allows the domain experts in a particular field to provide reusable models for their products. These models may include sub-models that allow reuse of selected portions of the configuration schema. When the system stores data related to each portion of the model, it stores the data in a partitioned manner that makes incremental updates of each component of the model more straightforward and less resource intensive.

Incrementally managing distributed configuration data

Technologies are provided for non-monotonic eventual convergence for desired state configuration. One class of problem in DSC is that, in some situations, DSC cannot move forward toward a desired state without first moving further from the desired state. For example, an executable file providing a service that needs to be replaced with a newer version, but that is currently executing (i.e., in the desired state of 'operating'), cannot be replaced with the newer version without first being stopped. But stopping the service moves in the wrong direction relative to the desired state, which is to have the service operating. This moving away from the desired state so as to be able to move closer to the desired state is a problem for conventional DSC systems that results in failures. The solution to this problem is herein referred to as 'non-monotonic eventual convergence' or &#x201c;NMEC&#x201d;. Such NMEC enables a DSC system to configure a target system for a desired state by moving further away from that state if such is needed to eventually reach the desired state.

Systems and methods for extending a programming language with a set of extensions using a strict meta-model are disclosed. Embodiments provide a set of interfaces that allow a schema to be synthesized. Syntax is introduced into an existing programming language to allow the construction of schematized data objects. A schema processor module translates a schema representation into new keywords. A document generator module receives the set of keywords and produces output in a selected form. When code comprising the keyword extensions is parsed, AST nodes represent keyword actions as a set of functions and implements those function calls with the original meta-data. A keyword definition comprises a name and an action to be taken at parse time and an action to be taken at runtime. The default action at parse time is to inject a function call into the code. The default action at runtime is to call the function.

Programming language with extensions using dynamic keywords

Systems and methods for configuring applications and resources on distributed nodes or machines are disclosed. A node exposes a synchronization resource that corresponds to a desired state on a remote resource. The node evaluates a state of the remote resource. A test function may be defined to check whether the remote resource is in the desired state. A set function may also be defined to set a state of the synchronization resource when the remote resource is in the desired state. The node configures the synchronization resource when the remote resource is in the desired state. The synchronization resource may be configured, for example, using a resource provider. The node may evaluate the states of a plurality remote resources. The synchronization resource may be configured when one or more of the remote resources are in the desired state or when all of the remote resources are in the desired state.

Distributed state model for system configuration synchronization

A workflow scripting system is described herein that combines the features of workflows and scripts by automatically translating between the two models. Using the system, a script author can create workflows on the fly using familiar scripting language, and a workflow author can use scripting steps to perform actions. Workflows run in this manner can be setup to execute in their own process to improve robustness or efficiency. Operations in an enterprise environment frequently take a long time and are subject to interruptions. By adding reliability concepts of workflows to a shell environment, users of the system can write scripts to address common needs of large-scale computing environments. Thus, the workflow scripting system blends the available resources provided by workflow and scripting environments to provide a host of powerful, advanced capabilities to IT personnel.

Automatic transcoding and semantic adaptation between scripting and workflow systems

Method and system for direct access of language metadata are disclosed. In an implementation, the method includes receiving commands from a user to modify language metadata of a programming language. The metadata is modified based on the command and the modified metadata is utilized as a feature in the programming language at runtime.

Direct access of language metadata

A computer monitoring system uses a set of parameterized models to gather information about monitored devices. The models include scripts for gathering information, as well as type validation and data validation functions. The parameters within the model are used to generate user interface prompts and to populate discovery scripts as well as data validation scripts. In some cases, the models may include localization settings that may customize the user interface and validation output for different languages. A processing engine may generate a user interface from the parameters defined in the models, customize the scripts from the user input, and cause the scripts to be executed. The data gathered by the scripts may be analyzed using type validation and data validation.

Parameterized computer monitoring system

Script is accessed and interpreted to identify an executable component. Processing context configuration files may then be used to identify an appropriate processing context for the identified executable component. Examples of processing context include, but are not limited to, a process in which the identified executable component is to run, one or more adaptations to perform on the component prior to running, and/or a security context in which to run the component. Processing context thus need not be specified in the actual script itself. The identified components may then be executed in the identified processing context.

External configuration of processing content for script

In an administrative tool environment, user input is supplied to an administrative tool framework for processing. The administrative tool framework maps user input to cmdlet objects. The cmdlet objects describe a grammar for parsing the user input and input objects to obtain expected input parameters. The input objects are emitted by one cmdlet and are available as input to another cmdlet. The input objects may be any precisely parseable input, such as .NET objects, plain strings, XML documents, and the like. The input objects are not live objects. The cmdlets may operate within the same process. Alternatively, one cmdlet may operate locally while another cmdlet operates remotely. The cmdlets may be provided by the administrative tool framework or may be provided by third party developers. The user input may be supplied to the framework via a host cmdlet.

Administrative tool environment

The adaptation of at least a portion of an object provided by a previous script component to a subsequent script component, despite the subsequent component being incapable of recognizing a format of the at least a portion of the object as provided by the previous component. The previous component generates an object having a property. Adaptation script identifies adaptation(s) to perform on the property prior to being used by the subsequent component. The adaptation is performed, and the adapted property is then used by the subsequent component.

Script-based object adaptation

Computerized facilitation of an assessment of risk associated with running interpretable code. The interpretable code under evaluation is parsed to identify a command unit within the interpretable code. One or more risk factors associated with the identified command unit is then identified using the parsed code. A report is then made of including identification of the command unit found the interpretable code along with the identified associated one or more risk factors. Thus, a user need not have to read and evaluate the interpretable code itself, but may instead review the much less complex report to evaluate the risks associated with running the interpretable code.

Growing community of inventors

Bellevue, WA, United States of America

Bruce Gordon Payette