Após instalação do CU6 no Exchange Server 2016 OWA tornou-se indisponível
Logo após instalar a atualização CU6 no Exchange Server 2016 OWA tornou-se indisponível para os usuários. Ao acessar o OWA de um usuário no Exchange 2016 CU6, ocorria o seguinte erro:
🙁 Something went wrong
We can’t get that information right now. Please try again later.
X-ClientId: xxxxx
X-FEServer: Exchange
A URL redirecionava ao endereço: https://mail.dominio.com/owa/auth/errorFE.aspx?httpCode=500
No Event Viewer, existiam os seguintes erros:
Event ID: 1309
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 12/4/2017 12:22:04 PM
Event time (UTC): 12/4/2017 11:22:04 AM
Event ID: 6fd47b742f4443b3be4ecf89e99cdf0a
Event sequence: 2
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/2/ROOT/owa-191-131568601008346029
Trust level: Full
Application Virtual Path: /owa
Application Path: C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\owa\
Machine name: EXCHANGE
Process information:
Process ID: 20648
Process name: w3wp.exe
Account name: NT AUTHORITY\SYSTEM
Exception information:
Exception type: TargetInvocationException
Exception message: Exception has been thrown by the target of an invocation.
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Owin.Loader.DefaultLoader.<>c__DisplayClass12.<MakeDelegate>b__b(IAppBuilder builder)
at Owin.Loader.DefaultLoader.<>c__DisplayClass1.<LoadImplementation>b__0(IAppBuilder builder)
at Microsoft.Owin.Host.SystemWeb.OwinAppContext.Initialize(Action`1 startup)
at Microsoft.Owin.Host.SystemWeb.OwinBuilder.Build(Action`1 startup)
at Microsoft.Owin.Host.SystemWeb.OwinHttpModule.InitializeBlueprint()
at System.Threading.LazyInitializer.EnsureInitializedCore[T](T& target, Boolean& initialized, Object& syncLock, Func`1 valueFactory)
at Microsoft.Owin.Host.SystemWeb.OwinHttpModule.Init(HttpApplication context)
at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)
Encryption certificate is absent
at Microsoft.Exchange.Security.Authentication.Utility.GetCertificates()
at Microsoft.Exchange.Clients.Owa2.Server.Core.notifications.SignalR.SignalRStartup.Configuration(IAppBuilder app)
Request information:
Request URL: https://localhost:444/owa/exhealth.check
Request path: /owa/exhealth.check
User host address: 127.0.0.1
User:
Is authenticated: False
Authentication Type:
Thread account name: NT AUTHORITY\SYSTEM
Thread information:
Thread ID: 11
Thread account name: NT AUTHORITY\SYSTEM
Is impersonating: False
Stack trace: at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at Owin.Loader.DefaultLoader.<>c__DisplayClass12.<MakeDelegate>b__b(IAppBuilder builder)
at Owin.Loader.DefaultLoader.<>c__DisplayClass1.<LoadImplementation>b__0(IAppBuilder builder)
at Microsoft.Owin.Host.SystemWeb.OwinAppContext.Initialize(Action`1 startup)
at Microsoft.Owin.Host.SystemWeb.OwinBuilder.Build(Action`1 startup)
at Microsoft.Owin.Host.SystemWeb.OwinHttpModule.InitializeBlueprint()
at System.Threading.LazyInitializer.EnsureInitializedCore[T](T& target, Boolean& initialized, Object& syncLock, Func`1 valueFactory)
at Microsoft.Owin.Host.SystemWeb.OwinHttpModule.Init(HttpApplication context)
at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)
A princípio achei que poderia ser algo relacionado ao SharedWebConfig.config, já que o erro EventID 1309 geralmente se refere a erros ou falta do SharedWebConfig.config. Mas notei que não era o caso ao ver a parte mencionada “Encryption certificate is absent at Microsoft.Exchange.Security.Authentication.Utility.GetCertificates()” na log acima, ficou claro então que se tratava de um erro de certificado.
A Microsoft já realizou a criação de um artigo para tratativa do problema. Porém recomendo que leiam meu artigo com atençao até o final, pois existem alguns gaps no artigo da Microsoft no qual abordarei aqui.
Causa:
O erro ocorre por conta da falta do Certificado OAuth, no qual na versão CU6 foi constatado um erro por parte da Microsoft de falta do mesmo, o que impacta no acesso ao OWA, e em alguns casos específicos no ECP também. Para validar se o certificado existe, não existe ou está corrompido, rode o seguinte comando:
Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint
No me caso, o comando o resultado foi o seguinte:
A special Rpc error occurs on server EXCHANGE: The certificate with thumbprint
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX was not found.
Resolução:
A Microsoft recomenda que seja instalado o CU7, que em teoria corrige esse problema, dentre alguns outros.
Particularmente eu não pude realizar essa solução, pois o CU7 tem um requisito mínimo de Forest/Domain level de 2008R2, o que me impossibilitou a atualização. Deixarei abaixo a solução de contorno para quem igual eu não pode aplicar a CU7.
Solução de contorno:
O primeiro ponto, é saber se a CU6 foi aplicada em todos os Exchange da organização, e se todos possuem o mesmo erro de falta do certificado OAuth. Para isso, rode o seguinte comando em todos os Exchanges, e veja se o erro sucede em todos:
Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint
- Caso exista algum Exchange na organizaçao no qual o certificado esteja integro, realize o export do certificado e importe em todos os Exchange que ocorre o erro.
- Caso o certificado exista em todos os servidores mesmo os que foram aplicados o CU6, e mesmo assim o erro persiste, verifique o diretório Exchange Back End no IIS e certifique-se que o site OWA e ECP contenham o certificado OAuth associado:
- No caso de nenhum Exchange na organização com o certificado valido, realize o seguinte procedimento:
1 – Crie um novo certificado OAuth com o seguinte comando:
New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName "contoso.com"
Nota: o parâmetro DomainName deve ser o endereço SMTP dos usuários, por exemplo “empresa.com.br”. Outro ponto é que ao rodar o comando, ele pedira para atribuir o serviço de IIS ao certificado, substituindo assim o atual certificado. Particularmente eu NÃO substitui, apesar de o artigo da Microsoft não mencionar nada sobre isso.
2 – Execute os seguintes comandos:
Set-AuthConfig -NewCertificateThumbprint <ThumbprintFromStep1> -NewCertificateEffectiveDate (Get-Date)
Set-AuthConfig –PublishCertificate
Set-AuthConfig -ClearPreviousCertificate
Nota: O Thumbprint será o mesmo do certificado criado no Step 1.
Nota: No artigo da Microsoft o primeiro comando esta errado, possuindo um “new” no início. O correto é Set.
3 – Realize o restart do servido Microsoft Exchange Service Host em todos os Exchanges da organizaçao.
4 – Realize os seguintes comandos em todos os Exchange da organização:
Restart-WebAppPool MSExchangeOWAAppPool
Restart-WebAppPool MSExchangeECPAppPool
Nota: No artigo da Microsoft é informado que a publicação pode ocorrer em media de uma hora. Na minha experiência, demorou em torno de uma hora e meia. Portanto sugiro que seja realizado a modificação, e se aguarde ao menos duas horas para se realizar qualquer outro procedimento em seguida.
Uma observação, se o ambiente é coexistente com 2010 ou 2013, os usuários de Exchange legados conseguem acessar normalmente o OWA, independentemente se o 2016 CU6 está fazendo proxy. Portanto apenas os usuários hospedados em databases do Exchange CU6 serão afetados.