Visual Studio SubscriptionのAzure特典でWindows Client OSとVisual Studio入りイメージを使う

免責事項開始
本件はMicrosoftサポートに問い合わせて得られた結果を書いていますが、ライセンスに関することはAzureサポートにお問い合わせください。
免責事項終了

いつのころからか定かではない（多分DevBoxがリリースされたころ）のですが、Visual Studioサブスクリプション特典のAzureサブスクリプションを使ってVisual Studio入りイメージを使おうとすると上記のエラーが出るようになりました。確実に以前は使えており、数年前にデプロイしたWindows 10 + Visual Studio入りイメージがAzure上にあります。

2023年5-6月ごろだったか、このエラーに初めて遭遇して、「一時的なものだろう」と思っていたのですが、まったく直る気配もなかったので、8月に問い合わせ始めて、ようやく今日回答がもらえました。まとめるとこんな感じ。

• Visual Studio サブスクリプションの特典Azureサブスクリプションの場合、クレジットカードなどを登録して上限解除しなければVisual Studio入りイメージは使えない（これはサードパーティーオファーなどと同じ）
• ただし、Azureサポートが試したところ、サードパーティーオファーと異なり、「無料枠から」クレジットが消費され、上限を超えた場合（Enterpriseの場合$200/month）に登録した課金方法への請求が行われる

とのことでした。「以前は大丈夫だったのに」と言って証拠のデプロイ済みVMも見せたのですが、いつ変わったかはサポートでもわからないといわれました。そして、多くの人は個人MSアカウント（outlook.jpなど）を使ってAzureサブスクリプションを使っているかもしれません。Virtual Desktopが出たころからですがこんなチェックが増えています。

一番下のLicensingにI confirm I have an eligible Windows 10/11 license with multi-tenant hosting rights.(Windows 10/11のマルチテナントホスティングライセンスを保有しています)という宣言です。知られている通り、Windows 10/11をAzureで使う場合Windows VDAもしくはWindows E3/E5のライセンスが必要です。Visual Studioサブスクリプションにはないのでは？ということはWindows Client OSが使えないのでは？ということになってしまいます。うーん、困った。

これも聞いたところ、「Visual Studioサブスクリプションの場合は使ってもよい（チェックを入れればよい）」のだそうです。根拠はたぶんこちら。

Visual Studio のサブスクライバーは、Microsoft Windows Virtual Desktop サービスで Azure Dev/Test の個人クレジットを使用できるようになりました。

出展：learn.microsoft.com

現実的にAzure Virtual Desktopを使う場合、Entraが必要で、個人MSアカウントでは無理（だよね？）なわけですが、ここでやるということになるのでしょうか。でも、正直これは困るのでこのサブスクリプションをEntraのテナント側に引っ越そうかなと思っています…。

あくまでも本記事は個人のメモなので、Azureサポートにご確認ください（大事なことなので二回目）

Azure DevOps Server 2022.1のデータベースにAzure SQL Databaseを使う

これはAzure DevOps アドベントカレンダー3日目の記事です。

qiita.com

USの感謝祭直後に2022.1が公開されました。オンプレミスのAzure DevOps Serverは年に一度程度バージョンアップを実施しています。昨年12月に2022.0が正式版公開されていますね。オンプレミスの更新だとこのくらいがいいのではないでしょうか。マイナーな機能更新は半年に一度行わるようです。サポートは10年なので比較的長く使えます。

devblogs.microsoft.com

ダウンロードやリリースメモは上記のブログから。大体Sprint228くらいまでの内容が入っているように見えます。私は普段クラウドサービスを扱っていますが、どうしてもクラウドサービスでは使えない、というケースはあります。Azure DevOps Serverを選ばざるを得ない場合はこの辺の理由でしょうか。

• そもそもクラウドにつながっていない、あるいは著しく制限されている
• 日本に置かなければならない（Azure DevOpsもGitHubも日本にはDCがありません）
• 独自のコンプライアンス＆セキュリティ基準がある
• 低レイテンシーが必要（クラウドサービスも割と充分ですが）
• オンプレミス以外で使えないライセンスのソフトがある（これは一応クラウドサービスでも解決できますが）

以前も一度試して失敗したのですが、今度こそということで以下の構成でインストールしてみます。

• Azure VM(Windows Server 2022) D2_v5
• SQL Database DTU model(構成データベース、データともにS3以上が必要)

今回はインストールだけなので8GB RAMですが、ElasticSearchの検索を使うならば16GB以上のメモリが必要でしょう。SQL DatabaseはDTUの場合、S3以上が必要なのでちょっとお高いのですが、日中しか使わず、ストレージが250GB以下であればAzure Automationを使って使うときだけこんなスクリプトでスケールアップ/ダウンすればいいでしょう。変更に大体5-6分くらいかかるので、気を付けてください。

