Natz's Digital 漂流記

Windows 7 RC 自動シャットダウン開始

2010-03-06T15:34:51Z

妻のマシンを Windows 7 化して (グラフィックス・カードは Aero が使えず、オンボードのオーディオは存在自体が認識されず、それぞれ必要最低限クラスのグラフィックス・カードとサウンド・カードを買ったりして少々手間取った) アレコレいじっていた先日、Windows 7 RC の強制シャットダウン措置が始まる 03/01 を過ぎていることに気が付いた。そこで「どれ、どうシャットダウンされるのか体験してみるか」と、VirtualBox 上の仮想マシン (以下 VM) の Windows 7 RC を起動した。 ]]>

いきなり海賊版呼ばわり

しばらく放置すると「Windows を使い続けるには、ファイルをバックアップして製品版をインストールし直せ」と言う旨のメッセージが表示され、さらに放置すると、VM がシャットダウンされた。問答無用でシャットダウンかと思っていたが、事前にメッセージを表示して警告してくれるのは、冷徹になり切れていないのか。

いずれにせよ 6月以降に起動するとどうなるのか興味があるので、RC の VM は、もうしばらく生かしておくとしよう。

最後に一つ、古い PC に Windows 7 をインストールして音が鳴らずに困っている方向けの情報提供。「とりあえず鳴りゃいいんだよ」と特にこだわらないのであれば、Sound Blaster 5.1 VX PCI SB-5.1-VX が安くて入手しやすい (本エントリー執筆現在)。Windows Update からダウンロードできるドライバー "Creative - Other hardware - SB 5.1 VX" で動く。

Windows 7: C:\Program Files フォルダーを別ドライブに移動 (x64 対応半自動化版)

2010-03-01T17:40:19Z

以前のエントリーで Windows 7 の C:\Program Fiels フォルダーを別ドライブに移動させる方法を紹介したが、本エントリーでは以前の加筆修正をまとめて「x64 対応半自動化版」とし、改めて 32ビット及び 64ビット環境双方でより汎用的に使える方法を紹介する。
]]>

※ 注意 ※

以下の作業で操作を誤ると、OS に回復不能な損傷を与えて Windows の再インストールが必要になる他、データを失う等の副次的被害が発生する可能性があります。本ページで紹介するスクリプトは筆者の環境で意図通りに動作することを確認していますが、全ての環境において正常動作を保証するものではありません。また処理内容を理解せずに改変及び実行することは、非常に危険です。本ページの内容を参考に行った作業によって何らかの損害を被った場合も筆者は一切の責任を負いませんので、お試しになる場合は、くれぐれも自己責任でお願いします。

想定する環境は Windows 7 Ultimate の 32ビット版及び 64ビット版。ProgramFiles フォルダーの移動前のパスを C:\Program Files、移動先のパスを D:\Program Files とし、文中では実パスに加え、それぞれ「旧 ProgramFiles フォルダー」、「移動先 ProgramFiles フォルダー」とも表記する。表示フォントによってはパス区切り記号の "¥" がバックスラッシュ (半角＼) になるので、"/" と間違えないように注意。

作業の流れは以前と変わらず、次の通り。

ローカル Administrator の有効化とパスワード設定。
ProgramFiles フォルダーをコピー。
レジストリの書き換え。
旧 ProgramFiles フォルダーの削除とシンボリック・リンク作成。
移動先のアプリケーションの動作確認。

1. ローカル Administrator の有効化とパスワード設定

まず、ローカル Administrator を有効化する。任意のユーザーでログオン後、スタートメニューの「全てのプログラム」 → 「アクセサリ」 → 「コマンドプロンプト」を右クリック → 「管理者として実行」でコマンドプロンプトを管理者権限で起動し、次のコマンドを入力する。

> net user Administrator /active:yes　← Administrator を有効化

> net user Administrator 　← パスワードを設定

> logoff　← ログオフ

管理者権限がない場合は、「システムエラー 5」「アクセスが拒否されました」等のエラーが発生する。コマンドが正常に終了したら、ログオフして Administrator でログオンし直す。

2. ProgramFiles フォルダーをコピー

次に旧 ProgramFiles フォルダーをコピーする。基本は xcopy コマンドに適切なオプションを与えて手動コピーだが、同じ作業を繰り返す可能性があるなら、バッチファイルでスクリプト化しておいた方が、ミスをするリスクを軽減できる。

以下のスクリプトは、旧 ProgramFiles フォルダーを所有権、アクセス許可設定、監査設定等を再現しつつ、移動先にコピーする。誤って実行してしまうことを防ぐため、Administrator 以外は実行できない (＝最後に飛ばされる) ようにしている。ファイル名は拡張子が ".bat" なら何でも構わないが、"hoge.bat" にするよりは、例えば "MoveProgramFiles_2_Copy.bat" 等、処理内容を想像できる名前の方がいいと思う。

※ 03/05 追記
日本語環境に存在する "Program Files\Windows NT\アクセサリ" は同じ場所にある "Accessories" へのジャンクションだが、xcopy に /b オプションを付加しても参照先の実体がコピーされてしまう。この対策として "アクセサリ" を一度削除して、改めて同名のジャンクションを作成している。

@echo off

