Problems with the FrontDesk kiosk app, listed by what you see on the tablet. Each entry follows the same shape: the symptom, what the message actually means, why it happens, how to fix it now, how to make the fix permanent, and what to do if it returns.

If you are setting a kiosk up for the first time rather than fixing one, start with Set Up Kiosk and Guard Devices.

Pairing fails with “Invalid Server Configuration”

Symptom

You are on the kiosk app’s Device Pairing Setup screen. You enter the server address and the Device Key, tap PAIR DEVICE, and instead of continuing, the app shows this message:

Invalid Server Configuration. Please ensure that the timezone settings on both the server and the kiosk are correct, and that the time is synchronized between all devices.

Pairing does not complete. The app remains on the pairing screen, and re-entering the key changes nothing.

What it means

Despite the wording, this is almost never a configuration problem and it is almost never a timezone problem. It means one thing: the tablet’s clock and the server’s clock disagree by more than 60 seconds.

When you tap PAIR DEVICE, the kiosk sends its device key to the server, and the server answers with, among other things, its own current time. The kiosk compares that against its own clock. If the two are more than 60 seconds apart, in either direction, the kiosk refuses to pair and shows the message above. A clock that is 3 minutes out is three times over the allowance, so pairing is refused every time.

Timezone is not what is being compared. The two clocks are compared as absolute points in time, not as the wall-clock reading each device displays. A kiosk in one timezone and a server in another will show different times on screen and still pass the check perfectly, as long as both clocks are actually correct. Only a wrong clock reading triggers it. This is the trap in the message: it sends people to the timezone setting, where there is nothing to fix. Set the timezone correctly anyway so that on-screen times read naturally, but do not expect it to clear this error.

The allowance is fixed. The 60-second window is built into the kiosk app. There is no setting on the server, in the device record, or on the tablet that widens or disables it, so the only way past this message is to correct the clock.

Where the check runs. It runs during pairing only, at the moment you tap PAIR DEVICE. It does not run again on later start-ups, so a kiosk that paired successfully keeps working even if its clock drifts afterwards. That is why the problem often appears out of nowhere on a tablet that has been in service for months: nothing changed except that the app had to pair again, after app data was cleared or after the server stopped accepting the stored keys and the app returned to the pairing screen. If you cleared app data to re-pair a device (see Clear App Data), you meet this check again on the way back in.

The Guard app does not do this check. Only FrontDesk kiosk pairing compares clocks. A guard handset pairs and works with a drifting clock, so “the Guard app is fine on the same network” tells you nothing about the kiosk tablet’s clock.

Why it happens

The usual cause is a tablet with no working time source, even though it looks like it has one.

• “Set time automatically” being on does not mean anything is setting the time. Android takes automatic time either from the mobile network (which needs a SIM and carrier support) or from an internet time server over the network. On a Wi-Fi-only tablet with no SIM, only the internet time server route is left.
• That route is easy to block. If the site firewall blocks outbound time traffic (UDP port 123), or blocks the address the tablet asks for, or the tablet is on a network segment with no internet access at all (common where the kiosk only needs to reach the EvTrack server on the local network), the toggle is on and nothing ever answers. The clock then free-runs on the tablet’s internal oscillator and drifts, typically by minutes over weeks. A site that restricts satellite positioning usually restricts other outbound traffic too, so treat “GPS is disabled here” as a hint that time traffic may be blocked as well.
• GPS is not Android’s normal clock source. Turning location services on will not fix this, and having them off is not the cause.
• Even a working automatic update is periodic, not continuous. The tablet corrects itself on a schedule, so a device with a poor or intermittent time source can still be minutes out between updates.
• The server can be the one at fault. Rare if the server runs a healthy time service, but worth ruling out. Useful discriminator: if one tablet fails to pair, suspect that tablet. If every kiosk suddenly fails to pair, suspect the server clock.

Fix it now

