Microsoft Intune で検証用にParallels Desktop上の仮想macを登録する

概要

Microsoft Intuneで検証するために物理マシンを使って検証できない(したくない)シーンってありますよね。
Windowsに関してはMulti-Sessionが対応していないとかあるのですが、Azure VMWindows 10 Proを構築すると特に何もせず登録が可能です。
ではmacOSはどうでしょうか。

以下によるとParallels DesktopVMware Fusionで対応しているそうです。
Parallels DesktopはProとBusinessが対象となります。

docs.microsoft.com

手順通りやってみる

kb.parallels.com

上記のリンク先の手順通りやってみます。

Parallels Desktop 上のmacへログインして以下コマンドをTerminalで実行します。

ioreg -l | grep IOPlatformSerialNumber

以下のようにシリアル番号が出力されるのでシリアル番号を設定します。
f:id:tsukatoh:20200721150751p:plain 対象の仮想マシンの設定に追加します。
[設定] → [ハードウェア] → [詳細設定] → [ブートフラグ]
f:id:tsukatoh:20200721151014p:plain f:id:tsukatoh:20200721151255p:plain 先ほど出力したシリアル番号を追記して値を設定します。

devices.smbios.serial="XXXX000XXX0X"

Intune登録用の「ポータルサイト」アプリから登録してみます。
が、以下のように構成プロファイルが登録できません。
f:id:tsukatoh:20200721151747p:plain

何が足りないのか…

構成の確認

mac VMの構成をみてみると、機種IDがParallelsになっていますね。
f:id:tsukatoh:20200721152220p:plain これでは証明書のインストールが出来ないようです。

機種IDを変更するようローカル側のmacから情報を取得して、以下のようにVMの設定を変更します。
[このmacについて] → [システムレポート] → [ハードウェア] → [機種ID] f:id:tsukatoh:20200721152530p:plain f:id:tsukatoh:20200721152658p:plain f:id:tsukatoh:20200721152717p:plain 設定変更する際には電源は停止します。
先ほどと同じように仮想マシンの設定に追加します。
[設定] → [ハードウェア] → [詳細設定] → [ブートフラグ]

devices.smbios.serial="XXXX000XXX0X"
devices.mac_hw_model="MacBookAir8,1"

起動後、機種ID、シリアル番号を確認して意図したものになっていることを確認します。

Intuneへのデバイス登録

Intune ポータル アプリ を起動して登録していきます。 手順については以下を参照。

docs.microsoft.com

f:id:tsukatoh:20200721153006p:plain 構成プロファイルがインストール出来ましたね。
ここまできたらすぐ終わります。

登録が完了した後、Microsoft Endpoint Manager admin center でも確認してみます。
f:id:tsukatoh:20200721153048p:plain 登録されていますね。
これで物理環境に変更を加えることなく検証することが可能となります。
是非お試しください。

※ 2020/08/05 追記
本設定ですがVM内で再起動すると無効化されるようです。
一旦シャットダウンして起動しなおすと適用されます。

Azure AD テナントを削除する際にエンタープライズ アプリケーションが残って削除できない時の対策

検証で使って不要になったAzure AD テナントを削除する時にはまったので備忘録的に。

全体的にはAzure AD テナントから削除に進むとチェックが走り、必要な操作に沿って対応していくと状態が全てグリーンになります。
が、色々外部連携やAzure DevOps等を利用していくと削除のできないものが出てきます。
削除時に出るエラーは以下のような状態ですね。

f:id:tsukatoh:20200709014953p:plain

一旦以下の手順で削除していき、これで解決できるならOKです。

docs.microsoft.com

しかしながら、Azure DevOps等はこの手順では消えてくれませんでした。
他システムや他テナントと連携するようなアプリケーションは削除ロックがかかるようで、普通には消えません。
残っている状態が以下のような状態ですね。

f:id:tsukatoh:20200709014922p:plain

そのような場合は以下の手順にて削除します。
事前に用意するものはWindows PowerShellへ以下モジュールのインストールをします。

事前準備

管理者権限でWindows PowerShellプロンプトを起動します。
以下コマンドでモジュールのインストールを行います。

Install-Module MSOnline

作業対象ディレクトリ確認

以下コマンドで対象のディレクトリか確認します。
間違ったテナントで作業すると大変なことになるので確認しましょう。

Get-MsolDomain

対象アプリケーションの無効化及び削除

以下コマンドで対象のアプリケーションを無効化します。
ObjectIdはAzure PortalのAzure AD → エンタープライズアプリケーション などから取得します。

Get-MsolServicePrincipal -ObjectId <ObjectId> | Set-MsolServicePrincipal -AccountEnabled $false