echo ### MOVING PROGRAMFILES: PHASE 2 ###
echo.

if not "%USERNAME%" equ "Administrator" (
    echo Only the Administrator can run this script.
    goto ERROR
)

rem User settings: START ==========
set FromDir=C:\Program Files
set FromDirX86=C:\Program Files (x86)
set ToDir=D:\Program Files
set ToDirX86=D:\Program Files (x86)
rem User settings: END ==========

:X86
if /i "%ProgramFiles%" equ "%FromDir%" (
    if exist "%FromDir%" (
        if not exist "%ToDir%" (
            xcopy /e /h /k /o /x /b /y "%FromDir%" "%ToDir%\"
            if exist "%ToDir%\Windows NT\アクセサリ" (
               takeown /f "%ToDir%\Windows NT\アクセサリ" /r /a /d y
               cacls "%ToDir%\Windows NT\アクセサリ" /t /e /c /g %USERNAME%:f
               rmdir /s /q "%ToDir%\Windows NT\アクセサリ"
               if not exist "%ToDir%\Windows NT\アクセサリ" mklink /j "%ToDir%\Windows NT\アクセサリ" "%ToDir%\Windows NT\Accessories"
           )
        )
    )
)

:X64
if /i "%ProgramFiles(x86)%" equ "%FromDirX86%" (
    if exist "%FromDirX86%" (
        if not exist "%ToDirX86%" (
            xcopy /e /h /k /o /x /b /y "%FromDirX86%" "%ToDirX86%\"
        )
    )
)

:END
echo.
echo Copying ProgramFiles directories was completed.
echo Replace paths in your registry as follows:
if /i "%ProgramFiles%" equ "%FromDir%" (
    echo   "%FromDir%" to "%ToDir%"
)
if /i "%ProgramFiles(x86)%" equ "%FromDirX86%" (
    echo   "%FromDirX86%" to "%ToDirX86%"
)

:ERROR
pause

コピーが完了したら、旧 ProgramFiles フォルダーと移動先 ProgramFiles フォルダーのプロパティ・ウィンドウを並べて、ファイルやフォルダーの数、合計サイズが正しいことを目視確認する。(03/05 追記： xcopy に /b オプションがなかった過去の記事を参考に実施した方は、"Phase 4" のスクリプトを参考に移動先 ProgarmFiles フォルダー内の "WindowsNT\アクセサリ" の所有権とフルコントロールを設定後に削除し、mklink /j で Accessories へのジャンクションを作成すると、同等の結果となる)

尚「ディスク上のサイズ」は、それぞれのフォルダーが存在するパーティションのクラスター・サイズ (＝アロケーション・ユニット・サイズ) によっては、一致しないことがある。前述の内容が正しければ、数値が違っていても気にする必要はない。

3. レジストリの書き換え

ProgramFiles フォルダーのコピーが完了したら、レジストリ中に存在する文字列 "C:\Program Files" を "D:\Program Files" に置換する。ただ該当箇所は大量に存在するので、Windows 標準の「レジストリエディター」でチマチマ置換する自信がなければ (僕は無理)、Registry Toolkit や RegGrep (32ビット環境のみ) 等の便利なツールを利用した方がいい。

Registry Toolkit を使う場合は、ツリー構造の "My Registry" を選択した状態でメニューの「Registry」 → 「Search of Replace in Registry」ダイアログを表示させ、"Settings" の "Match Case"、"Search/Replace In" の "Data" と "Value" のチェックを ON にして、「Replace」ボタンをクリックする (各項目名が何を指すのか不明な場合は、こちらのサイトが参考になる)。"Start In:" が "My Registry" 以外になっている場合はレジストリの全域をスキャンできないので、忘れずに確認する。ヒットした文字列を全て置換するには、最初に表示されるダイアログで「Replace Rest」ボタンをクリック。

尚、Registry Toolkit はシェアウェア (32ビット版/64ビット版各 $25.00、両方で $35.00。いずれも本エントリー執筆時点での価格) だが、今回限りの利用であれば、未登録状態でも目的は達せられる。もちろんそのまま使い続けたいと思えばライセンス購入を検討すればいいし、他に使い慣れたレジストリ編集ツールがあれば、そちらを使っても一向に構わない。

Registry Toolkit での置換

環境によっては 8.3形式の短いファイル名が使われている可能性もあるので、C:\PROGRA~1 を検索してみて、存在すれば D:\PROGRA~1 に置換する。

さらに、アプリケーション単位の INI ファイル等で旧 ProgramFiles フォルダーがフルパスで指定されている場合も不具合が予想されるので、移動先 ProgramFiles フォルダー内で文字列 "C:\Program Files" を検索する。その際はファイルの内容を検索対象に含めるため、事前に「フォルダーオプション」の「検索」タブにある「検索項目」で、「ファイル名と内容を常に検索する」を選択しておく。

クリーン・インストール直後の僕の環境 (＝ドライバー類も OS デフォルトのまま) では、8.3形式の ProgramFiles フォルダーのパスや、修正が必要な INI ファイルは見つからなかった。クリーン・インストール直後のように結果が予測できる単純な環境であれば、これらの検索は省略しても問題ないと思う。

