やっと使えた。
以前にAWS Workspacesを触ってから、ずーっとずーっとAzureで提供されるDaaS(Desktop as a Service)を触ってみたいー！と思っていたのだけど、まず12ヶ月無料期間はサービスが存在せず、いざ登場してみると扱いが非常に難しい・・・ということで、その仕組みが全く理解できずにおりました。
何が理解しづらかった？
多分、初期構築が独特なんだと思います。
管理インタフェースがGUIでは構築できず、PowerShellを使用する必要があるんです。
全体の流れは以下の通りです。
前半が丸々CLIで作る感じになっていて、GUIで作れる領域が少ないんです。Azure Portalで直接的にMarket Placeで作れそうなのはVMの作成ぐらいしかない上、できあがるリソースは見た目単なるAzure VMと変わらないと言う。
Portalベースで管理すると言うことが難しいサービスかなぁと思うと同時に、運用をCLIだけでこなすのが得意な人には合ってるのかもしれないなーと思った次第です。
構築手順
アプリケーションIDの登録
今回実施した手順では、アプリケーションIDの関連付けをURLアクセスで行っています。
2020年5月現在、どうやらアクセス許可発行をWebGUIで出来るページが生まれたようです。以下サイトにてディレクトリIDを放り込む形でServer Clientそれぞれの登録を行うことが可能です。結果の表示は変更ありません。
https://rdweb.wvd.microsoft.com/
https://login.microsoftonline.com/<Tenant Name>/adminconsent?client_id=5a0aa725-4958-4b0c-80a9-34562e23f3b7&redirect_uri=https%3A%2F%2Frdweb.wvd.microsoft.com%2FRDWeb%2FConsentCallback
https://login.microsoftonline.com/<Tenant Name>/adminconsent?client_id=fa4345a4-a730-4230-84a8-7d9651b86739&redirect_uri=https%3A%2F%2Frdweb.wvd.microsoft.com%2FRDWeb%2FConsentCallback
各コマンドを実行すると、サインインを求められ、以下の画面にて承諾を求められます。それぞれ「承諾」をクリックしてくださいまし。
指定アプリケーションに対する権限付与
Azure PortalからAzure AD->エンタープライズアプリケーションを開くと、先ほど承認したアプリケーションIDに基づいたリソースが表示されるようになる。
これをそれぞれクリックし、テナントを作成するユーザに対して「TenantCreate」という権限を付与する。
WVD用PowerShellモジュールを導入
テナントの作成には専用PowerShellモジュールを導入する必要がある。
途中、リポジトリの使用承認を求められるので、Yを入力してインストールを続行する。
■WVD向けモジュールのインストール
> Install-Module -Name Microsoft.RDInfra.RDPowerShell
信頼されていないリポジトリ
信頼されていないリポジトリからモジュールをインストールしようとしています。このリポジトリを信頼する場合は、Set-PSReposit
ory コマンドレットを実行して、リポジトリの InstallationPolicy の値を変更してください。'PSGallery'
からモジュールをインストールしますか?
[Y] はい(Y) [A] すべて続行(A) [N] いいえ(N) [L] すべて無視(L) [S] 中断(S) [?] ヘルプ (既定値は "N"): Y
そしてインポートを行う。
■WVD向けモジュールのインポート
> Import-Module -Name Microsoft.RDInfra.RDPowerShell
事前に必要な情報
テナント作成の前に、以下2つのパラメータを抑えておく必要がある。
- Azure AD Directory ID（AD Tenant ID）
Azure ADの概要画面で確認が出来る。テナントとAzure ADとの関連付けで必要になるんだと思う。 - Subscription ID
Subscriptionの概要画面や、各種リソースの概要画面で確認が出来る。課金と紐付ける存在なのかなと思われる。
テナントの作成
ここでようやくテナントの作成に着手することになるのだけど、管理サーバに相当するRDBrokerに対してユーザアカウントを登録する(?)ことを行う。
後々Desktopサーバを構成する際にTenantGroupを指定する必要があるのだけど、以下の記載のようにこの時点でDefault Tenant Groupが作成されているっぽい。
■RDSアカウントの作成
> Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"
DeploymentUrl TenantGroupName UserName
------------- --------------- --------
https://rdbroker.wvd.microsoft.com Default Tenant Group words@BLUECORE.NET
その上で、テナントを作成することになる。このとき、AD Tenant IDやSubscriptionIDが必要になってくる。
■WVDテナントの新規作成
> New-RdsTenant -Name BLUE-RDS-TNT -AadTenantId <AD Tenant ID> -AzureSubscriptionId <Subscription ID>
TenantGroupName : Default Tenant Group
AadTenantId : <AD Tenant ID>
TenantName : BLUE-RDS-TNT
Description :
FriendlyName :
SsoAdfsAuthority :
SsoClientId :
SsoClientSecret :
AzureSubscriptionId : <Subscription ID>
LogAnalyticsWorkspaceId :
LogAnalyticsPrimaryKey :
ホストプールの作成
テナントができあがったら、その配下にホストプールを作成する。このプールが実際にクライアントからVMを選択する際の大項目に相当する。
■WVDホストプールの作成
> New-RdsHostPool -TenantName BLUE-RDS-TNT -Name POOL-JPWEST
TenantName : BLUE-RDS-TNT
TenantGroupName : Default Tenant Group
HostPoolName : POOL-JPWEST
FriendlyName :
Description :
Persistent : False
CustomRdpProperty :
MaxSessionLimit : 999999
LoadBalancerType : BreadthFirst
ValidationEnv : False
Ring :
AssignmentType :
テナント参加用トークンの作成
テナントができあがった後、これに参加するために必要となるトークンを作成する。恐らくこれ、本来は実施しなくて良い方法・・のはずなのだけど、この後の作業でどうしてもうまくいかない箇所が有り、そこを補填する際に必要になった。
■WVDクライアントインストール時に使用するトークンの作成
New-RdsRegistrationInfo -TenantName BLUE-RDS-TNT -HostPoolName POOL-JPWEST -ExpirationHours 1 | Select-Object -ExpandProperty Token | Out-File -FilePath E:\TESTFILE
■テナント・プールに対するグループとユーザの関連付け
> Add-RdsAppGroupUser -TenantName BLUE-RDS-TNT -HostPoolName POOL-JPWEST -AppGroupName "Desktop Application Group" -UserPrincipalName words@bluecore.net
警告: 1.0.1534.2001
■トークンの出力
> $token = (Export-RdsRegistrationInfo -TenantName BLUE-RDS-TNT -HostPoolName POOL-JPWEST).Token
> print $token
無効なスイッチです - eyJhbGciOiJSUzI...ckVuqyH33G0Q6MQBUR0AUOHuuAH9-wjhWeXwF-X8A
-> トークンはRDS Agent導入時に使用する
VMのデプロイメント
これでVMをデプロイメントするために必要なモノがそろったので、以下の対応を実施していく。まずはAzure Portalより「リソースの追加」にて「Windows Virtual Desktop」で検索を行うと、VMのデプロイメントメニューが表示される。
デプロイメントの設定画面は確認画面を覗くと4画面で構成されている。
まずは基本的なリソースは一及びWVDに関係する基本的な情報を設定する。
2番目の画面では、どのようなVMをデプロイメントするのかを指定する。
今回私は個人テナントで構築してるのと、予約インスタンスの関係もあってB1msという小さなVMを1台だけ構成することに(稼ぎが少ないからしょうがない）
3つめの画面で注目するところとしては、参加ADに関する情報である。適切なDNS設定やユーザルートが構成されていれば、既存のオンプレミスAD環境を指定することも可能であり、例えば他のサービスだとサブネット委任しなければならない箇所でも、ユーザルートやNSG等の構成が可能になっていたりする。
先ほど入力してきたテナント情報やプール情報はここで入力することになります。ただ、テナントグループ名はデフォルトのままとする必要があります。
また、テナントのオーナー情報というのは、先に書いたCLIで設定した「RDSアカウントの情報」が該当します。
できあがったリソースは以下の通りなんですが、ぱっと見普通のVMと殆ど変わりません。正直、最初に訳分からずこのメニューだけ扱ったときは「これでどないせぇっちゅーんじゃ・・・」と思いました。
また、どうやらデプロイメントスクリプトに問題があるのか、それともスペックが脆弱だからなのか分からないのですが、100%の割合でデプロイメントの最後に実施されるプール登録処理が失敗してました。
この場合は、手動でエージェントの導入とテナントへの登録をする必要があったりします。導入するエージェントは以下の通りです。
Remote Desktop Agent
https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWrmXv
Remote Desktop Agent Bootloader
https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWrxrH
作成されたVM、実はVPNでつながっているのであれば通常のVMと同様にリモートデスクトップ接続でアクセスすることが可能です。それでログインした後に、ダウンロードしたRemote Desktop AgentとRemote Desktop Agent Bootloaderをインストールします。
Remote Desktop Agentをインストールする際に、先述した「テナント用認証トークン」が必要になってきます。あらかじめテキストで出力し、貼り付けるようにすると便利です。
クライアントソフトウェアのダウンロード
これで、サーバ側の準備は出来たわけでして、今度はクライアントソフトウェアのダウンロードが必要になります。
RDS Client
単なるリモートデスクトップと異なるような似たような・・という感じのクライアントソフトウェア。これをWVDへ接続する端末へインストールする必要がある。
Remote Desktop Client
https://go.microsoft.com/fwlink/?linkid=2068602
インストール自体はもの凄く簡単で、ウィザードに従ってインストールすれば簡単に導入できる。
クライアントを立ち上げる
クライアントを起動すると、初回起動時のみ設定の登録処理みたいなモノが動くようです。まずはログインした上で、最終的には右下側の画面が出てくれればOKです。
その後、メニュー画面へ遷移し、アイコンをダブルクリックすることにより接続させることが可能になります。
ログインの過程と言い、ログイン後の画面と言い、ちょっとリッチなリモートデスクトップ・・・？的な感じがしました。ユーザエクスペリエンスを少し多めに動かしてるのかな？？？と言う気もしないでもないです。
正直なところ
WVDは凄くコストメリットの高いサービスかなぁと言う気はします。ただ、どーしてもAWS WorkspacesやCitrix製品と比べると管理の容易性という面でかなり扱いにくい印象を受けます。
ただ、Workspacesを真似したところでそれはメリットにはなり得ないので、恐らくMicrosoftも色々考えていらっしゃるんだろうなーとは感じます。リモートワークなども叫ばれるこの時代、特にこうしたサービスは求められるんだろうなーとは思うのですが・・・・
なお、クライアントPCは思いのほかスペックが軽視されがちなケースが多いなぁと感じます。でも実際には、瞬発力というか、短距離走的な能力はサーバとPCを比べると結構PCの方が強いのです。OS側の最適化手法が異なるというのも一つの要因だとは思いますけれども。
いずれにしても、一つのリモートワーク的な姿として、ある程度技術習得は必要かなと認識を改めたところです。
using WordPress and
Comments are closed