IPまたはFQDNアドレスでWindows共有にアクセスできますが、ホスト名ではアクセスできません

私が管理している学校のラボコンピューターの1つは、\\ ad \ data $ディレクトリの下の共有にアクセスできません。ネットワーク上の他のコンピューターからアクセスできます。IP \\ 192.168.1.248 \ data $を使用すると、ファイルに適切にアクセスできます。FQDNを使用する場合、\\ ad.domain.name \ data $も機能します。学校の他のコンピューターも、この共有に適切にアクセスできます。

\\ ad \ data $で共有にアクセスしようとすると、「\\ ad \ data $にアクセスする権限がありません。管理者に連絡してアクセスをリクエストしてください」というメッセージが表示されます。ドメイン管理者アカウントでログインしています。

単一のドメインコンピューターが、アクセスする必要がある共有にアクセスできなくなる原因についてのアイデアはありますか？

サーバーはWindows Server 2008を実行しており、コンピューターはWindows 7 SP1を実行しています。

更新

ネットワーク上の他の複数のコンピューター、スタッフのコンピューター、学生のコンピューターで問題が発生しています。Active Directoryサーバーに重大な問題があると思い始めています。

同様の問題が発生しました。

ドメインとADがあり、すべてのユーザーのホームフォルダーがADにセットアップされています。

ユーザーがターミナルサーバーで作業し、ホームフォルダーが正常に機能するように設定した新しいノートブックでは、ドライブがマップされましたが、UNCまたはマップされたドライブをダブルクリックしてアクセスしようとするとエラーが発生しましたの場所が見つかりませんでした。

他のいくつかのフォーラムを閲覧すると、ホームフォルダーにIPまたはFQDNを介してアクセスできるかどうかを尋ねられたことがわかりました。試してみたところ、フォルダにアクセスできました。

最初は、DNSの問題だと思っていました。

さらに誰かを読んで「CSCキャッシュを削除してみてください」と言われ、それから私はほとんど自分自身に誓った。このノートブックは、オフラインファイルを使用する別のユーザー（同じサーバー上のホームフォルダーも）が使用したことを知っている。Win 7でCSCキャッシュを削除する簡単な方法を見つけました（XPではより簡単です）。コンピューターを再起動し、問題は解決しました。

ここに私が情報を見つけたリンクがあります：

http://www.petri.co.il/forums/showthread.php?t=60629

http://support.microsoft.com/kb/942974

このような問題が発生したのは、DNSがドメイン名を自動的に追加しないように設定されているためです。

そのため、 プライマリおよび接続固有のDNSサフィックスを追加するが選択され 、プライマリDNSサフィックスの親サフィックスを追加するがチェックされていることを確認します。

これは

Control Panel\Network and Internet\Network and Sharing Center
Local Area Connection Status
Properties
Internet Protocol Version 4 (TCP/IPv4) and/or Internet Protocol Version 6 (TCP/IPv6) 
Properties
Advanced
DNS

Win7 / server 2008>「資格情報マネージャー」でコントロールパネルタイプを選択し、保存されている資格情報を削除します。

同じ問題が何度か発生しましたが、接続されているすべての共有を削除して再作成することで解決しました。同じ場所に複数の接続があり（異なるURLを使用）、問題の原因であると思われます。

コマンドラインを使用：

1. 現在接続されている共有を表示するには
   net use
2. xxx.xxx.xxx.xxx上の共有Yへの接続を削除するには
   net use \\xxx.xxx.xxx.xxx\Y /delete
3. XXXで共有Yへの接続を削除するには
   net use \\XXX\Y /delete
4. マップされたネットワークドライブを削除するには
   net use Y: /delete
5. マップされたネットワークドライブを再接続するには
   net use Y: \\xxx.xxx.xxx.xxx\Y /PERSISTENT:YES /USER:XXX\user /SAVECRED

別の潜在的な容疑者は、Samsung PC Share Managerです。ホストからアンインストールすると、問題はなくなりました。

クライアントコンピューターが保存された資格情報を使用している可能性があります。コントロールパネルのWindows Credential Managerを使用して確認できます。

これは、machine_name \ Administrator などのローカル管理者アカウントで発生しますか？

マシンはドメインコントローラに対して適切に認証されていますか？

別の（または古い）資格情報を使用して\ adにまだ接続していないことを確認してください。「通常の」ドメインアカウントを使用してサーバー上の共有にマップされたドライブを接続し、ドメインの「admin」アカウントを使用して同じサーバー上の別の共有に接続しようとすると、同様の問題が発生しました。

再起動すると問題は解決しますか？

関連する問題が発生しました。Windows 7マシン上の共有/共有フォルダーおよびドライブにアクセスするXP Homeマシンがありました。Windows 7でワークグループ/ホームグループの設定をいじり、「パスワードで保護された共有」オプションを変更しました。XP Homeマシンで共有フォルダを見ることができましたが、共有フォルダの読み書きはできませんでした。XP Homeマシンで新しいユーザーを作成し、Win 7マシンで共有にアクセスしたときに問題がなかったため、ファイルの読み取りと書き込みができたためです。

そのため、古い（メイン）ユーザーアカウントに戻りましたが、まだ共有ファイルにアクセスできませんでした...

あらゆる種類のソリューションを試しました-net use * / delおよびユーザーアカウントを削除しましたnet user / delete-キャッシュされた資格情報を削除しようとしましたが、何も機能しませんでした。IPアドレスを介して共有にアクセスすることはできます。アッ!!

両方のマシンのワークグループをワークグループに設定してみました（XP HOMEマシンはMSHOMEでした）

最終的に私がしなければならなかったのは、Windows 7マシンのコンピューター名を変更し、再起動し、XP HOMEマシンから共有フォルダーにアクセスすることでした。次に、ログオンユーザー/パスワードを再入力しました。ただし、古いコンピューター名を使用するパスやものがあるため、Win 7コンピューターを元の名前に戻しました。アレルヤ！うまくいきました-ユーザー/パスワードの入力を求められ、XP HOMEマシンから共有にアクセスできました！

したがって、要約：キャッシュされた資格情報には何らかの問題があり、それらを削除する明白な方法はありません（ユーザーアカウントのネットワークパスワードマネージャーにも何も表示されませんでした）。したがって、コンピューター名を一時的に変更し、元に戻すと、いくつかの問題が修正される可能性があります。

私はこれらのようなフォーラムでいくつかの同様の問題に遭遇しましたが、私のものと同じものはありませんでした。

Server 2008 R2ボックスを更新してServer 2012 R2にアップグレードすると、この問題が発生しました。Credentials Managerに移動し、Windows Credentials-> Generic Credentialsを削除して問題を解決しました。

私の場合、驚いたことに、Windows 8.1でSMB 1.0サポート機能を有効にすることに加えて、DNSキャッシュをフラッシュする必要があることがわかりました。これは、ドメインから切断されたドメインに参加しているコンピューターでした。

他のケースでは、ドメインに参加していないコンピューターでDNSキャッシュをフラッシュしても解決しませんでした。しかし、奇妙なことに、完全修飾名\\Name.は機能し\\Nameなかったときに機能しました（この息子を最初のマシンで試したわけではありません）。ここで何が問題なのかわかりませんが、それはドメイン名の不足に関連していると推測しています。

これは、特定の1つのフォルダーでのみ発生しました。リダイレクトされたフォルダーを使用しているため、オフラインフォルダーが問題の原因であることが判明しました。そのため、Windowsは起動時に文字通り他のユーザーの資格情報でその共有に接続しているため、ログインしているユーザーからの接続を拒否します。

使用した解決策は、オフライン同期をオフにすることでした。

ネットワークACLである可能性があります。私が働いていたある環境では、ポート445をブロックするように変更されました。

\ hostname \ share

• クライアントはTCP / IPポート445でSMB経由で接続しようとしました
• ネットワークACLによってブロックされています
• クライアントが接続に失敗する

\ hostname.fqdn \ share

• クライアントはTCP.IPポート445でSMB経由で接続しようとしました
• ネットワークACLによってブロックされています
• クライアントはポート139でNetBT経由で接続します
• 接続成功

そのため、FQDNへの接続がNetBTを使用しようとし、ポート139が開いていたため、成功しました。

したがって、解決策はポート445のブロックを解除することでした。