Server 2003 ping domain.local verkeerde server?

[marc181982]

Opzet :
DC1 : SBS2003
DC2 : SQL
TS : Terminal server 2003

Onlangs paar problemen met DNS, DC1 is primary DC, DC2 is de secondary DC. Het kwam de laatste tijd voor dat de DNS service regelmatig stopte op DC2. Het probleem was dat de Terminal server DC2 als logon server gebruikte. Oftewel als DC2 vast liep konden de gebruikers zich niet meer aanmelden op de terminal server.

Dit is ondertussen omgezet zodat de SBS2003 als logon server word gebruikt zodat in de tussentijd het probleem konden oplossen.
(nltest /Server:client0 /SC_RESET:domain.local\dc1)

(vermoeden is dat de sql te belast is om op dat moment de aanmeldingen af te handelen. Weet dat het niet aan te raden is om een SQL server als secondary DC in te stellen, vorige systeembeheerder heeft dit zo geconfigureerd)


Als er nu een ping word uitgevoerd naar domain.local, dan komt er een response van de sql server.
Is dit aan te passen zodat de SBS2003 server als '1e DNS' server word gebruikt?
Is dit aan te passen door de priority aan te passen van de SRV records? Oftewel SRV record voor DC1 een priority te geven van 10 en DC2 en priority van 20?

Primary DNS in de DHCP en overige servers is het ipadres van de SBS2003 server. In het SOA record is de SBS2003 als primary server opgegeven.

[ Voor 43% gewijzigd door marc181982 op 08-01-2012 17:50 ]

[degroot]

Op de sql debdomain services deinstalleren. Je kan in een sbs omgeving maar 1 dc ( eigenlijk gc) hebben. Je aanmeldserver moet dus altijd de dc1 zijn

[marc181982]

degroot schreef op zondag 08 januari 2012 @ 18:39:
Op de sql debdomain services deinstalleren. Je kan in een sbs omgeving maar 1 dc ( eigenlijk gc) hebben. Je aanmeldserver moet dus altijd de dc1 zijn

Je kunt zonder problemen meerdere dc's in een domain plaatsen die al een SBS server bevat, het gaat alleen verkeerd als je een tweede SBS server wilt installeren. Zelfs meerdere GC's is mogelijk, enigste waar er rekening mee moet worden gehouden is dat alleen de SBS server als enigste in het domein alle FSMO rollen bevat.

Bekende SBS myth : http://blogs.technet.com/...dcs-in-an-sbs-domain.aspx

Deinstalleren van de domain-services is geen optie, stel dat de SBS server crashed dan kunnen de gebruikers zich alsnog aanmelden. Op de sql server draait een database waar dagelijks in word gewerkt.

[ Voor 35% gewijzigd door marc181982 op 08-01-2012 19:36 ]

[Question Mark]

Zou je niet gewoon de issue's met de SQL-server op willen lossen in plaats van allemaal vreemde workarounds toe willen gaan passen?

marc181982 schreef op zondag 08 januari 2012 @ 17:39:
Het kwam de laatste tijd voor dat de DNS service regelmatig stopte op DC2.
....
Oftewel als DC2 vast liep konden de gebruikers zich niet meer aanmelden op de terminal server.

Die server heeft een probleem, pak dat probleem gewoon aan

[marc181982]

Question Mark schreef op maandag 09 januari 2012 @ 15:08:
Zou je niet gewoon de issue's met de SQL-server op willen lossen in plaats van allemaal vreemde workarounds toe willen gaan passen?


[...]

Die server heeft een probleem, pak dat probleem gewoon aan

Graag zelfs, liefst opnieuw de rollen installeren maar de server kan aankomende weken niet opnieuw worden gestart i.v.m. werkzaamheden 24/7 op de sql server. Moet dus echt even een workaround voor dit probleem zoeken.

