A few weeks ago I saw that applications and packages was intermittently not being pushed over to our Secondary sites. When I looked in the sender.log I found the following:
There is no existing connection, Win32 error = 53
There is no existing connection, Win32 error = 53
Error during connection to \\<FQDN>\SMS_SITE (53). Error is considered fatal. Cannot connect to server <FQDN_of_server> at remote site <site_code>, won't try send requests going to site <site_code> for an hour or until there are no active send requests.
Could not establish connection.
Attempt to connect failed.
Every time I saw the problem, I tried to restart the SMS_Executive service on the Primary site. Suddenly all queued up sending packages started to go out to the Secondary sites. Okey, problem solved? No, it would after a random time stop to work again, and the same error appeared.
My first suspicion was that the Primary site account was not added to the local group SMS_SiteToSiteConnection_<site code>. But why would it work after a restart of the SMS_Executive service, and then suddenly stop working? So I started looking into the permissions on C:\Program Files\Microsoft Configuration Manager\inboxes\despooler.box\receive to double check everything was in order. There I found out that theSMS_SiteToSiteConnection_<site code> group was indeed there. I added the Primary site computer account explicitly with Full Permissions for troubleshooting purposes. That didn’t do the trick, the problem still occurred intermittently.
When I opened up Windows Explorer and tried browsing to the \\<secondary-site>\SMS_SITE share, it worked out just fine. This was really giving me a headache, because I couldn’t really understand why it wouldn’t work.
At this point I started to see a pattern for my problem. Every time I initiated a new session to the share by either browsing or restarting the SMS_Executive service, it worked but then stopped working after a while. It hit me that we’re using WAN accelerators on our local office locations. Could they have something to do with it? I talked to our network team and asked them to let my Primary site to Secondary site traffic pass-through the WAN accelerator. When they had re-configured one of the WAN accelerators and I had restart the SMS_Executive service once again, it worked (as expected of course, since it worked every time after a service restart). But as a pleasant surprise, for that specific Secondary site with the re-configured WAN accelerator, it had after 2 days still not stopped working. So the network team re-configured the rest of our WAN accelerators, and to date it has still not stopped working. Woho!
Hi Nickolaj,
We face similar issue in our environment, packages not pushed to some of our pull DP’s error code = 59. When browse through windows explorer it’s not working as well but able to browse with ip address. So my doubt is you asked network team to configure the traffic through WAN accelerator which is not in first place?