Table of Contents

Printers and/or scanners are not connecting

The image on the left shows ameliaRES connected to the ATB/BTP printer normally. The image on the right shows ameliaRES running but not connected to the ATB/BTP printers at all. They are still in "Unknown" status in the CUTE Terminal Window and the "Devices" status text is not visible in the lower-right status area of the ameliaRES window.

In this scenario there are a couple of things to check:

Ensure you selected the correct airport when you started ameliaRES

When ameliaRES first starts, you should be presented with a "User Preferences" screen where you pick your nearest airport. It is critical that you choose the CUTE airport you are working out of from that drop-down list. If you do not pick the correct airport then the printers will not be mapped to your ameliaRES instance.

Ensure the workstation names are correct

Open the "Session" tab in the amelia CUTE Terminal window and check the value of the "Pre-Hash Value". Note the name before the first colon. In the example above (left picture) you can see it is "violet".

Open the "Config" tab in the amelia CUTE Terminal window. Exapand the "Config" node and check the value of the "WSID" entry. In the example above (right picture) you can see it is "arinctest".

If these two values do not match then there is a configuration error on the CUTE workstation. You need to contact the airport technical support personnel and tell them the CUTE workstation is mis-configured. Provide them the following information:

These two values need to both be the local workstation name. The most common reason these values differ is because the session is being accessed through some remoting software such as Citrix or Microsoft Remote Desktop. To handle this situation the command line that is used to launch the amelia CUTE Terminal exe must include the "-l" command line option. For example:

C:\Program Files\InteliSys\TerminalClient\TerminalCuteHost.exe -l -f

Make sure the workstation has time to connect to the printers

In some cases, we have noticed that if the user logs into amelia too quickly after logging into the CUTE workstation, the workstation does not seem to have time to connect to the printers. Thus when ameliaRES checks for the printers at startup time it does not find them and therefore treats the session as having no CUTE printers.

One solution is that after you login to the CUTE workstation with your airport-provided credentials, wait a few moments before you login to ameliaRES. We have found that waiting between 15 and 60 seconds seems to work best.

Many airports insert a pause into the startup scripts to force this wait. Again, values between 15 and 60 seconds seem to work best.

To re-iterate, this is not an ameliaRES caused problem. It is because the mapping of the printers to the workstation in the airport system seems to take longer at some airports. Not all airports suffer from this issue. It is something to try if you see consistent issues with printers not being mapped at a particular airport or even at a particular workstation

One (or more) workstations do not map printers but other workstations at the same airport work just fine

In cases where certain workstations seem to have problems with mapping printers but other workstations are working just fine, you will need to contact the airport technical support. ameliaRES does not react differently to different workstations, even if they have different operating systems. ameliaRES is delivered over a thin-client application so there is actually very little software installed on the workstation. When only a few workstations are experiencing problems it is invariably a configuration issue on the local workstation and airport staff must address that.

Check for Host Connectivity

If upon starting the Terminal Emulator a dialog is displayed indicating a connection to the host could not be made (example here):

this indicates there is a problem establishing communications with the host server. This can indicate one of two problems:

Network Connection Failure

There is a network problem between the workstation and the host server. This could be a network router failure, a network port or network address range is blocked, an Internet outage or any other number of problems. To determine if this is the case, open a command prompt and use the Telnet utility to attempt to connect to the host. You first need to determine the host address and port you are connecting to. This can be found in the SystemConfig.cfg file under the "Communications" / "Addresses" entry or under the "Hosts" tab on the Terminal Emulator Status window:

In either case the address will look like the following (the actual address and port may vary):

net.tcp://199.59.133.130:8731/ameliaCuteCommSvc/

Open a Command Prompt and use Telnet to try to connect to the specified host:

If an error is returned (like the following screenshot) it indicates the host is unreachable due to a network problem:

If, instead, a connection is established (the exact behaviour will depend on the version of Telnet you are running), this indicates the host was reachable. This can indicate another cause for the host connection failure.

SSL Certificate Failure

There can sometimes be an issue with the SSL certificates used to protect the communications between the workstation and the host. Typically this is caused by not having the root certificates installed on the workstation. One way to verify this is to open the web portal in a web browser on the local worstation, URL - https://portal.intelisys.ca. It should open with no errors, especially security errors. Once loaded, use the browser to view the site's SSL certificate. This should open a dialog like the following:

