社畜の所業

社畜の所業

Microsoft365の機能について解説をしていきたいと思います。このブログの情報をご活用いただければ幸いです。たまに他の情報も取り入れていきたいと思います。

※このサイトはPR記事を含みます。

【Microsoft365参考書】新しいOutlook(New Outlook) vs クラシックOutlook 徹底比較|Exchange管理者が移行前に必ず確認すべき違い

新しいOutlook(New Outlook) vs クラシックOutlook 徹底比較|Exchange管理者が移行前に必ず確認すべき違い

「そろそろ新しいOutlook(New Outlook)に切り替えるべき?」

「でもPSTファイルやVBAマクロ、COMアドインは動くの?」

Microsoft 365やExchange Onlineの管理を任されている方なら、一度はこの悩みにぶつかったことがあるはずです。

Microsoftは現在、Classic OutlookからNew Outlookへの移行を強力に推進していますが、2026年時点でも一部の機能はClassic Outlookにしか存在しません

棚卸しをせずに全社展開してしまうと、「PSTが開けない」「マクロが動かない」「アドインが使えない」といった問い合わせが一気に増えてしまいます。

この記事では、Exchange Online / Microsoft 365 管理者の視点から、New OutlookとClassic Outlookの違いを徹底比較し、どちらを選ぶべきかの判断基準まで解説します。

 

 

 

1. 基本的な違いを一覧でチェック

まずは全体像から。New OutlookとClassic Outlookは、見た目が似ていても内部のアーキテクチャがまったく異なります。

項目 New Outlook Classic Outlook
ベース Outlook on the web ベース Win32ネイティブアプリ
データ管理 クラウド中心 OST/PST中心
UI Web版とほぼ共通 従来UI
動作 軽量 高機能だが重い場合あり
将来性 Microsoft推奨 将来的に縮小方向
カスタマイズ性 制限あり 豊富

Microsoft公式ではNew Outlookを「モダンなOutlook」と位置付けており、Windows・Web・Macでの体験統一を目指しています。

とはいえ、この「モダン化」の裏には管理者が見落としがちな機能差が潜んでいます。次章から順に見ていきましょう。

 

 

 

2. PSTファイル:従来運用が使えない落とし穴

機能 Classic Outlook New Outlook
PSTを開く △(一部対応のみ)
PST作成
PSTへのアーカイブ
PSTからインポート

New OutlookのPSTサポートは限定的で、従来のPST運用をそのまま移行できないケースがあります。長年PSTでメールを保管してきた部署がある場合は、事前の検証が必須です。

 

 

3. COMアドイン:New Outlookでは非対応

CRM連携、会計システム連携、独自の業務アドイン、Exchange管理ツールなど、Classic Outlookで動いていたCOMアドインはNew Outlookでは一切動作しません

代替として、Office Web Add-inへの移行が必要になります。社内で使われているアドインの棚卸しは、移行計画の最優先タスクと言えるでしょう。

 

 

 

4. VBAマクロ:自動化業務への影響

Classic OutlookではApplication_ItemSend()のようなVBAマクロで送信時処理などを自動化できますが、New OutlookはVBAを完全にはサポートしていません

自動仕分けや定型処理をVBAに依存している環境では、移行前の影響範囲の洗い出しが欠かせません。

 

 

5. オフライン利用:出張・モバイル環境での差

Classic OutlookはOSTへのキャッシュによりネットワークが切断していても操作可能な、非常に強いオフライン耐性を持っています。

一方New Outlookは基本的にクラウド接続を前提とした設計で、オフライン対応は部分的です。出張や移動の多い社員には、この差が業務効率に直結します。

 

 

 

6. Exchange Onlineとの接続方式の違い

Classic Outlookは主にMAPI over HTTP、Autodiscover、EWS(一部機能)を利用して接続します。

一方New Outlookの設計思想はOWA(Outlook on the web)にほぼ準じており、バックエンドはMicrosoft 365サービスとのクラウド接続を前提とした、従来よりWebベースに近い動作になります。

 

 

7. オンプレExchangeへの対応状況

