WS2K8 R2: RDP broken na stroomuitval

[dotacom]

Beste Tweakers,

Gisteren stootte ik op een probleem waar ik vannacht niet goed heb van kunnen slapen. Is ondertussen wel opgelost maar de kern van het probleem is er nog en ik ben er zeker van dat het terug zal komen.

Kleine achtergrond: internationaal MPLS netwerk dat zich uitstrekt over 5 landen. In elk land staan 2 identieke, fysieke servers die productie doen draaien.(HP WS 2K8 R2) Op server 1 draait de actieve productie database & op server 2 een mirror. Op server 2 draaien ook nog enkele Hyper-V VM's waaronder lokale printserver en domain controller. (DC) Alles monitoring software gebruiken wij PRTG.

Gisterenmiddag werd site B getroffen door een stroompanne van een tiental minuten. Gedurende deze periode vlogen ook de routers uit die deze site verbinden met MPLS netwerk. De 2 fysieke servers bleven draaien op UPS maar waren dus netwerkmatig even niet bereikbaar. Nadat stroom terug was, kwamen alle devices mooi terug online wat werd bevestigd door monitoring software.

Alleen RDP-sensor op server 1 gaf aan dat deze in error was. Iets wat op het eerste zicht zeer vreemd is gezien de fysieke server niet heeft uitgelegen tijdens de panne. (heb dit ook gecheckt nogmaals op server zelf via uptime) Netwerkmatig was alles wel in orde en ook de servers konden gepingd worden op IP/Hostname. No biggie dacht ik, RDP service herstarten en klaar. Via iLO nam ik console over en herstartte RDP service wat geen verschil uitmaakte. Hierop heb ik de server manueel gereboot maar ook dit bracht niets op.

Server 2 leek echter wel perfect te draaien en daarop kon nog steeds rechtstreeks naar RDP'en. Iets wat ik ook niet kon begrijpen want server1 & server2 zijn zelfde model en 99% hetzelfde opgezet. Als test werd server 2 ook nogmaals herstart en na een reboot verstoonde deze dezelfde problemen als server 1. (geen RDP modelijk)

Bijkomend probleem is dat niet alleen RDP niet meer werkte, ook de databases konden remote niet meer geraadpleegd worden waardoor in principe de hele fabriek stil lag.

Opmerkelijk, als ik op server 1 de logonserver opvroeg (set l), verwees deze naar de logonserver van site C. Wat niet zou mogen gezien hij de lokale DC als logonserver zou moeten gebruiken. Een ping naar "<domain>.group" resulteerde ook in een reply van de DC van site C. Waarom deze DC geselecteerd werd als logonserver is mij een raadel en kan ik niet verklaren. Op een gegeven moment verloor ook server 1 zijn statisch ingesteld IP adres en verkreeg een 169-adres, wat ik ook niet kan verklaren. Bij het checken via de GUI werd bevestigd dat IP op statisch stond ingesteld maar alle instellingen waren blanco.

Hierop vulde ik terug de correcte IP-instellingen in voor deze server. Achteraf voerde ik opnieuw ping uit naar "<domain>.group" en kreeg nu wel reply van de lokale DC. Nadien lukte het terug om te RDP'en in de server en werkte alles terug. Op server 2 werd dan ongeveer hetzelfde uitgevoerd. Aangezien deze server wel nog zijn statisch IP had, werd deze tijdelijk op DHCP gezet & nadien terug op statisch met juiste IP. Nadien kon ook hier terug in geRDP'd worden.

Iemand die een logische verklaring heeft voor bovenstaand verhaal? Heb mij al gek gezocht via google. Windows updates zijn ook uitgesloten. Ik vind wel gelijkaardige topics op fora maar deze zijn allemaal niet beantwoord.

Enkele "interessante" events op server 1:

* Event 1067, TerminalServices RemoteConnectionManager --> The terminal server cannot register 'TERMSRV' Service Principal Name to be used for server authentication. The following error occured: The specified domain either does not exist or could not be contacted.

* Event 5719 NETLOGON -->This computer was not able to set up a secure session with a domain controller in domain <domain> due to the following:
There are currently no logon servers available to service the logon request.
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.

* Event 461 --> CPQTeamMP PROBLEM: 802.3ad link aggregation (LACP) has failed. ACTION: Ensure all ports are connected to LACP-aware devices.

[MAX3400]

Ik lees een lang verhaal en ga proberen iets te zeggen over wat ik ervan begrijp.

Als eerste je eventlogs; 1067 & 5719 zijn zeker verklaarbaar als Server 1 eerder is opgestart dan de VM's op Server 2. Dat is dan meteen het nadeel van een gevirtualiseerde DC op Server 2. En omdat Terminal Server Services waarschijnlijk zijn afgeconfigureerd op FQDN en met Domain/Universal Groups, kon je er dus niet netjes heen via RDP.

Dat bepaalde machines (ongeacht welke site) een andere DC proberen te zoeken, kan jij vast wel verklaren middels je eigen infrastructuur zoals Sites & Services. Ik vind het niet meer dan logisch dat Server 1 een DC probeert te zoeken anders dan op Server 2 als Server 2 (nog) niet reageer zoals ik zojuist schetste.

Dat je IP-configuratie om zeep was; lastig verhaal maar hier heb je (voor een volgende keer) vast wel een oplossing voor? Want wat nou als je er remote helemaal niet meer bij kan; dan moet je toch ook de auto/vliegtuig in om het issue op te lossen? Neem aan dat er een goede System State Backup bestaat op elke site?

Hoor graag of er zaken zijn die ik verkeerd heb begrepen of dat je eventueel aanvullende info hebt hierover

[Glashelder]

Windows valt terug op 169 adressen als het merkt dat het statisch ingestelde IP adres al in gebruik is, en inderdaad, dat gebeurd pas bij een reboot. Dat kan wellicht veroorzaakt zijn doordat je LACP configuratie is omgevallen. Het is niet toevallig zo dat iemand LACP heeft ingesteld en vergeten is de config te saven?

[dotacom]

MAX3400 schreef op woensdag 26 augustus 2015 @ 08:18:
Ik lees een lang verhaal en ga proberen iets te zeggen over wat ik ervan begrijp.

Als eerste je eventlogs; 1067 & 5719 zijn zeker verklaarbaar als Server 1 eerder is opgestart dan de VM's op Server 2. Dat is dan meteen het nadeel van een gevirtualiseerde DC op Server 2. En omdat Terminal Server Services waarschijnlijk zijn afgeconfigureerd op FQDN en met Domain/Universal Groups, kon je er dus niet netjes heen via RDP.

Dat bepaalde machines (ongeacht welke site) een andere DC proberen te zoeken, kan jij vast wel verklaren middels je eigen infrastructuur zoals Sites & Services. Ik vind het niet meer dan logisch dat Server 1 een DC probeert te zoeken anders dan op Server 2 als Server 2 (nog) niet reageer zoals ik zojuist schetste.

Dat je IP-configuratie om zeep was; lastig verhaal maar hier heb je (voor een volgende keer) vast wel een oplossing voor? Want wat nou als je er remote helemaal niet meer bij kan; dan moet je toch ook de auto/vliegtuig in om het issue op te lossen? Neem aan dat er een goede System State Backup bestaat op elke site?

Hoor graag of er zaken zijn die ik verkeerd heb begrepen of dat je eventueel aanvullende info hebt hierover

Initieel werd er naar server 2 niet gekeken omdat die volgens monitoring systeem normaal draaide. Het RDP-probleem op server 1 is dus "ontstaan" terwijl de DC aanstond op server 2. (switches/routers waarop deze 2 servers waren aangesloten hebben wel uitgelegen tijdens stroompanne). Ik ga ervan uit dat ik ten allen tijde aan de server kan via de iLO. Er is ook bewust gekozen om 2 fysieke servers/site op te zetten indien het toch zou voorkomen dat één server niet meer boot er snel gefailoverd kan worden naar andere.

[dotacom]

Glashelder schreef op woensdag 26 augustus 2015 @ 08:28:
Windows valt terug op 169 adressen als het merkt dat het statisch ingestelde IP adres al in gebruik is, en inderdaad, dat gebeurd pas bij een reboot. Dat kan wellicht veroorzaakt zijn doordat je LACP configuratie is omgevallen. Het is niet toevallig zo dat iemand LACP heeft ingesteld en vergeten is de config te saven?

Nee daar komt niemand aan. Ik ben hier wel op volgend HP topic gestuit die mogelijks bovenstaand probleem verklaard: http://h30499.www3.hp.com...td-p/3908359#.Vd1jofbtlBc

Misschien eens kijken om NIC teaming firmware up te graden. Model dat wij hebben draaien is ML350p G8.

[MAX3400]

Domme vraag en mogelijk wederom niet door mij begrepen maar als je LACP 802.3ad hebt draaien, wil dat toch niet per definitie zeggen dat als een switch ermee stopt, dat de communicatie tussen de machines intact blijft? Uit mijn hoofd; als je 4 lijntjes in trunk hebt liggen en 1 van de 4 lijntjes is defect (stel doorgeknipt), dan is er toch een gerede kans dat de hele trunk eruit vliegt? Dat er dan ook switches zijn die het laten afweten, helpt niet met je connectivity

Dat je misschien iets met je firmware kan gaan doen, lijkt me ook zinvol inderdaad. Laat even weten of het gelukt is

[Gomez12]

Heb je wel alle caches etc van je client geleegd toen je server 1 probeerde te pingen? Want ik vermoed dat er daar nog wat in zat waardoor je resultaat kreeg.

Terwijl server 1 en 2 sneller op het wereldwijde gedeelte zaten dan dat ze elkaar zagen (waardoor ze overswitchten naar wereldwijde masters) waardoor je niet meer kon rdp'en.

Op zich klinkt het allemaal niet zo spannend, alleen was het ietwat ongewenst gedrag. Het is mij alleen even onduidelijk wat er nu wel gewenst gedrag zou zijn en wat daarvoor ingesteld is.
Als je bijv al je servers op dhcp hebt staan en je wereldwijde verbinding is sneller in de lucht en staat dhcp toe en een conculega heeft een dhcp server draaien dan is het allemaal volgens het boekje gegaan.
Alleen het was onverwacht en ongewenst, maar het klopte dan wel.

[dotacom]

Gomez12 schreef op woensdag 26 augustus 2015 @ 21:12:
Heb je wel alle caches etc van je client geleegd toen je server 1 probeerde te pingen? Want ik vermoed dat er daar nog wat in zat waardoor je resultaat kreeg.

Terwijl server 1 en 2 sneller op het wereldwijde gedeelte zaten dan dat ze elkaar zagen (waardoor ze overswitchten naar wereldwijde masters) waardoor je niet meer kon rdp'en.

Op zich klinkt het allemaal niet zo spannend, alleen was het ietwat ongewenst gedrag. Het is mij alleen even onduidelijk wat er nu wel gewenst gedrag zou zijn en wat daarvoor ingesteld is.
Als je bijv al je servers op dhcp hebt staan en je wereldwijde verbinding is sneller in de lucht en staat dhcp toe en een conculega heeft een dhcp server draaien dan is het allemaal volgens het boekje gegaan.
Alleen het was onverwacht en ongewenst, maar het klopte dan wel.

De servers draaien niet op DHCP maar zijn beiden statisch ingesteld.
Je 2e alinea versta ik niet goed: "Terwijl server 1 en 2 sneller op het wereldwijde gedeelte zaten dan dat ze elkaar zagen (waardoor ze overswitchten naar wereldwijde masters) waardoor je niet meer kon rdp'en."

Initieel was er alleen "probleem" met server 1. Deze is dan herstart geweest terwijl server 2 nog steeds aan stond & waar ook de DC virtueel op draait. Waarom zou deze dan overschakelen naar een andere DC en niet diegene die lokaal staat in die site?