徒然なるままに

知北さんの力作「Windows Server 2003 サポート終了対策」の最終版が出ました。
いろいろ参考になる内容が詰まっています。
しかし最後に追加された18項目。
気になるタイトルがいくつかあり、しかも内容無しURL無し。気になる。

http://www.slideshare.net/wintechq/windows-server-2003-eos
Windows Server 2003 サポート終了対策

Windows Server 2003 サポート終了とは関係なく、旧サーバーから新サーバーへの移行についてのヒントが多数盛り込まれているので、新旧サーバーの移行に携わる人にはとても参考になると思います。
あくまでもWindowsサーバーに関して、ですが。

テーマ : Windows
ジャンル : コンピュータ

前回はローカルマシンに対してGet-HotFixコマンドレットを実行して、インストールされている修正プログラムを取得してみました。
今回はリモートサーバーに対して実行してみます。

(写真1)リモートサーバーに対してGet-HotFixを実行


この書き方で、リモートのコンピューターに対しても実行可能でした。
しかしリモートサーバーのパスワードの入力(資格情報の要求)は求められます。
「Get-HotFix -ComputerName <コンピュータ名> -Credential <ユーザー名>」

多数のリモートサーバーに対してこれを実行する際に、1台ごとにパスワードを入力していたら実際には運用できないので、何らかの回避する方法はあるのでしょう。
今回はここまでです。
パスワードを暗号化したファイルから与えるとか、手入力せずに済む方法がわかったらまた書きます。

テーマ : Windows
ジャンル : コンピュータ

Windowsにインストールされている修正プログラム(パッチ)を取得する方法ですが、今まではSysteminfoコマンドを利用していました。
しかしインストールされているパッチが非常に多くなると、Systeminfoコマンドではパッチの一覧が表示されなくなる不具合があります。
そのため最近はPowerShellのGet-HofFixコマンドレットを使用するようになりました。
Get-HofFixコマンドレットはPowerShell 2.0以降で使用可能なようです。

(図1)Systeminfoコマンドの実行

C:\Windows\system32\cmd.exe

C:\>systeminfo ホスト名:               WINDOWS7SP1 OS 名:                  Microsoft Windows 7 Professional OS バージョン:          6.1.7601 Service Pack 1 ビルド 7601 OS 製造元:              Microsoft Corporation OS 構成:                メンバー ワークステーション OS ビルドの種類:        Multiprocessor Free 登録されている所有者:   norimaki 登録されている組織:     プロダクト ID:          00371-221-0601876-86639 最初のインストール日付: 2014/03/08, 23:28:55 システム起動時間:       2015/07/12, 14:51:03 システム製造元:         Microsoft Corporation システム モデル:        Virtual Machine システムの種類:         X86-based PC プロセッサ:             1 プロセッサインストール済みです。                         [01]: x64 Family 6 Model 42 Stepping 7 GenuineIntel ~2195 Mhz BIOS バージョン:        American Megatrends Inc. 090006 , 2012/05/23 Windows ディレクトリ:   C:\Windows システム ディレクトリ:  C:\Windows\system32 起動デバイス:           \Device\HarddiskVolume1 システム ロケール:      ja;倭国語 入力ロケール:           ja;倭国語 タイム ゾーン:          (UTC+09:00) 大阪、札幌、東京 物理メモリの合計:       1,024 MB 利用できる物理メモリ:   609 MB 仮想メモリ: 最大サイズ: 2,048 MB 仮想メモリ: 利用可能:   1,439 MB 仮想メモリ: 使用中:     609 MB ページ ファイルの場所:  C:\pagefile.sys ドメイン:               test01.local ログオン サーバー:      \WINDOWS7SP1 ホットフィックス:       255 ホットフィックスがインストールされています。                         [01]: KB955484                         [02]: KB982861                         [03]: 982861                         [04]: KB2670838 (中略)                         [242]: KB3046269                         [243]: KB3046306                         [244]: KB3046482                         [245]: KB3048070                         [246]: K ネットワーク カード:    1 NIC(s) インストール済みです。                         [01]: Microsoft Hyper-V ネットワーク アダプター                               接続名:        ローカル エリア接続 1                               DHCP が有効:    はい                               DHCP サーバー:    192.168.0.1                               IP アドレス                               [01]: 192.168.0.6 C:\>

