Configurar o uso de proxy para notificações por push para o OWA para dispositivos

Artigo
02/27/2024

Aplica-se a: Exchange Server 2013

Habilitar notificações por push para OWA for Devices (OWA para iPhone e OWA para iPad) para uma implantação local do Microsoft Exchange 2013 permite que um usuário receba atualizações no ícone Outlook Web App em sua OWA para iPhone e OWA para iPad indicando o número de mensagens invisíveis na caixa de entrada do usuário. Se as notificações por push não forem configuradas nem habilitadas, o usuário que tiver o OWA para dispositivos não saberá se há mensagens não lidas na caixa de correio a menos que ele inicie o aplicativo. Quando uma nova mensagem fica disponível, o selo do OWA para dispositivos é atualizado no dispositivo do usuário e fica com essa aparência.

Selo OWA para Dispositivos.

Como faço para habilitar notificações por push?

Para habilitar notificações por push, os servidores locais do Exchange 2013 devem se conectar ao Microsoft 365 ou Office 365 Serviço de Notificação por Push para enviar notificações por push para iPhones e iPads. Os servidores locais do Exchange 2013 roteam suas notificações de atualização por meio dos serviços de notificação do Microsoft 365 ou Office 365 para remover a necessidade de registrar contas de desenvolvedor com serviços de notificação por push de terceiros. O diagrama a seguir mostra o processo pelo qual os usuários do iPhone e do iPad podem obter atualizações por selo para mensagens não lidas.

Processo para Notificações por Push.

Para habilitar notificações por push, o administrador tem que:

Registre sua organização no Microsoft 365 ou Office 365.
Atualizar todos os servidores no local para a Atualização Cumulativa 3 (CU3) ou superior do Exchange Server 2013.
Configure o Exchange local 2013 para o Microsoft 365 ou Office 365 Autenticação.
Habilite notificações por push do Exchange Server local de 2013 para o Microsoft 365 ou Office 365 e verifique se as notificações por push estão funcionando.

Registrar sua organização no Microsoft 365 ou Office 365

O Microsoft 365 e Office 365 são serviços baseados em nuvem projetados para ajudar a atender às necessidades da sua organização para segurança robusta, confiabilidade e produtividade do usuário. Vários planos de assinatura disponíveis incluem acesso a aplicativos do Office, além de outros serviços de produtividade habilitados pela Internet (serviços de nuvem), como a conferência Web do Lync e Exchange Online email hospedado para empresas.

Muitos planos do Microsoft 365 e Office 365 também incluem a versão da área de trabalho dos aplicativos mais recentes do Office, que os usuários podem instalar em vários computadores e dispositivos. Todos os planos do Microsoft 365 e Office 365 são pagos por assinatura, mensalmente ou anualmente. Para saber mais ou se inscrever em Office 365 para sua organização, confira O que é o Microsoft 365 para empresas?. Para saber mais sobre cada um dos serviços oferecidos por meio do Microsoft 365 e Office 365, confira Descrições do Serviço do Microsoft 365 e Office 365.

Atualizar para a CU3 ou superior

A Atualização Cumulativa 3 (CU3) para o Exchange Server 2013 soluciona problemas encontrados no Exchange Server 2013 desde o seu lançamento do software. Ela engloba todos os problemas e correções da CU1 e CU2 e inclui outras correções e atualizações desde que a CU2 foi lançada. Essa atualização é altamente recomendada para todos os clientes locais do Exchange Server 2013 e obrigatória para as notificações por push. Para ler mais sobre as atualizações cumulativas, incluindo a CU3, consulte Atualizações para o Exchange 2013.

Configurar o Exchange Local 2013 para a Autenticação do Microsoft 365 ou Office 365

