SCCM

64bit OSに対して32bitプログラムでレジストリに値を書き込むと、64bit版のレジストリエディタでは「HKEY_LOCAL_MACHINESoftwareWOW6432Node」に値が保存されます。32bitのレジストリエディタからは通常通りの値に見えます。 - [64 ビット バージョンの Windows でシステム レジストリを表示する方法](http://support.microsoft.com/kb/305097/ja) System Center Configuration Managerにてレジストリの中に書き込まれている値をインベントリで収集する場合にこの部分が混乱の元になります。 また、クライアントにインストールされるエージェントは基本的に以下のようになります。 - 32ビットOSにインストールされるエージェントは32ビット - 64ビットOSにインストールされるSCCMのエージェントは64ビット どちらのバージョンのエージェントが動いているかはタスクマネージャーでccmexec.exeを確認すれば確認する事ができます。 32bitでレジストリに値を書き込むようにしておき、それを64bitのクライアントから読もうとすると読めない!というような事になってしまう可能性があります。 対策としては、32bit、64bitにかかわらずレジストリの同じ場所に値が書き込まれるべきで、.net frameworkで作成されているプログラムであれば、これはプロジェクトのビルド設定でプラットフォームターゲットを「Any CPU」に設定すればOKです。 32bitOS上のVisual Studioで新規にプロジェクトを作った状態だと、この値はx86に設定されていました。注意が必要だと思います。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMでレジストリに値を格納、インベントリで取得するときの32bit, 64bitの違いについての注意点 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/03/01/sccm%E3%81%A7%E3%83%AC%E3%82%B8%E3%82%B9%E3%83%88%E3%83%AA%E3%81%AB%E5%80%A4%E3%82%92%E6%A0%BC%E7%B4%8D%E3%80%81%E3%82%A4%E3%83%B3%E3%83%99%E3%83%B3%E3%83%88%E3%83%AA%E3%81%A7%E5%8F%96%E5%BE%97/)

Windows8のロックスクリーンをSCCM 2012 SP1でカスタマイズする方法がNothing but ConfigMgrさんで紹介されています。 Deploying Windows 8 and Customizing the Lock Screen with ConfigMgr 2012 | Nothing but ConfigMgr - Windos 8の展開はSCCM 2012 SP1でないと行えない - アクティベートされたWindows 8 Enterpriseでないとロックスクリーンのカスタマイズは行えない - [Windows 8 and Windows Server 2012 cumulative update: November 2012](http://support.microsoft.com/kb/2770917/en-us) が適用された端末でないとロックスクリーンのカスタマイズは行えない - HKLMSOFTWAREPoliciesMicrosoftWindowsPersonalizationの下にLockScreenImageをREG_SZで作成し、そこにjpgイメージへのパスを記入すればよい

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [Windows8のロックスクリーンをSCCM 2012 SP1でカスタマイズする方法 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/28/windows8%E3%81%AE%E3%83%AD%E3%83%83%E3%82%AF%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%92sccm-2012-sp1%E3%81%A7%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA%E3%81%99%E3%82%8B/)

以下の記事でワークグループ端末へのSCCMクライアントのプッシュインストールは「できるらしい」というところまで調べましたが実際には未実施でした。 - [SystemCenter Configuratoin Manager 2012のクライアントエージェントをワークグループ端末にプッシュインストールする方法 | WindowsServer管理者への道](http://ebi.dyndns.biz/windowsadmin/2013/02/07/systemcenter-configuratoin-manager-2012%e3%81%ae%e3%82%af%e3%83%a9%e3%82%a4%e3%82%a2%e3%83%b3%e3%83%88%e3%82%a8%e3%83%bc%e3%82%b8%e3%82%a7%e3%83%b3%e3%83%88%e3%82%92%e3%83%af%e3%83%bc%e3%82%af/) 時間を取って試してみた結果を記録しておきます。結論としては一応出来ましたが、確かにこれは厳しいかも…。 まずは、手順です。 サイトの設定にて、クライアントプッシュインストールの設定を行います。 [アカウント]タブにて、新規作成ボタンをクリックします。 ワークグループ端末のローカルの管理者アカウントを指定します。この時に[%COMPUTERNAME%]を使うのがミソです。 複数台で異なるローカル管理者アカウントが必要な場合には、複数登録しておくことができます。それぞれのアカウントで試行して成功するものを使ってくれます。 少なくともSMSSITECODEとSMSMPはオプションとして登録する必要があります。その他はお好みで。 クライアントがインストールされていないワークグループ端末に対して[クライアントインストール]を実行します。ちなみにこのクライアントはWindows7, XPです。 ここでは、[クライアントソフトウェアを常にインストールする]を選択しておかないとインストールが開始出来ませんので注意してください。 これでうまくいくかとおもいきや、残念ながらWindows7のプッシュインストールに失敗してしまいました。 admin$管理共有への接続に失敗しています。これはワークグループ端末では管理共有は規定でアクセスできないようになっているからですね。 - [【コラム】Windowsスマートチューニング (42) XP/Vista編: UACが有効な状態で管理共有を有効にする | パソコン | マイナビニュース](http://news.mynavi.jp/column/windows/042/index.html) 確認のためにUACを無効化して再度実行してみたところ、今度はプッシュインストールに成功しました。 結論 私がテストした結論としては以下のとおりです。 - ワークグループ端末にもプッシュインストールできる。 - 前提条件は以下 ローカルアドミンのID, Passwordがわかっている。 - Windows FireWallで以下を許可している。 Outbound and inbound: **File and Printer Sharing** - Inbound: **Windows Management Instrumentation (WMI)** - UACを無効化している、あるいはレジストリを編集し、管理共有へのアクセスを許可している。 - SCCMの(不安定、あるいは仕様がよくわからない)ネットワーク探索で端末が検索されている。 - 実際使えるか→使えない。 ...

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCM 2012 SP1でワークグループ端末へのクライアントプッシュインストールを試してみました。 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/27/sccm-2012-sp1%E3%81%A7%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E7%AB%AF%E6%9C%AB%E3%81%B8%E3%81%AE%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%83%97%E3%83%83/)

SystemCenter Configuratoin Manager 2012のクライアントエージェントをワークグループ端末にプッシュインストールする方法でワークグループ端末にもSCCMクライアントがpush installできるらしい…という話を書きました。実際に試してみようと思いまずはネットワークを探索…したのですが、なかなか出てきてくれずかなり困ってしまいました。まだよくわかっていない部分もあるのですが、いくつか調べたこと、わかったこと、教えてもらったことをを書いておきます。 ワークグループ端末の検索には「ネットワーク探索」を使います。 ネットワーク探索には3つの種類があります。ワークグループ端末に対してリモートから取得できるそれなりに詳細な情報を得るために「トポロジ、クライアント、およびクライアントのオペレーティングシステム」を選択します。テストのためクライアント側ではWindows Fire Wallは無効にしてあります。 とりあえず、サブネットで所属しているネットワークを入力。下に「ローカル サブネットを検索する」のチェックもあるので無意味な入力にも思えますが、とりあえず入力しておきます。 あとは、適当にスケジュールを設定しておけばOK…。 と思ったのですが、私のテストした環境ではこの状態ではデフォルトゲートウェイに設定してあるルーターは表示されたものの何時まで経っても何度実行しても、ワークグループ端末は表示されてくれませんでした。 ログはコンポーネントの「SMS_NETWORK_DISCOVERY」に表示されています。 仕事はしてくれているようですし、特にエラーも起きていません。しかし、端末は見つけてきてくれていません・・・。 #別の環境ではこの設定だけでもきちんと端末を見つけてきてくれた、という話も聞きます。違いはわかっていません。 時間が原因7日ともおもいこの状態で2,3日放置もしてみたのですが、結果は変化無しでした。あまり時間が取れずこのあとの調査ができていなかったのですがtechnetにこの設定だけではダメだという記載がある、ということを教えてもらいました。 - [Planning for Discovery in Configuration Manager](http://technet.microsoft.com/en-us/library/gg712308.aspx) 上記のページに以下の記述があります。 To enable Network Discovery to search for IP-addressable devices, you must configure one or more options that specify how to query for devices. The options are listed in the following table. この文章の下の表にある選択肢は以下の3つです。 - Domains - SNMP Devices - DHCP つまり、この文章をそのまま受け取れば、ネットワーク探索を有効にしてサブネットを登録すると、そのサブネット内のすべてのIPに対してポートスキャンをする…のではなく、ドメイン情報、SNMP、DHCPに入力された情報を元にそこで見つけた端末に対してのみ検索を行う…という事になると思います。 ...

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMのネットワークの探索でワークグループ端末が発見できない | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/26/sccm%E3%81%AE%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%AE%E6%8E%A2%E7%B4%A2%E3%81%A7%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97%E7%AB%AF%E6%9C%AB%E3%81%8C/)

Always on the clockさんで、SCCM 2012 SP1からできるようにになったMAC OXへのエージェントインストール方法が紹介されています。 - [MacOSにSCCMクライアントをインストール](http://sophiakunii.wordpress.com/2013/02/12/macos%E3%81%ABsccm%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%82%92%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB/) MAC OSの管理にはHTTPSの構成が必須になり、そのためにはクライアントにも証明書の配布が必要となり…ドメイン環境であればクライアント証明書の配布が容易なのでいいのですが、ワークグループの端末やMacの管理のために、クライアント全台を設定して回る必要がでてくるのは環境によっては厳しいですね。仕方がないといえば仕方がないのですけれども。 このあたり、どのようにすればクライアントエージェントの展開が簡単になるだろうかということを考えています。まだ考えはまとまっていないのですが、そのうちこのブログでお伝え出来ればいいなと思います。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCM 2012 SP1でMAC OXを管理 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/24/sccm-2012-sp1%E3%81%A7mac-ox%E3%82%92%E7%AE%A1%E7%90%86/)

SCCM 2012 SP1でワークグループ端末をHTTPS接続で管理する必要があり、いくつかハマりどころがありましたので共有しておきます。 一般的な手順 一般的な手順は以下のあたりで公開されています。ありがたいです。 - [SCCM2012のインストール ～ https編 « Always on the clock](http://sophiakunii.wordpress.com/2013/01/31/sccm2012%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB-%EF%BD%9E-https%E7%B7%A8/) - [How to install a ConfigMgr Client on a WORKGROUP computer, when the ConfigMgr Site is in Native Mode. | Nothing but ConfigMgr](http://www.petervanderwoude.nl/post/how-to-install-a-configmgr-client-on-a-workgroup-computer-when-the-configmgr-site-is-in-native-mode/) ポイントはクライアント証明書を配布、構成する必要があるという点ですね。ドメイン環境なら色々自動的にばらまく方法がありますが、ワークグループ環境だと中々厳しいですね・・・。 CRLの取得 話はこれで終わらずこの状況でドメイン参加しているクライアントはHTTPS通信できるようになりましたが、ワークグループ環境の端末はHTTPSで通信できないという状況になってしまいました。クライアントのログをよくみてみると「WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED」というようなエラーが出ており、それを元に検索すると証明書のCLRをとりにいって失敗しているということがわかりました。 手順通りに構成するとCRLはldap://から始まるアドレスで構成されており、ドメインに参加していないとこれが取得できないのかな？と推測されました。そこで「CRLを無効化すればいいんだろう」とおもって、すぐに思い浮かんだのはIEの設定です。 上記の「サーバーの証明書失効を確認する」のチェックボックスを外して試してみたところ…状況変わらず。CRLの線は外れだったのだろうと思い込んでまた別のことを色々調べ始めてしまいました。ですが、CRLを無効化すればとりあえず動くというのは当たりでした。実はSCCMではMP側にCRLをチェックする、しないの設定があったのでした。 以下のページを参考に、MPにてCRLのチェックを無効化し、クライアントを入れなおす(上書きインストール)することでこの問題はクリアすることができました。 - [RegTask: Failed to send registration request message. Error: 0x87d00231](http://social.technet.microsoft.com/Forums/en-US/configmanagerdeployment/thread/907fe750-3282-4f9e-b75a-f6e29696c30c/) SMSSLPパラメータの付与 上記の対応を行った上で、さらに、ワークグループクライアントに関してはコマンドラインのインストールパラメータでSMSSLPオプションを指定してあげないときちんとMPと通信出来ませんでした。ログ上ではAD上から管理ポイントを発見できないと出ていました。SMSSLPパラメータを付与することで解決しました。

SCCM 2012 SP1でワークグループ端末をHTTPS接続で管理する必要があり、いくつかハマりどころがありましたので共有しておきます。 一般的な手順 一般的な手順は以下のあたりで公開されています。ありがたいです。 - [SCCM2012のインストール ～ https編 « Always on the clock](http://sophiakunii.wordpress.com/2013/01/31/sccm2012%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB-%EF%BD%9E-https%E7%B7%A8/) - [How to install a ConfigMgr Client on a WORKGROUP computer, when the ConfigMgr Site is in Native Mode. | Nothing but ConfigMgr](http://www.petervanderwoude.nl/post/how-to-install-a-configmgr-client-on-a-workgroup-computer-when-the-configmgr-site-is-in-native-mode/) ポイントはクライアント証明書を配布、構成する必要があるという点ですね。ドメイン環境なら色々自動的にばらまく方法がありますが、ワークグループ環境だと中々厳しいですね・・・。 CRLの取得 話はこれで終わらずこの状況でドメイン参加しているクライアントはHTTPS通信できるようになりましたが、ワークグループ環境の端末はHTTPSで通信できないという状況になってしまいました。クライアントのログをよくみてみると「WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED」というようなエラーが出ており、それを元に検索すると証明書のCLRをとりにいって失敗しているということがわかりました。 手順通りに構成するとCRLはldap://から始まるアドレスで構成されており、ドメインに参加していないとこれが取得できないのかな？と推測されました。そこで「CRLを無効化すればいいんだろう」とおもって、すぐに思い浮かんだのはIEの設定です。 上記の「サーバーの証明書失効を確認する」のチェックボックスを外して試してみたところ…状況変わらず。CRLの線は外れだったのだろうと思い込んでまた別のことを色々調べ始めてしまいました。ですが、CRLを無効化すればとりあえず動くというのは当たりでした。実はSCCMではMP側にCRLをチェックする、しないの設定があったのでした。 以下のページを参考に、MPにてCRLのチェックを無効化し、クライアントを入れなおす(上書きインストール)することでこの問題はクリアすることができました。 - [RegTask: Failed to send registration request message. Error: 0x87d00231](http://social.technet.microsoft.com/Forums/en-US/configmanagerdeployment/thread/907fe750-3282-4f9e-b75a-f6e29696c30c/) SMSSLPパラメータの付与 上記の対応を行った上で、さらに、ワークグループクライアントに関してはコマンドラインのインストールパラメータでSMSSLPオプションを指定してあげないときちんとMPと通信出来ませんでした。ログ上ではAD上から管理ポイントを発見できないと出ていました。SMSSLPパラメータを付与することで解決しました。

SCCMのサイト情報をクライアントに通知する方法は色々ありますが、一番良く使われるのはActive Directory及びそのDNSへの発行だそうです。この処理が行われていればDNSを参照しているクライアントが管理ポイントを発見して正常に接続することができます。 以下はその処理が成功していることの確認方法です。 [管理] – [概要] – [階層の構成] – [Active Directoryフォレスト]に、探索を有効にしているフォレストの一覧が出てきます。そこで[発行ステータス]が[成功]になっていればきちんとフォレストに対して管理ポイントの情報を発行することができています。 この操作でCN=System Management,CN=Systemへのオブジェクトの作成が行われています。(おそらく) DNSにもSRVレコードが作成されています。 この辺りは基本的に自動的になされる処理なのであまり気にしないはずなのですが、私はSystem Managementフォルダへのコンピューターアカウントのアクセス件の出し方に失敗(子オブジェクトへのアクセス権を許可しなかった)関係でフォレストへの発行がうまく行かず、その結果ワークグループ環境のコンピューターで何時までたってもエージェントがまともに動かないことでこの辺りに問題が発生していたことに気が付きました。自戒を込めて書き残しておきます。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMサイト情報のActive Directoryへの発行 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/18/sccm%E3%82%B5%E3%82%A4%E3%83%88%E6%83%85%E5%A0%B1%E3%81%AEactive-directory%E3%81%B8%E3%81%AE%E7%99%BA%E8%A1%8C/)

SCCMにはまだ触り始めたばかりですが、何度かインストールを繰り返しています。その中で「何もしていないのにエラーが出ている」という現象にすでに何度か遭遇しています。どうやら普通にインストーラーを走らせただけでもうまく構成が完了していないようなケースがあるようです。 ですので、インストール直後にはまず正常性の確認を実行。何かうまくいかないときにもすぐに正常性の確認を実行。…と、癖をつける必要がありそうです。 まず、確認すべきなのは[サイトのステータス]。以下の場所できちんとすべてのステータスがOKになっていることを確認します。 さらに、[コンポーネントのステータス]でもすべてのコンポーネントのステータスがOKになっていることを確認します。 上記はほぼインストール直後で境界および境界グループの設定後に何台かクライアントを導入しただけの環境ですが、エラーおよび警告が発生してしまっていました。 エラーメッセージを表示します。 上記からはActive Directory内のコンテナ、オブジェクトへの権限が無いか、スキーマ拡張がなされていない…という事がわかります。修正後、カウンタをリセットしてしばらくすればステータスはOKに戻ります。万が一問題が解決されていなければ再度ステータスは重大に変化します。 上記のエラーの例は単に私の操作ミスでしたが、何かあった時にはここにまず反応が出てきますので常に確認をするべきと思われます。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMの正常性確認は都度行う必要があるようです。 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/17/sccm%E3%81%AE%E6%AD%A3%E5%B8%B8%E6%80%A7%E7%A2%BA%E8%AA%8D%E3%81%AF%E9%83%BD%E5%BA%A6%E8%A1%8C%E3%81%86%E5%BF%85%E8%A6%81%E3%81%8C%E3%81%82%E3%82%8B%E3%82%88%E3%81%86%E3%81%A7%E3%81%99%E3%80%82/)

SCCM自体ほぼリアルタイムに反応するようなシステムではなく、設定が反映されるまでに長い時間がかかってしまいます。ですが、そういう環境でも「なるべく早く設定を反映したい、結果を得たい」という時にはクライアント側でアクションをキックする、ということができます。 クライアントアクションは以下のように多数存在しています。 クライアントコンピューター上で1台ずつすべて操作をするのも大変なので、スクリプトでキックできると素敵です。これはCPAPPLET.CPAppletMgrというCOMオブジェクトを使うことで可能です。以下、VBScriptとPowerShellのスクリプト例です。 [gist id=“4942879”] [gist id=“4942874”] 参考になれば幸いです。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMのクライアントアクションをスクリプトで実行する方法 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/16/sccm%E3%81%AE%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%82%A2%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%88%E3%81%A7%E5%AE%9F%E8%A1%8C/)

SCCMで何かうまくいかないことが起きた時には、ログファイルを確認することになります。サーバー側、クライアント側両方に多数のログが生成されているのですが、メモ帳で開いて見るのは中々厳しいログです。そこでサーバー上にログファイルを閲覧するためのツールが用意されています。 ツールの置かれている場所は"C:\Program Files\Microsoft Configuration Manager\tools\cmtrace.exe"です。 初回起動時には、*.logへの関連付けの設定が行えます。 サーバー上のログファイルは"C:Program FilesMicrosoft Configuration ManagerLogs"に格納されています。 何か問題がある場合には、問題の箇所が赤でハイライトされます。 単純にインストールしただけなのにうまく動いていない事が結構あるので、ログファイルはこまめにチェックしたほうがよさそうです。 ログファイルの場所に関しては以下のKBに記載されています。 - Configuration Manager のログ ファイルのテクニカル リファレンス http://technet.microsoft.com/ja-jp/library/hh427342.aspx あまりにも多くのログファイルがあってクラクラしますね…。 さらに、このツールはクライアントPCにコピーすればクライアントPC上のログの確認にも使えます。ノートパットで見るよりもはるかに便利なので是非使ってみて下さい。追記されたものも自動的に見られて便利です。

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCCMのログファイルの確認方法 | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/02/13/sccm%E3%81%AE%E3%83%AD%E3%82%B0%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E7%A2%BA%E8%AA%8D%E6%96%B9%E6%B3%95/)