2020年7月18日土曜日

■Unified Access GatewayをAzure上にマネージドディスク/可用性セットありで展開する

Unified Access Gatewayは、vSphereだけでなく、AzureやEC2でも展開できます。
今回はAzure上に展開した場合について記載します。
UAGをAzure上に展開するためのスクリプトは、VMware社のダウンロードサイトからダウンロードすることが可能です。

※最新版は以下です


ただ、ダウンロードできるスクリプトのままAzure上に展開すると、Azureのマネージド・ディスクにならず、可用性セットにも入れることはできません。
※Horizon Cloud on AzureのUAGはマネージド・ディスクで可用性セット組まれ、おまけにデフォで2台構築されます。超イケてます。

なので、マネージド・ディスクにし、可用性セットに紐づけ、おまけに2台展開するようにスクリプトに追記してみました。
※2020年07月20日追記:
ブログ上での記載方法に問題があったため、Github にライセンスの記述を加えて上げなおしました。


上述のスクリプトでは、.ini ファイルで指定された可用性セットを読みだすようにしています。

$AvailSetName = $settings.Azure.AvailSet

なので、以下のようにiniファイルの[Azure]セクションの中に、あらかじめ作成した可用性セットの名前を入れます。

[Azure]
~~~中略~~~
AvailSet=uagdeploy

UAGを展開するスクリプトは、もともと以下の行でiniファイルの内容を$settings変数に格納するようになっています。

$settings = ImportIni $iniFile

この行以降であれば、iniファイル内に定義した変数とその値を取り出すことができます。 例えば、[General]セクションにあるnameに指定したUAG名は、以下の行で、スクリプト内にuagの仮想マシン名として取り込まれます。

$uagName=$settings.General.name

$settingsという変数の属性の一つをiniファイル内に任意に設定して、スクリプトから任意に呼び出せる感じでしょうか。 慣れてくれば、もっと自由にUAGを展開するスクリプトを組みなおせそうです。

追記:
こそこそと英語でもブログをつけてみたり。。。

2019年12月22日日曜日

■UAG 3.8 検証メモ(3):LinuxからUAG 3.8をvSphere環境に展開してみた(完結)

前回までで、私の目的は以下のとおりでした。

「一つのLinux仮想マシンの中に、Puppet ServerとPowerCLIを同居させるという構成」

そう、ここまでは、タイトルのUAGなんてちっとも出てこなかったんです。
ですが、そんな時、とある同僚氏が以下のようなことを言います。

「あれ?Yzさんなんだかおもしろそうなことをやっていますね。ところで僕最近PowerShellからUAGを展開するってやつやってみたんですけど、Linux版のPowerCLIでもUAGの展開はできるんですかね?」

なんだかとっても面白そうです。私もUAGのPowerShell展開は何回かやったことはあるのですが、Linux版PowerCLIでUAGが展開できるなら、現時点で私がやりたいほとんどのことがLinuxから行えることになります。
もともとの目的からはちょっと離れますが、やってみる価値はあります(多分。。。多分。。)。
こうして私はブログタイトル「UAG 3.8 検証メモ」に至ったのです。
※ちなみに、UAGのPowerShell展開の要件は以下の通りです。

  • PowerShellをキックするWindowsは8.1もしくは2008 R2以上であること
  • VMware OVF Tool 4.0.1以上が上述のWindowsマシンにインストールされていること
  • 展開先の環境は以下のいずれかであること
    •  ESXiがvCenter Serverで管理されていること
    •  Microsoft Hyper-V
    •  Microsoft Azure
    •  Amazon AWS EC2

※参考:System Requirements to Deploy Unified Access Gateway Using PowerShell

。。。はい。今回私がやろうとしていることは思いっきりサポート外構成です。
※本番環境でやるときは一時的にでもいいのでWindowsマシンをご用意ください※

気を取り直して、OVF Toolをダウンロードしてインストールします。

ダウンロードしたOVF ToolをUbuntu上に移動して、実行可能なように権限を変えます。


PS /home/htyz> ls
VMware-ovftool-4.3.0-14746126-lin.x86_64.bundle
PS /home/htyz> chmod 777 ./VMware-ovftool-4.3.0-14746126-lin.x86_64.bundle
PS /home/htyz>

変更後。実行します。途中インストールを確認したり、利用規約に同意するために、必要に応じて操作を求められます。

PS /home/htyz> sudo ./VMware-ovftool-4.3.0-14746126-lin.x86_64.bundle
[sudo] password for htyz:
Extracting VMware Installer...done.
You must accept the VMware OVF Tool component for Linux End User
License Agreement to continue.  Press Enter to proceed. #ここでEnter
VMWARE END USER LICENSE AGREEMENT

PLEASE NOTE THAT THE TERMS OF THIS END USER LICENSE AGREEMENT SHALL GOVERN YOUR
USE OF THE SOFTWARE, REGARDLESS OF ANY TERMS THAT MAY APPEAR DURING THE
INSTALLATION OF THE SOFTWARE.

IMPORTANT-READ CAREFULLY:   BY DOWNLOADING, INSTALLING, OR USING THE SOFTWARE,
YOU (THE INDIVIDUAL OR LEGAL ENTITY) AGREE TO BE BOUND BY THE TERMS OF THIS END
USER LICENSE AGREEMENT ("EULA").  IF YOU DO NOT AGREE TO THE TERMS OF THIS
EULA, YOU MUST NOT DOWNLOAD, INSTALL, OR USE THE SOFTWARE, AND YOU MUST DELETE
OR RETURN THE UNUSED SOFTWARE TO THE VENDOR FROM WHICH YOU ACQUIRED IT WITHIN
THIRTY (30) DAYS AND REQUEST A REFUND OF THE LICENSE FEE, IF ANY, THAT YOU PAID
FOR THE SOFTWARE.

EVALUATION LICENSE.  If You are licensing the Software for evaluation purposes,
Your use of the Software is only permitted in a non-production environment and
for the period limited by the License Key.  Notwithstanding any other provision
in this EULA, an Evaluation License of the Software is provided "AS-IS" without
indemnification, support or warranty of any kind, expressed or implied.

1.      DEFINITIONS.

1.1 "Affiliate" means, with respect to a party, an entity that is directly or
indirectly controlled by or is under common control with such party, where
"control" means an ownership, voting or similar interest representing fifty
percent (50%) or more of the total interests then outstanding of the relevant
entity (but only as long as such person or entity meets these requirements).
 :
 :
<中略>
 :
 :
12.12  Contact Information.  Please direct legal notices or other
correspondence to VMware, Inc., 3401 Hillview Avenue, Palo Alto, California
94304, United States of America.  If You have any questions concerning this
EULA, please send an email to info@vmware.com.

Do you agree? [yes/no]:  yes # ここでyes

The product is ready to be installed.  Press Enter to begin # ここでEnter
installation or Ctrl-C to cancel.

Installing VMware OVF Tool component for Linux 4.3.0
    Configuring...
[######################################################################] 100%
Installation was successful.
PS /home/htyz>

続いてUAG 3.8の展開です。
UAG 3.8と、その展開に必要なPowerShellモジュールを以下からダウンロードします。


今回使用するファイルは以下の二つです。

  • Unified Access Gateway (UAG) 3.8 for vSphere and Amazon AWS (Non-FIPS)
  • Unified Access Gateway (UAG) 3.8 PowerShell Scripts

ダウンロードしたら以下のように二つのファイルをLinux上に配置します。

PS /home/htyz> ls
euc-unified-access-gateway-3.8.0.0-15239073_OVF10.ova  uagdeploy-3.8.0.0-15239073.zip
PS /home/htyz>

zipファイルを解凍すると、uagdeployというフォルダが作成されます。


PS /home/htyz> unzip ./uagdeploy-3.8.0.0-15239073.zip
Archive:  ./uagdeploy-3.8.0.0-15239073.zip
   creating: uagdeploy/
  inflating: uagdeploy/uagdeploy.ps1
  inflating: uagdeploy/uagdeploy.psm1
  inflating: uagdeploy/uag5-smartcard.ini
  inflating: uagdeploy/uagdeployhv.ps1
  inflating: uagdeploy/uag12-azure.ini
  inflating: uagdeploy/uag9-awhv.ini
  inflating: uagdeploy/uag4-radius.ini
  inflating: uagdeploy/uag9-aw.ini
  inflating: uagdeploy/uag10-vidm.ini
  inflating: uagdeploy/uagdeployaz.ps1
  inflating: uagdeploy/uag1-basic.ini
  inflating: uagdeploy/uag3-securid.ini
  inflating: uagdeploy/uag11-ec2.ini
  inflating: uagdeploy/uag2-advanced.ini
  inflating: uagdeploy/uagdeployec2.ps1
PS /home/htyz> ls
euc-unified-access-gateway-3.8.0.0-15239073_OVF10.ova  uagdeploy  uagdeploy-3.8.0.0-15239073.zip
PS /home/htyz>

通常は展開された.iniファイルの中から、自分自身が使いたいファイルを編集してスクリプト「uagdeploy.ps1」をキックします。
※.iniファイルの編集方法については以下のコミュニティのスレッドに詳しくまとめられています。


ただし、今回はLinux上でPowerShellスクリプトをキックするため、「uagdeploy.ps1」そのものにちょっと手を加える必要があります。

「uagdeploy.ps1」は、Windows上での動作を想定されています。
また、中身は先ほどインストールしたovftoolコマンドを使用したスクリプトファイルです。
そのため、そのままだとWindows版のovftoolのパスを指定するようになっています。
なので、Linux版のovftoolのパスを調べて指定します。

PS /home/htyz/uagdeploy> whereis ovftool
ovftool: /usr/bin/ovftool
PS /home/htyz/uagdeploy> file /usr/bin/ovftool
/usr/bin/ovftool: symbolic link to /usr/lib/vmware-ovftool/ovftool
PS /home/htyz/uagdeploy>

※2019年12月時点で最新版のスクリプトファイルでは、121行目でovftoolのパスを指定しています。

121 $ovftool = "/usr/lib/vmware-ovftool/ovftool"


次に、iniファイルを編集します。今回は純粋な展開だけを検証します。
※なので、固定IPアドレスなどのオプションは省いています。
uag1-basic.iniを以下のように編集します。
<>でくくったところは、任意の値に変更して利用可能です。

PS /home/htyz/uagdeploy> cat -n ./test.ini
     1  [General]
     2  name=UAG1
     3  source=../euc-unified-access-gateway-3.8.0.0-15239073_OVF10.ova
     4  target=vi://administrator@vsphere.local:<パスワード>@/Datacenter/host/<ESXiホスト名またはクラスタ名>
     5  ds=<データストア名>
     6  deploymentOption=onenic
     7  netInternet=<接続先仮想スイッチのポートグループ名>
     8  netManagementNetwork=<接続先仮想スイッチのポートグループ名>
     9  netBackendNetwork=<接続先仮想スイッチのポートグループ名>
    10  honorCipherOrder=true
    11
PS /home/htyz/uagdeploy>

それではいよいよキックします。途中、CIEPへの同意やパスワードの設定が求められます。
※CIEPは任意です。

PS /home/htyz/uagdeploy> ./uagdeploy.ps1 ./test.ini
Unified Access Gateway (UAG) virtual appliance deployment script
Enter a root password for UAG1: *********
Re-enter the root password: *********
An admin password must be specified if access to the UAG Admin UI and REST API is required
Enter an optional admin password for the Admin UI and REST API management access for UAG1: *********
Re-enter the admin password: *********
Join the VMware Customer Experience Improvement Program?

This setting is supported in UAG versions 3.1 and newer.

VMware’s Customer Experience Improvement Program (CEIP) provides VMware with information that enables VMware to
improve its products and services, to fix problems, and to advise you on how best to deploy and use our products.

As part of the CEIP, VMware collects technical information about your organization's use of VMware products and
services on a regular basis in association with your organization's VMware license key(s). This information does
not personally identify any individual.

Additional information regarding the data collected through CEIP and the purposes for which it is used by VMware
is set forth in the Trust & Assurance Center at http://www.vmware.com/trustvmware/ceip.html.

If you prefer not to participate in VMware's CEIP for UAG 3.1 and newer, you should enter no.

You may join or leave VMware's CEIP for this product at any time. In the UAG Admin UI in System Configuration,
there is a setting 'Join CEIP' which can be set to yes or no and has immediate effect.

To Join the VMware Customer Experience Improvement Program with Unified Access Gateway version 3.1 and newer,
either enter yes or just hit return as the default for this setting is yes.
Join CEIP for UAG1 ? (default is yes for UAG 3.1 and newer): yes
Deployment will use a self-signed SSL/TLS server certificate (SSLcert)
Deployment will use a self-signed SSL/TLS server certificate (SSLcertAdmin)
Opening OVA source: ../euc-unified-access-gateway-3.8.0.0-15239073_OVF10.ova
The manifest validates
Source is signed and the certificate validates
Opening VI target: vi://administrator%40vsphere.local@xxxx.xxxxx.xxxxx:443/Datacenter/host/XXXXXXXX
Deploying to VI: vi://administrator%40vsphere.local@XXXXXXXX.XXXXXX.XXXX:443/Datacenter/host/XXXXXXXX
Transfer Completed
Powering on VM: UAG1
Task Completed
Received IP address: fe80::250:56ff:fea6:ed0c
Completed successfully
UAG virtual appliance UAG1 deployed successfully
PS /home/htyz/uagdeploy>

正常に展開できました。これで検証は成功です。(サポート外構成なので、検証以外に使いどころはほとんどないですが。。。)
あとは、UAGの管理画面から好きな機能を設定することで、Content GatewayやTunnel、Horizonのゲートウェイとして利用可能です。
繰り返しになりますが、本番環境で展開する際は、必ずサポートされた構成で、WindowsマシンからPowerShellスクリプトをキックして展開するようにしてください。

2019年12月21日土曜日

■UAG 3.8 検証メモ(2):Linux にPowerCLIをインストールしてみた

私の目的は以下のとおりでした。

「一つのLinux仮想マシンの中に、Puppet ServerとPowerCLIを同居させるという構成」

前回のブログを公開した後に気づいたのですが、ブログタイトルの「UAG 3.8 検証メモ」と、上述した私の目的はちょっと乖離しています。
なんでここまでぶれたかというきっかけは後述するとして、めげずにPowerCLIをインストールしていきます。

で、Linux版PowerCLIですが、インストール方法について記述された公式ドキュメントをなかなか見つけられなかったので、以下のブログ様を参照しました。
PowerCLIの現行(2019年12月時点)最新版は、以下から入手しました。
取得したzipファイルを、SCPなどでUbuntuに移し、optは以下のフォルダに移動します。

PS /home/htyz> dir


    Directory: /home/htyz

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
------          12/20/19  2:54 AM       94367926 VMware-PowerCLI-11.5.0-14912921.zip

PS /home/htyz> sudo mv ./VMware-PowerCLI-11.5.0-14912921.zip /opt/microsoft/powershell/6/Modules/
[sudo] password for htyz:
PS /home/htyz>

配置したら、unzipで展開します。
PowerShellでsudoコマンドが使えるのって、なんだか不思議な気持ちになります。

PS /opt/microsoft/powershell/6/Modules> sudo unzip ./VMware-PowerCLI-11.5.0-14912921.zip
Archive:  ./VMware-PowerCLI-11.5.0-14912921.zip
warning:  ./VMware-PowerCLI-11.5.0-14912921.zip appears to use backslashes as path separators
  inflating: VMware.DeployAutomation/EULA.rtf

展開後は、Import-Moduleコマンドを使ってインポートしていくのですが、以下のように「VMware.xxxxxxxxx.xxxx module is not currently supported...」といってインポートがこけることがままあります。
PS /opt/microsoft/powershell/6/Modules> Import-Module VMware.PowerCLI
WARNING: Please consider joining the VMware Customer Experience Improvement Program, so you can help us make PowerCLI a better product. You can join using the following command:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $true

VMware's Customer Experience Improvement Program ("CEIP") provides VMware with information that enables VMware to improve its products and services, to fix problems, and to advise you on how best to deploy and use our products.  As part of the CEIP, VMware collects technical information about your organization?s use of VMware products and services on a regular basis in association with your organization?s VMware license key(s).  This information does not personally identify any individual.

For more details: type "help about_ceip" to see the related help article.

To disable this warning and set your preference use the following command and restart PowerShell:
Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $true or $false.
Import-Module : VMware.VimAutomation.License module is not currently supported on the Core edition of PowerShell.
At line:1 char:1
+ Import-Module VMware.PowerCLI
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : OperationStopped: (VMware.VimAutomatio\u2026tion of PowerShell.:String) [Import-Module], RuntimeException
+ FullyQualifiedErrorId : VMware.VimAutomation.License module is not currently supported on the Core edition of PowerShell.,Microsoft.PowerShell.Commands.ImportModuleCommand

PS /opt/microsoft/powershell/6/Modules>

その場合は、「/opt/microsoft/powershell/6/Modules/VMware.PowerCLI/VMware.PowerCLI.psd1」に記載されている読み込み対象のモジュールからエラーになっているモジュールをコメントアウトしました。

 48 # Modules that must be imported into the global environment prior to importing this module
 49 RequiredModules = @(
 50 @{"ModuleName"="VMware.VimAutomation.Sdk";"ModuleVersion"="11.5.0.14898111"}
 51 @{"ModuleName"="VMware.VimAutomation.Common";"ModuleVersion"="11.5.0.14898112"}
 52 @{"ModuleName"="VMware.Vim";"ModuleVersion"="6.7.0.14898114"}
 53 @{"ModuleName"="VMware.VimAutomation.Core";"ModuleVersion"="11.5.0.14899560"}
 54 @{"ModuleName"="VMware.VimAutomation.Srm";"ModuleVersion"="11.5.0.14899557"}
 55 # @{"ModuleName"="VMware.VimAutomation.License";"ModuleVersion"="11.3.0.13990093"}
 56 @{"ModuleName"="VMware.VimAutomation.Vds";"ModuleVersion"="11.2.0.12483615"}
 57 @{"ModuleName"="VMware.VimAutomation.Vmc";"ModuleVersion"="11.5.0.14912923"}
 58 @{"ModuleName"="VMware.VimAutomation.Nsxt";"ModuleVersion"="11.5.0.14900141"}
 59 # @{"ModuleName"="VMware.VimAutomation.vROps";"ModuleVersion"="10.0.0.7893921"}
 60 @{"ModuleName"="VMware.VimAutomation.Cis.Core";"ModuleVersion"="11.5.0.14898113"}
 61 # @{"ModuleName"="VMware.VimAutomation.HorizonView";"ModuleVersion"="7.10.0.14653756"}
 62 @{"ModuleName"="VMware.VimAutomation.Cloud";"ModuleVersion"="11.0.0.10379994"}
 63 @{"ModuleName"="VMware.DeployAutomation";"ModuleVersion"="6.7.0.11233116"}
 64 # @{"ModuleName"="VMware.ImageBuilder";"ModuleVersion"="6.7.0.11233116"}
 65 @{"ModuleName"="VMware.VimAutomation.Storage";"ModuleVersion"="11.5.0.14901686"}
 66 @{"ModuleName"="VMware.VimAutomation.StorageUtility";"ModuleVersion"="1.3.0.0"}
 67 @{"ModuleName"="VMware.VumAutomation";"ModuleVersion"="6.5.1.7862888"}
 68 @{"ModuleName"="VMware.VimAutomation.Security";"ModuleVersion"="11.0.0.10380515"}
 69 @{"ModuleName"="VMware.VimAutomation.Hcx";"ModuleVersion"="11.5.0.14900247"}
 70 )

以上で一応PowerCLIをインストールできているはず。いくつかの機能は使えないけれど。
※ImageBuilderはずっとエラーを吐き続けていた。。もっと何か正しい方法がある気がしてならない。。

試しに、vCenter Serverに接続してみます。

PS /opt/microsoft/powershell/6/Modules> Connect-VIServer XXXXXXXX.XXXXXX.XXXX

Specify Credential
Please specify server credential
User: administrator@vsphere.local
Password for user administrator@vsphere.local: *********

Connect-VIServer : 12/21/19 1:24:25 PM  Connect-VIServer                The SSL connection could not be established, see inner exception.
At line:1 char:1
+ Connect-VIServer XXXXXXXX.XXXXXX.XXXX
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Connect-VIServer], ViError
+ FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_SoapException,VMware.VimAutomation.ViCore.Cmdlets.Commands.ConnectVIServer

