Abstract: 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.

Abstract: 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.

Abstract: A command line utility is described that overlays the management infrastructure of an enterprise to provide easier command options for administrators to effectively manage the enterprise. The primary intent of the command line utility is to facilitate management of the environment without requiring administrators to write scripts or navigate a vast schematized enterprise exposed through the management infrastructure. The command line utility provides command options through class aliases that enable the mapping of management queries and operations to a common term or friendly name that can be extended both in an alias file or at run time in the command line.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: The facilitation of error detection in interpretable code prior to run-time of the interpretable code. Upon accessing an interpretable command, corresponding structural rules for the interpretable command are used to automatically formulate a compilable linkable representation of the interpretable command that conforms to the construction rules. Source code may then be formulated that, when compiled, is linked to the compilable linkable representation of the interpretable command. If there are compilation errors, those errors may be discovered at compilation-time, rather than waiting until run-time. On the other hand, if there are no compilation errors, the compiled object may be executed to thereby invoke the interpretable command.

Abstract: 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.

Abstract: Described herein are technologies directed towards providing a common mechanism for tracking the activity status of one or more software actions of a computer system. Furthermore, the described technologies facilitate managing the presentation of the tracked activity status of individual actions and/or of a collection of such actions.

Abstract: An exemplary software architecture allows for defining and accessing data and auxiliary data for an item in a navigable namespace. For example, such an exemplary architecture can include a provider engine operable to access data for an item in a navigable namespace, an auxiliary provider engine operable to access auxiliary data for the item and an auxiliary provider class for use in defining the auxiliary data for the item and accessing the auxiliary data for the item. Various other exemplary technologies are also disclosed.

Abstract: The techniques and mechanisms described herein are directed to an interpreter security mechanism that minimizes security risks associated with interpreting a script written with a scripting language. The interpreter security mechanism recognizes a marker that indicates a beginning for a set of non-interpreted lines. Upon recognizing the marker, the interpreter refrains from interpreting subsequent lines in the script until an end of marker occurs or an end of file occurs. The end of marker indicates that the interpreter can resume interpreting the lines in the script that follow the end of marker.

Abstract: The techniques and mechanisms described herein are directed to a taint mechanism. An object-based command declares a taint directive for a parameter within a command declaration. The taint directive is then associated with that parameter in a manner such that when an engine processes the command, the engine determines whether to process the command based on the taint directive and input for the parameter. The taint directive may specify that the input may be tainted or untainted. The command declaration may also include a taint parameter that specifies a taint characteristic for output from the command. The taint characteristic may be tainted, untainted, or propagated. Any type of object may become tainted. An untaint process may be applied to tainted data to obtain untainted data if an authorization check performed by the engine is successful.

Abstract: The techniques and mechanisms described herein are directed to an extensible security architecture that provides a security mechanism for minimizing security problems within interpretive environments. The extensible security architecture comprises a script engine configured to process a script and a security manager configured to monitor the processing of the script based on a security policy. The security manager determines whether to open an assembly associated with a command within the script, whether to process the command, whether to allow certain input to the command, and the like. The security policy may be implemented by overriding one or more methods of a base security class that are called when processing the script. The input may be an object passed via an object-based pipeline.

Abstract: The techniques and mechanisms described herein are directed to a scripting security mechanism that minimizes security risks associated with interpreting a script written with a scripting language. An interpreter recognizes the scripting-language syntax within the script and processes each line that is designated within a data block using a restrictive set of operations. The restrictive set of operations are a subset of the total operations available for processing. If one of the lines within the data block attempts to perform an operation that is not within the restrictive set of operations, the interpreter provides an indication, such as an exception or message explaining the illegal operation. The interpreter also recognizes a list of export variables associated with the data block and exports only the variables identified in the list to an external environment if the export variable meets a constraint identified for it, if any.

Abstract: Systems and/or methods are presented that may be used to enable operation of a command line having an upstream command and a downstream command where the upstream command may output data of a type that may be unacceptable as input to the downstream command.

Abstract: The present comparison technique operates on objects having the same type, similar types, or different types. Multiple comparison objects may be compared against one or more reference objects. The comparison objects may be obtained from a prior cmdlet in a pipeline of cmdlets operating in an object-based environment. The reference object and comparison object may be compared in an order-based manner or in a key-based manner. In addition, specific properties may be specified which will identify which properties of the reference object and the comparison object to compare during the comparison. The comparison may generate an output that identifies the difference and/or similarities. The output may be pipelined to another cmdlet for further processing.

Abstract: A command line environment is configured to receive a command line that implicates a plurality of remote nodes. The command line environment is configured to establish a session, which may be persistent, to each implicated remote node, and to initiate execution of the remote command on those nodes. The session may be assigned to a variable, and the remote execution may be performed concurrently. Results of the remote execution are received and may be aggregated into an array. The command line environment may distribute the task of establishing sessions to other systems to improve performance.

Abstract: A system and method for securely transferring computer-readable objects across a remote boundary is provided. The method decomposes any type of object into a hierarchy of sub-components based on a list of known object types. Each sub-component either corresponds to a known object type or an unknown object type. The unknown object types may be decomposed further into known object types at another level in the hierarchy. The known objects in the hierarchy are serialized into a package that is transmitted to a remote entity. The remote entity reconstructs the hierarchy. For any of the known object types, the remote entity instantiates an object of the known object type and populates the object with information transmitted in the package. The decomposition may be limited by specifying a level for the hierarchy, specifying a number that limits the known objects that are serialized, or specifying the properties within the object to serialize.

Abstract: The present mechanism provides a grammar for specifying required prerequisites (e.g., number and type of input parameters) that an object must possess in order for processing to occur on the object. The mechanism allows programmers and non-programmers to easily specify these prerequisites. The prerequisites may be associated directly or indirectly with a data structure. For a direct specification, the data structure comprises a parameter declaration for each expected input parameter. For an indirect specification, the data structure comprises a parameter definition that references an external description, such as in an XML document. The data structure also providing a mechanism that identifies a corresponding parameter within an input source for each expected input parameter based on its declaration. The input source does not include live objects.

Abstract: 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.