(8) その他のサーバ側設定
管理コンソールの「管理」タブの中をざっとレビューしていきましょう
「更新サービス」
これはSCCM2012にはなかった機能ですね。MDMやらByoD やら、今時のデバイス管理ができる項目のようです。今のところうちの検証環境ではmanaged な PCデバイスだけがクライアントになる予定なので、ざくっと理解でいいのかな。
「階層の構成」
はい、必須設定項目です。
SCCM サイトマスターのコンピュータアカウントでADを舐める権限は与えたはずなので、コンピュータアカウントのAD探索を有効にします。
どのツリー以下を対象とするか（再帰にしないようにもできる）GUIで選択可能。でも検証環境だとコンピュータオブジェクトを移動させるのをよく忘れます…。
あ、一応別コンテキストも指定できるのね…。まあそこまでしなくてよいと思いますが。
差分探索ができるのはすごいですが、それでもフル探索７日間隔は空きすぎなので１日に設定。
このオプションは設定しませんでしたが、2003以後のAD機能レベルだとそんなことできるんですね。
で、設定したらすぐに完全探索を実行しておきましょう。
職場の本番機ではユーザ探索も有効にはしていますが、まったく使ったことがありません。
・境界
インストール直後は真っ白です。
よくこの状態で（後で出てきますが）前にインストールしたクライアントが管理対象になったものだと…。少なくともSCCM2012では境界情報がないと絶対に管理対象とはみなされませんでした。
まあ、いいや。とっとと設定しましょう。
AD探索するのでADのサイト情報が必要ですが、SMS2003のころは必須だったIPサブネットは不要のようです。（SCCM2012サーバにもADサイト情報のみ登録されています）
そりゃMDMしたいんだったら書きようがないですもんね。
rodcsite にはSCCMクライアントを置く予定はないので、Default-First-site を追加します。
サイトシステムには自分自身もまだ登録されていませんが、それはまた後で。
で次はサイト境界グループです。
あれ？前のサーバ（このサーバ以前にテストしていたSCCM CB）の残骸が残っている…。そうか、それでクライアントを認識したのか。なお通常はサイト境界を作っても勝手にはサイト境界グループには属さないことと、デフォルトのグループには追加がまともにできないため、手で境界グループを作成する必要があります。
まずこのサイトに自サーバを追加します。
SCCM2012と比べると、サーバの接続が高速かどうかという訳のわからんオプションが廃止になったようです。
もう１つ変更点。こんな画面が追加されました。どこにフォールバックするのか指定しなくても大丈夫なんですかね？
・Exchangeコネクタ
何ができるんでしょうね。私は Exchange サーバの管理をやったことがないのでさっぱりわかりません。
Active Directory フォレストはインストール時に設定された情報でOK。
クラウドサービス
SCCM2012 も SPを適用することにより追加された項目。SCCM CB はさらに項目が増えています。
サイトの構成
サイトのプロパティで。「署名および暗号化」のオプションはSCCM2012でも外しているのでここでも外しておきます。
コンポーネントのプロパティをチェックします。
サイトシステムのプロパティにプロキシを指定する欄があります。プロキシが必要な場合は指定することになりますが、私の検証環境では不要です。
おっと。FSP が入っていないですね。
端末側がSCCMのサーバに接続しようとして失敗した場合のセカンダリ問い合わせ先といった位置づけなので、本来はサイトサーバ以外にサーバを立てるのが好ましいのですが、聞いたところによると「サイトサーバと同じであってもFSPがあると実質リトライのような動きをするので、設定しておくのがおすすめ」とのこと。
接続パラメータはとりあえずデフォルトのままにしておきます。
はいおわり。
では引き続き、コンポーネントの設定なんだけど、サイトのところから表示するメニューを確認。# 何で２つに分かれているのかと小一時間（ry
ソフトウェア配布についてはリトライ関係のパラメータばっかり。いやまあ、大事ではありますが。
次はソフトウェアの更新ポイント。これ重要。でも長くなるので別項目にします。
管理ポイントのコンポーネント
AD publish ってこれですね。
これはSCCM2012にはなかった画面。とりあえず空白のまま。
ステータスレポートはデフォルトのままにしておきます。
どうやら Exchange 必須とか SMTP Auth 必須とか言われないみたいですね。何が飛び出るかまでは未確認です。
間隔はデフォルトのままにしています。
「セキュリティ」の「管理ユーザー」
当然ながらエンタープライズなソフトなので権限が存在するわけですが、筆者は一つ大きな過ちをやらかしてひどい目に遭いました。
インストールしたドメインユーザがデフォルトの全知全能管理者ユーザになるわけですが、そのユーザから別のユーザを「完全な権限を持つ管理者」に指定しただけでは、その追加した人は全権を掌握できません。
公式ドキュメントはこちら。ぜひ熟読いただきたいのですが、「セキュリティロール」と「セキュリティスコープ」という２つの要素があり、「セキュリティロール」が「完全な権限を持つ管理者」であっても「セキュリティスコープ」が「既定」だとできないことがあります（例えば、クライアントの自動更新設定で実稼働環境への昇格など）。
そして、セキュリティスコープが「既定」の管理者は、自分のスコープをフルに変更することもできません。
↑完全な管理者が自分の「既定」のスコープを消して、スコープを追加しなおそうとしているが「既定」しか出てこない。
そもそも新規に管理者を追加する時のデフォルトのスコープは「既定」です。
すでにスコープをフルで持っている管理者が操作すれば他のユーザのスコープをフルに変更することができます。
たとえ検証用サーバであっても、管理者ユーザIDが１つしかないと、うっかりそのIDを消した日には詰みになってどうにもできなくなる可能性があります（当たり前ですが同じ sAMAccountName のユーザIDを作ってもSIDが別物だから意味がない）。実環境のサーバならなおさらです。SQL ServerのWindows認証と同様に、構築時に複数のIDを「完全な権限を持つ管理者」かつ「スコープが完全」に指定しておくべきかと。
← １つ前へ ＊＊ 目次に戻る ＊＊ １つ先へ →