In continuation to the previous post on getting all overload signature of an object’s method, you would notice that we do not get any help regarding the number and overload for an type’s constructor. To view the overloads of a type constructor, below script can be used.
The above can also be re-written more succinctly using pipelines as shown below..
the results should look like below..
This would help you in knowing which constructor to use while creating new objects of a type.
Powershell ISE is great for authoring of Powershell scripts, however it does not provide intellisense for object method parameters.
For example, if you type the below code snippet on ISE, you do not get any help regarding the parameters GetDirectories can take as input. It also does not indicate if there are overloads for the same method with varying parameters and types.
For invoking these method, we browse through MSDN documentation to figure out the type and number of parameters. However, in powershell we can use the below method technique to view all the method signatures.
The idea is to execute the method without the parenthesis. When a method is invoked without parenthesis, powershell would use reflection and output all the method signatures.
This would help you in knowing which types and overloads to use while invoking the method.
As a continuation to the previous post on generating and applying the MOF files to all machines available within a domain controller (Here), we can use the same concept to configure Local Configuration Manager of all Machines in a domain to execute in Pull Mode.
A sample script that would configure is shown here that would configure all machine to pull configuration information from machine dc01.
The Node element within DSC Configuration accepts an array as computer names. We can use Powershell to generate computer names in the form of an array and pass the same to the node element.
This would generate a unique MOF file for each computer name found in Domain controller.
It would generate multiple MOF files at “C:\MofFiles” folder, each representing a computer or server.
Hope you would find this post useful.
Orchestrator stores information about folders and Runbooks in parent-child hierarchy within SQL Server Database. Folders and Runbooks can be nested with each other in great depths. At times, we need the entire path of the Runbook from the hierarchy and there is no easy out of box way to retrieve it through the product. SQL Query comes to the rescue!!
We can use the below sql query to obtain all the folder and Runbook paths within an Orchestrator installation. It will get runbooks that are not deleted and are enabled. ‘00000000-0000-0000-0000-000000000000’ in below query is the top level parent in the hierarchy and refers to the Policies folder.