FDE Policy assigned, but ERI not uploaded

Hi!
ZCM 17.4.1, Windows 10 Pro (1809). Locally I see disks encrypted, but no ERI uploaded to server, can’t force either, I mean, I run QT, it’s showing OK, but still no ERI. For few days now.
Any ideas? Before deeper digging in.
More thanks, Alar.

  • do you found the problem? we have the same issue with version 2020u1.

    regards

    claus

  • Hi!
    Must admit not’ recall exactly, but, yes, we got it appear there. Firstly, it could take some time to appear, I think it checked when service started and login to ZCM server succeeded, not sure, though, but probably You’re waited enough. Secondly, did You tried to force uploading it using ZCC? Does this problem happen only on one device?, some devices register ok?
    Terv, Alar.

  • It stopped in November (timeframe of updating to 2020U1) for all devices (also on devices they had already uploaded a eri version but no new eri version files were uploaded since then.

    Generating an eri file localy works, but if forcing to upload to the server not.

    claus

  • You may want to run a ZDC report to make sure all looks good with your Database and Servers.  However, there are not currently any open issues about ERI files not properly uploading.  In fact, I do not ever recall any previous reports where the issue was systemic as you are reporting, only reports in the past where a device may here or there fail to upload of a particular reason, but even in those cases it would upload if requested to do so again.

  • If you can, an SR would likely be the best route.........

  • Hi!
    Sorry, can’t add much more as Craig already wrote. Opening SR, if possible, wouldn’t do any harm, sure. Also, perhaps digging into logs (both – server and workstation) will lead to something, but, I understand, it might be difficult to accomplish. We had one-off case at the time.
    Hope You’ll find out.
    Terv, Alar.

  • I found the problem, after looking in the ZES log:

    [Always ][04.15.2021 07:28:44.234][5252][ZESService][ 14][][Reporting Uploader, Report Settings Enforcer Thread][][Report Upload to DNS failed - falling back to IP send.][][][][Reporting]
    [Always ][04.15.2021 07:28:46.276][5252][ZESService][ 14][][Reporting Uploader, Report Settings Enforcer Thread][][Report Upload to DNS failed - falling back to IP send.][][][][Reporting]
    [Always ][04.15.2021 07:28:48.323][5252][ZESService][ 14][][Reporting Uploader, Report Settings Enforcer Thread][][Report Upload to DNS failed - falling back to IP send.][][][][Reporting]
    [Always ][04.15.2021 07:28:50.365][5252][ZESService][ 14][][Reporting Uploader, Report Settings Enforcer Thread][][Report Upload failed - no connection to server.][][][][Reporting]
     
    so I installed Wireshark to look what is going on and saw that the eri upload tries to connect on port 80 on the ZCM Server and fails because we have our ZCM system configured on port 8080 and 8443 (historical, never had the courage to change this).
    It looks like an update (maybe 2020u1) has now hardcoded this, I think this is a new bug, all other services honor the configured ports.
    I used the susefirewall "fw_redirect" to redirect incoming port 80 requests to 8080 and I immediately got hundreds auf ERI files uploaded to the server, so no ERI files are lost.
    Support should look into this but I will not open a SR because we have to pay for each, and if the support finds that it is working as designed I will loose a paid SR.
    claus
     
     
  • Hi again!
    Well done! I’m sure Craig can comment these findings.
    Terv, Alar.
  • Thanks, I will report this.

    Note: Make sure to ask for refunds anytime your issue is a defect.  It is supposed to be returned in such cases.  However, no need in this case as I will get a bug opened.

  • Note: In regards to changing ports, It is not normally a huge deal if you have MULTIPLE configuration servers to which devices are configured to talk.  When there is only one, it is something I would avoid.  There are docs that discuss the details, but regardless of what one thinks the docs say, do not try to change the ports on a server that is the only primary to which some devices talk.