事例紹介

オンプレミスユーザ名とMicrosoft 365ユーザ名が同一ではない情報を同期させ、Windows端末のドメインユーザサインインのみでMicrosoft 365サービスが利用できるシングルサインオン環境を実装する。

エンドユーザ様のITインフラ環境をすべて更改する案件の中で、従業員が利用するユーザID、Windows端末やサーバを管理する認証基盤を担当しました。
認証基盤ではオンプレミスのADサーバとAzure AD(Entra ID)が存在し、その両方を同期(移行)し、シングルサインオンの仕組みを実装することが目的です。
オンプレミスユーザ名とMicrosoft 365ユーザ名が異なるメールアドレスを利用しており、そのユーザ情報を同期させる必要がありました。
その対応を行うため、自身も含めたプロジェクトチームメンバーに対応した前例が無かったので調査、検証、実証確認で以下の課題がありました。
・オンプレミスとクラウドの異なるユーザ情報の同期方式の確立と、その実証確認を求められる
・数千ユーザを対象にした本番環境への移行方法の確立
・事前調査作業のタスクが詳細に計画されていない

【同期方式の確立と、その実証確認】
Microsoft Azureサポートへ問い合わせ、過去事例が存在するのかの調査を経てAzure検証環境にていくつものシナリオを検証し、動作実証の確認をすることができました。
ADサーバのユーザ属性情報とAzure AD(Entra ID)のユーザ属性情報がどのように同期されているのかを理解整理し、その双方が正しく同期されているかを確認する必要がありました。

【本番環境への移行】
本番環境への移行は数千ユーザを対象に行うため、日をずらした10回の段階的移行としました。
しかし、日々の運用の中でユーザの登録、更新、削除が頻繁に行われており、前回移行した内容と現時点の内容が異なる問題が発生しました。
その対策として、各移行作業の冒頭で対象ユーザの比較と差分対応を実施しました。
長時間停止することができない移行であったため、移行前に差分認識と対応を行い停止することなく移行を実施しました。

本プロジェクトは事前の調査作業のタスクを詳細に分割し計画していなかったという問題があり、本来進めるべき上流工程の設計書作成と並行して対応する必要がありました。
調査内容を事前に洗い出し、調査内容を役割分担することで、対応時間を短縮することができました。
また、情報共有を密にとることで、類似の事象について重複した調査作業にならないよう対応することでプロジェクト全体の推進に貢献することができました。

構築、移行、テストについては、計画段階でどれだけ問題を解消することができるかを実践したことにより、問題なく進行することができました。

本プロジェクトを通して前例が無くともチームで協力して進めることで限られた時間の中で完了することが可能であることを体現することが出来ました。

OS：Windows Server 2019
DB：SQL Server
ミドルウェア：AzureAD Connect（Microsoft Entra Connect)、Active Directory
IaaS：Azure
SaaS：Intune、Azure Backup、Azure AD(Entra ID)

参加フェーズ：要件定義、基本設計、詳細設計、構築／テスト、本番移行

事例管理№：20230003

Exchange Server 2013のサポート期限切れに伴うExchange Onlineへの移行

お客様は海外へも展開する大規模な製造業で移行対象ユーザー数も数万人・海外も含めた関係会社も複数社という環境でした。
制としてメンバー全てがExchange Serverの経験はあるものExchange Onlineの経験者が少ない状況でした。
作業着手にあたり、以下を事前準備として進めました。
・Exchange ServerとExchange Onlineの互換、非互換の確認
・Exchange ServerとExchange Onlineの設定方法の違いの確認
・進め方の整理（WBSの整理）
必要に応じて、マイクロソフト社のサポートに協力をしていただきました。

要件定義・基本設計・詳細設計フェーズに於いては
Exchange Serverでご利用中の機能は全て移行することと、現状課題への対応及び、新たな機能の追加を行うというお客様の要件に対してExchange ServerとExchange Onlineの機能マッピングを行い、移行可否を抽出しました。
移行可能な要件については具体的な移行方法を設計し、移行不可能な要件については代替案の提案と検討を行いました。
移行不可能な主な要件は次に３点があり
①クロスプレミス環境において、Exchange Onlineとオンプレミスのユーザー間で予定表の中身が参照できないことがある
②移行前のOutlookの予定表リストが消えることがある
③予定表共有/フルアクセス権/代理人、代理人送信権限等のADオブジェクト権限を設定されている同士について同時に移行しないといけない対応を次の通りに実施しました。
・同一OU(部・課)に関してはグルーピングを事前に実施し、クロスプレミス環境が極力発生しないようにする
・Outlook on the Webであれば消えないため、Outlook on the Webの予定表から戻す
・ADオブジェクト権限を設定されている同士をグルーピングを実施しての移行を行う

構築、テストにフェーズに於いては、設計フェーズにて移行対象の確定と移行方法の確立をお客様のご協力の下、行うことが出来たこともあり、設計通りに実施することが出来ました。
構築後の移行につては、お客様環境がグローバルかつ、大規模ということもあり、非常に苦労するところが多くありました。
移行計画立案時は、多くの課題があり対応の検討が必要でした。
【主な検討事項】
・配布グループがオンプレミスとオンラインの両方に存在する場合、外部からのメールがループを発生する可能性がある。
・オンプレミスとオンラインで、メールの添付ファイルの容量制限が異なるため、メールのブロックを発生させる可能性がある。
・移行バッチを作成し、Load Balancerでバッチを分散し、Exchange Onlineへ移行する方法でパフォーマンスが足りなかった場合の対応方法。
【対応方法】
・配布グループについて、移行期間の最後にまとめて移行を行う。メールループが発生したNDRについて、既定値では、送信者のみに返されることになっているため、配布グループの管理者に返されるようにコマンドで設定を行う。
・エッジ トランスポート サーバーの添付ファイルフィルターを無効にして、サイズ制限を設定して添付ファイルを受け取れるようにする。
・他の移行方式として以下を検討
①Load Balancerを通さないで移行。
②Hybrid構成を追加して移行。
③回線を固定して、Exchange Onlineで回線のIPを指定して並行利用を行う
④空のメールボックスフォルダーを削除するか、メールボックスフォルダーを統合する
⑤MRSProxyのエクスポートバッファーのサイズを大きくする

移行計画に際しては、多ユーザ、多拠点に加え、海外の時差も考慮して実施することもあり、多くの時間を必要としました。

移行計画完了に至るまで、多くの時間を使い、密にお客様とコミュニケーションをとりながら、移行の実現方法を具体的に確定出来たことが成功にポイントだったと思っています。
また、当社の経験値としてもExchange Onlineのスキルが格段にあがり、次の類似作業へ繋がるプロジェクトとなりました。

OS：Windows Server 2019
DB：SQL Server
SaaS：Exchange Hybrid Server、Exchange Online

参加フェーズ：要件定義、基本設計、詳細設計、構築／テスト、移行設計、移行計画

事例№：20210001