カテゴリー: Windows

投稿日:

Windows Server 2008 SP2にInternet Explorer 9をインストールする 2022/07/06版

Check
Facebook にシェア
このエントリーをはてなブックマークに追加

検証のためにWindows Server 2008 SP2をセットアップしたわけだが、オフライン状態でInernet Explorer 9をインストールするために必要なものとして http://go.microsoft.com/fwlink/?LinkId=185111 を案内され、インストールの前提条件Internet Explorer 9に飛ばされ、下記を入手しろ、と言われる

  • サービス パック 2 for Windows Vista および Windows Server 2008 (KB948465) に関する情報
  • グラフィックス、イメージングWindows XPS ライブラリの説明 (KB971512)
  • Windows Vista および Windows Server 2008 のプラットフォーム更新プログラムの補足 (KB2117917) 
  • 注意 この更新プログラムをインストールする前971512更新プログラムをインストールする必要があります。

しかし、これらのリンクが機能しておらずアップデート用のファイルが入手できない。

試行錯誤してたどり着いた結果を書いておく。

Windows Sevrer 2008 SP2の入手について

今回SP2適用済みメディアを使用したが、SP2ことKB948465はMicrosoft Updateカタログで「KB948465」を検索して「windows6.0-kb948465-x64_2eedca0bfa5ae8d1b0acf2117ddc4f15ac5183c9.exe」を入手してインストール。

1個目 KB2117917 適用

Microsoft Updateカタログで「KB2117917」を検索して「windows6.0-kb2117917-x64_655a21758801e9648702791d7bf30f81b58884b3.msu」を入手してインストール。再起動はしなくても大丈夫

2個目KB2506014適用

Microsoft Updateカタログで「KB2506014」を検索して「windows6.0-kb2506014-x64_e4a62be05adf6d07841dd3df49fb5d63d1d3ba05.msu」を入手してインストール。再起動はしなくても大丈夫

3個目KB971512適用

Microsoft Updateカタログで「KB971512」を検索して「windows6.0-kb971512-x64_0b329b985437c6c572529e5fd0042b9d54aeaa0c.msu」を入手してインストール。再起動はしなくても大丈夫

問題発生

これでインストールの前提条件Internet Explorer 9に書かれている前提条件をクリアしているはずなのだが、インストールが拒否される。

まだ適用が必要な更新があるらしい。

「更新プログラムの取得」をクリックするとInternetExplorer8でhttp://go.microsoft.com/fwlink/?LinkId=185111 を開こうとするが開けずエラーとなる。

再起動して、もう１回、「windows6.0-kb971512-x64_0b329b985437c6c572529e5fd0042b9d54aeaa0c.msu」をインストールすると今回はなぜか完了した。

？？？と思ってWindows Updateの更新履歴を確認すると「KB2999226」が追加されている・・・

これは「Windows での汎用の C ランタイムの更新プログラム」であるようで、Windows Updateによりインストールされていた模様

4個目 KB2999226適用

というわけで、Microsoft Updateカタログで「KB2999226」を検索して「windows6.0-kb2999226-x64_0befbb0b78588f7c9f17ead1da3abeda2b6f4c7f.msu」を入手してインストール。

今回は再起動は必須。

Internet Explorer 9インストール

Microsoft Updateカタログで「Internet Explorer 9 2008用」を検索して3ページ目に出てくる「x64 ベース システム Windows Server 2008 用 Windows Internet Explorer 9」から「wu-ie9-windowsvista-x64_f599c02e7e1ea8a4e1029f0e49418a8be8416367.exe」を入手してインストール。

再起動は必須。

なお、 IE9.0の日本語化を「ie9-langpack-windowsvista-x64-jpn_331d32d2b458301c359cb95b639425ff2dbaf2a1.exe」のインストールで行おうとしたのですが、実行しても何も起こらず、日本語化も行われませんでした。

ルート証明書の更新

2022/07/06時点ではWindows Server 2008 SP2に含まれているルート証明書はすべて期限切れになっています。

httpsで使うためのルート証明書がないので、最近のほとんどのWebサイトにアクセスできません。

ルート証明書の更新についての調査過程メモ

2022/07/06時点ではWindows Server 2008 SP2に含まれているルート証明書はすべて期限切れになっています。

この更新に関して調べて見ると「【Windows】オフライン環境でルート証明書更新プログラムを利用する構成について」にて KB2813430 で提供されているという話があった。

Microsoft Updateカタログで「KB2813430」で検索して適用

