How to Encrypt SiteRemote Server to SQL Server Connections

If you want to encrypt the connection between your SiteRemote Server and the Microsoft SQL Server hosting the database for SiteRemote, especially when using a remote Microsoft SQL Server, you can just enable forced encryption in the settings of your Microsoft SQL Server. This enables basic encryption between the two servers. To learn how you can enable encryption for your Microsoft SQL Server please refer to the documentation of the SQL Server provided by Microsoft.

The above enables encryption but does not protect from man-in-the-middle attacks on the connection. If you need this additional layer of security, configure your Microsoft SQL Server to use a certificate and make sure the machine running the SiteRemote Server trusts the certificate. Please refer to the SQL Server documentation provided by Microsoft for the SQL Server version you are using to configure this setup. Once this is done, you need to change the connection string used by SiteRemote to connect to the SQL Server. Note that this change can only be done after SiteRemote has been installed.

Open the file ..\PROVISIO\SiteRemote\Config\SiteRemoteServer.config from your SiteRemote installation folder with an editor and look for lines similar to this example:

	<Add Name="default" Encrypted="true">
		<ConnectionString>Data Source=sql.server;Initial Catalog=SiteRemoteBackEndServer;User ID=sa;Password=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</ConnectionString>

You need to add encrypt=true and trustServerCertificate=false (true would not validate the certificate) to the connection string. The above example would look like this with the additional settings added:

	<Add Name="default" Encrypted="true">
		<ConnectionString>Data Source=sql.server;encrypt=true;trustServerCertificate=false;Initial Catalog=SiteRemoteBackEndServer;User ID=sa;Password=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</ConnectionString>

Limiting the Color Mode for VNC Connections

Please note that the following text is an updated version of this older post. The update applies to SiteRemote 5.1 and above (including version 6.1, which is the current version at the time of writing this post).

SiteRemote uses the auto mode to set the colors for the VNC session. This usually provides the best experience. You may like or need to limit the color mode to 256 colors only when establishing the connection, mainly because of poor connection speed.

To switch from auto mode to 256 colors you need to edit a file on the PC you are establishing the connection from. On this PC you have installed the UVNC client for SiteRemote, it is usually located in the path C:\Program Files (x86)\PROVISIO\VncViewer\. There you can find the file options.vnc. Please open the file with an editor like Notepad. You will see that there is not much in it:


These lines need to be added to the file:


The complete file should now look like this:


Save the file under its original name. Next you need to right-click the file, choose Options -> Security and give the default Windows Users group read and write access to the file.

When you now start your next VNC session it will default to just 256 colors, therefore speeding up the view on a slow Internet connection.

Note that independent from this change you can always edit the options of a running VNC connection by clicking the Options button in the upper toolbar of the VNC window. This allows you to make one-time changes to the current connection.

Using the Expert Mode of the SiteCaster Editor

The SiteCaster Editor comes with an expert mode, that allows you to edit settings beyond their default value range. This gives you the opportunity to customize your projects to match very specific requirements. Feel free to experiment with this mode, but be aware that changing values beyond their default range is outside of the scope of our free support.

To enter the expert mode open a project to view the project page. Now click the address bar of your browser and append &expert to the URL. Make sure you place it at the very end of the URL and then press enter to open the expert mode.

Next select the element you want to customize. In our example we want to adjust the font size and the font family of the Time/Date element. To do that, click on the new advanced edit button you will see in the toolbar after entering the expert mode.

After clicking the button you will see a list of all properties of the selected element in the inspector. In the list you will find the dateFontFamily and dateFontSize properties. Use the drop-down of the dateFontFamily property to select String and type in the font family of your liking into the text field. For the dateFontSize property select Number from the dropdown and then type in the pixel value you want to choose. Click on the Save button after you are done to apply the changed values.

To give you an idea of the advanced possibilities you get from choosing the expert mode here is a view of the default options you have for the Time/Date element.

 As you can see the default element will cover the needs of most users but when using the expert mode you can change the properties to whatever you like.

SiteRemote-Controlled Alert System for SiteKiosk Windows

The kiosk management solution SiteRemote can be used to create an alert message system for kiosk systems running SiteKiosk Windows. An alert message will overlay the default SiteKiosk user inferface informing users of special events. Note that the solution described in this blog post is intended as a sort of emergency system. If you just want to show changing information you should consider using SiteCaster.

