Compartir a través de

Configuración del proxy de notificaciones de inserción para OWA para dispositivos

  • Artículo

Se aplica a: Exchange Server 2013

La habilitación de notificaciones push para OWA para dispositivos (OWA para iPhone y OWA para iPad) para una implementación local de Microsoft Exchange 2013 permite a un usuario recibir actualizaciones en el icono de Outlook Web App en su OWA para iPhone y OWA para iPad que indica el número de mensajes no observados en la bandeja de entrada del usuario. Si las notificaciones de inserción no se configuran ni se habilitan, un usuario que tenga OWA para dispositivos no podrá saber que tiene mensajes no leídos en la bandeja de entrada a menos que inicie la aplicación. Cuando se recibe un nuevo mensaje, la notificación de OWA para dispositivos se actualiza en el dispositivo del usuario, con un aspecto similar a este.

Distintivo de OWA para dispositivos.

¿Cómo habilitar las notificaciones de inserción?

Para habilitar las notificaciones push, los servidores locales de Exchange 2013 deben conectarse a Microsoft 365 o Office 365 Servicio de notificaciones push para enviar notificaciones push a iPhones e iPad. Los servidores locales de Exchange 2013 enrutan sus notificaciones de actualización a través de los servicios de notificaciones de Microsoft 365 o Office 365 para eliminar la necesidad de inscribir cuentas de desarrollador con servicios de notificaciones push de terceros. En este diagrama te mostramos el proceso que permite que los usuarios de iPhone e iPad reciban actualizaciones en las notificaciones para mensajes no leídos.

Proceso de notificaciones push.

Para habilitar las notificaciones de inserción, el administrador tiene que hacer esto:

  1. Inscriba su organización en Microsoft 365 o Office 365.

  2. Actualizar todos los servidores locales a la actualización acumulativa 3 (CU3) de Exchange Server 2013 o una versión posterior.

  3. Configure Exchange 2013 local en Microsoft 365 o Office 365 Authentication.

  4. Habilite las notificaciones push desde el Exchange Server 2013 local a Microsoft 365 o Office 365 y compruebe que las notificaciones push funcionan.

Inscriba su organización en Microsoft 365 o Office 365

Microsoft 365 y Office 365 son servicios basados en la nube que están diseñados para ayudar a satisfacer las necesidades de su organización para una sólida seguridad, confiabilidad y productividad del usuario. Varios planes de suscripción disponibles incluyen acceso a aplicaciones de Office y otros servicios de productividad habilitados a través de Internet (servicios en la nube), como conferencias web de Lync y Exchange Online correo electrónico hospedado para empresas.

Muchos planes de Microsoft 365 y Office 365 también incluyen la versión de escritorio de las aplicaciones de Office más recientes, que los usuarios pueden instalar en varios equipos y dispositivos. Todos los planes de Microsoft 365 y Office 365 se pagan por suscripción, mensual o anualmente. Para obtener más información o inscribirse en Office 365 para su organización, consulte ¿Qué es Microsoft 365 para empresas?. Para obtener más información sobre cada uno de los servicios ofrecidos a través de Microsoft 365 y Office 365, consulte Descripciones de servicios de Microsoft 365 y Office 365.

Actualizar a CU3 o posterior

La actualización acumulativa 3 (CU3) para Exchange Server 2013 resuelve problemas encontrados en Exchange Server 2013 desde que se lanzó el software en la versión RTM. Contiene todos los problemas y correcciones de CU1 y CU2, e incluye otras correcciones y actualizaciones desde el lanzamiento de CU2. Esta actualización es muy recomendable para todos los clientes locales de Exchange Server 2013, aunque es necesaria para las notificaciones de inserción. Si quiere conocer mejor las actualizaciones acumulativas, incluida la CU3, vea Actualizaciones para Exchange 2013.

Configuración de Exchange 2013 local en Microsoft 365 o Office 365 Authentication

Un único método estandarizado para la autenticación de servidor a servidor es el enfoque que usa Exchange Server 2013. Exchange Server 2013 (y Lync Server 2013 y SharePoint 2013) y Office 2013 admiten el protocolo OAuth (autorización abierta) para la autenticación y autorización de servidor a servidor. Con OAuth, un protocolo de autorización estándar usado por muchos sitios web principales, las credenciales de usuario y las contraseñas no se pasan de un equipo a otro. En su lugar, la autenticación y la autorización se basan en los tokens de seguridad de OAuth; estos tokens conceden acceso a un conjunto específico de recursos durante un período de tiempo específico.

La autenticación de OAuth suele implicar tres componentes: un único servidor de autorización y los dos dominios que necesitan comunicarse entre sí. Los tokens de seguridad los emite el servidor de autorización (también conocido como servidor de tokens de seguridad) a los dos dominios que necesitan comunicarse; estos tokens comprueban que el otro dominio debe confiar en las comunicaciones que se originaron desde un dominio. Por ejemplo, el servidor de autorización podría emitir tokens que comprueben que los usuarios de un dominio específico de Lync Server 2013 pueden acceder a un dominio de Exchange 2013 especificado y viceversa.

Sugerencia

Un dominio Kerberos actúa como un contenedor de seguridad.