その後、グループポリシーエディッタを「gpedit.msc」で起動して、[コンピュータの構成]-[管理用テンプレート]-[システム]-[インターネット通信の管理]-[インターネット通信の設定]を開き、「ルート証明書の自動更新をオフにする」を「未構成」から「無効」に変更します。

これでいけるかなぁ・・・と思ったのですが、再起動したり２４時間放置してみたりしても状況に変化はなし。

Microsoftのページに「リリース ノート – Microsoft の信頼されたルート証明書プログラム」というのがあり、ルート証明書更新プログラムパッケージを https://aka.ms/CTLDownload というURLで配布している。

個々にアクセスすると、authrootstl.cab がダウンロードできるのでコマンドプロンプトから「certutil -syncWithWU ～\authrootstl.cab」と実行してみたが、現状有効なルート証明書がないようで、失敗した。

Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Users\Administrator>certutil -syncWithWU C:\Users\Administrator\Downloads\aut
hrootstl.cab
証明書チェーンは処理されましたが、信頼プロバイダが信頼していないルート証明書で強
制終了しました。 0x800b0109 (-2146762487) -- authrootstl.cab
CertUtil: -syncWithWU コマンド エラーです: 0x800b0109 (-2146762487)
CertUtil: 証明書チェーンは処理されましたが、信頼プロバイダが信頼していないルート
証明書で強制終了しました。

C:\Users\Administrator>

WSUS Offline Updateでルート証明書の更新をやっている部分を確認すると、win\glb\ディレクトリ内に拡張子crt(セキュリティ証明書)と拡張子crl(証明書失効リスト)のファイルがあり、certuril -addstore Root ～ という形で登録していました。

この証明書ファイル群はどこで入手？と調べたところMicrosoft Japan Windows Technology Support Blogの「ルート証明書更新プログラムの仕組みについて」にいろいろ記述を発見

信頼できるルート証明書のリスト http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab というのは、さきほどダウンロードしたやつ。

しかし、これの中を確認してもバイナリなので、リストに記載されているというルート証明書が分からない・・・

Windows Server 2008R2であれば「Support for urgent Trusted Root updates for Windows Root Certificate Program in Windows(3024777.)」でアップデートが提供されている。

Cirtixのサポート情報として「Windows Server 2008 のルート証明書の更新機能でルート証明書を自動更新できない場合に Hotfix のインストールに失敗する」(CTX130025)というのがあり、対策２が使えそうだが、初手のルート証明書入手先が現存していない。(英語版KB Hotfix Installation Fails if the Update Root Certificates Feature in Windows Server 2008 Cannot Automatically Update the Root Certificates (CTX129998)も同じ)

HPE KB「HP Insight Remote Support Advanced Software – Version A.05.50 with Windows 2008 and IE x64 and Remote Support Client RSC Fails to Register」も同じ入手先URLでアクセスできず。

「McAfee Enterprise 製品のインストール/アップグレードを成功させるためにルート証明機関を更新する方法」に、バッチファイル(2022_Certificates.bat.txt)とレジストリ設定用ファイル(2022_Certificates.reg.txt)を実行することで登録される、という手法が書いてある。

いい方法ないなぁ、と思ったら https://gist.github.com/mateusaubin/3671126 のコメントで「ASHER TOOLS Root Certificate Updater」 というのが紹介されていた。

内容はPowerShellでソースコードは https://github.com/asheroto/Root-Certificate-Updater で公開されている。

「certutil -f -addstore root ファイル名」で実行すると登録できた模様。

なるほど・・・

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc749331(v=ws.10)?redirectedfrom=MSDN

投稿日:

Windows Server 2008をいまさらセットアップした(作業メモ版)

Check
Facebook にシェア
このエントリーをはてなブックマークに追加

2022/07/08追記

何回か実行してみたところ、いろんな問題があったため、新しい記事「Windows Server 2008 SP2のWindows Updateがうまくいかない件への対処策 2022/07/07版」としてまとめ直しました。

とあるバックアップソフトの対象機種からWindows Server 2008が外れた。

これは「ホントにインストールできない」という意味なのか、それとも「インストールできるけどサポート対象と認定しない」という意味なのか、どちらなんだろ？と確認するため、Windows Server 2008環境を新規でセットアップした。

Windows Server 2008 SP2 のISOイメージを使ってvSphere環境でインストールを実施。

まず、VMware Toolsをインストールしようとしたら対応していないOSと言われてしまう。

