次の方法で共有


OWA for Devices のプッシュ通知のプロキシの設定

製品: Exchange Server 2013

Microsoft Exchange 2013 のオンプレミス展開で OWA for Devices (OWA for iPhone、OWA for iPad) のプッシュ通知を有効にすると、ユーザーは iPhone 用 OWA と OWA for iPad のOutlook Web App アイコンで更新プログラムを受け取り、ユーザーの受信トレイに表示されないメッセージの数を示すことができます。 プッシュ通知が構成および有効になっていない場合、OWA for Devices を持つユーザーは、アプリを起動せずに、未確認のメッセージが受信トレイに存在することを知る方法がありません。 新しいメッセージが使用可能になると、OWA for Devices バッジがユーザーのデバイスで更新され、次のバッジのようになります。

OWA for Devices バッジ。

プッシュ通知を有効にする方法

プッシュ通知を有効にするには、オンプレミスの Exchange 2013 サーバーが Microsoft 365 または Office 365 プッシュ通知サービスに接続して、iPhone と iPad にプッシュ通知を送信する必要があります。 Exchange 2013 オンプレミス サーバーは、Microsoft 365 または Office 365 通知サービスを通じて更新通知をルーティングし、サード パーティのプッシュ通知サービスに開発者アカウントを登録する必要を排除します。 次の図は、iPhone ユーザーと iPad ユーザーが見えないメッセージのバッジ更新プログラムを取得する方法のプロセスを示しています。

プッシュ通知のプロセス。

プッシュ通知を有効にするため、管理者は次のことを行う必要があります。

  1. Organizationを Microsoft 365 またはOffice 365に登録します。

  2. 社内サーバーのすべてを更新して、Exchange Server 2013 累積更新プログラム 3 (CU3) 以降にします。

  3. オンプレミスの Exchange 2013 を Microsoft 365 または Office 365 認証に設定します。

  4. オンプレミス Exchange Server 2013 から Microsoft 365 または Office 365 へのプッシュ通知を有効にし、プッシュ通知が機能していることを確認します。

Microsoft 365 または Office 365 にorganizationを登録する

Microsoft 365 および Office 365 は、堅牢なセキュリティ、信頼性、ユーザーの生産性に関するorganizationのニーズを満たすのに役立つクラウドベースのサービスです。 利用可能なさまざまなサブスクリプション プランには、Office アプリケーションへのアクセスのほか、インターネット (クラウド サービス) 経由で有効になっているその他の生産性サービス (Lync Web 会議、Exchange Onlineホステッド メールなど) が含まれます。

Microsoft 365 および Office 365 プランの多くには、最新の Office アプリケーションのデスクトップ バージョンも含まれており、ユーザーは複数のコンピューターやデバイスにインストールできます。 すべての Microsoft 365 プランと Office 365 プランは、サブスクリプションベース (月単位または年単位) で支払われます。 organizationのOffice 365に登録する方法について詳しくは、「ビジネス向け Microsoft 365 とは」をご覧ください。 Microsoft 365 および Office 365 を通じて提供される各サービスの詳細については、「Microsoft 365 および Office 365 サービスの説明」を参照してください。

CU3 以降への更新

Exchange Server 2013 用累積更新プログラム 3 (CU3) は、Exchange Server 2013 の RTM がリリースされて以来見つかった問題を解決します。 それには、CU1 と CU2 に含まれていた問題とその修正のすべてが含まれており、さらに CU2 がリリースされて以来見つかったその他の修正と更新プログラムも含まれています。 この更新プログラムは、Exchange Server 2013 のすべての社内カスタマーに対して推奨されているレベルのものですが、プッシュ通知に関しては必須となっています。 CU3 を含む累積的な更新プログラムについては、「Exchange 2013 の更新」を参照してください。

オンプレミス Exchange 2013 を Microsoft 365 または Office 365 認証に設定する

サーバー間認証の 1 つの標準化された方法は、Exchange Server 2013 で使用されるアプローチです。 Exchange Server 2013 (および Lync Server 2013 および SharePoint 2013) と Office 2013 では、サーバー間の認証と承認のための OAuth (Open Authorization) プロトコルがサポートされています。 多くの主要な Web サイトで使用される標準承認プロトコルである OAuth では、ユーザーの資格情報とパスワードは、あるコンピューターから別のコンピューターに渡されません。 代わりに、認証と承認は OAuth セキュリティ トークンに基づいています。これらのトークンは、特定の時間の特定のリソース セットへのアクセスを許可します。

OAuth 認証には通常、1 つの承認サーバーと、相互に通信する必要がある 2 つの領域の 3 つのコンポーネントが含まれます。 セキュリティ トークンは、通信する必要がある 2 つの領域に対して承認サーバー (セキュリティ トークン サーバーとも呼ばれます) によって発行されます。これらのトークンは、ある領域から発信される通信が他の領域から信頼される必要があることを確認します。 たとえば、承認サーバーは、特定の Lync Server 2013 領域のユーザーが指定された Exchange 2013 領域にアクセスできることを確認するトークンを発行する場合があります。その逆も同様です。

