Problem: No kind of content is being delivered
If you’re facing a situation when certain (or all) client workstations cannot receive any content types, including basic desktop alerts, there are few steps you can take to help us determine the source of the issue. This guide applies to client applications running under Windows OS.
Step 1. Determine the server URL
On a client workstation, find out what URL the client application is hitting in order to connect to DeskAlerts server. There are two ways to do that.
a. If your client applications are built with the tray icon support and you have “options” command available to your users, you can get the server URL from the Options window by clicking on a corresponding tray menu item:
b. If your client applications are built without the tray icon, or the “Options” item is disabled, locate the client application configuration file, located at %systemdrive%\Program Files (x86)\DeskAlerts\conf.xml for Windows OS 64-bit or at %systemdrive%\Program Files\DeskAlerts\conf.xml for Windows OS 32-bit. Open this file with Notepad or any other text editor and look for the line like this one: The value in quotes after “default” is the server URL.
Step 2. Check the basic connectivity
DeskAlerts agent automatically checks the connection to the server, and if something is wrong with it, the client application’s icon in the system tray starts to display the “connection lost” sign:
If the “connection lost” sign is present, contact your network administrator – usually this means that the clients were built with the wrong server URL, or DNS is functioning incorrectly.
If you don’t have the tray icon enabled, try navigating to the server URL you’ve retrieved on Step 1 using any web browser on your machine. If you are taken to the DeskAlerts server login page – the basic connectivity is OK and you should proceed to Step 3.
If not – report the connectivity issue to your network administrator. If the tray icon is present and is not showing the “Connection lost” sign – proceed to Step 3 to validate the user registration.
Step 3. Check if the current user is visible in the system
For this and further steps, you will need a valid login and password for the publishing console of DeskAlerts.
- Log in, then navigate to Active Directory → Organization page in the left-side menu. If your package doesn’t include Active Directory module – go to the Users and Groups → Users instead.
- Using a search field, try searching for the username of an employee currently logged in to a workstation which is not receiving content.
- If the user is not present in the search result – this means his account is not registered in the system. If you are using the Active Directory synchronization – make sure it includes the test user and is up to date.
- If the user is in the search results – pay attention to the “last activity” field of the search results. If it seems to be off (not showing recent date/time) – report this to DeskAlerts support. If it is valid, the user is visible in the system and you can proceed to Step 4.
Step 4. Send a test alert and pay attention to the receipt report.
Go to Alerts → Create alert and supply any test title and content. Proceed to the Recipients selection stage and target your test user as a recipient. Send an alert, wait for ~1 minute (if you know exactly what your client application polling frequency is – wait for the polling frequency period).
After that, go to Alerts → Sent and click on a report button in the Actions column of your test alert table row. If you see that alert is reported as “Received”, despite not actually showing up on the employee desktop, this is likely a DeskAlerts Server configuration issue.
Please report this to the person administering DeskAlerts server application in your company – they will need to re-run the DeskAlerts server installation, changing the Server URL to the one you determined on Step 1.
Another case when alerts may show as “received” in the system but not actually arrive to the end user’s workstation is when the system is in the lockdown state – so make sure you’re not over the license limit or, if you’re using a trial version, your trial period hasn’t expired yet.
If you find out that either of these conditions is true, contact DeskAlerts support. If the alert is showing up as “not received”, report all your findings to DeskAlerts support team.
Step 5 (Advanced) – Retrieving the server logs
To perform this step, you must have access to DeskAlerts application server In order for our technical support team to better understand the issues which might’ve occurred on the application server, please gather the following two types of logs and send them to DeskAlerts Support:
- The IIS log for the day when the issue has occurred – the location of these can be determined from IIS Manager, the “Logging” feature of the site running DeskAlerts. By default, these are located at C:\inetpub\logs\.
- The system log for the day when the issue has occurred – you can generate one by going to Event Viewer → Windows logs → Application and exporting all “warning” and “error” level events for the needed day.
Step 6 (Advanced) – Retrieving the client-side logs
To perform this step, you must have the rights to install applications on the employee workstation where the issue occurs, and the system client-server communication has to be done via HTTP, not HTTPS (you can tell from the server URL retrieved at Step 1).
- Make sure that the client application is running (deskalerts.exe in the list of processes)
- Download and install Telerik Fiddler web debugging application.3
- Run Telerik Fiddler so it will start tracing all outgoing web communication from the employee workstation.
- Send a test alert to this employee workstations
- Wait for 3-5 minutes with Fiddler still recording the client-server communication
- Save all recorded web sessions into .saz file using File → Save → All Sessions… Send the resulting file to DeskAlerts support with the description of other steps taken.
PDF copy of the article is available by the link below: