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

Just another POL Helpサイト site


1. 端末の定常的な挙動を設定

エンドポイントの端末やPCの定常的な挙動を設定するために、「構成プロファイル」、「パッケージを搭載したプロファイル」、「詳細設定」 及び「ルール」を作成して端末に送ります。

(図1)

  • パッケージにはアプリのインストーラファイルとスクリプトコマンドが内包され、 これを受信した端末はアプリをサイレント・インストールします。パッケージは、MobiControl Studioで作成されます。
    iOS端末宛には、「パッケージを搭載したプロファイル」を配布することはできません。替わりにアプリカタログでアプリを配布します。
  • 端末に対する非定常的な働きかけは、コンソールでアクション項目を選択したり、スクリプトコマンドを送信して実施します。 リモートWipeやリモート画面操作などが非定常的な働きかけです。

2. 配布のタイミング

  • 「構成プロファイル」と「パッケージを搭載したプロファイル」は、
    配布対象となる「端末」、「端末グループ」又は「AD(Active Directory)のグループ」を、コンソールで 指定(割り当て)したら、すぐに端末に送られ展開されます。但し、端末に展開するスケジュール日時を指定することで展開を遅らせることもできます。
  • 「詳細設定」と「ルール」は、
    端末からMobiControlサーバへのチェックイン(更新)の際に、端末に送られ展開されます。
    チェックインとは、サーバ側の待ち行列に溜まっているファイルやデータがあるかないかを端末側から問い合わせ、あればそれを受信することです。同時に端末側にも サーバに対し送るべきファイルやデータがあれば、それを送ります。
    チェックインは、「スケジュール」の時刻、又はコンソールでのチェックイン要求操作に基づき実施されます。

3. チェックインの仕組み

3-1. iOS以外の端末OSの場合

(図2)

iOS端末以外の端末は、チェックインのスケジュール表を内蔵し、チェックインの時刻になればサーバに対し、チェックインをします。 iOS端末以外の端末では、必ず、MobiControlエージェントという常駐ソフトがバックグラウンドで作動し続け、常にMobiControlサーバとの接続を 維持しています。端末がスリープ状態の時でも接続を維持します。
このエージェントがスケジュール表を内蔵しています。
このスケジュールの間隔はデフォルトで2時間ですが、「詳細設定」の「更新スケジュールの設定」にて、これを変更することができます。
  • スケジュールの時刻とは別に、コンソール管理者は、いつでも端末にチェックインを要求することができます。 「詳細設定」や「ルール」を今すぐ端末に反映したいときは、コンソール管理者側からチェックインを要求します。 いつでもサーバ側からチェックイン要求を送れるのは、端末とサーバ間が常時接続しているからです。
  • 「構成プロファイル」と「パッケージを搭載したプロファイル」は、その対象となる「端末」、「端末グループ」又は「ADのグループ」をコンソールで指定すれば、 MobiControlサーバが自動的にチェックイン要求を端末(群)に送ります。そのチェックインを受けて自動的に展開されます。

3-2. 端末OSが、iOSの場合

(図3)

iOS端末にMobiControlエージェントをインストールすることは、推奨されますが、必須ではありません。 替わりに、MDMプロトコルというメカニズムがOSに組み込まれていて、これがMobiControlサーバとのチェックインの主役となります。 MDMプロトコルはApple社の開発物です。MDMプロトコルは端末がスリープ中でも作動し続けています。
iOS端末の場合、端末とMobiControlサーバとは常時接続をしていません
チェックインのスケジュール表は、MobiControlサーバが保持しています。
チェックインの時刻になれば、MobiControlサーバは、APNs(Apple Push Notification service)経由で、端末に、チェックインすることを 要求します。APNsは、Appleが提供するプッシュ通信サービスです。MobiControlにとってAPNsの使用目的は、端末にチェックインを要求するだけです。 APNs経由で、Wipeなどのコマンドやメッセージを送ることはしません。
APNS経由でチェックイン要求を受信した端末は、MobiControlサーバにチェックインをします。
  • 「構成プロファイル」の配布対象となる「端末」、「端末グループ」又は「ADのグループ」をコンソールで指定すれば、 MobiControlサーバは自動的に、APNs経由でチェックイン要求を端末(群)に送ります。
  • 「詳細設定」や「ルール」を設定しても、すぐには、端末には反映されません。 チェックインのスケジュール表で、次のスケジュール時刻まで待ち、その時刻になったらMobiControlサーバはAPNs経由でチェックイン要求を端末(群)に送ります。
  • スケジュールの時刻とは別に、コンソール管理者は、いつでも端末にチェックインを要求することができます。 「詳細設定」や「ルール」を今すぐ端末に反映したいときには、コンソール管理者はAPNs経由でチェックインを要求します。
  • このスケジュールの間隔はデフォルトで2時間ですが、「詳細設定」の「更新スケジュールの設定」にて、これを変更することができます。
  • iOS端末では、チェックインに伴いファイルやデータの送受が終わると、 端末とMobiControlサーバとの間の接続は切断されます。
  • iOS端末をインターネットから隔離した閉域ネットワークで運用する場合でも、ポート5223だけは開けておく必要があります。 ポート5223以外に、初期設定の時にアクセスするAppleアクティベーションサーバとのポートも必要です。
iOS端末では、APNsとの通信ポートを確保しておくことは、必須です。「プロファイル」「詳細設定」及び「ルール」の展開だけでなく、 非定常的な働きかけも、
「APNs経由でのチェックイン要求」 -->「端末からのチェックイン」 -->「働きかけコマンドの端末への送付」
の順で実施されるからです。
iOS端末では、MobiControlのエージェントソフトは必須ではありませんが、インストールすることが推奨されます。 端末のリモート・ビューができたり、端末のIPアドレスなど追加的なステータス情報を収集できます。 詳しくは、「iOS: チェックインと接続」を参照ください。 iOS端末のエージェントは、端末ユーザの操作でのみ起動します。常に作動し続けることはありません。

3-3. Googleのプッシュ通信サービス

Android端末でのGoogleプッシュ通信サービスは、必須ではありません。なぜなら、Androidのエージェントは、MobiControlサーバとの接続を常時維持しているからです。 従って、いつでも、MobiControlサーバ側からチェックインを要求できます。

(図4)

常時接続をせず、スケジュールを設定し接続時間帯を制限することもできます。例えば夜間や週末は接続を停止しておくことができます。バッテリ節約が目的です。 接続を停止している時間帯には、チェックインができません。しかし、非接続時間帯でも、Googleのプッシュ通信サービス経由で、Android端末に 接続を要求するコマンドを送ることができます。そして、チェックインを実行し、「プロファイル」「詳細設定」及び「ルール」の展開ができます。 リモートWipeのような非定常的な働きかけも可能になります。 詳しくは、「設定を今すぐ更新する。オンラインにする。」を参照ください。

3-4. 閉域ネットワークでのAndroid端末

Android端末で、 接続時間帯を設定せず常時接続(デフォルト)の場合、Googleプッシュ通信サービスは、原則的に使いません。
結果として、Android端末は、閉域ネットワークでの運用が可能になります。閉域ネットワークとはインターネットから隔離されたネットワークです。閉域ネットワークの端末とは、 携帯電話会社が提供する閉域SIMカードを搭載した端末や、構内WiFiにしか接続できないようにした端末です。この場合、業務アプリは、 「パッケージを搭載したプロファイル」をMobiControlサーバから端末に直接配布することで、サイレント・インストールされます。
  • 完全閉域ネットワークでは、ウィルス検疫サービスが受けられません。ウィルスパターンの更新受信ができないからです。 これを可能にするには、SOTIのウィルスパターン送信サーバのURLへのアクセスを可能にしておきます。
    • https://mobicontrolservices.soti.net/BitDefenderAntivirus 
      (メインサーバ)
    • https://mobicontrolservices.soti.net/BDM/ 
      (ミラーサーバ)
  • Android Enterprise Device Owner Modeとして端末を設定する場合は、初期設定が終わるまで 端末を、GoogleにアクセスできるWiFi環境に置いておく必要があります。

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

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

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

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

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

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

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

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

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

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

