We voeren in sommige scripts een Get-ADGroupMember -Recursive uit en vorige week begonnen enkele van deze scripts ineens te falen vanwege een timeout. Uit onze logs kunnen we opmaken dat voordat de problemen begonnen, de lookuip telkins in enkele seconden gebeurde, en nu lopen we ineens met regelmaat tegen een timeout aan, en die is als ik me niet vergis 10 minuten!
Wat het nog vreemder maakt is dat we 1 domeincontroller hebben waartegen dit commando nog wel snel loopt. Als we die controller als -Server argument meegeven, dan hebben we alsnog resultaat op enkele seconden. De andere 4 DCs doen er allemaal veel langer over en eindigen regelmatig in een timeout.
Alle servers zitten op hetzelfde patch niveau en zijn op dit moment Server 2016, daar kunnen we de oorzaak dus al niet gaan zoeken. Een herstart van de controllers brengt ook geen oplossing. De controller die nog snel reageert durven we op dit moment ook niet herstarten, al gaan we er de installatie van security updates, en hun benodigde herstart, ook niet voor tegenhouden.
Wat ik online vind zijn vooral verklaringen die op alle servers traag zouden moeten werken, zoals SIDs in de groep die niet meer geresolved kunnen worden of omdat er andere domeinen in het spel zouden zijn. Maar niets waarbij het op de ene DC wel snel zou zijn en de andere niet.
Iemand die me in de juiste richting van een oplossing kan wijzen?
Wat server resources betreft: CPU gebruik en geheugen gebruik zitten niet tegen de 100% aan, ver van zelfs. Zeker na een reboot, wanneer het geheugen nog geen 20% van de capaciteit inneemt en de CPU onder de 25% blijft is het cmdlet ook traag. Voer ik het cmdlet lokaal uit, op een DC die traag reageert in de scripts, heb ik ook onmiddelijk resultaat. De DC die snel reageert zit in hetzelfde subnet als 2 van de trage DCs, dus daar zit ook geen verschil in bijv. firewall. Verhuizen van ESXi host heeft ook geen effect.
Wat het nog vreemder maakt is dat we 1 domeincontroller hebben waartegen dit commando nog wel snel loopt. Als we die controller als -Server argument meegeven, dan hebben we alsnog resultaat op enkele seconden. De andere 4 DCs doen er allemaal veel langer over en eindigen regelmatig in een timeout.
Alle servers zitten op hetzelfde patch niveau en zijn op dit moment Server 2016, daar kunnen we de oorzaak dus al niet gaan zoeken. Een herstart van de controllers brengt ook geen oplossing. De controller die nog snel reageert durven we op dit moment ook niet herstarten, al gaan we er de installatie van security updates, en hun benodigde herstart, ook niet voor tegenhouden.
Wat ik online vind zijn vooral verklaringen die op alle servers traag zouden moeten werken, zoals SIDs in de groep die niet meer geresolved kunnen worden of omdat er andere domeinen in het spel zouden zijn. Maar niets waarbij het op de ene DC wel snel zou zijn en de andere niet.
Iemand die me in de juiste richting van een oplossing kan wijzen?
Wat server resources betreft: CPU gebruik en geheugen gebruik zitten niet tegen de 100% aan, ver van zelfs. Zeker na een reboot, wanneer het geheugen nog geen 20% van de capaciteit inneemt en de CPU onder de 25% blijft is het cmdlet ook traag. Voer ik het cmdlet lokaal uit, op een DC die traag reageert in de scripts, heb ik ook onmiddelijk resultaat. De DC die snel reageert zit in hetzelfde subnet als 2 van de trage DCs, dus daar zit ook geen verschil in bijv. firewall. Verhuizen van ESXi host heeft ook geen effect.
No keyboard detected. Press F1 to continue.