You are viewing limited content. For full access, please sign in.



Workflow Error - I am confused about the source and the party (Who is the source and Who is the party)

asked on March 2

I am getting an error trying to send an email but the error source is listed as "System". I would expect the error source to be the SMTP server, yet there is no record of SMTP servers returning an error like this. So WHO is "System"?

There is a system stating that another party has closed the transport stream. How do I find out who the system is and who the party is?

      <Message>Authentication failed because the remote party has closed the transport stream.</Message>


0 0


replied on March 2

The remote party is whatever destination you're trying to reach. I can't be sure without seeing the full stack trace or knowing more about the mail server you're trying to reach, but a mismatch in TLS protocols between WF and the mail server is the likely cause.

1 0
replied on March 2

And the Source is the service identity that logged that message (whatever Workflow is running as). The default built-in "Local System" account that Workflow runs as by default often appears in logs as "System". It's not clear where exactly which log this error message came from, so Source might instead reference the base of the namespace that surfaced the error (System.Net.Mail). More likely the WF service identity though.

So System is Workflow. The remote party is the SMTP server.

In this case, the error says the SMTP endpoint is rejecting the connection, so it's almost certainly a TLS protocol version mismatch like Miruna said. Apply the usual SchUseStrongCrypto reg keys to enable TLS 1.2 for Workflow 10.4.2 or earlier, or upgrade to Workflow 10.4.3 which supports TLS 1.2 automatically because it uses .NET 4.8.

I've also seen this error appear when a customer has an SMTP relay or listener alias with a friendly name like with one or more actual mail servers behind it with names like Often the mail servers will have certs with only their hostnames instead of ones that include the alias. Workflow (really the .NET Mail class) expects to see in the certificate for the TLS handshake but gets one with instead and correctly rejects the connection due to the name mismatch.

DigiCert has a great free utility you can use to help troubleshoot this kind of issue if neither of the above work:

DigiCert Certificate Utility for Windows

0 0
replied on March 3

Let me post the full stack trace, I am not sure it says anything about TLS1.2 being required. If TLS1.2 was required and workflow was using a different version, then why would we also have many successful emails sent through the same SMTP server?

They are running WF: and I don't mind upgrading, but right now I don't see anything that says a different version of TLS is needed.

This DigiCert utility looks like it was meant to be run on the SMTP server OS, but they are using a cloud service (Office 365) so I would need a utility that can remotely request the TLS version of the SMTP server from it's endpoint address.

Again though, my logical brain is not accepting that an SMTP server is accepting a request on a different version of TLS one minute and one minute later deciding that it will only accept TLS1.2 then another minute later accepting a request on the other version.

There are 10-50 of successful emails a day and 5-15 failures. Only one SMTP server is configured and ever used. Only 1 workflow server and the failures are from the same workflow as the successes.

