Server 2008 R2 Group policy en Netlogon meldingen

[Postmen]

Hallo,
Ik zit al 3 weken met het volgende probleem:

We hebben een VMWare ESX omgeving (9 hosts) met daarop ongeveer 80 servers. Het merendeel daarvan draait Server 2008 R2 (ongeveer 60).

Sinds 3 weken komt er op 3 van deze virtuele servers de volgende melding in de System Log:
(Ik heb de namen van het domein en de servernamen geanonimiseerd)

EVENT ID: 5719 (NETLOGON)
This computer was not able to set up a secure session with a domain controller in domain DOMEIN due to the following:
The remote procedure call was cancelled.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

ADDITIONAL INFO
If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain.

EVENT ID: 5783 (NETLOGON)
The session setup to the Windows NT or Windows 2000 Domain Controller \\DC2.DOMEIN.local for the domain DOMEIN is not responsive. The current RPC call from Netlogon on \\APPLSRV1 to \\DC2.DOMEIN.local has been cancelled.

EVENT ID: 1006 (GROUPPOLICY)
The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.
SupportInfo1 1
SupportInfo2 5288
ProcessingMode 0
ProcessingTimeInMilliseconds 903199
ErrorCode 81
ErrorDescription Server Down
DCName

Het probleem doet zich niet voor bij het opstarten, maar komt op willekeurige tijdstippen, behalve bij het opstarten. Het gaat om 1 Oracle Weblogic Productieserver, 1 Oracle Weblogic TEST Server en een andere Productie applicatieserver. Wanneer het probleem optreedt, zijn de Oracle Applicaties op de betreffende server niet meer beschikbaar. Om het probleem snel op te lossen, rebooten we de betreffende server zodat de gebruikers weer verder kunnen.

Op de TEST applicatieserver heb ik uitgebreider onderzoek kunnen doen. Opvallende zaken:
1. Op het moment dat het probleem zich voordoet, kan ik met NSLookup alle records uit de DNS opvragen. Ook de service records van de DC's (2 stuks)

2. Op het moment dat het probleem zich voordoet, kan ik op de betreffende server met NLtest de volgende informatie opvragen:

code:

nltest /dsgetsite 
Default-First-Site-Name
The command completed successfully

code:

nltest /dsgetdc:DOMEIN
           DC: \\DC1
      Address: \\10.100.102.51
     Dom Guid: 0f2228b3-c05e-4f08-be1c-9b9cb4c53b7e
     Dom Name: DOMEIN
  Forest Name: DOMEIN.local
 Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_FOREST CLOSE_S
ITE FULL_SECRET WS
The command completed successfully

code:

nltest /sc_query:DOMEIN
Flags: 30 HAS_IP  HAS_TIMESERV
Trusted DC Name \\DC1.DOMEIN.local
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

code:

nltest /dclist:DOMEIN
Deze geeft een Time-OUT en kan niet worden opgevraagd. De precieze foutmelding kan ik op dit moment niet achterhalen, omdat de servers op dit moment in de lucht zijn.

Wat heb ik allemaal geprobeert: (alle acties op de TEST Oracle server)
- Move naar andere ESX host
- E1000 netwerkkaart toegekend ipv VMXNET3
- Alle TCP Offload settings in de netwerkkaart op DISABLED
- Uninstall van KB3002657 op de domeincontrollers
- NETLOGON debuglogging aangezet (nltest /DBFlag:0x2080FFFF)
Output hiervan:

code:

08/16 07:29:04 [MISC] DsGetDcName function called: Dom:DOMEIN.local Acct:(null) Flags: FORCE DS BACKGROUND RET_DNS 
08/16 07:29:04 [MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c01ffff1
08/16 07:29:04 [MAILSLOT] NetpDcPingListIp: DOMEIN.local: Sent UDP ping to 10.100.102.52
08/16 07:29:04 [MISC] NetpDcGetName: NetpDcGetNameIp returned 0
08/16 07:29:04 [MISC] LoadBalanceDebug (Flags: FORCE DS IP BACKGROUND DNS RET_DNS ): DC=DC2, SrvCount=2, FailedAQueryCount=0, DcsPinged=1, LoopIndex=0
08/16 07:29:04 [MISC] DsGetDcName function returns 0: Dom:DOMEIN.local Acct:(null) Flags: FORCE DS BACKGROUND RET_DNS 
08/16 07:29:04 [MISC] DsGetDcName function called: Dom:DC2.DOMEIN.local Acct:(null) Flags: LDAPONLY RET_DNS 
08/16 07:29:04 [MISC] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c01ffff1
08/16 07:29:04 [CRITICAL] NetpDcGetNameIp: DC2.DOMEIN.local: No data returned from DnsQuery.
08/16 07:29:04 [MISC] NetpDcGetName: NetpDcGetNameIp returned 1355
08/16 07:29:04 [CRITICAL] NetpDcGetName: DC2.DOMEIN.local: IP and Netbios are both done.
08/16 07:29:04 [MISC] DsGetDcName function returns 1355: Dom:DC2.DOMEIN.local Acct:(null) Flags: LDAPONLY RET_DNS

- ESET Antivirus disabled
- VMWare Tools deinstallatie uitgevoerd en lagere versie geinstalleerd

Na deze laatste actie is de server nog niet weer 'down' geweest, maar dit is ook pas deze ochtend uitgevoerd.

Op diverse fora zie ik hetzelfde probleem voor bij komen, echter zonder oplossing. Iemand die mij wel een oplossing kan geven of die nog een briljante tip heeft?

[Brahiewahiewa]

Lijkt er op dat DC2 niet te bereiken is

C:\Users\Brahiewahiewa>net helpmsg 1355

The specified domain either does not exist or could not be contacted.

[Postmen]

Klopt, maar waardoor? Alle andere server hebben dit probleem niet, en zoals je kan zien in de NLTEST meldingen kan ik op dat moment allerlei zaken opvragen in het domein, behalve de DCLIST.

DNS werkt op dat moment wel, kan ook gewoon de service records opvragen. Ik heb de TEST applicatieserver ook nog uit het domein verwijdert en opnieuw gejoined, ook geen resultaat.

[Wom]

Heb in het verleden iets soortgelijks voor gehad, maar het enige wat ik er van kan terugvinden is een link naar een KB bij Microsoft.

https://technet.microsoft.com/en-us/library/cc961803.aspx

To determine the cause of trust relationship problems
Log on with a local account.
Set Net Logon flags by using the Nltest tool as follows:
nltest /dbflag:0x2000ffff.
Run nltest as follows : nltest /sc_reset:< domain name to which you think your computer is joined > .
The % windir %\debug\netlogon.log explains why the secure channel setup is not possible. One possible reason is that SYSVOL isn't ready on the computer. By examining the Netlogon.log file, you can find the following error:
08/30 10:15:19 [MAILSLOT] Returning paused to 'Reskit1' since: SysVol not ready

Mijn geheugen helpt me niet, maar volgens mij had het te maken met een trust van het computer acount. Al geprobeer die opnieuw aan te maken? Kan een mismatch zijn van de trusted pwds.

[Postmen]

Ik heb de Server al uit het domein gehad en opnieuw toegevoegd. Ik kan wanneer het probleem zich weer voordoet, de "nltest /sc_reset:< domain name to which you think your computer is joined >" optie proberen. Ik kan het probleem niet zomaar reproduceren, het duurt na een reboot ongeveer 13 uur (maar is verschillend) voordat het probleem zich weer voordoet. Op 1 van de productie servers heeft het probleem zich al meer dan 24 uur niet voorgedaan, de andere reboot ik nu elke nacht om 03.00u zodat deze overdag beschikbaar is.

EDIT:
Zojuist is de server weer 'plat' gegaan. Ik heb nltest /sc_reset:DOMEIN geprobeert, met het volgende resultaat:

code:

nltest /sc_reset:DOMEIN
I_NetLogonControl failed: Status = 1311 0x51f ERROR_NO_LOGON_SERVERS

In de netlogon.log staat het volgende:

code:

08/17 21:36:41 [MISC] DbFlag is set to 2000ffff
08/17 21:37:00 [SESSION] NETLOGON_CONTROL_REDISCOVER function received.
08/17 21:37:45 [CRITICAL] DOMEIN: NlTimeoutSetWriterClientSession timed out: 0 258
08/17 21:37:45 [CRITICAL] NetrLogonControl2: Can't become writer of client session.

EDIT2:
Zojuist aan het stoeien geweest met PortQrUI. Port 135 op de DC1 is niet te openen vanaf de Applicatieserver. Andere poorten lijken wel te werken. Firewall staat uitgeschakeld, ik zal Antivirus eens verwijderen van de server.

[ Voor 44% gewijzigd door Postmen op 17-08-2015 23:04 ]

[Brahiewahiewa]

Postmen schreef op maandag 17 augustus 2015 @ 15:28:
Klopt, maar waardoor? Alle andere server hebben dit probleem niet, en zoals je kan zien in de NLTEST meldingen kan ik op dat moment allerlei zaken opvragen in het domein, behalve de DCLIST.

DNS werkt op dat moment wel, kan ook gewoon de service records opvragen. Ik heb de TEST applicatieserver ook nog uit het domein verwijdert en opnieuw gejoined, ook geen resultaat.

Wat doet

tracert <ip van DC2>

[Postmen]

Tracert, Ping, alles werkt op dat moment gewoon. DNS werkt op dat moment ook. Ik heb gisteravond de ESET antivirus van de Test applicatieserver verwijdert, Servers is tot nu toe niet meer onbereikbaar geweest. Lijkt dus vooralsnog de oplossing van het probleem te zijn.

Bedankt WOM voor de tip van NLTEST /SC_RESET. Deze gaf me meer informatie om te zoeken naar de specifieke foutmelding die ik hierboven heb gepost. Die zoekactie verwees me naar de tool http://www.microsoft.com/...oad/details.aspx?id=24009. De port query gaf een melding op port 135 waarna ik dit forumtopic (https://www.petri.com/for...work-problem-outbound-tcp) vond, waarin iemand min of meer hetzelfde probleem had, waarin F-Secure de boosdoener was.

Ik had ESET al wel uitgeschakeld gehad, maar uiteindelijk lijkt een de-installatie de oplossing te zijn. Mocht het probleem zich nog wel opnieuw voordoen, laat ik het weten!

[ Voor 6% gewijzigd door Postmen op 18-08-2015 12:36 ]