ハイブリッド環境を運用している管理者にとって、ここが最も重要なポイントです。

  • Classic Outlook: Exchange Server 2016 / 2019、Hybrid環境に完全対応
  • New Outlook: オンプレExchangeはIMAPベースによる部分対応にとどまる

そのため、Hybrid環境オンプレ共有メールボックスカスタム機能を利用している組織では、当面Classic Outlookを継続する方が安全です。

 

 

 

8. 共有メールボックス・委任アクセス

機能 New Outlook Classic Outlook
共有メールボックス利用
アーカイブメールボックス
代理人(Delegate)アクセス

共有メールボックス自体は両方で利用できますが、代理人機能はNew Outlookで一部制限があるため、秘書業務や代理送信を行う部署では要注意です。

 

 

9. メールルールの自由度

Classic Outlookはスクリプト実行やクライアント専用ルール、複雑な条件分岐など高度なルール作成が可能です。

一方New Outlookは主にサーバールール中心で、一部の高度な条件には未対応です。凝った自動仕分けルールを組んでいる場合は、移行後に動作確認が必要です。

 

 

 

ここはNew Outlookの強みです。Microsoft SearchによるクラウドインデックスなのでOSTのインデックス管理が不要になります。

Classic OutlookはWindows Searchに依存しているため、インデックス破損・OST肥大化・検索漏れといったトラブルが起きやすい傾向があります。検索品質を重視するなら、New Outlookに軍配が上がります。

 

 

11. Copilotの実装状況

メール要約、返信案作成、スレッド分析といったCopilot新機能はNew Outlookが先行実装しています。

Classic Outlookも対応を拡大中ですが、常に後追いの立ち位置です。生成AIを積極活用したい組織にとっては、New Outlookへの移行がそのままAI活用の近道になります。

 

 

 

12. 【結論】どちらを選ぶべきか?管理者向け判断フロー

✅ New Outlookがおすすめな環境

  • Exchange Onlineのみを利用している
  • PST運用が不要
  • VBAを使っていない
  • COMアドインを使っていない
  • Copilotを積極的に活用したい

✅ Classic Outlookを継続すべき環境

  • ハイブリッドExchange構成
  • Exchange Server 2016/2019を併用
  • PST運用がある
  • VBAを利用している
  • COMアドインを利用している
  • 高度なメールルールを使っている

現実的な判断まとめ
・Exchange Online単独運用 → New Outlookへ移行可能
・Hybrid Exchange → 当面はClassic Outlook推奨
・独自アドイン利用 → Classic Outlook推奨

特に注意したいのは、ユーザーが使っているアドイン・VBA・自動仕分けルールを事前に棚卸ししないまま全社展開してしまうケースです。

切り替え後に問い合わせが殺到する典型的な失敗パターンなので、必ず移行前チェックリストを作成してから展開することをおすすめします。

なお、Microsoftの公式比較表は頻繁に更新されるため、実際の移行判断時には必ず最新のMicrosoft公式ドキュメントも合わせて確認してください。

 

 

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

 

【Microsoft365参考書】PowershellでExchangeOnlineに接続する手順

 

この記事でわかること

  • PowerShellでExchange Onlineに接続する手順(初回のモジュールインストールを含む)
  • 【重要】Microsoft Entra ID(旧Azure AD)に接続する最新の方法
  • Microsoft Purview(旧セキュリティコンプライアンスセンター)に接続する場合の参照先

PowerShellのコマンドレットを使うと、Exchange管理センターの画面上ではできない設定や、複数ユーザーへの一括操作などが可能になります。

この記事では、PowerShellからExchange Onlineに接続するための基本手順と、あわせてよく利用されるMicrosoft Entra ID・Microsoft Purviewへの接続方法もご紹介します。

前提条件
基本認証(ベーシック認証)は既に廃止されているため、現在はExchangeOnlineManagementモジュール(通称: V3モジュール)を利用して、先進認証(モダン認証)でExchange Onlineに接続する必要があります。

 

 

 

Exchange Onlineに接続する手順

