Configuration de l’envoi par proxy de notifications Push pour OWA pour les périphériques

Article
02/27/2024

S’applique à : Exchange Server 2013

L’activation des notifications Push pour OWA pour les appareils (OWA pour iPhone et OWA pour iPad) pour un déploiement local de Microsoft Exchange 2013 permet à un utilisateur de recevoir des mises à jour sur l’icône Outlook Web App sur son OWA pour iPhone et OWA pour iPad indiquant le nombre de messages invisibles dans la boîte de réception de l’utilisateur. Si les notifications push ne sont ni configurées ni activées, un utilisateur disposant d'OWA pour les périphériques n'a aucun moyen de savoir si sa boîte de réception contient des messages non vus, sans lancer l'application. Quand un nouveau message est disponible, le badge OWA pour les périphériques est mis à jour sur le périphérique de l'utilisateur et ressemble au badge ci-après.

Badge OWA pour appareils.

Comment activer les notifications Push ?

Pour activer les notifications Push, les serveurs Exchange 2013 locaux doivent se connecter au service de notification Push Microsoft 365 ou Office 365 pour envoyer des notifications Push aux iPhones et iPad. Les serveurs locaux Exchange 2013 acheminent leurs notifications de mise à jour via les services de notification Microsoft 365 ou Office 365 pour supprimer la nécessité d’inscrire des comptes de développeur auprès de services de notification Push tiers. Le diagramme suivant montre comment les utilisateurs d’iPhone et d’iPad peuvent obtenir des mises à jour de badge pour les messages invisibles.

Processus pour les notifications Push.

Pour activer les notifications Push, l'administrateur doit effecteur les actions suivantes :

Inscrivez votre organization dans Microsoft 365 ou Office 365.
mettre à jour tous les serveurs sur site vers la mise à jour cumulative 3 (CU3) d'Exchange Server 2013 ou une version ultérieure ;
Configurez Exchange 2013 local sur Microsoft 365 ou l’authentification Office 365.
Activez les notifications Push du Exchange Server local 2013 vers Microsoft 365 ou Office 365 et vérifiez que les notifications Push fonctionnent.

Inscrire votre organization dans Microsoft 365 ou Office 365

Microsoft 365 et Office 365 sont des services cloud conçus pour répondre aux besoins de vos organization en matière de sécurité, de fiabilité et de productivité des utilisateurs. Les différents plans d’abonnement disponibles incluent l’accès aux applications Office ainsi qu’à d’autres services de productivité activés sur Internet (services cloud), tels que les conférences web Lync et les e-mails hébergés Exchange Online pour les entreprises.

De nombreuses offres Microsoft 365 et Office 365 incluent également la version de bureau des dernières applications Office, que les utilisateurs peuvent installer sur plusieurs ordinateurs et appareils. Tous les plans Microsoft 365 et Office 365 sont payés sur une base d’abonnement, mensuellement ou annuellement. Pour en savoir plus ou pour vous inscrire à Office 365 pour votre organization, consultez Qu’est-ce que Microsoft 365 pour les entreprises ?. Pour plus d’informations sur chacun des services proposés via Microsoft 365 et Office 365, consultez Descriptions des services Microsoft 365 et Office 365.

Effectuer une mise à jour vers CU3 ou version ultérieure

La mise à jour cumulative 3 (CU3) pour Exchange Server 2013 résout les problèmes détectés dans Exchange Server 2013 puisque le logiciel a été publié depuis la version de publication (RTM). Elle contient tous les problèmes et correctifs déjà présents dans CU1 et CU2, ainsi que d'autres correctifs et mises à jour postérieurs à la publication de CU2. Cette mise à jour est fortement recommandée pour tous les clients Exchange Server 2013 sur site, mais elle est obligatoire pour les notifications Push. Pour en savoir plus sur les mises à jour cumulatives, y compris CU3, voir Mises à jour pour Exchange 2013.

Configurer Exchange 2013 local sur Microsoft 365 ou l’authentification Office 365

L’approche utilisée par Exchange Server 2013 est une méthode standardisée unique pour l’authentification de serveur à serveur. Exchange Server 2013 (et Lync Server 2013 et SharePoint 2013) et Office 2013 prennent en charge le protocole OAuth (Open Authorization) pour l’authentification et l’autorisation de serveur à serveur. Avec OAuth, un protocole d’autorisation standard utilisé par de nombreux sites web principaux, les informations d’identification et les mots de passe des utilisateurs ne sont pas transmis d’un ordinateur à un autre. Au lieu de cela, l’authentification et l’autorisation sont basées sur les jetons de sécurité OAuth ; ces jetons accordent l’accès à un ensemble spécifique de ressources pendant un laps de temps spécifique.

L’authentification OAuth implique généralement trois composants : un serveur d’autorisation unique et les deux domaines qui doivent communiquer entre eux. Les jetons de sécurité sont émis par le serveur d’autorisation (également appelé serveur de jetons de sécurité) pour les deux domaines qui doivent communiquer ; ces jetons vérifient que les communications provenant d’un domaine doivent être approuvées par l’autre domaine. Par exemple, le serveur d’autorisation peut émettre des jetons qui vérifient que les utilisateurs d’un domaine Lync Server 2013 spécifique peuvent accéder à un domaine Exchange 2013 spécifié, et vice versa.

