The other day, I logged into a client site for some updates. New content, some images, nothing fancy. This particular client ran their site on Sitefinity 6.3. I was able to log in, navigate and pull up the page for editing without a problem.
But when I’d made my changes and tried to save, I received an error. One I’d never seen before.
“No endpoint listening”?
“Incorrect address or SOAP action”?
What the heck’s going on?
So I talked to our Sitefinity developer. And found out this wasn’t the fault of the website itself. This was happening on all the sites we’d moved to a new server. A brand-new server running Windows Server 2012 R2, in fact.
The Technical Situation
We’d just moved a group of websites to this new server. It was setup with the latest Windows Server, and activated all the relevant IIS 8.5 modules (for example: MIME Types for XAML, XAP and XBAP; handler mappings for .svc and .xamlx file extensions; permissions and authentication; and so on).
The sites were live on the front end and working fine. But when you tried to edit a page or a Content module, execution failed. It gave a vague error message that was not very helpful:
“There was no endpoint listening at http://domain.com/DefaultWorkflows/AnyContentApprovalWorkflow.xamlx that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.”
In order to explain how this error comes about, let me step back a bit & examine Sitefinity’s publication process.
How Sitefinity Updates Pages (And Why It Wasn’t for Us)
Sitefinity Administration uses a SilverLight-based workflow process that has the server posting to itself to publish content and pages. When this executes, the server posts outbound to the Internet using either the website’s domain setting, or the configuration value set in Advanced Settings -> System -> ServicePath.
Placing the website’s DNS entry in that field had the same results as the error mentioned above. We traced the path and found it went outside of our network to the Internet. There it tried to resolve the address, and come BACK to the server to save the data.
Internal IP to External IP to Internal IP…hello, routing snag! Sitefinity couldn’t find the path back, and responded with the error. (Trying to go directly to the workflow services path yielded a 404.)
Took us a little while to figure out why Sitefinity wasn’t behaving!
The Solution? Edit the Hosts File, Tell the Servers to Stay Local
The solution we eventually found was to add entries in the server’s hosts file. Essentially, we made the server stop looking out to the Internet for those IP addresses, and stay local instead.
To do this, we had to add entries for every domain binding that pointed at the localhost IP address (127.0.0.1). Followed by the domain entries, like mydomain.com and www.mydomain.com.
Once we had these entries in place, the server behaved itself. Sitefinity updates went through like clockwork. We repeated the process for every other Sitefinity website we host, adding more DNS binding entries to each hosts file. Now everything works fine.
This solution is NOT documented yet! Probably because it’s so unusual. But we did find information online from other Sitefinity CMS users who experienced a similar problem. Some as far back as Sitefinity 4.0.
NOTE: This solution is a workaround at best. It does allow users to continue editing Sitefinity content. But it’s not the cleanest practice.
I’m hopeful a solution is coming in Sitefinity 7.0. In the meantime, if you’ve migrated a Sitefinity website onto a Windows Server 2012 R2 server and can’t update pages now…this is what you’ll have to do.
The moment we hear about a more permanent in-system fix, we’ll post it here.
Have you run up against this update issue post-migration? How’d you resolve it? If your solution is different, please share it in the comments.