プロファイル,詳細設定,ルール

Just another POL Helpサイト site

2020年 3月 27日

1. ご無沙汰の端末を摘出

(図1)は、Android端末、Windows PC 及び Windows Embedded端末のアラートルールの設定の一部分です。 (図1)は、MobiControlサーバとの間で、360分間(=6時間)以上、オフラインであった端末をアラート対象として摘出する設定です。 アラートは、アラートログに記録し、更には、オプションで関係者に自動的にメール通報します。

(図1)

Android端末、Windows PC 及び Windows Embedded端末は、MobiControlサーバに常時接続しているのが、デフォルト設定です。 長時間、オフラインであることは、異常です。「バッテリが無くなった」「構内から持ち出されWiFi接続ができなくなった」「SIMカードが抜きとられた」 などが考えられます。直ちに、端末ユーザにコンタクトし、善処する必要があります。尚、(図1)の360(分間)という値は、任意に設定できます。
このアラートルールを、必ず、設定しておいてください


(図2)は、iOS端末のアラートルールの設定の一部分です。 (図2)は、MobiControlサーバへの前回のチェックインから、360分間(=6時間)、経ったのにかかわらず、チェックインしてこないiOS端末をアラート対象として摘出する設定です。 アラートは、アラートログに記録し、更には、オプションで関係者にメールを自動通報します。

(図2)

iOS端末は、MobiControlサーバに、2時間毎にチェックインするのが、デフォルト設定です。長時間、チェックインがないことは、異常です。 iOS端末(iPhone、iPad、macOSコンピュータ)を管理対象としている場合は、 このアラートルールを、必ず、設定しておいてください
上の2つのアラートのしきい値は、分単位で設定します。アラート文には、%HOURS%時間、%DAYS%日間、のマクロ文字列を 挿入しておきます。%HOURS%は、経過分数を60で除した値、%DAYS%日間では、経過分数を1440で除した値を表示します。

2. 頻繁なチェックインが、運用のキモ

端末やエンドポイントが、MobiControlサーバに頻繁にチェックインしていることが、管理上、重要です。
チェックインとは、端末側から、サーバに対し、待ち行列に溜まっているファイルやデータがないかを問い合わせをし、もしあれば、それらをダウンロードすることです。 ついでに、端末側からもサーバに、ファイルやデータを送ります。
コンソールで設定した「構成プロファイル」「詳細設定」「ルール」などのファイルや設定データは、端末からのチェックインがあったときに、 端末に展開されます。

(図3)
チェックインの時に、送受されるファイルやデータ

iOS端末に対しては、「パッケージを搭載したプロファイル」を送付することはできません。
「特定の端末に、どうしてもプロファイルが適用されない」
「アプリカタログルールを適用したのに、特定の端末にだけは、アプリがインストールされない」
等の問い合わせが あります。その原因の一つとして、「当該端末が、永らくチェックインをしていない」という事案が多々あります。おかしいときは、チェックインをしているかどうかを、まずは見てください。

Android端末、Windows PC 及び Windows Embedded端末が、チェックインをするためには、MobiControlサーバに接続していることが 前提です。 接続していないと、チェックインはできません。

3. 端末一覧のコラムに、「最後に切断した日時」や「最後のチェックイン」を掲げる

(図4)は、Android端末の一覧表示のサンプルです。端末の名前の右側に、「最後に切断した日時」の列を表示してあります。 「最後に切断した日時」とは、「端末がMobiControlサーバから、直近に、切断した時刻」です。
Android端末、Windows PC 及び Windows Embedded端末は、MobiControlサーバに、デフォルトでは、常時接続しています。 接続中の端末は、コンソールでは、と空色の アイコンで表示されます。これは、正常です。

(図4)
Android Enterpriseの端末だけの一覧

しかし、 とグレイの アイコンの端末は、切断中であることを示しています。この際、端末の名前の右に、「最後に切断した日時」を表示しておくと、切断してから永く時間経過している端末に気が付くことができます。 の端末などが、その例です。切断してからは、当然、チェックインはしてないことになります。

のコラムには、頻繁に参照する端末プロパティを選抜して掲げておくと よいでしょう。「最後に切断した日時」や「エージェントバージョン」などは、常に掲げておくことを、お勧めします。 端末一覧への端末プロパティの選抜掲示方法については、「中央ペインでの表示項目の変更」を参照ください。


