Exchange Unified Messaging - voicemails not being delivered to mailbox

Not open for further replies.


Hi there

We have recently implemented Exchange Unified Messaging server role (Exchange 2010 RTM) in the environment. The voice routing to the ExUM server is ok and calls are sent to the correct mailbox, played the correct greeting and can successfully leave a message. Users can dial in to the mailbox to record greetings and retrieve messages etc. etc.

However - issue is that once the message is left it does not get transported to the users Exchange Mailbox but remains spooled on the ExUM server

Event log shows the following:

A pipeline stage encountered the following error. Details : 'Microsoft.Exchange.Net.ExSmtpClient.TlsApiFailureException: A TLS API failure occurred. Error = 0x80090301

Server stack trace:
at Microsoft.Exchange.Net.ExSmtpClient.SmtpSslStream.SmtpSslHelper.Encrypt(Byte[] bytesToEncrypt, Int32 offset, Int32 numberOfBytesToEncrypt)
at Microsoft.Exchange.Net.ExSmtpClient.SmtpSslStream.SmtpSslHelper.Encrypt(Byte[] bytesToEncrypt)
at Microsoft.Exchange.Net.ExSmtpClient.SmtpSslStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.Command(SmtpChunk[] chunks, SmtpCommandType command, Int32 expectedCode)
at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.Ehlo()
at Microsoft.Exchange.Net.ExSmtpClient.SmtpClient.Submit()
at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.SubmitMessage()
at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.InternalDoSynchronousWork()
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.EndInvokeHelper(Message reqMsg, Boolean bProxyCase)
at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(Object NotUsed, MessageData& msgData)
at Microsoft.Exchange.UM.UMCore.SynchronousPipelineStageBase.SynchronousWorkDelegate.EndInvoke(IAsyncResult result)
at Microsoft.Exchange.UM.UMCore.SynchronousPipelineStageBase.EndSynchronousWork(IAsyncResult r)'

-- This error is thrown every time the ExUM server tries to establish a connection to the Hub Transport Server

The Application Log event properties are: Event ID 1423 / Task Category: UMCore

This seems to be an encryption problem, but why? All servers are using the default self-signed certificates and there are no other transport problems in the Exchange Organisation.

One area I am suspicious of is the fact that the self signed certificates do not have the FQDN in the Subject CN=..... field - in my experience with TLS the FQDN is required, but in this case only the hostname is used.

I am planning to re-generate and assign the certificates to the Exchange services using the proper FQDN, but I need to be sure that I am covering all the bases.

Further to this - when looking through the Network Monitor trace I see the error as:

Protocol Name - SSL

Description - SSL :SSLv2RecordLayer, Error (needs reassembly)

Error: HandShakeMessageType: Error

ErrorType: Unknown Authentication Format

Has anyone else had experience with this problem and is there any further advice to add?

Thanks very much for your time and help with this


Hi - thanks for the response

Yes - the exchange UM server is the only one over which I have full control and the ability to tinker outside of change control as it is in pre-production. I have generated and installed a certificate with the correct FQDN on that server and assigned to the UM service

Of course, I have also tested with the certificate just using the host name as per the hub transport server as well to make sure that if the certificates were wrong, at least they were consistently wrong.

Thanks again



Did you ever find out what caused this? We have the same problem on one of our UM servers and it's driving me mad. The UM service just constanly throws this message.





I've resolved this. Our problem UM 2010 box was talking to a local 2010 CAS. The CAS server had had rootsupd.exe run on it to update the local computer " Trusted Root Certification Authorities" store.

This caused a TLS handshake failure between the UM and CAS servers because their were far too many trusted authorities for the process to work.

There were 314 trusted authorities on the CAS. I have trimmed these down to about 80 and UM immediately worked and this error went away (I also restarted the UM service just to be sure).


Not open for further replies.