チーム共有チャネルは独自の課題をもたらします
組織は、Teams 共有チャネルのコンプライアンスとバックアップをどのように処理しますか?
チームの顧客は、当然のことながら、 パブリック プレビューでの共有チャンネル機能の差し迫った登場 3月に。お気に入りのテナントとのフェデレーション コラボレーションを実装できるのはうれしいことですが (図 1)、アプリケーションに主要な新機能を導入するには、独自の管理上の課題が伴います。
コンプライアンスの話題を取り上げます。マイクロソフトは、データ損失防止、アイテム保持ポリシー、通信コンプライアンスなどのすべてのMicrosoft 365コンプライアンステクノロジが共有チャネルで動作すると述べています。Microsoftの主張は正確であり、コンプライアンスは共有チャネルを所有するテナント内で発生するため、すべて可能です。つまり、すべての処理はホーム テナント内で行われ、共有チャネル内で作成および使用されるすべてのデータはそのテナントに残ります。
ホーム テナント内のデータの保持と管理は、Teams が通常のチャネルとプライベート チャネルでゲスト ユーザーによって生成されたデータのコンプライアンスを処理する方法に似ていますが、Azure AD B2B Connect のテナント間ポリシーに基づくテナント間のフェデレーション配置は、テナント間でデータが共有されることを意味すると考える人もいます。または、Teams が両方のテナントにデータのコピーを作成することもできます。
重複は可能だが実行不可能
技術的な観点から見ると、Microsoft 365 基板は、共有チャネルに関連するテナント内のデータを複製する可能性があります。重複は Teams メッセージでは簡単ですが、他のワークロードやアプリケーションが共有チャネルに関与するにつれて、ますます乱雑になります。たとえば、基質はテナントごとに重複する SharePoint サイトを作成し、ユーザーが作業するときにドキュメントとリストを同期できます。しかし、共有はどのように機能しますか?それとも情報保護?また、機密文書のコピーが他のテナントに残ることを本当に望んでいますか?
時間とエンジニアリングの才能は、問題を解決し、解決することができます。しかし、マイクロソフトは最初からシンプルに保つ原則を採用し、共有チャネルにはホストテナント上で残って管理される1つのデータセットがあると言うのが賢明だと思います。
共有チャネルのクラウド専用メールボックス
共有チャネル実装の興味深い側面は、クラウド専用メールボックス (“シャード メールボックス") を使用して、予定表アイテムやコンプライアンス レコードなど、チャネルで使用されるデータを保持することです。通常のチャネルではこの情報がグループ メールボックスに格納されますが、プライベート チャネルには予定表がなく、チャネル メンバーの個人用メールボックスにコンプライアンス レコードが格納されます。Microsoft は、クラウドのみのメールボックスがハイブリッド ユーザーとゲスト ユーザーのデータを保持する方法であるため、コンプライアンスに適していることを認識しています。この実装の大きな利点は、Microsoft がプライベート チャネルに対して行う必要があったように、共有チャネルに対して特別な保持処理を作成する必要がないことです。通常の Teams アイテム保持ポリシーは、ハイブリッドアカウントとゲストアカウントのコンプライアンスレコードを既に処理しています。これで、共有チャンネルのそれらを処理します。
コンプライアンス処理を 1 つのテナントに維持することで、コンプライアンス マネージャーが他のテナントのユーザーのアクティビティを管理する方法を考える必要がある場合でも、確かに問題が簡素化されます。明白な答えは、フェデレーションの会話を調査する必要があるときに、他のテナントと協力する手段に同意することです。この分野で物事がどのように発展するかを見るのは興味深いでしょう。
共有チャネルにクラウド専用メールボックスを使用すると、欠点があります。通常の管理インターフェイスとクライアント インターフェイスは、これらのメールボックスにアクセスできません。電子情報開示検索などのコンプライアンス処理がそれらのメールボックス内の情報を見つけることができる場合、これは大きな問題ではないように思えるかもしれません。この問題は、アプリケーションがパブリック API を使用して、バックアップやテナント間の移行などの目的で共有チャネル データにアクセスしようとする場合にあります。
チーム バックアップの課題
Teams は、既にバックアップが最も困難な Microsoft 365 アプリケーションです。Teams メッセージ用の Microsoft バックアップ API がなく、Teams と Planner などの他の Microsoft 365 アプリケーションとの統合の程度は、バックアップ ISV が Exchange Online からコンプライアンス レコードをコピーするなどの手法を使用することを余儀なくされていることを意味します。このアプローチでは、コンプライアンス記録が確実にコピーされます。データを復元しようとすると、問題が発生します。
マイクロソフトには、テナントベンダーへのバックアップとテナントが使用するベータ版のTeamsメッセージングAPIがあります。チャネル会話からコピーされたデータの復元は、次の内容を含む新しいメッセージとして終了します。g 元のトピックとそのすべての返信がターゲット チャンネルに投稿されました。これが元のデータの完全な表現でなくても、(必要に応じて)十分です。チャットメッセージは、ベータAPIがそれらを処理しなかったため、常に課題でした。
希望は、 チーム エクスポート API.10 月 1 日から一般公開されている新しい API は、バックアップ ISV が Teams のチャットとチャネル メッセージをコピーするために必要なすべてのものを提供するようです。もちろん、メッセージの復元は別の日の作業であり、テナント間のアクセス ポリシーやチャネル メンバーシップの名簿の修正などの問題が含まれます。
エクスポート API は、現在、通常のチャネルとプライベート チャネルを処理できます。Microsoftは、Export APIが共有チャネルを処理できるかどうかは明らかにしていない。この機能が利用可能になるというのが妥当な前提ですが、いつこれが起こるかについての情報はありません。そして、そのような能力が実行可能になったとしても、まだあります マイクロソフトが API に使用している課金モデルの問題.マイクロソフトは提供している 充電の仕組みに関するガイドライン エクスポート API を使用して Teams メッセージをエクスポートする場合、これらのガイドラインは、Teams メッセージングのボリュームが重い、中程度、および軽いものを含む、さまざまな種類のテナントの課金パターンに調整する必要があります。
バックアップベンダーが潜在的な顧客と話し合うのは、製品がこのような課金モデルを持つAPIに依存している場合、困難です。マイクロソフトは、お客様が Teams Export API を一定期間無料で使用してデータを収集し、許容可能な課金体制を把握できるようにすると思います。これが完了すると、テナントは Azure サブスクリプションを使用して消費するバックアップ トランザクションの料金を支払う可能性があります。
共有チャネルは、テナント間のコラボレーションにとって素晴らしい一歩です。すべてのテクノロジと同様に、その実装と管理には新しい API とテクノロジが必要です。学習は続きます!
このような洞察は簡単には得られません。テクノロジーを知り、舞台裏の見方を理解する必要があります。の知識と経験から利益を得る Office 365 for IT プロフェッショナル Office 365とより広いMicrosoft 365エコシステムをカバーする最高の電子書籍を購読することでチーム。