調べると最後のWindows Server 2008 SP2対応はVMware Tools 11.0.6だったらしい。

このバージョンのVMware toolsダウンロードを https://packages.vmware.com/tools/releases/11.0.6/ から行ってインストールを実施。

続いて、Windows OSのアップデートは WSUS Offline Updateを使ってオフライン状態でアップデートできないかな、と確認してみると、ESR versionの 11.9.1 であればWindows Server 2008に対応していたので、ISOイメージを作成した。

が・・・ ListMissingUpdateIds.vbs で、「信頼プロバイダが信頼していないルート証明書で強制終了しました」というエラーで失敗して、パッチ適用の本編に進まない。

certmgr.mscを起動して確認してみると「証明書失効リスト」にいろいろある・・・

ListMissingUpdateIds.vbs の処理を修正しないとダメっぽいんだけど、うまくデバグできなかったので対処を諦めて普通にWindows Updateを実施。

しかし、最後10個ぐらいのところで、それ以上進まなくなる、という現象が発生。

2回実施中2回とも発生なので、特定の何かで問題が発生している模様。

この状態になると強制電源OFF/ONして、Windows Updateのロールバック処理を行うぐらいしか対処方法が無かった。

ロールバック完了後に再度Windows Updateを実行してみると半分以上がまだ未適用でした・・・面倒くさい

この後のWindows Updateはハングアップすることはなく普通に進み、とはいえ、何回か再起動とWindows Updateの再実行が必要でした。

で・・・

今回、Windows Server 2008環境を構築するきっかけとなった非対応問題ですが、「インストールできない」という状況でした。

なぜインストールできないのか、というのは前提条件である.NET Framework 4.6.2がWindows Server 2008に非対応だったから、ということでした。

なお、Windows Server 2008については古いバージョンをインストールしておけばサーバ側が新しいバージョンであってもバックアップ/リストアが問題無く動作していました。

WSUS Offline Updateを使わないでいきなりWindows Updateしてみると、Microsoftサイトにアクセスできずに終わります。

なぜかこのような状態になっているかと言えば、といえばhttpsアクセス時に使用する証明書が全て有効期限切れとなっているためですね。

これはcertmgr.mscを起動して確認出来る信頼されたルート証明書機関の有効期限を見ればわかります。

WSUS Offline Updateはルート証明書の更新はやってくれて下記の様な感じになっています。これによりhttpsによるアクセスが成功するようになっている感じですね。

投稿日:

Prolific社のUSBシリアルチップPL2303シリーズのWindows10/Windows11非対応問題

Check
Facebook にシェア
このエントリーをはてなブックマークに追加

USBシリアルアダプタに以前はよく使われていたProlific社のPL2303シリーズ。

ある時期から偽物チップが登場して、上手く動く/動かない、という話になったことにキレたProlific社が古いチップをまとめてEOS(End of Support)したので、EOS以後にリリースしたWindows10以降で使えなくなった、なんてことがあった。

この互換性問題もあってか信頼性を求めるとFTDI社FT232シリーズ、安さを追求するとWCH社のCH340シリーズなど他社のUSBシリアルが採用されがちになってる。

で・・・このEOSに関するProlific社の公式表明としては、2012年2月に、PL-2303HX, PL-2303Xシリーズを廃盤として、PL-2303TAを後継とするアナウンスを出している。これの影響でPL-2303HXA,PL-2303XAおよびそれより古いPL2303シリーズがWindows8以降で使えなくなった。

このため該当するチップを使っているUSBシリアルをWindows10にさすと、以下のような表示となって使えない。(PL2303HXA PHASED OUT SINCE 2012, PLEASE CONTACT YOUR SUPPLIER. )

で・・・Press Releaseを見ると、2019年12月にその後継とされたPL-2303TA含めて、PL2303HXD, PL2303RA,PL2303EA, PL2303SAがEOSとなっていた。

この時点では特に問題なかったのだが、どうやらWindows11ではこのPL-2303TA採用チップなどが「PL2303TA DO NOT SUPPORT WINDOWS 11 OR LATER, PLEASE CONTACT YOUR SUPPLIER.」として使えなくなっているらしい。

Windows 10用のドライバを持ってきて強制的に適用すれば使用できるようにはなるらしいですが、Windows Update経由のドライバ更新があったりすると使えなくなったりしそうなので、あまりお薦めできなそうです。

2023/01/28追記

ツクモに行ったら ainex ADV119 v2 が500円で売ってた