無効化されたら削除します。

Get-MsolServicePrincipal -ObjectId <ObjectId> | Remove-MsolServicePrincipal

ポータルのエンタープライズアプリケーションから表示されなくなっていれば成功です。

WVDのプロファイルをFSLogixを使って Private Link 経由で Azure Storage へ保管する

Windows Virtual Desktop (WVD) のプロファイルを外部へ保管する方法としてFSLogixが推奨されています。
WVDを使う理由としてデータを社外に持ち出したくないというところもあると思います。
Azure 上にプロファイルサーバーを立ててそこに保管する方法もありますが、サーバーを管理したくないので Azure Storage のBLOBへ配置します。
また、表題にもあるように完全にVNet内で通信を完結するために Private Link でBLOBへ接続します。

docs.microsoft.com

流れとしては以下となります。

  • Azure Storage の作成
  • WVD用仮想マシン(イメージ)の作成
  • FSLogix をインストール
  • サインインしての検証

Azure Storage の作成

まず Azure ポータルからStorage Accountを作成します。

名称等を入れます。
注意事項としてはパフォーマンスはPremiumを選択しましょう。
Standardだとサインイン・アウト時の読み込みなどの速度に影響してきます。

f:id:tsukatoh:20200605100613p:plain

接続方法はプライベート エンドポイントを選択します。

f:id:tsukatoh:20200605100632p:plain

名称と展開する仮想ネットワーク・サブネットを選択します。
ここでプライベートDNS統合を選択することで接続文字列等を変更なく利用できます。

f:id:tsukatoh:20200605100644p:plain

検証に成功したら作成します。
ARMテンプレートにも対応しているので、利用したい場合はダウンロードして参考にしてみてください。

f:id:tsukatoh:20200605100726p:plain

WVD用仮想マシン(イメージ)の作成

今回は Microsoft Windows 10 + Office 365 ProPlus で構築していきます。
選択したのは Windows 10 Enterprise multi-session, Version 2004 + Office 365 ProPlusです。
画面についてはここでは触れませんが、ネットワークは先ほど作った Azure Storage の Private Link のエンドポイントに接続できるよう、同一VNet内かPeeringされたネットワークに配置してください。

f:id:tsukatoh:20200605100801p:plain

FSLogix をインストール

VMの展開が完了したらリモートデスクトップ接続して作業します。
(安全に接続するには Azure Bastion で接続する方がいいと思います。)

FSLogix をダウンロードします。

https://aka.ms/fslogix_download

展開して x64\Release\FSLogixAppsSetup.exe を実行します。
他にある実行ファイルはそれぞれ以下の役割をインストールしますが今回は対象外です。
FSLogixAppsJavaRuleEditorSetup.exe → Javaバージョン管理機能のルール作成 FSLogixAppsRuleEditorSetup.exe → Application Masking

f:id:tsukatoh:20200605101303p:plain

次にGPO設定用にadml、admxファイルをコピーします。
fslogix.adml → C:\Windows\PolicyDefinitions\en-US
fslogix.admx → C:\Windows\PolicyDefinitions

f:id:tsukatoh:20200605101448p:plainf:id:tsukatoh:20200605104035p:plain

ファイル名を指定して実行で「gpedit.msc」を実行します。

f:id:tsukatoh:20200605101734p:plain

[コンピューターの構成] → [管理用テンプレート] → [FSLogix] → [Profile Containers] → [Enabled] をEnabledへ変更
[コンピューターの構成] → [管理用テンプレート] → [FSLogix] → [Profile Containers] → [Cloud Cache] → [Cloud Cache Locations] を有効にして「type=azure,connectionString="接続文字列"」を入れます。

f:id:tsukatoh:20200605102751p:plainf:id:tsukatoh:20200605102804p:plain

でもこのままではキーがそのまま見えてしまうので隠蔽して登録します。

C:\Program Files\FSLogix\Apps\frx.exe add-secure-key -key blobkey -value [BLOB Key]

f:id:tsukatoh:20200605102904p:plain

出来上がったら以下に置き換えて登録しなおします。

type=azure,connectionString=”DefaultEndpointsProtocol=https;AccountName=[account_name];AccountKey=|fslogix/blobkey|;EndpointSuffix=core.windows.net”;

サインインしての検証

設定が終わったらサインインして検証します。
一度サインアウトしてサインインしなおします。

ディスクの管理から見るとプロファイルがVHDとしてマウントされています。

f:id:tsukatoh:20200605103158p:plain

VNet上のマシンから Azure Storage Explorer や Azure Portal から見ると以下のようにユーザー毎にコンテナーが作られ、その中にvhdファイルが保管されていることが確認できます。

