Try our conversational search powered by Generative AI!

EPIServer CMS RemoteEventServiceEndpoint net.tcp port stops listening


Dear All,

we are facing an issue where the RemoteEventServiceEndpoint net.tcp ports stops listening and do not start unless we recycle IIS app pool. CMS is hosted in IIS6. Here are the configurations for your reference:

Everytime publishers try to publish, content does not go live and we have to recycle app pools to bring up the listening ports and ask them again to publish.

May you please help what could we do to resolve this?



Edited, Jul 15, 2016 22:31

Does it work at all?

If not, firewalls are the main suspects...

Restarting iis will also clear cache so then you will always get the latest content 

Jul 17, 2016 14:17

Hi Daniel,

Many thanks for your reply.

Yes, it works always when the front-end server's net.tcp RemoteEventServiceEndpoint port is listening on the server. But due to some reason, the listening ports e.g. 13078 & 13089 as mentioned in my earlier post, stops listening on the server itself (so no firewall problem I guess). 

Then to bring these ports up, we have to recycle app pools for the sites and ask the publishers to publish new content again. Caching is not a problem, but random stoppage of these net.tcp ports at front end nodes is.

May you kindly comment on any such known behaviour with net.tcp and how we can get around this issue in EpiServer, so that the ports always keep listening instead of us admins going in the system and recycling the app pools again and again.

Thanks and Regards,


Jul 17, 2016 21:41

What version of Episerver are you on if you are running on IIS 6. Some old version I guess?

Haven't seen a similar bug myself I'm afraid.

Jul 17, 2016 23:48

Hi Daniel,

The EPIServer CMS version we are using is 6.1.

If this is a bug or default net.tcp behaviour, I am not sure.

Thanks and Regards,


Jul 18, 2016 21:38

Sounds like a bug.

Could be this one

My advice would be to upgrade to latest cms 6R2 and hopefully this and a few hundred more bugs are solved. If not, contact Episerver and add a support ticket for it.

Edited, Jul 19, 2016 9:11
<p>If you enable Episerver.log on Debug, do you see any errors ? Can you paste the error stack here ?</p>
Jul 19, 2016 9:29

Thanks Guys,

It seems like that automatic IIS app pool recycles that have been configured on front end nodes, bring down the service ports. Reason, upon recycle, W3SVC is not able to release the older worker process, within default time of 120 seconds, meanwhile, the new app pool process (ASP.Net code in it) which gets created, tries to bind service port mentioned in my post above which fails as the ports are already held by the older process. So I get an AddressAlreadyInUse .Net exception.

A subsequent recycle however, brings the ports up again. So I will have to figure out a way to initiate recycle on AddressAlreadyInUse exception for respective ports.

Have you seen any of the users implementing any better solution to this?

Thanks and Regards,


Jul 20, 2016 23:07
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.