Hyper-V環境下で動作するドメインコントローラーの時刻を合わせる

FSMOを別な物理サーバーへ移動したところ、ドメインに参加しているPCの時刻が頻繁にずれるようになってしまい悩んでいた。
昨日もHyper-V環境下で動作するDCの時刻を確認したら2分も遅れていた。先週の金曜日は殆ど合っていたのに。DCのW32TIMEサービスの設定も正しくしてあるはずなのに。

今日もネットでいろいろと調べていたら、Microsoft サポートに「Windows Server で権限のあるタイム サーバーを構成する方法」というのが掲載されていた。
http://support.microsoft.com/kb/816042/ja

ここには、「権限のあるタイム サーバーの時刻は、ハードウェアから収集するように構成することを強くお勧めします。権限のあるタイム サーバーをインターネット上のタイム ソースと同期するように構成した場合、認証は行われません。」と記載されていた。

これだ、と思い、早速その通りに設定してみたらドンピシャ(FSMOだけは物理サーバーにしてある)。

Hyper-Vの環境下で動作するDCの時刻が±1秒程度の精度で動き出した。この前までは、精度が上がっても数秒のずれがあったのに(Hyper-Vの環境下で動作するゲストOSの時刻は、その仕組み上、時刻が遅れ気味になる)。

ネット上では、NTPサーバーを使用することを推奨するような記事が多いが、FSMOの場合は自分自身のCMOSクロックを使用することが正しそうだ。と言うことは、Active Directry環境下ではNTPサーバーを使用することは無い???

Hyper-Vの環境で動作するDCの場合、統合サービスの時刻の同期はチェックを外さないといけないので、これも忘れないようにしないとね。因みにマイクロソフトでは時刻の同期について「物理システムである Hyper-V ホストが持つ時刻に、仮想システムであるゲスト OS の時刻を同期させるためのものですが、ホストとゲストの時刻を常に同じにすることを目的とはしていません。」と言い切っているので注意が必要だ。

SQL SERVERのインスタンスをコマンドで再起動する

SQL SERVERのインスタンスをコマンドで再起動したくてネットで調べたら、参考になるものが少なかったのでここに記しておく。

私の環境は、
Windows Server 2008 R2 SP1、SQL SERVER 2005 SP3で、SQL Server AgentとSQL Serverはサービスとして起動している。SQL Server AgentとSQL Serverをサービスとして起動していないとこの手順は有効ではないので注意。

手順は、
1) SQL Server Agentを停止
2) SQL Server インスタンスを一時停止。この一時停止がポイントだ。一時停止をせずにいきなり停止すると、実行中のアプリケーションがあった場合、インスタンスとの接続を切られて異常終了してしまう。これを防ぐために一時停止を行う。しかし一時停止でも、アプリケーション側で接続が切られた時に再接続するようなロジックを書いてないと異常終了してしまうのは一緒。
3) SQL Server インスタンスを停止。
4) SQL Server インスタンスを起動
5) SQL Server Agentを起動

コマンドにすると
net stop "SQL Server Agent (MSSQLSERVER)"
net pause "SQL Server (MSSQLSERVER)"
net stop "SQL Server (MSSQLSERVER)"
net start "SQL Server (MSSQLSERVER)"
net start "SQL Server Agent (MSSQLSERVER)"

ここではインスタンス名をデフォルトの名称にしているが、異なるインスタンスを再起動したければ、MSSQLSERVERの所をそのインスタンス名に置き替えれば良い。

私が試した環境のWindows Server 2008 R2 SP1では、管理者権限がないとコマンドが拒否されて正常に機能しないので注意が必要だ。

参考までに
msdnではインスタンスを停止する際のメモとして以下を記している。
「シャットダウンを正常に行うには、SQL Server インスタンスを停止する前に、SQL Server を一時停止して SQL Server エージェント サービスを停止してください。いずれの操作も net コマンドまたは SQL Server 構成マネージャを使用して実行できます。」

また、サービスの一時停止と再開については
「Microsoft SQL Server のインスタンスを一時停止した場合、サーバーに接続されているユーザーはタスクを終了できますが、新しい接続は許可されません。たとえば、SQL Server のインスタンスを数分間にわたって一時停止し、SQL Server をシャットダウンする前に、接続されているユーザーにシャットダウン メッセージを送ることができます。また、一時停止した SQL Server サービスを再開することもできます。 」と解説している。

http://msdn.microsoft.com/ja-jp/library/ms187463(SQL.90).aspx

SQL BPA command lineは動作を停止しました