「255 ホットフィックスがインストールされています。」と表示されています。
しかし246番目のホットフィックスがKB番号の途中で切れているので、これ以降は不明です。

(図2)PowerShellのGet-HotFixコマンドレットを実行

C:\Windows\system32\cmd.exe

C:\>powershell.exe Get-HotFix Source        Description      HotFixID      InstalledBy          InstalledOn ------        -----------      --------      -----------          ----------- WINDOWS7SP1   Update           KB955484      WINDOWS7SP1\norimaki 2014/03/09 0:00:00 WINDOWS7SP1   Update           KB982861      WINDOWS7SP1\norimaki 2015/01/17 0:00:00 WINDOWS7SP1   Update           982861        WINDOWS7SP1\norimaki 2015/01/17 0:00:00 WINDOWS7SP1   Update           KB2670838     NT AUTHORITY\SYSTEM  2014/03/09 0:00:00 WINDOWS7SP1   Update           KB958830      WINDOWS7SP1\TestU... 2015/06/03 0:00:00 WINDOWS7SP1   Security Update  KB2479943     WINDOWS7SP1\norimaki 2014/03/09 0:00:00 WINDOWS7SP1   Security Update  KB2491683     WINDOWS7SP1\norimaki 2014/03/09 0:00:00 (中略) WINDOWS7SP1   Security Update  KB3061518     NT AUTHORITY\SYSTEM  2015/07/12 0:00:00 WINDOWS7SP1   Security Update  KB3063858     NT AUTHORITY\SYSTEM  2015/07/12 0:00:00 WINDOWS7SP1   Update           KB3068708     NT AUTHORITY\SYSTEM  2015/07/12 0:00:00 WINDOWS7SP1   Update           KB976902      WINDOWS7SP1\Admin... 2010/11/20 0:00:00 WINDOWS7SP1   Update           KB982018      NT AUTHORITY\SYSTEM  2014/03/09 0:00:00 C:\>powershell.exe Get-HotFix |find /i "WINDOWS7SP1" /c 255 C:\>

こんな感じでインストールされている修正プログラムの一覧が表示されます。
Get-HotFixコマンドレットでは255行すべてが表示されます。

今回の例ではコマンドプロンプト(cmd.exe)からpowershell.exeを呼び出して、Get-HotFixの結果をパイプでfindに送って、/cで行数カウントしています。
するとSourceがWINDOWS7SP1である修正プログラムが255行存在していることがわかります。

(図3)Get-HotFixをexport-csvでテキストファイルにエクスポートする

Windows PowerShell

PS C:\> Get-HotFix |sort HotFixID |export-csv -encoding default C:\Temp\Get-HotFix.csv PS C:\>

いつものように、Get-HotFixの結果をパイプでexport-csvに送って、テキストファイルにエクスポートする事もできます。
この例では「sort HotFixID」を指定して、HotFixID順にソートしています。

多数の修正プログラムがインストールされた環境でsysteminfoではそれが表示されないのは、Systeminfoの不具合のようです。
systeminfo.exeではバッファサイズに制限があるため、修正プログラムが200以上もインストールされていると、正しく表示されない場合があるとの事。
Windows Server 2003についてのサポート技術情報ですが、少なくともWindows Server 2008 R2 / Windows 7では状況は同じです。
もう、これが改善する事は無いのでしょうね。
wmic qfeコマンドを使用するか、PowerShellのGet-HotFixを使用するしかないのでしょう。

http://support.microsoft.com/kb/2644427/ja
SystemInfo.exe does not display all updates in Windows Server 2003

テーマ : Windows
ジャンル : コンピュータ

自分用のメモです。

ntdsutilコマンドのmetadata cleanupで、サイト内のドメインコントローラーの一覧を表示するまでの画面。Windows Server 2008 R2のActive Directoryの例を掲載。
最近はdsquery serverとか、Get-ADDomainControllerでドメインコントローラーの一覧を参照する事が多いけれど、最終的にActive Directoryに取り残されたごみを削除するときはntdsutilコマンドですからね。

