2021年4月10日土曜日

Windows10 2004 にKB5001567 をWSUS 経由で配布すると適用できない

KB5001567 ですが、こちらの更新プログラムは既定でWSUS からの配信ができない更新プログラムとなります。
そのため、WSUS を利用して配信したい場合、WSUS へのインポート作業が必要となります。


WSUS へKB5001567 を無事インポートできたところで、こちらの更新プログラムをWindows10 2004 のクライアントへ配信すると、クライアント側には何故か適用できていないが、WSUS レポート上はKB5001567 がインストール済みと表示されます。
※Windows10 20H2 は問題なく適用できます。



原因は不明ですが、私の検証だと、KB5000802 をインストールすると、KB5001567 がインストール済みと判定されてしまうようです。
また、KB5000802 をインストールすると、同梱されているサービススタックの更新プログラム、KB5000858 がインストールされますので、KB5000802 かKB5000858 がインストールされると、KB5001567 がインストール済み、という判定がされてしまうようです。

現状こちらの更新プログラムを適用したい場合は、Windows Update カタログサイトからスタンドアロンの更新プログラムをダウンロードして適用するか、Windows Update から適用するしか方法がないようです。

しかしながら、すでにKB5001649 がリリースされているので、こちらを適用するのが正解でしょう。

2020年5月20日水曜日

クライアント端末の最新のIP アドレス取得について

SCCM でクライアント端末のIP アドレスの取得について調べてみました。
まず、IP アドレスを取得する方法は大きく3つあります。

  • Active Directory のシステム探索
  • 定期探索
  • ハードウェアインベントリ(Win32_NetworkAdapterConfiguration)

これらの中で、ハードウェアインベントリ以外はシステムリソースの値を更新します。

例えば、コレクションを生成する際にクエリ規則でシステムリソースからIP アドレスを選択した場合に、そのクエリ規則を有効にするためには、ハードウェアインベントリ以外の方法でIP アドレスの情報を更新しないと、意図したコレクションに所属しないわけです。

そのため、クライアント側の最新のIP アドレスを反映したコレクションを作りたい、ということであれば、Active Directory のシステム探索、及び定期探索を実行するしかなく、定期探索についてはスケジュール設定できないため、Active Directory のシステム探索のスキャンサイクルを短くするしか方法がありません。

ちなみに、ハードウェアインベントリで収集したIP アドレスは、データベースの下記のビューを更新します。

  • v_GS_NETWORK_ADAPTER_CONFIGURATION

それ以外の探索では、下記のビューを更新します。

  • v_RA_System_IPAddresses

これらの値を取得しているかどうかは、クライアント端末側の[InventoryAgent.log] で確認ができます。

参考:ログ ファイルのリファレンス


また、クライアントに複数のIP アドレスが合った場合に、どちらが最新のIP アドレスであるか(後から設定されたIP アドレスであるかどうか)といったこともSCCM ではわからないため、この場合は境界グループで配布ポイントを制御しないと、意図しない配布ポイントからコンテンツをダウンロードしてしまう、といった懸念がありますので、注意が必要です。

2020年5月5日火曜日

SCCM Client Agent のパッケージ配信インストール方法

SCCM Client Agent をパッケージ展開してClient Agent をインストール(アップグレードも可)する場合、まずプライマリサイトサーバの最新バージョンのClientフォルダを展開のパッケージ作成時に指定するフォルダにコピーします。

デフォルトでClient フォルダは以下になります。
C:\Program Files\Microsoft Configuration Manager\Client

そのフォルダ内に下記のサンプルコマンドを持つバッチファイルを「install.bat」として保存します。

■サンプルコマンド
 \\<ServerName>\<ContentsPath>\ccmsetup.exe /source:"\\<ServerName>\<ContentsPath>" SMSSITECODE=<SiteCode>
※適宜、管理ポイントを指定するオプション等を追加してください。 (*1)

パッケージ展開作成時に、[このパッケージにソースファイルを含める] を選択して、先ほどコピーしたフォルダを選択し、コマンドラインに下記のように指定します。
%windir%\sysnative\cmd.exe /c install.bat

こちらのパッケージを展開すれば、クライアントのインストール、もしくはアップグレードが可能になるかと思います。
すでにClient Agent がインストールされているクライアントにインストール(アップグレード)する場合、サイズの制限に達していなければ、ccmcache は削除されませんので、検証してみてください。

(*1) CCMSetup.exe のコマンドライン パラメーター

SCCM で管理しているクライアントで、意図せずパッチが適用され再起動されてしまう場合

SCCM で管理しているクライアントに再起動をしないように展開設定してパッチを適用しているが、意図せずクライアント側でパッチ適用、及び再起動が実行されてしまう場合があります。

この原因の多くは、WSUS のグループポリシーによるものです。

具体的には、下記のグループポリシーが有効になっている場合、WSUS 側で管理されているパッチが適用され、再起動がされてしまいます。


そのため、クライアントのパッチのすべてをSCCM で管理したい場合は、こちらの項目を[無効] にするのがよいでしょう。

2020年5月4日月曜日

ダウンロード済みのソフトウェア更新プログラムをダウンロードしていない状態に戻す方法

前回、ソフトウェア更新プログラムのコンテンツをダウンロードするのに、VPN 回線を利用させない方法をご紹介しましたが、1つの展開設定に関して、前提条件を満たさないと表示されない設定がありました。

それは配布ポイントからコンテンツをダウンロードさせない設定になるのですが、展開設定の中で、「展開パッケージなし」を選択する、というものでした。


この選択画面を表示させる場合、対象のコンテンツがダウンロードされていない状態でないと、この画面は表示されません。

そのため、これをダウンロードされていない状態に戻すやり方があります。
参照している展開をすべて削除することで[ダウンロード済み] 列が[はい] から[いいえ] に変わります。

やり方としては、QU であれば、下記の[展開パッケージ] より、[メンバーの表示] を表示させると、その展開パッケージが参照しているQU を確認できるので、ダウンロード済みを[いいえ] にしたいQU がある場合は、その展開パッケージを削除します。

FU の場合は、展開] タブより、展開を削除していただければOK です。


ただ、すでに展開をしているような状況であると、展開を削除しなければいけないため、削除してよいかを確認する必要がありますが、間違えて展開を削除しても、また対象のコレクションに対して展開を作成してあげれば、QU, FU が適用されていないコレクションに対して、再度適用する動作となります。
ただ、自身が作成していない展開設定であれば、確認をして削除することをお勧めします。

2020年5月3日日曜日

VPN回線を使わないで、VPNクライアントにソフトウェア更新プログラムをダウンロード

SCCM でVPN クライアントを管理する場合、VPN 回線を利用して何GB ものコンテンツを配布ポイントからダウンロードしてしまうことが、管理者にとっての悩みになるかと思います。

しかし、VPN Split Tunneling を利用できる環境であると、VPN 回線でSCCM サーバーとのポリシー情報を同期し、インターネット回線でFU, QU などのソフトウェア更新プログラムを取得することが可能になるかと思います。

じゃあ、実際にどうやるかというと、下記の前提条件を元に、いくつか設定する項目がありますので、そちらを設定して上げるとうまくいくと思われます。

前提条件:VPN クライアントを特定の境界、境界グループに所属させる。

この前提条件を満たすことにより、境界グループの下の設定を利用できます。


この設定にチェックを入れておくことで、通常配布ポイントにコンテンツを取得しに行く動作が、最初にクラウドベースのソース、すなわちWindows Update 等を参照しに行きます。
VPN Split Tunneling を利用して、これにチェックを入れるということは、展開設定はVPN 通信でサーバーからクライアントに同期され、クライアントはこのチェックの通り、インターネット経由でコンテンツをダウンロードする、ということが可能となります。

ただ、インターネット経由でのダウンロードに失敗した場合、やはり配布ポイントにコンテンツを取得しに行こうとする動作は依然として残っています。

その場合は、展開設定で[展開パッケージなし] を選択してあげると、配布ポイントにコンテンツが存在しない状態となります。



これに加えて下記の設定をしてあげることで、配布ポイントにコンテンツがない場合、インターネット経由でコンテンツをダウンロードする動作となりますので、検証して頂ければと思います。


2019年9月8日日曜日

AWSでBitnamiを利用して立てたWordpressのサイトをHTTPS化

■やりたいこと
・AWSのCertificate Managerを利用してHTTPS化

■前提条件
・リダイレクト処理は入れない
・AWSのセキュリティグループのポートは80と443を開けておく
・AWSのEC2インスタンスにつけているロードバランサのリスナーポートは80と443を使う。443は証明書が登録されている。両ポート、共にEC2インスタンスに転送する設定にする。

■主なファイルの読み込み順序

/opt/bitnami/apache2/conf/bitnami/bitnami-apps-vhosts.conf
/opt/bitnami/apps/wordpress/conf/httpd-vhosts.conf
/opt/bitnami/apps/wordpress/conf/httpd-app.conf
/opt/bitnami/apps/wordpress/conf/htaccess.conf

■修正したファイル
/opt/bitnami/apps/wordpress/conf/httpd-vhost.conf

<VirtualHost *:80>
    ServerName yourdomain.com
    ServerAlias yourdomain.com
    DocumentRoot "/opt/bitnami/apps/wordpress/htdocs"
</VirtualHost>
<VirtualHost *:443>
    ServerName www.yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot "/opt/bitnami/apps/wordpress/htdocs"
    SSLEngine on
    SSLCertificateFile "/opt/bitnami/apache2/conf/server.crt"
    SSLCertificateKeyFile "/opt/bitnami/apache2/conf/server.key"
    Include "/opt/bitnami/apps/wordpress/conf/httpd-app.conf"
</VirtualHost>
ちなみに、サーバ証明書ファイルが存在するファイルは、以下のパスになります。
/opt/bitnami/apache2/conf