WORKS

事例紹介

お客様のニーズに合わせた最適なソリューションをご提供しています。
ご利用いただいているお客様の事例を紹介します。

  • インフラ構築
  • Microsoft Azure
  • Entra ID
  • AVD

Azure Virtual Desktop 導入(不動産業(一般、企業向け物件、販売、管理))

システム概要

Azure Virtual Desktop 導入(PoC実施後、本番環境構築)

導入期間

4ヶ月

課題と効果

課題
顧客環境においてAVD導入におけるEntraIDとは異なるID管理を導入しており、影響が不明
効果
Oktaを導入されており、それらの認証はEntraID、オンプレミスドメイン環境ともに依存する環境であった為、EntraIDの認証を使わず、またAVDのコントロールプレーン経由での接続もしないサードパーティ製のリモート接続ツールをを用いて提供することで解消
課題
社内NWをVPN網に設定されていることによる外部からのAVD接続経路の限定
効果
ExpressRouteで社内VPN網へ接続し、Azure側、オンプレミス側のNWの設計、設定をすることで解消
課題
Azure環境の運用を顧客側で行った実績が無い
効果
Azure Portalへの接続からを記述した管理者向け手順書を作業単位で用意し、利用者向けにトレーニングデモを行うことで対応

目的

顧客のパートナー向けに社内システムを利用してもらう為、顧客端末の貸与、VPN接続のコスト削減が目的。
PoCを行う必要があったのはOktaでID管理をしており、AVDの利用が可能であるか調査が必要であった。

ポイント

AVDの設計、構築に伴い、既存Azureに新規サブスクリプションを追加し構築が可能であるかの検証、判定がPoCのメインでした。
一番のネックは、Oktaの利用実績が無い中、Microsoft、顧客への仕様確認と合わせ、現状の調査と生じた課題の回避策の用意がありました。
検証環境を提供側で簡易な本番模倣環境を用意し、検証環境と本番環境で確認できる範囲を定めて、本番でしかできない部分については顧客側の全体に影響を及ぼす箇所について説明を実施しています。

提案内容については顧客側のステークホルダーに対し行い、PoCの前進判定を得て本番環境構築に至っています。
週次定例でスケジュール、課題管理を行い、コミュニケーションを柔軟に行うことで課題に対して顧客側も安心してできないものはできないと別案に対して前向きに歩を進めることが出来ました。

本来AVDはMicrosoftが提供しているAVDのサービスを利用して接続するのが一般的ですが、今回はAVDの管理機能、FAT端末に代わるマスタOS管理といった必要であることを明確にした機能のみの利用に絞り込むことで制限がある環境でもAVDを社外から利用することができる設計、構築となっています。

本案件ではAVDの基本機能と合わせて下記構成を用意することで社外からの接続を実現しています。
・サードパーティ製のリモート接続ツール(接続元、MACアドレス制限、独自のID/PW接続)
・PoC時はオンプレミスドメインのADサーバがAzure上にあったのでVNETピアリング設定
その後本番環境構築ではExpressRoute回線を接続に切り替えることで顧客NW内への接続制限を回避。

作業期間はPoC2ヶ月、本番2カ月と短期間での調査、構築となりましたが、検証、調査を先に網羅的に対応することでリリースにも影響なく納品することが出来ました。

パブリッククラウド:Microsoft Azure
仮想VDI:Azure Virtual Desktop
リモートアクセスツール:顧客製品の為、名称は非公開。(httpプロトコルでの画面転送、アクセス制限機能あり)

参加フェーズ:PoC、基本設計、詳細設計、構築/テスト、本番導入、管理者向け手順書作成

事例管理№:20240003

  • インフラ構築
  • Microsoft Azure
  • Entra ID

インフラ基盤更新【金融業/クレジットカード】

システム概要

インフラ基盤更改
弊社は認証基盤のADサーバ、Azure AD(Entra ID)を担当。

導入期間

12ヶ月

課題と効果

課題
オンプレミスとAzure同期の対応実績者がプロジェクト内に存在しないため、実証確認から対応を行う必要があった
効果
オンプレミスドメインユーザでWindows端末にサインインのみでMicrosoft 365のサービスを利用可能とするシングルサインオンを実装し、ユーザサインイン負荷を軽減した
課題
ADサーバは更改前資料が最新化されているかが誰も分からない状態となっていた。
実機調査が必要であった
効果
エンドユーザの運用中本番ADサーバに入り、更新箇所を確認するこで、更改ADサーバで必要な要素を洗い出して手戻りすることがない設計書を作成することが出来た
課題
Azure環境の知識が少ない対応であったため、実働確認までに時間がかかった
効果
プロジェクトチーム内のAzure有識者とMicrosoftサポートと連携し、ヒントを得て最小時間で実働確認が実施出来た

目的

オンプレミスユーザ名と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