Case Scenario:
Following an upgrade to a newer SecureDoc client, the client was not able to get some devices to boot and get it to communicate with the SES.
Probable Cause:
In this case, it was found that the upgrade was performed by a local admin user that did not have "God-like" elevated rights, AND that the client had locked down access to the registry for non-God-like admins, so parts of the upgrade installation had failed silently.
Product version affected:
All SD versions
Environment:
Windows OS and devices
Steps to follow:
- Determine if the account that did the installation has all the necessary admin elevated rights to change the registry during the process of installation. Did the tech ran the installation "run as administrator"?
- To get back into the system client can do the following:
- Challenge/Response to authenticate to get into the machine
- Use a physical keyfile on a USB media
Once it is in Windows:
- Rename the .DAT files (SDSend.dat; ~SDSend.dat, etc) to some other name.
- Retry forcing the device to communicate to the server - this will probably work, and there may be somewhat of a flood of new key files or other remote command traffic to come down from the server. Let that work its way through.
If the client still cannot communicate
Using the Legacy Control Center app, import the device profile to force it to be reset correctly, then restart SDService and SDPin, then try to force communication with the server by right-clicking on the SecureDoc lock icon and requesting that the client re-communicate with the server. This should be successful at this point.