SCCMでソフトウェアパッケージが展開できない場合、Windows統合認証が設定されていることをを確認すべき。

SCCMでソフトウェアパッケージ展開ができないというトラブルがありました。 - ソフトウェアセンターにはアプリケーションが見える - インストールしようとするとエラーメッセージが表示されて、インストールされない どこも設定は間違っていないように見えたのでかなり悩んでしまいましたが、結局機能として「Windows統合認証」が追加されておらず、クライアントがHTTPでパッケージにアクセスできていなかったようです。 WSUSとSCCMサーバーを同じサーバーに導入する場合にはWSUSのインストールの中で自動的にWindows統合認証が有効化されるのですが、WSUSは別のサーバーである場合にはWindows統合認証を入れなくても前提条件をクリアしてしまい、必要なサイトがWindows統合認証になっておらず、このような症状が出ることがあるようです。 結局正常に動作している別環境のSCCMサーバーとIISのディレクトリの認証のプロパティを比較し、同一に設定しなおしてあげることで問題は解決しました。

January 15, 2014 · 1 min · 胡田昌彦

シャットダウンが進まない時には停止処理中のサービスに注目

メンテナンス中にトラブルがあってかなり無駄に時間を使ってしまったので反省も兼ねてメモしておきます。 Hyper-Vクラスタで予備ノードが無いテスト系のノードにhotfixを適用して再起動する作業をしていました。再起動を実行した所…Remote Desktopからはすぐにログオフさせられたもののいつまでたってもシャットダウンしない状況になってしまいました。結局起きていたことは以下の様なことでした。 - Hyper-Vのホストなので、稼働していた仮想マシンの状態を保存 - iSCSI接続に障害を併発しており(そもそもその対応のメンテナンスだったのですが)、ディスクへの書き込みパフォーマンスが出ていなくて時間がかかっていた - さらにディスクが見えなくなりHyper-V Virtual Machine Managementサービスが異常停止 - Hyper-V Virtual Machine Managementサービスはしばらくして自動的に開始 - その間にClusterサービスが停止中のままになる(デッドロック?) 結局Remote PowerShellでは接続できたので、Enter-PSSessionで該当ノードに入り、clusterサービスの実体であるclussvcを殺すことで再起動処理が先に進みました。 get-process clussvc | kill シャットダウンプロセスが進まない場合には、停止処理中で止まってしまっているサービスを見つけてそのプロセスを切るというのはすぐに思いつけないといけないですね。今日はこれに気がつくまでに1時間くらいかかってしまいました。反省です。また、そもそもHyper-Vクラスタでは予備ノードが無いとメンテナンスが非常に厳しいですね。

January 9, 2014 · 1 min · 胡田昌彦

SCVMMで管理されている特定のホストに仮想マシンを展開(移動)できない「VMM は、VirtualHardDisk オブジェクト xxxx を見つけることができません。」

