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

SUM windows error 1219

Hello,

 

I got system and I need to fix it. System is build from two SUM, DMZ (hostname - SOPHOS) and Internal. With DMZ I got it and fixed, server is ok, clients is ok.

Both servers are windows server 2012 R2 Std, using WORKGROUP.

But I have problem with Internal server. It should get updates from DMZ server. (sometimes it success, but sometimes it fails with error 1219)

Using UNC to connect from Internal to DMZ (Netbios and RMS ports are opened)

Some lines from SUMTrace log:

All ok:

2017-11-27 10:26:22 : <Info> Downloading and processing customer file data...
2017-11-27 10:26:22 : <Info> Attempting to read local customer file: catalogue/sumcf.dat
2017-11-27 10:26:22 : <Info> Loading warehouses...
2017-11-27 10:26:22 : <Info> Adding packages to sync...
2017-11-27 10:26:22 : <Info> Finding dependencies...
2017-11-27 10:26:23 : <Info> Syncing packages...
2017-11-27 10:26:23 : SyncOperationWarehouseData: Comparing local timestamp 2016-07-14T16:06:57 to remote 2016-07-14T16:06:57
2017-11-27 10:26:23 : SyncOperationWarehouseData: Comparing local timestamp 2016-01-20T14:49:59 to remote 2016-01-20T14:49:59
2017-11-27 10:26:23 : SyncOperationWarehouseData: Comparing local timestamp 2017-05-25T16:57:42 to remote 2017-05-25T16:57:42
2017-11-27 10:26:23 : SyncOperationWarehouseData: Comparing local timestamp 2014-10-28T10:49:32 to remote 2014-10-28T10:49:32
2017-11-27 10:26:23 : SyncOperationWarehouseData: Comparing local timestamp 2017-11-10T14:10:57 to remote 2017-11-10T14:10:57
2017-11-27 10:26:23 : SyncOperationWarehouseData: Comparing local timestamp 2017-11-23T09:38:29 to remote 2017-11-23T09:38:29
2017-11-27 10:26:23 : SyncOperationWarehouseData: Comparing local timestamp 2017-11-23T15:03:04 to remote 2017-11-23T15:03:04
2017-11-27 10:26:23 : SyncOperationWarehouseData: Comparing local timestamp 2017-11-10T14:07:32 to remote 2017-11-10T14:07:32
2017-11-27 10:26:23 : SyncOperationWarehouseData: Comparing local timestamp 2017-11-21T09:15:37 to remote 2017-11-21T09:15:37
2017-11-27 10:26:23 : SyncOperationWarehouseData: Comparing local timestamp 2017-10-17T12:08:24 to remote 2017-10-17T12:08:24
2017-11-27 10:26:23 : SyncOperationWarehouseData: Comparing local timestamp 2017-11-27T02:36:11 to remote 2017-11-27T02:36:11

 

Error:

2017-11-27 10:33:04 : <Info> Downloading and processing customer file data...
2017-11-27 10:33:04 : <Info> Attempting to read local customer file: catalogue/sumcf.dat
2017-11-27 10:33:04 : <Info> Downloading remote customer file.
2017-11-27 10:33:04 : <Info> Successfully downloaded remote customer file content from \\SOPHOS\SophosUpdate\Warehouse
2017-11-27 10:33:04 : <Info> Modifying file according to license state 0
2017-11-27 10:33:04 : <Info> Loading warehouses...
2017-11-27 10:33:04 : Unexpected failure in CreatePackageSourceFrom: Could not add connection to server '\\SOPHOS\SophosUpdate' with username 'Administrator'. The error code is 1219.
2017-11-27 10:33:04 : <ERROR> LoadWarehouseList: Failed to load catalogue sdds.SVE2017-4.4: The warehouse source list has been exhausted.
2017-11-27 10:33:04 : <WARNING> Sync iteration failed. CurrentResult: 6, Error: The warehouse source list has been exhausted.

 

I also tried to change Administrator account to SophosUpdateMgr without success, same error 1219.

I can successfully open UNC share from Internal server. (there is no permanent mapped drives)

What troubleshooting should I do next?

 

BR,