Timestamp: 2021-03-03 15:36:06.242
Local Time: 3/3/2021 7:36:06 AM
Category: Activity
Machine: SERVER
Severity: Error
Application Domain: Laserfiche.Workflow.Service.exe
Process Id: 3340
Process Name: C:\Program Files\Laserfiche\Laserfiche Workflow 10\Laserfiche.Workflow.Service.exe
Win32 Thread Id: 18692 - 
Thread Name: 
Message: <Exception handlingInstanceId="d35554a9-d58b-448b-9662-8ae8fe34fbb3">
  <Description>An exception of type 'System.Exception' occurred and was caught.</Description>
  <DateTime>2021-03-03 07:36:06Z</DateTime>
  <ExceptionType>System.Exception, mscorlib, Version=, Culture=neutral, PublicKeyToken=</ExceptionType>
  <Message>Failure sending mail.</Message>
  <HelpLink />
  <Property name="ActivityName">Email_Email</Property>
  <Property name="ActivityType">Laserfiche.Workflow.Activities.Email.EmailActivity</Property>
  <Property name="InstanceId">9a812208-b7d3-45f0-a3b0-5dc8d1d522a2</Property>
  <Property name="TargetSite">Void ProcessTaskQueueEvent(System.Workflow.ComponentModel.ActivityExecutionContext)</Property>
  <Property name="HResult">-2146233088</Property>
  <StackTrace>   at Laserfiche.Workflow.Activities.TaskActivityBase.ProcessTaskQueueEvent(ActivityExecutionContext context)
   at Laserfiche.Workflow.Activities.TaskActivityBase.OnEvent(Object sender, QueueEventArgs e)
   at System.Workflow.ComponentModel.ActivityExecutorDelegateInfo`1.ActivityExecutorDelegateOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime)
   at System.Workflow.Runtime.Scheduler.Run()</StackTrace>
    <info name="MachineName" value="SERVER" />
    <info name="TimeStamp" value="3/3/2021 3:36:06 PM" />
    <info name="FullName" value="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=5.0.414.0, Culture=neutral, PublicKeyToken=" />
    <info name="AppDomainName" value="Laserfiche.Workflow.Service.exe" />
    <info name="ThreadIdentity" value="" />
    <info name="WindowsIdentity" value="NT AUTHORITY\SYSTEM" />
    <ExceptionType>System.Net.Mail.SmtpException, System, Version=, Culture=neutral, PublicKeyToken=</ExceptionType>
    <Message>Failure sending mail.</Message>
    <HelpLink />
    <Property name="StatusCode">GeneralFailure</Property>
    <Property name="EmailSyncLevel">2</Property>
    <Property name="StartTime">3/3/2021 3:36:05 PM</Property>
    <Property name="EndTime">3/3/2021 3:36:06 PM</Property>
    <Property name="Duration">00:00:00.4062240</Property>
    <Property name="InstanceId">9a812208-b7d3-45f0-a3b0-5dc8d1d522a2</Property>
    <Property name="ActivityName">Email_Email</Property>
    <Property name="Workflow">SendSMSNotification</Property>
    <Property name="ContextGuid">4822028c-7321-437e-8bd1-039416dc71be</Property>
    <Property name="TargetSite">Void Send(System.Net.Mail.MailMessage)</Property>
    <Property name="HResult">-2146233088</Property>
    <StackTrace>   at System.Net.Mail.SmtpClient.Send(MailMessage message)
   at Laserfiche.Workflow.Activities.Email.Runtime.EmailTaskExecutor.Execute(EmailTaskOptions options, TaskExecutorContext status)</StackTrace>
      <ExceptionType>System.IO.IOException, mscorlib, Version=, Culture=neutral, PublicKeyToken=</ExceptionType>
      <Message>Authentication failed because the remote party has closed the transport stream.</Message>
      <HelpLink />
      <Property name="TargetSite">Void StartReadFrame(Byte[], Int32, System.Net.AsyncProtocolRequest)</Property>
      <Property name="HResult">-2146232800</Property>
      <StackTrace>   at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
   at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.Mail.SmtpConnection.Flush()
   at System.Net.Mail.ReadLinesCommand.Send(SmtpConnection conn)
   at System.Net.Mail.EHelloCommand.Send(SmtpConnection conn, String domain)
   at System.Net.Mail.SmtpConnection.GetConnection(ServicePoint servicePoint)
   at System.Net.Mail.SmtpClient.GetConnection()
   at System.Net.Mail.SmtpClient.Send(MailMessage message)</StackTrace>


0 0
replied on March 4

Well we didn't find the reason for the transport stream being closed but we did find part of the problem. There is an option in workflow where you can specify an alternative SMTP server to use, besides anything configured in the master SMTP server list.

It is on the lower right hand corner as a hyperlink called Advanced. They had been using this, so the email was using a different SMTP server hosted locally rather than the office 365 service. We switched to Office 365 and hopefully the failures will stop.

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.