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

SEC server migration from W2008 to W2016 has stopped SUM communicating with Sophos.

Hi,

I have been tasked with removing old OS platforms from our internal environment and have built a Win2016 server (02) to migrate our existing (and sole) SEC management server role (01) across to. I followed the server to server migration guide (install database component, migrate database and CA, repoint all endpoints etc) however, the one intractable problem I appear to have is that the new SEC server is not getting any updates from Sophos. The ubiquitous 80040401|0402|0406 errors are in the Update Manager log details on every update attempt.

I rechecked the subscription credentials (no authentication failure evident?) and I deleted the contents of the Working\ and Update Manager\Warehouse\ folders but both remain completely empty when I invoke subsequent Update requests. 

I checked with my firewall admin colleagues and there are connection requests going out to Sophos servers (two IP addresses 99.84.224.44, 23.32.52.109) on port 443 but don't appear to be responses/files coming back from Sophos.

I did see the version of SUM initially went from 1.6.x.. to 1.7.1.19, so some communication must have been successful?

Is it possible that the Sophos server end is refusing to authenticate my new server (same internal subnet but different host IP to the previous - formerly working - parent SUM host) even though the subscription login credentials are valid? The Recommended subscription is unchanged, also updating policies.

I assume by following all the migration guide steps that all the config of the previous host was moved and activated intact on the new host?

Thanks,

Cameron



This thread was automatically locked due to age.
  • Hello Cameron,

    SUM initially went from 1.6.x.. to 1.7.1.19, so some communication must have been successful?
    Correct. This suggests that a) the connection could be established and b) the credentials have been accepted. As far as communication with the backend (Sophos) is concerned it should work.

    I see: Last successful download - Never and Could not read from the update source location. The LogViewer says: Cannot create stream - haven't seen posts regarding this error lately (a knowledgebase article suggests credentials or firewall issues as cause but I thin these can be ruled out as SUM has updated). Could you post a relevant part of the SUMTrace log? If there is some useful information it's in the lines around the first occurrence in an update cycle of Cannot create stream.

    There are some posts that "blame" permissions on the \Warehouse\ folder, please see here.  

    Christian

  • Hi Cameron,

     

    In addition to Christian`s workaround, I would like to add a few troubleshooting steps here.

    From the screen capture above, we could see that "Sync to the cloud server is failing" and the error shows "could not contact update location",

    Please double-check and confirm the username and password you are entering is correct and then Sophos Domains are not blocked by your firewall.

    You can see the knowledgebase article here and see if that helps,

    SAJ
    Community Support Engineer | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'This helped me' link.
  • thanks, the firewall guys insist that everything is fully open for my new host in order to do the current debugging and suggested there may be something wrong at the Sophos end given I changed to a different Host IP for this new client end server. Their wireshark trace did not show traffic returning as a response to my host's connection requests.

    I assumed the credentials for our SUM account are correct and unchanged as when i try to use any incorrect ones I get an authentication failure message, quickly, in the Update Manager details.

    I will certainly do these tests (as linked) to manually confirm the accessibility of the listed Sophos hosts, but am out of the office until Friday, now.

     

    regards

    Cameron. 

  • Thank you,

     

    I will get onto the SUMtrace.log and also the permissions check for warehouse\ upon my return.

    I also recall seeing a couple of .lock files somewhere in that general area, which were not disappearing..

     

    regards

    Cameron.

  • Hi again,

     

    My initial action so far has been to follow the linked thread about folder permissions and I did discover that the fully empty Warehouse and Working subfolders did start populating when i tried to add Everyone permissions to the folder structure (somewhere, not sure which one did it), however, the Threat Update and Software Update errors persisted.

    Then, when I made the Everyone account Read/Write on the share (rather than the filesystem) instead of Read (as per the references thread), now the error status for the Update Manager update did finally go away and the update timestamp completed to current time.  

    It is not clear in the previous threads whether this should be temporary or is permanently necessary for the update server to function (nor why it would be set on new installation with the incorrect permissions to begin with!), however, I do note that the folder structure does have the Read-only bit set on every folder and subfolder and when debugging I did try Un-setting the read-only bit at the share|Warehouse|Update Manager subfolder levels etc and although never got any errors (I do have domain and local administrator privileges), yet immediately after, I would recheck the properties of all these folders and the Read-only bit was Set again !?! ie. I cannot turn it off!

    but at this stage, it looks like all my clients have alarmed as being out of date and then updated themselves to current, so that sounds like a very positive outcome. :)

     

    regards

    Cameron.

     

     

  • Hello Cameron,

    good to hear it's working.

    Now, as said, I haven't investigated the detail (due to the "lack of this error". Also I didn't check the permission on the default share that the installer creates. Shares are inticate as both share and file system permissions come into play (and usually unless you have a reason to do otherwise you'd give Everyone Full Control - as this article suggests).
    temporary or is permanently
    AFAIK once all folders have been successfully populated you can reset the NTFS permissions (if they indeed did matter) and should do so but keep Everyone's Share permissions.

    the folder structure does have the Read-only bit set on every folder
    funny you didn't notice before.
    First of all, attributes and permissions are not the same. It's complex and complicated. Especially the R/O attribute is the source of confusion. 
    It's a common misconception and "the Internet" and even Microsoft's Social and Answers are full of threads about this alleged "bug" and the steps "required  to correct" the perceived issue. It's an intricacy of the file system. In file systems like NTFS there's a data space ("file") and one or more directory entries ("file names") in a folder pointing to it (AKA hard links). Usually what is called a file refers to name+data. For any data a reference count, how many names point to it (in most cases it is 1), is kept. If you delete a "file" the count is decreased, when it reaches zero the directory entry is also removed regardless of the R/O attribute of the folder. OTOH, if you have write permission on the folder you can delete any name (whether you have the necessary permissions on the file/data or not). Consequently the count likely reaches zero, resulting in the data to get removed as well regardless of the permissions on the file.
    While a folder is also "just" a file it is a special file with semantics  different from a plain file's. The R/O attribute controls whether you can modify directory entries directly (with the above mentioned consequences) or implicitly. Thus removing the R/O attribute from a folder is perhaps not the best idea.

    Christian