f:id:tsukatoh:20200605103235p:plainf:id:tsukatoh:20200605103246p:plain

VNet外のマシンから上記のように確認しても権限がないとアクセスすることができません。

f:id:tsukatoh:20200605103300p:plain

Storage BLOB へのアクセスをPrivate Link経由にすることでBLOBストレージを外部に公開することなくプライベートなネットワークで利用することができ、WVDのプロファイルの保管用途としても外部に公開したくないというニーズにも応えられるようになっています。

リモートワークのお供にWindows Virtual Desktop (WVD)

Windows Virtual Desktop (WVD)

昨今の社会情勢からリモートワークが基本となり、お家から仕事するという生活が続いているかと思います。
ですが、職種や職域によってはどうしてもオフィスに行かなければならない方々もいらっしゃいます。
それを少しでも緩和できる可能性があるのがWindows Virtual Desktop(WVD)ではないかと思います。
WVDとはMicrosoft Azure上で動作するマネージドVirtual Desktop Infrastructure(VDI)サービスです。
Azure上にWindows 10デスクトップ環境を用意してリモートで接続し、作業できる環境を用意するサービスです。
Express RouteやVPNを使ってオンプレミスのデータセンターと接続することで、社内データやネットワークにもアクセスすることができます。

個人的にもVDIはもう10年以上触ってきているので、Azureでここまで簡単に構築できるのは感慨深いです。
2020/05/01にパブリックプレビューとして公開されたARMで管理された新しいWVDのご紹介をしていきます。

docs.microsoft.com

構築には以下の方法があります。

※ 2020年5月25日現在はAzure Resource Manager (ARM) での構築は非対応です

Azure Portal で構築する

前提としてAzure AD DSかAzure AD Connectで構築されたAzure ADが構築済みなこと。

tsukatoh.hatenablog.com

Azure Portalから「Windows Virtual Desktop」を検索します。

f:id:tsukatoh:20200525182237p:plain

「Create a host pool」をクリックします。

f:id:tsukatoh:20200525182316p:plain

Basicesには以下の情報を入力します。

f:id:tsukatoh:20200525182335p:plain

  • Subscription → サブスクリプションを選択
  • Resource Group → リソースグループを作成(ここでのRGはHost poolリソースの配置先)
  • Host pool Name → ホストプールの名称を入力
  • Location → メタデータの保管先(現状は日本は選択不可)
  • Host pool type → Pooledは共有型、Personalは個人固定型
  • Max session limit → 最大セッション数
  • Load balancing algorithm → Breadth-first Breadth-firstは幅優先の負荷分散、Depth-firtsは深さ優先の負荷分散

Virtual Machinesには以下の情報を入力します。

f:id:tsukatoh:20200525183826p:plain

  • Add virtual machines → デフォルトはNo、ここではVMの設定を入れるためにYes
  • Resource group → リソースグループを指定、何も指定しなければHost poolと同一のRGに配置
  • Virtual machine location → VMの配置先リージョン
  • Virtual machine size → VMのサイズを指定
  • Number of VMs → VMの台数
  • Name prefix → VMの名称の頭文字、後ろにナンバリングが入る
  • Image type → VMのイメージの選択元、作成したイメージもGalleryから選択できる
  • Image → イメージを選択、カスタムイメージはBrowse〜から選択する
  • OS disk type → ディスク種類の選択ができる、早いものがほしければPremium SSD
  • Virtual network → AzureADに接続可能なVNetを選択(ピアリングでも可)
  • Subnet → 配置可能なサブネットを選択
  • Public IP → パブリックIPを設定する場合はYes、通常はNoでいいと思います
  • Network security group → NSGを設定するかどうか、Subnetに設定しておいてここではNoneにするのがいいと思います
  • Specify domain or unit → OUの指定をする場合に選択
  • AD domain join UPN → ドメイン参加実行アカウント

Workspaceには以下の情報を入力します。

f:id:tsukatoh:20200525182452p:plain

  • Register desktop app group → デフォルトはNo、ここではワークスペース名を指定するためYes
  • To this workspace → ワークスペース名を入力、WVDサインイン時にユーザーに見える名称です

Review + createをクリックして作成します。

作成完了したら接続します。

【Web Client】

https://rdweb.wvd.microsoft.com/arm/webclient/

【WVD専用クライアント】

https://go.microsoft.com/fwlink/?linkid=2068602

f:id:tsukatoh:20200525184233p:plain f:id:tsukatoh:20200525184248p:plain

ARM対応になり、Powershellでの管理必須というハードルから解放されました。
導入もしやすくなったのではないでしょうか?
是非お試しあれ。

Azure Active Directory Domain Services を PowerShell で構築する