2e probleem is te weinig geheugen, regelmatig meldingen low virtual memory (geen memory leak of programma's die abnormaal veel geheugen gebruiken)
Stel dat het probleem opgelost is ben ik bang dat de server het niet gaat trekken.
Server is 32-bit, max geheugen zit erin. Wil helaas niet naar een nieuwe server, upgrade naar 2008 64-bit aanbevolen maar helaas.

[ Voor 4% gewijzigd door marc181982 op 09-01-2012 19:53 ]

[3DDude]

met question mark.
zoek in de eventlogs naar wat het probleem is op die sql.

Nou snap ik overigens niet waarom dat een dc is ?
Heeft dat een specifieke reden nog ?

en je low virtual mem = pagefile switch die eventueel naar een niet te volle hdd ? of vergroot de pagesize is 1.5 tot 2 keer je Ram kan wel.
dus 4gb ram: page 6 a 8.

[ Voor 33% gewijzigd door 3DDude op 09-01-2012 21:34 ]

[akimosan]

Aanpassen priority op de SRV records kan wel. Zou wel goed een export maken welke records je allemaal aanpast, zodat je weer terug kunt aanpassen.

Het doet waarschijnlijk niets voor je domain.local = DC2 verhaal aangezien dat op round robin gaat. Maar je DC1 zal wel als eerste voor queries worden aangesproken waar het de services betreft (LDAP, KERBEROS, etc) dus dat biedt wat lucht.

Wat je geheugen betreft (misschien een kleinere pool aan geheugen reserveren voor je SQL server) als deze dan gaat swappen en performance verlies kent, dan heb je al eerder aangegeven waar dat aan ligt. Het is een management beslissing om geen upgrade naar 2008 uit te voeren en de server van meer geheugen te voorzien.

De SQL server is duidelijk geen 24x7 server anders had je wel HA of meer redundancy aangebracht, ik neem aan dat de SQL ook onderhoudstaken draait als backup, etc.
Eerder zeg je dat er overdag op wordt gewerkt, dus een reboot 's avonds of in het weekend zou wel kunnen? Dan valt dat toch in te plannen? Zet je een andere DC in en verwijder je Domain Services van de SQL server.

[marc181982]

akimosan schreef op dinsdag 10 januari 2012 @ 00:25:
Aanpassen priority op de SRV records kan wel. Zou wel goed een export maken welke records je allemaal aanpast, zodat je weer terug kunt aanpassen.

Het doet waarschijnlijk niets voor je domain.local = DC2 verhaal aangezien dat op round robin gaat. Maar je DC1 zal wel als eerste voor queries worden aangesproken waar het de services betreft (LDAP, KERBEROS, etc) dus dat biedt wat lucht.

Wat je geheugen betreft (misschien een kleinere pool aan geheugen reserveren voor je SQL server) als deze dan gaat swappen en performance verlies kent, dan heb je al eerder aangegeven waar dat aan ligt. Het is een management beslissing om geen upgrade naar 2008 uit te voeren en de server van meer geheugen te voorzien.

De SQL server is duidelijk geen 24x7 server anders had je wel HA of meer redundancy aangebracht, ik neem aan dat de SQL ook onderhoudstaken draait als backup, etc.
Eerder zeg je dat er overdag op wordt gewerkt, dus een reboot 's avonds of in het weekend zou wel kunnen? Dan valt dat toch in te plannen? Zet je een andere DC in en verwijder je Domain Services van de SQL server.

Ondertussen al de priority van de srv records aangepast, de queries gaan nu eerst naar de sbs server.

Merendeel van de gebruikers werkt overdag op de server, meestal zijn er 2/3 die er avonds/nachts op werken.
MKB is het budget meestal laag, geen geld voor een extra server. Soms kan het niet anders.

Dat de gebruikers er 24/7 op werken is tijdelijk, zoals nu uitziet 2 tot 3 weken.

Backup taken worden nachts uitgevoerd, de gebruikers die op dat moment aan het werk zijn hebben hier geen last van.

[ Voor 5% gewijzigd door marc181982 op 10-01-2012 09:21 ]

[Jazzy]

Waarom verwijder je AD niet van die server?

[_H_G_]

marc181982 schreef op dinsdag 10 januari 2012 @ 09:19:
Ondertussen al de priority van de srv records aangepast, de queries gaan nu eerst naar de sbs server.

Maar het volgende is hiermee toch niet opgelost?

marc181982 schreef op zondag 08 januari 2012 @ 17:39:
Als er nu een ping word uitgevoerd naar domain.local, dan komt er een response van de sql server.

Al hoeft het geen probleem voor je tijdelijke workaround te zijn, maar ik zou eens een keer dcdiag op je sbs2003 draaien.

[marc181982]

_H_G_ schreef op dinsdag 10 januari 2012 @ 10:34:
[...]

Maar het volgende is hiermee toch niet opgelost?

[...]

Al hoeft het geen probleem voor je tijdelijke workaround te zijn, maar ik zou eens een keer dcdiag op je sbs2003 draaien.

Dcdiag en Netdiag zijn al gedraaid op de server, geen fouten. DNS op de SBS server draait zonder problemen

[marc181982]

Jazzy schreef op dinsdag 10 januari 2012 @ 09:23:
Waarom verwijder je AD niet van die server?

Wil deze graag houden als soort van 'backup-dc' zodat de gebruikers door kunnen werken als in het ergste geval de SBS server crashed .

[ Voor 38% gewijzigd door marc181982 op 10-01-2012 12:46 ]

[Jazzy]

marc181982 schreef op dinsdag 10 januari 2012 @ 12:41:
[...]


Wil deze graag houden als soort van 'backup-dc' zodat de gebruikers door kunnen werken als in het ergste geval de SBS server crashed .

Doorwerken dan zonder mail, bestanden, printers, DHCP en alle andere taken die de SBS server vervult. Je zou het zelfs schijnveiligheid kunnen noemen, omdat je er in geval van nood maar weinig profijt van hebt.

Als je het mij vraagt ben je beter af met gezond functionerende servers die niet vastlopen of op andere manieren voor problemen zorgen. Om de instabiliteit en het feit dat de tweede DC ook SQL server is zou ik AD van deze server verwijderen. De SBS 2003 server is prima in staat om zelf DC, DNS, DHCP en alle andere rollen te vervullen.

Zorg dat je bij uitval van de SBS 2003 server een goede backup kunt restoren om snel weer in de lucht te zijn. Daar heb je meer aan dan 2 van de vele rollen in je netwerk redundant proberen te houden.