Oscar



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

    1219 is: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. SUM is normally running as Local System but connects to the share using the specified credentials (BTW: you should never use an admin account for this purpose). The error suggests that there is another connection by Local System to the DMZ server but with different credentials. You should be able to find the open handle and its owning process using Process Explorer (Find Handle or DLL ... with DMZ-server as argument).
    Next steps naturally depend on your findings.

    Christian

  • Hello,

     

    Thank You for response!

    Yes I`m aware of admin accounts, how I said, I got this system recently and I need to manage it, but first need to fix it.

    Thank You for pointing on Process Explorer, I used it and did not find any other processes connected to system. So I decide go deeper and monitor in real time.

    I got some log files, where connection was successful and where connection failed.

    There no other processes establishing connection with DMZ server.

    I sent logs to You in private message.

     

    Br,

    Oscar

Reply
  • Hello,

     

    Thank You for response!

    Yes I`m aware of admin accounts, how I said, I got this system recently and I need to manage it, but first need to fix it.

    Thank You for pointing on Process Explorer, I used it and did not find any other processes connected to system. So I decide go deeper and monitor in real time.

    I got some log files, where connection was successful and where connection failed.

    There no other processes establishing connection with DMZ server.

    I sent logs to You in private message.

     

    Br,

    Oscar

Children
  • Hello Oscar,

    the logs provide no further insight. It's probably not that easy to find the offending connection (I'm quite sure there is one) as it seems to short-lived as there's success as well. Find handle would show it if you look for it at the right time.

    You could run the command line handle.exe in a loop. Depending on the Security Audit settings on your DMZ server both SUCCESS and FAILED logins should be in the Security Event log - while this wouldn't show the process on the internal server the username would perhaps give a hint.

    In case your DMZ server publishes SophosUpdate as a web CID you could update via HTTP instead of UNC.

    Christian 

  • Hello,

     

    I understand my mistake, I searched for \\sophos\sophosupdate handle. Today I searched for \\sophos handle. Found one intereseting handle allso connecting to that \\sophos.

    So I made a workaround. In windows host files I added new line with new name. After that I checked again and there is only SophosUpdateMgr.exe connections. And it still fails with 1219 error. Also there is no Failed logins on DMZ server in Security Audit event log, all connections from Internal is with Audit Success.

    So probably is there something bad with configure update manager settings?

    There is also one warning message when I was change update manager source address:

    It is not possible to determine if the source location \\sophosdmzserver\SophosUpdate has a direct network path to Sophos because the location is not managed.

    But I read about this warning and I can ignore it.

     

    HTTP is not configured.

     

     

    EDIT for log:

    2017-12-08 11:24:07 : <Info> Downloading and processing customer file data...
    2017-12-08 11:24:07 : <Info> Attempting to read local customer file: catalogue/sumcf.dat
    2017-12-08 11:24:07 : <Info> Downloading remote customer file.
    2017-12-08 11:24:07 : <Info> Successfully downloaded remote customer file content from \\sophosdmzserver\SophosUpdate\Warehouse
    2017-12-08 11:24:07 : <Info> Modifying file according to license state 0
    2017-12-08 11:24:07 : <Info> Loading warehouses...
    2017-12-08 11:24:07 : Unexpected failure in CreatePackageSourceFrom: Could not add connection to server '\\sophosdmzserver\SophosUpdate' with username 'SophosUpdateMgr'. The error code is 1219.
    2017-12-08 11:24:07 : <ERROR> LoadWarehouseList: Failed to load catalogue sdds.SVE2017-4.4: The warehouse source list has been exhausted.
    2017-12-08 11:24:07 : <WARNING> Sync iteration failed. CurrentResult: 6, Error: The warehouse source list has been exhausted.

     

     

    Br,

    Oscar

  • Still without success.

    I went HTTP path, and now works, just needed to configure other port than 80 because 80 is taken by other service.

    Resume: UNC - still does not work and I gived up. HTTP works.

    Thanks Christian for helping.

     

    Br,

    Oscar

  • Hello Oscar,

    In windows host files I added new line with new name
    nice try. But the hostname (or IP) in the handle is unimportant, you can't cheat Windows this way. Whatever the name it's the same host and the occasional other connection is still there. This is not a SUM misconfiguration.

    Christian

  • Ahhh, ok.

    But workaround with HTTP works perfectly, so we can close this issue :)

    Appreciate Your help.

     

    Br,

    Oscar