By Stefan Koell on Thursday, November 26, 2009 11:57:53 PM

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!

By Stefan Koell on Sunday, November 15, 2009 2:16:43 AM

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!

By Stefan Koell on Tuesday, November 10, 2009 6:04:15 PM

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

By Stefan Koell on Monday, November 09, 2009 1:46:29 PM

 

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

Read More »

By Stefan Koell on Tuesday, November 03, 2009 4:58:28 PM

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