Two files are needed on the SiteKiosk terminal. One is a JavaScript file (named alertswitch.js in this example) the second is an HTML file (named alert.html in this example). Both should be placed in a folder called alert that should be placed in the HTML folder of the SiteKiosk installation path.

Let's start with the alertswitch.js JavaScript file. The code of the file is as follows:

//Periodic event to check alert conditions every 25 seconds
//The lower this value the harder to use the local SiteKiosk escape menu to close SiteKiosk
SiteKiosk.Scheduler.AddPeriodicEvent(25000, CheckAlertValue);

//Shell object used to read the registry
var WshShell = new ActiveXObject("WScript.Shell");

//Global variable for the event id of the periodic alert text check
var PeriodicEventID = 0;

//Alert dialog properties
var gk_Emergency = SiteKiosk.SiteKioskUI.CreateHTMLDialog();
//Path to the html file used for the alert
gk_Emergency.URL = "file://" + SiteKiosk.SiteKioskDirectory + "Html\\Alert\\Alert.html";
gk_Emergency.TopMostWindow = true;
gk_Emergency.Closable = false;
gk_Emergency.Title = false;
gk_Emergency.Border = false;
gk_Emergency.Scrollbars = false;
gk_Emergency.Sysmenu = false;
gk_Emergency.CloseOnInput = false;
gk_Emergency.OnClose = onClose;

