UEFI bootでディスクのSerial Noを変えて起動しなくなったら。

 検証用に大量の物理・仮想マシンを並べたりする時によく使われる、クローニングという手法。
 仮想マシンだと特に簡単にコピー出来るので、さくっと出来て嬉しいことが多い反面、気をつけなくてはいけないこともあるワケで。
 そんな中には、従来のBIOS環境だと気にする必要が無かった、UEFI環境ならではのネタもあるワケです。

 そんな中で今回ネタにするのは、割とありがちな「ディスクのシリアルID書き換えたら起動しなくなった」という話。
 自分も初めてやらかした時は「あちゃ~」という感じだったので。

 ◇

 まず、前提。

 状況:

 UEFIで起動する環境でブートドライブのシリアル番号を変更すると起動しなくなる。

 解決策:

 Step1:bcdbootで修理する。
 Step2:それで駄目なら、bootrecで修理する。

 当方が色々やらかした範囲では、ブートドライブのシリアル変更のみならbcdbootの自動修復で100%回復している。
 何も考えずに直してくれるのでこれが一番ラク。
 但し万が一これがコケた時に備えて、後で本来正当なbootrecのやり方もメモっておく。

 ◇

 以下、まずはbcdbootでやる方法。

 1:
 起動がコケてるマシンをWindows Install DVD(またはUSBメモリ等)で起動し、コマンドプロンプトを開く。

 システムによってはInstall DVDよりも起動優先度が高いデバイスが存在する為、必要ならばBIOS(UEFI)画面に入って起動優先度を変更する。
 DVDから起動したらインストールオプションから左下「コンピューターを修復する」を選択し、「トラブルシューティング」→「詳細オプション」→「コマンドプロンプト」。

 2:
 diskpartでWindows SystemのあるボリュームにC:を割り当てる。

 select disk 0
 → list volume
 → 一覧からWindows本体が入っているパーティションの番号をチェックし、select volume 番号
   (例えばselect volume 3)
   大抵の場合Infoに「ブート」と入っている
 → assign letter=C:
 → exit

 3:
 bcdbootでC:から起動するエントリを作成する。

 bcdboot C:¥Windows /l ja-JP

 4:
 DVDを抜いてシステムを再起動する。

 以上。
 実はこのうち3.のC:を割り当てる作業をせず、4.でオプション無のままでbcdbootコマンドを打つだけでも、結構な確率で起動する状態に戻せる。
 とはいえ時々コケることもあるので、ドライブレターを振っておいた方が幸せな模様。

 ◇

 それでは次に、bootrecコマンドを使う場合。
 以下の例は修復フルセット。

 1:
 起動がコケてるマシンをWindows Install DVD(またはUSBメモリ等)で起動し、コマンドプロンプトを開く。

 2:
 diskpartでWindows SystemのあるボリュームにC:を割り当てる。

 3:
 diskpartでBoot PartitionにF:を割り当てる。

 select disk 0
 → list volume
 → 一覧からBootパーティションの番号をチェックし、select volume 番号
   (例えばselect volume 0)
   大抵の場合Labelは「システムで予約済み」、Infoに「システム」と入っている
 → assign letter=F:
 → exit

 4:
 Bootフォルダに入ってbootrecコマンドで再構築する

 F:
 → 環境依存で以下のうちどれか、dir等でBootフォルダを探す
   cd ¥EFI¥Microsoft¥Boot
   cd ¥ESD¥Windows¥EFI¥Microsoft¥Boot
   cd ¥Boot
 → bootrec /fixboot
 → bootrec /fixmbr
 → bootrec /rebuildbcd

 5:
 DVDを抜いてシステムを再起動する。

 ◇

 以上、こんな感じでほぼ何とかなる筈。

 ちなみにマルチブート構成ではrebuildbcdで複数のWindowsが認識され自動でエントリに追加される筈だが、時々取りこぼしも出る模様。
 所詮自動修復なので、その辺りは手修正しましょうということで。

 あと、シリアル書換でなくトラブル対応でも良く出てくるbootrec /fixbootだが、そういう場合はWindows Systemの入っているボリューム(上の例だとC:)がActiveにマークされていることを確認することをお忘れ無く。Systemの入っているボリュームがActiveになっていないとこのコマンドはエラーになってくれるので。

Share

ヘンな名前のファイルが削除出来なくて困ったら。

 超絶今更っちゃ今更ネタなのだが、ちょっとドツボってる場面を見かけたので。

 WindowsのFileSystemAPIはまぁ実に実装がテキトーというか何というかなので、普通にエクスプローラやコマンドプロンプトからは扱えないファイル名のファイルも簡単に作れてしまう。
 まぁそれ自体は兎も角として、世間にはアンインストールしてもそういうファイルを残していくとか、挙げ句テンポラリファイルとしてそういうNGファイル名を使ってる為に、何かの拍子でテンポラリファイルが残ってしまうとアンインストールがエラーになるというヘボ実装のアプリが存在するのであり。

 で、そんなファイルを削除する方法。意外と知られていないらしいので、メモ代わりに書いておく。

 DOS窓を開いて「del ”¥¥?¥ドライブレター:¥フルパス¥ファイル名”」

 ※勿論「¥」は半角で。blogで半角にすると「\」に文字が化けてしまうので。

 ポイントは「¥¥?¥」の部分。
 これはWindowsが持つ特殊パスの一つで、通常使われるpath名展開・正規化エンジンをバイパスするもの。
 なので、通常は正規化されてしまい手が出せなくなるヘンなファイル名やフォルダ名も指定出来るようになる。

 逆に言うと、カレントパスを示す「.¥」等の特殊表記、パス記述での区切り記号(¥)の重複や代替区切り文字の使用(/)等は全てこの正規化エンジンが展開しているので、この指定方法を使うと全てNGになる。

 #なので、スクリプト等で厳密にパス名を検査したい場合に使ったり。

 ちなみに当方が見かけたのはCygwinをテキトーに入れてテキトーに削除しようとしてドツボってた場面。
 「REAME.」(←このファイル名の最後の「.」が問題)なるファイルが残ってしまい、エクスプローラから削除出来なくなる模様。

Share

Active Directoryのドメイン名を変更してみる(注:とってもやりたくない)。

 タイトルがアレだが、本音でもある。

 WindowsのActive Directoryは一応ドメイン名の変更がサポートされているし、必要なツール一式もWindowsに標準で入っているので作業が出来ない訳ではない。・・・が、本音ではやりたくないのよコレ、大体何か起こるし。

 ということで、今回は取り敢えず自分がやった作業記録っぽいものを以下に。
 日本語で手順一式が書かれたページはあまり無いようなので、もしかしたら誰かの役に立つかも、的なノリで。

 ◆事前準備

 1◇兎に角、全てのAD間のレプリケーションが正常に走っていることを確認する。

 個人的な経験からして、見落としがちなのが、片方向はOKだが反対方向はNGというパターン。
 以下のコマンド、全てのサーバでレプリケーションが常時正しく行われているかどうか確認しましょう。

 repadmin /showrepl [ADサーバ名]

 もし「失敗しました。」なんて出ている場合で、且つ「ネットワークが物理的に切れていない」「名前解決がコケてない」となると、大体はRPC絡みでトラブっているので、その場合は取り敢えずパスワードリセットで。

 netdom /resetpwd /Server:[サーバ名] /UserD:[ドメイン名]¥[ドメイン管理者名] /PasswordD:[パスワード]

 ADサーバの中に1箇所でもレプリケーション不良があった場合、一見正常に見えるサーバも含めて全てのサーバでパスワードリセットをかけた方が良い模様。というか、そうしないとレプリケーションが復活しなかったことも。
 で、パスワードリセットが正常に働けば、止まっていたレプリケーションが流れ始める筈なので、一休みしてから再度repadminでステータスを確認すればOKの筈。

 ・・・これで駄目だと結構面倒臭い、というかそもそもADが危険な状態の可能性が高いので、ドメイン名変更云々の前に現ドメインを修復して健全にしてからね、と。

 2◇可能であればGC(グローバルカタログ)をプライマリの1つに減らす。

 GCのレプリケーションは時間がかかるせいかどうか、GCが複数ある状態での作業だと思わぬエラーが発生したりする確率が高い「気がする」。
 なので、この作業を始める前にプライマリの1つ以外は全てGCの役割を外し、作業が終わってたら再度GCに設定すれば良い・・・と「思われる」。

 #動作原理だけ考えれば、レプリケーションさえ常時問題無いならばGCの設定がど~かなんて一切関係ありませんが、という話の筈なのだけど。

 ◆作業開始

 1◇現在の設定のエクスポートとリストの修正

 rendom /list

 このコマンドを打つとカレントの下にDomainlist.xmlというファイルが作成されるので、コレを適当テキストエディタで開く。

 <DNSname>現在のADドメイン名</DNSName>
 <NetBiosName>現在のADドメイン名のNetBIOS名</NetBiosName>

 という項目が複数あるので、このADドメイン名とNetBIOS名を変更後のものに書き換える。
 ちなみに

 <NetBiosName></NetBiosName>

 という風に項目があるが値が入っていない箇所はそのまま放置でOK。

 2◇新ドメイン名のロードと同期

 rendom /upload

 これで、現在のADサーバに変更された設定がアップロードされる。

 ♯と同時にドメイン名変更用の特別モードに入るので、再度設定変更をアップロードすることは出来なくなる。

 repadmin /syncall /e /d /P

 これで、全てのADサーバに変更された設定を同期させる。

 但しこれ、/Pが付いているので「同期要求」であることに注意。
 片方向のレプリケーションが正常で反対方向のレプリケーションがエラー、なんて状況だと、実はレプリケーションエラーなのにこのコマンドでエラーが出なかったりする。理由は簡単、同期要求だけは正常に伝達出来ているので。
 なので、先程も出した /showrepl コマンドできちんと同期出来ていることを確認しましょう、と。

 3◇更新準備と更新開始

 設定同期が完了したら、以下のコマンドで更新準備開始。

 rendom /prepare

 ローカルはすぐ終わるだろうが、リモートサーバ等ではたまに待たされることも。
 また、レブリレーションが終わっていなければ当然エラーになるので、細い回線越しのサーバがあるような環境では少し待ってあげるのも吉。
 ちなみに、何度コマンド打っても特に問題無いですよ。

 そして、全てのサーバが準備完了なったら、全てのADサーバが自動再起動しても問題無いことを確認して以下のコマンドでアップデート実行。

 rendom /execute

 エラーが無ければ自動的に全てのADサーバで再起動がかかります、はい。

 4◇設定修正

 ポリシー周り等、自動で更新されない箇所を修正しましょう。

 gpfixup /olddns:古ドメイン /newdns:新ドメイン
 gpfixup /oldnb:古ドメイン /newnb:新ドメイン

 ここで一旦、再び全てのADサーバを再起動。

 5◇DNS名修正

 プライマリDNSが自動で修正されないことがあるので、その場合は手動で修正する。
 GUIから新ドメインの前方参照ゾーンを「Active Directory統合」で作成。

 新ドメイン
 _msdcs.新ドメイン

 ゾーンさえ作成すればあとはADが勝手にレコードを作ってくれるし、セカンダリDNS以降はまぁ待っていれば複製されるかと。
 新ドメインのゾーンが作成されていることを確認して、ここで更に全てのADサーバを再起動。

 再起動後、既に用済みの旧ドメインの前方参照ゾーンは削除する。削除完了後再度再起動。

 ・・・何度も再起動していていい加減にしろ的な感想も出てくると思われるが、この辺りはホスト名他色々書き換わっている関係で、面倒でも素直に再起動した方が良い模様。省略すると後で「アレこれ反映されてない」的な場面に出くわすことも。
 また、再起動してから実際に新しい設定が反映され始めるまで、最低でも10分程度は待った方がいいというも当然ということで。

 6◇ホスト名修正

 再起動&反映待ち完了後、「フルコンピュータ名」が

 サーバ名.新ドメイン

 に正しくなっていることを確認。普通は修正されている筈だが、もしなっていなければ修正する。
 例によって「コンピュータ名/ドメイン名の変更」から「詳細」ボタンを押して「このコンピューターのプライマリ DNSサフィックス」を書き換え。

 7◇後片付け

 AD上のゴミ片付けコマンドを入力。

 rendom /clean

 特に問題が無ければ、一連の作業完了コマンドを入力。

 rendom /end

 これでADがドメイン名変更用の特別モードから通常モードへ移行するので、作業完了、と。

 ◆クライアントは

 入り直すタイミングで新ドメイン名が反映される。
 但しクライアントキャッシュ上では旧ドメイン名が残ってしまっているので、変更直後の最初のログインだけは、電源投入直後の表示されるログインユーザー履歴からはログイン出来ない。

 ◆◆◆

 ・・・まぁこんな感じですか。

 作業として大したことは無いのだが、うっかりレプリケーションエラーが出てしまうと変更作業自体が止まってしまうので大変ですな。

 それでは、今回はこんなところで。

Share

たかがファン、されどファン。

 最近立て続けにアレな状況に遭ったので、こんなこともあるんだよ的雑談投下。
 一言でまとめると

 「安物ファンと故障ファンは即交換で」

 ・・・いやぁホントに。

 ◇

 事例1:故障ファン、HDDを死の一歩手前まで追い込む。

 犯人 :故障したHDD冷却ファン(40mm)、リムーバブルケージ付属
 被害者:HDD
 被害 :I/O停止、HDD内容不整合に伴うデータ損失

 リムーバブルHDDケージに付いている冷却ファンが逝ってノイズ源と化し、電源ラインを辿って悪さをした例。
 HDDはI/Oがハングした上、大人しく停止しているかと思いきや何故か一定間隔でシーク音がするという謎挙動に陥り、電源OFFまでずっとそれが続くハメに。
 そして問題のファンを取り外し、再度電源投入してみたところ、HDDは復活したものの、SMART値がとんでもないことに。

 ◇

 事例2:経年劣化ファン、システムを落とす。

 犯人 :経年劣化したシステム冷却ファン(120mm)
 被害者:チップセット(Intel X3420)、HDD
 被害 :稼働中のフリーズ、BSOD、HDD内容不整合に伴うデータ損失

 マザー上のファン端子に接続されていたファンが逝ってノイズ源と化し、電源ラインを辿って悪さをした例。
 CPUはVRMの向こう側なのでまだマシなのだが、チップセットとHDDはモロに攻撃を喰らってしまった。
 Windowsサーバとはいえ最近は滅多に青画面なんて出ないからね・・・久々に見たよコレ。

 しかもHDD側のSATA IFがハング状態で、単なるRebootをしたところ肝心のデータ用HDDがBIOSからも見えないという非常に心臓に悪い事態に。
 幸い物理電源OFF→ONで復活というパターンだったが、これホントにビビりましたで。

 ちなみに取り外した劣化ファン、指で軽く弾く程度ではフィンが全く動かないというレベルまで悪化してましたとさ。
 それでも電源繋ぐと一応(規格より大幅に遅いが)回りはした(カクカクだけど)のだから・・・そらねぇ。

 ◇

 事例3:安物ファン、RAIDを瀬戸際に追い込む。

 犯人 :安物ファン(92mm)
 被害者:HDD、RAIDコントローラ
 被害 :精神的苦痛

 HDD冷却の為に「良かれと思って」追加されたファンが悪さした例。
 これも電源ノイズだが、特に劣化した訳ではないというのがタチが悪い。

 実際、アキバ等で普通に売られているファンの中にも、新品購入直後からかなりのノイズ源である商品が存在する。
 言ってしまえば「安物」なのだが、残念ながら普通に名が通っているブランドのあまり安くない製品でも酷いモノが存在するのは事実。
 そして、こういうファンがあまり電源ノイズに配慮されていなかったり、既に色々と厳しい状態にある環境に接続されたりしてしまうと、「一線を越える最後の一押し」になってしまうことがある。

 ちなみに今回は何が起こったかというと、

 1・RAIDで冗長性検査が走る
 2・不整合が発見されリビルド開始
 3・リビルドが妙に遅い、しかも時々止まっているように見える
 4・通常(過去実績)の3倍以上の時間がかかってリビルド完了

 ということで。
 念のためHDDのSMARTをチェックしたところCRC Errorの数字がトンでもないことになっていた上に、RAIDコントローラ側のログにもIO Timeoutが多数出ていたので、コントローラのIOリカバリが踏ん張ってくれなかったらアレイ崩壊もあり得たという状況。

 ◇

 以上3例、何れもたかが(高くとも)¥2,000程度のファンのせいで心臓に悪かったという実話。
 ブラシレスとはいえモータをナメるな、ということで。

 今回最後の「特に劣化していないファンでも障害の原因になる」というのはケースとしては結構レアな話ではあるが、ゼロではないのもまた事実。
 こういう場合、勿論最良なのはSANYO等の「ノイズにも配慮された一流メーカ品」ファンに交換することなのだが、応急処置としてはファン電源を取るコネクタを変えてみるというのも結構アリだったりする。同一電源ラインに接続されてる構成部品がたまたま「ノイズの影響を受け易い」ものだとアウトだが、他のコネクタだとギリギリセーフとか。

 とはいえまぁ新品状態で「結構酷い」ものも、大抵の環境ではあまり問題なく動いているというのが実際なので、神経質になり過ぎる必要も無いとは思いますよ。
 そりゃまぁ最初っからあちこちで問題起こすようだとさすがに商品として厳しいしね。

 ♯電源が弱ってたり激安品だったり、はたまたマザーが激安だったりするとリスクは上がるでしょうな。

 ◇

 一方、最初の例ではちっちゃなファンが強烈ノイズ源になってしまったという話。
 最近ではあまり見ないがチップセット冷却用ファンなんかも劣化すると相当なことになることが多い。

 そして、今回発生したリムーバブルなHDDケージのファンについては、少なくとも40mmについては当方が普段使っているRATOC製を含めてまともな品質のファンが付いている製品を見たことはない上に、HDDの直近に接続されていることもあり、非常に「危険」な部類。
 少しでも動作音が大きくなったり、何か妙な音がするようになったら速攻でメンテか交換が必要です、はい。

 ♯ブラシレスファンで異音の出始めぐらいだと単なる「油ぎれ」のことが多いので、オイルと注入テクを持っているなら注油だけで復活することが多い。

 ◇

 最後に、半田ごてを握れる人向けの話。
 ファンと並列に、出来ればファンの直近に0.1μ程度のセラコンと100~470μ程度の無極性電界コンを接続してやると電源ラインへのノイズ流出をかなり抑えることが出来る。
 当方は別にHTPC指向でもなんでもないが、誤動作する程のノイズを喰らってはたまらないので。

 ♯安物マザー&ヘタレ電源の場合、同じくノイズ絡みの話でUSB電源ラインに同様の小細工をするとUSB接続が安定するなんてことも。

 ちなみに、このテのノイズ対策として希に1000μF超の無極性電界コンを接続するなんて話を見かけるが、これにはちょっと注意が必要。
 大容量がノイズ抑制に効くこともある一方で、あまり大きいとスイッチング電源に対する容量性負荷がどうとかいう話も出てくるので。
 その辺りの話が分からない人は470μFぐらいに抑えておくのが平和ですよ。

 ♯ニチコンMUSE・ESで25V470μFだと単価¥70程度、お手頃価格でも効果はそれなりに期待出来ます。

Share

Windows Server 2012「記憶域」のGUIが全く使い物にならない件について。

 さて、当方も最近関わることも多くなってきたWindows Server 2012。
 Windows Core(Kernelとその周辺)の出来は悪くない、Hyper-Vも使い物になるようになってきた、けどまぁ兎に角UIについてはいつまで経っても慣れない、ホント最低ですわ。

 そんなWindows 2012だが、目玉機能の一つとして「記憶域」というヤツがあったのを覚えている方はどれくらい居ますかね。
 正確にはWindows 8にもあります、機能制限されていますが。

 で、この「記憶域」、確かMicrosoftはそれなりに推していた記憶があるし、お題目だけ見ると結構魅力的なんで、ストレージ絡みの話が出てくると思い出したかのように、或いはホントにふと思い出して、「どうなの」的な話が出ることがあるのですが。

 「オモチャですが」

 現時点ではこれが答えです、本当に。
 アイデアは他のブロックストレージと同じなのに、何でここまで駄目な実装なんだろうかと。

 とはいえ、腐ってますが一応ブロックストレージな訳でして。
 コア部分の出来もイマイチながら、それに輪をかけて酷いのがGUI。
 おかげで、実際にディスクが故障した際にGUIからは修復もままらないという、トンでもない事態になっています。

 #前ネタでも書いたが、Windows8/Windows Server 2012シリーズの共通コンセプトは「クソGUI」だと本気で信じてます。

 とはいえ、実はPowerShellを使えば多少は何とかなることはあんまり知られていない模様。
 他にも、「故障したディスクを交換するには同一容量以上のディスクでなければならない」という言い方がよくされますが、これも正確な表現じゃないですよ。
 正確には

 「故障したディスクに格納されていた論理領域+α以上の容量が物理冗長性が損なわれない複数ディスクの合計であれば良い」

 ということです。

 ということで、以下に「運用上最低限必要なのに何故かPowerShellが必須な操作」について、少しメモっておきます。
 どうしても「記憶域」を使わないといけないという事態に陥った場合にでも参照して下さい。

 1◆論理ディスクの修復

 GUIからだと何故か全く動かずエラーが消えないことが往々にしてある。あと、自動修復が発動しないことも。
 そういう時は、PowerShellから

 Repair-VirtualDisk -FriendlyName “論理ディスク名”

 で既存の論理ディスクを直ちに修復開始します。
 ちなみに、これでも駄目な時は基本的にその論理ディスクは壊れてます。

 2◆故障ディスクの削除

 何とびっくり、故障したディスクの取り外しすらGUIからだとまともに出来ないのがMicrosoft Quality。
 延々とエラー表示が残ってしまい、GUIからは復旧出来なくなることも。

 以下、その時の対処法。

 a) 既に見えなくなっている幻のディスクに対して、Set-PhysicalDiskで取外フラグを立てる。

 Set-Physicaldisk -FriendlyName “物理ディスク名” -Usage Retired

 b) Repair-VirtualDisk で既存の論理ディスクを修復する。(1と一緒)
 c) 幻のディスクを記憶域から削除する。

 もっと詳細に手順を見たい方は「もっと読む」以下に画像付で貼っておきます。
 あと、c)は基本的にGUIで出来ます。駄目な時はPowerShellのRemove-Physicaldiskで。

 3◆縮小再構成

 論理ディスク容量が当初予定より小さくなってしまった等で、物理ディスクを減らしたい時に。
 世間ではこれが出来ないと思われているフシがあるが、GUIからは出来ないだけでPowerShell使えば出来まっせ。

 a) 取り外したいディスクに対して、Set-PhysicalDiskで取外フラグを立てる。
 b) Repair-VirtualDisk で既存の論理ディスクを修復する。
 c) GUIを使用し、物理ディスクを記憶域から削除する。

 手順は故障時と同一で、違いは実在するディスク相手に操作することだけです。

 ちなみに物理ディスク容量が不足しているとa)かb)で失敗するので諦めて増やしましょう。
 記憶域の容量の割り当て方には意外と無駄が多いようで、そんなにガリガリには削れないです。

 ◇

 とまぁ、今回はこんな感じで。

Continue reading “Windows Server 2012「記憶域」のGUIが全く使い物にならない件について。”

Share