The Remote Desktop Canary Version 3 release represented a point of major overhaul in its evolution. Why? Here are a few of the key capabilities that came along and continue to make it such a powerful synthetic monitoring tool.
Remote Desktop Canary Functions as a Windows Service.
One of the major limitations of previous versions of Remote Desktop Canary was that it ran in an interactive user session while doing its testing. This meant that if the server running Remote Desktop Canary rebooted, you’d have to depend on the Remote Desktop Canary Kickstarter, running on a different VM, to relaunch the user session used for testing on that server.
Fortunately, after a lot of R&D, we found a way for a local Windows service to orchestrate the creation and teardown of a user testing session to run Remote Desktop Canary’s tests. By doing so, we’ve completely eliminated the need for the Remote Desktop Canary Kickstarter applet. More importantly, the service itself will resume testing operations after a system restart for any reason.
*This also means that Remote Desktop Canary can now test RDS/WVD environments that have login banners enabled, and bypass them with synthetic input, without needing the Kickstarter tool enabled or a user session running unlocked.*
You Can Schedule Different Workflow Tests At Different Times During the Day.
With the creation of the new Remote Desktop Canary Service as mentioned above, Remote Desktop Canary v3 can now schedule specific workflow tests at different times. All you need to do is build the testing routines you need and save them to separate workflow files. Then, you can schedule each workflow file to run during specific times of the day. Remote Desktop Canary will do the rest for you.
For example, you may want to do a sanity check early every morning and have Remote Desktop Canary test all of your RDS session hosts or WVD hosts after your nightly reboot. Why exactly? To make sure they are responding properly and that logins can proceed successfully all the way to a desktop, with no hiccups related to loading group policies or FSLogix / UPDs. Then, you may want Canary to start a recurring test the rest of the day for each of your RDS collections through the connection broker. Finally, since you schedule nightly reboots of your hosts (or shut your WVD hosts down at 1am to save money), you may want to have a period of time each evening when Remote Desktop Canary is not doing any testing at all.
Remote Desktop Canary Automatically Retrieves Relevant Event Log Information From Session Hosts Having Problems.
And it can even include that information in its automated alert emails. Here’s how this works . . .
In previous versions of Remote Desktop Canary, you would receive basic alerts if a connection broker or session host was not responding or it was taking to long to log in and reach a desktop. In version 3 of Remote Desktop Canary, you can configure *internal* workflows (e.g. tests running inside your network) to automatically gather errors and warning events from many different Windows event logs that may be diagnostically relevant to the problem at hand.
For instance, if FSLogix is taking a long time to load a user’s profile, if group policies are causing login delays, etc, Remote Desktop Canary will automatically include event log information that was logged around the time of the issue inside the alert email it sends to you. This will give you immediate context as to the true problem, and should shorten the time it takes you to fix the issue.
What Next?
That’s three (at least) good reasons to look to Remote Desktop Canary to make your life easier and help monitor RDS infrastructure health.
Find out more about the very latest capabilities and pricing for Remote Desktop Canary.
Updated: November 2022.
Leave a Reply