It’s almost a year since Royal TS became Shareware. When you obtain a license for Royal TS you also get a 12-month software upgrade protection to ensure that you have access to the latest versions of Royal TS for a year after your purchase date.

Some of our very first customers were asking about extending the software upgrade protection and thought it might be a good idea to publish a blog post to clarify a few things about our licensing. So here we go…

First of all, there is no extension for the software upgrade protection and there is no need for that. Here's why and how we planned our licensing structure:

The license key currently issued is bound to the Royal TS Version 1.6.x

The next major version of Royal TS (V2.0) a new license key will be needed. The keys for 1.6.x will not work anymore. The key issued for Version 2.0 will work with all minor versions of version 2.x. Version 3.0 will need a new license key again and so on.

With our software upgrade protection we ensure you have access to all new major and minor releases for a duration of 12 months after purchase. This way you will not have to buy another license a month later after your purchase in case a new major version is released.

Every customer qualifying for a free upgrade according to our software upgrade protection will get the new license key automatically by email when the new release is available.

Every customer who does not qualify for a free upgrade anymore (because the purchase date was back more than a year) will get automatically notified by email when a new major version is released and they will also get a discount coupon to use when they decide to upgrade to the new version.

We think this is a very fair approach because you do not have to pay for an extension without having a new major version on the horizon but at the same time ensures that loyal customers get the benefit of a discount when the release is ready and they decide to upgrade.

I hope this makes sense and want to express my appreciation for all of you supporting Royal TS. Thank you!

We are still working hard on version 2 of Royal TS but over the last couple of months we also needed to take care of some bug of the current version. One of the current issues are some Windows 7 quirks which will hopefully be ironed out with the upcoming release 1.6.8. But here a complete list of fixes and features:

Windows 7 / Font related:

It seems that in Windows 7 the font size changed slightly. At least in some dialogs there are tiny text-cut-offs. These should be fixed now. Another issues for a lot of users is the text size in the tree view and the list view. We were always following the best practices and Windows design guidelines. We used the standard system font and size as recommended. So, when switching from XP to Vista/Win7, Royal TS will use a different (and larger) font. We got a lot of feedback about these issues and implemented a quick fix.

For once we will reduce the default font size back to 8.25pt instead of 9.0pt regardless of the OS.

Additionally we will provide a way to change the font and font size for both separately, the tree view and the list view. For now, there’s no UI for this because we basically rewrite all the UI for V2 and didn’t want to invest much in the soon to be obsolete UI. You need to edit some XML to set the font or font size.

Which brings us to another small but useful new feature: directly opening the config folder from Royal TS. A frequently asked question always is: Where are my task and application settings stored. And the answer is not always easy because it depends if you have some folder redirection policies and it also depends on the OS you use.

So, if you open up the Activity Log from the View menu, notice the Config Folder button on the toolbar:

Clicking on this button will open a File Explorer displaying the directory with your setting files.

When you now open the code4ward.RoyalTS.ApplicationSettingsData.xml you will see the following new settings:

The order of the items may be different on your system.

LegacyTreeStyle can be true or false: When true, it will display +/- signs (XP style) instead of the little triangles (Vista/7 style).
ListViewFontName can be Default or a font name of your choice: When set to Default it will use the system’s default font.
ListViewFontSize can be Default or a size of your choice: When set to Default it will use 8.25. If you use Vista or Windows 7 and want to use the system’s default font size you need to change it to 9.0!
TreeViewFontName and TreeViewFontSize will be the same as ListViewFontName and ListViewFontSize except it controls the font of the tree view.
TreeViewHighlightType is by default None and can be Full, Partial or TextOnly: Controls how the items in the tree view will be highlighted after selection.

Control on which Screen the session will appear when it’s not embedded

Notice that there’s now the possibility to setup on which display screen your external session will be opened. This option is only available when you have selected External Window or External Window (Full Screen) and when you have more than one display connected to your computer. The default value is Last Remembered, which saves the position of your session when the window is closed or the session is disconnected but selecting a specific display let’s you force to open it always on the specified screen.

Also note the shortcut to the Display Properties Control Panel, which might be handy if you do not know what display number corresponds to your actual screens.

If more than one display is connected, you can also use the Connect with Options functionality to temporarily open a connection on a specific monitor.

Changes to the Remote Desktop Module

Royal TS now sports a fancy Connecting and Reconnecting indicator:

An often requested feature is to have a better reconnect function to instruct Royal TS to keep on trying to reconnect during a reboot of the remote system. This feature is still NOT available but this indicator is the first of two steps to get it implemented. The idea is to have a checkbox of some sort which says Try to reconnect until server is available again.

Network Level Authentication (NLA):

Royal TS supports NLA and on Windows 2008(R2) and Vista/7 NLA is enabled by default meaning the client trying to connect needs to have NLA enabled. If NLA is not enabled the connection fails with the error code 2825. If this error occurs and the connection doesn’t have NLA checked in the advanced settings tab, Royal TS not only publishes a warning about that, it is trying again with NLA enabled automatically.