Set-AzSqlDatabase -ResourceGroupName <resourcegroup> -DatabaseName "AzureDevOps_Configuration" -ServerName <servername> -Edition "Standard" -RequestedServiceObjectiveName "S3"
Set-AzSqlDatabase -ResourceGroupName <resourcegroup> -DatabaseName "AzureDevOps_DefaultCollection" -ServerName <servername> -Edition "Standard" -RequestedServiceObjectiveName "S3"

DatabaseNameにはラベルがつけられます。例えばAzure DevOps Server 2022用であればAzureDevOps_2022Configurationという名前で作っておくことでインストール時に明示的に指定できます。一つのデータベースには同じバージョンのサーバーからしか接続できないので、ご注意ください。

SQL DatabaseをEntra管理する

Entraで認証できるSQL Databaseでなくてはなりません。個人用MSアカウント時代にも一回やったことがあるのですが、ダメでした。

VMがActive Directoryに参加している必要がある

インストール前にActive Directoryに参加しておいてください。Entra Domain Services（旧Active Directory Domain Services）でも構いません。私はEntra Domain Services使っています。なので、Entra IDでのWindows Server ログインはできません。設定していると失敗します。

System Managed Identityを作る

次に、SQL DBにアクセスするVMに対してSystem Managed Identityを作ります。

VMにSQL DB Contributorロールを割り当てます。

SQLを実行する

SQL Databaseのmasterデータベースに対して以下のSQLを実行します。

CREATE USER [VMName] FROM EXTERNAL PROVIDER
ALTER ROLE [dbmanager] ADD MEMBER [VMName]

[VMName]にはSQL DatabaseへアクセスするVM名を書いてください。FQDNではありません。

SQL DatabaseのAzureDevOps_Configurationおよび、AzureDevOps_DefaultCollectionデータベースに対して以下のSQLを実行します。

CREATE USER [VMName] FROM EXTERNAL PROVIDER  
ALTER ROLE [db_owner] ADD MEMBER [VMName]  
ALTER USER [VMName] WITH DEFAULT_SCHEMA=dbo  

[VMName]は同様にVM名に置き換えてください。

これでインストールが可能になります。

インストーラー

ほとんど通常と変わらないのですが、2点だけ。

新しい配置を選んだ場合は新しい配置 - Azureを選んでください。ほかの二つを選ぶと失敗します。

ここでSQL Databaseのサーバー名を入力します。データベースサーバーのFQDNで指定してください。前述のラベルは詳細オプションをクリックすると、ラベルの入力が可能です。SQL Databaseを使うときはラベルを使ったほうがいいでしょう。

それら以外は同じです。

どっちが安いのか

参考までにSQL Databaseを使わず、VMだけで構成する場合とSQL Databaseを使う場合の費用を考えてみます。以下条件。

• ビルドエージェントをインストールするVMは考慮しない（Serverとの同居不可です）
• Azure DevOpsのライセンスはVisual Studio Subscriptionを使う。アクセスするユーザー全員に必要なので注意
• 東日本に作る
• 稼働時間は720時間
• プライベート接続するためのインフラはどちらも同じものが必要ということで除外
• 価格は2023/12/2現在のレートに基づきます

VM+SQL DB