(図5)は、iOS端末の一覧表示のサンプルです。端末の名前の右側に、「最後のチェックイン」の列を表示してあります。 「最後のチェックイン」とは、iOSにビルドインされているMDMプロトコルというプログラムが、MobiControlサーバにチェックインした時刻です。

(図5)
iOS端末だけの一覧

2時間間隔で、チェックインをするのがデフォルトです。従って、「最後のチェックイン」の時刻が、2時間より前であるiOS端末は、異常です。 の端末などが、その異常な例です。

「最後のチェックイン」を端末の名前の右横に掲げる方法については、「中央ペインでの表示項目の変更を参照ください。

iOS端末は、MobiControlサーバに、通常は、オフラインのままです。それでも、チェックインのトリガーが発動すると、チェックインを実行します。 その時も、アイコンのカラーは、グレイのままです。

iOS端末での「接続」と「チェックイン」の関係は、Android端末やWindows系デバイスなどと、異なります。後述します。

4. Android端末、Windowsは、どのようなトリガーで、MobiControlサーバに接続するか

Android端末、Windows PC 及び Windows Embedded端末は、次の4つのどれかのトリガーで、MobiControlサーバに接続に行きます。 (但し、c.項は、Android端末だけで実施できます。)
接続とは、httpsセッションを開始し、それを維持することです。MobiControlサーバ側から端末に対し、接続に行くことはありません。 接続しただけでは、(図3)で図示したデータやファイルの送受を、基本的には実行しません。これらの送受は、チェックインの時に実行します。
  1. 端末に電源を入れた。OSを再起動した。
    MobiControlエージェントが、バックグラウンドで起動し、MobiControlサーバに接続します。
  2. 接続時間帯で設定した 接続開始時刻になった。
  3. Googleプッシュ通信サービス経由で、コンソールから端末へ、"connect -f"のスクリプトを送付。
    設定を今すぐ更新する。オンラインにする」の(図4)を参照ください。
  4. 端末ユーザが、マニュアルで接続。
    をタップして、端末のステータスを開くと(図6)が 現れます。
    (図6)の「エージェントステータス」赤矢印部分を長押しします。(図7)のように変ります。 「未接続」が「接続済」に変わりました。これで端末はMobiControlサーバに接続しました。
    (図6)(図7)

バッテリ節約のために、接続時間帯を設定し、それ以外の時間帯では MobiControlサーバと接続させないこともできます。その接続時間帯以外の時間帯でも、 上記の c.項、又は、 d.項 を実行すると、端末はMobiControlサーバに接続します。

接続時間帯の時間なら、Android端末、Windows PC 及び Windows Embedded端末は、常時接続しているのが仕様です。しかし、一部のAndroid端末では、 接続時間帯にもかからず、オフになる場合があります。「常にサーバとの接続を維持」を参照して、常時接続を維持してください。

5. Android端末、Windowsは、どのようなトリガーで、MobiControlサーバにチェックインするか

(図3)のような送受は、端末側からのチェックインがあったときに実行されます。MobiControlサーバ側からチェックインをすることはありません。 但し、MobiControlサーバ(コンソール)は、端末にチェックインをするように、要求することはできます。
Android端末、Windows PC 及び Windows Embedded端末では、MobiControlサーバに接続していない時は、チェックインは実行されません
接続していることを前提に、 端末は、次のいずれのかのトリガーで、チェックインを行います。
  1. 端末が保存している更新スケジュール(図11)の時刻になった

    (図8)

  2. MobiControlサーバ側が、端末にチェックインすることを要求した。次の場合に要求をします。
    • b-1. 構成プロファイルの割り当てを行った
    • b-2. 端末詳細設定を設定した
    • b-3. コンソールで、「端末にチェックインを要求」を選択した
    (図9)
    端末グループ単位でチェックインを要求
    (図10)
    端末単位でチェックインを要求
    「ルール」を設定しただけでは、サーバは、端末にチェックインの要求をしません。ルールを今すぐ展開したい場合は、b-3.項を実施する必要があります。
  3. 端末が、MobiControlサーバに接続した瞬間
    但し、(図11)の「更新スケジュールの設定」で、「端末が接続した時に常に更新」にチェック(赤矢印)を入れておくことが前提です。 チェックをいれておかないと、接続をしても、その時点ではチェックインをしません。

    (図11)更新スケジュールの設定

尚、ファイル同期ルールによるファイルの送受タイミングには、上述の「チェックイン」の際に同時に行う場合と、「ファイル同期ルール独自のスケジュール」の時刻に送受をする場合の 2つの選択肢があります。

Windows Modernとして設定したPCに対しての、上記 b.項のチェックイン要求は、WNS(Windows Notification Service)経由で行われます。

(図12)

WNSを設定していない場合は、Windows Modern に対しては、b.項を実施できません。その場合は、a.項 又は c.項のトリガーでのチェックインまで待つことになります。 詳しくは、「WNSから認証を得る」を参照ください。

6. iOS端末は、どのようなトリガーで、MobiControlサーバにチェックインするか

iPhoneやiPad が、MobiControlサーバにチェックインをする端末側の主体プログラムは、 MobiControlエージェントでなく、MDMプロトコルです。MDMプロトコルは、iOS端末のOSにビルドインされているプログラムです。 MobiControlサーバは、APNs(Apple Push Notification service)経由で、端末のMDMプロトコルに、チェックインを要求します。

(図13)

APNs経由で「チェックイン要求」を受信した端末は、たとえスリープ中でも、MobiControlサーバにチェックインをします。
端末(MDMプロトコル)は、チェックインの時だけ、httpsセッションを確立し、 チェックインに伴う送受が終われば、httpsセッションを切断します。
MobiControlサーバは、次のいずれかのトリガーで、APNs経由で、端末にチェックインを要求します。
  1. 更新スケジュールの時刻
    Android端末、Windows PC 及び Windows Embedded端末では、更新スケジュールを内蔵していて、その時刻になれば、端末側からチェックインしますが、iOS端末では、更新スケジュールを内蔵していません。 その替わり、MobiControlサーバが更新スケジュールを内蔵していて、時刻になれば、チェックイン要求をAPNs経由で、端末に送ります。
  2. コンソールで、「端末にチェックインを要求」を選択した (図9)と(図10)を参照。
  3. コンソールで、端末への働きかけ項目を選択した
  4. 構成プロファイルの「割り当て」を行った
  5. 端末詳細設定を設定した。
「ルール」を設定しただけでは、サーバは、端末にチェックインの要求をしません。ルールを今すぐ展開したい場合は、 b項を実施する必要があります。

iOS端末のチェックインの特長は、MobiControlエージェントによるサーバへの接続がなくても、又、MobiControlエージェントが起動していなくても、 実行できることです。更には、MobiControlエージェントがインストールされてなくても、チェックインができます。エージェントレス運用です。

7. iOS端末に、MobiControlエージェントをインストールする

前述したように、iOS端末は、MobiControlエージェントがなくても、MDMプロトコルがチェックインを行います。
しかし、MDMプロトコルのチェックインでは、サーバは、次のような端末側情報を取得できません。 これらの情報は、MobiControlエージェントがサーバに接続することで、取得できます。
  1. リモート端末の画面表示
    iPhone及びiPadの画面をコンソールに表示します。端末ユーザの操作に従い、コンソールでの画面も変化します。 SDK for iOSを組み込んだアプリを起動したときのみに利用できます。 SDK for iOSを組み込んでないアプリの画面のリモート表示をするには、サーバのバージョンをv14.2以上に アップグレードする必要があります。
  2. 端末の地理的位置情報
    iOS 端末の位置表示」を参照ください。端末がオンラインならば、その 位置をコンソールに地図表示します。但し、端末がオフラインであっても、端末の地理的位置の履歴は 端末内で記録され続けています。端末がオンラインになれば、その履歴もサーバに送られ、今までの移動経路を、コンソールに表示できます。 サーバで一度取得できた「過去の移動経路」は、端末がオフラインでも地図表示できます。
  3. 次のような端末ステータス情報
    • IPアドレス
    • バッテリ空き容量
    • 総メモリと書込可能なメモリ容量
    • 脱獄(JailBreak)しているかどうか
  4. 通信費管理ルールに基づく使用データ量

詳しくは、「iOS: チェックインと接続」を参照ください。
アプリカタログに、MobiControlエージェントを加えておくと、MobiControlエージェントが、端末にインストールされます。

MobiControlエージェントによる接続は、端末ユーザの操作が必要です。次のいずれかを実行して貰います。
    端末で、
  • をタップ して、MobiControlエージェントを起動する。
  • コンソールからメッセージを送信。端末画面にポップアップ表示されるメッセージを開くと、MobiControlエージェントが起動します。
  • SDK for iOSを組み込んだアプリを起動する

8. 配布対象の端末グループ

8-1 階層構造の端末グループに対応

MobiControlの端末グループは、会社/団体の組織を反映して、階層構造で作成します。
そして、「構成プロファイル」、「パッケージを搭載したプロファイル」、「詳細設定」 又は「ルール」のどれでも、 上位の端末グループに割り当てることも、下位の端末グループに割り当てられることも可能です。
例えば、本部内の全ての端末の設定値を共通にしたい場合は、本部単位で設定します。
課単位で設定したい項目があれば、課単位で設定します。
(図14)

8-2. 「構成プロファイル」と「ルール」なら、その複数を、1つの端末グループに割当てが可能

例えば、本部という名前の端末グループに、構成プロファイルAを割り当てたとします。 そうすると、その本部の傘下の「第1部」と「第2部」にも、当該構成プロファイルが 割り当てられます。
更に、「第1部」だけに、「構成プロファイルB」を割り当てたとします。 そうすると、「第1部」には、「構成プロファイルA」と「構成プロファイルB」が共存して 端末の挙動を規定します。
これは、「ルール」の場合も、同じです。一つの端末グループに複数のルールが共存できます。
(図15)
例えば、2つのアプリカタログ・ルールが適用されると、端末の アプリカタログには、両方のアプリ群が表示されます。
「ルール」は、仮想端末グループにも適用できます。しかし、 「構成プロファイル」は、仮想端末グループにも適用できません

8-3. 「詳細設定」は、1つの端末グループの1つの端末ファミリに対して、1つしか設定できない

「詳細設定」の場合も、上位の端末グループ単位で設定すれば、下位の端末グループの端末に、 自動的に反映されます。
しかし、下位の端末グループ単位で、設定すると、上位で設定した詳細設定の値は、上書きされます。(図16)での 「詳細設定A」は「詳細設定B」で上書きされます。共存はできません。
(図16)
1つの端末ファミリに対し、1つしか「詳細設定」は設定できません。「詳細設定」は、仮想端末グループにも適用できます。

9. 認証サービスによる認証

オプションとして、端末の登録時に、認証サービスによる認証を経るようにすることができます。 認証サービスには、ディレクトリサービスと、SAML2.0仕様のIDプロバイダがあります。 これらに対応するMobiControl機能との関係を、次表に示します。

ディレクトリサービスIDプロバイダ
(Azure IdP、Okta、OneLoginなど)
オンプレミスAzure AD
iPhone、iPad、Android、macOS
  • 端末登録時の認証
  • 端末の共用 注1
  • 構成プロファイルへの埋め込み 注2
Windows Modern

端末登録時の認証
構成プロファイルへの埋め込み 注2
セルフサービスポータル
コンソールへのログイン認証
  • 注1 端末の共用
    1台の端末を、異なる部門のユーザ間で共用する機能。認証サービスによる認証を得ることで、端末ユーザを変えることができる。端末ユーザが変わると、 端末の設定やアプリなどを、自動切換えできる。
  • 注2 構成プロファイルへの埋め込み
    メール、WiFi、VPNなどの構成プロファイルに端末ユーザのUPNやメールアドレスを自動的に埋め込んでから、端末に配布する機能。端末ユーザが、これらの設定操作をする必要がなくなる。

9-1. 認証サービスに認証させるメリット

  1. Exchangeメールアカウントの自動設定
    MobiControlに登録すると、すぐにExchangeメールの送受が可能になります。メールサーバに対するパスワード入力も不要です。
    メール、WiFi、VPNに関する構成プロファイルには、端末ユーザのAD_DSに対するパスワードを付して端末に配布し展開します。
    但し、MobiControlサーバが、そのパスワードを保存しているのは、端末登録後10分間だけです。 端末がMobiControlに登録する前に、構成プロファイルを、端末グループに割り当てておくことが望まれます。
  2. WiFiやVPNへの自動接続
    AD_DSによる認証を経て利用できるWiFiやVPNがあります。MobiControlに登録すると、端末ユーザは認証操作なくして、 これを利用できます。
    もし、WiFiやVPNが、IDプロバイダによるSAML認証に対応しておれば、SSOが働いて、ユーザの認証作業なくして、利用開始できます。
  3. 端末の共用
    会社支給端末を全従業員に配布できない場合に利用します。端末は、端末グループが異なると、インストールする業務アプリや 構成プロファイルが異なります。
    共用端末では、認証サービスによる認証を経て、各々の従業員の所属する端末グループ毎の 業務アプリや構成プロファイルで端末を利用できます。
  4. コンソールの端末一覧にユーザ名を表示
    コンソールの端末一覧には、端末毎の端末プロパティを表示できます。その端末プロパティの1つとして、 認証サービスでのユーザ名を表示できます。端末一覧への端末プロパティの選抜掲示方法については、「中央ペインでの表示項目の変更」を参照ください。
  5. 端末ユーザは、セルフサービスポータルにアクセスできます。
    端末を紛失した場合などに、端末ユーザは、PC、タブレット、スマホで、特定のURLにアクセスすると、 紛失した端末の地理的位置を地図表示できます。紛失した端末がロック状態でも、拾得者に読んでもらう メッセージを表示します。iOS端末の場合は、連絡してもらう電話番号への電話リンクも表示します。最悪の場合はリモートWipeができます
    コンソール管理者が出勤していない夜間や休日に有用です
  6. MobiControlコンソールへのアクセス認証
    MobiControlコンソールにアクセスする際に、認証サービスによる認証を要求することができます。認証サービスに依っては2段階認証を 要求する機能もあります。これを利用すると、Mobicontrolコンソールへのアクセスにも2段階認証を適用できます。
  7. iOS端末は、下記をダウンロードができます。
    • CardDAVサーバから、電話番号帳を
    • CalDAVサーバから、社内の同僚、上司のスケジュールを

9-2. 構成プロファイルは、認証サービスのユーザグループを割当て対象にできる

構成プロファイルは、端末単位や端末グループ単位で、割り当てることができますが、認証サービスのユーザグループにも割り当てることが できます。
1つのユーザグループに、MobiControlの複数の端末グループをマッピング(紐づけ)させておくことができます。 その場合、1つのユーザグループに、割り当てられた構成プロファイルは、マッピングしてある全ての(MobiControlの)端末グループの端末に、 配布され、展開されます。

(図17)
「認証サービスのユーザーグループ」に割り当て

10. 「構成プロファイル」と「詳細設定」は、端末の定常的な挙動規定

「構成プロファイル」と「詳細設定」は、コンソールのダイアログに入力や選択をすることで、MobiControlサーバ内に 作成されます。
例えば、端末はSSIDに対応するパスワードを要求されたら、構成プロファイルの設定値を参照して送ります。

(図18) 
構成プロファイルの展開

11. 「ルール」は、端末とサーバの両方の挙動を規定

(図19)
端末のMobiControlサーバへの登録、アプリの配布、ファイルの同期、アラートの検知など、端末からのアクションに対し、サーバ側が対応する仕組みがルールです。
幾つかのルールがあり、これを作成し、端末に展開します。

12. 非定常的な働きかけ

「プロファイル」、「詳細設定」及び 「ルール」は、端末の定常的な挙動を設定します。 これら以外に、コンソール管理者は、非定常的に端末に働きかけることができます。 「端末画面をリモート操作する」、「端末にロックをかける」「端末を紛失モードにする」「Wipe(初期化)する」などです。
コンソールでの「働きかけ」操作には2種類があります。
  1. アクション項目(又はアクションアイコン)を選択
  2. スクリプトコマンドを送信
a.の操作は、全ての端末OSに対し実施できます。
b.の操作は、Android、Windows Classic、Windows Embedded、Linux 宛のみに適用できます。
a.の操作に比べると、b.のスクリプトコマンドの送信は、 より多彩な働きかけができます。