Conseil

Un domaine est un conteneur de sécurité.

Toutefois, pour l’authentification serveur à serveur local, il n’est pas nécessaire d’utiliser un serveur de jetons tiers. Les produits serveur tels que Lync Server 2013 et Exchange 2013 disposent chacun d'un serveur de jeton intégré qui peut être utilisé à des fins d'authentification avec d'autres serveurs Microsoft (tels que SharePoint Server) qui prennent en charge l'authentification de serveur à serveur. Par exemple, Lync Server 2013 peut émettre et signer un jeton de sécurité par lui-même, puis utiliser ce jeton pour communiquer avec Exchange 2013. Dans un cas comme celui-ci, il n’est pas nécessaire d’utiliser un serveur de jetons tiers.

Pour configurer l’authentification de serveur à serveur pour une implémentation locale de Exchange Server 2013 vers Microsoft 365 ou Office 365, vous devez effectuer deux étapes :

Étape 1 - Attribuer un certificat à l’émetteur de jeton intégré du Exchange Server local : Tout d’abord, un administrateur Exchange local doit utiliser le script Exchange Management Shell suivant pour créer un certificat s’il n’en a pas été créé auparavant et l’affecter à l’émetteur de jeton intégré du Exchange Server local. Ce processus est un processus unique ; une fois qu’un certificat a été créé, ce certificat doit être réutilisé pour d’autres scénarios d’authentification et non remplacé. Veillez à mettre à jour la valeur de $tenantDomain pour qu’elle soit le nom de votre domaine. Pour ce faire, copiez et collez le code suivant.

Remarque : la copie et le collage du code dans un éditeur de texte comme le Bloc-notes et son enregistrement avec une extension .ps1 facilite l’exécution des scripts 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."

Les résultats doivent ressembler à la sortie suivante :

L’empreinte du certificat configurée est : 7595DBDEA83DACB5757441D44899BCDB9911253C
Exportation du certificat...
Complet.

Remarque

Avant de continuer, le module Azure Active Directory pour les applets de commande Windows PowerShell est requis. Si le module Azure Active Directory pour les applets de commande Windows PowerShell (précédemment appelé module Microsoft Online Services pour Windows PowerShell) n’a pas été installé, vous pouvez l’installer à partir de Gérer Microsoft Entra ID à l’aide de Windows PowerShell.

Étape 2 : Configurer Microsoft 365 ou Office 365 pour communiquer avec Exchange 2013 en local : Configurez le serveur Microsoft 365 ou Office 365 avec lequel Exchange Server 2013 communique pour être une application partenaire. Par exemple, si Exchange Server 2013 en local doit communiquer avec Microsoft 365 ou Office 365, vous devez configurer Exchange local pour qu’il soit une application partenaire. Une application partenaire est une application avec laquelle Exchange 2013 peut directement échanger des jetons de sécurité, sans avoir à passer par un serveur de jeton de sécurité tiers. Un administrateur Exchange 2013 local doit utiliser le script Exchange Management Shell suivant pour configurer Microsoft 365 ou Office 365 organization avec lequel Exchange 2013 communique en tant qu’application partenaire. Pendant l’exécution, une invite à entrer le nom d’utilisateur et le mot de passe de l’administrateur du domaine Microsoft 365 ou Office 365 organization (par exemple, administrator@fabrikam.com). Veillez à mettre à jour la valeur de $CertFile à l’emplacement du certificat s’il n’est pas créé à partir du script précédent. Pour ce faire, copiez et collez le code suivant.
```
# 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."
}
```
Les résultats doivent ressembler à la sortie suivante :

Entrez le nom d’utilisateur et le mot de passe de l’administrateur du domaine Microsoft 365 ou Office 365 organization...
Ajout d’une clé au principal de service...
Complet.

Activer l’envoi par proxy de notifications Push

Une fois l’authentification OAuth correctement configurée en suivant les étapes précédentes, un administrateur local doit activer le proxy de notification Push à l’aide du script suivant. Veillez à mettre à jour la valeur de $tenantDomain pour qu’elle soit le nom de votre domaine. Pour ce faire, copiez et collez le code suivant.

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

Le résultat attendu doit être similaire à la sortie suivante :

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

Vérifier le fonctionnement des notifications Push

Une fois les étapes précédentes terminées, les notifications Push sont testées par l’un des éléments suivants :

Envoi d'un message électronique de test à la boîte aux lettres de l'utilisateur :
1. Configurez un compte sur un périphérique mobile dans OWA pour les périphériques afin de vous abonner aux notifications.
2. Revenez à l'écran d'accueil du périphérique, qui place OWA pour les périphériques en arrière-plan.
3. Envoyez un message électronique à partir d'un autre périphérique, comme un PC, à la boîte de réception du compte configuré sur le périphérique mobile.
4. Après quelques minutes, l'icône de l'application doit indiquer le nombre de message non vus.

Activation de la surveillance. Une autre méthode de test des notifications Push ou de recherche de la raison de l'échec des notifications consiste à activer le contrôle sur un serveur de boîtes aux lettres de votre organisation. Un administrateur du serveur Exchange 2013 sur site doit appeler le contrôle par proxy des notifications Push à l'aide du script suivant. Pour ce faire, copiez et collez le code suivant.

# 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."
}