Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 22 replies
  • Subscribers 1 subscriber
  • Views 49639 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

80040404 Threat detection data update failed.

tomerb

We have a central update manager that's providing updates for several local servers via http. The whole system worked fine until just a few weeks ago. I think the cause of the problem was the release of SEC 10.0.4, but I'm not sure about that.

The central update manager has the following subscriptions:

9.5 - recommended

9.7 - recommended

10.0 - recommended

The local severs have a full installation of SEC 5.0 and are subscribed to either 9.5 and 10.0 or 9.7 and 10.0.

A few weeks ago seemingly all local servers started issuing 80040404/80040401/80040406 error messages. I've tried the procedure described here

http://www.sophos.com/en-us/support/knowledgebase/66176.aspx

on central as well as local servers - no success.

I've "split" the subscription on the central server into 10.0.3 and 10.0.4 and tried either subscription on one of the local servers - no success.

Finally, I did a complete re-install on a test server (local server) and even that didn't help. Looking at the files I found out, though, that the Sxxx directories are completely missing on the local server whereas the Warehouse seems to be filled normally (~250MB).

Any suggestions?

:24987


This thread was automatically locked due to age.
  • 0

    Hi,

    So you have a central SEC/SUM, that is fine?  It's populating the warehouse directory and pushing to the distribution points?

    The problem is just the "child" SUMs are failing to update from the shared out warehouse on the central server?

    What does the update manager trace log have in it when the "child" SUM tries to update from the parent?

    In this post I also describe how you can telnet to the SUM interface to see what's going on:

    /search?q= 9989

    It only allows local connections by default but may also be of use.

    What if you change a "child" SUM to update from Sophos, does that work?  Is the problem only with the "childs" when they try to update from the parent?  

    Regards,

    Jak

    :25025
  • 0

    So you have a central SEC/SUM, that is fine?  It's populating the warehouse directory and pushing to the distribution points?

    Yes, I'm fairly confident about that. SUM reports no errors at all and directories (Sxxxx) are created as expeted.

    The problem is just the "child" SUMs are failing to update from the shared out warehouse on the central server?

    That's true.

    What does the update manager trace log have in it when the "child" SUM tries to update from the parent?

    Now that's interesting! I'm getting a

    Failed to authenticate user for resource with host server. URL was:

    http://<server>/Warehouse/ec03188cd2c5bb12353ff926b32bc00bx000.dat

    When trying to access this particular file in a browser, I do get a password prompt. However, I can access most (possibly all - I've tried only a few) other files without getting one. I've never configured any kind of password authentication, because we don't need it and we wanted to keep things simple.

    As a quick and dirty solution I tried to supply credentials (tested in a browser - they work) but that doesn't change anything. However, at least I have an idea now where to look for things that are going wrong: The IIS configuration on the parent, which is btw a dedicated Windows 2003 Server.

    I'd still appreciate any other suggestions and I will come back as soon as I find out anything new.

    :25033
  • 0

    I think I'm getting closer to the source of the problem:

    The file ec03188cd2c5bb12353ff926b32bc00bx000.dat has different file system permissions than most (all?) other files in the Warehouse directory: Only Administrators, SYSTEM and Sophos Console Service Users have access - the account for anonymous web access is missing as well as all other accounts. [edit]The file also doesn't seem to have a digital signature from Sophos which most (all?) other files have.[/edit] Although I can't think of any cause at the moment, this at least explains the symptoms.

    I will try to (once again) re-populate the Warehouse on the parent.

    :25035
  • 0

    Hi,

    That file you call out is "vvf.xml".  "vvf.xml" comes with the SAV package but also is downloaded as part of the SEC data package.  

    The files in the SEC data package are put there by SUM, i.e. on 2008+:
    "\programdata\sophos\Sophos Endpoint Management\5.0\Updates\Secure\SDFs\SophosMA\sec\MSDC\vvf.xml"

    Note: maybe in a slightly different location if you've upgrades as the directory is maintained. 

    This appears to be a hardlink to the file in the warehouse directory, which explains the different permissions.  To prove it you can run:

    fsutil hardlink "C:"\programdata\sophos\Sophos Endpoint Management\5.0\Updates\Secure\SDFs\SophosMA\sec\MSDC\vvf.xml"

    Will show the link to the file in the warehouse.

    Running AccessEnum (http://technet.microsoft.com/en-us/sysinternals/bb897332.aspx ) against the Warehouse directory will highlight the files with different permissions.  These mush be each of the dat files associates with the files in the directory mentioned above.

    This file type wouldn't be signed as it's just an XML data file.

    Regards,

    Jak

    :25039
  • 0

    The file is indeed an xml-File - however, there doesn't seem to be any file called wf.xml in "C:\Documents and Settings\All Users\Sophos\". (At least using explorer search won't find one.)

    The good news is that this doesn't matter any more as the problem seems to be solved by now. I repeated the procedure I mentioned in my very first post - this time it worked. I have no idea why this didn't work the first time or what went wrong in the first place.

    So thanks a lot for your help - I think I learned quite a lot today. :)

    Thomas

    :25045
  • 0

    HI, I think the problem is my font choice :)

    It's:

    VVF.XML not W.XML

    Regards,

    Jak

    :25053
  • 0

    Not really an improvement, Jak :smileywink: (and now an "f" disappeared)

    Lemme try this one: vvf.xml not wf.xml - or perhaps: vvf.xml not wf.xml - but lay the blame on Sophos for choosing such a name :smileyvery-happy:

    Christian

    :25057
  • 0

    So here I am again with the same infrastructure, similar symptoms and - most certainly - a different reason. So we still (again) got a 80040404/80040401/80040406 issue, but the SUMTrace shows different errors plus there are child servers out there that actually work. So here's the SUMTrace...

    It starts with:

    2012-06-05 15:27:24 : Cmd-ALL << [I1021][ActionGatherCurrencyData-SDDM][DispatcherSupplements-2012-06-05T13-27-21-4] Action 'ActionGatherCurrencyData-SDDM' with caller 'DispatcherSupplements-2012-06-05T13-27-21-4' started...
    2012-06-05 15:27:24 : GatherCurrencyData: Considering payload Payload-SDDM...
    2012-06-05 15:27:24 : GatherCurrencyData: Sync marked as failed, sending the abort.
    2012-06-05 15:27:24 : Cmd-ALL << [E402D][DispatcherSupplements-2012-06-05T13-27-21-4][A845A8B5-6532-4EF1-B19E-1DB2B3CB73D1] Gather Currency Data operation invoked by dispatcherId 'DispatcherSupplements-2012-06-05T13-27-21-4' on product with rigid name 'A845A8B5-6532-4EF1-B19E-1DB2B3CB73D1' has been aborted because the data has not been synchronised correctly.
    2012-06-05 15:27:24 : Cmd-ALL << [I0009][ActionGatherCurrencyData-SDDM][DispatcherSupplements-2012-06-05T13-27-21-4] Action 'ActionGatherCurrencyData-SDDM' with caller 'DispatcherSupplements-2012-06-05T13-27-21-4' succeeded!
    2012-06-05 15:27:24 : Cmd-ALL << [I1021][ActionDecodeEverything-SDDM][DispatcherSupplements-2012-06-05T13-27-21-4] Action 'ActionDecodeEverything-SDDM' with caller 'DispatcherSupplements-2012-06-05T13-27-21-4' started...
    2012-06-05 15:27:24 : Cmd-ALL << [E402A][A845A8B5-6532-4EF1-B19E-1DB2B3CB73D1][RECOMMENDED] The decode of payload A845A8B5-6532-4EF1-B19E-1DB2B3CB73D1 and requested version RECOMMENDED was aborted because the synchronise is marked as failed.
    2012-06-05 15:27:24 : Cmd-ALL << [E400D][ActionDecodeEverything-SDDM][DispatcherSupplements-2012-06-05T13-27-21-4] Action 'ActionDecodeEverything-SDDM' with caller 'DispatcherSupplements-2012-06-05T13-27-21-4' failed!
    2012-06-05 15:27:24 : Cmd-ALL << [E400E][DispatcherSupplements-2012-06-05T13-27-21-4] Event with dispatcher ID 'DispatcherSupplements-2012-06-05T13-27-21-4' failed to execute.
    2012-06-05 15:27:24 : Cmd-ALL << [I1020][DispatcherSupplements-2012-06-05T13-27-21-4] All events with dispatcher ID 'DispatcherSupplements-2012-06-05T13-27-21-4' complete.
    2012-06-05 15:27:24 : Cmd-Sock-980 >> DumpConfigXML default

    (snipped a bit)

    2012-06-05 15:37:23 : Package synchronisation started.
    2012-06-05 15:37:23 : Finished package synchronisation.
    2012-06-05 15:37:23 : Sync failure: Cannot create stream 70d5 a8cb 97e2 7fede 48ab 38ea f7c4 ae7x 000 .xml
    2012-06-05 15:37:23 : Cmd-ALL << [E401F][2DE69C24 - D975 - 47b2 - 8D2F - 6BEA861A9C75][Cannot create stream 70d5 a8cb 97e2 7fed e48a b38e af7c 4ae7 x000 .xml][RECOMMENDED][http://172.25.x.y/Warehouse] Supplement synchronisation operation failed when synchronising payload '2DE69C24-D975-47b2-8D2F-6BEA861A9C75'. Details: Cannot create stream 70d5a8cb97e27fede48ab38eaf7c4ae7x000.xml
    2012-06-05 15:37:23 : Cmd-ALL << [E403C][F26F7EC0-1302-4DA7-8B6B-A5383051D41A][Not attempted.][RECOMMENDED][http://172.25.x.y/Warehouse] Supplements for payload 'F26F7EC0-1302-4DA7-8B6B-A5383051D41A' could not be synchronised because the synchronise operation failed due to an earlier error.
    2012-06-05 15:37:23 : Cmd-ALL << [E403C][F26F7EC0-1302-4DA7-8B6B-A5383051D41A][Not attempted.][RECOMMENDED][http://172.25.x.y/Warehouse] Supplements for payload 'F26F7EC0-1302-4DA7-8B6B-A5383051D41A' could not be synchronised because the synchronise operation failed due to an earlier error.
    2012-06-05 15:37:23 : Cmd-ALL << [E403C][7D48A012-0C64-4F21-BA27-A9CEDF442749][Not attempted.][0.0.0][http://172.25.x.y/Warehouse] Supplements for payload '7D48A012-0C64-4F21-BA27-A9CEDF442749' could not be synchronised because the synchronise operation failed due to an earlier error.
    2012-06-05 15:37:23 : Cmd-ALL << [E403C][A845A8B5-6532-4EF1-B19E-1DB2B3CB73D1][Not attempted.][RECOMMENDED][http://172.25.x.y/Warehouse] Supplements for payload 'A845A8B5-6532-4EF1-B19E-1DB2B3CB73D1' could not be synchronised because the synchronise operation failed due to an earlier error.
    2012-06-05 15:37:23 : Cmd-ALL << [E400D][ActionSyncSupplements][DispatcherSupplements-2012-06-05T13-37-21-5] Action 'ActionSyncSupplements' with caller 'DispatcherSupplements-2012-06-05T13-37-21-5' failed!
    2012-06-05 15:37:23 : Cmd-ALL << [I1021][ActionGatherCurrencyData-Sub0][DispatcherSupplements-2012-06-05T13-37-21-5] Action 'ActionGatherCurrencyData-Sub0' with caller 'DispatcherSupplements-2012-06-05T13-37-21-5' started...
    2012-06-05 15:37:23 : GatherCurrencyData: Considering payload Payload-Sub0...
    2012-06-05 15:37:23 : GatherCurrencyData: Sync marked as failed, sending the abort.

    (snipped the rest)

    To be honest, I'm lost at the moment and a bit frustrated, too. I've got some 80 servers out there and Sophos is supposed to be only a minor issue.

    :25561
  • 0

    Can the computer where the failing SUM is obtain the file:

    http://172.25.x.y/Warehouse] /0d5a8cb97e27fede48ab38eaf7c4ae7x000.xml

    where the ip is that of the parent.

    Regards,

    Jak

    :25563
  • 0

    No, apparantly that file doesn't exist on the parent. So I'll rebuild the warehouse on the parent once more. If it doesn't help, at least it won't hurt.

    Is this possibly a version issue? All "functional" children are running SEC 5.0 and so does the parent. The children that aren't working have recently been updated to SEC 5.1.

    :25573