WEBVTT

00:00:00.120 --> 00:00:04.660
m365fmのマイクロソフトナレッジ ナゲットへようこそホストを務める

00:00:04.660 --> 00:00:07.380
ミルコピーターズです今日のトピック は誰もが名前は聞いたことがある

00:00:07.380 --> 00:00:09.640
ものの本当の意味を理解している 人は少ないものですアジュール

00:00:09.640 --> 00:00:13.060
バーチャルデスクトップavdについて です一体何なのでしょうか単なる

00:00:13.060 --> 00:00:15.740
クラウド上のリモートpcなのでしょうか それとももっと大きな何かでしょうか

00:00:15.740 --> 00:00:19.160
多くの人はその名前を聞いて単なる vpnの代替手段やアジュールの仮想

00:00:19.160 --> 00:00:21.960
マシンを借りる方法だと考えています 自宅から職場のコンピュータに

00:00:21.960 --> 00:00:24.660
接続するリモートデスクトップ ツールと混同している人もいます

00:00:24.660 --> 00:00:28.640
実はそのどれでもありませんそれ よりも遥かに大きなものですクラウド

00:00:28.640 --> 00:00:32.180
から安全に提供される完全なデスク トップ体験なのですこのエピソード

00:00:32.180 --> 00:00:36.540
の終わりにはavdの本質仕組みそして 企業がなぜavdへ移行しているのか

00:00:36.540 --> 00:00:39.920
が理解できるでしょうマーケティング の飾り言葉ではなく全体像を把握

00:00:39.920 --> 00:00:42.840
できるよう確信となる構成要素 をわかりやすく解説します

00:00:42.840 --> 00:00:46.060
アジュールバーチャルデスクトップ とは何でしょうか全体像を見て

00:00:46.060 --> 00:00:49.040
いきましょう最もシンプルな定義 はこうですアジュールバーチャル

00:00:49.040 --> 00:00:51.780
デスクトップとはwindowsとwindows アプリケーションをクラウドから

00:00:51.780 --> 00:00:54.360
あらゆるデバイスへ提供するもの ですストリーミングサービスを

00:00:54.360 --> 00:00:57.160
創造してください映画やテレビ 番組をストリーミングする代わり

00:00:57.160 --> 00:01:00.220
に仕事のデスクトップと業務アプリ をストリーミングするのですネット

00:01:00.220 --> 00:01:03.180
フリックスが自社サーバーで負荷 を処理するようにavdはアジュール

00:01:03.180 --> 00:01:05.420
サーバーでコンピューティング を処理しますネットフリックス

00:01:05.420 --> 00:01:08.800
の仕組みはご存知でしょうテレビ スマホノートpcでアプリを開けば

00:01:08.800 --> 00:01:11.540
どのデバイスでも同じ体験が 得られます処理保存レンダリング

00:01:11.540 --> 00:01:13.820
といった実際の重い作業はすべて ネットフリックスのサーバー上で

00:01:13.820 --> 00:01:16.080
行われますあなたのデバイスは そのコンテンツを表示するための

00:01:16.080 --> 00:01:18.780
窓口にすぎませんネットフリックス と同じようにavdを利用するために

00:01:18.780 --> 00:01:21.440
高性能なデバイスは必要ありません 実際の作業はクラウドで行われる

00:01:21.440 --> 00:01:24.420
からですavdも同じ仕組みです ユーザーはすべてのアプリが入った

00:01:24.420 --> 00:01:27.000
フル機能のwindowsデスクトップ を利用しますが実際のコンピューティング

00:01:27.000 --> 00:01:29.580
はazureで稼働する仮想マシン 上で行われますローカルのデバイス

00:01:29.580 --> 00:01:32.680
はリモートマシンで起きている ことを表示しているだけですwindows

00:01:32.680 --> 00:01:37.680
ノートpcmacipadchromebookさらには osの動作がやっとの古いpcでも

00:01:37.680 --> 00:01:41.200
構いませんwindowsアプリを動かせる 環境さえあれば大丈夫ですwindows

00:01:41.200 --> 00:01:43.660
アプリはどのデバイスにもインストール できる軽量なクライアントであり

00:01:43.660 --> 00:01:46.480
avdサービスに接続してリモート デスクトップを表示しますそれだけ

00:01:46.480 --> 00:01:50.220
で十分なのですここで重要な 違いを説明します一人一人にpcを丸ごと

00:01:50.220 --> 00:01:52.880
借りるわけではありませんそう ではなく管理された共有環境に

00:01:52.880 --> 00:01:55.720
接続するのですそしてここから が重要な点ですマルチセッション

00:01:55.720 --> 00:01:58.140
と呼ばれる機能により一台のwindows マシンで複数のユーザーが同時

00:01:58.140 --> 00:02:00.700
に作業できるようになります通常 のwindowsは一度に一人のユーザー

00:02:00.700 --> 00:02:03.600
が利用することを前提に設計されて いますavdはその常識を変えます

00:02:03.600 --> 00:02:06.460
一般的なwindowsノートpcでは一度 にログインできるのは一人だけです

00:02:06.460 --> 00:02:10.020
それがwindowsの仕組みだからです しかしavdを使えば一台のwindows

00:02:10.020 --> 00:02:12.340
マシンに複数のユーザーが同時 にアクセスできます各ユーザー

00:02:12.340 --> 00:02:14.620
は個別に分離されたセッション を持ち独自のアプリケーション

00:02:14.620 --> 00:02:17.520
やファイルを利用できますそれ らはすべて基盤となる同じ仮想

00:02:17.520 --> 00:02:20.520
マシンを共有していますこれは 通常のノートpcでは不可能なこと

00:02:20.520 --> 00:02:24.100
でありavdが企業のコストを大幅 に削減できる大きな理由の一つです

00:02:24.100 --> 00:02:28.420
avdはazure上で実行される仮想 マシンで動作しますが複雑なバック

00:02:28.420 --> 00:02:31.580
エンド処理はすべてmicrosoft が管理しますユーザーを適切な

00:02:31.580 --> 00:02:34.600
セッションホストへ誘導する ブローカー接続を処理するゲート

00:02:34.600 --> 00:02:37.860
ウェイそして利用可能なマシン へユーザーを分散させる負荷分散

00:02:37.860 --> 00:02:41.340
などですこれらをご自身で構築 する必要はありませんホストプール

00:02:41.340 --> 00:02:44.800
を作成しアプリケーションを設定 しユーザーを割り当てるだけで

00:02:44.800 --> 00:02:48.080
済みますitチームにとっては管理 が簡素化されハードウェアコスト

00:02:48.080 --> 00:02:51.500
も削減されますではこれがなぜ 重要なのでしょうかつまりユーザー

00:02:51.500 --> 00:02:53.740
は場所やデバイスを問わず完全な windowsエクスペリエンスを利用

00:02:53.740 --> 00:02:56.580
できるということですmacを使っている グラフィックデザイナーもwindows

00:02:56.580 --> 00:02:59.640
専用のデザインソフトを実行 できます現場の作業員もタブレット

00:02:59.640 --> 00:03:03.200
からデスクで使うのと同じ業務用 アプリにアクセスできますまた

00:03:03.200 --> 00:03:07.200
受け負い業者は個人のノートpcから ログインし自分のマシンに何も

00:03:07.200 --> 00:03:10.300
インストールすることなく安全に 作業できますデータはazureデータ

00:03:10.300 --> 00:03:13.980
センターから外部に出ないため紛失 や盗難の恐れがあるノートpcに保存

00:03:13.980 --> 00:03:17.020
するよりも安全ですこれはユーザー とit部門の両方にとってメリット

00:03:17.020 --> 00:03:20.160
がありますしかしなぜavdが存在 するのかを理解するにはそれが解決

00:03:20.160 --> 00:03:22.720
する課題に目を向ける必要があります その点については次のセグメント

00:03:22.720 --> 00:03:26.980
で解説します従来の方法と新しい 方法の比較です従来の方法はシンプル

00:03:26.980 --> 00:03:31.060
でした全従業員に高性能なノートpc を購入し必要なアプリをすべて

00:03:31.060 --> 00:03:34.040
インストールして1台ずつ管理 していましたそして3から4年ごと

00:03:34.040 --> 00:03:37.000
にハードウェアをすべて入れ替え また最初からやり直すのですしかし

00:03:37.000 --> 00:03:40.200
問題はその背後に膨大な隠れた コストがあったことですitチーム

00:03:40.200 --> 00:03:42.800
は展開セキュリティパッチの適用 トラブルシューティングに何時間

00:03:42.800 --> 00:03:45.740
も費やしていましたノートpcが 紛失や故障をすれば交換してすべて

00:03:45.740 --> 00:03:47.900
を再インストールする必要があり ユーザーがファイルをバックアップ

00:03:47.900 --> 00:03:50.140
していることを祈るしかありません でしたウイルスに感染した場合

00:03:50.140 --> 00:03:52.440
はマシンを初期化してゼロから やり直さなければなりません

00:03:52.440 --> 00:03:55.380
でしたやがてリモートワークが 普及しこの従来の方法は完全に

00:03:55.380 --> 00:03:59.500
通用しなくなりましたvpnは低速で 扱いにくく自宅のpcは安全とは

00:03:59.500 --> 00:04:03.140
言えず会社のデータは紛失盗難 侵害のリスクがあるデバイスに

00:04:03.140 --> 00:04:06.400
保存されていましたエンドポイント を管理できていなくてもその中に

00:04:06.400 --> 00:04:09.380
あるデータの保護は依然として 企業の責任でしたアジュールバーチャル

00:04:09.380 --> 00:04:13.520
デスクトップ略してavdを使った 新しい方法では状況が全く異なります

00:04:13.520 --> 00:04:16.800
負荷の高い処理はローカルデバイス ではなくアジュール上で行われます

00:04:16.800 --> 00:04:20.220
ノートpcやタブレットスマホは クラウド環境を除くための窓に

00:04:20.220 --> 00:04:23.820
すぎません実際の作業やアプリケーション ファイル処理はすべてデータ

00:04:23.820 --> 00:04:27.100
センター内に止まりますこれは 大きな転換ですpcを紛失しても

00:04:27.100 --> 00:04:29.980
データは失われません別のデバイス を用意してavdに再ログインすれば

00:04:29.980 --> 00:04:32.280
作業を中断した場所からすぐに 再開できますファイルはそこに

00:04:32.280 --> 00:04:35.040
ありアプリケーションの設定も 個人の環境もそのまま残っています

00:04:35.040 --> 00:04:38.760
デバイス自体が消耗品になった のです支払いの仕組みも変わります

00:04:38.760 --> 00:04:42.780
数年ごとの多額の設備投資で 何百台ものpcを買い揃える代わり

00:04:42.780 --> 00:04:46.380
に運用コストへとシフトできます 使用した分だけ支払うのです

00:04:46.380 --> 00:04:50.520
今日50人明日100人が作業する なら規模を拡大できます翌月に

00:04:50.520 --> 00:04:54.460
人数が減れば規模を縮小できます 高価なハードウェアを抱えたり急

00:04:54.460 --> 00:04:57.960
な需要に慌てて買い足したりする 必要はありません次にこれを実現

00:04:57.960 --> 00:05:02.020
する実際の構成要素を最も重要な ものから見ていきましょう構成要素

00:05:02.020 --> 00:05:06.600
その1ホストプールとセッションホスト です最初の構成要素はホストプール

00:05:06.600 --> 00:05:10.160
と呼ばれます名前の通りwindows デスクトップやアプリを提供

00:05:10.160 --> 00:05:14.060
する仮想マシンの集合体です 全て同じ設定で構成されユーザー

00:05:14.060 --> 00:05:17.240
がいつでも接続できるpcのグループ だと考えてくださいそのプール

00:05:17.240 --> 00:05:21.140
内の個々のマシンはセッションホスト と呼ばれますこれらは通常マルチ

00:05:21.140 --> 00:05:24.240
セッション版のwindows11エンタープライズ を実行している実際の仮想マシン

00:05:24.240 --> 00:05:27.680
ですつまり複数の人が同時に同じ マシンにログインしそれぞれが

00:05:27.680 --> 00:05:31.180
独立したセッションを使えるということ ですさてホストプールには2種類あり

00:05:31.180 --> 00:05:34.680
その違いはコストと柔軟性に影響 しますプール型ホストプール

00:05:34.680 --> 00:05:37.900
はホテルに例えられます複数の ゲストが滞在しますが特定の

00:05:37.900 --> 00:05:40.020
部屋が割り当てられているわけ ではありませんチェックイン時に

00:05:40.020 --> 00:05:43.220
空いている部屋に入りチェック アウトすればその部屋は次は別の

00:05:43.220 --> 00:05:46.040
誰かのものになりますプール型 ホストプールではユーザーは

00:05:46.040 --> 00:05:49.140
その時点で容量に余裕のあるセッション ホストに割り当てられます今日は

00:05:49.140 --> 00:05:52.120
マシンaを使っていても明日は マシンbを使うかもしれません

00:05:52.120 --> 00:05:54.560
これはより少ないマシンで多くの ユーザーを収容できるため

00:05:54.560 --> 00:05:57.400
多くのナレッジワーカーにとって 非常に効率的です個人用ホストプール

00:05:57.400 --> 00:06:00.580
は自分専用のアパートのような ものです自分専用で他の人は使わず

00:06:00.580 --> 00:06:03.760
自分の持ち物がそこにあります 自分の設定自分のファイルです

00:06:03.760 --> 00:06:06.860
ログインするたびに同じマシン が割り当てられますこれは一貫

00:06:06.860 --> 00:06:09.720
したパフォーマンスを必要とする パワーユーザーや共有環境では

00:06:09.720 --> 00:06:12.260
うまく動作しない特殊なソフトウェア をインストールする必要がある

00:06:12.260 --> 00:06:15.300
場合に便利ですただしユーザー ごとに専用のvmが必要になる

00:06:15.300 --> 00:06:19.360
ためコストは高くなりますさてここ からが面白いところですavdはユーザー

00:06:19.360 --> 00:06:21.180
がどのセッションホストに割り 当てられるかをどのように判断

00:06:21.180 --> 00:06:23.700
するのでしょうかそれがロード バランシングであり2つの手法

00:06:23.700 --> 00:06:26.500
がありますブレッドスファースト 幅優先とはシステムが利用可能な

00:06:26.500 --> 00:06:28.500
すべてのセッションホストにユーザー を均等に分散させる方法です

00:06:28.500 --> 00:06:31.780
例えば10台のマシンに100人のユーザー がいる場合各マシンに約10人が

00:06:31.780 --> 00:06:34.140
割り当てられますこれにより特定 のホストが過負荷になることが

00:06:34.140 --> 00:06:36.500
なく一貫したパフォーマンス が得られるためほとんどの展開で

00:06:36.500 --> 00:06:39.320
デフォルト設定となっています デプスファースト深さ優先はその

00:06:39.320 --> 00:06:42.100
逆です一つのセッションホスト を完全に満たしてから次のホスト

00:06:42.100 --> 00:06:45.240
へ移動しますユーザー1から10は 全てマシンAにユーザー11から20

00:06:45.240 --> 00:06:48.220
はマシンBにという具合ですなぜ このようなことをするのでしょうか

00:06:48.220 --> 00:06:51.340
空のマシンの電源を切ることが できるからですマシンAとマシンB

00:06:51.340 --> 00:06:54.240
が満杯になればマシンCからZを シャットダウンしてコストを節約

00:06:54.240 --> 00:06:57.860
できます深さ優先はオートスケーリング と非常に相性が良くそれが次の要素

00:06:57.860 --> 00:07:01.460
であるスケーリングですAVDを設定 してログインしている人数に基づいて

00:07:01.460 --> 00:07:04.240
セッションホストを自動的に追加 または削除できますピーク時には

00:07:04.240 --> 00:07:08.100
20台のマシンを稼働させておける かもしれません夜間にはわずか2台