Single Sign On:

Royal TS now also supports SSO (big thanks to Wulfert on supporting me with testing and providing valuable information!). You need to setup your environment according to this blog post of the Terminal Services Team Blog: http://blogs.msdn.com/rds/archive/2007/04/19/how-to-enable-single-sign-on-for-my-terminal-server-connections.aspx

If you can connect using mstsc.exe without your explicit credentials (your desktop credentials are passed through to the remote system using Kerberos) you can now also use Royal TS. Just leave the credential information blank (no Username, Domain and no Password), enable Network Level Authentication (NLA) in the Advanced tab of your connection and set Auth. Level to Connect, but warn me if server authentication fails.

Other fixes:

• Individual disk redirection on Windows 7 is now working correctly.
• TS Gateway Credentials are now remembered.
• Bulk Reconnect from the list is now working.
• Some minor UI fixes.

One feature needed to be removed!

A quite handy feature I cannot miss anymore is to move an existing connection out of the main window into an external window using the Change menu. If you are working on two machines and you need to quickly compare something, you can easily pull out one session to an external window and put it on the second screen. Don’t worry, this will still be possible!

The feature that needed to be dropped is Window Mode: External (Full Screen). As you can see in the screen shot above, it’s not available anymore. You can of course still open an external session from scratch in external full screen mode, you just cannot do it with an initially embedded session. The ActiveX control seems to be very unstable when doing this and sometimes it worked but then again sometimes not. So for quality reasons I decided to take it out. Nobody is happy about application crashes…

When will 1.6.8 be available?

Beta testing of 1.6.8 will start within the next few days. If you want to participate and try out the beta you can easily join the beta group. To do so, you need to create an account on the code4ward site (if you do not have one already), sign in and click on this link: http://www.code4ward.net/main/Default.aspx?rsvp=RTSBETA

Clicking on this link doesn’t really give much feedback. To verify if you are member of the beta group, click on your user name on top, right side and click on Manage Services in your Profile. If you see Royal TS Beta Group, you are in.

Member of the beta group will get email announcements about new beta releases and access to the beta forum to discuss the current beta release.

If you decide to try out the beta, always make backup copies of your .rts files and setting files (like task settings if you have lots of them).

Depending on the issues found in the beta 1.6.8 will be publicly released within the next two or three weeks.

Thanks for all of you who provided feedback, suggestions and bug reports. Your help is very much appreciated!

This is a LGIMB-post (Let Google Index My Brain) so that I know where to look for when I need it.

I became a link to Kevin Holman’s blog from a support engineer where all SCOM hotfixes are listed. It’s an old post but constantly updated like just yesterday to include the SP1 rollup hotfixes.

http://blogs.technet.com/kevinholman/archive/2009/01/27/which-hotfixes-should-i-apply.aspx

This is a step-by-step guide in multiple parts:

Part 1 will cover the Probe Actions Module Types: Part 1 is available on SCC or on code4ward 
Part 2 will be about creating a Data Source: Part 2 is available on SCC or on code4ward
Part 3 will cover creating a Monitor Type: Part 3 is available on SCC or on code4ward
Part 4 will cover the Unit Monitor itself

As always be careful with the samples provided here. Always use a test environment first to try those examples!

Will only work with OpsMgr 2007 R2 !

Part 4: Unit Monitor

Selecting a Target

In this demo, I will target the Root Management Server class to keep it simple. This way we do not have to go through all the steps to disable the monitor and enable it with an override, etc. Another way to find an appropriate target is to discover one. The environment we are working in, admins can configure their own monitoring by just providing some registry keys and values. This registry information is discovered, an instance of a custom class (which is hosted on a computer) will be created and most properties of this class are holding the configuration values for the monitor. My friend Tenchuu mentioned to publish some blog posts about PowerShell discovery and he also wants to blog about this concept.