メーカページを見てみると「ADV-119 ○ ドライバは従来よりウェブに公開しているもので対応します。」と書いてある。

ということはWindows 11の標準ドライバでは対応しないやつなんだな、と思い買ってみると、予想通り以下の表示

で、メーカページからリンクがはれている「PL2303 Windows Driver Download USB to UART RS232 Serial」から「Windows 10 RS3 or higher」と書かれてる方をダウンロードして「PL2303_DCHU_Win10_20H1_19H1_5_v3.8.36.2_20210315_ML_Driver」のドライバを適用すると、下記の表示となり、使用できるようになりました

2023/11/14追記

上記のProlificサイトにアクセスできない場合はMicrosoft Updateカタログで「VID_067B PID_2303 3.8.36.2」で検索して出てきた「Prolific – Ports – 3.8.36.2」のやつを使うといけるかもしれない。

投稿日:

Windows 10 環境でいつの間にかDHCPによるIPv6アドレスができなくなってた件への対応

Check
Facebook にシェア
このエントリーをはてなブックマークに追加

Windows 10 21H2環境でDHCPサーバからIPv6アドレスがちゃんと割り当てられて、各Webサイトに対してIPv6アクセスができる、という状態であることを確認していた。

しかし、ふと気がついて見るといつの間にかにIPv6アクセスではなくなっていたようだった。(たとえば IIJmio にアクセスするとConnected via IPv4表記になっていた)

「ipconfig /all」コマンドを実行してみると、「リンクローカルIPv6アドレス」はあるものの「IPv6アドレス」がない。
また、DNSサーバとして、これまでIPv6アドレスが２つ登録されていたものが、IPv4サーバのみになっていた。

手動でIPv6アドレスを設定してみるとIPv6アクセスができるので、ネットワーク側の問題ではないようだ。

いろいろ悩んだのですが、「netsh interface ipv6 dump」コマンドでIPv6に関する設定情報を取得してみるとおかしな状態が・・・（ログを取ってなかったので↓はこんな感じだった、という再現出力で、細かいパラメータについてはたぶん実際の状況とは異なると思います）

C:\Users\osakanataro>netsh interface ipv6 dump


# ----------------------------------
# IPv6 構成
# ----------------------------------
pushd interface ipv6

reset
set interface interface="イーサネット (カーネル デバッガー)" forwarding=enabled advertise=enabled nud=enabled ignoredefaultroutes=disabled
set interface interface="Wi-Fi" forwarding=enabled advertise=enabled nud=enabled ignoredefaultroutes=disabled
set interface interface="ローカル エリア接続* 1" forwarding=enabled advertise=enabled nud=enabled ignoredefaultroutes=disabled
set interface interface="イーサネット" forwarding=enabled advertise=enabled nud=enabled ignoredefaultroutes=disabled
set interface interface="ローカル エリア接続* 4" forwarding=enabled advertise=enabled mtu=1280 nud=enabled ignoredefaultroutes=disabled
set interface interface="ローカル エリア接続* 2" forwarding=enabled advertise=enabled nud=enabled ignoredefaultroutes=disabled
set interface interface="イーサネット 2" forwarding=enabled advertise=enabled nud=enabled ignoredefaultroutes=disabled
set interface interface="イーサネット 3" forwarding=enabled advertise=enabled nud=enabled ignoredefaultroutes=disabled
set interface interface="イーサネット 4" forwarding=enabled advertise=enabled nud=enabled ignoredefaultroutes=disabled
set interface interface="vEthernet (Default Switch)" forwarding=enabled advertise=enabled nud=enabled ignoredefaultroutes=disabled


popd
# IPv6 構成の最後



# ----------------------------------
# ISATAP 構成
# ----------------------------------
pushd interface isatap



popd
# ISATAP 構成の最後



# ----------------------------------
# 6to4 構成
# ----------------------------------
pushd interface 6to4

reset



popd
# 6to4 構成の最後



C:\Users\osakanataro>

コントロールパネルのネットワークアダプターでは表示されないデバイスについての設定がいろいろ入っていました。

ここらへんの設定が影響しているかもしれない、ということで、IPv6に関する設定をすべて消去してみました。

コマンドは「netsh interface ipv6 reset」です。

実行完了後、Windows OSの再起動が必要です。

再起動後に確認してみると、IPv6アドレスが期待通りに割り当てられており、また、IPv6アクセスも正常にできていました。