Um método único e padronizado para autenticação servidor a servidor é a abordagem usada pelo Exchange Server 2013. Exchange Server 2013 (e o Lync Server 2013 e o SharePoint 2013) e o Office 2013 dão suporte ao protocolo OAuth (Autorização Aberta) para autenticação e autorização de servidor para servidor. Com o OAuth, um protocolo de autorização padrão usado por muitos sites importantes, credenciais de usuário e senhas não são passados de um computador para outro. Em vez disso, a autenticação e a autorização são baseadas nos tokens de segurança OAuth; esses tokens concedem acesso a um conjunto específico de recursos por um período específico de tempo.

A autenticação OAuth normalmente envolve três componentes: um único servidor de autorização e os dois reinos que precisam se comunicar entre si. Os tokens de segurança são emitidos pelo servidor de autorização (também conhecido como servidor do token de segurança) para os dois realms que precisam se comunicar; esse tokens verificam se as comunicações originadas de um realm devem ser confiadas pelo outro realm. Por exemplo, o servidor de autorização pode emitir tokens que verificam se usuários de um domínio específico do Lync Server 2013 podem acessar um reino especificado do Exchange 2013 e vice-versa.

Dica

Um realm é um contêiner de segurança.

No entanto, para autenticação local de servidor para servidor, não há necessidade de usar um servidor de token de terceiros. Produtos de servidor, como o Lync Server 2013 e o Exchange 2013 têm um servidor de token integrado que pode ser usado para fins de autenticação com outros servidores da Microsoft (como o SharePoint Server) que oferecem suporte à autenticação de servidor para servidor. Por exemplo, o Lync Server 2013 pode ele mesmo gerar e assinar um token de segurança e usá-lo para se comunicar com o Exchange 2013. Em um caso como esse, não há necessidade de um servidor de token de terceiros.

Para configurar a autenticação servidor a servidor para uma implementação local do Exchange Server 2013 para o Microsoft 365 ou Office 365, você deve concluir duas etapas:

Etapa 1 – Atribuir um certificado ao emissor de token interno do Exchange Server local: primeiro, um administrador do Exchange local deve usar o seguinte script do Exchange Management Shell para criar um certificado se um não tiver sido criado antes e atribuí-lo ao emissor de token interno do Exchange Server local. Esse processo é um processo único; depois que um certificado for criado, esse certificado deve ser reutilizado para outros cenários de autenticação e não substituído. Certifique-se de atualizar o valor de $tenantDomain com o nome do seu domínio. Para fazer isso, copie e cole o seguinte código.

Observação: copiar e colar o código em um editor de texto como o Bloco de Notas e salvá-lo com uma extensão .ps1 facilita a execução de scripts do Shell.

# Make sure to update the following $tenantDomain with your Microsoft 365 or Office 365 organization domain.

$tenantDomain = "Fabrikam.com"

# Check whether the cert returned from Get-AuthConfig is valid and keysize must be >= 2048

$c = Get-ExchangeCertificate | ?{$_.CertificateDomains -eq $env:USERDNSDOMAIN -and $_.Services -ge "SMTP" -and $_.PublicKeySize -ge 2048 -and $_.FriendlyName -match "OAuth"}
If ($c.Count -eq 0)
{
    Write-Host "Creating certificate for oAuth..."
    $ski = [System.Guid]::NewGuid().ToString("N")
    $friendlyName = "Exchange S2S OAuth"
    New-ExchangeCertificate -FriendlyName $friendlyName -DomainName $env:USERDNSDOMAIN -Services Federation -KeySize 2048 -PrivateKeyExportable $true -SubjectKeyIdentifier $ski
    $c = Get-ExchangeCertificate | ?{$_.friendlyname -eq $friendlyName}
}
ElseIf ($c.Count -gt 1)
{
    $c = $c[0]
}

$a = $c | ?{$_.Thumbprint -eq (get-authconfig).CurrentCertificateThumbprint}
If ($a.Count -eq 0)
{
    Set-AuthConfig -CertificateThumbprint $c.Thumbprint
}
Write-Host "Configured Certificate Thumbprint is:"(get-authconfig).CurrentCertificateThumbprint

# Export the certificate

Write-Host "Exporting certificate..."
if((test-path $env:SYSTEMDRIVE\OAuthConfig) -eq $false)
{
    md $env:SYSTEMDRIVE\OAuthConfig
}
cd $env:SYSTEMDRIVE\OAuthConfig

$oAuthCert = (dir Cert:\LocalMachine\My) | where {$_.FriendlyName -match "OAuth"}
$certType = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
$certBytes = $oAuthCert.Export($certType)
$CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
[System.IO.File]::WriteAllBytes($CertFile, $certBytes)

# Set AuthServer
$authServer = Get-AuthServer MicrosoftSts;
if ($authServer.Length -eq 0)
{
    Write-Host "Creating AuthServer Config..."
    New-AuthServer MicrosoftSts -AuthMetadataUrl https://accounts.accesscontrol.windows.net/metadata/json/1/?realm=$tenantDomain
}
elseif ($authServer.AuthMetadataUrl -ne "https://accounts.accesscontrol.windows.net/metadata/json/1/?realm=$tenantDomain")
{
    Write-Warning "AuthServer config already exists but the AuthMetdataUrl doesn't match the appropriate value. Updating..."
    Set-AuthServer MicrosoftSts -AuthMetadataUrl https://accounts.accesscontrol.windows.net/metadata/json/1/?realm=$tenantDomain
}
else
{
    Write-Host "AuthServer Config already exists."
}
Write-Host "Complete."

Os resultados devem se assemelhar à seguinte saída:

Impressão digital de certificado configurada é: 7595DBDEA83DACB5757441D44899BCDB9911253C
Exportando certificado...
Completa.

Observação

Antes de continuar, o módulo do Azure Active Directory para cmdlets Windows PowerShell é necessário. Se o módulo do Azure Active Directory para cmdlets Windows PowerShell (anteriormente conhecido como Módulo de Serviços Online da Microsoft para Windows PowerShell) não tiver sido instalado, você poderá instalá-lo de Gerenciar Microsoft Entra ID usando Windows PowerShell.

Etapa 2 – Configurar o Microsoft 365 ou Office 365 para se comunicar com o Exchange 2013 local: configure o servidor microsoft 365 ou Office 365 com o qual Exchange Server 2013 se comunica para ser um aplicativo parceiro. Por exemplo, se Exchange Server 2013 local precisar se comunicar com o Microsoft 365 ou Office 365, você precisará configurar o Exchange local para ser um aplicativo parceiro. Um aplicativo parceiro é qualquer aplicativo com o qual o Exchange 2013 pode trocar diretamente tokens de segurança, sem precisar passar por um servidor de token de segurança de terceiros. Um administrador local do Exchange 2013 deve usar o script do Shell de Gerenciamento do Exchange a seguir para configurar a organização microsoft 365 ou Office 365 com a qual o Exchange 2013 se comunica para ser um aplicativo parceiro. Durante a execução, um prompt para inserir o nome de usuário do administrador e a senha do domínio da organização do Microsoft 365 ou Office 365 (por exemplo, administrator@fabrikam.com). Atualize o valor de $CertFile para o local do certificado se não for criado do script anterior. Para fazer isso, copie e cole o seguinte código.
```
# Make sure to update the following $CertFile with the path to the cert if not using the previous script.

$CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"

If (Test-Path $CertFile)
{
    $ServiceName = "00000002-0000-0ff1-ce00-000000000000";

    $objFSO = New-Object -ComObject Scripting.FileSystemObject;
    $CertFile = $objFSO.GetAbsolutePathName($CertFile);

    $cer = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($CertFile)
    $binCert = $cer.GetRawCertData();
    $credValue = [System.Convert]::ToBase64String($binCert);

    Write-Host "Please enter the administrator username and password of the Microsoft 365 or Office 365 organization domain..."

    Write-Host "Adding a key to Service Principal..."

    $p = Get-MgServicePrincipal -Filter "AppId eq '$ServiceName'"
    $params = @{
      keyCredential = @{
          type = "AsymmetricX509Cert"
          usage = "Verify"
          key = $credValue
          endDateTime = $cer.GetExpirationDateString()
          startDateTime = $cer.GetEffectiveDateString()
      }
    }

    Add-MgServicePrincipalKey -ServicePrincipalId $p.Id -BodyParameter $params

}
Else
{
    Write-Error "Cannot find certificate."
}
```
Os resultados devem se assemelhar à seguinte saída:

Insira o nome de usuário do administrador e a senha do domínio da organização do Microsoft 365 ou Office 365...
Adicionando uma chave à Entidade de Serviço...
Completa.

Habilitar o uso de proxy para as notificações por push

Depois que a autenticação OAuth for configurada com êxito seguindo as etapas anteriores, um administrador local deve habilitar o proxy de notificação por push usando o script a seguir. Certifique-se de atualizar o valor de $tenantDomain com o nome do seu domínio. Para fazer isso, copie e cole o seguinte código.

$tenantDomain = "Fabrikam.com"
Enable-PushNotificationProxy -Organization:$tenantDomain

O resultado esperado deve ser semelhante à seguinte saída:

RunspaceId        : 4f2eb5cc-b696-482f-92bb-5b254cd19d60
DisplayName       : On Premises Proxy app
Enabled           : True
Organization      : fabrikam.com
Uri               : https://outlook.office365.com/PushNotifications
Identity          : OnPrem-Proxy
IsValid           : True
ExchangeVersion   : 0.20 (15.0.0.0)
Name              : OnPrem-Proxy
DistinguishedName : CN=OnPrem-Proxy,CN=Push Notifications Settings,CN=First Organization,CN=Microsoft
                    Exchange,CN=Services,CN=Configuration,DC=Domain,DC=extest,DC=microsoft,DC=com
Guid              : 8b567958-58a4-403c-a8f0-524d7f1e9279
ObjectCategory    : fabrikam.com/Configuration/Schema/ms-Exch-Push-Notifications-App
ObjectClass       : {top, msExchPushNotificationsApp}
WhenChanged       : 8/27/2013 7:23:47 PM
WhenCreated       : 8/14/2013 1:30:27 PM
WhenChangedUTC    : 8/28/2013 2:23:47 AM
WhenCreatedUTC    : 8/14/2013 8:30:27 PM
OrganizationId    :
OriginatingServer : server.fabrikam.com
ObjectState       : Unchanged

Verifique se as notificações por push estão funcionando

Após a conclusão das etapas anteriores, as notificações por push são testadas por um dos seguintes procedimentos:

Enviando uma mensagem de email de teste para a caixa de correio do usuário:
1. Configure uma conta do OWA para Dispositivos em um dispositivo móvel para se inscrever nas notificações.
2. Retorne à tela inicial do dispositivo com o OWA para Dispositivos em segundo plano.
3. Envie uma mensagem de email a partir de outro dispositivo, como um computador, para a caixa de entrada da conta configurada no dispositivo móvel.
4. Após alguns minutos, essa mensagem gerará uma contagem de mensagem não vista indicada no ícone do aplicativo.

Habilitando o monitoramento. Como método alternativo para testar as notificações por push, ou para investigar o motivo de falhas nas notificações, habilite o monitoramento em um servidor de caixa de correio em sua organização. Os administradores de servidor do Exchange 2013 local devem invocar o monitoramento de proxy das notificações por push usando o seguinte script. Para fazer isso, copie e cole o seguinte código.

# Send a push notification to verify connectivity.

$s = Get-ExchangeServer | ?{$_.ServerRole -match "Mailbox"}
If ($s.Count -gt 1)
{
    $s = $s[0]
}
If ($s.Count -ne 0)
{
    # Restart the monitoring service to clear the cache from when push was previously disabled.
    Restart-Service MSExchangeHM

    # Give the monitoring service enough time to load.
    Start-Sleep -Seconds:120

    Invoke-MonitoringProbe PushNotifications.Proxy\PushNotificationsEnterpriseConnectivityProbe -Server:$s.Fqdn | fl ResultType, Error, Exception
}
Else
{
    Write-Error "Cannot find a Mailbox server in the current site."
}