PS /opt/microsoft/powershell/6/Modules>

と思ったらエラーがでました。SSL接続ができない旨のエラーです。
vCenterが自己署名証明書を使用しているので、接続を受け付けるよう設定を変更してあげる必要があります。

PS /opt/microsoft/powershell/6/Modules> Set-PowerCLIConfiguration -InvalidCertificateAction:ignore

Perform operation?
Performing operation 'Update PowerCLI configuration.'?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): Y

Scope    ProxyPolicy     DefaultVIServerMode InvalidCertificateAction  DisplayDeprecationWarnings WebOperationTimeout
                                                                                                  Seconds
-----    -----------     ------------------- ------------------------  -------------------------- -------------------
Session  UseSystemProxy  Multiple            Ignore                    True                       300
User                                         Ignore
AllUsers

PS /opt/microsoft/powershell/6/Modules>

再挑戦したところ、正常に接続できました。

PS /opt/microsoft/powershell/6/Modules> Connect-VIServer XXXXXXXX.XXXXXX.XXXX

Specify Credential
Please specify server credential
User: administrator@vsphere.local
Password for user administrator@vsphere.local: *********


Name                           Port  User
----                           ----  ----
XXXXXXXX.XXXXXX.XXXX          443   VSPHERE.LOCAL\Administrator