なお、再起動後の「netsh interface ipv6 dump」の内容は下記のようになっていました。(Hyper-V設定を行っているので、vEthernetがあります)

C:\Users\osakanataro>netsh interface ipv6 dump


# ----------------------------------
# IPv6 構成
# ----------------------------------
pushd interface ipv6

reset
set interface interface="vEthernet (Default Switch)" forwarding=enabled advertise=enabled nud=enabled ignoredefaultroutes=disabled


popd
# IPv6 構成の最後



# ----------------------------------
# ISATAP 構成
# ----------------------------------
pushd interface isatap



popd
# ISATAP 構成の最後



# ----------------------------------
# 6to4 構成
# ----------------------------------
pushd interface 6to4

reset



popd
# 6to4 構成の最後



C:\Users\osakanataro>
投稿日:

ssh接続を使って２つ先にある管理画面Webにアクセスする

Check
Facebook にシェア
このエントリーをはてなブックマークに追加

下記の様な感じで、踏み台サーバを２つ経由した先にある管理画面Webを、手元の操作端末上のブラウザで確認したい。

sshによるトンネル接続を利用したSOCKS proxyを使うことで実現できる。

構成の概要としては下記の様な形となる。

操作端末はWindows 10で、puttyを使用してssh接続を行い、Firefoxブラウザで管理画面を開く、という想定。

まず、SSH接続1について設定

[Session]-[Host Name] で 踏み台サーバ1 とポート番号を指定(port 22)
[Connection]-[Data]-[Auto-login username] で 踏み台サーバ1のログインユーザ名
[Connection]-[SSH]-[Tunnels]の[Forwarded ports] で 「L10022 踏み台サーバ2:22」(“Local”,”Souce port:10022″,”Destination: 踏み台サーバ2:22″)
公開鍵認証を使用する場合は [Connection]-[SSH]-[Auth]の[Private key file for authentication]に指定

これにより、「踏み台サーバ1へのSSH接続1」と「操作端末のローカルポート10022にアクセスすると踏み台サーバ2のポート22に転送されるトンネル接続」が出来る。

次に作成されたトンネル接続を利用したSSH接続2を設定

[Session]-[Host Name] で localhost ポート 10022 を指定
[Connection]-[Data]-[Auto-login username] で 踏み台サーバ2のログインユーザ名
[Connection]-[SSH]-[Tunnels]の[Forwarded ports] で 「D10080」(“Dynamic”,”Souce port:10080)
公開鍵認証を使用する場合は [Connection]-[SSH]-[Auth]の[Private key file for authentication]に指定

これで「”接続端末のローカルポート10022″から 踏み台サーバ ポート22 に転送されてSSH接続2」と「操作端末のローカルポート 10080 にアクセスすると、踏み台サーバ2 上からネットワーク接続できるトンネル接続」が出来る。

最後に、Firefoxの[General]-[Network Settings]にて、「Manual proxy configuration」で「SOCKS Host: localhost Port: 10080」と設定する。

これで操作端末上から閉鎖網2上にあるWeb管理画面を開けるようになった。

2022/01/20追記

TeraTermでも同様のことを行う手法を調べた。

puttyみたくテンプレート化できないので、ショートカットで起動できるようコマンドラインオプションとして指定する手法とした。

"C:\Program Files (x86)\teraterm\ttermpro.exe" 踏み台サーバ1 /ssh2 /auth=publickey /keyfile=X:\tmp\sshkey\～.ppk /ssh-L10022:踏み台サーバ2:22 /user=踏み台サーバ1のログインユーザ名 /passwd=秘密鍵のパスフレーズ

"C:\Program Files (x86)\teraterm\ttermpro.exe" localhost:10022 /ssh2 /auth=publickey /keyfile=X:\tmp\sshkey\～.ppk /ssh-D10080 /user=踏み台サーバ2のログインユーザ名 /passwd=秘密鍵のパスフレーズ

なお、引数でパスフレーズを指定しない場合、「SSH2秘密鍵の読み込みに失敗しました wrong passphrase」という下記のダイアログが表示されてうざいです。

また、TeraTermでSSHのダイナミックポート転送を行う場合、指定したポートが使用できない場合、下記の様なApplication fault Execption:ACCESS_VIOLATIONダイアログが表示されることがある。

ダイアログもなしにTeraTermが終了することもある。

2022/01/21 追記
TeraTermでのSOCKS proxy(ダイナミックポート転送)がどうにも不安定なので、 puttyで実施している。