6-3. 「詳細設定」は、1つの端末グループに対しては、1つしか割当てられない

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

7. 非定常的な働きかけ

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

8. Active Directory

8-1. AD_DS認証をして、端末をMobiControlに登録するメリット

端末をMobiControlに登録する際に、AD_DS認証を強制するように、端末登録ルールを作成することができます。 AD_DS認証をすると、MobiControlサーバは、UPNなどの端末ユーザのAD_DS属性を把握できます。 AD_DS属性をMobicontrolが把握できることで、端末に対する管理領域を拡げることができます。
以下、AD_DS認証をしての端末登録のメリットを列挙します。
  1. コンソールでの端末一覧画面に、端末の属性情報の一つとして、ユーザ名を表示できるようになる。
  2. マクロ文字列の%ENROLLEDUSER_UPN% が使える。
    MobiControlでは、マクロ文字列というものを多く用意しています。
    そのうちの一つに、%ENROLLEDUSER_UPN% があります。登録した端末ユーザのAD_DSのUPNの代替となる文字列です。 構成プロファイルやルールの中に、この%ENROLLEDUSER_UPN% を入力することができます。 そうすると、MobiConrolサーバは、端末毎のUPNに文字変換してから 構成プロファイルを配布したり、ルールを展開します。こうすることで、構成プロファイルやルールを 個別端末毎の作成ではなく、グループ単位で作成できるようになります。 %ENROLLEDUSER_UPN% を使える構成プロファイルとして、次があります。
    • メールアカウントに対する構成プロファイル
    • AD_DS認証を要求するVPNアカウントの構成プロファイル
    • AD_DS認証を要求するWiFiの資格条件の構成プロファイル
      (多くのWiFi APを設置する構内でのWiFi展開に便利)
    • AD_DSから社内電話番号帳を端末にダウンロード(iOS端末のみ)
    • CardDAVサーバから、電話番号帳をダウンロード(iOS端末のみ)
    • CalDAVサーバから、社内の同僚、上司のスケジュールのダウンロード(iOS端末のみ)

    (図10)は、VPNの構成プロファイルの作成ダイアログの一部分。
    VPNサーバへのログインするためのユーザ名として %ENROLLEDUSER_UPN% を入力している。

    (図10)

  3. マクロ文字列の%ENROLLEDUSER_Username% が使える
    コンソールに表示する端末の名前の文字列の一部に、ユーザの名前を挿入できるようになります。
  4. AD_DSのグループを対象にした構成プロファイルの配布が可能
    下記の「8-2. 構成プロファイルは、ADのグループを割当て対象にできる」を参照ください。
  5. セルフサービスポータルが使える
    端末ユーザが、 管理対象の端末以外の、PC、タブレット、スマホで、自らの管理対象端末のステータスを視ることができる ようになります。 端末ユーザご自身で、紛失した端末の地理的位置を表示し、 端末をロックしたり、WIPE(初期化)ができます。
  6. 各部門の管理者が、MobiControlコンソールにアクセスできる。
    MobiControlコンソールへのアクセス権限の認証に、AD_DSを使うことができます。 これにより、各部門の管理者は、自らのPCにコンソール画面を表示できます。 各部門の管理者は、部下の端末にメッセージを一斉に送ったり、部下の端末の地理的位置をPCに表示できるようになります。 この場合、管理できる端末グループを、当該管理者の管掌部門に限定できます。
AD_DSサーバはイントラネット内部にあるのに、MobiControlサーバがインターネット空間にある場合、AD_DSによる認証が 困難な場合があります。
この場合は、AD_FSサーバ(Active Directory Federation Serviceサーバ)を媒介することになります。 詳しくは、「AD FSとの接続プロファイルの作成」を参照ください。
  • AD_DS、又はAD_FSによる認証が可能な端末OSは、 iOS、Android、及びWindows Modernです。
  • Android端末を、managed Google アカウントによるAndroid Enterprise Device Owner Modeとして設定する場合は、 AD_DS、又はAD_FSのどれかによる認証が必須です。
    (managed Google Play アカウントの場合は、ADによる認証は必須ではありません)
  • Windows Modernの登録の際は、AD_DS、又はAD_FSのどれかによる認証が必須です。
  • Windows Classic及びWindows Embeddedの登録の場合は、AD_DS、及びAD_FSのどの認証もできません。

8-2. 構成プロファイルは、ADのグループを割当て対象にできる

構成プロファイルは、端末グループに割り当てができますが、AD_DS(Active Directory Domain Service)のグループにも割り当てることができます。
その場合、端末登録ルールの作成で、AD_DSのグループをマッピングします。
(図11)で、「端末登録ルール(A)」の登録先となる端末グループを「端末グループ(a)」とします。
(図11)
ADのグループを端末登録ルールにマッピング
この「端末登録ルール(A)」と「端末登録ルール(B)」に、ADのグループマッピングしておきます。
そして、「構成プロファイル(X)」を「端末グループ(a)」に、「構成プロファイル(Y)」を 「ADのグループ)」に割り当てたとします。
そうすると、「端末グループ(a)」に登録された端末には、「構成プロファイル(X)」と「構成プロファイル(Y)」が適用されます。 一方、「端末グループ(b)」に登録された端末には、「構成プロファイル(Y)」のみしか適用されません。
「ADのグループ」のメンバーである 従業員の端末でも、「ADのグループ」がマッピングされてない 端末グループに登録した端末には、構成プロファイル(Y)は適用されません。
「ADのグループ」がマッピングされてない 端末グループとは、端末グループ(a)と端末グループ(b)以外の端末グループを指します。

下表のように、今、4種類の端末登録ルールを作成したとします。 AD_DSのグループにマッピングする場合としない場合を、下表を例として説明します。
端末登録ルール
の名前
登録先となる
端末グループの名前
マッピングしたAD_DSの
グループ名
適用される構成プロファイル
a大阪営業課A大阪営業課OSAKA 「大阪営業課」端末グループと「Osaka」AD_DSグループに割り当てられた構成プロファイルの両方
b大阪営業課Bマッピングをしない 「大阪営業課」端末グループに割り当てられた構成プロファイルのみ
c大阪購買課A大阪購買課OSAKA 「大阪購買課」端末グループと「Osaka」AD_DSグループに割り当てられた構成プロファイルの両方
d大阪購買課Bマッピングをしない 「大阪購買課」端末グループに割り当てられた構成プロファイルのみ
AD_DSグループの「OSAKA」に割り当てられた構成プロファイルは、a.とc.の両方に適用されることに、ご注目ください。(図12)は、上の表を反映しています。 ここでの「マッピング」の意味をご理解ください。

(図12)

AD_DSのグループをマッピングできるのは、Apple製品とAndroid端末の端末登録ルールだけです
AD_DSのグループをマッピングする端末登録ルールでの端末認証手段は、AD_DSまたはAD_FS(Active Directory Federation Service) とすることが必須です。
AD_DSのグループをマッピングしない端末登録ルールでの 認証手段の選択肢の一つとして、 AD_DSまたはAD_FS(Active Directory Federation Service)を選択することもできます。 AD_DS または AD_FS による認証に関連して、端末登録ルールの作成オプションは、次の5択になります
AD_DS または AD_FSによる認証
AD_DS認証 AD_FS認証両方共しない
ADのグループを
マッピング
する
しない