(写真1)ntdsutilのmetadata cleanupでサイト内のドメインコントローラーを一覧表示

C:\Windows\system32\cmd.exe

C:\>ntdsutil ntdsutil: metadata cleanup metadata cleanup: connections server connections: connect to server WIN2008R2DC WIN2008R2DC に結合しています... ローカルでログオンしているユーザーの資格情報を使って WIN2008R2DC に接続しました。 server connections: q metadata cleanup: select operation target select operation target: list domains 1 個のドメインを検出しました 0 - DC=test01,DC=local select operation target: select domain 0 現在のサイトがありません ドメイン - DC=test01,DC=local 現在のサーバーがありません 現在の名前付けコンテキストがありません select operation target: list site 1 個のサイトを検出しました 0 - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test01,DC=local select operation target: select site 0 サイト - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test01,DC=local ドメイン - DC=test01,DC=local 現在のサーバーがありません 現在の名前付けコンテキストがありません select operation target: list servers in site 1 個のサーバーを検出しました 0 - CN=WIN2008R2DC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test01,DC=local select operation target: q metadata cleanup: q ntdsutil: q C:\>

テーマ : Windows
ジャンル : コンピュータ

今年、2015年7月1日にうるう秒がありますね。

http://internet.watch.impress.co.jp/docs/news/20150501_700381.html
「うるう秒」まであと2カ月――7月1日午前の「8時59分60秒」挿入に備えて確認を -INTERNET Watch

原子時計を基準とする原子時に対し、地球の公転や自転を基準にする天文時が少しずつ遅れているため、数年に一度「うるう秒」を挿入して調整します。
今年の7月1日のUTC 00:00:00にうるう秒が挿入されます。(JSTで09:00:00)

こんな感じです。(JST)
2015/7/1 08:59:58
2015/7/1 08:59:59
2015/7/1 08:59:60 ←挿入される「うるう秒」
2015/7/1 09:00:00
2015/7/1 09:00:01

これ、コンピューターシステムの世界ではちょいちょい問題になるんですよね。
特にLinuxではカーネルバージョンやntpdのパッケージバージョンによっては、OSがハングアップするなどの様々な問題が実際に発生するみたいです。(うるう秒対応の仕様や、実装上のバグなどが絡んでいるみたいですが)

WindowsはOSレベルでは問題はありません。
Windowsでは、うるう秒は無視してシステム時計が進んでいくので、うるう秒に対応したNTPと比較すると、09:00:00には1秒進んだ状態になります。
しかし次回の時刻同期の際に時計が1秒戻されて、NTPサーバーと一致します。

この「1秒戻す」ですが、時計を逆戻りさせて一気に一致させるか(Stepモード)、それとも時計の進み方を少しだけゆっくりにして徐々に補正するか(Slewモード)は、設定によります。

またSQL ServerやOracle Databaseなどの主要なソフトウェア(ミドルウェア)は、基本的にはうるう秒の影響は受けません。
内部的には連番で管理され、トランザクションの処理中に時計が進んだり戻ったりしても、処理は正しく継続します。
ただし時刻を指定してリカバリするような処理など、一部は影響が発生する場合もあるようです。
また当然ですが、データベースのデータ型としての「時分秒」に、「60秒」をセットするとデータを書き込む際にエラーとなります。
データベースの時刻型は、うるう秒を意識していない(想定していない)からです。

Windows関連の情報

http://support.microsoft.com/kb/2722715/ja
うるう秒に関するサポートについて
http://support.microsoft.com/kb/909614/ja
うるう秒に関する Windows タイム サービスの処理
http://support.microsoft.com/kb/939322/ja
高精度の環境に向けた Windows タイム サービスの構成を目的とするサポート範囲
http://support.microsoft.com/kb/2722681/ja
Windows Time サービスにおける時刻同期の仕組み