PS /opt/microsoft/powershell/6/Modules>

次回はいよいよUAGを展開します。あれ、Puppetは、、、?

■UAG 3.8 検証メモ(1):PowerShell CoreをLinuxにインストールしてみた

最近検証でvSphere上に仮想マシンをポンポン作ることが増えてきました。
特にWindowsの仮想マシンを作るたびに、手動でポチポチとGUI画面をいじっていたのですが、漠然と「もうちょっと効率化できたらいいなぁ」と最近思うようになりました。
現時点での具体的な要件としては、

  • Windowsの仮想マシンを作成したときに、仮想マシンのインベントリ名をWindowsのコンピュータ名として設定したい
  • 作成した仮想マシンを自動的にドメインに参加させたい

この二つです。
上記だけであれば、vCenter上で仮想マシンテンプレートからクローンを作成する際に、プロファイルをポチポチと割り当ててあげれば解決するのですが、使用するOSはWindows以外も含まれることがあるため、もう少し幅の広い構成管理ツールを導入したいと考えていました。

具体的には、Puppetです。
なぜPuppetなのかというと、以前神保町にある某社さんでPuppetの超絶わかりやすいセミナーを受けたことがあったのと、Rubyを以前趣味でちょこっとかじったことがあるため、Puppetに生かせたらいいなぁと思ったためです。

そこで私は懊悩しました。懊悩のプロセスは以下の通りです。
スタート地点がPuppetなので、もしかしたら「何でもっとすんなり考えないの?」と思う方もいらっしゃるかと思いますが、生暖かい目で読み飛ばしてください。

---<懊悩ここから>----------
LinuxでPuppet使って検証環境作成をちょっと楽にしたい。

Puppet Serverのインストール(+方法)を知りたい。
でも待てよ、これだけだとWindowsのコンピュータ名をvCenterのインベントリ名にしたり、ドメイン参加ができないのでわ。。。

vSphere Command Line Interfaceを使えばええんや!(多分)

vSphere Command Line Interfaceインストールできない。CPANまったくわからん
※プロキシ環境下だとそもそもCPANがうまくセットアップできない。。。
他に代替案がないか。。。

代替案1:vCenter ServerのREST API使えばいける!
→なぞに失敗。再トライ予定。
代替案2:大本命のPowerCLI!
でもこれ、Puppet Serverと同居できないのでわ。。
※PuppetマスターはLinux限定。PowerCLIってWindows用ですよね?(←誤解)

PowerCLI 11.5 のzipモジュール使えばいけそう!
MSのPS Core をLinuxにいれて、そこからzipでPowerCLIいれられる!
さらにその中にPuppet Serverを同居させる!
---<懊悩ここまで>----------

というわけで、一つのLinux仮想マシンの中に、Puppet ServerとPowerCLIを同居させるという構成に挑戦してみます。

今回は、Ubuntu 18.04にPowerShell Coreをインストールしてみたいと思います。
PowerShell Coreのインストール方法は、以下のMicrosoft公式サイトに記載されています。


なお、今回は以下の通りUbuntu 18.04を使用しています。

htyz@ubuntu:~$ cat -n /etc/lsb-release
     1  DISTRIB_ID=Ubuntu
     2  DISTRIB_RELEASE=18.04
     3  DISTRIB_CODENAME=bionic
     4  DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
htyz@ubuntu:~$

それでは、先ほどのMicrosoft公式サイトのインストラクションに従ってインストールします。

htyz@ubuntu:~$ wget -q https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb
htyz@ubuntu:~$ sudo dpkg -i packages-microsoft-prod.deb
htyz@ubuntu:~$ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu bionic InRelease
 :
<略>
 :
Get:32 http://archive.ubuntu.com/ubuntu bionic-security/multiverse Translation-en [2600 B]
Fetched 18.3 MB in 2min 19s (132 kB/s)
Reading package lists... Done
htyz@ubuntu:~$ sudo add-apt-repository universe
'universe' distribution component is already enabled for all sources.
htyz@ubuntu:~$ sudo apt-get install -y powershell
Reading package lists... Done
 :
<略>
 :
Processing triggers for libc-bin (2.27-3ubuntu1) ...
htyz@ubuntu:~$

上記でインストール完了です。
インストール後は、pwshコマンドでPowerShellに切り替えることが可能です。

htyz@ubuntu:~$ pwsh
PowerShell 6.2.3
Copyright (c) Microsoft Corporation. All rights reserved.

https://aka.ms/pscore6-docs
Type 'help' to get help.

PS /home/htyz> dir


    Directory: /home/htyz

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
------            1/2/19 11:49 PM           3132 packages-microsoft-prod.deb

PS /home/htyz>

試しにdirコマンドを実行すると、ちゃんと実行できていることがわかります。
次回はPowerShellにvSphere PowerCLIをインストールしていきます。

2019年12月12日木曜日

■Workspace ONE UEM API Explorerについて

この投稿は、vExperts Advent Calendar 2019 - Adventar 12日目の記事です。

今年初めて vExperts Advent Calendar に参加させていただきます。どうぞ宜しくお願い致します。

今回の記事のテーマは、「Workspace ONE UEM(以下UEM)の持つREST APIの動作確認をしてみること」です。

VMware製品の持つAPIの多くは、以下のページでどのようなものがあるかを確認することが可能です。


ただ、UEMのAPIについては上記ページに記載はなく、UEMホストそのものに同様のページが設けられています。具体的には各UEMホストの、以下のURLに準備されています。

  • https://<UEMのFQDN>/api/help/#!/apis

上記URLにアクセスすると、Workspace ONE UEM API Explorerが表示されます。
REST APIの動作確認というと、postmanなどのREST Clientをインストールしたり、FireFoxやChromeにREST Clientのプラグインを追加したりする方が多いかと思います。
UEMがバージョン8.xのころは私も上記の方法でREST APIの動作確認を行っていましたが、バージョン9.2ごろから、このWorkspace ONE UEM API ExplorerからREST APIの動作を確認することができるようになりました。
今回は一例として、「UEMに登録されているユーザーアカウントをREST APIで取得」したいと思います。

今回は、ハンズオンラボ環境を使用するので、以下のホストのREST APIにアクセスしています。
※アクセスしてページを表示するだけならいつでもできますが、実際にAPIを利用するには、ハンズオンラボコース(HOL-2051-09-UEM)の登録と開始が必要です。

  • hol.awmdm.com

上記ページにアクセスすると、以下のような画面が表示されます。

このエントリを記述した2019年12月12日時点で筆者が確認する限り、
この画面はどのUEMホストにおいても日本語化されていないようです。

上記の画面から、画面左上のAPIsをクリックすると、APIを用途ごとに分類したページが表示されます。


今回はユーザをREST APIで取得するため、右上の検索欄にuserと入力します。
userと入力すると検索条件に合致するAPIがリストされていきます。


今回は、/users/searchというAPIを利用するので、画面をスクロールダウンして探し出し、API名をクリックします。


