a

エラーコードは失念してしまいましたが、以下のコマンドを実行してシステムのファイルを修復したところ、認証の問題が解消したという事例がありました。

sfc /scannow

ありがとうございます。

sfc /scannow

を試してみたのですが、ダメでした。。。。

以下のスレッドを見つけました。疎通できなくなっている原因として、以前にネットワーク関連の変更を実施されていないでしょうか。

Windowsインスタンスのライセンス認証切れ
https://forums.aws.amazon.com/message.jspa?messageID=516336

ご回答ありがとうございます。

ご案内頂いたスレッド私も気になったのですが、
169.254.169.250 または 169.254.169.251 へのルーティングエントリは、route printで確認すると、エントリーされているうようなのです。

以下がルーティングの結果なので、どこか違っているか、来なる点などございましたら、ご指摘頂けますでしょうか？

ご参考までに、以下がネットワークの状況です。
C:\Users\Administrator>ipconfig
Windows IP 構成
イーサネット アダプター VPN - VPN Client:
接続固有の DNS サフィックス . . . :
IPv4 アドレス . . . . . . . . . . : 192.168.100.11
サブネット マスク . . . . . . . . : 255.255.255.0
デフォルト ゲートウェイ . . . . . :
イーサネット アダプター ローカル エリア接続:
接続固有の DNS サフィックス . . . : ap-northeast-1.compute.internal
IPv4 アドレス . . . . . . . . . . : 10.0.0.90
サブネット マスク . . . . . . . . : 255.255.255.0
デフォルト ゲートウェイ . . . . . : 10.0.0.1

C:\Users\Administrator>route print
IPv4 ルート テーブル

アクティブ ルート:
ネットワーク宛先 ネットマスク ゲートウェイ インターフェイ
ス メトリック
169.254.169.250 255.255.255.255 10.0.0.1 10.0.0.90 10
169.254.169.251 255.255.255.255 10.0.0.1 10.0.0.90 10
169.254.169.254 255.255.255.255 10.0.0.1 10.0.0.90 10
192.168.100.0 255.255.255.0 リンク上 192.168.100.11 257

Edited by: 4suta on Jan 24, 2018 4:53 PM

VPN を利用されているようですが、以下のページにあるような状況は発生していないでしょうか。

windowsでVPN接続とネットワーク接続を併用したときのハマり
https://blog.freedom-man.com/windows_vpn_network/

アドバイスありがとうございます。

頂いた情報をもとに、いろいろと試しておりますが、なかなかうまくいきません。

こちらのページの
ネットワークの設定で[リモートネットワークでデフォルトゲートウェイを使う]を外す必要がある。
http://www.kisc.meiji.ac.jp/~ksd/nsd/support/dialup/vpn_s_xp.html
にて、「リモートネットワークでデフォルトゲートウェイを使う」の設定が見当たらなかったのですが、
VPNは、こちらのものを利用しており、
https://ja.softether.org/
当該サーバーは、vpn clientとしてうごかしておりますが、これが何か関係しますでしょうか？
vpn client にはデフォルトゲートウェイは設定しておりません。

その他、
route DEL 169.254.169.250
として既存のルーティングテーブルを削除してから、
route ADD 169.254.169.250 255.255.255.255 10.0.0.1
とてみたのですが、同じエラーとなってしまいました。

お手数をおかけしますが、宜しくお願い致します。

Edited by: 4suta on Jan 24, 2018 10:25 PM

お世話になっております。

同じwindows環境の旧インスタンスで、アベイラビリティゾーン「ap-northeast-1b」にあるもので確認したところ、、
169.254.169.250へは、正常に疎通確認できました。
この時のプライベートIPは「10.188.151.83」のようになっておりました。

やはり、10.0.0.90のアドレスですと、ダメなようです。

以下のコマンドで、ルーティングテーブルを変更すれば、いけそうな気がするのですが、ルーターのIPはどこへ向けてセットすればよいのかわからず悩んでおります。
route ADD <private subnetの宛先IP> MASK <private subnetのサブネットマスク> <ルータのIP>

なに他に試してみる事などありましたら
引き続き、宜しくお願い致します。

サブネット毎にデフォルトゲートウェイに設定すべき IP アドレスは変わりますが、DHCP を無効にして上書き設定などしていなければ問題が発生する可能性は少ないと思います。

可能であれば同じサブネットに通信可能な新しいインスタンス (AWS が提供する AMI そのまま、など) を作成して ipconfig /all の結果を比較するなどしてみた方が良いかもしれません。

お世話になっております。

可能であれば同じサブネットに通信可能な新しいインスタンス (AWS が提供する AMI そのまま、など) を作成して ipconfig /all の結果を比較するなどしてみた方が良いかもしれません。

別のインタンスを立ち上げて確認してみたのですが、
旧インタンスt1.microで起動したときは、プライベートIPは、「10.185.175.134」というようになっており、KMSサーバーにも疎通でき、ライセンス認証は正常に行えています。

次世代インスタンスの「m4.2xlarge」にすると、プライベートIPは、「10.0.0.90」というようなアドレスになり、、KMSサーバーにはつながらないようです。

ＶＰＮも、一旦、オフラインにして試してみたのですが、やはり、だめでした....

また、他の方法ためしてみたいと思いますが、どうやら、プライベートIPは、「10.0.0.XX」といったアドレスになっているとだめなようです。

宜しくお願い致します。

こちらのスレッドは確認済みでしょうか。

https://forums.aws.amazon.com/thread.jspa?threadID=102769

slmgr.vbs /skms ec2-175-41-251-13.ap-northeast-1.compute.amazonaws.com

ap-northeast-1b をお使いとのことなので、169.254.169.250 が使えないのではないかという考えに至りました。

お世話になっております。

サポート契約をして問い合わせしたところ、
もともと、旧インタンスをアップグレードするために、スナップショットから、仮想化タイプをHVMに切り替えVPC環境に作成したのですが、スナップショットからインタンスを作成すると、Platform が Linux となり、billingProduct コードが失われてしまい、ランセンス認証できなくなるということでした。

• Amazon EBS-Backed Linux AMI の作成 - Amazon Elastic Compute Cloud 　- スナップショットからの Linux AMI の作成 < https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html#creating-launching-ami-from-snapshot >

どうやら、一から再構築しないどダメなようです。。。

いろいろと、親身になってアドバイス頂きありがとうございました。

かなり当てずっぽうな回答をしてしまった事をお詫びします。
これからが大変そうですが、とりあえず原因が分かって良かったですね。
私にとっても貴重な経験になりました。ありがとうございます。

いえいえ、とんでもございません。
アドバイス頂いて大変感謝しております。
ご丁寧にありがとうございました。