VMware関連の製品ですが、アプライアンスであるvCenter Server Applianceの一部バージョンではうるう秒の影響があるようです。
これはアプライアンスに組み込まれているOSである、 SUSE Linuxが原因のようです。
VMware ESXiや、Windows版のvCenter Serverは問題ありません。

VMware関連の情報

http://kb.vmware.com/kb/2115818
VMware KB: Support for leap seconds in VMware Product

Oracle DatabaseはKROWNに掲載されているので、詳細については触れません。
例えば、こんなドキュメントとかを見てください。
KROWN:33273 うるう秒について
KROWN:16785 システム時刻の変更にともなう注意点

Linuxは私の専門外なので、割愛します。


さてここからは、とあるシステムでのうるう秒の影響を調査していて出てきた話です。
なんと「時計が逆戻りすると動作に問題が出るアプリケーション」がありました。
システム全体の窓口SE、パッケージを担当するSE、製品部門、お客様、いろんな立場の人と話しましたが、皆さんは「時計を逆戻りしないようにして」と簡単に言います。

でも、(うるう秒は関係なく)時計はずれるものです。
ずれる、時計を合わせる、ずれる、時計を合わせる。これを繰り返します。
時計をずれなくする魔法はありません。

対象のサーバーを調べましたが、数年運用してみて、時計のずれが多い時は10数秒程度でした。
NTPによる時刻同期を設定していれば、まあそんなもんでしょう。
Windowsでワークグループ環境なら、既定値ではずれが1秒を超えたら一気に時計を合わせます。
それ以内なら、時計を少し早目に進め(または少しゆっくりと進め)、徐々に時刻を補正します。

だからアプリケーションがシステム時計に対し、「時計を逆戻りしないように」を要求するのは現実的には無理な要求です。
時計を逆戻りしない範囲を、標準の1秒から、例えば5分とか10分に変更する事は出来ます。
それでも、その範囲を超えたら結局は一気に時計を戻します。
この範囲を極端な話、たとえば1日にしてもいいのですが、こんなにずれたら事実上いつまで待っても時計が合わないままになります。
(LinuxのSlewモードでは1秒の補正に2000秒。Windowsの補正度合は非公開)

Windowsの時刻同期のSlewモードとStepモードについては、この記事が参考になります。

http://blogs.technet.com/b/jpntsblog/archive/2012/12/28/slew-step.aspx
Windows Time サービス - Slew モードと Step モード - - Ask the Network & AD Support Team - Site Home - TechNet Blogs
http://blogs.technet.com/b/jpntsblog/archive/2013/02/28/step.aspx
絶対 step モードで時刻同期させたくない場合の設定方法について - Ask the Network & AD Support Team - Site Home - TechNet Blogs

以下、あるソフトウェアに対する愚痴です。

システム時計はハードウェアクロックと、OSの時刻同期の仕組みで動作します。
最近ではVMwareなどの仮想マシンが主流なので、さらにVMware ToolsによるESXiホストとの時刻同期なども加わり、時計合わせも複雑です。

最近調べたあるLinux仮想マシンは、予期せずにntpdが起動しない状態で運用され、数分も時計がずれていました。
ハード故障、人的ミス、ネットワーク障害、予期しないサービスの停止などで、時計が大きくずれる可能性はいつでもあります。

某パッケージソフトは「システム時計が進んでしまったら、実際の時刻(NTPサーバー)がそれに追い付くまでサービスを停止したままにし、時刻が追い付いたらサービスを開始する」が解決策として書かれていました。

これが何を意味するか分かりますか?
そう、こんな運用をしろって事です。
・時計が1時間ずれたら、1時間サービスを停止したままにする。
・時計が1日ずれたら、1日サービスを停止したままにする。
・時計が1か月ずれたら、1か月サービスを停止したままにする。

時刻同期が正常にできていればこんな事は無いのですが、予期しない障害で時計が大きく進んだら、長期間に渡って業務を停止しなければならない事になりますよね。
これは単なる「制限事項」では片づけられない、致命的で重大な不具合です。
よくこんな製品を世に出したと思う。これを知った時はショックで声も出なかった。
ほんと、改善して欲しい。

テーマ : Windows
ジャンル : コンピュータ