1. PowerShellを管理者として起動する

  1. [スタート] をクリックします。
  2. 画面をスクロールし、[Windows PowerShell] を右クリックします。
  3. 表示されるメニューから [管理者として実行] をクリックします。

2. 初回のみ:実行ポリシーを変更する

初めてPowerShellを利用する場合は、以下のコマンドを実行して設定変更が必要です。実行済みの場合はこの手順は不要です。

Set-ExecutionPolicy RemoteSigned

※警告メッセージが表示されるので、[Y] と入力して [Enter] キーを押してください。

3. 初回のみ:ExchangeOnlineManagementモジュールをインストールする

見落としがちなポイント
モジュールがインストールされていない状態で Connect-ExchangeOnline を実行すると、コマンドレットが見つからない旨のエラーになります。初めて接続する端末では、必ず先に以下のコマンドでモジュールをインストールしてください。

Install-Module -Name ExchangeOnlineManagement

※実行時に「信頼されていないリポジトリからインストールしますか?」といった確認が表示された場合は [A](すべて続行) を入力してください。インストール済みの場合、この手順は不要です(Update-Module -Name ExchangeOnlineManagement で最新版に更新できます)。

4. Exchange Onlineに接続する

Connect-ExchangeOnline -UserPrincipalName <対象アカウントのユーザーID(UPN)>

※実行するとサインイン画面が表示されるので、管理者のIDとパスワードで認証を行ってください(多要素認証を設定している場合は、あわせて認証を行います)。黄色の警告文が表示されたら、接続完了のサインです。

 

 

 

Microsoft Entra ID(旧Azure AD)に接続する場合

⚠ 重要な仕様変更(必ずお読みください)
以前はAzure AD(現Microsoft Entra ID)への接続に「MSOnline」モジュール(Install-Module -Name MSOnlineConnect-MsolService)が使われていましたが、このモジュールはMicrosoftにより2025年3月30日にサポートが終了し、2025年4月〜5月にかけて全テナントで完全に動作しなくなりました。現在このコマンドレットを実行しようとしても接続エラーになります。

後継であるMicrosoft Graph PowerShell SDKへの切り替えが必要です。

Get-MgUserUpdate-MgUser など、コマンドレットに Mg を含むものを利用する場合は、Microsoft Graph PowerShell SDKでの接続が必要です。

初回のみ:モジュールをインストールする

Install-Module -Name Microsoft.Graph -Scope CurrentUser

※インストール済みの場合はこの手順は不要です。特にエラーが発生しなければ完了です。

Microsoft Entra IDに接続する

以下のコマンドレットを実行すると、ブラウザでサインイン画面が表示されるので、管理者アカウントでサインインしてください。ユーザー情報の変更などを行う場合は、必要な権限(スコープ)を指定します。

Connect-MgGraph -Scopes "User.ReadWrite.All"

※参照(読み取り)のみで良い場合は "User.Read.All" など、操作内容に応じて必要最小限のスコープを指定することをおすすめします。

 

 

 

Microsoft Purview(旧セキュリティコンプライアンスセンター)に接続する場合

コンプライアンス関連の設定(保持ポリシー、コンテンツ検索、DLPなど)を行う場合は、Microsoft Purview(旧称: セキュリティコンプライアンスセンター)への接続が必要です。こちらはConnect-IPPSSessionコマンドレットを使用します。

接続手順の詳細は、以下の記事をあわせてご参照ください。

it-bibouroku.hateblo.jp

 

 

 

よくある質問

Q. Connect-ExchangeOnlineを実行すると「コマンドが見つかりません」というエラーになります。
A. ExchangeOnlineManagementモジュールがインストールされていない可能性があります。Install-Module -Name ExchangeOnlineManagement を実行してから、再度お試しください。

Q. Connect-MsolServiceを実行するとエラーになります。
A. MSOnlineモジュールはMicrosoftによって2025年に完全に廃止されており、現在は接続できません。この記事で案内しているMicrosoft Graph PowerShell SDK(Connect-MgGraph)への切り替えが必要です。

Q. 多要素認証(MFA)を設定していますが、接続できますか?
A. Connect-ExchangeOnlineConnect-MgGraphいずれも先進認証(モダン認証)に対応しており、多要素認証を設定したアカウントでも問題なく接続できます。

 

 

 