SCVMMをしばらく使っているのですが、気がつくとクラスタ内の特定のホストにのみ仮想マシンが展開できない状態になってしまっていました。確認した具体的な現象は以下です。 - テンプレートから新規に仮想マシンを展開する際に特定ホストに展開すると必ず失敗する。 - 特定ホストから他のホストへの移動(Live Migration)は成功するが、逆方向の移動は失敗する。 - 問題のホスト上で稼働している仮想マシンには何も問題が無い。 発生していたエラーは以下です。 エラー (801) VMM は、VirtualHardDisk オブジェクト 3256807c-4362-45d5-8aab-bc3526ca4d44 を見つけることができません。 推奨される操作 このオブジェクトがクラウドのプライベート ライブラリ領域内に保管されている場合は、帯域外アクセスを介してオブジェクトが存在することを確認してください。それ以外の場合は、クラウド管理者に連絡してください。 このIDを持つオブジェクトが本当にあるのかどうか確認してみたのですが見つかりませんでした。どうやらSCVMMの内部レコードが壊れてしまいおかしな状況になってしまっているようです。 情報を探した所、以下のKBを見つけ、SQL分を実行した所症状は改善されました。 - [Performing an operation in Virtual Machine Manager fails with error 801](http://support.microsoft.com/kb/2756886/ja) B D S d ( D D O F W B i D W F E C D C E E E b S E E P E H E f E H E N L E O G C L o E C C E T I G ( L E T D O A M I L E . L L L N C L I @ E R C S L M N A C t E A A H E N V T E H E L I R T b C R R c ( H E O T T E l T E E u N @ D V N c C R V _ s E @ I F D E u A T A c H W V @ @ t X f d R r X s T R N u D L H V V o T e O i T t E A S s I C D H D m t i M v o N A t d _ I D r _ F c s e F m c S C o , V d I i c R h d I R _ u A T m D d v u O _ N b d O c s C I _ V r f e r M s O o M u t T O c D i r u I s t T . = r o I N u r v o n d o c a t c s m O r i e m i r u t N b @ u o _ N T s v q u s u U l V s r c 1 o e W d u n t s L _ D t u T r I H b e i o L W r o r 1 d E o i q m = ) L i m s C R . d u _ C v _ o U f E t e e c 0 _ e c r R r b n i u ) V I u S o [ l t d r D d r O m V _ i e s r s R H W f n o i o D L i t r v r F I C e i e O d _ r f I I R ] V i N N H e T T N D r O O O T W @ @ H V V I E H H N R D D E I I d d V , , H D @ @ I V V D D D r r I i i S v v e e N I I O d d T N U L L ) 実 行 に 必 要 な 時 間 は も の の 数 秒 で す 。 出 て い る エ ラ ー メ ッ セ ー ジ と 解 決 方 法 に か な り 乖 離 が あ る の で 、 注 意 が 必 要 で す 。 ま た 、 こ の よ う な 状 況 に な っ て し ま う と い う こ と は S C V M M に 製 品 と し て 問 題 が あ る と い う 事 で も 有 り 、 長 く 運 用 す る 中 で は 注 意 が 必 要 な よ う で す 。

August 12, 2013 · 4 min · 胡田昌彦

SCVMMにて「サポートされていないクラスター構成」となり何もできなくなる

先日SCVMMで論理ネットワークとVLAN、VMネットワークを改めて勉強し、複数のVLANに対応するように構成を変更しました。あらかたうまく行ったのですが、しばらく時間がたってからなぜか1台の仮想サーバーのみ「サポートされていないクラスター構成」となってしまいました。 実際の影響としては以下の状態でした。 - 対象サーバーにネットワーク経由でアクセス出来ない(pingも通らない) - SCVMM上でも何も操作できない コンソールでの接続もできない - 修復を実行しても直らない - 構成変更をしようとしてもできない PowerShellでRepair-VMを-Forceオプション付きで実行しても修復されず、SCVMMからは手がでない状態になってしまいました。 直接の原因として該当しそうなのは以下のエラーです。 エラー (13921) 高可用性バーチャル マシン (XXXXXXX) は、正しく構成されていないネットワーク アダプターがあるため、 サポートされません。 推奨される操作 すべての仮想ネットワーク アダプターが、高可用性仮想スイッチに接続または切断されていることを確認してください。 そして構成上も特におかしいところも見当たりません。ネットマーク周りの設定変更を行いましたし、ネットワークがおかしいというエラーも出ていますが、他のサーバーは稼働しているので特別このサーバーだけがこのような状態になる理由もよくわかりません。 仕方がないのでネット上を検索して回った所以下に似たような状況の方が。 - [Unsupported cluster configuration SCVMM 2012](http://social.technet.microsoft.com/Forums/en-US/virtualmachinemanager/thread/d9b6961c-a5fb-40c6-9e1d-32a35907af34) フェールオーバークラスタから移動したら直ってしまったということなので、真似をしてみました。 結果、ノードを移動することでエラーは解消されました。 これでとりあえず問題は回避かと思いましたが、この状態でも外部と通信ができませんでした。結局よくNICの状態を見てみたところ、2つある仮想NICの接続先が入れ替わってしまっていることがわかりました。あるいは仮想NICが入れ替わった…のかもしれません。これはipconfig /allで表示されるMACアドレスとSCVMM側で仮想マシンのハードウェア構成から確認できるMACアドレスを突き合わせることで判明しました。 結局、仮想NICのVMネットワークへの接続を切り替える(入れ替える)ことでネットワーク接続も復旧しました。 なぜこの1台だけでこの現象が発生したのかはわかりませんが - フェールオーバークラスタマネージャーから操作して逃げる - MACアドレスで仮想マシン上のNICとハードウェア構成のNICを突き合わせる というノウハウが得られたのでよしとします。同じような現象が発生した際の参考になれば幸いです。

May 28, 2013 · 1 min · 胡田昌彦

SCVMMにて「サポートされていないクラスター構成」となり何もできなくなる

SystemCenter関連の記事は以下のブログに移行しました。 - [System Center Blog](http://ebi.dyndns.biz/systemcenter/) この記事は以下の記事に移行しました。 - [SCVMMにて「サポートされていないクラスター構成」となり何もできなくなる | System Center Blog](http://ebi.dyndns.biz/systemcenter/2013/05/28/scvmm%E3%81%AB%E3%81%A6%E3%80%8C%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%AA%E3%81%84%E3%82%AF%E3%83%A9%E3%82%B9%E3%82%BF%E3%83%BC%E6%A7%8B%E6%88%90%E3%80%8D/)

May 28, 2013 · 1 min · 胡田昌彦

フェールオーバークラスタに「すでに存在するファイルを作成することはできません。」により参加できないノードが発生しました。

「すでに存在するファイルを作成することはできません。」というエラーで、クラスタのノードがクラスタに参加できなくなってしまいました。 Get-ClusterLog <ホスト名>で。“C:\Windows\Cluster\Reports\Cluster.log"にファイルが生成されます。クラスタログファイルを確認したところ以下の記述でした。 00002214.000021fc::2013/03/02-14:11:54.080 INFO [TM] Adding interface ServerName - Backup-Team to cluster configuration 00002214.000021fc::2013/03/02-14:11:54.085 ERR [GUM] Node 1: Local Execution of a gum request /tm/gum/set-state resulted in exception AlreadyExists(183)’ because of ‘already exists’(ServerName - Backup-Team) 00002214.000021fc::2013/03/02-14:11:54.085 ERR [CORE] Node 1: exception caught AlreadyExists(183)’ because of ‘already exists’(ServerName - Backup-Team) 00002214.000021fc::2013/03/02-14:11:54.085 ERR Exception in the PostForm is fatal (status = 183) 00002214.000021fc::2013/03/02-14:11:54.085 ERR Exception in the PostForm is fatal (status = 183), executing OnStop NICがすでに存在している…という状況のようです。この情報をもとに検索してみると以下のブログにヒットしました。 ...

March 5, 2013 · 1 min · 胡田昌彦

Hyper-V Replica設定時のKerberos Error : 0x8009030C 0x00002EFEとトラブルシュート方法

Dave’s blogでHyper-V Replica設定時のKerberosエラーに関してのトラブルシュートの記録が書かれていました。原因もさることながらトラブルシュートの方法が参考になりました。 The Case of the Unexplained Windows Server 2012 Replica Kerberos Error : 0x8009030C 0x00002EFE - Dave’s blog - Site Home - TechNet Blogs 発生したエラーの直接の原因はローカルセキュリティポリシーで「ネットワーク経由でのアクセス」が規定から変更されており、アクセス権がなかったから…ということだったそうです。そこに至るまでに調査したのは以下の項目。 - イベントログ(アプリケーション、システム) - Microsoft Exchange Server Error Code Look-up toolでのエラーコードの調査 - SPNの確認 - Kerberosの委任設定の確認 - ADとの接続確認 - Kerberosチケット確認 - パケットキャプチャ - プロセスモニタ - logman.exeでのkerberosイベント確認 - イベントログ(セキュリティ) 結局、はじめからセキュリティ監査ログを見ていれば…という結論にはなっていますが調査項目は参考になりますね。

February 25, 2013 · 1 min · 胡田昌彦

2台のPCをネットワークで接続する

今回の話題はWindowsネットワークに関してです。まずは一番基本的なところから、ということで2台のWindowsPCをネットワークで接続することから始めます。 まず接続する(レイヤー1) まず2台のPCを接続する必要があります。接続するには主に以下のような方法があります。 ハブ(スイッチングハブ、あるいはリピータハブ)を用意し、それぞれのPCをハブに接続する。ケーブルにはストレートケーブルを使う。 クロスケーブルを使い、2台のPCを直接接続する。 それぞれ無線LANのアクセスポイントに接続する。 どの方法でも構いません。下位レイヤに上位レイヤが無影響でいられるところがOSI参照モデルのメリットです。(参照:OSI参照モデルとTCP/IP) APIPA(Automatic Private Ip Addressing)を理解する 接続がすんだら次はネットワークの設定…なのですがその前に今の状態を確認してみましょう。 何もネットワークの設定をしていない状態で以下のコマンドを実行してみてください。 ping もう一台のコンピューター名 どうでしょうか?何も設定していないのにpingに応答があったと思います。(応答がない場合には後述する「通信できない原因」を参照してください)もうちょっと見てみましょう。「スタート」→「ファイル名を指定して実行」にて「\もう一台のコンピューター名」を入力してみてください。結果は環境やパスワードの設定などによって異なるのですが以下のような挙動のはずです。 パスワード入力を求められた コンピュータに接続でき、ウインドウが開いた さらに言うと、「マイネットワーク」を開いて適当にたどってもらうと、そこにもう一台のコンピューターも表示されているはずです。表示されるまでには時間がかかるのでまだ表示されていないようであれば10分程度待ってからもう一度表示してみてください。 つまり、何も設定していないのにもうネットワーク的に接続されていて、しかも、コンピューター名をお互いに認識できているわけです。Windowsは知識がないユーザーのために「とりあえず刺せば繋がる」ようになっているわけですね。 このときネットワークの設定はAPIPAという機構が働いて設定されています。アドレスは169.254.0.0/16の範囲から重複しないように選ばれます。ipconfig /allで設定を確認することができます。 この機能、親切だし便利ではあるのですが「設定されるまでに時間がかかる」「インターネットには接続できない」という致命的な問題もあり、実際にはよく分かっていない人がわけもわからず使ってしまっていることをのぞけばまず使われていません。 ネットワークの設定をする(レイヤー3) では、きちんとネットワークの設定をしていきましょう。現在はTCP/IPがデファクトスタンダードですので、WindowsのネットワークにおいてもTCP/IPの設定をすることになります。設定は以下の手順で行えます。 「マイネットワーク」を右クリック→「プロパティ」→「ローカルエリア接続」(※使用するネットワークアダプタ)を右クリック→「プロパティ」→「インターネットプロトコル(TCP/IP)」→「プロパティ」 ここで2台のコンピューターのネットワーク設定を以下のように設定します。 同一のネットワーク 重複しないIPアドレス 今はプライベートなネットワークを作ろうとしていますのでIPアドレスとしてはプライベートIPアドレスを設定すべきです。具体的には以下のアドレスの範囲から選択します。 範囲 サブネットマスク 10.0.0.0 - 10.255.255.255 255.0.0.0 172.16.0.0 - 172.31.255.255 255.240.0.0 192.168.0.0 - 192.168.255.255 255.255.0.0 実際には2台であれば192.168.1.0/24のネットワークを使って、192.168.1.1, 192.168.1.2というIPを割り当てることが慣習的に多いです。 しかし、上記のプライベートIPアドレスの範囲であれば何を使っても構いません。さらに言うと上記のプライベートIPアドレスの範囲を超えてグローバルIPアドレスの範囲を使っても通信は問題なく行えます。ただし、特殊用途のIPアドレスとして割り当てられている範囲もあるため、適当に設定すると通信できないこともあり得ますので、素直にプライベートIPアドレスを使うべきでしょう。 デフォルトゲートウェイとサブネットマスク このとき、デフォルトゲートウェイとDNSサーバーに何を入れればいいのか迷うかもしれませんが、今回の構成ではネットワーク上に存在しないわけですから何も入力しなくて構いません。あるいは何か適当なIPアドレスを入力しても構いません。このような構成は検証環境等ではよくあります。 ここでひとつ注意点です。たまにデフォルトゲートウェイに値が入っていないと正常に動作しないアプリケーションがありますので注意してください。(単にソフトウェアのつくりが悪いだけなのですが) 例:Outlook 2007 と Exchange Server の接続を試みたときに、エラー メッセージ “アクションを完了できません。Microsoft Exchange Server への接続が利用できません” または “Your Microsoft Exchange Server is unavailable” が表示される 通信してみる ここまででWindowsネットワークの設定が完了しました。 ...

February 5, 2009 · 1 min · 胡田昌彦

「インターネットに繋がらない」 - Proxy編

「インターネットに繋がらない」 - 初級編では直接、インターネットに接続されている環境での処理の流れを見てもらいました。今度は別のバリエーションとして、直接はインターネットに接続されておらず、Proxyを経由してインターネット上のWebサイトを閲覧するようなケースを考えてみます。 一般家庭でProxyを利用しているようなケースは極稀でしょうけれども、企業では様々な理由からProxyを利用しないとWebサイトの閲覧ができないように構成していることもあります。特にセキュリティに気を使っている企業ではProxyの利用は当たり前です。あとは、サイトを閲覧する際に実IPを隠すためにあえてProxyを利用するようなケースもあるかとは思いますが今回はそのあたりに関しては扱いません。例の如く別エントリにて解説予定です…。 Proxy接続の場合には通常の直接インターネットへ接続(Webサイトの閲覧)をする場合と比較すると以下のようなプロセスの違いがあります。 直接 Proxy経由 1.PCが起動する 2.有線または無線にてEthernetに接続する 3.固定またはDHCPにてTCP/IPの設定がなされる 4.ブラウザにてURLが指定される 1.PCが起動する 2.有線または無線にてEthernetに接続する 3.固定またはDHCPにてTCP/IPの設定がなされる 4.ブラウザにてURLが指定される 5.DNSにホスト名に対応するIPアドレスを問い合わせ、回答を得る 6.該当のWeb Serverに接続する 7.Web Serverからコンテンツを得る 8.ブラウザにコンテンツを表示する 5.Proxyサーバーに接続する 6.Proxyサーバーからコンテンツを得る 7.ブラウザにコンテンツを表示する 大きな違いは以下の2点です。 DNSを使用した”名前解決”を実行しない(必要ない) 接続するのは常にProxyサーバー Proxyサーバーを利用する場合には、Proxyサーバーに実際のコンテンツの取得をお願いする形になります。つまりProxyサーバーは「直接」の場合の5,6,7の動作を行い、その結果をPCに渡してくれるわけです。 トラブルシュートの方法 トラブルシュートとしては、Proxyサーバーの設定およびProxyサーバーへの接続があります。 Internet Explorerの場合には「ツール」→「インターネットオプション」→「接続」タブ→「LANの設定」からProxyの設定を行います。 Proxyへの接続がきちんとできているかを確かめるには、「telnet Proxyサーバー ポート番号」を実行するとよいでしょう。コマンドを実行して、画面が真っ暗になれば接続できています。 「ローカルアドレスにはプロキシサーバーを使用しない」の意味 Proxy環境の場合によく問題になるのは「ローカルアドレス」という言葉の意味です。普通に「ローカルアドレス」と聞くと同一セグメントのIPアドレスなり、プライベートアドレスなりといったものを連想すると思いますが、これはそういう意味ではなくて「名前に.(ドット)が含まれていないもの」という意味になっています。通常WindowsネットワークではPC名のみで近くのサーバーへの接続(名前解決)ができるため、このような判断基準になっているのだろうと思います。 具体例をあげましょう。Proxyサーバーを利用し、かつ「ローカルアドレスにはプロキシサーバーを使用しない」のチェックが入っているとします。 pcname(ホスト名) pcname.test.local(FQDN) 192.168.1.1 上記の3つが全く同じホストを指している場合、1はホストに対して直接のアクセス、2と3はProxyサーバー経由のアクセスということになります。単純に.(ドット)が含まれているかどうかが判断基準です。 よく2や3の場合でも同じサブネットなんだからProxyサーバー経由ではなく直接接続してくれると勘違いしてしまうケースがあるので、きをつけてください。 2や3の入力方法でも直接接続させたい場合には除外設定を行えばよいです。 そもそもProxy接続をしなければいけないことをどのように知るのか Proxy接続が必要な環境であること自体を知る、あるいは直接接続はできないと判断するにはどうすればいいでしょうか。これはDNSの確認とHTTPポートでの接続の可否で判断できます。 外部のホスト名の名前解決ができるか まず、DNSに関して。DHCPなり固定IPなりできちんとしたDNSを割り振られていることを前提とします。この状態でnslookupにて外部ホストの名前解決ができるかどうかを確認します。 上記のように名前解決ができるようであれば、自らWebサイトへの接続が試行できるので、Proxyは必要ない環境の可能性が高いです。逆にここで名前解決ができないようであればProxyが必須の環境であるということがわかります。あるいは完全にインターネット上のホストへのアクセスができないか、です。 外部のホストに接続できるか 名前解決ができる環境であれば直接Webサイトへの試行を行うことができます。Webサーバーへの接続はtelnetでHTTPポートへの接続で試すことができます。 名前解決ができても外部ホストに接続できない場合や逆に名前解決ができなくても外部ホストに接続ができる場合などもあり得ます。ですが基本的には両方うまくいかなければProxy接続が必要な環境だ、ということがいえます。 Proxyの設定に関する注意点 ちなみにWindows上のアプリケーションの場合にはインターネットアクセスの際にIEのProxyの設定を参照するものも結構あるので注意が必要です。特に規定のブラウザをIE以外のブラウザに変更しているときには注意が必要です。IEのProxy設定にも設定を入れておきましょう。 また、サービスで動作しているプロセスがProxy設定を必要とするケースがあります。この場合には該当アカウントのプロファイル上でIEのProxy設定を行う必要があるものもあるので注意が必要です。 さらに、IEのProxyを見ないでWinHTTPの設定を見るアプリケーションもあります。さらにはIEでアクセスするくせにWinHTTPの設定を見るようなものも存在していますので(Microsoft Update等)、proxycfgコマンドでの設定が必要なケースもあります。このあたりには注意が必要です。 参考:How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site ...

December 23, 2008 · 1 min · 胡田昌彦

「インターネットに繋がらない」 - 初級編

「インターネットに繋がらない!」という発言をよく聞きます。テクノロジーを理解していないお客さんならともかく、プロとしてはこのような発言はしたくないものです。「インターネットに繋がらない」時には具体的にどのようなことが原因として考えられるのか考えてみます。 ※ここでは「インターネットに繋がる」という言葉の正確さに関しては議論しないことにします。 大まかな流れとその確認確認ポイント 通常お客さんが「インターネットに繋がらない」と言ったときにはブラウザでWeb上のコンテンツを表示できなくなったときでしょうから、そのときの大まかな流れを見てみます。 PCが起動する 有線または無線にてEthernetに接続する 固定またはDHCPにてTCP/IPの設定がなされる ブラウザにてURLが指定される DNSにホスト名に対応するIPアドレスを問い合わせ、回答を得る 該当のWeb Serverに接続する Web Serverからコンテンツを得る ブラウザにコンテンツを表示する これはかなり大まかな流れであって、実際にはまだまだいくらでも細かく処理を記述することが可能ですが、最低この程度の粒度では事象を抑えてもらいたいです。 このレベルでの確認ポイントは以下です。 きちんとケーブルが刺さっているか IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 該当のWeb Serverに接続できているか コンテンツを得られるか それぞれ確認方法を紹介してみましょう。 きちんとケーブルが刺さっているか これはどうやって確認すればいいかというと・・・・。目で見て確認してください(笑)。でも、せっかくなのでコマンドで確認する方法も紹介しましょう。 このように「ipconfig」というコマンドを使うとネットワークの状態を見ることができます。今、上の図ではきちんとIPアドレス等が表示されているので、この状態であれば「ケーブルがきちんと刺さっている」と言うことがわかります。ケーブルがきちんと刺さっていない場合にはここには「media disconnected」と表示されます。このように表示された場合にはケーブルが刺さっていない状態ですので、ケーブルの確認をしてください。 IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSの設定がきちんとなされているか ケーブルが刺さっていることを確認したら次はIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNS等のTCP/IPの設定がきちんとなされているかを確認します。これも先ほどと同じく「ipconfig」コマンドで確認できるのですが、「ipconfig」コマンドだけではDNSの設定が確認できないので「ipconfig /all」コマンドを実行することで確認します。 ここできちんとIPアドレス(IP Address)、サブネットマスク(Subnet Mask)、デフォルトゲートウェイ(Default Gateway)、DNS(DNS Servers)が設定されていることを確認します。 ここでこれらのパラメータを自分で設定している人(固定的に設定している人)と自動的に設定している人とで若干確認、修正方法が異なります。 固定になっているのか、自動になっているのかの判別は上記コマンド結果の「Dhcp Enabled」の部分がYesになっているかNoになっているかでわかります。上記のサンプルではDHCPが有効になっていて、DHCPサーバー(192.168.1.254)からTCP/IPの設定を自動取得していることがわかります。 固定で設定している場合には「インターネットプロトコル(TCP/IP)」のプロパティから手動で値を設定、修正します。 自動になっている場合にはDHCPサーバーがきちんと稼動して、正しい設定を配布してくれている必要があります。自動的に取得する設定になっているにもかかわらず「169.254.x.x」、あるいは「0.0.0.0」というアドレスになっている場合には正常にDHCPサーバーから設定を取得できていない状態です。DHCPサーバーの正常動作を確認するか、あるいは固定で設定してしまうかなどの対応が必要です。 参考:APIPA - Wikipedia そもそもどんな値を設定すればいいのか、設定されていればいいのかわからない人はTCP/IPの基礎を勉強しなくてはいけないですね。後日書く予定です。 ここまでの設定の確認としては、「デフォルトゲートウェイまでのpingが通ることを確認する」という方法が有効です。 「ping デフォルトゲートウェイのIPアドレス」を実行して、Pingに対してReplyがあることを確認しましょう。 DNSでの名前解決(ホスト名からIPアドレスへの変換)がきちんとなされているか 次にDNSでの名前解決がきちんとなされているかの確認方法です。「nslookup」というコマンドをつかって「nslookup ホスト名」とすることで調べられます。「ホスト名」というのはURLのうち下の例で言うとxxxx.xxx.xxの部分です。 「http://xxxx.xxx.xx/yyy/xxx/」 http://の直後からはじめの「/」の前までの部分ですね。 このようにホスト名からIPアドレスへの変換がうまくいっている必要があります。そもそもここでスペルミスなどをすると以下のように答えが返ってきません。 ここがうまくいかない場合には以下の2つの可能性があります。 TCP/IPの設定でDNSの設定を間違えている(正しいDNSサーバーを利用していない) 接続しようとしている先のサイトの情報を保持しているDNSサーバーに障害が起きている どちらなのかを判断するためには、その他のホスト名の名前解決ができるかどうかを調べましょう。私はいつも「www.google.com」が解決できるかどうか試しています。 ここまでのこと(ケーブル、TCP/IP設定、DNS)を一度に試す方法があります。それは「ping www.google.com」を実行することです。 ケーブルが繋がっていなければPingに応答があるわけはありませんし、TCP/IPの設定がただしいからgoogleのサーバーまで通信できています。また、www.google.comをDNSをつかってIPアドレスに変換できているからPingが打てているのです。www.google.comのホストはきちんとpingのReplyを返してくれるので確認が取れるわけです。 該当のWeb Serverに接続できているか ここまでの確認でクライアント側のTCP/IPおよびDNSの設定は問題ないことがわかりました。もう少し上の層に視点を切り替えていきます。まずは、該当のWeb Serverに接続できているかどうかです。 ...

December 14, 2008 · 1 min · 胡田昌彦