00:07:08.100 --> 00:07:11.120
で済むかもしれませんシステム は定義したスケジュールに基づいて

00:07:11.120 --> 00:07:14.540
これを自動的に処理しますここで 真のコスト削減効果が発揮されます

00:07:14.540 --> 00:07:17.220
使用されていないマシンに対して 料金を支払う必要はありません

00:07:17.220 --> 00:07:20.460
ではなぜこれが重要なのでしょうか 深さ優先のロードバランシング

00:07:20.460 --> 00:07:22.560
とオートスケーリングを組み合わせ たプール型ホストプールはコスト

00:07:22.560 --> 00:07:25.580
を大幅に削減できますユーザー 全員分を購入する代わりにピーク

00:07:25.580 --> 00:07:28.520
時の同時利用人数分だけを用意 すれば良くそのマシンも実際に

00:07:28.520 --> 00:07:31.580
作業している時間だけ稼働させる ことができますこれでvmを含む

00:07:31.580 --> 00:07:34.320
ホストプールが用意できましたでは ユーザーはどのようにしてアプリ

00:07:34.320 --> 00:07:37.160
を利用するのでしょうか構成要素 の2つ目アプリケーショングループ

00:07:37.160 --> 00:07:39.600
ですアプリケーショングループ とはユーザーが何にアクセス

00:07:39.600 --> 00:07:42.340
できるかを決定する論理的な コンテナですこれらを権限セット

00:07:42.340 --> 00:07:45.640
と考えてください完全なデスクトップ か特定のアプリケーションのみ

00:07:45.640 --> 00:07:48.720
を提供しますタイプは2つあります デスクトップアプリケーショングループ

00:07:48.720 --> 00:07:51.680
ではユーザーはwindowsのデスクトップ 環境全体を利用できますログイン

00:07:51.680 --> 00:07:53.860
するとスタートメニュータスク バーファイルエクスプローラー

00:07:53.860 --> 00:07:56.660
など全てが表示されます見た目も 操作感も通常のwindowsコンピュータ

00:07:56.660 --> 00:07:59.400
と変わりません基本的には その通りだからですほとんどの企業

00:07:59.400 --> 00:08:01.760
はここから始めますリモート アプリのアプリケーショングループ

00:08:01.760 --> 00:08:04.320
は少し異なりますユーザーにフル デスクトップを提供する代わり

00:08:04.320 --> 00:08:07.200
に個別のアプリケーションを提供 しますここからが魔法のような

00:08:07.200 --> 00:08:09.960
部分ですそれらのアプリケーション はユーザーのデバイス上でローカル

00:08:09.960 --> 00:08:13.020
に実行されているように見えます ワードを開くとmacやタブレット

00:08:13.020 --> 00:08:16.500
上のローカルアプリと並んで独自 のウィンドウに表示されますデスクトップ

00:08:16.500 --> 00:08:20.060
の背景や仮想マシンのインターフェース は表示されずアプリケーションがシームレス

00:08:20.060 --> 00:08:23.120
に実行されるだけですワード エクセルそしてカスタムの業務

00:08:23.120 --> 00:08:25.660
ツールという3つのアプリケーション しか必要としないユーザーを想像

00:08:25.660 --> 00:08:28.500
してみてくださいリモートアプリ ならそれら3つのアプリだけを公開

00:08:28.500 --> 00:08:30.920
できますユーザーがwindowsアプリ を開いて3つのアイコンを確認し

00:08:30.920 --> 00:08:33.320
どれかをクリックするとそのアプリケーション が独自のウィンドウで開きます

00:08:33.320 --> 00:08:36.060
デスクトップが表示されることは なくその必要もありませんタスク

00:08:36.060 --> 00:08:39.120
ワーカーにとっては遥かにすっきり とした体験ですここで重要な詳細

00:08:39.120 --> 00:08:41.620
をお伝えしますリモートアプリ はプール型ホストプールでのみ

00:08:41.620 --> 00:08:44.680
利用可能です個人用ホストプール を使用していない限りフルデスクトップ

00:08:44.680 --> 00:08:48.020
体験に限定されますそれがこの 技術の仕組みなのですしかしここ

00:08:48.020 --> 00:08:50.740
からが強力な点ですユーザー には異なるホストプールにまたがる

00:08:50.740 --> 00:08:52.860
複数のアプリケーショングループ を割り当てることができますつまり

00:08:52.860 --> 00:08:55.640
あるユーザーは一方のホストプール からのデスクトップアプリケーショングループ

00:08:55.640 --> 00:08:58.100
ともう一方からのリモートアプリ グループの両方を持つことができます

00:08:58.100 --> 00:09:00.880
そのユーザーがwindowsアプリに ログインするとフルデスクトップ

00:09:00.880 --> 00:09:03.480
アイコンと個別のアプリアイコン の両方が表示されますユーザー

00:09:03.480 --> 00:09:07.100
は必要な方を選択できます実際 にはどのように機能するのでしょうか

00:09:07.100 --> 00:09:09.980
アプリケーショングループを作成 しazure adのユーザーまたはグループ

00:09:09.980 --> 00:09:12.800
に割り当てると次にユーザー がwindowsアプリを開いたときにそれら

00:09:12.800 --> 00:09:15.800
のリソースが自動的に表示され ます手動設定や構成ファイルリンク