まとめ

PowerShellからMicrosoft 365の各サービスに接続する際は、以下のポイントを押さえておきましょう。

  1. Exchange Onlineへの接続には、事前に ExchangeOnlineManagement モジュールのインストールが必要
  2. Microsoft Entra ID(旧Azure AD)への接続は、廃止されたMSOnlineモジュールではなくMicrosoft Graph PowerShell SDK(Connect-MgGraph)を使用する
  3. Microsoft Purview(旧セキュリティコンプライアンスセンター)への接続は Connect-IPPSSession を使用する
  4. いずれも先進認証に対応しており、多要素認証を設定したアカウントでも接続可能

社内の手順書やスクリプトにMSOnlineモジュールの記載が残っている場合は、この機会にMicrosoft Graph PowerShell SDKへの切り替えをおすすめします。

 

 

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

 

【Microsoft365参考書】PowerShellでMicrosoft Teamsに接続する方法

PowerShellでMicrosoft Teamsに接続する方法

この記事でわかること

  • PowerShellでMicrosoft Teamsに接続する手順
  • 【重要】モジュールのバージョンに関する最新の考え方
  • 2回目以降、より簡単に接続する方法

Teamsの管理設定の中には、Teams管理センターの画面からは変更できず、PowerShellのコマンドレットでのみ設定可能なものがあります。

この記事では、PowerShellからMicrosoft Teamsに接続するための基本手順をご紹介します。

 

 

 

1. 現在のモジュールバージョンを確認する

  1. [Windows PowerShell] を右クリックし、[管理者として実行] をクリックします。
  2. UACプロンプトが表示されたら [はい] をクリックします。
  3. 以下のコマンドレットを実行し、現在インストールされているモジュールのバージョンを確認します。

Get-InstalledModule -Name MicrosoftTeams

⚠ バージョンの考え方が変わっています
以前は「3.0.0以上であればよい」という目安で案内されることが多かったのですが、現在のMicrosoftTeamsモジュールは既にメジャーバージョン6〜7台まで更新が進んでいます。特定のバージョン番号を目安にするのではなく、常に最新の安定版に更新しておくことをおすすめします。

また、公式ドキュメントでは、異なるメジャーバージョン(例: 新しいバージョンと2.x系)を同じ組織内の異なる管理端末で混在させて運用することは推奨されていません。複数の管理者で運用している場合は、バージョンをそろえておくと予期しない挙動を避けやすくなります。

 

 

 

2. モジュールをインストール・更新する

モジュールが入っていない場合

以下を実行してモジュールをインストールします。

Install-Module -Name MicrosoftTeams

既にモジュールが入っている場合

以下を実行して最新版に更新します。

Update-Module -Name MicrosoftTeams

※モジュールを既にインポート(読み込み)した状態で更新しようとすると失敗することがあります。その場合はPowerShellを一度閉じ、新しく管理者権限のPowerShellを開き直してから再度実行してください。

 

 

 

3. Microsoft Teamsに接続する

モジュールのインストール・更新が完了したら、以下のコマンドレットを順に実行します。

Import-Module -Name MicrosoftTeams

Connect-MicrosoftTeams

サインイン画面が表示されたら、管理者ユーザーのアカウントとパスワードを入力してサインインしてください(多要素認証を設定している場合は、あわせて認証を行います)。

 

 

2回目以降の接続

モジュールのインストールが完了していれば、次回以降は以下の手順のみで接続できます。

  1. [Windows PowerShell] を右クリックし、[管理者として実行] をクリックします。※UACプロンプトが表示されたら [はい] をクリックします。
  2. 以下のコマンドレットを実行して接続します。

Connect-MicrosoftTeams

サインイン画面が表示されたら、管理者ユーザーのアカウントとパスワードを入力してサインインしてください。

 

 

 

よくある質問

Q. Connect-MicrosoftTeamsを実行すると「コマンドが見つかりません」というエラーになります。
A. モジュールがインストールされていないか、インポートされていない可能性があります。Install-Module -Name MicrosoftTeams を実行後、Import-Module -Name MicrosoftTeams を実行してから、再度お試しください。