クリックすると、API検索画面の最上部が表示されます。この画面をスクロールダウンすると/users/searchのパラメータ入力画面があるのですが、いったんここでは[AUTHORIZE]ボタンをクリックします。


[AUTHORIZE]ボタンをクリックすると、UEMに対してREST APIでGETやPOSTを行う権限を持つユーザーのログイン情報や、使用しているUEMのテナント情報などを投入する画面がポップアップ表示されます。

オレンジ色の枠内で示したエリアで、必要な情報を入力します。
全部表示されない場合は、オレンジ枠内右側のスクロールバーを
スクロールダウンし、適宜必要な項目を表示/入力します。

今回は、以下3つの情報を入力します。
  1. ユーザー認証情報(ユーザー名/パスワード)
  2. REST APIキー
  3. 組織グループID
それぞれの情報を集めてみましょう。
まずはユーザー認証情報です。これは単純に、UEM管理コンソールの管理者ユーザー名とパスワードです。

usernameとpassword欄に入力し、
[Authorize]ボタンをクリックします。

次に、REST APIキーです。これは、UEM管理コンソール上にログイン後、グループと設定>すべての設定>システム>高度な設定>API>REST APIで閲覧できます。デフォルト状態ではコピーすることができませんが、[オーバーライド]することでコピー可能になります。

管理コンソールにログインして。。
[グループと設定](画面左下)→[すべての設定]をクリック
ポップアップ表示されたら、
[システム][高度な設定][API][REST API]と進み、
[オーバーライド]をクリック。
オーバーライド後、画面に表示されたAPIキーの中から、
アカウントタイプが「管理者」のAPIキーをコピー

ここまで来たら、あとはAPIの画面に戻り、aw-tenant-code欄にAPIキーをペーストします。

ユーザー名/パスワードを入力した後に[AUTHORIZE]用の
ポップアップ画面が閉じるため、再度画面右上の
[AUTHORIZE]ボタンをクリックして、
aw-tenant-code欄にAPIキーをペースト
し、
ポップアップ画面内の[Authorize]ボタンをクリックします。


最後に組織グループIDです。これはUEM管理コンソールログイン後、画面左上のタブにマウスオーバーした際に表示される「グループID」です。

画像は『■ HOL-1957-01-UEM(5):組織グループってなんだ? - その1 』から。
※今回使用する値とは異なります

グループIDをコピーし(または控え)たら、先ほどと同様APIの画面に戻り、aw-groupid欄にペーストします。

画面右上の[AUTHORIZE]ボタンをクリックして、
aw-groupid欄に組織グループIDをペースト
し、
ポップアップ画面内の[Authorize]ボタンをクリックします。

それではテスト用に作成したユーザー情報を取得してみます。
認証情報等を入力した画面が閉じたら、画面をスクロールダウンし、/users/searchのクエリ入力画面にてfirstname欄にtestと入力します(※この環境では事前にtestというファーストネームを持つユーザーを3つ作成しています)。正常にAPIが動作すれば、3つのユーザーの情報を取得してくれるはずです。


クエリを入力したら、[Try it out!]をクリックし、リクエストを実行します。


実行すると、[Try it out!]ボタンの下に、CurlでこのREST APIをたたく場合のオプション付きの実行例が表示されます。UEMにアクセス可能なLinuxでこのコマンドを使用することでも、同様の結果が得られます。


そしてさらにスクロールダウンすると、レスポンスが出力されています。


今回はユーザー情報の取得を実施しましたが、ほかにも様々なAPIが用意されています。
普段からUEMを利用される方は、ご利用中のUEMコンソールのAPIをのぞいてみると、今の管理操作をちょっと楽にしてくれる、思わぬAPIを見つけられるかもしれませんね。

明日の vExperts Advent Calendar 2019 - Adventarmasotsuka さんです。
どうぞ宜しくお願い致します。

2019年10月6日日曜日

■VCAP-DTM Design受験レポート

昨日、VCAP-DTM Designを受験して、なんとか合格できましたので、「こんなことをやりました」というのを纏めて記載します。
「今度VCAP-DTMに挑戦するよ!」という方の足掛かりになれば幸いです。

■VCAP-DTM Designとは
VMware 社の提供する VDI 製品、VMware Horizon 7と、それに関連する製品群についての設計知識に関する能力を問う資格試験です。
VMware 社の提供する資格試験としては VCP が有名ですが、今回受けてきた VCAP はVCP の上位資格として位置づけられています。
DTM は DeskTop and Mobilityの略です。
VCAP は対象になる製品によってDCV、NV、DTM、CMAの4種類があります。
また、4種類の VCAP それぞれに、DesignとDeployの2種類があります。

Designは VCP と同様の問題形式で、設計に必要な知識を問います。試験時間は2時間ちょっとです。
Deployはリモートで試験環境に接続し、実際の構築を行う試験で、試験時間は4時間程度です。

■VCAP-DTM Designでの試験対象
主に、以下の製品が試験の対象になります。
  • VMware Horizon 7 (バージョン7.2)
  • VMware App Volumes
  • VMware User Environment Manager(現Dynamic Environment Manager)
  • VMware AirWatch(現Workspace ONE UEM)
  • VMware Identity Manager(現Workspace ONE Access)
  • VMware vRealize Operations Manager for Horizon
  • VMware Unified Access Gateway

■試験勉強に使用したマテリアル
主に以下の二つのWebサイトにある、試験対象製品の公式ドキュメントを読みました。
指定のバージョンは7.2なので、7.2と同時期にリリースされた関連製品群のドキュメントを探す必要があります。
この探す作業が結構キツく、勉強開始当初は途方に暮れていたのですが、試験対象バージョンの製品の公式ドキュメントを纏めている方がいらっしゃいました。
上記リンク先のブログで、必要なVMware 公式ドキュメントがまとめられたzipファイルをダウンロード可能です(2019年10月6日現在)

上記のドキュメントの内、特に以下の2つのドキュメントは、Horizonの重要なコンセプトがまとめられています。
  • VMWARE HORIZON 7 ENTERPRISE EDITION REFERENCE ARCHITECTURE
  • VMWARE HORIZON 7 ENTERPRISE EDITION MULTI-SITE REFERENCE ARCHITECTURE
そのため何度か読み返すことで、Horizon設計のベースとなる考え方を身に着けるのに大いに役立ちました。
そのほかのドキュメントは、上記2つのドキュメントを読んでいてちょっとピンとこなかった製品や機能の細かい仕様を把握するのに使用しました。

■その他
試験では英語を選択しました(ピアソンの申し込み時には日本語も選択肢にありました。ただ、今までVCAPが日本語対応したという話を聞いたことがなく、半信半疑でした。また、上述したドキュメントによるインプットもすべて英語のため、勉強時と受験時の差異が少なくていいと判断しました)。
私の英語のレベルは勉強をちょっと頑張った高校生レベルです。ネイティブスピーカーや留学経験者、帰国子女の皆さんのようにぺらぺら、というわけではありませんが、幸いにも15分程度時間が余ったので、回答漏れがないかを見直すことができました。

■感想
実はこの試験、私は9月に一度受けて落ちています。
今回は2度目の挑戦だったのですが、試験勉強といえど、製品について知れば知るほど、自分の知識の足りなさとVMwareの描くEUCの可能性を感じることができました。

今回は幸いにも合格できましたが、だからといって自分自身が劇的につよつよエンジニアになったわけではないため、今後も精進していきたいと思います。

2019年7月9日火曜日

■Unified Access Gatewayにtcpdumpとnetcatをインストールしてみよう

Unified Access GatewayはPhoton OS上で動いています。そのため、いつもお世話になっているyumコマンドやaptコマンドが使えません。
「やっぱり既成の仮想アプライアンスだから、インストールはあきらめたほうがいいのかなぁ」などと思っていたら、VMware社のPhotonOSのGithubページに以下のような記事がありました。

■Installing the Packages for tcpdump and netcat with tdnf

。。。なんか行けそう。
※UAGに限らず、既成の仮想アプライアンスにコマンドをインストールするときは事前にスナップショットをとりましょう
ちなみに、今回はUAG 3.5を使用しています。

whereisコマンドでtdnfをひっかけてみると、どうやら"/etc/tdnf/tdnf.conf"が設定ファイルのようです。
tdnfってあまり聞いたことないコマンドですが、名前的にdnfと同じように使えるのでは?
と思い早速tdnf.confにプロキシ設定を追記しました。書式はyum.confやdnf.confと同じです。

root@photon-machine [ /etc/tdnf ]# more /etc/tdnf/tdnf.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=true
repodir=/etc/yum.repos.d
cachedir=/var/cache/tdnf
proxy=http://xxx.xxx.xxx.xxx:xxxx/ #ここを追記
proxy=https://xxx.xxx.xxx.xxx:xxxx/ #ここを追記
root@photon-machine [ /etc/tdnf ]#

追記後、netcatをインストールしたら以上にインストールできました。

root@photon-machine [ /etc/tdnf ]# tdnf install netcat
Refreshing metadata for: 'VMware Photon Linux 2.0(x86_64) Updates'
Refreshing metadata for: 'VMware Photon Extras 2.0(x86_64)'
Refreshing metadata for: 'VMware Photon Linux 2.0(x86_64)'
photon                                 1472127    100%
Installing:
netcat                                          x86_64                  0.7.1-5.ph2                     photon                     64.24k 65778

Total installed size:  64.24k 65778
Is this ok [y/N]:y

Downloading:
netcat                                   38627    100%
Testing transaction
Running transaction
Installing/Updating: netcat-0.7.1-5.ph2.x86_64

Complete!
root@photon-machine [ /etc/tdnf ]# 

tcpdumpはというと、そのままやってもインストールができません。

root@photon-machine [ /etc/tdnf ]# tdnf install -y tcpdump
Found 1 problem(s) while resolving
1. installed package vmware-gss-support-2.0.0.0-1.noarch obsoletes tcpdump provided by tcpdump-4.9.2-2.ph2.x86_64
Error(1301) : Hawkey general runtime error
root@photon-machine [ /etc/tdnf ]#

何やら"vmware-gss-support-2.0.0.0-1.noarch"というパッケージがインストールを阻害しているようです。
どうやらこのパッケージは、VMwareサポートに問い合わせ時に、サポートからのインストラクションによってデバッグ用ツールをインストールするためのツールのようです。

root@photon-machine [ /etc/tdnf ]# tdnf info vmware-gss-support
Name          : vmware-gss-support
Arch          : noarch
Epoch         : 0
Version       : 2.0.0.0
Release       : 1
Install Size  :   1.02M 1066015 (1066015)
Repo          : @System
Summary       : Bundle of network diagnose packages/tools for VMware GSS Support.
URL           : (null)
License       : commercial
Description   : This package bundles and places binary rpms for network diagnosing tools,
such as tcpdump, ethtool, onto the system. Those packages are only
to be installed on the system, instructed by VMware GSS support, with
provided installation script when debugging system/network issues.
Once debugging task has completed, they are to be uninstalled from the
system with provided uninstallation script. It is to keep the system
meeting STIG compliance with security hardening requirements.


Total Size:   1.02M 1066015 (1066015)
root@photon-machine [ /etc/tdnf ]# 

"vmware-gss-support-2.0.0.0-1.noarch"をremoveしてから再トライしたところ、tcpdumpがインストールできました。

root@photon-machine [ /etc/tdnf ]# tdnf remove vmware-gss-support

Removing:
vmware-gss-support                              noarch                  2.0.0.0-1                       @System                   1.02M 1066015

Total installed size:   1.02M 1066015
Is this ok [y/N]:y
Testing transaction
Running transaction
Removing: vmware-gss-support-2.0.0.0-1.noarch

Complete!
root@photon-machine [ /etc/tdnf ]# tdnf install -y tcpdump

Installing:
tcpdump                                         x86_64                  4.9.2-2.ph2                     photon-updates            2.22M 2329996

Total installed size:   2.22M 2329996

Downloading:
tcpdump                                 912388    100%
Testing transaction
Running transaction
Installing/Updating: tcpdump-4.9.2-2.ph2.x86_64

Complete!
root@photon-machine [ /etc/tdnf ]#

構築時に本格的に困ったらサポートにお問い合わせいただくのがベストですが、ちょっと切り分けのために使ってみたいコマンドがある場合は、事前に停止状態のUAGのスナップショットをとって、tdnfで欲しいコマンドを探してインストールしてみるという選択肢もありかもしれませんね。

2019年4月7日日曜日

■Workspace ONE UEMで試してみた(6):組織グループの管理者を作成してみよう

前回からだいぶ時間が空いてしまいましたが、引き続きHOL1957で体験できるUEMの機能について記述します。

今回は、組織グループの管理者の作成についてです。

前回までで、組織グループは「設定を区分けするためのグループ」と説明しました。
組織グループはデバイスの「機能」だけでなく、「用途」に応じて組織グループを構成することで、企業で使用されるデバイス群を適切に管理することを可能にするものです。

ですが、このデバイスが大量にあった場合や、組織の体制上どうしても一つの管理者では管理を行えない場合はどうでしょうか。

例えば、デバイスが100,000台あり、いくつもの組織グループに分散して管理されている場合、それらを一つの管理者アカウントで設定、管理することは適切でしょうか。管理者アカウントに実質的にログインする管理者さんが複数いたとしても、ひとつの管理者アカウントがいくつもの組織グループを管理売る場合、組織グループの選択ミスなどが考えられます(重役向けデバイスに配信したい社内WebサイトのリンクをパートタイマーさんのBYODデバイス向けに配信したりしたら、大問題です)。

例えば、世界中に拠点を置くような企業の場合、Follow The Sunの対応や、多言語対応が求められます。
組織グループは任意の数作成できて、各国の拠点ごとに必要な設定を実施可能です。
ただ管理者アカウントがひとつの場合、一人の管理者が24時間多言語対応でバリバリ戦わなくてはいけなくなるかもしれませんし、ひとつの管理者アカウントを国をまたいだ複数名で共有するとしても、逐一管理者アカウントの言語設定をログイン時に変更しなくてはいけないかもしれません。前者ははっきり言ってつらいものがありますし、後者も手間が増えてしまいます。
図1:管理者アカウントがひとつ、管理者もひとり、
Follow The Sunで多言語対応。。。
24時間、戦えますか?
そのため、組織の体制やデバイスの量によっては、管理者を複数作成し、それぞれに管理を任せてしまうことが得策です。
図2:展開する国が増えたり、部門が増えたりしても、
もう怖くない!
今回は上記の[図2]をもとに、管理者の作成方法を、組織グループの作成方法とともに記載します。
まずは組織グループを作成します。
グループと設定>グループ>組織グループ>詳細と進み、
[サブ組織グループを追加]タブをクリックします。
図2の中の「HtYz」にあたる組織グループを作成します。
赤いアスタリスク(*)のついた項目を埋め、保存をクリックします。
ログの出力を英語にするため、ここのロケールは英語にすることをお勧めします。
画面が自動的に遷移し、いつの間にか[詳細]タブに移っています。
実はこの時点で、すでに作成した組織グループ「HtYz」に画面が切り替わっています。
再び[サブ組織グループの追加]をクリックし、同じ要領で
図2の中の[HtYz001]にあたる組織グループを作成します。
画面上部のタブをクリックします。
ここでは作成した組織グループを階層構造で確認することが可能です。
デフォルトでは組織グループが青字で表示されています。
※モザイクなのは最上位組織グループですが、ここにはハンズオンラボ環境の仕様上、
登録者のメールアドレスが表示されるため、モザイクとしています。。。汗

太字で表示されているのは現在UEM管理コンソール画面で表示している組織グループです。
この図では組織グループ「HtYz001」にいますが、一つ上の「HtYz」をクリックします。
再び組織グループ「HtYz」が表示されます。
再び「サブ組織グループの追加」画面から
組織グループ「HtYz002」を作成します。
次に、管理者アカウントを作成します。
作成後、組織グループを移動せずに
アカウント>管理者>リスト表示と進み、
追加ボタンから[管理者を追加]をクリックします。
管理者の追加画面が表示されます。
[ベーシック]タブにて、管理者ユーザ名、パスワード、
ユーザのファーストネームとラストネーム、メールアドレス、
タイムゾーン、ロケールを埋めます。
※すべて赤いアスタリスク(*)のついた項目です。
ロケールなども忘れずに入力します。
ここのロケールは管理者がUEM管理コンソールの画面で目にする言語なので、
管理者ごとの母国語を選択するようにします。
※ここでは飽くまで例のため、英語に設定しています。
次に「役割」タブで、この管理者をどこの組織グループの、
どのような役割を与えるかを設定します。
ここでは図2における「HtYz」にあたる組織グループの、
「HOL Administrator」という役割を与え、保存します。
この管理者は、最上位組織グループ(組織グループ階層でモザイクだった場所)
にはアクセス権を持ちません
保存ボタンをクリックしたら、PINコードを聞かれます。
入力したら、自動的に画面が遷移します。
管理者ユーザのリスト表示画面に戻ります。
新しい管理者が表示されていることを確認し、画面右上の
現在の管理者ユーザ名(ラボ環境利用者のメールアドレスです)をクリックし、
ログアウトをクリックしてください。
最後に、作成した管理者でログインし、図2の状態になっていることを確認します。
ログイン画面に戻されます。
以降は、「■ HOL-1957-01-UEM(1):UEM管理コンソールログイン」で
示した要領でログインします。
ログイン後、画面右上には新しく作成した管理者ユーザが表示されます。
また、画面上部の組織グループ名をクリックすると、もともとあった
最上位組織グループが、移動可能な組織グループのリストから消えています。
今回示した方法を使用することで、管理者ユーザの設定可能な範囲を制限し、作業ミスを減らす、責任を分散するなどのメリットが考えられます。
大量のデバイスをひとり(または少人数のチーム)で管理することで、管理者の負担が大きくなってしまうことが不安な場合は、管理者を増やし、担当範囲を分けてしまうことで負担を軽減することをご検討してみてください

2019年3月9日土曜日

■Workspace ONE UEMで試してみた(5):組織グループってなんだ? - その2

前回は組織グループの存在意義について簡単にご説明し、組織グループの画面上の確認箇所について触れました。
今回は、組織グループの仕様について説明します。
  1. 設定、デバイス、ユーザはすべて組織グループに紐づく
    ※デバイスの紐づく組織グループは一意のグループIDが必要
  2. UEMのすべてのテナントに、既定でひとつ作成され、木構造に沿って複数組織グループを作成可能
  3. 組織グループの設定は原則親から子へと継承される
    ※設定ごとに継承の要否を切り替え可能
    ※親子間の組織グループで設定に矛盾があった場合は原則子の設定が優先される
  4. デバイスは、所有者として紐づいたユーザの所属組織グループ以下であれば、移動可能
上記ひとつずつ図にすると、以下のようになります。

1.設定、デバイス、ユーザアカウントはすべて組織グループに紐づく
前回、「設定を区分けするためのグループ」と称した通り、Workspace ONE UEM(以下UEM)においては、設定が組織グループに紐づきます。そして設定以外にも、その設定を受け取る端末、その端末のユーザとして紐づけられるユーザアカウントも、すべて組織グループに紐づきます。
デバイスの紐づく組織グループは一意のグループIDが必要です。
デバイスはUEMの管理下に入るときにグループIDで、自身の設定をどの組織グループから取得すべきか識別しています。
2.UEMのすべてのテナントに、既定でひとつ作成され、木構造に沿って複数組織グループを作成可能
組織グループは、UEMの環境がVMware社から払い出されると、必ず既定でひとつ作成されます。
ただ、このままだとすべてのデバイスの設定が十把一絡げに一緒になってしまうため、木構造に沿って複数の組織グループを作成し、管理設定をそれぞれのグループで変化させることができます
組織グループを企業の部署にのっとって階層構造にした例。
ちなみに、既定で作成される組織グループのグループ名は申し込み企業様の英語名、グループIDは[企業の英語名の略称4文字程度+数字4桁]というパターンが多いですが、これらの値は後から管理コンソール上で変更可能です
また、組織グループはいつでも既存組織グループの子として作成可能です
3.組織グループの設定は原則親から子へと継承される
木構造で広がっていく組織グループにおいて、親となる組織グループで設定された内容は子となる組織グループにも継承されます
ただし、継承だけだと組織グループに分けている意味がないため、設定ごとに継承の要否を切り替え可能です
また、親子間の組織グループで設定に矛盾があった場合は原則、子の設定が優先されます
4.デバイスは、所有者として紐づいたユーザの所属組織グループ以下であれば、移動可能
最後にこれが最も便利な機能だと思うのですが、所有者として紐づいたユーザの所属組織グループの、子や孫の組織グループであれば、デバイスの所属組織グループを簡単に切り替えることが可能です。
これによりユーザの部署移動時のモバイル端末の設定変更が容易に行えたり本番環境の中に障害切り分け用の組織グループを作成し、端末ユーザの操作なしにモバイル端末の設定を切り替え可能です。

以上4つが、組織グループの主な仕様となります(細かいものはもうちょっとありますが。。。)。
今回は図の中の例として、企業の部署ごとに組織グループを分けていますが、そのほかにも設定の区分けとしては、時短勤務で働く人、パートタイムで働く人、利用する端末の種類など、さまざまな定義をもとに組織グループを作成することが可能です。
今回は少し座学っぽくなってしまいましたが、どのような定義で組織グループを分ける場合でも、上記の仕様を踏まえたうえで設計することによって、導入後の拡張や運用のしやすさがぐんと上がるので、組織グループの設計の際には今回ご紹介したことを踏まえてみていただけますと幸いです!

2019年2月11日月曜日

■Workspace ONE UEMで試してみた(5):組織グループってなんだ? - その1

前回の最後のほうで、つい「組織グループ」という言葉を使ってしまいました。
説明なしにこの言葉を使うと、ほとんどのお客様が「なんだろう?」という疑問を浮かべます。
ですが、Workspace ONE UEM(旧AirWatch)を使用するうえで、この言葉は避けて通れません。なので、私も私なりに解説しようと思います。

とはいえ、きっちりとした解説はVMware社員の方がリレー式に書いているJapan End-User Computing Blogでも行われているので、このブログでは飽くまで私なりの組織グループの理解を記載するのにとどまります(同じこと書いてもつまらないですし。。。)。
「マニュアルやいろんなブログを読んでみたけれど、なんかしっくりこないなぁ」という方のお役に立てれば幸いです。

組織グループとは何か。
私は、「設定を区分けするためのグループ」と考えています。

Workspace ONE UEMにはたくさんのデバイスが管理されることになります。
それらのデバイスは、iOS、Android、Windows 10など、様々な種類だったり、フルタイムで働く正社員さんが使う会社貸与デバイス、子育てなどで時短勤務の従業員さんが使うデバイス、またはアルバイトさんのBYODデバイスなどなど、様々な利用形態だったりするかもしれません。

それらのデバイスに対して、十把一絡げにまったく同じ設定を行うことは、果たして妥当でしょうか?

例えば、正社員さんが使う会社貸与デバイスは会社の資産だから、GPSの情報を定期的に収集し、紛失防止に努める必要があるかもしれませんが、アルバイトさんのBYODデバイスに同じ設定を入れてしまうと、プライバシー侵害の問題になってしまうかもしれません。

例えば、正社員向けに利用させたい発注管理アプリがあるとします。このアプリを十把一絡げにWorkspace ONE UEM管理下のデバイスに配信してしまうと、また、アルバイトさんのBYODデバイスに対して配信されてしまい、今度は会社の情報漏えいの危険さえあります。

上記2つは極端な例ですが、ほかにもいろんな例が考えられます。
そのため、デバイスによって設定を区分けすることはEMM製品を利用する上で必要な措置であるとお考えいただいたほうが無難です。

ひとまず組織グループの存在意義についてお話ししたので、次に組織グループは画面上どこに存在するのかを確認したいと思います。

組織グループを確認する最も確実な方法は、[グループと設定]>[グループ]>[組織グループ]>[詳細]の情報です。ここには組織グループ名、組織グループのID、タイプ、国、ロケール、利用している企業の業種、タイムゾーンの設定情報が表示されています。

組織グループの詳細画面。
各項目についての詳細な説明はいつか行いたいと思います。。。
また、画面上部のタブにマウスオーバーしても組織グループを確認することが可能です。
ここで表示される組織グループは、現在管理コンソールで開いている(設定をしている)組織グループです。

現在管理コンソールに開いている組織グループ。
次回以降は、組織グループの性質も含めて解説していきたいと思います。
 


2019年2月10日日曜日

■Workspace ONE UEMで試してみた(4):ログイン画面の変更

vYettiってご存知でしょうか。
いつだったかWeb系で話題になったイエティさんのログイン画面Angular版を使って、VMware社員のWilliam Lamさんがいい感じにvSphereのログイン画面をカスタムしたものです。
詳しいやり方はこちらに記載されています(そんなに難しくなさそうなのでいつか弊社検証環境にこっそりと仕掛けてみたい。。。)。
以下はvYettiのデモ動画です。



ところで、Web系のログイン画面といえば、Workspace ONE UEMのログイン画面ですよ(強引)。
こちらもカスタマイズ可能なんです!(オンプレミスに存在するvCenterほど自由にカスタムできるではありませんが。。汗)。

あまり日の目を見ることの少ない機能ではありますが、以下に手順を記載します。
まずは普通にUEMの管理画面にアクセスし、ログインします。

通常のログイン画面。シンプルで素敵ですが、
「自社のロゴに変えたい!」というかたもいらっしゃいます。
 ログイン後、[グループと設定]>[すべての設定]と進み、[システム]>[ブランディング]の順に進みます。

通常のログイン後の画面です。
画面左上にはVMware社のラボのロゴ(三角フラスコ)が見えます。

「ブランディング」画面です。先ほどのおしゃれな
三角フラスコマークはここで設定されています。
 早速、ログイン画面を編集してみましょう!

まずは[会社のロゴ]から。[アップロード]をクリックし、好きな画像を選択して[保存]します。

設定を[オーバーライド]に変えると、編集可能になります。
[アップロード]をクリックします。

ポップアップ表示でファイル選択ボタンが表示されます。
[参照]をクリックします。

ファイルを選んでアップロードしたら、
[保存]をクリックします。

画像が切り替わりました。
おしゃれなのが見つからなかったので
タヌキの写真にしています。。

同じ要領で、その下にある[ログインページの背景]も好きな画像に変更します。

同じようにアップロードをクリックし。。。

画像を追加しました。
イチゴ畑にしてみます。
次は[企業 Web サイトの URL]を変更します。
次に、[企業 Web サイトの URL]も好きな値に変更します。
このWebサイトは、[会社のロゴ]として設定した画像をクリックしたときに表示されるWebサイトです。

このブログのURLに変更しました。
これで、タヌキの写真をクリックするとこのブログが表示されます。

設定画面をスクロールダウンすると、操作画面の色合いを編集する画面が表示されます。
ここも編集してみましょう。

カラーコードの右横にある小さな色相環をクリックすると、
大きなパレットが表示されるので、好みの色を選択します。

選択した色の通りに右のプレビュー画面が変わったことを確認します。
選択した色に応じて、テキストの色も変更できます。
濃い目の紫を背景色にしたので、[明るい色]を選択します。

[ナビゲーション](画面左のペイン)と
[ハイライト](洗濯時の強調)も同じ要領で変更します。
変更したら画面底部の[保存]をクリックし、画面右上の
バツをクリックしてポップアップを閉じます。
設定画面を閉じると、すでに変更が反映されていることがわかります。

すでに設定が変更されています。
ちょっと見づらくて後悔する色味です。。。
ログイン画面が変わっていることを確認するため、
画面右上のログインユーザ名をクリックし、
[ログアウト]します。

管理コンソールからログアウトすると、先ほど設定したロゴと背景でカスタムされたログイン画面が表示されます。

変更後のログイン画面。
タヌキがイチゴ畑にぽつんといます。

ちなみにロゴとして設定した画像をクリックすると、[企業 Web サイトの URL]のページがちゃんと表示されます。


なお、この設定は組織グループ単位で変更することが可能なため、ご利用の環境が共有環境であったとしても問題なく実施することが可能です(同一ブラウザ内で最後にログアウトした組織グループの設定が次回以降のログイン時に適用されるようです)。

別のブラウザから表示したlabs.awmdm.comのログイン画面。
デフォルトのものがちゃんと表示されています。
 「長く使うものだからカスタマイズしたい!」というかたは、ぜひお試しください!