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

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 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.

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