Note the 3 certificates in the Certification Path. Also, notice the text under the Certificate Status that indicates "The Certificate is OK". Any other values indicate a certificate is invalid. If the certificate is invalid, please contact airport personnel for instructions on how to update it. Normally this is done as part of the workstation initial setup.

However, even if this shows all certificates are valid when using the browser, there could still be an issue (the browsers seem to trust certain root certificates that are not always installed in the machine's certificate store). For this reason, a utility can be used to verify if the certificates are all valid and installed appropriately on the workstation.

The CertChainVerify utility can be downloaded from here: CertChainVerify.zip

Once extracted, run the exe. You will be prompted to enter the URL of a website containing the certificate to be verified:

In this example, the address "https://portal.intelisys.ca" has been entered. This site uses the same certificate that the InteliSys Terminal Emulator uses.

Upon pressing enter, the certificate will be retrieved and then verified on the local workstation:

As can be seen in this example, the certificate chain shows the three certificates seen in the browser test. We can also see the status of each certificate along with if each certificate is installed on the local machine (see the highlighted lines). All certificates must be valid. The top level cert (intelisys.ca) does not need to be installed locally, but the root and all intermediate certs must be installed in the local store.

If any certificate is marked as invalid and/or the last certificate is marked as not installed in the proper local store.

You can download the required certificates from here:

Once extracted, you can double click on the p7b file. This will open a utility. You should see the three certificates in the file.

You need to install the root and all intermediate certificates. Double click on the "DigiCert Global Root CA" certificate and it should open the Certificate details. Click the "Install Certificate..." button. In the Certificate Import Wizard be sure to select "Local Machine" as the Store Location.

When prompted, be sure to select the "Place all certificates in the following store" option. Then using the Browse button, select the "Trusted Root Certification Authorities" store.

Click Finish to import the certificate.

Repeat this for all intermediate certificates - "RapidSSL RSA CA 2018" in this case.

You can re-run the CertChainVerify utility and it should show the root cert is now installed locally.

Retrieving Log Files

In many cases InteliSys or airport personnel will ask you to retrieve log files from the workstation to help diagnose the issue. Depending on the airport environment this will need to be done by either airport technical staff or airline technical staff.

Enable Session Logging

By default logging is disabled. This is because log files can become quite large over time.

To enable logging for the local workstation:

In Windows Explorer, navigate to the folder where the SystemConfig.cfg file is located. The file location is specific to the environment. Some environments use a network share for each airline, others will have a copy on each workstation.
Edit the SystemConfig.cfg file in a text editor (such as Notepad). Find the section that looks like the following (there may be slight variations):
```
        "TraceLoggers": {
            "FileWriter": {
                "TraceLogLevel": "Off",
                "FileName": "..\\logs\\##WSID##\\Log_##WSID##.log",
                "MaximumFileSize": "5000000",
                "SuppressUnravel": "False"
            },
            "EndpointWriter": {
                "TraceLogLevel": "Off"
            }
        },
```
1. Under "FileWriter", modify the value next to "TraceLogLevel" to be "Debug" (case sensitive). Only change the one under the "FileWriter" entry. DO NOT change the one under "EndpointWriter"
2. Under "FileWriter", modify the value next to "SuppressUnravel" to "True" (case sensitive).
3. Under "FileWriter", ensure the value next to "MaximumFileSize" is at least 5000000
4. Make note of the value next to "FileName". This indicates the path where the log file will be written (values such as ##WSID## and ##USER## will be replaced with the workstation name and the user name respectively in the file path).
5. Save the File
Shut down any running instances of the TerminalEmulator, ameliaRES and Citrix (or just restart your computer)
Start your CUTE workstation as you normally would and proceed as far as you can until you get to the error situation.
Shut down the ameliaRES and the TerminalEmulator.
Navigate to the file path specified above in the "FileName" value
There should be a log file there. You can view it yourself in a text editor (such as Notepad).
Send this file to support personnel to aid in debugging.
Once debugging is complete you may want to reset the values in SystemConfig.cfg back to the following to again prevent large log files being kept around:
1. TraceLogLevel - set to "Off" (case sensitive)
2. SuppressUnravel - set to "False" (case sensitive)

Generating a "WCF Trace" Log File

In some cases, InteliSys support personnel may request a WCF Trace be performed to generate a trace log file. This gives very verbose details on the underlying operating system's communication protocol between the workstation and the server. To generate this file do the following:

Make sure all instances of the TerminalEmulator application are closed
Open the folder where TerminalEmulator.exe is installed
Find and edit the file "TerminalEmulator.exe.config".
1. Near the bottom you will see a "<system.diagnostics> / <trace>" entry. In that section, under "<sources> / <source>" you will see a "switchValue" attribute. By default it should be "Off" (case sensitive). Modify this value to instead contain (Case Sensitive):
```
Information, ActivityTracing
```
2. This will result in a complete section that looks like the following:
```
<system.diagnostics>
  <trace autoflush="true">
    <listeners>
    </listeners>
  </trace>
  <sources>
    <source name="System.ServiceModel"
            switchValue="Information, ActivityTracing"
            propagateActivity="true">
      <listeners>
        <add name="sdt"
             type="System.Diagnostics.XmlWriterTraceListener"
             initializeData= "WcfDetailTrace.svclog" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>
```
  NOTE: The <system.diagnostics> block may be present in the file but marked to be ignored. Check for the presence of "" around the block, such as the following:
```

```
  If present they need to be removed or the section will be ignored. They can be replaced after the log file is generated if you wish.
Save and close the file.
Restart TerminalEmulator as you would normally
Once you get the connection error, close TerminalEmulator.
1. In the same folder as TerminalEmulator you should find a file named "WcfDetailTrace.svclog".
2. Generally you should send this file to InteliSys Personnel, but you can also review it yourself using the Microsoft SvcTraceViewer app ("C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\SvcTraceViewer.exe" - alternatively see HERE for instructions on where to obtain it)
IMPORTANT Be sure to revert the "switchValue" setting to "Off" when you are done debugging. The service trace logs can be quite large and can also affect performance.

More details on WCF trace logging can be found HERE.

Retrieving Environment Variables

Many CUTE system providers use environment variables to control communications with the peripherals. As such, it can be very helpful to InteliSys technical personnel to see what environment variables are defined and what their values are on the workstation that is having problems. One way to get all these environment variables and their values in a way that can be sent to InteliSys is to run the following command in a cmd.exe window:

set > C:\EnvVars.txt

It is important that this command be run in the same configuration / environment / permissions as is used to start TerminalEmulator. For example, if the user session that runs TerminalEmulator has reduced permissions or different device configurations, be sure to run this command in that user session.

Diagnostics Screen

In some cases it can be useful to capture scanner data in raw format. This can be done using the CUTE Diagnostics Screen, accessible via the Utilities menu, then CUTE Tools. This will open the CUTE Tools and Settings interface.

Click on the Tools button and then Diagnostics to open the CUTE Diagnostics interface. Click on the Scanners tab. Then scan an item and it should populate the information.

At this point any scanned data will appear in this screen. The screenshot shows an example of a BTP scan event.

The CUTE Printing Environment Initialization Has Failed

When you login to the workstation and start the CUTE environment, the TerminalEmulator window shows that all devices are connected:

Then, after you select your airport after logging into ameliaRES, you see a dialog box such as the following with the error message "The CUTE printing environment initialization has failed":

This indicates that communications with the devices failed.

The green "Online" status in the TerminalEmulator window indicates that we were able to open a connect to the Device. The green "Online" status does not indicate any communications were sent to the device.

The first communications attempt is made after you pick your airport in ameliaRES. If no response is received back from the peripheral (printer) at this time, then the "CUTE Printing Environment Initialization" error dialog is displayed.

This can be caused by different things depending on the airport's CUTE printing environment provider:

ARINC, SITA, Ultra, Mercator

These are managed CUTE environments and all communications with the peripherals goes through special software from these vendors. In this case, a reboot of the workstation will generally resolve the issue. If the issue persists you will need to contact airport technical support for assistance.

AirIT, iCUTE, DirectConnect, Airline-Owned Devices

In these environments ameliaRES communicates with the peripherals directly using COM ports.

Generally this error occurs in these environments because Windows will occasionally swap the COM port settings.

Open Window Device Manager and expand the "Ports (COM & LPT)" section:

Now open the SystemConfig.cfg file in the TerminalEmulator folder and find the "Devices" section:

The COM port settings, most notably the names, COM1, COM2, etc, must match the names in the Windows Device Manager. Further, you must ensure that the ATB COM port and the BTP COM port have not been swapped. For some reason, Some versions of Windows 10 like to swap the ATB and BTP COM ports on reboot.

InteliSys Service Desk Documentation

CUTE Troubleshooting Guide