Sin embargo, para la autenticación de servidor a servidor local no es necesario usar un servidor de tokens de terceros. Los productos de servidor, como Lync Server 2013 y Exchange 2013 tienen cada uno un servidor de tokens integrado que puede usarse para la autenticación con otros servidores Microsoft (como SharePoint Server) que admitan la autenticación de servidor a servidor. Por ejemplo, Lync Server 2013 puede emitir y firmar un token de seguridad por sí mismo, y después usarlo para comunicarse con Exchange 2013. En un caso como este, no es necesario un servidor de tokens de terceros.

Para configurar la autenticación de servidor a servidor para una implementación local de Exchange Server 2013 en Microsoft 365 o Office 365, debe completar dos pasos:

  • Paso 1: Asignar un certificado al emisor de tokens integrado del Exchange Server local: en primer lugar, un administrador de Exchange local debe usar el siguiente script del Shell de administración de Exchange para crear un certificado si no se creó antes y asignarlo al emisor de tokens integrado del Exchange Server local. Este proceso es un proceso único; después de crear un certificado, ese certificado debe reutilizarse para otros escenarios de autenticación y no reemplazarse. Asegúrese de actualizar el valor de $tenantDomain para que sea el nombre del dominio. Para ello, copie y pegue el siguiente código.

    Nota: Copiar y pegar el código en un editor de texto como el Bloc de notas y guardarlo con una extensión de .ps1 facilita la ejecución de scripts de 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."

    Los resultados deben ser similares a los resultados siguientes:

La huella digital del certificado configurada es: 7595DBDEA83DACB5757441D44899BCDB9911253C
Exportar certificado...
Íntegro.

Nota:

Antes de continuar, se requiere el módulo de Azure Active Directory para los cmdlets de Windows PowerShell. Si no se ha instalado el módulo de Azure Active Directory para cmdlets de Windows PowerShell (anteriormente conocido como módulo de Microsoft Online Services para Windows PowerShell), puede instalarlo desde Administrar Microsoft Entra ID mediante Windows PowerShell.

  • Paso 2: Configurar Microsoft 365 o Office 365 para comunicarse con Exchange 2013 local: Configure el servidor de Microsoft 365 o Office 365 con el que se comunica Exchange Server 2013 para que sea una aplicación asociada. Por ejemplo, si Exchange Server 2013 local necesita comunicarse con Microsoft 365 o Office 365, debe configurar Exchange local para que sea una aplicación asociada. Una aplicación de socio es cualquier aplicación con la que Exchange 2013 puede intercambiar directamente tokens de seguridad, sin tener que pasar por un servidor de tokens de seguridad de terceros. Un administrador local de Exchange 2013 debe usar el siguiente script del Shell de administración de Exchange para configurar Microsoft 365 o Office 365 organización con la que Exchange 2013 se comunica para que sea una aplicación asociada. Durante la ejecución, se le pedirá que escriba el nombre de usuario y la contraseña del administrador del dominio de la organización de Microsoft 365 o Office 365 (por ejemplo, administrator@fabrikam.com). Asegúrese de actualizar el valor de $CertFile a la ubicación del certificado si no se ha creado a partir del script anterior. Para ello, copie y pegue el siguiente 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."
}

    Los resultados deben ser similares a los resultados siguientes:

    Escriba el nombre de usuario y la contraseña del administrador del dominio de microsoft 365 o Office 365 organización...
    Agregar una clave a la entidad de servicio...
    Íntegro.

Habilitar la creación de conexiones proxy de notificaciones de inserción

Después de configurar correctamente la autenticación de OAuth siguiendo los pasos anteriores, un administrador local debe habilitar el proxy de notificaciones push mediante el siguiente script. Asegúrese de actualizar el valor de $tenantDomain para que sea el nombre del dominio. Para ello, copie y pegue el siguiente código.

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

El resultado esperado debe ser similar a la salida siguiente:

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

Comprobar que las notificaciones de inserción funcionan

Una vez completados los pasos anteriores, una de las siguientes opciones prueba las notificaciones push:

  • Enviar un mensaje de correo electrónico de prueba al buzón de correo del usuario:

    1. Configure una cuenta en OWA para dispositivos en un dispositivo móvil para suscribirse a las notificaciones.

    2. Vuelva a la pantalla de inicio del dispositivo, que pone OWA para dispositivos en segundo plano.

    3. Envíe un mensaje de correo electrónico desde otro dispositivo, como un equipo de sobremesa, dirigido a la bandeja de entrada de la cuenta configurada en el dispositivo móvil.

    4. El resultado debería ser una indicación con el recuento de mensajes no leídos en el icono de la aplicación en cuestión de pocos minutos.

  • Habilitación de la supervisión. Una alternativa para probar las notificaciones de inserción, o para investigar por qué se producen errores, consiste en habilitar la supervisión en un servidor de buzones de correo de la organización. Un administrador del servidor Exchange 2013 local debe usar este script para invocar la supervisión del proxy de notificaciones de inserción. Para ello, copie y pegue el siguiente 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."
}

    El resultado esperado debe ser similar a la salida siguiente:

    ResultType: correcto
    Error:
    Excepción: