Konfigurieren von Proxyfunktionen für Pushbenachrichtigungen in OWA for Devices

Artikel
03/05/2024

Gilt für: Exchange Server 2013

Wenn Sie Pushbenachrichtigungen für OWA für Geräte (OWA für iPhone und OWA für iPad) für eine lokale Bereitstellung von Microsoft Exchange 2013 aktivieren, erhalten Benutzer Updates auf dem Outlook Web App Symbol auf ihrem OWA für iPhone und OWA für iPad, das die Anzahl der nicht angezeigten Nachrichten im Posteingang des Benutzers angibt. Wenn Pushbenachrichtigungen nicht konfiguriert und aktiviert sind, ist ein OWA für Geräte-Benutzer nicht in der Lage, ungelesene Nachrichten in seinem Posteingang zu erkennen, ohne die App zu starten. Wenn eine neue Nachricht verfügbar ist, wird das OWA für Geräte-Badge auf dem Gerät des Benutzers aktualisiert und sieht folgendermaßen aus.

Badge für OWA für Geräte.

Wie aktivieren Sie Pushbenachrichtigungen?

Um Pushbenachrichtigungen zu aktivieren, müssen die lokalen Exchange 2013-Server eine Verbindung mit dem Microsoft 365- oder Office 365 Pushbenachrichtigungsdienst herstellen, um Pushbenachrichtigungen an iPhones und iPads zu senden. Lokale Exchange 2013-Server leiten ihre Updatebenachrichtigungen über die Microsoft 365- oder Office 365-Benachrichtigungsdienste weiter, um die Registrierung von Entwicklerkonten bei Pushbenachrichtigungsdiensten von Drittanbietern zu entfernen. Im folgenden Diagramm wird aufgezeigt, wie der Prozess zum Abrufen von Badge-Updates zum Anzeigen neuer Nachrichten für das iPhone und iPad funktioniert.

Prozess für Pushbenachrichtigungen.

Um Push-Benachrichtigungen zu aktivieren, muss der Administrator:

Registrieren Sie Ihre organization bei Microsoft 365 oder Office 365.
Aktualisieren Sie alle lokalen Server auf die Version Exchange Server 2013 Kumulatives Update 3 (CU3) oder höher.
Richten Sie lokale Exchange 2013 für Microsoft 365 oder Office 365-Authentifizierung ein.
Aktivieren Sie Pushbenachrichtigungen vom lokalen Exchange Server 2013 an Microsoft 365 oder Office 365, und überprüfen Sie, ob Pushbenachrichtigungen funktionieren.

Registrieren Ihrer organization in Microsoft 365 oder Office 365

Microsoft 365 und Office 365 sind cloudbasierte Dienste, die den Anforderungen Ihrer organization an robuste Sicherheit, Zuverlässigkeit und Benutzerproduktivität gerecht werden. Verschiedene verfügbare Abonnementpläne umfassen den Zugriff auf Office-Anwendungen sowie andere Produktivitätsdienste, die über das Internet (Clouddienste) aktiviert sind, z. B. Lync-Webkonferenzen und Exchange Online gehostete E-Mail für Unternehmen.

Viele Microsoft 365- und Office 365-Pläne enthalten auch die Desktopversion der neuesten Office-Anwendungen, die Benutzer auf mehreren Computern und Geräten installieren können. Alle Microsoft 365- und Office 365-Pläne werden monatlich oder jährlich auf Abonnementbasis bezahlt. Weitere Informationen oder eine Registrierung bei Office 365 für Ihre organization finden Sie unter Was ist Microsoft 365 Business?. Weitere Informationen zu den einzelnen Diensten, die über Microsoft 365 und Office 365 angeboten werden, finden Sie unter Microsoft 365 und Office 365 Dienstbeschreibungen.

Aktualisieren Sie auf CU3 oder höher

Das kumulative Update 3 (CU3) für Exchange Server 2013 behebt Probleme, die in Exchange Server 2013 seit Veröffentlichung der RTM gefunden wurden. Es enthält alle Korrekturen von CU1 und CU2 sowie weitere Korrekturen und Aktualisierungen, die seit Veröffentlichung von CU2 bereitgestellt wurden. Dieses Update wird dringend für alle Kunden empfohlen, die einen lokalen Exchange Server 2013 einsetzen, außerdem ist es für Pushbenachrichtigungen erforderlich. Informationen zu kumulativen Updates, einschließlich CU3, finden Sie unter Updates für Exchange 2013.

Einrichten der lokalen Exchange 2013-Authentifizierung mit Microsoft 365 oder Office 365-Authentifizierung

Eine einzelne, standardisierte Methode für die Server-zu-Server-Authentifizierung ist der ansatz, der von Exchange Server 2013 verwendet wird. Exchange Server 2013 (sowie Lync Server 2013 und SharePoint 2013) und Office 2013 unterstützen das OAuth-Protokoll (Open Authorization) für die Server-zu-Server-Authentifizierung und -Autorisierung. Bei OAuth, einem Standardautorisierungsprotokoll, das von vielen wichtigen Websites verwendet wird, werden Benutzeranmeldeinformationen und Kennwörter nicht von einem Computer an einen anderen übergeben. Stattdessen basieren Authentifizierung und Autorisierung auf den OAuth-Sicherheitstoken; diese Token gewähren für einen bestimmten Zeitraum den Zugriff auf einen bestimmten Satz an Ressourcen.

OAuth-Authentifizierung umfasst normalerweise drei Komponenten: einen Server mit Einzelanmeldung und zwei Bereiche, die miteinander kommunizieren müssen. Sicherheitstoken werden vom Authorisierungsserver (auch als Sicherheitstokenserver bezeichnet) an die zwei Bereiche ausgegeben, die kommunizieren müssen; diese Token prüfen, ob die Kommunikation des einen Bereichs für den anderen Bereich vertrauenswürdig ist. Der Authorisierungsserver kann beispielsweise Token ausgeben, die prüfen, ob Benutzer von einem bestimmten Bereich von Lync Server 2013 auf einen bestimmten Bereich von Exchange 2013 zugreifen können und umgekehrt.

Tipp

Ein Bereich ist ein Container für die Sicherheit.

Für die lokale Server-zu-Server-Authentifizierung ist es jedoch nicht erforderlich, einen Tokenserver eines Drittanbieters zu verwenden. Serverprodukte wie Lync Server 2013 und Exchange 2013 verfügen über einen integrierten Tokenserver, der zu Authentifizierungszwecken mit anderen Microsoft-Servern (z. B. SharePoint-Server) verwendet werden kann, die die Server-zu-Server-Authentifizierung unterstützen. Lync Server 2013 kann beispielsweise alleine ein Sicherheitstoken ausgeben und signieren, sowie dieses Token anschließend zum Kommunizieren mit Exchange 2013 einsetzen. In einem solchen Fall ist kein Tokenserver eines Drittanbieters erforderlich.

Um die Server-zu-Server-Authentifizierung für eine lokale Implementierung von Exchange Server 2013 in Microsoft 365 oder Office 365 zu konfigurieren, müssen Sie zwei Schritte ausführen:

Schritt 1: Zuweisen eines Zertifikats zum integrierten Tokenaussteller des lokalen Exchange Server: Zunächst muss ein lokaler Exchange-Administrator das folgende Exchange-Verwaltungsshell-Skript verwenden, um ein Zertifikat zu erstellen, sofern es noch nicht erstellt wurde, und es dem integrierten Tokenaussteller des lokalen Exchange Server zuweisen. Dieser Prozess ist ein einmaliger Prozess; Nachdem ein Zertifikat erstellt wurde, sollte dieses Zertifikat für andere Authentifizierungsszenarien wiederverwendet und nicht ersetzt werden. Achten Sie darauf, den Wert von $tenantDomain so zu aktualisieren, dass er der Name Ihrer Domäne ist. Dazu kopieren Sie und fügen Sie den folgenden Code ein.

Hinweis: Das Kopieren und Einfügen des Codes in einen Text-Editor wie Editor und das Speichern mit einer .ps1-Erweiterung erleichtert die Ausführung von Shellskripts.

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

Die Ergebnisse sollten der folgenden Ausgabe ähneln:

Konfigurierter Zertifikatfingerabdruck: 7595DBDEA83DACB5757441D44899BCDB9911253C
Zertifikat wird exportiert...
Vollständig.

Hinweis

Bevor Sie fortfahren, ist das Azure Active Directory-Modul für Windows PowerShell Cmdlets erforderlich. Wenn das Azure Active Directory-Modul für Windows PowerShell-Cmdlets (zuvor als Microsoft Online Services-Modul für Windows PowerShell bezeichnet) nicht installiert wurde, können Sie es über Verwalten von Microsoft Entra ID mithilfe von Windows PowerShell installieren.

Schritt 2: Konfigurieren von Microsoft 365 oder Office 365 für die Kommunikation mit Exchange 2013 lokal: Konfigurieren Sie den Microsoft 365- oder Office 365-Server, mit dem Exchange Server 2013 kommuniziert, als Partneranwendung. Wenn beispielsweise Exchange Server 2013 lokal mit Microsoft 365 oder Office 365 kommunizieren muss, müssen Sie Exchange lokal als Partneranwendung konfigurieren. Bei einer Partneranwendung handelt es sich um eine Anwendung, die direkt Sicherheitstoken mit Exchange 2013 austauscht, ohne dafür einen Sicherheitstokenserver eines Drittanbieters verwenden zu müssen. Ein lokaler Exchange 2013-Administrator muss das folgende Exchange-Verwaltungsshell-Skript verwenden, um die Microsoft 365 oder Office 365 organization zu konfigurieren, mit der Exchange 2013 als Partneranwendung kommuniziert. Während der Ausführung wird eine Aufforderung zur Eingabe des Administratorbenutzernamens und des Kennworts der Microsoft 365- oder Office 365 organization-Domäne (z. Badministrator@fabrikam.com. ) ausgeführt. Stellen Sie sicher, den Wert der $CertFile auf den Speicherort des Zertifikats zu aktualisieren, falls dies noch nicht mit dem vorherigen Skript geschehen ist. Dazu kopieren Sie und fügen Sie den folgenden Code ein.
```
# 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."
}
```
Die Ergebnisse sollten der folgenden Ausgabe ähneln:

Geben Sie den Benutzernamen und das Kennwort des Administrators der Microsoft 365- oder Office 365 organization-Domäne ein...
Hinzufügen eines Schlüssels zum Dienstprinzipal...
Vollständig.

Aktivieren der Proxyfunktion für Pushbenachrichtigungen

Nachdem die OAuth-Authentifizierung nach den vorherigen Schritten erfolgreich eingerichtet wurde, muss ein lokaler Administrator das Proxying für Pushbenachrichtigungen mithilfe des folgenden Skripts aktivieren. Achten Sie darauf, den Wert von $tenantDomain so zu aktualisieren, dass er der Name Ihrer Domäne ist. Dazu kopieren Sie und fügen Sie den folgenden Code ein.

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

Das erwartete Ergebnis sollte der folgenden Ausgabe ähneln:

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

Prüfen Sie die Pushbenachrichtigungen

Nachdem die vorherigen Schritte abgeschlossen sind, werden Pushbenachrichtigungen mit einer der folgenden Tests getestet:

Senden einer e-Mail-Testnachricht an das Postfach des Benutzers:
1. Richten Sie auf einem mobilen Gerät ein Konto in OWA for Devices ein, um die Benachrichtigungen zu abonnieren.
2. Kehren Sie auf den Startbildschirm des Geräts zurück, sodass OWA for Devices in den Hintergrund verschoben wird.
3. Senden Sie eine E-Mail-Nachricht von einem anderen Gerät, z. B. einem PC, die an den Posteingang des auf dem mobilen Gerät eingerichteten Kontos gesendet wird.
4. In einigen Augenblicken sollte am App-Symbol eine Anzahl ungelesener Nachrichten angezeigt werden.

Aktivieren der Überwachung. Eine alternative Methode zum Testen von Pushbenachrichtigungen oder zur Untersuchung der Gründe, warum Benachrichtigungen fehlschlagen, ist das Aktivieren der Überwachung auf einem Postfachserver in Ihrem organization. Ein lokaler Exchange 2013-Serveradministrator muss die Überwachung des Pushbenachrichtigungsproxys mithilfe des folgenden Skripts aufrufen. Dazu kopieren Sie und fügen Sie den folgenden Code ein.

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