ヒント

領域は、セキュリティのコンテナーとなるものです。

ただし、オンプレミスのサーバー間認証では、サード パーティのトークン サーバーを使用する必要はありません。 Lync Server 2013 や Exchange 2013 などのサーバー製品にはそれぞれ、サーバー間認証をサポートする他の Microsoft サーバー (SharePoint Server など) との認証のために使用できる組み込みトークン サーバーがあります。 たとえば、Lync Server 2013 はセキュリティトークンを自ら発行して署名し、そのトークンを使用して Exchange 2013 と通信できます。 このような場合、サードパーティのトークン サーバーは必要ありません。

Exchange Server 2013 から Microsoft 365 または Office 365 へのオンプレミス実装のサーバー間認証を構成するには、次の 2 つの手順を実行する必要があります。

  • 手順 1 - オンプレミス Exchange Serverの組み込みトークン発行者に証明書を割り当てる: まず、オンプレミスの Exchange 管理者は、次の Exchange 管理シェル スクリプトを使用して、以前に作成されていない証明書を作成し、それをオンプレミス Exchange Serverの組み込みトークン発行者に割り当てる必要があります。 このプロセスは 1 回限りのプロセスです。証明書が作成されたら、その証明書を他の認証シナリオで再利用し、置き換えないようにする必要があります。 $tenantDomain の値を、実際のドメイン名に必ず更新してください。 そのためには、以下のコードをコピーおよび貼り付けてください。

    : メモ帳などのテキスト エディターにコードをコピーして貼り付け、.ps1 拡張機能で保存すると、シェル スクリプトを簡単に実行できます。

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

    結果は次の出力のようになります。

構成済みの証明書拇印: 7595DBDEA83DACB5757441D44899BCDB9911253C
証明書のエクスポート...
完了。

注:

続行する前に、Windows PowerShellコマンドレット用の Azure Active Directory モジュールが必要です。 Windows PowerShell コマンドレット用の Azure Active Directory モジュール (以前は Microsoft Online Services Module for Windows PowerShell) がインストールされていない場合は、Windows PowerShellを使用して管理Microsoft Entra IDからインストールできます。

  • 手順 2 - オンプレミスの Exchange 2013 と通信するように Microsoft 365 またはOffice 365を構成する: 2013 Exchange Serverが通信する Microsoft 365 または Office 365 サーバーをパートナー アプリケーションとして構成します。 たとえば、Exchange Server 2013 オンプレミスが Microsoft 365 またはOffice 365と通信する必要がある場合は、Exchange オンプレミスをパートナー アプリケーションとして構成する必要があります。 パートナー アプリケーションは、サード パーティ セキュリティ トークン サーバーを使用せずに、Exchange 2013 が直接セキュリティ トークンを交換できるアプリケーションです。 オンプレミスの Exchange 2013 管理者は、次の Exchange Management Shell スクリプトを使用して、Exchange 2013 がパートナー アプリケーションとして通信する Microsoft 365 またはOffice 365 organizationを構成する必要があります。 実行中に、Microsoft 365 または Office 365 organization ドメインの管理者ユーザー名とパスワードを入力するように求められます (例: administrator@fabrikam.com)。 証明書が前のスクリプトから作成されたのではない場合、$CertFile の値を更新し証明書の場所を設定します。 そのためには、以下のコードをコピーおよび貼り付けてください。

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

    結果は次の出力のようになります。

    Microsoft 365 または Office 365 organization ドメインの管理者ユーザー名とパスワードを入力してください。...
    サービス プリンシパルへのキーの追加...
    完了。

プッシュ通知のプロキシを有効にする

上記の手順に従って OAuth 認証が正常に設定されたら、オンプレミス管理者は、次のスクリプトを使用してプッシュ通知プロキシを有効にする必要があります。 $tenantDomain の値を、実際のドメイン名に必ず更新してください。 そのためには、以下のコードをコピーおよび貼り付けてください。

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

予想される結果は、次の出力のようになります。

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

プッシュ通知の動作検証

上記の手順が完了すると、プッシュ通知は次のいずれかによってテストされます。

  • テスト電子メール メッセージをユーザーのメールボックスに送信する。

    1. モバイル デバイス上の OWA for Devices で通知サブスクライブのためのアカウントを設定します。

    2. デバイスのホーム画面に戻ります。OWA for Devices はバックグラウンドになります。

    3. PC などの別のデバイスから、モバイル デバイスに設定されたアカウントの受信ボックス宛てに電子メール メッセージを送信します。

    4. 数分以内に、アプリのアイコン上に不可視カウントが表示されるはずです。

  • モニターを有効にする。 プッシュ通知のテスト、あるいは通知が失敗する原因を調べる別の方法として、組織内のメールボックス サーバーに対するモニターを有効にするという方法があります。 社内 Exchange 2013 サーバー管理者は、以下のスクリプトを使用して、プッシュ通知プロキシのモニターを起動する必要があります。 そのためには、以下のコードをコピーおよび貼り付けてください。

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

    予想される結果は、次の出力のようになります。

    ResultType : 成功
    エラー:
    例外: