none
プロビジョニングパッケージのPolicies/Update/RequireDeferUpgradeの代替(1607) RRS feed

  • 質問

  • 1511をCBBにする設定でプロビジョニングパッケージのPolicies/Update/RequireDeferUpgradeがあります。

    しかし、

    https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/device-update-management#windows10version1607forupdatemanagement

    Here are the new policies added in Windows 10, version 1607 in Policy CSP. You should use these policies for the new Windows 10, version 1607 devices.

    とあり

    Note
    For policies supported for Windows Update for Business, when you set policies for both Windows 10, version 1607 and Windows 10, version 1511 running on 1607, then 1607 policies will be configured (1607 trumps 1511).

    ともありますが、新しいPoliciesは10.014393.0のWindows ICDでは有効になっていません。

    MDM等を使用せずに、クライアントPCでのみプロビジョニンングパッケージでカスタマイズする場合には、古いポリシーを使うしかないのでしょうか?

    • 種類を変更済み tmori3y2 2017年1月23日 12:01
    • 種類を変更済み tmori3y2 2017年1月23日 12:52
    2017年1月17日 22:27

回答

  • もともと、以下の記事を見て、非Windows系サーバを中心に運営されているネットワーク(非ドメイン環境)の開発系Windows 10クライアント(開発環境 or 評価専用)での標準設定の展開にプロビジョニングパッケージが利用できないか?と考えました。

    https://technet.microsoft.com/ja-jp/itpro/windows/manage/configure-devices-without-mdm

    Windowsサーバもあるにはありますが、集中管理しない理由は、1511と1607の設定を個別に設定したいと思ったからです。

    しかし、これまでの調査結果を考えると、1607での非対応の機能もあることから、Windows Updateの制御にプロビジョニングパッケージを使用すべきではないと思うようになりました。

    1607では、GPOもUIと連動しないという問題はありますが、非ドメイン環境の設定にはGPOのレジストリを検討してみようと思います。


    • 回答としてマーク tmori3y2 2017年1月23日 12:56
    2017年1月23日 12:56

すべての返信

  • https://technet.microsoft.com/ja-jp/itpro/windows/manage/waas-configure-wufb

    をヒントにプロビジョニンングパッケージでPolicies/Update/RequireDeferUpgrade=trueに変更したときの挙動をみました。

    レジストリ:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\Update

    (1)インストール

    ・RequireDeferUpgrade=1

    ・RequireDeferUpgrade_ProviderSet=1 (生成)

    ・設定画面の更新プログラムの詳細オプション:連動せず

    (2)アンインストール

    ・RequireDeferUpgrade=0

    ・RequireDeferUpgrade_ProviderSet (削除)

    ・RequireDeferUpgrade_LastWrite=1 (生成)

    ・設定画面の更新プログラムの詳細オプション:連動せず

    この挙動はPolicies/Update/AllowMUUpdateServiceも同じでした。

    個人的には、設定画面に反映されない項目についてはプロビジョニンングパッケージで操作しない方が無難と思いました。

    取り敢えず閉じさせていただきます。

    参考資料追記

    https://technet.microsoft.com/ja-jp/library/mt622729(v=vs.85).aspx

    017.01.20情報共有のため追記

    UI設定は、

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UX\Settings

    に保存されるようですが、どうもこれがMDMの設定と連動していないようです。

    GPOは1511だとgpupdate /forceでUXの方も書き換わっていたように思うのですが、1607だと書き換わりません。

    また、

    https://technet.microsoft.com/ja-jp/itpro/windows/manage/waas-configure-wufb

    の最後の方に、1511の旧式GPU/MDMの設定が有効なのは1607の新しい設定がされるまでで、一旦1607の設定がされるとそちらが優先されるとあります。

    これも厄介は話かと思いました。


    • 回答としてマーク tmori3y2 2017年1月18日 15:36
    • 編集済み tmori3y2 2017年1月19日 15:39
    2017年1月18日 15:36
  • もともと、以下の記事を見て、非Windows系サーバを中心に運営されているネットワーク(非ドメイン環境)の開発系Windows 10クライアント(開発環境 or 評価専用)での標準設定の展開にプロビジョニングパッケージが利用できないか?と考えました。

    https://technet.microsoft.com/ja-jp/itpro/windows/manage/configure-devices-without-mdm

    Windowsサーバもあるにはありますが、集中管理しない理由は、1511と1607の設定を個別に設定したいと思ったからです。

    しかし、これまでの調査結果を考えると、1607での非対応の機能もあることから、Windows Updateの制御にプロビジョニングパッケージを使用すべきではないと思うようになりました。

    1607では、GPOもUIと連動しないという問題はありますが、非ドメイン環境の設定にはGPOのレジストリを検討してみようと思います。


    • 回答としてマーク tmori3y2 2017年1月23日 12:56
    2017年1月23日 12:56