Creating the Unit Monitor

	Change to the Health Model space and select Monitors in the tree. Right-click into the Monitors pane and select New->Custom Unit Monitor I specified as ID: code4ward.Sample.PowerShellMonitor.Monitor.FileContentCheck Display Name is: File Content Check Monitor As Target choose Browse all classes…
	As I mentioned earlier, for this demo we use the RMS. In production environments you do not want to do that. Always use own custom classes or target your monitors according to the best practice white papers and create appropriate overrides to enable your monitor for a group of instances. As Parent Monitor we will select System.Health.AvailabilityState
	In the Configuration tab we will click on Browse for a type… and select our monitor type we created in part 3 of this series.
	When we selected our type you will be presented with a generic configuration UI. These are the config values we defined in the monitor type. We will provide some hardcoded values in here (see screenshot). In this example we will set Debug to false by default but for troubleshooting you could create an override for a specific instance or a group of instances to enable debugging. As you may remember, we allowed the override of the debug parameter in our monitor type. You can also access your target’s properties using the fly-out button. So let’s pretend you discover your own class with a property called LogFile, you could target this monitor to that class and pull in the LogFile parameter into the File config value to dynamically fill in your file to monitor.
	The next tab looks familiar and provides to UI to define the health state conditions. The column Monitor Condition will show you the names/IDs we provided in our monitor type.
	As usual you can configure the alerting for the monitor. Notice that we pull out the MessageText value from our property bag. We will skip the Diagnostic and Recovery task for now. This is because we first need to successfully save the monitor before we actually can add a recovery or diagnostic tab. I’m not sure if this is by design or a bug, but when you try to do it before you actually saved the monitor you cannot select the parent monitor in the task configuration (because it just doesn’t exist yet).
	In the Options tab we adjust the Category to AvailabiliytHealth Usually you want to set Enabled to false by default and create an override to enable this monitor but in this case we leave it enabled because we targeted the RMS for this demo. Now let’s hit OK and reopen the monitor we just created.
	Change to the Diagnostic and Recovery tab, click on Add… and select Diagnostic for critical health state Specify a unique ID for that task like: code4ward.Sample.PowerShellMonitor.Diagnostic.FileContentCheck We name the task: Execute File Content Check Here a little hint: you can also create a diagnostic task for the healthy state. In the Configuration tab you can change the value in the drop down list: Execute when monitor’s health is: to Success
	In the Modules tab click on the Create… button in the Actions section and look for the Probe module we created in our first part. This time the one which is called AsTask at the end.
	You need to type in the same configuration as we provided for the monitor. If you do not want to execute this diagnostic task automatically when the state changes you need to disable the task in the Options tab.
	Creating an Agent Task is very similar. Just select to create a Custom Task and browse for the same type as in the diagnostic task. Provide a configuration and you are done.
	Create a file C:\test.txt or whatever file you specified in the config of the unit monitor. When the text file contains the string ERROR! you will get a unhealthy state for the monitor and an alert.   Import the MP and change the target type in the Discovered Inventory view to Root Management Server.
	Then open the Health Explorer and look for the monitor File Content Check Monitor. Also notice that we have our diagnostic task which can be executed and displays the property bag in the output.

That’s it. If you have any suggestions for improvement, questions or general feedback on this series, do not hesitate to contact me or leave a comment. I’ve also attached the complete management pack with this sample monitor.

cheers,
Stefan Koell
http://www.code4ward.net

This is a step-by-step guide in multiple parts:

Part 1 will cover the Probe Actions Module Types: Part 1 is available on SCC or on code4ward 
Part 2 will be about creating a Data Source: Part 2 is available on SCC or on code4ward
Part 3 will cover creating a Monitor Type
Part 4 will cover the Unit Monitor itself

As always be careful with the samples provided here. Always use a test environment first to try those examples!

Will only work with OpsMgr 2007 R2 !

Part 3: Monitor Type

What’s a Monitor Type?

A monitor type actually defines the workflow for a monitor. So, before you can create a monitor you need to hook up different modules and specify how these play together and what the monitor should do. The first two parts showed how to create these modules and data sources and now all those modules are coming together…