旧 ProgramFiles フォルダーを指す全ての文字列置換が完了後、Windows 7 を再起動する。

4. 旧 ProgramFiles フォルダーの削除とシンボリック・リンク作成

旧 ProgramFiles フォルダーを削除する前には、所有権を奪ったり、アクセス許可設定を変更する作業が必要になる。HDD を別のマシンに接続したり、KNOPPIX 等の CD-ROM/DVD-ROM から起動して NTFS パーティションの操作が可能な Linux から削除する方法もあるが、Windows XP にはなかった便利なコマンドが使える Windows 7 では、バッチファイルでスクリプト化しておいて直接実行するのが確実で手っ取り早い。

以下のスクリプトは、takeown で旧 ProgramFiles フォルダーと 64ビット環境では ProgramFiles(x86) フォルダーの所有権を Administrator に設定し、cacls で Administrator にフルコントロール権限を与えてから rmdir で削除後、mklink で C:\ 直下に移動先 ProgramFiles フォルダーと、64ビット環境では ProgramFiles(x86) フォルダーへのシンボリック・リンクを作成する。旧 ProgramFiles フォルダー削除時に邪魔になるサービス IP Helper は処理前に停止させ、処理後に改めて起動させる。また前述のスクリプト同様、Administrator 以外は実行できない (＝最後に飛ばされる) ようにしている。

ここでもファイル名は何でもいいが、"MoveProgramFiles_4_Remove.bat" 等、処理内容を想像できる名前が望ましい。

@echo off

echo ### MOVING PROGRAMFILES: PHASE 4 ###
echo.

if not "%USERNAME%" equ "Administrator" (
    echo Only the Administrator can run this script.
    goto ERROR
)

rem User settings: START ==========
set FromDir=C:\Program Files
set FromDirX86=C:\Program Files (x86)
set ToDir=D:\Program Files
set ToDirX86=D:\Program Files (x86)
rem User settings: END ==========

net stop "IP Helper"

:X86
if /i "%ProgramFiles%" equ "%ToDir%" (
    if exist "%ToDir%" (
        if exist "%FromDir%" (
            takeown /f "%FromDir%" /r /a /d y
            cacls "%FromDir%" /t /e /c /g %USERNAME%:f
            rmdir /s /q "%FromDir%"
            if not exist "%FromDir%" mklink /d "%FromDir%" "%ToDir%"
        )
    )
)

:X64
if /i "%ProgramFiles(x86)%" equ "%ToDirX86%" (
    if exist "%ToDirX86%" (
        if exist "%FromDirX86%" (
            takeown /f "%FromDirX86%" /r /a /d y
            cacls "%FromDirX86%" /t /e /c /g %USERNAME%:f
            rmdir /s /q "%FromDirX86%"
            if not exist "%FromDirX86%" mklink /d "%FromDirX86%" "%ToDirX86%"
        )
    )
)

net start "IP Helper"
echo.
dir /a C:\
if exist "%ToDir%" (
    echo.
    set ProgramFiles
    set CommonProgramFiles
)

:END
echo.
echo Moving ProgramFiles directories was completed.

:ERROR
pause

シンボリック・リンクは、レジストリの編集不可能な領域に書かれているパス対策。旧 ProgramFiles フォルダーのパスで移動先 ProgramFiles フォルダーにアクセスできるようにするための仕組みで、シンボリック・リンクを作成しない状態では、デスクトップの右クリック・メニューの「ガジェット」が機能しなかった。とりあえず他には目立った不具合は見つからなかったが、作成しておいた方がよさそうだ。

5. 移動先のアプリケーションの動作確認

移動させたアプリケーションが正常に動作することを確認し、作業完了。

VMware ESXi 4.0 に物理 NIC を追加 (Dell PowerEdge 830)

2010-02-25T12:44:40Z

我が家の VMware ESXi 4.0 で構築した仮想化環境は、ネットワークの冗長化は考慮しておらず、ESXi が稼働する Dell PowerEdge 830 の NIC はオンボードの 1枚 (?) だけだった。しかし普段利用するネットワークとは完全に分離されたテスト用ネットワークが作れると何かと都合がいいので、NIC を追加することにした。

この手の PC パーツのいいところは、増設作業を密かに行えば、「また余計なモノ買って！」と妻に非難される恐れが少ないことだ。ケースの中に納めてしまえば存在が発覚することはまずないし、仮に 1本増えた LAN ケーブルに気付かれたとしても、最初から 2本だったと言い張ればいい。
]]> Intel PRO/1000 GT Desktop Adapter (PWLA8391GT) にした。

届いた PWLA8391GT を増設してみると、ESXi は vmnic1 としてあっさり認識してくれた。さすが Intel 製。これで裏 LAN を作るもよし、冗長化するもよし、幅が広がった。

「裏 LAN」新設

Windows 7 で LinkStation LS-WH2.0TGL/R1 に接続できない

2010-02-22T13:50:00Z

デフォルト状態の Windows 7 は、LinkStation LS-WH2.0TGL/R1 (以下 LS-WHGL) の共有フォルダーのマウントに失敗する。と言うより LinkStation にアクセスすらできず、共有フォルダーを一覧することができない状態になる。

これは Vista と旧バージョンの Samba 間でも発生していた「LAN Manager 認証レベル」の設定値に起因する問題で、Windows 7 でもローカルセキュリティポリシーで設定を変更するかレジストリを直接編集して、認証レベルを下げる必要がある。BUFFALO でも当然この問題は認識されていて、「ファイル共有セキュリティレベル変更ツール」が公開されている (昨年 10月にリリースされた Ver.1.10 からは Windows 7 にも対応)。

このツールで今回の不具合を解消できることは検証したが、デフォルト状態の Windows Vista/7 が接続できないのは、LS-WHGL と言うより、旧バージョンの Samba に対して。Samba をファイルサーバーにしている環境でも、Samba のバージョンによっては同様の現象が発生するはずなので、前述のツールは使わず、より汎用的な方法で解決してみる。
]]>
この結果変更されるのは、レジストリの "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa" にある LmCompatibilityLevel で、Windows 7 のデフォルトでは「未定義」となっている「LAN Manager 認証レベル」とレジストリ (DWORD 値) の対応は、次の通り。

* 0: LM と NTLM 応答を送信する
* 1: LM と NTLM 応答を送信する (ネゴシエートした場合 NTLMv2 セッションセキュリティを使う)
2: NTLM 応答のみ送信する
3: NTLMv2 応答のみ送信する
4: NTLMv2 応答のみ送信する (LM を拒否する)
5: NTLMv2 応答のみ送信する (LM と NTLM を拒否する)

LS-WHGL では "0" か "1" に変更するとアクセスできるようになり、他の環境では "2" でも大丈夫かもしれない。

ただしこの操作は、互換性と引き換えにセキュリティ・レベルを落としていることを認識しておく必要がある。"0" より "1" の方がマシだし、"2" で行ける環境ならその方がいい。

Windows 7 でも親指 Shift 入力

2010-02-18T14:55:13Z

僕はキーボードで文字入力をする際、「親指シフト」を長年愛用している。と言っても本物の親指 Shift キーボードを使う本格派ではなく、OS レベルでキーマップを変更し、通常のキーボードで右手の親指で押しやすい位置にある [変換] キーを [Shift] キーにしているだけだが。

サーバー (特に Case sensitive な UNIX 系) をいじったり、(X)HTML や CSS を手でタイプしたりプログラミング等をしていると、大文字・小文字が混在したアルファベットや記号をタイプする機会が多くなり、必然的に [Shift] キーの使用頻度が高くなる。そこで個人的には漢字変換には [スペース] キーを使うため全く無用の [変換] キーを [Shift] キーに変更すると、通常のキーマップではほとんど使わない右手の親指で [Shift] キーを押し続けながら他の指をフル活用することができるようになって、タイピング効率が格段に上がる。
]]> Windows Server 2003 Resource Kit (無償) に含まれるツールで、Windows 7 でもしっかり機能する。

Resource Kit をインストール後も、Resource Kit に含まれる個々のツールはスタート・メニューには登録されないので、インストール・フォルダーにある remapkey.exe を直接実行するか、スタート・メニューの「Windows Resource Kit Tools」→「Command Shell」で remapkey [Enter] とタイプし、RemapKey を起動する。RemapKey はレジストリを編集するので、いずれの方法も管理者権限が必要になる点に注意。

RemapKey の使い方は簡単で、「ベースキーボード」欄のキーを、「リマップキーボード」欄の置換したいキー上にドラッグ＆ドロップするだけ。左端の「保存・終了」ボタンで保存して Windows を再起動すれば、余計なサービスやツールが常駐することもなく、ログオン前の状態からこのキーマップが有効になる。

[変換] キーを [Shift] キーに変更

マニュアルによると、RemapKey によるレジストリの変更箇所は "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout" 以下に作成される Binary 値 "Scancode Map"。このエントリーを書き出しておけば、他の Windows クライアントに展開する際にも使える。

僕は上記に加え、[半角/全角] キーが持つ IME の ON/OFF 機能を、MS-IME の設定で [ひらがな] キーにも割り当てている。これにより右手の親指には、[Shift] キーの他に IME の切り替えと言う役目が与えられる ([半角/全角] キーの機能はそのまま)。

RemapKey ではなく MS-IME の設定で実現する理由は、他のユーザーの混乱を最小限にするためだ。キーマップを問答無用に変更してしまうようなカスタマイズは、ログオン前から有効になることからわかるように、他のユーザーにも及ぶ。主に自身で利用する PC であっても、他のユーザーがログオンする可能性がある場合は少々乱暴とも言えるので、常駐型のキーマップ変更ツール以外でユーザーごとに代替手段がある場合は、そちらで行った方がいいと思う。

Windows 7 で Samba ドメインに参加

2010-02-14T05:45:09Z

少し前に自宅の CentOS 5.4 上に構築した Samba ドメイン (+ OpenLDAP 2.3.43) の PDC を 3.3.9 → 3.4.5 にバージョンアップしたので、実機の環境を移行する予行演習として、VirtualBox 3.1.4 上の仮想マシン (以下 VM) に素の Windows 7 Ultimate をインストールし、ドメイン参加させてみた。実機に搭載するグラフィックス・カードの Aero 対応がわかっていて、他に検証が必要なハードウェアがなければ、無理にデュアル・ブート等の環境を構築する必要はない。

尚、VirtualBox で VM を作成する際は、ネットワークがデフォルトで NAT になっていることを認識しておいた方がいい。意図して NAT のままにする場合は問題ないが、デフォルトがブリッジの VMware シリーズ等に慣れていて気付かないと、ハマる可能性がある。
]]> 以前のエントリーと同様。しかし次のように変更箇所が減っている点に、Samba の進歩の跡が見える。

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters" 以下に値を追加。

DWORD： DNSNameResolutionRequired = 0
DWORD： DomainCompatibilityMode = 1

さて、上記設定で Samba ドメインに参加はできるものの、ドメイン参加直後に「このコンピューターのプライマリドメイン DNS 名を "" に変更できませんでした」とエラーが発生する。この現象は Windows 7 RC を Samba 3.3.x ドメインに参加させたときは発生しなかったような気がしないでもないが (イマイチ記憶が定かでない)、例えば Samba ドメイン名を "DOMHOGE" とすると、DNS サフィックスもそのまま "DOMHOGE" になってしまう。それじゃ困るだろと手動で変更しようとしても、同様に失敗する。

DNS サフィックス変更不可

英語版の同じ場面

この現象を回避するには、再び次のようにレジストリを編集して、DNS サフィックスを直接任意のドメイン名に変更してしまえば OK。元ネタはこちら。

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters" 以下の値を変更。

String: NV Domain = "example.local"

これでようやく、正常にドメインに参加した状態になる。

Samba の旧バージョンも含めて、より詳細な情報はこちらのサイトが参考になる。バージョンによって、対応状況にバラつきがあるようだ。

concrete5: MySQL ユーザーのパスワード

2010-02-09T21:27:53Z

オープンソースの CMS ツール concrete5 (5.3.3.1.ja) で使う MySQL ユーザーのパスワードに "@" が含まれていると、インストール時に「データベースに接続出来ません」とエラーになる。確かに "@" はユーザー名とサーバー名の区切り記号でもあるので微妙な文字と言えるが、phpMyAdmin では、同じユーザー名とパスワードで DB にアクセスできる。
]]>

$dsn = DB_TYPE . '://' . DB_USERNAME . ':' . DB_PASSWORD . '@' . DB_SERVER . '/' . DB_DATABASE;

と格納され、concrete/libraries/3rdparty/adodb/adodb.inc.php 中の関数 ADONewConnection() で処理されて行く過程が追える。しかし "@" が通るように何とか頑張る、と言うのは本質ではないので、素直に「"@" を使わない」のが、スマートな解決策だろう。

とりあえず concrete5 で利用する MySQL ユーザーのパスワードは、危ない記号は避けて英数字だけにしておくのが無難か (concrete5 上のユーザーのパスワードは、"@" も利用可能)。

Windows 7: C:\Program Files フォルダーを別ドライブに移動

2010-02-07T21:42:25Z

■ 変更履歴

2010-03-02: より確実・汎用的な改訂版「x64 対応半自動化版」を公開。
2010-03-01: ProgramFiles フォルダーのコピー方法を変更 (xcopy コマンド)。
2010-02-28: 64ビット環境でのレジストリ置換方法を追加。
2010-02-20: ProgramFiles フォルダーのシンボリック・リンク作成を追加。

Windows 7 のシステム要件によると、インストール先ディスクの空き容量は 32ビット版で 16GB 以上、64ビット版で 20GB 以上とされている。Windows 7 Ultimate (32ビット版) をクリーン・インストールした直後の C: ドライブのディスク消費量は 7GB 程度 (ページファイルを除く) だが、このシステム要件は、様々なプログラムをインストールしたり、「ドキュメント」以下にファイルを溜め込んで行く使い方を想定してのこと。大容量化が進んだ最近の HDD なら「1.5TB の C: ドライブ一発」と言うこともできるので、旧型 PC にインストールする場合以外では、ディスク容量が問題になることは少なそうだ。ただし「1.5TB 一発」は男らしさのアピールにはいいとして、ディスク障害発生時のリスク、OS の再インストール、デフラグ時のコスト等を考えると、あまり効率的とは言えない。

一方、ディスクを適切なサイズにパーティショニングしたり別ディスクを用意するなどして、システム以外のソフトウェアを別ドライブにインストールする方法は、Windows のパフォーマンス向上、と言うより低下防止やリスク軽減策としてよく見られる。しかし各プログラムのインストール時に毎回別ドライブの任意の場所を指定していては、うっかり C: ドライブにインストールしてしまうこともあるし、プログラム本体は別ドライブにインストールできても、付属品が C: ドライブ (Program Files\Common Files 等) に入ってしまうこともある。こうした事態を防ぐには、Windows がデフォルトのインストール先として認識している、環境変数 ProgramFiles で定義されたフォルダー (以下「ProgramFiles フォルダー」) を移動させてしまえばいい。
]]>

※ 注意 ※

以下の作業で操作を誤ると、OS に回復不能な損傷を与えて Windows の再インストールが必要になる他、データを失う等の副次的被害が発生する可能性があります。本ページの内容を参考に行った作業によって何らかの損害を被った場合も、筆者は一切の責任を負いません。お試しになる場合は、くれぐれも自己責任でお願いします。

僕は Windows 9x 時代から XP まで (Vista は見送り)、自分で好きにいじれる PC は必ず OS インストール直後に ProgramFiles フォルダー別ドライブに移動させることにしている。そこで今後少しずつ進める予定の Windows XP → Windows 7 の段階的なリプレイスに備えて検証してみると、Windows 7 でも XP とほぼ同様の操作で、ProgramFiles フォルダーの移動ができることがわかった。しかし Vista 以降の Windows ならではの部分があるので、手順をまとめておく。(※ 03/02 追記：より確実・汎用的な改訂版「x64 対応半自動化版」を公開)

作業の流れは以下の通り。Windows 7 は Ultimate (32ビット版) で、インストール直後のデフォルト・ユーザー名を test、ProgramFiles フォルダー移動前のパスを C:\Program Files、移動先を D:\Program Files と仮定している。表示フォントによっては、パス区切り記号の "¥" がバックスラッシュ (半角＼) になるので、"/" と間違えないように注意。

ローカル Administrator の有効化、及びパスワード設定。
ProgramFiles フォルダーをコピー。
レジストリの書き換え。
旧 ProgramFiles フォルダーを削除。
移動先のアプリケーションの動作確認。

作業は Windows 7 のクリーン・インストール直後、できれば上記作業に必須ではないドライバー類もインストールしない状態の方が、手間とリスクを最小限にできる。

1. ローカル Administrator の有効化、及びパスワード設定

最強のユーザーであるローカル Administrator は、Windows 7 のデフォルト状態では無効になっている。まずデフォルト・ユーザー test でログオン後、スタートメニューの「全てのプログラム」 → 「アクセサリ」 → 「コマンドプロンプト」を右クリック → 「管理者として実行」を選択し、コマンドプロンプトを管理者権限で起動する。コマンドプロンプトでは次の操作を行う。

> net user Administrator /active:yes　← Administrator を有効化

> net user Administrator 　← パスワードを設定

> set ProgramFiles　← 環境変数を確認
ProgramFiles=C:\Program Files　← この段階では C: ドライブ

> set CommonProgramFiles
CommonProgramFiles=C:\Program Files\Common Files　← こちらも同様

※ 64ビット環境では上記変数名に "(x86)" を付加した環境変数も存在し、それぞれ " (x86)" を付加した値が設定されている。

コマンドプロンプトを管理者権限で実行していないと、「システムエラー 5」「アクセスが拒否されました」等のメッセージが表示される。最後の set コマンドは、この段階で Windows が ProgramFiles フォルダーとして認識している場所を確認している。

Administrator を有効化できたら test はログオフし、Administrator でログオンし直す。

2. ProgramFiles フォルダーをコピー

Windows 7 のデフォルト状態では、拡張子や隠しファイルが表示されていない。「フォルダーと検索のオプション」の「表示」タブの「詳細設定」で、次の設定を変更する。

隠しファイル、隠しフォルダー、および隠しドライブを表示する　→ 選択
登録されている拡張子は表示しない　→ OFF
保護されたオペレーティングシステムファイルを表示しない (推奨)　→ OFF

※ 03/01 修正
以前はエクスプローラー上でフォルダーをコピーする方法を記載していたが、アクセス許可設定や属性等が再現できない問題があるので、xcopy コマンドを用いる方法に変更。

フォルダのコピーは、管理者権限のコマンドプロンプトを開き、以下のように xcopy コマンドで行う。

> xcopy /e /h /k /o /x /b /y "C:\Program Files" "D:\Program Files\"

> xcopy /e /h /k /o /x /b /y "C:\Program Files (x86)" "D:\Program Files (x86)\"　← 64ビット環境の場合

上記オプションは、空フォルダーを含むサブ・フォルダー (/e)、隠しファイル及びシステム・ファイル (/h)、属性 (/k)、所有権及び ACL 情報 (/o)、監査設定 (/x)、リンク自体をコピー (/b)、上書き時の問い合わせなし (/y) を指定している。

※ 03/05 追記
ジャンクション "Program Files\Windows NT\アクセサリ" の扱いが不完全であることが判明したので、「x64 対応半自動化版」で修正。上記コマンドを既に実施してしまった場合は、手動修正も可能。

コピーが完了したら、エクスプローラーでコピー元とコピー先の各フォルダーのプロパティを開き、ファイルやフォルダーの数、アクセス許可設定等が正しくコピーできているか確認する。

3. レジストリの書き換え

このフェイズでは、レジストリ中に存在する "C:\Program Files" と言う文字列を移動先のパス、今回の例では D:\Program Files に置換する。単純だが記述箇所が大量にあるため、一つ一つ探し出して編集するのは現実的でない。

そこで利用するのが、レジストリ中の任意の文字列を検索・置換する RegGrep。Windows 9x 時代からお世話になっている便利なツールで、Windows 7 でも動く。(02/28 追記： RegGrep は 32ビット環境限定。64ビット環境では、Registry Toolkit の 64ビット版で意図通りの置換ができた。同ツールは 32ビット版もあり)

RegGrep を管理者権限で起動したら (UAC を無効化していなければ右クリック → 「管理者権限で実行」)、次のように設定して「置換」ボタンをクリックする。

検索文字列に "C:\Program Files"、置換文字列に移動先のパス、今回の例では "D:\Program Files" とそれぞれ入力 ("" は不要)。
「対象ルートキー」で HKEY_DYN_DATA キー (Windows XP 以降では存在しない) 以外を ON。
「オプション」で「大文字と小文字を区別する」を ON。

最初にヒットした文字列のダイアログで「すべて置換」ボタンをクリックすると、以後発見される文字列が全て置換される。

※ 02/28 追記
前述の Registry Toolkit を使用する場合は、ツリー構造の "My Registry" を選択した状態でメニューの「Registry」 → 「Search of Replace in Registry」ダイアログを表示させ、"Settings" の "Match Case"、"Search/Replace In" の "Data" と "Value" のチェックを ON にして、「Replace」ボタンをクリックする (各項目の名前にピンと来なければ、こちらのサイトが参考になる)。"Start In:" が "My Registry" 以外になっている場合はレジストリの全域をスキャンできないので、忘れずに確認する。ヒットした文字列を全て置換するには、最初に表示されるダイアログで「Replace Rest」ボタンをクリック。

Registry Toolkit での置換

尚、Windows XP では 8.3形式の短いファイル名が使われているので、この後 C:\PROGRA~1 を D:\PROGRA~1 に置換する。クリーン・インストール直後の Windows 7 では 8.3形式での記述は見つからなかったが、念のため検索しておいた方がいいかもしれない。僕の環境では存在しなかったが、もし C:\PROGRA~2 と言う記述が見つかっても、これは C:\ProgramData の 8.3形式表記なので、そうと知らずに書き換えてしまうと危ない。

さらに、アプリケーション単位の INI ファイル等で旧 Program Files フォルダーがフルパスで指定されている場合も不具合が予想されるので、移動先 Program Files フォルダー内で文字列 "C:\Program Files" を検索する。その際「フォルダーオプション」の「検索」タブにある「検索項目」で、「ファイル名と内容を常に検索する」を選択しておかないと、INI ファイルの内容を検索できない。

ちなみにクリーン・インストール直後の僕の環境では、8.3形式の ProgramFiles フォルダーのパスや、修正が必要な INI ファイルは見つからなかった。

ProgramFiles フォルダーを指す全ての文字列置換が完了後、Windows 7 を再起動する。

4. 旧 ProgramFiles フォルダーを削除

これまでの作業でスタートメニュー中にあるショートカットのリンク先も、移動先の ProgramFiles フォルダーに追従しているはずなので、不要になったはずの旧 ProgramFiles フォルダー (と 64ビット環境では ProgramFiles(x86) フォルダー) を削除する。Windows XP ではいきなり Administrator で削除できたが、セキュリティが強化された Windows 7 では (恐らく Vista も同様)、事前にひと手間必要になる。

旧 ProgramFiles フォルダーを削除するには、Windows 7 上で直接行う他に、C: ドライブがある HDD を別のマシンに接続したり、KNOPPIX (5.x で NTFS パーティションの操作が可能) 等の CD 起動 Linux を使う等、いくつか方法がある。ひとまず Windows 7 上で直接削除するには、以下の手順で行う。

まず Administrator でログオン後、コマンドプロンプトで次のコマンドを入力し、Windows の該当環境変数の値が移動先の ProgramFiles フォルダーに変わっていることを確認する。

> set ProgramFiles
ProgramFiles=D:\Program Files　← 値が移動先 ProgramFiles フォルダーに変更されている

> set CommonProgramFiles
CommonProgramFiles=D:\Program Files\Common Files　← こちらも変更されている

環境変数 ProgramFiles 及び CommonProgramFiles の値が移動先 ProgramFiles フォルダー以下に変更されている、即ち Windows が C:\Program Files の存在を忘れてしまっていることが確認できたら、以下の操作で所有権を奪う。旧 ProgramFiles フォルダーのプロパティを開き、「セキュリティ」タブの「詳細設定」ボタンで、「セキュリティの詳細設定」ウィンドウを開く。「所有者」タブで「現在の所有者」が TrustedInstaller になっていることを確認して「編集」ボタンをクリック。「所有者の変更」欄から Administrator を選択して「サブコンテナーとオブジェクトの所有者を置き換える」を ON にし、「OK」ボタンをクリック。

次にアクセス権限を変更する。同じ「セキュリティの詳細設定」ウィンドウで「アクセス許可」タブに移動し、「アクセス許可の変更」ボタンをクリック。「アクセス許可エントリ」欄の Administrators を選択した状態で「編集」ボタンをクリックし、「適用先」を「このフォルダー、サブフォルダーおよびファイル」、「アクセス許可」欄の「フルコントロール」を ON にして閉じる。「セキュリティの詳細設定」ウィンドウに戻るので、「子オブジェクトのアクセス許可すべてを、このオブジェクトからの継承可能なアクセス許可で置き換える」を ON にして、開いている全てのウィンドウを「OK」ボタンで閉じる。