SQL SERVER 2000を2005へアップグレードする為に、SQL SERVER 2005 アップグレード アドバイザー使用した。アップグレード アドバイザー分析ウィザードの開始をクリックして、各種条件を設定し、最後に実行ボタンをクリックすると
「SQL BPA command lineは動作を停止しました」
と表示され異常終了してしまう。

解決方法をネットで調べたら、どうやらBPAClient.dllを複写してあげると解決する場合があることが分かった。
私の場合は、OSがWindows Server 2008 R2 STD SP1だが、
"C:\Program Files (x86)\Microsoft SQL Server 2005 Upgrade Advisor\BPA\bin\BPAClient.dll"
を
"C:\Program Files (x86)\Microsoft SQL Server 2005 Upgrade Advisor\BPA\"
へコピーして解決できた。

この後、アップグレードを実施したら、また同様のエラーメッセージ。
この時は、
"C:\Program Files (x86)\Microsoft SQL Server\90\Setup Bootstrap\BPA\bin\BPAClient.dll"
を
"C:\Program Files (x86)\Microsoft SQL Server\90\Setup Bootstrap\BPA\"
へコピーして解決できた。

DiffPDFとBrava Desktop

今回あるサーバーを入れ替える事になった。古いサーバーではSQL SERVER 2000が動作しており、新サーバーではSQL SERVER 2005を使用する予定だ。サーバー入れ替え時にはプログラムが正常に動作するのか検証が必要だ。データベースのテーブルの照合だったらSQL文をで比較してしまえば簡単なのだが、問題は紙に出力する帳票類だ。今回、テストするページ数はA4とA5を合わせて6,000ページ以上!!これを一文字も見逃さずに新旧で照合するのは並大抵の努力ではないし、また、それに要する時間も半端じゃないと思う。2人でやったら1カ月くらいかかるんじゃないの?その後、誤りが判明したらまた照合。これを何回かやったらいい加減イヤになってくると思う。

これを何とかプログラムでできないかと思い、インターネットでPDFを照合するソフトが在るかなと思って検索してみると、Brava DesktopとDiffPDFの2つが見つかった。

早速使い比べてみた。
Brava Desktopは有償のソフト、対するDiffPDFはフリーソフト。どちらが良いかな。

完全に一致しているPDF同士を比較するならば、DiffPDFの圧勝!! DiffPDFは差分があったページだけを抽出して表示してくれるから、完全に一致している場合は結果画面に「2つの文書は一致していると思われる」と少々自信なさげなメッセージを表示してくれる。1,000ページ位あっても所要時間は2分程度。それに対してBrava Desktopは不一致のページだけを抽出表示する機能がないので、1ページずつ黙視で確認していくしかない。これはかなり手間もかかるし、ミスも誘発すると思う。

しかし、帳票にはタイムスタンプがついている事が多い。その場合はどちらのソフトを使用しても全部のページがエラーページとなってしまうので、今度はどこがエラーしているかを正確に把握できる事が重要だ。その場合は、帳票の種類によってBrava DesktopとDiffPDFの両方に軍配が上がる。

照合するPDFによって2つのソフトを使い分けるとより早く照合作業を完了させられる。今回、6,000ページ以上を照合したが、要した時間は1人で8時間程度だった。やはりタイムスタンプの部分やSQL SERVERの返してくる値の順番によって値の印字位置が違う場合に時間を費やしてしまったので、使いながらどちらがより使いやすいかを考えた方が良いと思う。

それにしても、DiffPDFには大いに感謝!!

Windows7 デスクトップから一部のショートカットが消えた

先日、ユーザーからデスクトップのショートカットをダブルクリックしても何も開かなくなってしまったと連絡が有り、調査したらLANのL2SWが故障していた。取り敢えず、予備の機器と交換して対処した。

すると、本日、そのユーザーからデスクトップの一部のショートカットが消えていると連絡があった。どうせ、自分で消してしまったんだろと思って適当に対応したが、何となく気になりネットで調べてみた。すると、Windws7 にはコンピューター保守という機能があり、デスクトップのショートカットが消えてしまうことが有ることが判明。

マイクロソフト サポート オンラインの回答
(一部名称が異なっていたのでWindows7 SP1に合わせて変更してあります。)

●現象
 Windows 7 を実行しているコンピューターで、デスクトップ上に作成したショートカットが消えます。

●原因
 これらのショートカットは、システム保守のトラブルシューティング ツールにより破損していると見なされ、削除されます。

 システム保守のトラブルシューティング ツールは、オペレーティング システムの保守を毎週実行します。システム保守のトラブルシューティング ツールは問題を自動的に解決するか、アクション センターを通じて問題を報告します。デスクトップ上で 4 つを超える破損したショートカットが存在する場合、システム保守のトラブルシューティング ツールはデスクトップから破損したショートカットを自動的にすべて削除します。

●回避策
 この問題を回避するには、以下のいずれかの方法を使用します。
 ・方法 1
    デスクトップ上の破損したショートカットの数を 4 つ以下に維持します。
 ・方法 2
    デスクトップ上に 4 つを超える破損したショートカットが必要である場合、システム保守のトラブルシューティング ツールを無効にする方法があります。
    注: システム保守のトラブルシューティング ツールを無効にすると、これにより実行されるすべての保守タスクが無効になります。そのため、方法 1 を使用することをお勧めします。

 システム保守のトラブルシューティング ツールを無効にするには、次の手順を実行します。
  [スタート] ボタン元に戻す画像を拡大するをクリックし、[コントロール パネル] をクリックします。
  [システムとセキュリティ] で [コンピューターの一般的な問題のトラブルシューティング] をクリックします。
  左側のナビゲーション ウィンドウで [設定の変更] をクリックします。
  [コンピューター保守] を [無効] に設定します。

XPにはデスクトップのクリーンアップという無用の長物があり、PCをセットアップする度に解除する手間がかかっていたが、Windows7にはそれが無くなって良かったと思っていたら、こんな所に伏兵が潜んでいた。プログラムへのショートカットはリンクが切れることはあまり無いだろうけど、サーバーへのショートカットなんて、ネットワークを経由しているので切れることが有るのは当然なのに(マイクロソフトもそれは認識している)、マイクロソフトは何でこんな面倒な機能を追加したんだろう。

Office File Validation (OFV) アドインがインストールされた Excel 2003 でネットワーク上のファイル共有から XLS ファイルを開く時に時間がかかる

以下は、Excel2003のBookのファイル名、ファイルサイズとそのファイルが開くまでの所要時間の一覧だ。計測は同じファイルを3度試行している。計測は手元にあったストップウォッチで計測したので、アバウトだ。ファイルはLAN上のサーバーに保存されている。

book名 ファイルサイズ(Byte) 計測１回目、2回目、3回目
book1.xls 92,160Byte 8秒、8秒、8秒
book2.xls 95,232Byte 8秒、8秒、8秒
book3.xls 920,064Byte 48秒、48秒、48秒
book4.xls 2,285,056Byte 147秒、135秒、131秒

book1.xlsを開くまでに8秒かかっている。ファイルサイズは僅か90KBなのに。驚くのはbook4の時間だ。なんと2分以上かかっている。

実はこれ、office file validation add-inをインストール後の時間。

さて、office file validation add-inをアンインストールして計測すると、全部がほぼ瞬時に開く。ストップウォッチでは計測しようがない。 刹那。

つまり、マイクロソフトが Office ファイル検証機能としてWindows Updateで配付した重要な更新プログラム(office file validation add-in)を適用すると、この様にネットワーク上のBookを開く時間が大幅に増える。Book4.xlsなんて仕事にならない。

これに対して、マイクロソフトはブログで次のように回答している。
「Office ファイル検証機能 (OFV) の効果について考える」
http://blogs.technet.com/b/jpsecurity/archive/2011/07/06/3439785.aspx

故に、我が社ではoffice file validation add-inは適用しないこととする。我が社ではWSUS(Windows Server Update Services)で一括管理しているから、ユーザーがやることは何もないから安心して。

P.S マイクロソフトがこれの対策を3つ公開しているが、腹が立つのは「Excel 2007 または Excel 2010 を使用する 」だってさ。Excel2003なんて古いものをつかっていないでさっさと新しいExcelを使えと言われてるような気がする。

パソコンがスリープ状態にならないときのチェック方法(Windows 7)

弊社も東電管轄内なので、15%の節電をせざるを得ないので、会社のパソコンを未使用時にスリープに移行するように設定を始めた。その中で、パソコンがスリープにならなかったり、また、スリープになっても直ぐに復帰してしまう現象が見受けられた。

マイクロソフトのWEBサイトにその原因を特定する為の調査コマンドが掲載されていたのでそのコマンドを記しておく。

powercfg /energy -output %USERPROFILE%\Desktop\energy.html
これを実行すると、1分間のシステム監視を行ってデスクトップにログを出力するので、「エラー」項目にスリープ移行を妨げているデバイスドライバなどがないか確認する。幾つもエラー項目が出るが、通常はそれでも問題なくスリープに入れるみたい。

自分のパソコンで実行してみたら、確かに原因が特定できた。