Creating the Monitor Type

	Let’s navigate to the Monitor Types section in the Type Library space. Right-click on the Module Types panel and select New –> Composite Monitor Type. Type in an ID like: code4ward.Sample.PowerShellMonitor.MonitorType.CheckFileContent Also provide a Name like: Check File Content Monitor Type
	Click on the States tab and provide some meaningful IDs for the two states our monitor can have. In our case: ID of state 1 will be Healthy and ID of state 2 will be Unhealthy A three state monitor is not much different than a two state monitor. If you go through this guide you should also be able to create a three state monitor.
	The Member Modules tab is a bit different in this case. What here happens, is basically just the definition of modules and their configuration. There’s no order of execution of these modules. So here we define all our modules we need for our workflow and we start with our Data Source we created in Part 2. Click on the Add… button and look for the Data Source code4ward.Sample.PowerShellMonitor.DataSource.CheckFileContent As ID we specify DS (again, as mentioned in the previous parts, this ID must only be unique for the modules we need here, it doesn’t need to be unique through the whole MP!)
	After you hit OK, the configuration window of our module will show up. All the parameters for our data source will be set to $Config/…$ (see screenshot). You can use the fly-out button and select the Promote menu item to automatically fill in the $Config/…$ values. Just to repeat this one, here we define that our consumer (in this particular case the unit monitor) will provide these values. Every value you will set here “hardcoded” will not be configurable in the unit monitor. Also, remember, that if you have defined optional (non-required) parameters in the data source, you may need to add them manually by clicking on Edit… and use a XML editor (such as Notepad.exe or Visual Studio) to put in your parameter. A side note: when you use Visual Studio, an XML schema will be generated and used automatically which speeds up XML editing! In our case, no optional parameters are defined or needed, so nothing special to do here.
	Next we need two modules to evaluate our health state. Remember, our script returns a property bag, so we need to look for a value in our property bag (in our case “Status”) to determine if the health state is “Healthy” or “Unhealthy” (as we defined those IDs for our health states). So click on Add… again and look for the System.ExpressionFilter module and give that one the ID HealthyExpression. When the Configuration window appears, do not bother to insert data into the generic XML mask, click on Configure… to open up the expression builder UI.
	There we specify our expression for the Healthy state: Property[@Name=’Status’] Equals OK Click on OK and let’s do the same for the Unhealthy expression
	Same procedure as 2 steps above. We just specify another ID: UnhealthyExpression
	Type in the following in the expression builder: Property[@Name=’Status’] Equals ERROR
	At this point we would have already enough to create a two state monitor. Our data source which basically executes our script probe on a schedule and two expressions, one for each state. We will add two more modules. We need them to configure “On Demand” detection (= Recalculate Health button in Health Explorer).
	To enable on demand detection, we need our script probe we created in Part 1 of this guide and a PassThrough module (which is simple and doesn’t need any configuration). Click on Add… again and look for our Probe Action from Part 1 (NOT the one  we created for our Tasks!) The ID will be something like “Script”.
	In the Configuration window we will again Promote the parameters with the fly-out button, except the ExecutedAsTask parameter can be set to false, because the situation where we use this module will never see that parameter set to true. One question will arise here: We already configured the parameters $Config/File$, $Config/ErrorText$ and $Config/Debug$, what will happen now? The answer is fairly simple: In this case both modules will use the same parameter. When we configure the unit monitor we provide the parameter for $Config/File$ once and will be used in both modules. Our On-Demand detection will now execute our Probe Action module and use the same parameter as the Data Source we defined in this workflow. So when we set the Debug parameter to true on the monitor level, we will get debug information every time the monitor is executed and every time we do a Recalculate Health. Let’s say we always want to avoid debug information when we click on Recalculate Health, we just need to “hardwire” this parameter to false in this Configuration window and it will always be false in this workflow.
	The last module we need, is a PassThrough module. This module doesn’t need to be configured at all and is just needed to kick-off the workflow in the On Demand module. Do not ask me what it does exactly, I just know it is needed. Now let the fun part begin and change to the Regular tab to setup the workflow.
	In this tab we define for each health state (in our case two states) the workflow. So select the Healthy state in the list and check all modules we need in this workflow to evaluate a healthy state: We need our Data Source, we called it DS and our HealthyExpression. When those two modules are enabled, we need to define the execution order of these modules using the drop down lists in the Next Module column. The start of our workflow is the Data Source (DS), so here the Next Module must be set to HealthyExpression. The HealthyExpression is the last module in this workflow, so the Next Module must be set to Monitor State Output.
	Let’s move on to the Unhealthy state. Check all modules we need in this workflow to evaluate a unhealthy state: We need our Data Source again and this time the UnhealthyExpression Again, when those two modules are checked and enabled, setup the execution order: The start of our workflow is again the Data Source (DS). The Next Module must be set to UnhealthyExpression. The UnhealthyExpression is the last module in this workflow, so the Next Module must be set to Monitor State Output. That’s it for our two state monitor. Now we will setup the On Demand detection.
	First we need to check the Use On Demand Detection check box. On top of this dialog you have again both available health states. We need to setup a workflow for each health state. Select the first state (Healthy) in the list if not already selected and enable the modules needed for this workflow. In this case we need the PassThrough module, the Script (our Probe Action) and again the HealthyExpression. For the On Demand detection the first module is always the PassThrough module, so we select the Script module as Next Module for the PassThrough module. The Script module will return our property bag which needs to be passed on to the HealthyExpression module. The HealthyExpression module is our last in this workflow, so we set Monitor State Output as Next Module.
	Select the Unhealthy state in the list and let’s do the same workflow but in the end we will use the UnhealthyExpression module instead of the HealthyExpression. After that we finished all our workflows. Each workflow (healthy and unhealthy) will always be executed independently each time the monitor will run. So if you use other criteria in your expression (some performance value instead of a status text, or some and/or logic), be sure that each expression will uniquely identify each health state.
	As in our previous modules we need to be sure that the configuration schema is correct. The authoring console doesn’t always pre-set the right data type for each configuration value. So double check that Interval is an Integer and Debug is a Boolean.
	Now to the Overridable Parameters tab. Use the Add… button on the bottom to allow overrides on individual parameters. You may notice that I do not want to provide a way to override the File to monitor. This of course is up to you what you allow to be overridden and what not. I think it’s always a good idea to allow an override on Debug and Interval, this way you can look into issues on a specific server or change some configuration for a group of computers or so. As mentioned in the previous parts, you can mark this Monitor Type as Public, so that other MPs can reference your MP and use your Monitor Type (if sealed, of course). Click on OK and you are done!

That’s it for part 3. The next step will be creating the unit monitor and a task.

cheers,
Stefan Koell
http://www.code4ward.net

MS released an update earlier this week for XP SP3, Vista SP1/SP2 to install Remote Desktop Connection 7.0.

Follow this link to download the package: http://support.microsoft.com/kb/969084

Follow this link to see what exact features are available in RDC 7 on which OS: http://blogs.msdn.com/rds/archive/2009/08/21/remote-desktop-connection-7-for-windows-7-windows-xp-windows-vista.aspx