This gets the kiosk paired today. It is a temporary fix on a tablet with no time source, so do the “Make it stick” section afterwards.

1. Measure the difference. Put the tablet next to a screen showing a clock you trust (the server’s own clock, or any device known to be correct), and compare them to the second. Note how far out the tablet is and in which direction.
2. Check the server first if several kiosks are affected. Compare the server’s clock against the trusted source. If the server is the one that is wrong, fix the server’s time service and stop here; the kiosks will pair once the server is right.
3. Set the tablet’s clock by hand. On the tablet, open Settings > System > Date & time. Turn Set time automatically off, then set the date and the time to match the trusted clock as closely as you can, within a few seconds. Set the timezone to the site’s zone while you are on the screen, so displayed times read correctly.
4. Leave automatic time off for now. Only turn it back on once the tablet actually has a time source that works (next section). Left on with nothing answering, it changes nothing and hides the fact that the clock is unmanaged.
5. Pair again. Open the kiosk app. If it starts on the Device Pairing Setup screen, enter the server address and the Device Key from the device record, and tap PAIR DEVICE. If the app starts somewhere else, clear its app data first, see Clear App Data, then start it again. The device key is on the device’s record in the web interface, see Get Device Key.

End state: the message does not appear, the app carries on past the pairing screen to the kiosk welcome screen, and the device record in the web interface shows the kiosk as connected.

Make it stick

A tablet with no time source will drift back out and fail the next time it has to pair. Give it a real time source, in this order of preference:

1. Point the tablets at a time server through your device management platform. If the tablets are enrolled in an MDM or run in a managed kiosk mode, set the date and time policy centrally and point it at a time server the tablets can actually reach. This is the durable answer for a fleet, because it survives factory resets and re-provisioning.
2. Use the site’s own time server. Many sites already run one internally, often the same one that keeps the EvTrack server correct. Pointing the tablets at it makes the two clocks agree by construction, which is exactly what the pairing check tests. Some Android builds expose a time server field under the date and time settings; where the build does not, this has to come from the device management platform, because ordinary apps are not allowed to set the system clock on an unmanaged Android device.
3. Open the network path. Ask the network team to allow outbound time traffic (UDP port 123) from the tablet network to your chosen time server, internal or on the internet. Without that, every other option silently does nothing. Once the path is open, turn Set time automatically back on and confirm the next day that the tablet is still correct.
4. Keep the server’s time service healthy. The check compares two clocks, so both have to be right. A server whose time service has stopped will fail every kiosk pairing on the system at once.

If it comes back

• Recurrence means the tablet still has no working time source. A manual correction holds only until drift eats the 60-second allowance again. If the message returns weeks or months later on the same tablet, go back to “Make it stick” instead of setting the clock by hand a second time.
• Spot-check monthly. Compare the kiosk’s clock with a trusted clock. If it has moved by more than a minute since the last check, the tablet is free-running and the fix has not landed.
• All kiosks at once points at the server. One tablet is a tablet problem. Every tablet on the same day is a server clock problem.
• Do not chase the timezone. Changing timezone settings on the tablet or on the server has no effect on this message. If times pair correctly but display in the wrong zone, that is a separate regional setting, covered in Region Settings.

Other symptoms

• A visitor is refused at the kiosk or the checkpoint: work through the decision diagram in Access Control Lists, which maps each numbered result the kiosk reports to its cause, and explains why the same refusal can come from five different faults.
• The kiosk pairs but behaves unexpectedly (wrong fields on the registration form, camera not requested, agreements missing, wrong lockdown behaviour): this is configuration rather than a device fault. Kiosk behaviour is set centrally, see Kiosk Settings.
• The kiosk needs to be paired to a different server or device record: clear the app’s data first, see Clear App Data, then pair again as in Configure App on Device.
• Installing or updating the app, and pairing a new device from scratch: see Set Up Kiosk and Guard Devices.