これでようやく、旧 ProgramFiles フォルダー以下を好きに料理できるようになる。フォルダー削除時に「IP Helper が使用中で sqmapi.dll が削除できない」旨のメッセージが表示される場合は、タスクマネージャーの「サービス」タブで iphlpsvc を探し、右クリック → 「サービスの停止」で一時的に IP Helper を止めて、残ったフォルダーを削除する。削除後、改めて iphlpsvc を右クリックメニューで起動し直しておく。

参考までに、KNOPPIX を使う場合の手順を以下で説明する。

KNOPPIX で起動後、まずデスクトップに表示される HDD のアイコンをダブル・クリックして中身を確認する。旧 ProgramFiles フォルダーがあるデバイスを特定できたら、root 権限のシェルを起動 (メニューの「KNOPPIX」 → 「Root Shell」)。HDD アイコンをダブル・クリックした時点で、該当デバイス・ファイルが読み取り専用でマウントされているので、次の手順で削除する。(C: ドライブが /dev/sda2 と認識されていると仮定)

# umount /media/sda2　← Program Files フォルダーがあるディレクトリをアンマウント (読み取り専用)

# mount /dev/sda2 /media/sda2　← 再度マウント

# cd /media/sda2/

# rm -rf "Program Files"　← 丸ごと削除

僕が KNOPPIX 5.3.1 でテストした際は、Program Files/Windows NT/アクセサリの削除に失敗したが、Windows 7 に Administrator でログオン後、前述のアクセス権限云々の操作をせずに、いきなり削除できた。

尚、本エントリーの公開後、実はデスクトップの右クリック → 「ガジェット」のアイコンが表示されず、機能しないことに気がついた。改めてレジストリを検索してみると、"HKEY_CLASSES_ROOT\DesktopBackground\Shell\Gadgets\command" 等、管理者であっても編集できない部分に旧 ProgramFiles フォルダーのパスが残っている。旧 ProgramFiles フォルダーは既に削除してしまって存在しないので、機能しないと言うわけだ。

この不具合の解消のため、管理者権限でコマンドプロンプトを起動し、次のように C: ドライブ直下にシンボリックリンクを作成する。

C:\Users\Administrator> cd ..\..\　← C: ドライブ直下に移動

C:\> mklink /d "Program Files" "D:\Program Files"　← /d オプションでフォルダーへのシンボリックリンクを作成

C:\> dir　← 確認
　：
2010/02/19 21:31 Program Files [D:\Program Files]
　：

※ 64ビット環境では、同じ場所で "Program Files (x86)" → "D:\Program Files (x86)" のシンボリック・リンクも作成する。

UNIX 系 OS で多用するシンボリック・リンクだが、Windows でも作ることができ、同名で呼ばれているとは知らなかった。この mklink コマンドが導入されたのは Vista からで、XP でもリソース・キットに含まれる linkd コマンドで実現できるらしい。ひょっとするとレジストリを無理やり置換する必要はなかったんじゃないか、と一瞬考えたが、旧 ProgramFiles フォルダーを削除する前の段階で Windows 7 が移動先 ProgramFiles フォルダーを環境変数 ProgramFiles として認識していなければいけないので、やはり置換は必要だ。

5. 移動先のアプリケーションの動作確認

移動させたドライブのアプリケーションをスタートメニュー等から起動し、正常に動作することを確認して作業完了。

僕の環境では、上記作業で ProgramFiles フォルダーを移動させることができた。ただこれは Windows 7 をクリーン・インストールした直後の状態なので、既に各種アプリケーションがインストールされている状態では同じように行くとは限らないし、アプリケーションによっては、移動はできても正常動作しない可能性がある点には、ご注意いただきたい。

ProgramFiles フォルダーが移動できれば、あとはページファイルを専用パーティションに移動させたり、「ドキュメント」等の「個人用フォルダー」以下にある任意のフォルダーを別ドライブに移動させる等して、極力 C: ドライブを「軽く」する。「個人用フォルダー」以下のフォルダーは、右クリック → プロパティの「場所」タブで任意の場所を指定できるので楽だ。

Windows Server 2008 で Samba ドメインに参加

2010-02-06T04:45:57Z

今頃検証。Windows Server 2008 (Standard) は、デフォルト状態で普通に Samba 3.4.5 + OpenLDAP の Samba ドメインに参加できた。さすが Vista ベース。
]]>

CentOS 5.4, Debian 5.0: Facter 変数 lsb* が参照できない

2010-02-04T13:03:29Z

先日より多くの変数が利用できると言うことで Ruby ライブラリ Facter のバージョンを上げたが、我が家で稼働する 2台の仮想マシン (以下 VM) で、lsb* で始まる全ての変数が参照できていなかった。特に lsbmajdistrelease はバージョンアップの目的の一つでもあったので、使えないのは困る。

lsb* が参照できない VM は、CentOS 5.4 と Debian/GNU Linux 5.0 が各 1台ずつ。実機を含む他のマシンでは問題ないので、どうせ何かのパッケージが足りないんだろうと、他の VM と rpm -qa | sort を diff してみると、あっさり見つかった。
]]>

CentOS 5.4: redhat-lsb
Debian GNU/Linux 5.0: lsb-base, lsb-core, lsb-release

普段意識することはあまりないが、これも LSB (Linux Standard Base) プロジェクトの成果か。