Programming Continuous Test Schedules

Our implementation is mostly using the Continuous Tests to monitor performance and availability of are RDS hosts. We have 900+ Target (Application Session Hosts) in one datacenter, 230 in our second datacenter and 110 in our third datacenter.

On the weekends, our applications routinely do maintenance on the Application Session Hosts and we have a Powershell script the disables all tests on Friday evening and re-enables them on Monday morning. As Task Scheduler has proven to be unreliable, we use a PDQ ( Deploy scheduled deployment to run these scripts. Unfortunately, this is not 100% reliable and I frequently get call late Friday night that some tests are still running.

So, you’ll understand that we are quite excited to make use of the scheduling function for Continuous Tests. If you haven’t seen this yet, it can be found in the Test configuration under the head TEST SETTINGS.

It provides you 3 options: Always on, Dally Schedule and Weekly Schedule. It also lets you select when (during the selected schedule) you want the test to run or not run, in 15 minute increments. As you can see if the picture above, we would like to test to run all week except from Friday at 8:00pm to Monday at 7:00am.

Note: The GUI to set these allows you to drag across a time period and you don’t have to individually select each time slot, but it can behave a little different from what you might expect, so check it carefully.

Of course, with the large number of tests that we have, we wanted to enable the schedules programmatically. Unfortunately, the API does not yet have the option to do so.

So, we took a look at database itself. We have configured an external SQL database, so we were able to examine where and how these were stored.

Since I am not a coder or a SQL DB admin, my first approach to looking at databases that I didn’t write is to use Access with an ODBC connector to exam the table and data in a database. Using this method, I found the Environments.ActiveTimeSlots table that has 3 values, ScheduleId, Mode and TimeSlots. It was fairly obvious what each value represented.

Note: the above picture is from my lab, where I only had 2 tests configured.

For Mode 3 (weekly schedule), the value in TimeSlots consists of 672 characters, T for Enabled and F for disabled, one for each 15 minute block in a day.

To set this for all our tests, we could have copied and pasted this in the Access database, as we had configured the data source as a live link rather than an import.

But, we wanted this to be a repeatable process that reduces the possibility of human error. So, we used a SQL statement to update the values in the table.

So, from with SQL Server Management Studio, we created the following SQL code:

Update Environments.ActiveTimeSlots
Set Mode = 3

This changed all of the tests to run on a weekly schedule.

We then ran the following code to configure the actual schedule:

Update Environments.ActiveTimeSlots

When this is applied, we get a successful implementation on 106 rows.

Of course, if you do not want the same schedule, you’ll need to use a Where statement to filter the ones that you wish to apply the change to.

Also, in order to get the value to write to the TimeSlots value, I copied it from the Access view of the database. It is just setting the T or F properly in each 15 minute period, but that can be tedious.

Hopefully, we will see an API to do this properly, but this is a quick work-around.

Update – 17 Oct 2023

In the SQL query above, I had split updating thee Mode field from the TimeSlots field. We had received an error message when I tried to do both with the same query. I consulted one of my SQL resources Thuria Abuzamel) who straightened me out.

The proper query is:

Update Environments.ActiveTimeSlots
Set Mode = 3

Leave a Reply