Q. モジュールを更新しようとすると失敗します。
A. 現在のPowerShellセッションで既にモジュールが読み込まれていると、更新に失敗することがあります。PowerShellを一度閉じ、新しく管理者権限のPowerShellを起動してから Update-Module -Name MicrosoftTeams を実行してください。

Q. どのくらいの頻度でモジュールを更新すればいいですか?
A. 明確な周期は定められていませんが、新しいコマンドレットや修正が頻繁に追加されているため、定期的(月次など)に Update-Module -Name MicrosoftTeams を実行し、最新の安定版を利用することをおすすめします。

 

 

 

まとめ

PowerShellからMicrosoft Teamsに接続する際は、以下のポイントを押さえておきましょう。

  1. 特定のバージョン番号にこだわらず、常に最新の安定版のMicrosoftTeamsモジュールを利用する
  2. 初回は Install-Module(または Update-Module)→ Import-ModuleConnect-MicrosoftTeams の順に実行する
  3. 2回目以降は Connect-MicrosoftTeams の実行のみでよい
  4. 組織内で複数の管理者が運用している場合は、モジュールのバージョンをそろえておく

Teams管理センターの画面にない設定項目を変更したい場合は、まずこの接続手順から試してみてください。

 

 

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

 

【Microsoft365参考書】MC1248389 Credential パラメーターが廃止される?

MC1248389 Credential パラメーターが廃止される?

 

 

 

 

MC1248389 の内容とは?

Connect-ExchangeOnline および Connect-IppsSession コマンドレット で Credential パラメーターが利用できなくなるという内容です。

2026年 12 月以降にリリースされる ExchangeOnline モジュールでは、Creadential パラメーターは利用することができませんが、 それ以前にリリースされている ExchangeOnline モジュールでは、Credential パラメーターが引き続き利用できます。

ただし、Credential パラメーターがサーバー側で別途廃止されることが予定されていますので、今後、2026 年 12 月以前にリリースされている ExchangeOnline モジュールでも利用できなくなります。

 

 

 

影響は?

Connect-ExchangeOnline と Connect-IppsSession コマンドレット で Credential パラメーターが利用できなくなるという点だけですので、Connect-ExchangeOnline と Connect-IppsSession コマンドレット で Credential パラメーターを利用していなければ影響はありません

多いのがスクリプトなどで Credential パラメーターを利用している場合は、Credential パラメーターを使わない構成に変更しなければいけません。

 

 

 

Credential パラメーターの役割とは?

Credential パラメーターは、PSCredential オブジェクト(ユーザー名+パスワード)を指定して、対話なしで Exchange Online に接続するためのパラメーターです。

この方式は内部的に ROPC(Resource Owner Password Credentials)フローを使用します。

 

使われていた代表的なケース

  • タスクスケジューラ等での非対話型スクリプト
  • MFA を使っていない管理者アカウントでの認証

 

it-bibouroku.hateblo.jp

 

 

 

 

なぜCredential パラメーターが問題視されているのか?

Credential パラメーターが依存している ROPC フローには、以下の重大な制約があります。

  • MFA 非対応
  • 条件付きアクセス非対応
  • パスワードを直接扱う(セキュリティリスク)

 

Microsoft は MFA を必須とする方向へ全面移行しており、ROPC 自体が MSAL v4.74.0 以降で非推奨になっています。

そのため、Credential パラメーターは Microsoft のセキュリティ基準を満たせないという位置付けになっています。

 

 

 

Credential をスクリプトで使っていた場合の代替案

Credential をスクリプトで使っていた場合の代替案は、Microsoft が公式に「シナリオ別」に整理していて、主に次の3つの方法があります。

Credential は ROPC という MFA 非対応の古い方式に依存するため、MFA/条件付きアクセスに対応できないため、2026年12月以降のモジュールでは削除される予定です。 

 

代替案①:対話型サインイン(人が実行するスクリプト向け)

