나는이 문제에 대해 여러 가지 다른 질문을 보았지만 상황이 동일하지 않거나 솔루션이 작동하지 않으므로 제안 사항이 있는지 알기 위해 게시 할 것이라고 생각했습니다.
다양한 도메인 PC 및 랩톱에서 “lewis.local 2 (인증되지 않음)”이라는 연결 이름을 임의로 부여하는 것으로 보입니다. lewis.local은 도메인이며 네트워크 유형 로고가 일반적으로 표시되는 느낌표를 제공합니다.
이것은 VPN을 통해 연결할 때마다 발생하는 것으로 보입니다.
우리의 설정은 다음과 같습니다
- Windows Server 2003 R2 (x32)를 실행하는 2 대의 서버
- 주 서버에는 AD, DNS 및 DHCP가 설치되어 있습니다.
- 약 30 개의 클라이언트 컴퓨터에있는 IPv4 (일부 유선, 일부 무선)
아무도 솔루션에 대한 생각이 있다면 감사하겠습니다. AD 서버 역할을 제외한 모든 시스템을 제거하고 모든 시스템을 재설정하고 아무것도 시도하지 않았습니다.
대부분의 경우 도메인 연결처럼 작동하는 것을 방해하지는 않지만 번거 롭습니다!
또한 관련이 있는지 여부는 알 수 없지만 DHCP 서버는 클라이언트에 IP 주소를 발급하는 데 오랜 시간이 걸리는 것 같습니다.
답변
이 문제의 원인 중 하나는 컴퓨터 계정 암호가 도메인 컨트롤러와 동기화되지 않은 경우입니다.
예를 들어 Active Directory의 컴퓨터 계정을 수동으로 제거했다가 다시 추가하거나 클라이언트 컴퓨터가 이전 시점으로 복원 된 경우 (시스템 계정 암호는 30 일마다 자동으로 변경됨)가 발생할 수 있습니다.
나를 위해 일한 Reset-ComputerMachinePassword것은 상승 된 (!) PowerShell에서 실행하여 컴퓨터 계정 암호를 수동으로 재설정하는 것이 었습니다 .
PS> Reset-ComputerMachinePassword -Credential MYDOMAIN\SomeDomainAdminAccount
재부팅하지 않으려면 재부팅하거나 네트워크 카드를 비활성화했다가 다시 활성화 한 후 (인증되지 않은) 메모를 사라 야합니다.
답변
문제가있는 각 컴퓨터에서 다음 명령을 실행하십시오.
netsh winsock 재설정 카탈로그
netsh int ipv4 reset reset.log
netsh int ipv6 reset reset.log
PC를 다시 시작한 다음 컴퓨터를 도메인에 다시 가입시킵니다.
답변
도메인 이름에서 TLD를 제거하고 재부팅하면 재부팅 후 다시 추가되고 모두 양호해야합니다.
예 : company.local이 로컬을 제거하고 재부팅하면 재부팅 후 다시 추가됩니다.
답변
나는 같은 문제가 있었고 PC와 DC 사이의 방화벽이 PC로 135,389 등을 차단하고있는 것으로 판명되었습니다.
그 문제를 찾기 위해 Wireshark를 PC에서 실행하고을 수행했습니다 gpupdate /force. wireshark에서 응답없이 많은 syn 패킷이 DC로 나가는 것을 보았습니다.
방화벽이 수정되면 PC를 재부팅하고 DC에 올바르게 연결할 수 있었고 문제가 해결되었습니다.
답변
컴퓨터와 도메인 사이의 신뢰를 엉망으로 만드는 것 같습니다. 도메인에서 컴퓨터를 제거하고 읽으십시오.
왜 이런 일이 발생했는지 말하기 어렵습니다. DC의 이벤트 로그에 현재 또는이 시간이 시작될 때쯤에 오류 메시지가 있습니까? 네트워크가 변경 되었습니까?
답변
몇 가지 가능한 솔루션 :
- DC에서 DHCP 임대 및 예약을 확인하십시오. 문제가있는 시스템에 대해 여러 개의 항목이있는 경우 각 항목을 한 항목으로 분류하십시오. 그런 다음
ipconfig /release && ipconfig /renew해당 머신에서 실행하십시오 . - 장치 관리자에서 네트워크 어댑터를 제거한 다음 새 하드웨어를 검색하여 NIC를 다시 설치하십시오.
- Windows 방화벽 프로필을 기본값으로
wf.msc복원하십시오. “기본 정책 복원”을 실행 하고 클릭하십시오. - 모든 방화벽을 완전히 비활성화하십시오. Windows 방화벽의 경우
wf.msc“Windows 방화벽 속성”을 실행하고 각 프로필 탭 (도메인, 개인, 공용)에 대해 방화벽 상태를 “끄기”로 설정하십시오.
마지막 옵션은 실제로 수정 된 것은 아니지만 문제 해결에 도움이 될 수 있습니다.
답변
어쩌면 이것은 길을 따라 누군가를 도울 것입니다. 이 문제가 발생했으며 그 이유는 리버베드 스틸 헤드 어플라이언스에서 VLAN이 일치하지 않았기 때문입니다. 리버베드의 In-Path 인터페이스는 라우터의 LAN 포트에 연결되었으며 In-Path 인터페이스는 “VLAN 태그 ID”가 “0”으로 구성되었습니다. 이로 인해 문제가 발생했습니다. 라우터 LAN 인터페이스가 하위 인터페이스 구성 (음성 VLAN 40 및 데이터 / 네이티브 VLAN 1 용)에 있으며 VLAN 태그 ID를 “1”(데이터 / 네이티브)에 할당하여이 문제를 해결할 수있었습니다. 문제가 즉시 해결되었습니다.