Azure Active Directory Domain Services (Azure AD DS または AADDS)

AADDSって構築後にDNSの設定をしないとドメイン参加できないので、構築後のAADDSリソースの概要をAzure Portalから見るとDNSを構成するボタンが表示されています。
今回、それをPowerShellでやる場合のメモです。

そもそもとしてのAzure AD DS の構築方法としては以下があります。

  • Azure Portal で構築する
  • Azure PowerShell で構築する
  • Azure Resource Manager (ARM) で構築する

Azure Portal で構築する

docs.microsoft.com

PowerShell での構築方法

docs.microsoft.com

ARM テンプレートでの構築方法

docs.microsoft.com

今回は2つ目のPowerShellで構築していたのですがAADDS構築後に通常だとAzure Portalから操作する部分があり、そこも自動化したくて考慮点を調べました。

考慮点

  • Custom DNS をVNetへ設定しなければならない
  • Network Security Group をSubnetへ設定しなければならない

AADDS構築後に以下の画像のようにDNS構成をするボタンが概要ページに出てきますが、ここでカスタムDNSNSGの設定をしてくれています。 f:id:tsukatoh:20200427174330p:plain

PowerShell での追加設定の仕方

Custmom DNS をVNetへ設定する

  1. 既存の構築用に使ったNew-AzVirtualNetworkの最後尾にDnsServerを追加して適用する。

【構築時のコマンド】

PS> $VNet = New-AzVirtualNetwork `
      -ResourceGroupName <ResourceGroupName> `
      -Location <AzureLocation> `
      -Name <VNetName> `
      -AddressPrefix 0.0.0.0/0 `
      -Subnet <SubnetName>
PS> $VNet | Set-AzVirtualNetwork

【適用するコマンド】

PS> $VNet = New-AzVirtualNetwork `
      -ResourceGroupName <ResourceGroupName> `
      -Location <AzureLocation> `
      -Name <VNetName> `
      -AddressPrefix 0.0.0.0/0 `
      -Subnet <SubnetName> `
      -DnsServer 0.0.0.4,0.0.0.5
PS> $VNet | Set-AzVirtualNetwork

上記設定まで完了すると以下のように変化します。 NSGを設定しろ的な感じですね。 f:id:tsukatoh:20200427174421p:plain

Network Security Group (NSG) をSubnetへ設定する

  • VNetの情報取得
PS> $VNet = Get-AzVirtualNetwork -Name <VNetName> -ResourceGroupName <ResourceGroupName>
  • サブネットの情報取得
PS> $Subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $VNet -Name <SubnetName>
  • Network Security Group (NSG) の情報取得
PS> $Nsg = Get-Az NetworkSecurityGroup -ResourceGroupName <ResourceGroupName> -Name <NSGName>
  • Subnetへ適用するNSGのコンフィグ設定
PS> $Subnet.NetworkSecurityGroup = $Nsg
  • VNetへのコンフィグ適用
PS> Set-AzVirtualNetwork -VirtualNetwork $VNet

まとめると以下になります。

PS> $VNet = Get-AzVirtualNetwork -Name <VNetName> -ResourceGroupName <ResourceGroupName>
PS> $Subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $VNet -Name <SubnetName>
PS> $Nsg = Get-Az NetworkSecurityGroup -ResourceGroupName <ResourceGroupName> -Name <NSGName>
PS> $Subnet.NetworkSecurityGroup = $Nsg
PS> Set-AzVirtualNetwork -VirtualNetwork $VNet

完了するとPortalのボタンで設定したものと同じようになります。 f:id:tsukatoh:20200427174502p:plain

上記で問題なくドメイン参加まで行けましたので、PowerShellで全部組みたい方(少数派デスヨネ)に参考になれば。

KEDA 1.0.0がリリースされました!

最近注目しているKEDA(Kubernetes-based Event Driven Autoscaling)の1.0.0リリースされました!

keda.sh

アップデート内容としては、以下となります。

  • スケーラーの追加 →External(外部スケーラー)、NATS Streamingの2つが追加
  • スケーラーの拡張性
    →別のコンテナでスケーラーを実行し、gRPCを介してKEDAと通信する
  • IDベースの認証用のTriggerAuthenticationとPod Identityがデプロイメント間で共有できるようになった
  • デプロイメントのスケールアウトに加えて、イベントでジョブをスケジュールする
  • GitHubアクションにおける追加のテストと自動化

KEDAについてはServerlessDays Fukuoka 2019でお話させていただく予定です。
注目しているプロダクトが進化していくのは嬉しいですね!
(少しでもコミットできればと思っています。。。

fukuoka.serverlessdays.io