So far no word from MS if and when a client update like this may become available for Windows 2003/2008.

I wasn’t yet able to fully test this update with Royal TS but so far (on a Vista x64 box) it’s working fine. Anyone having issues with that? Let me know…

This is a step-by-step guide in multiple parts:

Part 1 will cover the Probe Actions Module Types: Part 1 is available here on SCC or here on code4ward 
Part 2 will be about creating a Data Source
Part 3 will cover creating a Monitor Type
Part 4 will cover the Unit Monitor itself

As always be careful with the samples provided here. Always use a test environment first to try those examples!

Will only work with OpsMgr 2007 R2 !

Part 2: Data Source

What do we need a data source for?

The data source we create will be needed in out monitor type (which will be explained in Part 3 of this series). So far we only defined a module which is returning a property bag with our state information and a wrapped up module we use for a (diagnostic-)task later on. In the latter case, the trigger for our module will be the operator launching the task. For our monitor we need a scheduler to trigger our probe – so for this we will create a simple data source.

Creating the Data Source

	Change to the Data Sources node and right-click to create a New->Composite Data Source… The ID will be: code4ward.Sample.PowerShellMonitor.DataSource.CheckFileContent Name will be: Check File Content Data Source
	Now change to the Member Modules tab and click on Add… Look for the System.Scheduler, select it and give it an ID like: Scheduler Remember, the ID we choose here needs only to be unique within the Member Modules scope, it doesn’t need to be unique for the whole MP. Therefore you can also choose the ID Scheduler for another data source in this MP. Hit OK.
	We will configure this module that all the configuration will be passed on from its consumer. You can use the fly-out button and select Promote… to fill in the appropriate $Config values.
	Now let’s add another module, our Check File Content Probe we created in the first part. We ID it Probe
	The configuration of our Check File Content probe is also straight forward. All parameters (except the last one) will be populated by its consumer. The last parameter will be set to false. We know that the module in this data source will never be used with the additional information we provide when we execute it as task.
	Before we move on to the next tab, we need to define the order our modules are executed: The Scheduler is our first module, which is basically triggering the workflow. So, in the Next Module column we set Probe as our next module to be executed. the Probe module will provide the Module Output
	In the Configuration Schema tab we need to verify (again) that all the data types are set accordingly. The authoring console tends to always use String as type, so we need to correct them to set Interval to Integer and Debug to Boolean. Also keep in mind that optional parameters will not be shown here by default. In case you have modules with optional parameters you need to add them explicitly. It is also important the the order of the parameters are correct! In our case we do not have and use any optional parameters, so nothing to do for us here. But if we would have defined an optional boolean parameter named “Bob” in our CheckFileContent probe after the ErrorText and we want to use it, we must add this parameter manually to this list right after the ErrorText parameter and set it to boolean. The arrows next to the list allows to reorder the list.
	In the Overridable Parameters tab we add all our parameters to the list. As mentioned in Part 1, if you want to seal you MP and want others to use this data source in their own MP you need to mark this data source Public in the Options tab.

That’s it for part 2. The next step will be creating the monitor type.

cheers,
Stefan Koell
http://www.code4ward.net

This is a step-by-step guide in multiple parts:

Part 1 will cover the Probe Actions Module Types
Part 2 will be about creating a Data Source
Part 3 will cover creating a Monitor Type
Part 4 will cover the Unit Monitor itself

As always be careful with the samples provided here. Always use a test environment first to try those examples!

Will only work with OpsMgr 2007 R2 !

Part 1: Probe Action Modules

In the following example we will use a PowerShell script to check for a string in a file. If the string is found we alter the health state to “Unhealthy”, otherwise the health state is “Healthy”.

param([string]$file, [string]$errorText, $debug, $executedAsTask)

if ($debug -ne "true"){$debug = [bool]$false}else{$debug = [bool]$true}

if ($executedAsTask -ne "true"){$executedAsTask = [bool]$false}else{$executedAsTask = [bool]$true}

$Script:API             = new-object -comObject "MOM.ScriptAPI"

$Script:Bag             = $Script:API.CreatePropertyBag()

$Script:LOG_ERROR       = 1

$Script:LOG_WARNING     = 2

$Script:LOG_INFORMATION = 4

$Script:ScriptName      = "code4ward.Sample.PowerShellMonitor.ps1"

$Script:Arguments       = "Received Arguments:`rFile = $file`rErrorText = $errorText`rDebug = $debug`rExecutedAsTask = $executedAsTask"

function Write-DebugInfo([string] $msg)

{

    if ($debug) 

    {

        $Script:API.LogScriptEvent("$ScriptName",100,$Script:LOG_INFORMATION,"`r$Arguments`r`r$msg")

    }

}

function Write-ErrorInfo([string] $msg)

{

    $Script:API.LogScriptEvent("$ScriptName",500,$Script:LOG_ERROR,"`r$Arguments`r`r$msg")

}

Write-DebugInfo "Script started..."

if ($file.Trim().Length -gt 0)

{

    $FileExists = (Test-Path $file)

}

else

{

    Write-ErrorInfo "No file was specified."

    return

}

if (-not $FileExists) 

{

    Write-ErrorInfo = "File '$file' not found."

    return

}

$File = Get-Item $file

[string]$FileContent = @()

foreach ($Line in Get-Content $File)

{

    $FileContent += "`r$Line"

}

if ($errorText.Trim().Length -gt 0)

{

    if ($FileContent.Contains($errorText))

    {

       $Script:Bag.AddValue("Status","ERROR")

       $Script:Bag.AddValue("MessageText","Error text '$errorText' found in file '$file'.")

    }

    else

    {

       $Script:Bag.AddValue("Status","OK")

       $Script:Bag.AddValue("MessageText","Error text '$errorText' not found in file '$file'.")

    }

    if ($executedAsTask)

    {

        $Script:Bag.AddValue("AdditionalStuff","goes here")

    }

}

else

{

    Write-ErrorInfo "No error text specified"

}

#$Script:API.Return($Bag)

$Script:Bag

Write-DebugInfo "Script ended..."

Note that at the very end of the script we just write $Script:Bag and NOT $Script:API.Return($Bag) as you might expect. However, I left this line commented in the script for testing because only the return command will generate the property bag data in the console which is useful for testing and debugging but the Module we are using soon will not work with the Return method.

How will this script be used?

We create one module holding the script and it’s configuration. This module will be used for our data source (scheduled) and the monitor type for “On Demand Detection” (enabling the recalculate health functionality). We create a second module wrapped around our first module with a different configuration to use the same script as a diagnostic or agent task. The reason for the second module is to illustrate the concept of wrapping modules providing the same functionality but with different configuration. In our case, the overridable parameters and the configurable parameters will be different in the second module.

The documentation on Technet is getting better and better. For a module reference visit: http://technet.microsoft.com/en-us/library/dd391800.aspx

What are the parameters for?

File: specify the full path to the file to check for
ErrorText: the string we are looking for and generate an alert
Debug: can be “true” or “false”. If true additional information will be published to the event log.
ExecutedAsTask: in this example only used to illustrate that we can use the same script for different modules/tasks. In a real world script you may use this to provide an extended property bag to pass more information to your operator.

There’s no error handling in this script, therefore it is far from production quality and only used to show the concepts of a PowerShell 2-state-script-monitor!

Creating the Modules

	Open up the “Authoring Console” (needs to be installed separately and can be found on the SCOM R2 media) and let’s create a new management pack using File->New…   The MP ID is: code4ward.Sample.PowerShellMonitor The Display Name is: code4ward Sample PowerShell Monitor Now let’s navigate to the Type Library space, and select Type Library\Module Types\Probe Actions in the tree view.
	Right-click in the Probe Actions and select New->Composite Probe Action. Type in an ID: code4ward.Sample.PowerShellMonitor.Probe.CheckFileContent Type in a Name: Check File Content
	Change to the Member Modules tab and click on Add… Now look for the PowerShellPropertyBagProbe module, select it and specify an ID for the module like Probe Click OK. Back in the Member Modules tab click on Edit and again in the configuration window click again on Edit and choose an external editor (like Notepad) if not already chosen.
	Replace the XML stuff inside the <Configuration> element with the code below and not that the script body needs to be filled as well with the script at the beginning of this post. <ScriptName>code4ward.Sample.PowerShellMonitor.ps1</ScriptName> <ScriptBody> <![CDATA[ SCRIPTBODY GOES HERE ! ]]> </ScriptBody> <Parameters> <Parameter> <Name>File</Name> <Value>$Config/File$</Value> </Parameter> <Parameter> <Name>ErrorText</Name> <Value>$Config/ErrorText$</Value> </Parameter> <Parameter> <Name>Debug</Name> <Value>$Config/Debug$</Value> </Parameter> <Parameter> <Name>ExecutedAsTask</Name> <Value>$Config/ExecutedAsTask$</Value> </Parameter> </Parameters> <TimeoutSeconds>300</TimeoutSeconds> After you closed the configuration dialog, select Module Output in the drop down list in the Next Module column.
	Now let’s switch to the Configuration Schema tab. Use the Add… button on the bottom of the dialog to create the parameters as shown in the screenshot. Watch out for the type drop down list and ensure that the type is correct for each parameter.
	Now we move on to the Overridable Parameters tab and add all of our parameters to the list. When you click the Add… button, a menu shows you all available parameters we defined in the previous tab. Just select one after the other and to keep it simple we call them the same as defined in the configuration. (The name you specify here will appear in the override dialog.) Also, always verify the data type in the Configuration Element column.
	In the Data Types tab we need to check the radio button This module requires input data.
	Last but not least, we change the Accessibility proerty to Public. This is optional and may be useful when you seal your MP and provide these modules to use in other MPs. Now let’s hit OK and see if we can successfully close this dialog. If you get an exception, you may have a typo or a wrong order of parameters, which is also very important.
	As mentioned before we will create a module based on the just created one to provide a different configuration. Again, right-click on the Probe Actions pane and select New->Composite Probe Action… This one gets the ID: code4ward.Sample.PowerShellMonitor.Probe.CheckFileContentAsTask The name is: Check File Content as Task
	In the Member Modules tab we click on Add… again but this time we choose the module we just created.
	Now we will see the configuration we just created in the previous module. Except for the ExecutedAsTask configuration we use the little arrow button on the right side of each value and hit promote. This means File, ErrorText and Debug will be passed to the module using our configuration (where we actually use this module) and the ExecutedAsTask will be set to true. Click on OK and don’t forget to set the Module Output in the Next Module column.
	The Configuration Schema tab should know all your config settings for this module but always check for the right data type! In our case you need to explicitly set Debug to Boolean. I guess this is a bug in the Authoring Console because for some types this works automatically for some others not. Maybe future releases of the Authoring Console will be more reliable in this regard.
	Next tab Overridable Parameters. In this derived module we only allow to override the Debug value. Because the task will be available in the diagnostics of the monitor, we already know which File and what ErrorText we want to check.
	As in the previous module, we need to set the Input Data right in the Data Types tab.