function CheckAlertValue(){
		//Check registry value !NOTE! The following registry path is for 64-Bit systems!
		if (WshShell.RegRead("HKLM\\SOFTWARE\\Wow6432Node\\PROVISIO\\SiteKiosk\\AlertValue") !== ""){
			//Resets the screensaver idle timeout to make sure the screensaver is not interfering with the alert
			//Show the alert
			//Force hiding of the task bar during the alert (Note: Not required when running SiteKiosk in full screen mode)
			SiteKiosk.SiteSkin.TaskbarVisible = false;
			if (PeriodicEventID !== 0)
			//Remove the periodic event that checks for alert text changes	
			//Show the taskbar again (Note: Not required when running SiteKiosk in full screen mode)
			SiteKiosk.SiteSkin.TaskbarVisible = true;
			//Close the alert
		//No matching registry value, do nothing

//Return the registry value to the alert dialog on request
function GetRegistryValue(){
    return WshShell.RegRead("HKLM\\SOFTWARE\\Wow6432Node\\PROVISIO\\SiteKiosk\\AlertValue");

//Allow the alert to write the event id of the periodic event that checks for alert text changes
function SetPeriodicEventID(evtid){
    PeriodicEventID = evtid;

function onClose(){
	if (PeriodicEventID !== 0)
	//Remove the periodic event that checks for alert text changes because dialog has been closed from outside of the script

The file must be added to SiteKiosk as an external script file. This can be done in the configuration of SiteKiosk under Start Page & Browser -> Advanced. The file uses the AddPeriodicEvent method of the SiteKiosk Object Model to periodically check a registry value (in our example HKLM\\SOFTWARE\\Wow6432Node\\PROVISIO\\SiteKiosk\\AlertValue). The registry value is either an empty string or contains the alert text that should be displayed. If the check does not return an empty string, the ShowDialog method is used to show the dialog defined with the CreateHTMLDialog method. One of the properties of the dialog is the path to the alert.html file explained below in this document. If the alert is shown the taskbar of SiteKiosk is switched off (only required if no full screen mode is used) using the TaskbarVisible property. Additionally the SiteKiosk screensaver will be prevented during the display of the alert to minimize any possible interference with the alert message, which is why the Reactivate method is used. Once an empty string is detected in the registry the alert is switched off by means of the CloseDialog method.

The external script also contains two methods to provide the HTML file that displays the actual alert with the alert message (GetRegisryValue method) and to receive the event id of the periodic event used in the HTML file to check for changes in the alert text. The id is used to stop the periodic event once the alert message is no longer displayed with the help of the RemoveEvent method.

The alert.html HTML file that accompanies the external script is used to display the alert message. You might change the design of that page to whatever you like. The code of the HTML file is as follows:

<!DOCTYPE html>
<meta charset="utf-8">
	html { 
		background: red no-repeat center fixed; 
		background-size: cover;
	body { 
		font-family: arial;
		font-size: 100px;
		color: white; 
	div {
		margin-top: 15%;
		padding: 20px;
	<body style="margin:0px;"> 
		<div id="Alert-Text">
	<script type="text/JScript">
		//Initialize the SiteKiosk Object Model
		//Get the alert text from the external script
		function GetAlertValue(){
			document.getElementById("Alert-Text").innerHTML = SiteKiosk.ScriptDispatch.GetRegistryValue();
		//Check the alert text every 5 seconds for changes
		var evtid = SiteKiosk.Scheduler.AddPeriodicEvent(5000, GetAlertValue);
		//Write event id to external script to remove event when closing the alert

After the initialization of the SiteKiosk Object Model the ScriptDispatch object is used to retrieve the alert message from the external script. The AddPeriodicEvent method is used to periodically request the alert message to quickly react to changes. The id for that event is passed to the external script so that the event can be canelled once the alert is closed.

Note that the times for the periodic events in the script can be changed to your liking and the requirements of your environment.

With the two files required on the SiteKiosk terminal in place we can now focus on the SiteRemote part. Obviously the SiteKiosk terminal needs to be registered with a SiteRemote server. Within your SiteRemote team go to the SiteKiosk tab and select Jobs. Scroll all the way down and select New template. For the alert system to work we need at least two templates. One that switches the alert on and one to switch it off. The template that switches the alert on includes the string for the alert message. In case you have different predefined alert messages that you want to display with the alert system based on different situations, you can create different templates for each of the messages.

The create an ON template provide a job name, select SiteKiosk Windows as client type and Execute Script as action type. Click Add next to the selected action type and paste the following script into the script field. Make sure that you do not select the option Script requires SiteKiosk Object:

//ON !NOTE! The following registry path is for 64-Bit systems!
var gk_WshShell = new ActiveXObject("WScript.Shell");
gk_WshShell.RegWrite("HKLM\\SOFTWARE\\Wow6432Node\\PROVISIO\\SiteKiosk\\AlertValue", "Alert Text", "REG_SZ");

This will write the string Alert Text to the registry of a SiteKiosk terminal the job will be assigned to. Change the string to whatever you like and make as many different ON templates as you require. Note that you can also change the text each time you assign the job template to a machine.

The OFF template simply writes an empty string to the terminal's registry:

//OFF !NOTE! The following registry path is for 64-Bit systems!
var gk_WshShell = new ActiveXObject("WScript.Shell");
gk_WshShell.RegWrite("HKLM\\SOFTWARE\\Wow6432Node\\PROVISIO\\SiteKiosk\\AlertValue", "", "REG_SZ");

Each time you want to activate or deactivate an alert on one machine or a number of machines click one of the templates and assign it. If you assign the ON template from this example to a machine that runs the required files described above you will get an alert like this:

Note that for the alert message to be displayed, SiteKiosk must be running, which is the normal state on a SiteKiosk kiosk terminal.

Using VNC Repeater Connection with SiteRemote Server Behind NAT Gateway

If you are using your SiteRemote Server behind a NAT gateway and you want to use the VNC Repeater Connection, you need to make a change to the Siteremoteserver.config file. Please note that this is only required when using the repeater connection, which uses the SiteRemote Server as a repeater, not when using the direct connection.

Open the file ..\PROVISIO\SiteRemote\Config\SiteRemoteServer.config with an editor like Notepad. And look for the line

<VNCRepeater.config Enabled="true" ViewerPort="5901" ServerPort="5500" MaxSessionCount="42" />

Now add the HostName parameter to that line that specifies the host name of the NAT gateway that will forward the repeater request to your SiteRemote Server. Please make sure that required ports are open and forwarded correctly.

The line should look like this, of course with your host name instead of

<VNCRepeater.config HostName="" Enabled="true" ViewerPort="5901" ServerPort="5500" MaxSessionCount="42" />

You are now able to use a VNC repeater connection with your SiteRemote Server as the repeater behind a NAT gateway.

The above applies to SiteRemote Server 6.1 or higher.

Using the SiteKiosk Object Model in SiteCaster

The PROVISIO Developer Blog has many examples of how to use the SiteKiosk Object Model in the browsers of SiteKiosk Windows and SiteKiosk Android or as an external script in SiteKiosk Windows. This time we will look at a short example that shows you how to use the Object Model in SiteCaster as well.

Because SiteCaster is Chrome-based, it uses the new SiteKiosk Object Model for Chrome. This Object Model is still in the making, the most current state of the preliminary documentation can be obtained through our support department. Interested developers can just send us a short email.

The example code is for SiteKiosk Windows and will show you how you can start an external application from a SiteCaster element.

The first step is to create an html page that will open an application by using the SiteKiosk Object Model. The code for the simple test web page looks like this:

<!DOCTYPE html>
    //method to initialize the SK Object Model for SiteKiosk Windows (Chrome) and SiteKiosk Android
    (new Function(_siteKiosk.getSiteKioskObjectModelCode()))();
    <body style="margin:0px;text-align:center;background-color:#FFD932;">
        <input id="id_test" type="button" value="Test" style="margin-top:50px;" />
    <script type="text/javascript">
        siteKiosk.ready(function (){
             document.getElementById("id_test").onclick = function () {dotest();};
            function dotest(){
                //will only work in SiteKiosk Windows and open the specified application"C:\\Program Files (x86)\\Notepad++\\notepad++.exe", false); 

You need to initialize the SiteKiosk Object Model by running _siteKiosk.getSiteKioskObjectModelCode(). The method,checkifalreadyrunning) will start the specified application. The first parameter is a string containing the path (and optional start parameters) to the local application on the machine SiteCaster is running on. The second parameter is a boolean value that specifies whether SiteKiosk should check if the application is alreay running or start additional instances. The page can either be stored locally on the machine where SiteCaster is running or on a web server. Either way, you need to make sure that the URL or path of the file has been added in the SiteCaster configuration of SiteKiosk as an URL with script permission.

The second step is to add the page to SiteCaster. Go to your SiteCaster team and either edit an existing project or create a new one. In this example I use the Start Screen template and add a new Webpage element to the left of the existing center elements.

Step three is publishing the project to the assigned machines where you can then push a button to start a local Windows application from SiteCaster.

Note that depending on the nature of the started application you might want to consider making additional configuration and/or script changes to handle closing the application or allowing/blocking certain dialogs of the application.

Using the Blackboard Information Page on a SiteRemote Server

NOTE: This only applies to customers running their own SiteRemote Server (5.2 and above).

The Blackboard is used by the SiteRemote Server and the SiteKiosk Windows and SiteKiosk Android clients to exchange some internal information. There have been two Developer Blog posts (SiteKiosk Windows, SiteKiosk Android) that have shown how this information can be used on a client with the help of the SiteKiosk Object Model. This post will show how to view all available Blackboard information of a single client machine by adding a page to the teams of a SiteRemote Server. This also enables you to easily search the Blackboard information.

Please be aware that the Blackboard information is limited in its use for purposes other than the internal processes of the SiteRemote server and client communication, under specific project circumstances the option to use it might still be very helpful.

To add the Blackboard page to teams on your SiteRemote Server version 6.1 or higher, go to the Settings page of the SiteRemote Server Administration and check the option Show Blackboard information page per machine and Blackboard machine list filter settings on Team settings page. Save the change. Note that in SiteRemote Server version 6.1 or higher, this will also provide you with the option to create your own machine list blackboard filters. Go to the Administration -> Settings page in a SiteRemote team and look for the Machine List Settings. There you can create machine list filters that search through the blackboard entries of machines.

To add the Blackboard page to teams on your SiteRemote Server version 5.2 to 6.0, you need to edit the file ..\PROVISIO\SiteRemote\Web\Web.sitemap. Open it with an editor and look for these lines:

<siteMapNode url="terminal/logs/view.aspx" title="$(String:683)" accesstype="LogFileTab" displayTreeView="true">
	<siteMapNode url="terminal/logs/createexport.aspx" displayTreeView="true"></siteMapNode>

Add this new line directly after:

<siteMapNode url="terminal/blackboard/blackboard.aspx" title="Blackboard" accesstype="LogFileTab" displayTreeView="true"/>

Afterwards you should get this result:

<siteMapNode url="terminal/logs/view.aspx" title="$(String:683)" accesstype="LogFileTab" displayTreeView="true">
	<siteMapNode url="terminal/logs/createexport.aspx" displayTreeView="true"></siteMapNode>
<siteMapNode url="terminal/blackboard/blackboard.aspx" title="Blackboard" accesstype="LogFileTab" displayTreeView="true"/>

If you now login to a team on your SiteRemote Server and select a machine from the treeview on the left, you will have a new Blackboard tab next to the Logfiles tab of that machine.

The page can slightly differ based on the available Blackboard information of that specific machine.

You can now also use the SiteRemote search feature to search the value fields of the Blackboard. To search through the Blackboard use the bs macro. Let's look at an example, the Blackboard contains the current SiteKiosk configuration of a machine in the key CtS.SiteRemote.Config.Files/d/SiteKiosk. If you now want to find all machines that use the URL as the start page, you would simply search vor and the result lists all machines with that URL in the configuration.

Distributing the SiteKiosk Windows Start Screen with SiteRemote

The SiteKiosk Windows Start Screen is a powerful and easy to use tool to create a customized kiosk terminal experience. If you want to use the same Start Screen setup, either newly created or changed, on more than one kiosk system, you can distribute the required files using different methods. In case your environment only includes a handful of PCs at the same location you may just use a USB stick, otherwise the more comfortable method is to use SiteRemote.

For our test scenario we create a very simple Start Screen using Template 3, that only includes a monochrome background and a text. Note that the complexity of the Start Screen you create does not alter the described scenario in any way. This is what our starting design will look like:

Once you are done creating or changing your Start Screen you need to save it by clicking on the corresponding icon in the Start Screen Editor. Once this is done you are presented with a dialog that tells you where all the files associated with the Start Screen are located. It will be the same location on all your SiteKiosk Windows installations (C:\Users\Public\SiteKiosk\content):

You will get this information dialog whenever you make any changes. This is a reminder that you now may need to distribute the changed files to all your PCs. You can now copy the content folder onto a USB stick and then copy the folder to the exact same location on all your machines, overwriting the previous version or use SiteRemote to achieve this. How to use SiteRemote for this purpose is what we want to look at in a little more detail.

First we create a new simple Start Screen design that will look different than the original design to symbolize the changes:

Again the changes need to be saved when leaving the Start Screen Editor. Once this has been successfully done, we open the Windows Explorer and browser to the content folder at C:\Users\Public\SiteKiosk. If you right click the content folder you can select Send to and then choose Compressed (zipped) folder. This results in a file at this very location:

Now we need a small tool that will unzip the folder once we have distributed it through SiteRemote. You can for example use the command line version of 7-Zip. The application is called 7za.exe and is available here in the 7-Zip Extra package.

Next just login to your SiteRemote team, go to the SiteKiosk tab and select Jobs from the submenu. Create a new job (you may save it as a job template if you like):

Set Job Name and Description to your liking and select SiteKiosk Windows as the Client Type. Now you need to add three job steps. The first one will be a File Upload that will place the 7za.exe file in the C:\Users\Public\ folder. Make sure to use the slash at the end of the file path. Also choose Overwrite to make sure any existing version at that location is overwritten:

The second step will again be a File Upload and upload the file with the complete Start Screen content. Use the same settings as with the first step:

The third and last step will be of the Run Executable type. If will use the following command line to run 7za.exe and unzip the content of the archive to its final destination:

"C:\Users\Public\7za.exe" x "C:\Users\Public\" -aoa -oC:\Users\Public\SiteKiosk

Leave the other options as they are, especially leave Invisible execution with administrative rights selected:

Finally assign the jobs to the desired machines and wait for it to complete. Note that the changes will only come into play once the Start Screen is refreshed, to speed things up you can send another SiteRemote job that restarts SiteKiosk.

Accessing 64-Bit System Folders and Registry Paths from the SiteRemote Job System

The SiteRemote component on the Windows client side is a 32-bit application. This means that the SiteRemote jobs you are running on the client are executed within a 32-bit context. This is relevant when your are using a 64-bit system and you for example want to access the SOFTWARE folder in the Windows registry. By default you will then target the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node path instead of HKEY_LOCAL_MACHINE\SOFTWARE. The same applies to applications from the System32 folder, by default a 32-bit application will be redirected to C:\Windows\SysWOW64 instead of using C:\Windows\System32.

What to do, when you explicitly need to access the 64-bit part of the registry or start a 64-bit system application? Microsoft offers solutions that you can use in your SiteRemote jobs to mitigate the behaviour described above.

First let's look at the Windows registry. To for example set registry values for a 64-bit application by using a SiteRemote job you can create a job with the action type Run Ececutable and use the following command line:

reg import C:\Windows\Temp\test.reg /reg:64

This calls the reg.exe application with the parameter import that specifies the path to .reg file that includes the registry data you want to write to the registry (for this example we assume that there is already a test.reg file in c:\Windows\Temp). After that you use the /reg:64 switch to specify that you want to import the data from the .reg file to the 64-bit part of the registry. For the purpose of this test the content of the .reg file will look like this:

Windows Registry Editor Version 5.00

"TEST"="Test Value"

A SiteRemote job step that includes the above will look like this:

A successful execution will show this result:

When not applying what has been described above the test value would have been written to the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node path.

Next we will look at starting a 64-bit application. For this demonstration we will use the 64-bit version of notepad.exe located in C:\Windows\System32 on a 64-bit Windows system. In order to be able to start this application from the 32-bit environment of the SiteRemote client we need to use a batch file that makes use of the Sysnative folder redirection of Windows. Using Sysnative as the folder name will redirect any request, even those from a 32-bit application, to the native system folder of 64-bit Windows system it is used on. Our batch will look like this:

start %windir%\Sysnative\notepad.exe

For this demonstration we will place it in C:\Windows\Temp as test.bat. Of course you could also create another SiteRemote job step that uploads the file to the client. Next we create the job step that executes the batch file. The command line looks like this:

c:\windows\syswow64\cmd.exe /c "start c:\windows\temp\test.bat"

For the path to the cmd.exe we could actually also use c:\windows\system32\cmd.exe. This will automatically be translated to the SysWOW64 folder on a 64-bit system.

Our job will look like this:

For the purpose of this demonstration we will choose the option Visible execution with user rights to make notepad.exe show up. Executing the job on the target system will give us this result:

Note that the task manager shows that this is actually the 64-bit version of notepad.exe (visible from the missing 32 bit appendix).

Using the SiteRemote Database from other Applications

In case you are using your own SiteRemote Server you are able to access the valuable data of the SiteRemote database from other applications. The SiteRemote database includes a great number of information that is useful for other purposes as well, such as address information, software and hardware information etc.

The SiteRemote database utilizes the common Microsoft SQL engine, so start with having a look at the SiteRemote database tables by using the Microsoft SQL Management Studio and connect to your SiteRemote Server. You will see that most of the tables are using pretty obvious names.

You can use the default coding methods of your preferred programming language to access the database, either locally or remotely. Make sure that you have a database user with appropriate user rights and that you configured the SQL database access according to the Microsoft SQL Server documentation.

A simple C# code for such an SQL query, that finds all terminals that are in the time zone with idx 72 (GMT+01:00, you will find the time zones in the table tblTimeZone) and writes them into a text file, can look like this:

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace SRdbAccess
    class Program
        static void Main(string[] args)
            //Required information to connect to the database.
            SqlConnection obj_sqlconnection = new SqlConnection("Server=;Database=SiteRemoteBackEndServer;User Id=TheUserName;Password=TheUserPassword;");
            //Query that retrieves all terminals that are in a specific time zone.
            string str_sqlquery = "SELECT * FROM tblTerminal WHERE TimeZone_Idx = @Timezone";
            //Build the SQL command.
            SqlCommand obj_sqlcommand = new SqlCommand(str_sqlquery, obj_sqlconnection);
            //Look for terminals from time zone with idx 72, which is GMT+01:00. You will find the time zones in the table tblTimeZone.
            obj_sqlcommand.Parameters.AddWithValue("@Timezone", 72);

            //Use the data reader to show the display name of all terminals that are from the same time zone and write them to a file.
		    SqlDataReader obj_sqldatareader = obj_sqlcommand.ExecuteReader();
            using (System.IO.StreamWriter obj_filetowriteto = new System.IO.StreamWriter(@"C:\Users\Public\Documents\SiteRemoteSQLQueryResult.txt", true))
                while (obj_sqldatareader.Read())

            //Close the data reader after the read process.

            //Close the connection to the database.

The following screenshot shows you an example result of the above query. The search returns the display name of the three terminals that are in the time zone with idx 72: