35歳からの中二病エンジニア

社寺・鉄道・アニメを愛でるウェブ技術者の呟き

Windows 10の設定をPowerShellから一発適用する

aikawame.hateblo.jp

MacからWindowsへの移行シリーズ第3回では、インストールされたWindows 10に設定を自動適用していく。なお、シリーズの目次は上記リンクから辿ってほしい。

ここでやること

  • Windowsを設定するためのPowerShellスクリプトを作成する
    • 不要なUWPアプリの削除
    • Package Managementの設定
    • Package Managementによるアプリケーションのインストール
    • レジストリファイルによるWindows設定のカスタマイズ

ちなみに先に断っておくと、ここでの内容もやろうと思えばAnsibleで実現できなくはない。ただ、AnsibleとWindowsの接続にはWinRMというSSHとは異なる仕組みが必要で、その準備が面倒だったり、SSHへの対応もまだexperimentalだったりと過渡期な感じなので、個人的に現時点ではPowerShellでやった方が楽だという結論に達した。興味のある方はAnsibleの公式ドキュメントを参照していただきたい。

成果物

github.com

土台のスクリプトを用意する

さて、先述の処理を全て1つのファイルにまとめることも可能ではあるけれども、長くなるので土台のスクリプトから呼び出すようにしたい。土台のスクリプトは成果物のinstall.ps1として用意してあるので、順に説明していく。

1行目の Set-ExecutionPolicy は、スクリプト実行についての設定で、クライアント向けのWindowsエディションだとデフォルトは Restricted となっている。この状態だとスクリプトを実行できないので、最初に RemoteSigned とすることでポリシーを緩めている。当然セキュリティー的な観点からは褒められた行為ではないので、一連の作業が完了したら元に戻しておきたい。

2行目の $ErrorActionPreference = 'Stop' は、エラーハンドリングに関する設定だ。デフォルトは Continueとなっていて、エラー発生時にも処理が続行されるので、止めるように設定を変更している。

4行目からの処理では、構成管理用のリポジトリーをWindowsの一時ディレクトリーに展開している。Invoke-WebRequest を使わないのか?と思われるかもしれないが、ヤツはファイルの書き出しが非常に遅いのでサイズの大きなデータには適さない。そのため、今回紹介しているスクリプトでも極力使わないようにしている。

10行目から呼び出しているスクリプトは、それぞれ先に箇条書きした処理の内容となっている。続く14行目からがレジストリファイルの呼び出しだ。レジストリ設定についてはPowerShellで書くこともできるが、レジストリファイルの方がレジストリエディターやサードパーティーツールでのインポート・エクスポートが便利なので、こちらのやり方をオススメしたい。

19行目からのWSL関連の処理は最終回で紹介するので、ここでは触れない。最後の処理は見ての通り、一時ディレクトリーの後始末だ。

不要なUWPアプリを削除する

Macだと、プリインストールされているアプリケーションはたとえ「チェス」であっても削除できない(SIPを無効にすれば削除できるが…)。一方のWindowsでは、デフォルトで削除できるようになっている。一部のアプリケーションはスタートメニューからは削除できないが、PowerShellを使えば可能だ。

ただし、一部のアプリケーションは削除すると他のアプリケーションとの依存関係で不具合が発生することもあるので、サンドボックス等の壊れても構わない環境で確認しておいた方が安全だ。この辺り、安全側に倒した代償としてユーザーの自由を奪うMacと、比較的自由だが弄って壊れても自己責任なWindowsという、両者の思想の違いがよく表れていると思う。

さて、アプリケーションを削除するコマンドは以下となっている。

Get-AppxPackage 'Microsoft.MicrosoftSolitaireCollection' | Remove-AppxPackage

このコマンドではソリティアのみを削除するが、成果物のremove_appx_packages.ps1のようにスクリプトファイルにしてパッケージ名を配列化しておけば、実行するだけで指定したパッケージを一括削除できるので便利だ。僕はほぼ全てのUWPアプリを削除するようにしている。

ちなみに、現在インストールされているアプリケーションを一覧したい場合には、以下のようなコマンドを使う。

Get-AppxPackage | Sort-Object Name | Select Name, PackageFullName

ところで、「UWPアプリ」と断っている通り、ここで対象となるのは最近登場したUWPアプリのみで、従来からのデスクトップアプリは範疇外となる。この辺り、近年のWindowsは過渡期な雰囲気でカオス感溢れているけれども、そこもまた後方互換性を重視するWindowsと過去をバッサリ切り捨てるMacの思想の違いということでひとつ。

Package Managementを設定する

不要なアプリケーションを削除したら、今度はアプリケーションのインストールだ。

MacだとここでHomebrewの出番なのだけれども、Windowsの場合はPackage Managementというパッケージ管理の仕組みが最近になって標準搭載されるようになった。一方、それ以前からChocolateyというサードパーティーのパッケージ管理ツールが存在していて、デファクトスタンダードとなっていた。

こうした歴史的経緯から、Package ManagementはChocolateyを含むパッケージ管理ツールを「プロバイダー」として取り込み、自身は共通のインターフェイスで動作するラッパーとしての役割を果たしている。というわけで、ここではChocolateyを含むプロバイダーをPackage Managementに設定する。

基本的なコマンドは以下のようになる。

Install-PackageProvider 'Chocolatey' -Force

成果物のinstall_package_providers.ps1ではよく使われるものとして4つのプロバイダーが指定されているけれども、NuGetはPowerShellGetが依存しているのと、ChocolateyとChocolateyGetはいずれもChocolateyのプロバイダーなので、実質2つである。もっと言うなら、PowerShellGetはPowerShellのモジュールを集めたプロバイダーだけれども、PowerShellを頻用するのでもなければ不要かもしれない。

Package Managementを使ってアプリケーションをインストールする

プロバイダーを設定したら、あとはChocolateyパッケージを指定してインストールすれば良い。パッケージの検索はChocolateyのサイトからでも良いし、コマンドでも行える。

Find-Package 'Chrome' -ProviderName 'ChocolateyGet'

あとは以下のコマンドでインストールすれば良い。この辺りは他のパッケージ管理ツールと大体同じだ。

Install-Package 'GoogleChrome' -Force -ProviderName 'ChocolateyGet'

ただ、ChocolateyもChocolateyGetも結構な頻度でコケる上に、再試行もしてくれない。それってパッケージ管理システムとしてどうなのか…?というツッコミはありつつも、成果物のinstall_packages.ps1では自前で再試行できるようにスクリプトを組んで何度かコケても完走するように改善してある。

ちなみに、ATOKやTablePlusのようにChocolateyに登録されていないパッケージもそれなりに多いので、その場合は手動でインストールするなり、自前でスクリプトを書く必要がある。この辺りはMacだとHomebrewにもMac App Storeにも登録されていないパッケージは稀なので、Windowsはちょっと面倒だなとは思う。

まとめると、パッケージインストールの流れとしては、コケる頻度がまだ低いChocolateyGetで検索、無ければChocolateyで検索、それでも無ければ自前という流れが良いと思われる。

レジストリファイルを使ってWindows設定をカスタマイズする

ここからは少し毛色の違う処理として、Windows設定のカスタマイズを行う。これはMacで言う所の defaults コマンドのようなものだと思っておけば良いだろうか。

Windowsでも、正に defaults コマンドのような形で設定を1行ずつ実行していくこともできる。実際、近年のカスタマイズ関連記事ではそちらの手法を紹介されることが多い。ただ、個人的には大量の設定をカスタマイズするので1行ずつ地道に書いていくのは億劫だと思っている。というわけで、旧来からの手法ではあるがレジストリファイルを使うことにしている。レジストリファイルの良い所は、Windows公式ツールであるレジストリエディターや各種サードパーティーツールでのインポート・エクスポートに対応していることだ。

具体的な手順としては、僕の場合はRegistryChangesViewというレジストリの差分チェックツールを使い、設定画面等で変更する前後での差分を取って、レジストリファイルにエクスポートするという手法を採用している。あとは、適当にググって当たったカスタマイズ記事を参照しても良いのだけれども、その場合は記事の内容が古くてきちんと動かないようなこともあるので注意されたい。原則としてレジストリを直接弄るのは自己責任ということは肝に銘じておくべし。

ちなみに、成果物に載せているレジストリファイルはWindowsの設定とコントロールパネルの項目を概ね網羅しているので、参考になれば幸いだ。ただ、デフォルト値とか各設定の詳細まで説明し始めるとそれだけで独立したシリーズになってしまうので、そのあたりはカスタマイズ専門のサイトにお任せしたい。

そしてWSL2の構成管理へ

ここまででWindows側は一通り設定できたので、次の記事はいよいよ最終回、WSL2配下のUbuntuの構成管理ついて触れていきたい。

aikawame.hateblo.jp

【新パッケージ】Windows 10 Home 日本語版/May 2019 Update適用/パッケージ版

【新パッケージ】Windows 10 Home 日本語版/May 2019 Update適用/パッケージ版

  • 発売日: 2019/09/13
  • メディア: USBメモリスティック