00:09:15.800 --> 00:09:19.140
の送信などは一切不要ですただ 表示されるだけですしかしユーザー

00:09:19.140 --> 00:09:21.640
がこれらのリソースを見つける 方法が必要ですそこで登場する

00:09:21.640 --> 00:09:24.960
のがワークスペースです構成要素 の3つ目ワークスペースですホスト

00:09:24.960 --> 00:09:27.560
プールとアプリケーショングループ は準備できましたがユーザーがこれら

00:09:27.560 --> 00:09:30.340
すべてのリソースを見つけてアクセス する手段が必要ですそこで登場

00:09:30.340 --> 00:09:33.200
するのがワークスペースですワーク スペースとはアプリケーショングループ

00:09:33.200 --> 00:09:35.900
を論理的にまとめたものですwindows アプリを開いたときにユーザー

00:09:35.900 --> 00:09:38.700
に見えるものがこれですスマホ でアプリを整理するフォルダのような

00:09:38.700 --> 00:09:41.620
ものだと考えてくださいスマホ を開いてすべてのアプリが画面

00:09:41.620 --> 00:09:44.140
上に散乱しているのを見ること はありませんよねゲームは一つの

00:09:44.140 --> 00:09:46.520
フォルダ生産性ツールは別の フォルダといった具合にグループ

00:09:46.520 --> 00:09:49.280
化されていますワークスペース はavdリソースに対しても同じこと

00:09:49.280 --> 00:09:51.700
を行いますすべてのアプリケーション グループは必ずワークスペース

00:09:51.700 --> 00:09:54.660
に関連付ける必要がありますこれは 避けられませんアプリケーショングループ

00:09:54.660 --> 00:09:57.440
を作成してもワークスペースに接続 しなければユーザーはそれを見る

00:09:57.440 --> 00:09:59.860
ことができませんバックグラウンド には存在しますが誰もアクセス

00:09:59.860 --> 00:10:02.720
できない状態になりますワークスペース こそがそれを表示可能にするもの

00:10:02.720 --> 00:10:05.380
なのですユーザーの視点からどの ように見えるかを見てみましょう

00:10:05.380 --> 00:10:08.860
ユーザーがデバイスでwindowsアプリ を開き仕事用アカウントでサイン

00:10:08.860 --> 00:10:12.260
インすると割り当てられたすべて のリソースデスクトップアプリケーション

00:10:12.260 --> 00:10:15.540
などがワークスペースごとに整理 されて表示されます手動でのセットアップ

00:10:15.540 --> 00:10:18.840
や構成ファイルit部門から送られて くるリンクをクリックする必要もありません

00:10:18.840 --> 00:10:22.940
ただそこに現れるのです様々な シナリオに合わせて複数のワークスペース

00:10:22.940 --> 00:10:26.620
を作成できます例えば財務部門 向けに会計アプリをまとめたワークスペース

00:10:26.620 --> 00:10:29.420
エンジニアリングチーム向けに 設計ツールを集めたワークスペース

00:10:29.420 --> 00:10:32.300
さらに契約社員向けにアクセス を制限したワークスペースなどが

00:10:32.300 --> 00:10:34.900
作れますユーザーには割り当て られたワークスペースのみが表示

00:10:34.900 --> 00:10:38.500
されるため財務担当者がエンジニアリング ツールを見ることはなく契約社員

00:10:38.500 --> 00:10:41.620
が内部用アプリを見ることもありません ユーザーエクスペリエンスは非常

00:10:41.620 --> 00:10:44.560
にシンプルですウィンドウズアプリ を開いてサインインすれば必要な

00:10:44.560 --> 00:10:46.840
ものが全てそこに揃っています デスクトップのアイコンをクリック

00:10:46.840 --> 00:10:49.060
すればフル機能のウィンドウズ セッションが開始されますアプリ

00:10:49.060 --> 00:10:51.480
のアイコンをクリックすればローカル プログラムのように開きます

00:10:51.480 --> 00:10:54.640
vpnも複雑な設定も不要でアクセス 可能なものがリストとしてすっきり

00:10:54.640 --> 00:10:58.340
と表示されますこれで全ての要素 が揃いましたしかしユーザーはどのように

00:10:58.340 --> 00:11:00.760
ログインしてデスクトップにアクセス するのでしょうかユーザーがどの

00:11:00.760 --> 00:11:03.620
ように接続するかそのidとアクセス のレイヤーについて説明します

00:11:03.620 --> 00:11:07.800
全ての始まりはmicrosoftentraidです まだazureactive directoryという名称

00:11:07.800 --> 00:11:10.540
で馴染みがあるかもしれません 少し前にブランド名が変更されました

00:11:10.540 --> 00:11:14.420
が中身のシステムは同じですentraid はデジタルオフィスの受付のような

00:11:14.420 --> 00:11:17.380
ものだと考えてくださいあなたが 誰であり何にアクセスできるか

00:11:17.380 --> 00:11:21.120
を把握していますmicrosoft 365teamsシェアポイントへのログイン

00:11:21.120 --> 00:11:24.580
を管理しておりもちろんavdへの アクセスも制御していますでは実際

00:11:24.580 --> 00:11:27.440
にユーザーはどのように接続する のでしょうかその流れを順を追って

00:11:27.440 --> 00:11:30.840
説明しますユーザーがデバイス でwindowsアプリを開き仕事用のメール

00:11:30.840 --> 00:11:33.660
アドレスとパスワードでサインイン します多要素認証が設定されて

00:11:33.660 --> 00:11:37.420
いればそれも行いますwindowsアプリ がentraidに認証リクエストを送信

00:11:37.420 --> 00:11:41.360
しそこで身元が確認されます 次にavdがそのユーザーがどのアプリケーショングループ

00:11:41.360 --> 00:11:44.420
に属しているかを確認します 最後にセッションホスト自体がユーザー

00:11:44.420 --> 00:11:48.060
を認証しますこの最後のステップ が重要ですユーザーはwindowsアプリ

00:11:48.060 --> 00:11:50.960
にログインしていても仮想マシン にサインインするには別途権限が

00:11:50.960 --> 00:11:54.320
必要ですこれは仮想マシンユーザー ログインという特定のazureロール

00:11:54.320 --> 00:11:56.560
によって制御されていますこの ロールが割り当てられていない

00:11:56.560 --> 00:11:59.760
とユーザーはavdに認証してwindows アプリでリソースを見ることが

00:11:59.760 --> 00:12:03.080
できても接続しようとすると失敗 しますセッションホストにログイン

00:12:03.080 --> 00:12:05.760
する権限がないからですここで ベストプラクティスの出番

00:12:05.760 --> 00:12:08.640
です個々のユーザーに直接権限 を割り当てないでください常に

00:12:08.640 --> 00:12:11.300
グループを使用するようにしましょう エントラーidでグループを作成し

00:12:11.300 --> 00:12:14.220
アフズザーズのような名前を付けて 全ユーザーを追加しますその後その

00:12:14.220 --> 00:12:16.600
グループをアプリケーショングループ と仮想マシンユーザーログインロール

00:12:16.600 --> 00:12:19.260
に割り当てます新しくメンバー が加わったらそのグループに追加

00:12:19.260 --> 00:12:23.260
するだけです退職者が出たらグループ から削除しますこれでもうavdの設定

00:12:23.260 --> 00:12:25.960
を二度と触る必要はありません 旧リモートデスクトップクライアント

00:12:25.960 --> 00:12:30.600
であるwindowsアプリはwindows mac ios androidそしてwebブラウザーでも

00:12:30.600 --> 00:12:33.560
利用可能ですユーザーは特別な デバイスを用意する必要はありません

00:12:33.560 --> 00:12:37.040
今持っているデバイスをそのまま 使えますすべてエントラーidベース

00:12:37.040 --> 00:12:40.680
なので既存のセキュリティポリシー が自動的に適用されます多要素

00:12:40.680 --> 00:12:45.960
認証もmicrosoft 365と同じように機能 します準拠デバイスの要求や特定

00:12:45.960 --> 00:12:48.880
の場所からのアクセス制限とい った条件付きアクセスポリシー

00:12:48.880 --> 00:12:53.460
もsharepointやexchangeと同様にavdへ 適用されますすべてのサービス

00:12:53.460 --> 00:12:56.240
で一貫したセキュリティポリシー を維持できますシングルサイン

00:12:56.240 --> 00:13:00.120
オンにも対応していますwindowsアプリ で一度認証すればデスクトップや

00:13:00.120 --> 00:13:03.460
アプリの起動時に再度入力を求め られることはありませんシームレス

00:13:03.460 --> 00:13:07.140
な体験です一度サインインすれば すべてがそのまま使えますしかし

00:13:07.140 --> 00:13:10.740
avdを真に快適にするための重要な 要素がもう一つありそれはすべての

00:13:10.740 --> 00:13:14.440
ユーザーに関わることですユーザープロファイル の課題ですなぜエフスロジックス

00:13:14.440 --> 00:13:18.340
が重要なのか皆さんがあまり意識 していない点をご紹介しますプール型ホスト

00:13:18.340 --> 00:13:21.200
プールではログインするたび に異なる仮想マシンに割り当てられる

00:13:21.200 --> 00:13:25.600
ことがあります今日はマシンa明日 はマシンbその次はマシンcプロファイル

00:13:25.600 --> 00:13:29.040
管理がなければログインするたび に新品のコンピューターを使っている

00:13:29.040 --> 00:13:32.280
ような感覚になりますブックマーク もデスクトップのファイルも保存

00:13:32.280 --> 00:13:35.280
したパスワードもアウトルック の署名も何一つありません部屋を

00:13:35.280 --> 00:13:38.180
出るたびに完全に片付けられリセット されるホテルの部屋にチェックイン

00:13:38.180 --> 00:13:41.560
するようなものです設定や基本設定 ファイルはすべて消えてしまいます

00:13:41.560 --> 00:13:44.740
かつての解決策はローミング プロファイルでしたwindowsが中央

00:13:44.740 --> 00:13:47.340
サーバーからプロファイル全体 をログインしたマシンへコピー

00:13:47.340 --> 00:13:50.440
する仕組みです理にかなっている ように聞こえますよね実際には

00:13:50.440 --> 00:13:54.520
低速で信頼性が低く破損しやすい ものでしたログオンに30秒以上

00:13:54.520 --> 00:13:56.960
かかることもありましたコピー が中断されるとプロファイル

00:13:56.960 --> 00:13:59.640
が完全に壊れてしまうこともありました itチームは破損したプロファイル

00:13:59.640 --> 00:14:02.380
の修復に膨大な時間を費やして おり決して良い体験とは言えませんでした

00:14:02.380 --> 00:14:05.560
マイクロソフトはこの深刻な問題 を認識しエフスロジックスという

00:14:05.560 --> 00:14:09.280
企業を買収してその技術をavdに 直接統合しましたエフスロジックス

00:14:09.280 --> 00:14:12.220
はプロファイルの問題を完全に そして非常に洗練された方法で

00:14:12.220 --> 00:14:15.400
解決します仕組みはこうですプロ ファイルをコピーしてやり取り

00:14:15.400 --> 00:14:18.300
する代わりにエフスロジックス は各ユーザーのプロファイルを

00:14:18.300 --> 00:14:22.020
単一の仮想ハードディスクファイル としてazure filesなどの中心的な

00:14:22.020 --> 00:14:25.500
場所に保存しますユーザーがavdに ログインするとエフスロジックス

00:14:25.500 --> 00:14:28.280
がそのディスクをセッション に直接マウントしますusbドライブ

00:14:28.280 --> 00:14:31.720
を差し込むように瞬時に接続され ます設定ファイルブックマーク

00:14:31.720 --> 00:14:35.420
基本設定のすべてが即座に反映 されますその結果は劇的ですログ

00:14:35.420 --> 00:14:39.440
オン時間は30秒以上から7から8 秒程度まで短縮されますプロファイル

00:14:39.440 --> 00:14:42.600
は一元管理されているためどの セッションホストに接続しても

00:14:42.600 --> 00:14:45.460
問題ありませんプロファイル は自動的にユーザーを追いかけ

00:14:45.460 --> 00:14:49.500
ますエフスロジックスはマイクロソフト 365アプリの大きな問題も解決します

00:14:49.500 --> 00:14:52.360
従来のプール環境ではアウトルック のキャッシュモードやワンドライブ

00:14:52.360 --> 00:14:55.140
の同期は事実上使用できません でしたパフォーマンスが非常に劣悪

00:14:55.140 --> 00:14:57.800
だったのですエフスロジックス を使えばどちらも完璧に動作します

00:14:57.800 --> 00:14:59.880
ユーザーはオフラインアクセス 可能な完全なアウトルックを利用

00:14:59.880 --> 00:15:02.060
できワンドライブはファイルを 同期しチームも適切にキャッシュ

00:15:02.060 --> 00:15:04.920
されますすべてが快適に動作 しますこれがエフスロジックス

00:15:04.920 --> 00:15:07.460
がavdのユーザープロファイル における標準かつ必須のソリューション

00:15:07.460 --> 00:15:09.960
とされる理由ですこれなしで プロファイルを管理しようとしない

00:15:09.960 --> 00:15:12.700
でくださいログオンの低速化 プロファイルの破損ユーザーの

00:15:12.700 --> 00:15:15.380
不満を招くことになります初日 からエフスロジックスを使って

00:15:15.380 --> 00:15:18.660
ください構成要素をご理解いただけ たところで企業が実際に移行を

00:15:18.660 --> 00:15:21.880
進めている理由についてお話し しましょうなぜ企業はavdを選ぶ

00:15:21.880 --> 00:15:25.060
のでしょうかセキュリティとコスト のメリットです企業が従来のラップ

00:15:25.060 --> 00:15:27.980
トップではなくavdを選ぶ理由 は何でしょうかそれは結局のところ

00:15:27.980 --> 00:15:30.840
セキュリティとコストに集約されます 詳しく見ていきましょうまずは

00:15:30.840 --> 00:15:33.640
セキュリティモデルですavdでは データがazureデータセンターから

00:15:33.640 --> 00:15:36.020
出ることはありませんユーザー のデバイスはリモートマシンで

00:15:36.020 --> 00:15:39.300
起きていることを表示している にすぎません実際のファイルアプリケーション

00:15:39.300 --> 00:15:42.680
機密情報はすべてマイクロソフト のデータセンター内に泊まりセキュリティ

00:15:42.680 --> 00:15:45.540
管理下に置かれますたとえラップ トップを紛失してもデータは

00:15:45.540 --> 00:15:48.480
最初からそこに存在しないため 盗まれるものはありませんすべて

00:15:48.480 --> 00:15:51.480
のエンドポイントを暗号化したり 盗難デバイスを遠隔消去したりする

00:15:51.480 --> 00:15:54.400
心配は不要ですマイクロソフト はディフェンダ法エンドポイント

00:15:54.400 --> 00:15:58.340
をavdセッションホストに直接統合 しているため仮想マシンは他の

00:15:58.340 --> 00:16:02.060
管理デバイスと同様に監視保護 されますマルウェア検知脅威

00:16:02.060 --> 00:16:06.200
ハンティング自動応答のすべて がavd環境に適用されますit部門

00:16:06.200 --> 00:16:09.300
は物理デバイスと仮想デスクトップ を横断して一元的なセキュリティ

00:16:09.300 --> 00:16:12.200
ビューを得ることができます 次に一元管理についてお話し

00:16:12.200 --> 00:16:15.260
しますこれはitチームにとって 非常に大きな利点です何百台もの

00:16:15.260 --> 00:16:17.880
個別のラップトップを管理し アップデートを展開し問題をトラブル

00:16:17.880 --> 00:16:20.300
シューティングし故障したハードウェア を交換する代わりに一つの環境

00:16:20.300 --> 00:16:22.860
を管理するだけで済みますゴールデン イメージを一度更新すればすべて

00:16:22.860 --> 00:16:25.040
のセッションホストにその更新 が適用されますポリシー変更を

00:16:25.040 --> 00:16:27.860
一度プッシュすればすべてのユーザー に適用されます運用オーバーヘッド

00:16:27.860 --> 00:16:31.280
は大幅に削減されます時間と労力 を節約できるのですそしてコスト面

00:16:31.280 --> 00:16:34.620
です自動スケーリングこそavdが真に コストを削減できる機能ですセッションホスト

00:16:34.620 --> 00:16:37.020
はユーザーがログインしている 間だけ実行されますピーク時には

00:16:37.020 --> 00:16:40.600
50台のマシンが稼働していても構 いません夜間や週末には2台だけ

00:16:40.600 --> 00:16:42.960
で済むかもしれません自動スケーリング によりコンピューティング時間

00:16:42.960 --> 00:16:46.160
を40から60%削減できますアイドル 状態のマシンに料金を支払う必要

00:16:46.160 --> 00:16:49.060
はありません適切なサイズ設定も コスト削減の重要な手段です従来

00:16:49.060 --> 00:16:51.440
のモデルでは大半のユーザーには 基本的なツールしか必要ない場合

00:16:51.440 --> 00:16:54.100
でも最も負荷の高いユーザーに合わせて 高性能なノートpcを購入する

00:16:54.100 --> 00:16:56.640
必要がありましたavdなら実際 のワークロードの要件に合わせて

00:16:56.640 --> 00:16:59.100
仮想マシンのサイズを最適化 できますパワーユーザーにはより

00:16:59.100 --> 00:17:01.600
大きなマシンをタスクワーカー にはより小さく安価なマシンを

00:17:01.600 --> 00:17:03.880
提供できます誰も必要としない ハードウェアに過剰な投資をする

00:17:03.880 --> 00:17:07.040
必要はもうありませんさらにすでに 利用可能なライセンス上のメリット

00:17:07.040 --> 00:17:12.280
もあります組織でwindows 1011エンタープライズ またはmicrosoft365e3e5を

00:17:12.280 --> 00:17:16.120
使用していればwindowsデスクトップ の追加ライセンス費用なしでavdを利用

00:17:16.120 --> 00:17:19.060
できます既存のライセンスで カバーされるからですこれにより

00:17:19.060 --> 00:17:23.220
大きな障壁が取り除かれますそして 展開速度も違います従来のモデル

00:17:23.220 --> 00:17:27.160
では新しい従業員のオンボーディング にはpcの手配到着待ちイメージ

00:17:27.160 --> 00:17:30.480
の展開アプリのインストール設定 作業が必要でしたこれには数日

00:17:30.480 --> 00:17:34.400
から数週間かかることもありましたavd なら数分で新しいユーザーを設定

00:17:34.400 --> 00:17:37.420
しアカウントを作成して適切な グループに割り当てるだけで手持ち

00:17:37.420 --> 00:17:40.560
のデバイスからすぐに業務を開始 できますここまでの内容の要点を

00:17:40.560 --> 00:17:44.880
まとめますつまりazure virtual desktop とは何かこれはwindows

00:17:44.880 --> 00:17:47.300
デスクトップとアプリケーション をazureからあらゆるデバイスに

00:17:47.300 --> 00:17:50.720
配信するマネージドサービスです 内部的にはホストプール内の仮想

00:17:50.720 --> 00:17:53.440
マシンがアプリケーショングループ として構成されワークスペース

00:17:53.440 --> 00:17:56.220
を通じて提供されますユーザー はwindowsアプリからエントラーid

00:17:56.220 --> 00:18:00.380
で認証しmacタブレットchromebook 古いpcからでも完全なwindows

00:18:00.380 --> 00:18:03.180
エクスペリエンスを利用できます 一言でまとめるとこうなります

00:18:03.180 --> 00:18:06.760
avdはコンピューティング体験 を物理デバイスから切り離します処理

00:18:06.760 --> 00:18:10.060
はクラウドで行われデバイスは 単なる窓口となりますavdを検討

00:18:10.060 --> 00:18:13.080
中の方に私からの推奨事項です まずはプールされたホストプール

00:18:13.080 --> 00:18:15.520
から始めましょうマルチセッション とオートスケーリングにより最も

00:18:15.520 --> 00:18:18.020
優れたコスト効率が得られます 初日からエフスロジックスを使用

00:18:18.020 --> 00:18:20.580
してくださいそれなしでプロファイル を管理することなど考えないで

00:18:20.580 --> 00:18:24.140
くださいそれによって体験の快適 さが全く変わってきますまた権限

00:18:24.140 --> 00:18:27.300
は個人単位ではなくグループ単位 で割り当ててくださいavdユーザーグループ

00:18:27.300 --> 00:18:30.140
を作成してメンバーを追加しそこ からアクセスを管理しますavdを

00:18:30.140 --> 00:18:32.520
テストしたい場合は小さく始め ましょう一つのホストプール

00:18:32.520 --> 00:18:35.260
で数人のユーザーから使い心地 を試してみてください導入の障壁

00:18:35.260 --> 00:18:38.300
は低く本格展開の前にパイロット 運用で多くのことを学べます以上

00:18:38.300 --> 00:18:41.740
azure virtual desktopの簡単な解説 でしたマイクロソフトテクノロジー

00:18:41.740 --> 00:18:45.260
のわかりやすい解説を今後も見 たい方は登録をぜひシェアもお願いします