こういう時に最適
  • 管理者が手元でスクリプトを実行する(手動運用)
  • MFA が有効(当たり前に要求される)

 


Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

この方法は モダン認証で MFA/条件付きアクセスに対応します。

Microsoft も管理者が対話的に接続するならこれを推奨しています。 

 

代替案②:アプリ専用認証(App-only:無人実行/スケジュール実行向け)

こういう時に最適
  • タスクスケジューラ、CI/CD、サーバー上の定期実行など “人がログインしない自動化”
  • Azure の外(オンプレ/他クラウド/ローカル)で動く自動化

Microsoft は、Credential の代わりとして証明書ベース or シークレットベースの App-only が推奨しています。

例(証明書サムプリント)
Connect-ExchangeOnline `
-AppId <AppId> `
-CertificateThumbprint <Thumbprint> `
-Organization "contoso.onmicrosoft.com"


ユーザーのパスワードを保存しない「アプリ(サービスアカウントのようなもの)」として接続するイメージです。

 

代替案③:マネージド ID(Azure 上の自動化向け・最も安全)

こういう時に最適
  • Azure Functions / Automation Account / Runbook など Azure 上で動く無人処理
  • “秘密情報(パスワード/シークレット)を置きたくない”

Microsoft は「Azure サービス内の自動化は Managed Identity が理想」と明記しています。


Connect-ExchangeOnline -ManagedIdentity

 

ポイント
  • “Azure が面倒な認証を肩代わりしてくれる
  • ”証明書やシークレット管理が不要

 

 

 

Credential パラメーターを利用しているのか確認するには?

Connect-ExchangeOnline や Connect-IPPSSession コマンドレットの実行時に Credential パラメーターを使用して認証情報を入力して Exchange Online やセキュリティコンプライアンスセンターに接続を行う場合、「ROPC」 という認証方式による接続方法となり、Microsoft Entra 管理センターの [サインインログ] から確認することが可能です。

 

Microsoft Entra 管理センターの [サインインログ] を確認する

1. 管理者アカウントより Microsoft Entra 管理センター (https://entra.microsoft.com) にサインインします。
2. 画面左メニューより [監視と正常性] > [サインインログ] の順にクリックします。
3. 検索期間を適宜変更 (過去 7 日間、過去 1 か月など) します。
※ 検索可能な日数は所有するライセンスによって異なり、最大 1 か月間となります。
 
4. [フィルターの追加] > [アプリケーション] の順に選択し、テキストボックスに "Microsoft Exchange REST API Based Powershell" と入力して [適用] をクリックします。
5. 認証プロトコル の値が "ROPC" と表示されている場合は、Credential パラメーターを使用した接続が行われておりますため、[ユーザー] の列から実行したユーザーを確認することができます。
※ 既定の状態では「認証プロトコル」 の項目は表示しない設定のため、画面上部の [ビューの管理] > [列の編集] とクリックし、「認証プロトコル」のチェックボックスにチェックをつ
け、[保存] をクリックしてください。

 

it-bibouroku.hateblo.jp

 

it-bibouroku.hateblo.jp

 

it-bibouroku.hateblo.jp

 

【Microsoft365参考書】PowerShellでMicrosoft Purview(旧セキュリティコンプライアンスセンター)に先進認証で接続する方法

PowerShellでMicrosoft Purview(旧セキュリティコンプライアンスセンター)に先進認証で接続する方法

この記事でわかること

  • PowerShellからMicrosoft Purview(旧セキュリティコンプライアンスセンター)に先進認証で接続する手順
  • 【最新版】モジュールのバージョンに関する正しい呼称
  • 【Tips】検索専用の軽量セッションで接続する方法

今回は、コンテンツ検索や保持ポリシー、DLPなどコンプライアンス関連の操作を行う際に必要となる、Microsoft Purview(旧称: セキュリティコンプライアンスセンター)への接続手順をご紹介します。

基本認証(ベーシック認証)は既に廃止されているため、先進認証(モダン認証)での接続が必須です。以下の手順は、多要素認証(MFA)を設定しているアカウントでも問題なく利用できます。

 

 

 

Microsoft Purviewへ接続する手順

※以下の手順のうち、モジュールのインストールに関する手順(後述の2〜4)は初回のみ必要です。次回以降は省略して問題ありません。

1. PowerShellを管理者として起動する

[Windows PowerShell] を右クリックし、[管理者として実行] をクリックして起動します。

2. 実行ポリシーを確認する

Get-ExecutionPolicy

表示結果が [RemoteSigned] ではない場合、以下のコマンドレットを実行してください。

3. 初回のみ:実行ポリシーを変更する

Set-ExecutionPolicy RemoteSigned

※警告メッセージが表示されるので、[Y] と入力して [Enter] キーを押してください。再度手順2に戻り、表示結果を確認してください。

4. 初回のみ:モジュールをインストールする

Install-Module -Name ExchangeOnlineManagement

※このコマンドでインストールされるのは、現行のExchangeOnlineManagementモジュール(V3)です。以前は「V2」と呼ばれていましたが、現在はV3が最新のバージョンとして提供されています。既にインストール済みの場合は Update-Module -Name ExchangeOnlineManagement で最新版に更新しておくことをおすすめします。

5. 初回のみ:モジュールを読み込む

Import-Module ExchangeOnlineManagement

※インストール後、自動的に読み込まれる場合もありますが、明示的に実行しておくとトラブルを避けやすくなります。

6. Microsoft Purviewへ接続する

[構文]
Connect-IPPSSession -UserPrincipalName <管理者のログインID>

[実行例]
Connect-IPPSSession -UserPrincipalName User01@contoso.com

※アカウントの資格情報入力が求められる画面が表示されたら、画面の指示に従い管理者のサインインメールアドレスとパスワードを入力してください(多要素認証を設定している場合は、あわせて認証を行います)。

補足
現行のモジュール(v3.2.0以降)では、既定でREST APIモードによる接続が行われるため、ローカルコンピューター側でWinRMの基本認証を有効化しておく必要はありません。古い情報では「WinRMの設定変更が必要」と案内されている場合がありますが、現在は原則不要です。

 

 

 

検索専用の軽量セッションで接続する

コンテンツ検索など、検索系の操作だけを行いたい場合は、-EnableSearchOnlySession パラメーターを付けて接続することで、より軽量なセッションで接続することも可能です(ExchangeOnlineManagement v3.9.0以降で利用可能)。

[実行例]
Connect-IPPSSession -UserPrincipalName User01@contoso.com -EnableSearchOnlySession

 

 

 

よくある質問

Q. Connect-IPPSSessionを実行すると「WinRM は処理を完了できません」というエラーが表示されます。
A. 別の記事で詳しく対処法をご紹介しています。あわせてご参照ください。

it-bibouroku.hateblo.jp

 

Q. 「EXO V2」と書かれている記事をよく見かけますが、今インストールされるのはV2ですか?
A. いいえ、現在 Install-Module -Name ExchangeOnlineManagement でインストールされるのは最新のV3です。V2という呼称は過去のバージョンのもので、現在は使われていません。

Q. Exchange Onlineへの接続(Connect-ExchangeOnline)と、この記事の接続は同じセッションで使えますか?
A. Connect-ExchangeOnlineConnect-IPPSSession は別々のセッションとして両方同時に接続しておくことができます。それぞれのコマンドレットがどちらのセッションに属するかを意識しながら利用してください。

 

 

 

まとめ

PowerShellからMicrosoft Purview(旧セキュリティコンプライアンスセンター)へ接続する際は、以下のポイントを押さえておきましょう。

  1. 初回のみ、実行ポリシーの変更とExchangeOnlineManagementモジュール(V3)のインストールが必要
  2. 接続は Connect-IPPSSession -UserPrincipalName <管理者のログインID> で行う
  3. 現行モジュールは既定でREST APIモード接続のため、WinRMの基本認証設定は原則不要
  4. 検索系の操作だけを行う場合は -EnableSearchOnlySession で軽量に接続できる

コンプライアンス関連の設定やコンテンツ検索を行う機会が多い方は、この手順をブックマークしておくと便利です。

 

 

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp

it-bibouroku.hateblo.jp