用途	種類	数量	価格
Web App	D2ads v5 (2 vCPUs, 8 GB RAM S10 Managed Disk	1	¥25,267.96
検索	D4ads v5 (4 vCPUs, 16 GB RAM)	1	¥50,618.45
DB	S3: 100 DTUs, 250 GB	2	¥49,448.73
通信	Private Link(100GB)	1	¥1,375.28
合計			¥126,710.42

単一構成

用途	種類	数量	価格
Web+SQL+検索	E4as v5 (4 vCPUs, 32 GB RAM) E10 Managed Disk	1	¥50,861.85
データストレージ	Premium SSD v2, 1 X 512 GiB Disks, 730 Hours, 3000 IOPS, 125 MB/s	1	¥7,295.85
合計			¥58,157.70

比較して

…思っていましたが、やはりVM単独で動かすほうが安いですね（汗）。前者の構成のメリットはチューニングがほぼ不要になる、バックアップを自動で取ってくれる（Azure DevOps内にもありますが）、といったあたりでしょうか。

SQL Databaseを24時間使う必要がなければ例えば夜間や土日はS0に落とせば300時間くらいの稼働で済むでしょう。そうすればもうちょっと安くできますし、検索とWebサーバーを同一にすると、たぶん2万円くらいの差額になるはずです。この辺はどうするか、ですかね。

TestBase for Microsoft 365を試してみる

TestBaseとは

for Office 365といわれていたころから一応あることは知っていましたが、Entraに紐づくサブスクリプションがなかったのと、ちょっとお高めのイメージがあったので、使えなかったんですよね。お仕事で試せる機会があればと思っていましたが、Armデバイスのプレビューが始まった時に申し込みの機会があったので申し込んでみました。今回はArmでのテストではありません（プレビュー通ればやってみます）。

learn.microsoft.com

ドキュメントに「Azureサービスです」と書かれている通り、使うのはAzureポータルからです。サインアップすると100時間くらいの無料枠が付いてくるようです。なんでAzureに含まれるサービスではありますが、Intuneへのデプロイ前にカスタムアプリケーションのテストに使えるので、E2Eテスト環境として最適です。

似たものとしてAzure PipelineがサポートするDeployment Groupおよび、Azure Playwrite Testingサービス（プレビュー）というものがあります。

learn.microsoft.com

azure.microsoft.com

	TestBase	Deployment Group	PlayWrite Testing
テスト対象	- クライアントOS - サーバーOS - プレビューOS いずれもWindows	任意のOS	PlayWriteでサポートされているWindows/Linux
独自OSイメージ	可	可	不可
対象アプリ	Storeおよび、Windowsアプリ, Webも頑張れば？	デプロイ対象で動くもの任意	Webのみ
価格	無料枠ありの有料	対象VMの料金とPipelineの料金	最初の100分は30日無料。そのあと分単位の従量課金
CI統合	SDKはあるので頑張る	サポート	サポート

用途に応じてサービスを使い分けることになります。TestBaseとしては組織内や販売するアプリケーションの展開前テストという意味合いが強いでしょうか。もちろんMicrosoft 365 Apps（Officeアプリ）も含まれるので、Officeアプリケーションのアドイン（もう基本的に廃止方向ですが）との互換テストにもいいと思います。ただ、OSは英語になるはずなので、自分で言語設定変えるスクリプト入れ込むか、カスタムイメージを用意するとなるとちょっとつらいでしょうね。

使用してみる

AzureポータルからTestBaseアカウントを作ってパッケージをアップロードしてみます。今回はMicrosoftが用意しているサンプル(テストスクリプトが入っているzipをアップロードしてテストする)でやってみます。

github.com

アカウント作成後、Upload pre-build packageを選択します。どれを選んでも次の画面で変更できるので問題ありません。

所定のフォルダー構成とスクリプト名で圧縮したzipファイルを選択してアップロード、パッケージ名とバージョンを決めます。セマンティックバージョン推奨です。なお、余談ですがこの画面で「やっぱりやめた」とキャンセルするとTestBaseのNew Package一覧にごみが残るので気を付けてください（気づいたら数個残っていた…）。

packega sourceでIntuneのパッケージや普通のwin32アプリケーション、wingetのリポジトリからも選択可能です。

例えばPackerとか。一つ注意しなければならないのは、「WinGetに公開されているバージョンが即時反映されていないっぽい」ということです。例えばGoLang 1.20.8や1.20.9がありません。wingetレポジトリにはあります。

github.com

同期されていないこともあるようです。

次は何のテストをするかです。今回はOut of Box(スクリプト外のアプリ)のテストを選びます。ちなみにMicrosoftのサンプルではストアのToDoアプリをテストします。Functional(機能テスト)やFlow Drivenも同時に選択可能です。

今回は使いませんが、Office入りが必要であれば、Pre-install Microsoft appsを有効にして対象のOfficeのアーキテクチャやチャネルを選択します。

テストスクリプトにはルールがあります。終了時（close）、インストール時(install)、起動時(launch)、削除時(uninstall)それぞれに従ってスクリプトの編集を行います。今回は出来上がったスクリプトの名前から自動判定してくれたので、そのままです。

Windowsには毎月パッチと年に一度の機能更新があります。そのどちらか、あるいは両方をテストするかどうかです。

セキュリティ更新の対象となるOS、機能更新の対象となるOSを一つ以上選択します。

これはどのOSからの更新かというベースラインイメージの選択です。OSの機能更新を選択した場合は必須です。

これで保存すれば完了です。

Varidationが実行されます。これがかなり長いです。割と単純なスクリプトだと思ったのですが1時間くらいしてやっとreadyになりました。

右端のRun on requestをクリックしてもまだComming soonでした…。

でも一応varidationが終わった時点で動き出しているようで、ちゃんとこんな風にテスト中の状態が見えます。

まとめ

複数のバージョンのWindows Client OSやServer OSを用意して、インストールテストするのは大変だと思います。TestBaseはそういうところでうまく使えそうです。

CIと絡めたパッケージの更新やIntune使った展開もやってみたいですね。

2023/11/5 追記（テスト結果）

8時間くらいかかって終了していました。今回のパッチではセキュリティパッチ検証1台につき1時間ちょっとかかっていますね。機能更新でも同じくらいかかっています。Build versionもしっかり10月のBパッチを使っていますね。

こちらは実行したときの様子です。信頼性、メモリ使用量（8GBのVMですね）、CPU使用状況の比較もできます。同じTo DoでもOSバージョンによって結構誓いが見て取れます。今回は起動テストだけですね。

ログや実行したときの動画もダウンロードできます。割と大きいファイルになります。今回どちらも60MBくらいのzipでした。アプリ起動までに結構待つもんですね。スクリプトなのかな。今回のテストでは800x600くらいの動画になっていましたが、変えられるのかな。

結構面白いですね。セキュリティパッチどのくらいでTestBaseにリリースされるのかわかりませんが、CIと関連させてテストできれば使いどころはあると思います。

オンプレミスと同期しているAzure Entra(Active Directory) Domain Servicesでオンプレミスのユーザーを使う

以前、Team Foundation ServerのKindle本を書いたとき、Azure AD Domain Servicesのドメインに参加したWindows Serverを使っていました。当時はEntra(Azure AD)テナントの都合でMicrosoft 365ドメインと同じドメインで使えなかったのですが、サブスクリプションのテナントをM365テナントと同じテナントに付け替えたので、使えるようになりました。ということで、重い腰を上げてVMの移行をしたら割とはまりました。

Azure Entra Domain Servicesを別ドメインへ移行

できません。もともとドメインがことなるし、実験用だったので全く問題ないのですが、Entra Domain Services(旧AADDS)ではドメイン変更するときは一から作り直しです。昔、ARMになる前のClassic deployからARMへ切り替えたとき一度削除して再デプロイしたらユーザー情報が丸ごと残っていて助かったのですが、今回はドメインも違うしそもそもオンプレADと同期するので消えても問題ないことにします。

サブスクリプションの変更はできるそうですが、やらないに越したことはないので、本当に使うときは計画的に。評価用で…と思っても、Entraテナントに対してEntra Domain Servicesは一つしか作れないので、要注意です。

ドメイン参加していたVMを移行する

Azureの仕様上、異なるVirtual Networkに関連付けられているNICを同時にマウントできないようです。そして、Azure VMは必ず一つ以上のNICがアタッチされていないといけません。どうするか…ということで、Managed Diskを残して、VM削除（NICは消えてもいい）。

残ったManaged Diskから再度VMを作る、ということになります。新VMでは新しいVNETにアタッチされたNICを使います。

VMを新しく作ったら、ちゃんとAzure Entra Domain Serviceへpingが通るかどうか確認しましょう。

ping Entraドメイン名

応答が返ればOKです。

learn.microsoft.com

新ドメインへ参加

ここでめちゃくちゃはまりました。Windows ServerをEntra Domain Servicesに参加するとき、オンプレミスのIDとパスワードを指定しても「アカウントがロックされています」というエラーで入れません。

いくつかオンプレミス（でEntraと同期している）のアカウントを指定してもだめ。トラブルシューティングによると5分以内に2回試行して失敗するとロックだそうなので、30分待ちます。

learn.microsoft.com

しかしそれでもだめ。

jpazureid.github.io

アカウントリセットが必要なのではないかと教えてもらったけど、以前からオンプレミスにあるアカウントだしなぁ…ということで、よくよくドキュメント見直してみたら、オンプレミスからEntraへはAzure Entra Connectを使ってハッシュ同期していて、それで済んでいると思っていたら別途ハッシュ同期やらないといけなかったみたいですね。

learn.microsoft.com

このドキュメントにあるPowerShellスクリプトを実行すればちゃんとAzure VMでもAzure Entra Domain Servicesへの参加ができました。最初スクリプトがエラーになって、なんだ？と思ったら

$azureadConnector = "<CASE SENSITIVE AZURE AD CONNECTOR NAME>"

ここを書き直すのに、hoge.onmicrosoft.com - AADの- AADをつけ忘れていたからでした。よく読もう。ちなみにこの辺のAzure Entra Connectのオンプレミス同期はAZ-500の試験範囲です（ちょっと前に受けたばかり）。Entra Domain Servicesは確か演習でもやらなかったけど。