Outlookの「Policy Management in new Outlook for Windows」で押さえるべき結論は、新しいOutlook for Windowsの管理は、従来のOutlook向けGPOをそのまま流用する発想では足りないという点です。メールボックスやアカウント単位の制御は主にExchange PowerShell、Loop・フィードバック・診断データ・接続エクスペリエンスのようなMicrosoft 365横断の機能はCloud Policyで管理する、という役割分担で整理する必要があります。Microsoft公式情報では、新しいOutlook向けポリシーはセキュリティ、業務効率、データ保護、ユーザー体験を維持するために、Exchange PowerShell cmdletsとCloud Policyを使って構成するものと説明されています。(Microsoft Learn)
この記事では、Outlook管理者・Microsoft 365管理者・業務アドインを扱う開発者向けに、Policy Management in new Outlook for Windowsの変更点、影響範囲、確認すべき設定、移行時の注意点を実務目線で整理します。
Policy Management in new Outlook for Windowsで何が変わるのか
Policy Management in new Outlook for Windowsの重要な変更点は、管理対象が「Outlookデスクトップアプリ単体」から、Outlook on the web、新しいOutlook for Windows、Microsoft 365のクラウド設定をまたぐ管理モデルに近づいていることです。
従来のOutlookでは、ADMXテンプレート、グループポリシー、レジストリ、COM/VSTOアドイン、端末ごとの設定で多くの制御を行ってきました。一方、新しいOutlook for Windowsでは、Outlook on the webのメールボックスポリシーが新しいOutlookにも影響します。Microsoftは、Outlook on the webのメールボックスポリシーが新しいOutlookにも影響すると明記しており、従来のOutlook用ADMXやCloud Policyの多くはクラシックOutlook向けであるため、新しいOutlook向けには対応するポリシーを別途確認する必要があります。(Microsoft Learn)
つまり、管理者が最初に行うべきことは「新しいOutlookを有効にするか、無効にするか」だけではありません。既存のOutlook管理項目を棚卸しし、次のどこで制御するのかを切り分ける必要があります。
| 確認項目 | 主な管理方法 | 実務上のポイント |
|---|---|---|
| 組織メールボックスを新しいOutlookで使わせるか | Exchange Online PowerShell | Set-CASMailboxまたはSet-OwaMailboxPolicyで制御する |
| 個人アカウント追加を許可するか | Set-OwaMailboxPolicy | 業務端末でGmailや個人Outlook.comを使わせたくない場合は優先度が高い |
| 添付ファイル、署名、オフライン、PSTなど | 主にSet-OwaMailboxPolicy | Outlook on the webにも影響する設定があるため、Web利用者への影響も確認する |
| Loop、フィードバック、診断データ、接続エクスペリエンス | Cloud Policy | Microsoft 365 Apps admin centerでユーザー単位に配布する |
| 従来Outlookから新しいOutlookへの移行促進 | Group Policy、Cloud Policy、レジストリ | 移行タイミングとユーザー通知の設計が必要 |
| COM/VSTOアドイン | Webアドインへの移行検討 | 新しいOutlookではCOM/VSTOアドインはサポートされない |
影響範囲は「新しいOutlookだけ」ではない
新しいOutlookのポリシー管理で失敗しやすいのは、影響範囲を新しいOutlook for Windowsだけに限定して考えてしまうことです。
Microsoft公式情報では、多くのメールボックスポリシーはOutlook on the webと新しいOutlook for Windowsの両方に適用されるため、一方だけ有効・無効を分けられない場合があると説明されています。(Microsoft Learn)
たとえば、添付ファイルの扱い、署名、オフライン、PST、個人アカウント、追加ストレージプロバイダーなどを制御する場合、ユーザーが新しいOutlookだけでなくOutlook on the webも利用しているなら、両方の業務フローを確認する必要があります。
影響を受けやすいユーザー
特に影響が大きいのは、次のようなユーザーです。
| ユーザー・部門 | 起きやすい影響 | 事前確認のポイント |
|---|---|---|
| 営業・外勤ユーザー | オフライン利用、添付ファイル操作、個人アカウント併用に影響 | オフラインモード、添付ファイル制限、個人アカウント追加可否 |
| 経理・法務・人事 | PST、添付ファイル、IRM、S/MIME、外部共有に影響 | 保存ルール、監査、暗号化、DLP運用 |
| 経営層・秘書 | 共有メールボックス、代理アクセス、予定表連携に影響 | 共有メールボックス、予定表、アドイン互換性 |
| 開発・業務システム部門 | COM/VSTOアドイン、mailto、.ics連携に影響 | Webアドイン対応、プロトコル起動時の動作確認 |
| ヘルプデスク | 問い合わせ先、フィードバック、サポート導線に影響 | Contact Support、In-product feedbackの制御 |
まず確認すべきはプライマリアカウントの扱い
Policy Management in new Outlook for Windowsで最も重要な概念の一つが、プライマリアカウントです。
新しいOutlookでは、テーマ、文字サイズと間隔、診断データ、接続エクスペリエンスなど、アプリ全体に関係する設定が、最初に追加されたアカウント、つまりプライマリアカウントに紐づく場合があります。Microsoftは、アプリ全体の設定を管理するには、対象の組織アカウントをプライマリアカウントにする必要があると説明しています。(Microsoft Learn)
これは実務上かなり重要です。たとえば、ユーザーが先に個人アカウントを追加し、その後に会社アカウントを追加した場合、管理者が想定したポリシー適用にならない可能性があります。
推奨される確認ポイント
新しいOutlookを展開する前に、次の順番で確認してください。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | 会社アカウントを必ず最初に追加させる必要があるか | セキュリティ・監査・診断データ制御を重視するなら必要性が高い |
| 2 | 個人アカウントを許可するか | 業務端末でのデータ混在を避けるなら禁止を検討 |
| 3 | WindowsサインインアカウントとOutlookのプライマリアカウントを一致させるか | 管理端末でポリシー適用を安定させたい場合は有効化を検討 |
| 4 | 既に個人アカウントを追加済みのユーザーがいるか | 展開前に対象ユーザーを洗い出し、影響を周知する |
Microsoftは、Microsoft Intune admin centerから「Require the Primary Account to match the Windows signed-in account」ポリシーを構成する方法と、レジストリでoutlookforwindowsprimaryaccountmustmatchdevicesigninaccountを1に設定する方法を案内しています。このポリシーを有効にすると、初回アカウント追加時にWindowsサインインに使われたプライマリSMTPアドレスが提案され、ユーザーは変更できなくなります。(Microsoft Learn)
HKEY_CURRENT_USER\Software\Policies\Microsoft\office\16.0\outlook
outlookforwindowsprimaryaccountmustmatchdevicesigninaccount = 1この設定は便利ですが、Windowsサインインアカウント、Microsoft Entra ID、Officeアクティベーション、既存のメールアドレス運用が整理されていない環境では、想定外のアカウントがプライマリアカウントとして扱われる可能性があります。特にUPNとメールアドレスが異なる組織では、事前テストが必須です。
Exchange PowerShellで管理する主な設定
新しいOutlookのメールボックスや機能を制御する中心は、Exchange Online PowerShellです。Microsoftは、多くの機能はExchange PowerShell cmdletsで管理できる一方、Loopやフィードバック、診断データ、接続エクスペリエンスなどMicrosoft 365全体にまたがる機能はCloud Policyを使うべきと説明しています。(Microsoft Learn)
個人アカウントの追加を制限する
業務端末で個人メールを使わせたくない場合は、Set-OwaMailboxPolicyのPersonalAccountsEnabledを確認します。Microsoft公式情報では、個人アカウントの追加をブロックするには、Set-OwaMailboxPolicyでPersonalAccountsEnabledを$falseに設定すると説明されています。(Microsoft Learn)
Set-OwaMailboxPolicy -Identity "OwaMailboxPolicy-Default" -PersonalAccountsEnabled $falseまた、許可する組織ドメインを絞り込む場合は、AllowedOrganizationAccountDomainsを確認します。これにより、Outlookに追加できる組織アカウントのドメインを制御できます。(Microsoft Learn)
Set-OwaMailboxPolicy -Identity "OwaMailboxPolicy-Default" `
-AllowedOrganizationAccountDomains "contoso.com"実務では、いきなり既定ポリシーを変更するより、対象部門用のカスタムOWAメールボックスポリシーを作成し、検証ユーザーに割り当ててから全社展開する方が安全です。
新しいOutlookへのアクセスを許可・禁止する
新しいOutlookで会社または学校のメールボックスを使わせるかどうかは、Set-CASMailboxまたはSet-OwaMailboxPolicyで制御できます。Microsoftは、個別または複数のメールボックスを細かく制御する方法としてSet-CASMailbox、既存および将来のメールボックスに広く適用する方法としてSet-OwaMailboxPolicyを案内しています。(Microsoft Learn)
個別ユーザーを無効化する例です。
Set-CASMailbox -Identity [email protected] -OneWinNativeOutlookEnabled $false既定のOWAメールボックスポリシーで広く制御する例です。
Set-OwaMailboxPolicy -Identity "OwaMailboxPolicy-Default" `
-OneWinNativeOutlookEnabled $falseここで注意したいのは、アプリのインストール制御とメールボックスアクセス制御は別物という点です。ユーザーがMicrosoft StoreやWindowsの導線から新しいOutlookアプリを入手できたとしても、Exchange側で会社メールボックスの追加をブロックすれば、業務メールの利用は制限できます。Microsoftも、新しいOutlookアプリをどの経路で取得したかにかかわらず、会社または学校のメールボックスを追加できないようにする最終的なブロックとしてExchangeメールボックスポリシーを使うと説明しています。(Microsoft Learn)
添付ファイルのダウンロードや外部ストレージ連携を確認する
新しいOutlookでは、Word、Excel、PowerPoint、テキストファイル、多くのメディアファイルを直接開ける場合があります。管理者はSet-OwaMailboxPolicyのAllowedFileTypesやBlockedFileTypesで許可・ブロックする拡張子を構成できます。(Microsoft Learn)
たとえば、セキュリティ部門が「実行形式ファイルやスクリプトファイルの取り扱い」を厳格にしたい場合、添付ファイルのブロック設定、Defender for Office 365のポリシー、DLP、条件付きアクセスを組み合わせて確認する必要があります。
また、Box、Dropbox、Google Drive、個人用OneDriveなどMicrosoft以外のオンラインストレージを添付ファイル連携に使わせるかどうかは、AdditionalStorageProvidersAvailableの確認対象になります。(Microsoft Learn)
オフラインモードとPSTは移行前に必ず検証する
外勤、出張、工場、店舗、ネットワーク制限のある拠点では、オフライン利用の可否が業務に直結します。新しいOutlookのオフライン利用はOfflineEnabledWinで制御できます。Microsoftは、このパラメーターで新しいOutlook for Windowsのオフライン利用を許可またはブロックできると説明しています。(Microsoft Learn)
PSTについても確認が必要です。Microsoft公式情報では、新しいOutlook for WindowsのOutlookデータファイル、つまり.pstサポートは既定で有効であり、管理者はOutlookDataFileメールボックスポリシーで無効化または制限できると説明されています。ただし、新しいOutlookではプライマリアカウントのOutlookDataFileメールボックスポリシーのみが適用されます。(Microsoft Learn)
これは、メールアーカイブや退職者対応、監査、eDiscovery、ローカル保存禁止ポリシーに関係します。PSTを許可するかどうかは、Outlookの使い勝手だけでなく、情報ガバナンスの観点で判断してください。
Cloud Policyで管理すべき設定
Cloud Policyは、Microsoft 365 Apps for enterpriseのポリシー設定をユーザーのデバイスに適用する仕組みです。ドメイン参加や端末管理の有無にかかわらず、ユーザーがMicrosoft 365 Appsにサインインすると、そのユーザーに割り当てられたポリシーがデバイスに移動して適用されます。(Microsoft Learn)
新しいOutlookでは、次のような設定でCloud Policyが重要になります。
| 管理対象 | Cloud Policyを使う理由 | 確認ポイント |
|---|---|---|
| 診断データ | Microsoft 365 Apps全体のプライバシー管理に関わる | 組織のプライバシーポリシーと整合するか |
| 接続エクスペリエンス | Office全体のクラウド連携機能に影響 | 利便性とデータ保護のバランス |
| Microsoft Loop | OutlookだけでなくTeams、OneDrive、SharePointにも関係 | Loopコンポーネントの利用可否と保存場所 |
| In-product feedback | ユーザーがMicrosoftへフィードバック送信できるか | サポート窓口や情報送信ルールとの整合 |
| Contact Support | 新しいOutlook内のサポート導線を表示するか | 社内ヘルプデスクに誘導したい場合は制御を検討 |
Cloud Policyはユーザーオブジェクトに適用され、デバイスオブジェクトは無視されます。また、ユーザーが複数のMicrosoft Entraグループに所属し、競合するポリシー設定がある場合は優先順位で適用が決まります。Microsoftは、Cloud Policyで実装された設定は、Windows Serverのグループポリシーやローカル適用の設定より優先されるとも説明しています。(Microsoft Learn)
Cloud Policyの展開で失敗しやすいポイント
Cloud Policyは便利ですが、即時反映を前提にした運用には向きません。Microsoft公式情報では、Cloud Policyの設定はOfficeアプリの再起動後に適用されること、ポリシー取得のチェックイン間隔があること、ユーザーが対象のセキュリティグループに所属しているか確認する必要があることが示されています。(Microsoft Learn)
トラブル時は、次の順番で確認すると切り分けが早くなります。
| 症状 | 確認すること |
|---|---|
| ポリシーが適用されない | ユーザーがMicrosoft 365 Appsにサインインし、有効なライセンスを持っているか |
| 一部ユーザーだけ設定が違う | Microsoft Entraグループの所属とCloud Policyの優先順位 |
| 端末ごとに挙動が違う | 同一Windowsセッションで複数ユーザーがOfficeにサインインしていないか |
| 変更後も反映されない | Officeアプリの再起動、チェックイン間隔、Cloud Policy関連レジストリ |
| GPOと結果が違う | Cloud PolicyがGPOより優先されていないか |
従来のOutlookから新しいOutlookへの移行ポリシー
Policy Management in new Outlook for Windowsを理解するうえで、移行制御も重要です。
Microsoftは、組織が新しいOutlookへ移行する準備ができた場合、Group Policy、Cloud Policy service for Microsoft 365、またはレジストリ値で「Admin-Controlled Migration to New Outlook」ポリシーを設定できると説明しています。(Microsoft Learn)
このポリシーを有効にすると、ユーザーはクラシックOutlookから新しいOutlookへ移行するための案内を段階的に受けます。Microsoft公式情報では、この移行体験は3ステップで行われ、各ステップは新しいアプリ起動セッションで実行されます。(Microsoft Learn)
自動移行を制御する代表的な設定
| 目的 | 設定 | 実務での使いどころ |
|---|---|---|
| 新しいOutlookへの移行を開始する | DoNewOutlookAutoMigration = 1 | 検証済み部門から段階展開する |
| 自動移行を止める | DoNewOutlookAutoMigration = 0 | 業務アドインや運用検証が未完了の場合 |
| 再移行の間隔を指定する | NewOutlookAutoMigrationRetryIntervals | ユーザーがクラシックOutlookへ戻った後、再度移行を促す |
| 新しいOutlookからクラシックOutlookへ戻るトグルを隠す | HideClassicOutlookToggleOut | 移行完了後に戻りを抑制したい場合 |
レジストリで自動移行を有効化する例です。
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\General
DoNewOutlookAutoMigration = dword:00000001無効化する場合は次のように設定します。
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\General
DoNewOutlookAutoMigration = dword:00000000ユーザーが新しいOutlookへ移行した後にクラシックOutlookへ戻ることを想定する場合は、NewOutlookAutoMigrationRetryIntervalsで再試行間隔を設計します。Microsoftは、値0または未設定なら再移行しない、値1ならクラシックOutlook起動ごとに移行を試みる、2から99000までの値ならN日後に再移行を開始すると説明しています。(Microsoft Learn)
展開前に確認すべきチェックリスト
新しいOutlookのポリシー展開では、技術設定だけでなく、ユーザー体験とサポート体制も含めて確認する必要があります。
| チェック項目 | 確認内容 | 未確認の場合のリスク |
|---|---|---|
| 対象ユーザー | 部門、ライセンス、Exchange Online利用状況 | 対象外ユーザーに移行ポリシーが適用される |
| メールボックス環境 | Exchange Onlineか、オンプレミスやハイブリッドが含まれるか | サポート対象外環境に誤って展開する |
| プライマリアカウント | 会社アカウントが最初に追加される設計か | ポリシー適用や診断データ制御が想定とずれる |
| 個人アカウント | 追加を許可するか禁止するか | 業務データと個人データが混在する |
| Outlook on the web | 同じメールボックスポリシーの影響を受けるか | Web利用者の機能まで変わる |
| 添付ファイル | 許可・禁止拡張子、外部ストレージ連携 | 業務ファイルが開けない、または漏えいリスクが残る |
| PST | 許可、禁止、読み取り専用など | ローカル保存や監査対応に影響 |
| オフライン | 外勤・店舗・災害時運用 | ネットワーク断で業務が止まる |
| アドイン | COM/VSTO依存の有無 | 業務アプリ連携が動かない |
| サポート導線 | Contact Support、社内ヘルプデスク | ユーザーがMicrosoft側へ直接問い合わせる、または迷う |
特に注意が必要なのは、オンプレミス環境です。Microsoftは、新しいOutlookはオンプレミス環境ではサポートされていないため、Microsoft 365ユーザーとオンプレミスユーザーが混在するハイブリッド環境では、Microsoft 365ユーザーだけを対象にすべきと説明しています。また、ソブリンクラウドでは新しいOutlookを利用できないため、該当環境ではポリシーを有効にしないよう注意が必要です。(Microsoft Learn)
開発者が確認すべきアドインと連携の注意点
新しいOutlookへの移行で、開発者や業務システム担当者が最も注意すべきなのはアドインです。
Microsoftは、新しいOutlook on WindowsではOutlook Webアドインをサポートする一方、VSTOおよびCOMアドインはサポートされないと説明しています。既存のVSTO/COMアドインを新しいOutlookで使い続けるには、Outlook Webアドインへ移行する必要があります。(Microsoft Learn)
開発・移行で確認すること
| 確認項目 | 具体的に見るポイント |
|---|---|
| COM/VSTOアドインの棚卸し | インストール済みアドイン、利用部門、利用頻度、代替手段 |
| Webアドインの有無 | ベンダーがAppSourceまたはプライベートWebアドインを提供しているか |
| Outlook JS API対応 | 必要なシナリオがWebアドインで実現できるか |
| Microsoft Graph連携 | Outlookアドインだけで足りない処理をGraph APIで補えるか |
| オフライン時の挙動 | 新しいOutlookがオフラインのときにアドインが動くか |
| mailto・.ics起動 | 外部業務システムからメール作成・予定作成を呼び出す処理 |
Microsoftは、COMアドインを使っている組織に対して、インストール済みCOM/VSTOアドインの確認、ミッションクリティカルなアドインの特定、Webアドインの有無の確認、ネイティブ機能で代替できるかの検討、必要に応じたWebアドイン開発を推奨しています。(Microsoft Learn)
また、新しいOutlookでオフライン設定を有効にしても、OutlookアドインやMicrosoft 365/Copilotストアはオフライン時に利用できない場合があります。Microsoftは、オフライン状態で起動した場合、インストール済みアドインがリボンやアクションバーに表示されないこと、イベントベースのアドインが起動できないことがあると説明しています。(Microsoft Learn)
メール送信前チェック、誤送信防止、DLP、CRM連携、電子署名、ファイル保存など、業務上止められないアドインがある場合は、新しいOutlookの移行スケジュールより先にアドイン検証を終える必要があります。
管理者がやるべき移行手順
新しいOutlookのPolicy Managementは、設定を一つ変更して終わりではありません。次の流れで進めると、トラブルを抑えやすくなります。
既存ポリシーを棚卸しする
最初に、クラシックOutlookで使っているGPO、ADMX、Cloud Policy、レジストリ、Exchange Online PowerShell、アドイン制御を洗い出します。
Microsoftは、クラシックOutlook用ポリシーを使っている組織では、新しいOutlook向けの同等または関連ポリシーを実装する必要があるとし、Cloud PolicyのエクスポートやGPOレポートを使って既存ポリシーを確認する方法を案内しています。(Microsoft Learn)
新しいOutlook向けの制御先にマッピングする
棚卸ししたポリシーを、次の4種類に分類します。
| 分類 | 例 |
|---|---|
| Exchange PowerShellへ移すもの | 個人アカウント、添付ファイル、PST、署名、オフライン、S/MIME、IRM |
| Cloud Policyで管理するもの | 診断データ、接続エクスペリエンス、Loop、フィードバック、Contact Support |
| 移行制御として扱うもの | Try the new Outlookトグル、自動移行、再移行間隔 |
| 代替策が必要なもの | COM/VSTOアドイン、クラシックOutlook専用のレジストリ制御 |
Microsoftのマッピング資料では、クラシックOutlookのポリシーIDやレジストリ値に対応する新しいOutlook向けポリシーが表で整理されています。表にないポリシーIDやレジストリ値については、同等の新しいOutlookポリシーが存在しない可能性があります。(Microsoft Learn)
検証グループを作る
いきなり全社展開せず、次のような検証グループを作ります。
| グループ | 目的 |
|---|---|
| IT部門 | 基本設定、ポリシー反映、ログ、問い合わせ対応を検証 |
| アドイン利用部門 | COM/VSTO、Webアドイン、業務システム連携を検証 |
| 外勤ユーザー | オフライン、添付ファイル、モバイルとの併用を検証 |
| 管理職・秘書 | 共有メールボックス、代理送信、予定表、会議設定を検証 |
検証では「新しいOutlookが起動するか」だけでなく、「今まで通り業務が完了するか」を確認してください。特に、月末処理、請求書送信、採用連絡、契約書レビュー、問い合わせ対応など、業務の締切があるプロセスで試すことが重要です。
展開後に確認する
展開後は、設定が効いているかをPowerShellとユーザー確認の両方で見ます。
Get-CASMailbox -Identity [email protected] |
Format-List Name,OneWinNativeOutlookEnabled,OWAEnabled,OWAMailboxPolicyOWAメールボックスポリシーの確認例です。
Get-OwaMailboxPolicy |
Format-Table Name,OneWinNativeOutlookEnabled,PersonalAccountsEnabled,OfflineEnabledWinCloud Policyについては、Microsoft 365 Apps admin centerで対象ポリシー、スコープ、優先順位、対象グループを確認します。必要に応じて、ユーザー端末側のCloud Policy関連レジストリも確認します。
よくある誤解と対策
「新しいOutlookトグルを隠せば完全にブロックできる」は誤解
クラシックOutlook内の「新しいOutlookを試す」トグルを隠しても、それだけで新しいOutlookアプリの利用や会社メールボックスの追加を完全に防げるわけではありません。Microsoftは、トグルを隠すポリシーはクラシックOutlook内の表示を制御するものであり、メールボックスを新しいOutlookに追加できるかは別のExchangeポリシーで制御できると説明しています。(Microsoft Learn)
対策は、トグル制御、アプリのインストール制御、Exchange側のメールボックスアクセス制御を分けて設計することです。
「GPOがあるから新しいOutlookにも効く」は危険
クラシックOutlook向けのADMXや多くのCloud Policyは、基本的にクラシックOutlook向けです。Microsoftは、クラシックOutlookで構成しているポリシーがある場合、新しいOutlook向けの対応ポリシーを実装する必要があると説明しています。(Microsoft Learn)
対策は、既存GPOをそのまま前提にせず、Microsoftのマッピング表を使って新しいOutlook側の制御方法に置き換えることです。
「個人アカウントを禁止すれば十分」ではない
個人アカウントを禁止しても、プライマリアカウント、既存追加済みアカウント、外部ストレージ、添付ファイル保存、PST、共有メールボックスなど、別の経路でデータ混在や情報持ち出しのリスクが残る場合があります。
対策は、個人アカウント禁止に加えて、会社アカウントをプライマリアカウントにする設定、添付ファイル制御、外部ストレージ連携、PSTポリシーをセットで確認することです。
「アドインは後で直せばよい」は移行遅延の原因になる
新しいOutlookではCOM/VSTOアドインがサポートされないため、業務アドインの確認を後回しにすると、移行直前で止まる可能性があります。Microsoftは、WebアドインがないCOMアドインについては、ネイティブ機能で代替できるかを確認し、足りない場合はパートナーや社内開発チームとWebアドイン開発を始めるよう案内しています。(Microsoft Learn)
対策は、移行計画の最初にアドイン棚卸しを入れることです。利用率が低いアドインは廃止候補にし、業務上必須のアドインはWebアドイン、Microsoft Graph、Power Automate、ネイティブ機能のどれで代替するか決めます。
まず取るべきアクション
Policy Management in new Outlook for Windowsへの対応で、最初に行うべきことは次の3つです。
まず、既存のOutlook管理項目を棚卸ししてください。GPO、ADMX、レジストリ、Cloud Policy、Exchange Online PowerShell、アドイン、PST、添付ファイル、個人アカウントの設定を一覧化します。
次に、各設定を「Exchange PowerShellで管理するもの」「Cloud Policyで管理するもの」「移行ポリシーで管理するもの」「代替策が必要なもの」に分けます。特に、プライマリアカウント、個人アカウント、Outlook on the webへの影響、COM/VSTOアドインは優先的に確認してください。
最後に、検証グループで展開し、ユーザーの実業務で確認します。新しいOutlookが起動するかではなく、メール送信、予定表、添付ファイル、共有メールボックス、アドイン、オフライン、PST、サポート導線まで含めて、業務が完了できるかをチェックすることが重要です。
新しいOutlookのポリシー管理は、単なるOutlook設定変更ではありません。Exchange Online、Microsoft 365 Apps、Cloud Policy、アドイン、情報保護をまたぐ運用設計です。今のうちに管理方法を整理しておけば、移行時の問い合わせ、業務停止、セキュリティ例外を大きく減らせます。
コメント