Configurazione delle notifiche push che eseguono l'inoltro di OWA per i dispositivi

Articolo
04/04/2023

Si applica a: Exchange Server 2013

L'abilitazione delle notifiche push per OWA per dispositivi (OWA per iPhone e OWA per iPad) per una distribuzione locale di Microsoft Exchange 2013 consente a un utente di ricevere aggiornamenti sull'icona Outlook Web App nell'OWA per iPhone e OWA per iPad che indica il numero di messaggi non visualizzati nella posta in arrivo dell'utente. Se le notifiche push non sono configurate e abilitate, un utente con OWA per i dispositivi non può sapere in alcun modo quanti messaggi non letti sono presenti nella cartella Posta in arrivo, senza avviare l'app. Quando è disponibile un nuovo messaggio, il badge di OWA per i dispositivi viene aggiornato sul dispositivo dell'utente e avrà il seguente aspetto.

Badge di OWA per dispositivi.

Come è possibile attivare le notifiche push?

Per abilitare le notifiche push, i server Exchange 2013 locali devono connettersi a Microsoft 365 o al servizio di notifica push Office 365 per inviare notifiche push a iPhone e iPad. I server locali di Exchange 2013 instradano le notifiche di aggiornamento tramite i servizi di notifica Microsoft 365 o Office 365 per rimuovere la necessità di registrare account per sviluppatori con servizi di notifica push di terze parti. Il seguente diagramma illustra il processo relativo alla ricezione di aggiornamenti badge da parte di iPhone e iPad in merito ai messaggi non letti.

Processo per le notifiche push.

Per abilitare le notifiche push, l'amministratore deve effettuare le seguenti operazioni:

Registrare l'organizzazione in Microsoft 365 o Office 365.
Aggiornare tutti i server locali a Exchange Server 2013 Cumulative Update 3 (CU3) o a una versione successiva.
Configurare Exchange 2013 locale in Microsoft 365 o Office 365 Authentication.
Abilitare le notifiche push dal Exchange Server locale 2013 a Microsoft 365 o Office 365 e verificare che le notifiche push funzionino.

Registrare l'organizzazione in Microsoft 365 o Office 365

Microsoft 365 e Office 365 sono servizi basati sul cloud progettati per soddisfare le esigenze dell'organizzazione in materia di sicurezza, affidabilità e produttività degli utenti. Diversi piani di sottoscrizione disponibili includono l'accesso alle applicazioni di Office e altri servizi di produttività abilitati su Internet (servizi cloud), ad esempio conferenze Web lync e Exchange Online posta elettronica ospitata per le aziende.

Molti piani di Microsoft 365 e Office 365 includono anche la versione desktop delle applicazioni di Office più recenti, che gli utenti possono installare in più computer e dispositivi. Tutti i piani di Microsoft 365 e Office 365 vengono pagati su base di sottoscrizione, mensile o annuale. Per altre informazioni o per iscriversi a Office 365 per l'organizzazione, vedere Che cos'è Microsoft 365 per le aziende?. Per altre informazioni su ognuno dei servizi offerti tramite Microsoft 365 e Office 365, vedere Microsoft 365 e Office 365 Service Descriptions.For more about each of the services offered through Microsoft 365 and Office 365, see Microsoft 365 and Office 365 Service Descriptions.

Aggiornare a CU3 o versione successiva

Cumulative Update 3 (CU3) per Exchange Server 2013 consente di risolvere problemi rilevati in Exchange Server 2013 dal momento di rilascio del prodotto dalla versione RTM. L'aggiornamento contiene tutti i problemi e le risoluzione di CU1 e CU2 e include ulteriori correzioni e aggiornamenti relativi al periodo successivo al rilascio di CU2. Si consiglia di eseguire questo aggiornamento per tutti i clienti locali di Exchange 2013 ed è necessario per le notifiche push. Per ulteriori informazioni sugli aggiornamenti cumulativi, compreso quello CU3, vedere Aggiornamenti per Exchange 2013.

Configurare Exchange 2013 locale in Microsoft 365 o Office 365 Authentication

Un singolo metodo standardizzato per l'autenticazione da server a server è l'approccio usato da Exchange Server 2013. Exchange Server 2013 (e Lync Server 2013 e SharePoint 2013) e Office 2013 supportano il protocollo OAuth (Open Authorization) per l'autenticazione e l'autorizzazione da server a server. Con OAuth, un protocollo di autorizzazione standard usato da molti siti Web principali, le credenziali utente e le password non vengono passate da un computer a un altro. L'autenticazione e l'autorizzazione sono invece basate sui token di sicurezza OAuth; questi token concedono l'accesso a un set specifico di risorse per un periodo di tempo specifico.

L'autenticazione OAuth include in genere tre componenti: un singolo server di autorizzazione e le due aree di autenticazione che devono comunicare tra loro. I token di sicurezza vengono rilasciati dal server di autorizzazione (noto anche come server dei token di sicurezza) alle due aree di autenticazione che devono comunicare; questi token verificano che le comunicazioni provenienti da un'area di autenticazione debbano essere considerate attendibili dall'altra area di autenticazione. Ad esempio, il server di autorizzazione potrebbe emettere token che verificano che gli utenti di un'area di autenticazione di Lync Server 2013 specifica siano in grado di accedere a un'area di autenticazione di Exchange 2013 specificata e viceversa.

Consiglio

Un'area di autenticazione rappresenta un contenitore di sicurezza.

Tuttavia, per l'autenticazione da server a server locale non è necessario usare un server token di terze parti. I prodotti server quali Lync Server 2013 ed Exchange 2013 dispongono di un server di token integrato che può essere utilizzato per eseguire l'autenticazione con altri server Microsoft (ad esempio, SharePoint Server) che supportano l'autenticazione tra server. Ad esempio, Lync Server 2013 può rilasciare e firmare un token di sicurezza in modo autonomo, quindi può utilizzare quel token per comunicare con Exchange 2013. In un caso come questo, non è necessario un server token di terze parti.

Per configurare l'autenticazione da server a server per un'implementazione locale di Exchange Server 2013 a Microsoft 365 o Office 365, è necessario completare due passaggi:

Passaggio 1: assegnare un certificato all'autorità di certificazione del token predefinito del Exchange Server locale: in primo luogo, un amministratore di Exchange locale deve usare lo script exchange management shell seguente per creare un certificato se non è stato creato prima e assegnarlo all'autorità di certificazione del token predefinito del Exchange Server locale. Questo processo è un processo una tantum; dopo aver creato un certificato, il certificato deve essere riutilizzato per altri scenari di autenticazione e non sostituito. Assicurarsi di aggiornare il valore di $tenantDomain come nome del dominio. A tale scopo, copiare e incollare il codice seguente.

Nota: copiare e incollare il codice in un editor di testo come Blocco note e salvarlo con un'estensione .ps1 semplifica l'esecuzione degli script della 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."

I risultati dovrebbero essere simili all'output seguente:

L'identificazione personale del certificato configurata è: 7595DBDEA83DACB5757441D44899BCDB9911253C
Esportazione del certificato...
Completo.

Nota

Prima di continuare, è necessario il modulo Azure Active Directory per Windows PowerShell cmdlet. Se il modulo di Azure Active Directory per Windows PowerShell cmdlet (noto in precedenza come Modulo di Microsoft Online Services per Windows PowerShell) non è stato installato, è possibile installarlo da Gestisci Microsoft Entra ID usando Windows PowerShell.

Passaggio 2: Configurare Microsoft 365 o Office 365 per comunicare con Exchange 2013 in locale: configurare il server Microsoft 365 o Office 365 con cui Exchange Server 2013 comunica come applicazione partner. Ad esempio, se Exchange Server 2013 in locale deve comunicare con Microsoft 365 o Office 365, è necessario configurare Exchange locale come applicazione partner. Un'applicazione partner rappresenta qualsiasi applicazione con la quale Exchange 2013 può scambiare token di sicurezza in modo diretto, senza necessità di passare attraverso un server di token di sicurezza di terze parti. Un amministratore locale di Exchange 2013 deve usare lo script exchange management shell seguente per configurare l'organizzazione microsoft 365 o Office 365 con cui Exchange 2013 comunica come applicazione partner. Durante l'esecuzione, viene richiesto di immettere il nome utente e la password dell'amministratore del dominio dell'organizzazione di Microsoft 365 o Office 365 (ad esempio, administrator@fabrikam.com). Assicurarsi di aggiornare il valore di $CertFile al percorso del certificato se non viene creato dallo script precedente. A tale scopo, copiare e incollare il codice seguente.
```
# 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."
}
```
I risultati dovrebbero essere simili all'output seguente:

Immettere il nome utente e la password dell'amministratore del dominio dell'organizzazione di Microsoft 365 o Office 365...
Aggiunta di una chiave all'entità servizio...
Completo.

Abilitare l'inoltro delle notifiche push

Dopo aver configurato correttamente l'autenticazione OAuth seguendo i passaggi precedenti, un amministratore locale deve abilitare il proxy delle notifiche push usando lo script seguente. Assicurarsi di aggiornare il valore di $tenantDomain come nome del dominio. A tale scopo, copiare e incollare il codice seguente.

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

Il risultato previsto dovrebbe essere simile all'output seguente:

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

Verificare che le notifiche push funzionino

Al termine dei passaggi precedenti, le notifiche push vengono testate da uno dei seguenti:

Invio di un messaggio di posta elettronica di testo alla cassetta postale dell'utente:
1. Configurare un account in OWA per dispositivi su un dispositivo mobile al fine di eseguire la sottoscrizione per le notifiche.
2. Tornare alla schermata principale del dispositivo, che inserisce OWA per dispositivi in background.
3. Inviare un messaggio di posta elettronica da un altro dispositivo, ad esempio un PC, che viene inserito nella cartella Posta in arrivo dell'account configurato sul dispositivo mobile.
4. Si dovrebbe ottenere un conteggio nascosto che viene indicato sull'icona dell'app in pochi minuti.

Abilitazione del monitoraggio. Un metodo alternativo per testare le notifiche push o per capire il motivo del mancato funzionamento delle notifiche consiste nel monitoraggio di un server di cassette postali nell'organizzazione dell'utente. L'amministratore di un server di Exchange 2013 locale deve richiamare il monitoraggio di inoltro delle notifiche push utilizzando il seguente script. A tale scopo, copiare e incollare il codice seguente.

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