That’s it for now. The next step will be creating the Data Source.

cheers,
Stefan Koell
http://www.code4ward.net

This is a step-by-step guide on how to create a PowerShell tasks using the authoring console. This will only work for OpsMgr R2 installations!

I am not exactly a certified-OpsMgr-under-the-hood-specialist – I had the honor to be part of a workshop where Brian Wren (http://blogs.technet.com/brianwren/) revealed some OpsMgr secrets. So this post is for one part storing my gained knowledge in the Interwebz so that Google can index it and I can find it again, another part of course is to give something back to the community. So if you have suggestions for improvements or any questions, go ahead and comment on this post.

For this guide we create a task which allows us to set a registry value on a remote machine.

Why do we want to do this? First of all, it is a great example to show some concepts behind Module Types. Secondly, we use a task like this to set some custom computer attributes. We use some additional computer attributes to mark a computers productive, test, etc. We do that by looking for a registry value and discover these attributes (maybe a topic for another guide). To easily move a computer from test to production we just need to set a registry value.

Here a short overview of this blog post:

1. We need a PowerShell script: SetRegistryValue.ps1
2. We will create a generic module type allowing us to set any registry value
3. We will create a wrapper for this module type to set a registry value in a specific key using our generic module type
4. We will create an agent task consuming this module and provide two overridable parameters. One for debugging, and one providing the value for the registry

1. The Script:

# Script Name:  SetRegistryValue.ps1
# Parameter 1:  path  (e.g. "HKLM:\Software\Somekey\Somesubkey")
# Parameter 2:  name  (e.g. "SomeValueName")
# Parameter 3:  value (e.g. "SomeValue")
# Parameter 4:  type (e.g. "String", "Binary", "DWord", "MultString", "ExpandString")
# Parameter 5:  debug (e.g. "false", "true")
# -----------------------------------------------------------------------------
# Parameters
param([string]$path,[string]$name,[string]$value,[string]$type,[string]$debug)

if ($debug -ne "true"){$debug = [bool]$false}else{$debug = [bool]$true}
$Script:API = new-object -comObject "MOM.ScriptAPI"
$Script:LOG_ERROR       = 1
$Script:LOG_WARNING     = 2
$Script:LOG_INFORMATION = 4
$Script:ScriptName = "SetRegistryValue.ps1"
$Script:Arguments  = "Received Arguments: `rPath='$path' `rName='$name' `rValue='$value' `rDebug='$debug'"

function Write-DebugInfo
{
    param ([string] $msg)
    if ($debug) 
    {
        $API.LogScriptEvent("$ScriptName",100,$Script:LOG_INFORMATION,"`r$Arguments`r`r$msg")
    }
}
function Write-ErrorInfo
{
    param ([string] $msg)
    $API.LogScriptEvent("$ScriptName",500,$Script:LOG_ERROR,"`r$Arguments`r`r$msg")
}

Write-DebugInfo("Script started.")

# check if registry key exists
if (Test-Path $path)
{
    Write-DebugInfo("Path $path found in registry.") 
}
else
{
    Write-DebugInfo("Path $path doesn't exist. Creating registry keys...")
    New-Item -Path $path -force | Out-Null
}
New-ItemProperty -Path $path -name $name -value $value -Type $type -force | Out-Null
Write-DebugInfo("Registry value $value of type $type in $path $name created/updated.")
Write-Host "Registry value $value of type $type in $path $name created/updated."
Write-DebugInfo("Script ended.")

This script will create/set a registry value of a specific type. Disclaimer: Use this at your own risk. Always use a test environment! Writing/Overwriting registry values can harm your system. You really need to know what you are doing! There’s also no error handling in this script and it’s far from production quality! Works on my machine!

2. Generic Module Type to Set a Registry Value

Now let’s start up the authoring console and create a new empty management pack using the “File->New…” menu command:

In my example the MP ID is “code4ward.Sample”

The friendly name is “code4ward Sample”

Of course you can use your own IDs and names.

Now let’s navigate to the “Type Library” space and select “Probe Actions” in the “Module Types”:

Right-click in the Probe Actions pane and select “New->Composite Probe Action…” command.

Set the ID to “code4ward.Sample.Action.SetRegistryValue”. Click OK; the property pages for this new module type will open.

Name it “Set Registry Value”

Here we are going to create a very generic module of our own, capable of settings registry values on a target machine.

Change to the “Member Modules” tab and click on “Add…”.

Look for: “PowerShellProbe”, select the “Microsoft.Windows.PowerShellProbe” and specify a Module ID – in my case the ID is “Script”. Click OK.

Some of the modules are documented on Technet already (more to come soon): http://technet.microsoft.com/en-us/library/dd789057.aspx

Now the configuration window for the PowerShellProbe opens up. Click on “Edit…” and if not already configured, choose a text editor (notepad.exe) to open the configuration in an external editor.

Now we need to fill in the configuration of this PowerShellModule:

Type a script name “SetRegistryValue.ps1” in the ScriptName tags, copy the script above into the ScriptBody tag, be sure to wrap a “” tag around it (without the quotes), set the TimeoutSeconds to 300 or something.

Note that there’s no Parameters section in the configuration XML when we open it. We need to create our own. Also note that the script on top of this post allows named parameters. For each Parameter in your script create a parameter element containing the Name element which must correspond to the actual name of the parameter (this is not case-sensitive) and a value element like “$Config/SomeValue$. The name of the value element is important when we wrap another module type around it. This basically says, the value will be submitted to the module from its consumer (task or other module, etc.).

It is also very important that the Parameters element is right after the ScriptBody element (see screenshot!).

Before we continue, we also need to select “Module Output” in the “Next Module” column.

Now let’s continue to the “Configuration Schema” tab.

Just add all the parameters of the script using the the “Add…” button in the “Simple Configuration Schema” section.

Verify, that every parameter has the appropriate type selected (in our case Debug must be a boolean, all other parameters are strings (default)).

Next stop: Overridable Parameters

Use the “Add… “ button at the bottom to enable overrides for all parameters (I used the same names as the parameters to avoid confusion).

One last step before we close this beast. We need to select the radio button “This module requires input data”.

Additionally you may consider to make your module public (in the Options tab, Accessibility) if you want to allow others to consume your module (your MP needs to be sealed then).

Now we created a very generic module allowing us to set any registry values. Now let’s pretend we need to set in HKLM:\Software\code4ward the value “Environment” to some value. Let’s wrap another module type around the one we just created:

3. The Wrapper Module Type

As explained above, right-click and select “New->Composite Probe Action…” and type in an ID like “code4ward.Sample.SetRegistryEnvironment” and a name like “Set Registry Environment”.

In the “Member Modules” tab we add our previously created module and provide an ID like “Probe”. The configuration of our module looks like this:

Next to the value and debug field you can use the “Promote” menu item to automatically fill in the $Config/…$

Using this configuration, we tell our new module to consume our previously created module where the Path, Name and Type parameter is pre-set and the value and debug parameter will be set by it’s consumer (later on by the task or by providing an override).

Also be sure to select “Module Output” in the “Next Module” column.

Now we only need to provide two configuration values (all the others are pre-set). Be sure that the Debug type is Boolean.

Also create two overridable parameters, only this time we call the $Config/Value$ parameter “Environment”. This is the name presented to you by the override dialog!

In the next tab “Data Types” we also need to check “This module requires input data” again.

Click on “OK” and save your MP.

So far we are ready with our modules.

4. Now let’s put all together to create a Task

Let’s switch to the “Health Model” space and select “Tasks\Agent Tasks”. Right-click on the Agent Task panel and select “New->Custom Task”. Provide an ID like "code4ward.Sample.Task.SetEnvironment” and a display name “Set Environment”. As target we select “Microsoft.Windows.Computer” – this way we can use the task in the computers state view.

In the “Configuration” tab, click on the “Browse for a type” link and select the “code4ward.Sample.SetRegistryEnvironment” module type we created before.

After we selected the module type, we can pre-set the parameters. In our case we leave the value blank and should be specified using an override, the debug parameter is set to false by default and can be set to true for debugging using the override parameters dialog.

Here the result:

I am also thinking of posting a step-by-step guide like this one on how to set up a 2 state monitor using a powershell script with the “Recalculate Health” ability. If you’re interested in such a guide, please let me know and give me some feedback?

cheers,

Stefan

http://www.code4ward.net

I’m happy to announce a new LogSmith release with one new “killer feature”: When you click on an event, you’ll see the event parameters in the details pane.

This should speed up authoring rules where you want to check for specific event parameters.

For a complete feature list, go here: http://www.code4ward.net/main/LogSmith/Features.aspx

LogSmith is available for free (Donations are welcome and appreciated), use at your own risk, you can download it here: http://www.code4ward.net/main/LogSmith/Download.aspx