Jump to content

Whistleblower

Members
  • Content Count

    368
  • Joined

  • Last visited

Community Reputation

45 Popular

About Whistleblower

  • Rank
    Senior Member
  1. Wie schön frisch und luftig jetzt hier alles ist! Gratulation zum gelungenen Neustart udn danke dafür dass ihr euch die ganez Arbeit hier mit dem Forum macht. Mir gefällt es auf Anhieb gut, werde mich jetz mal ein wenig umsehen.
  2. Wir wissen doch alle, dass deine Suchergebnisse sich von denen von mir oder AndreasWU unterscheiden. Sehr wahrscheinlich ist sein erster Link nicht so hilfreich wie du denkst. Was ist so schwer daran deinen hilfreichen ersten Link einfach hier zu posten anstatt die ganze Zeit so geheimnisvoll rumzuschwurbeln? Du hast ihn gefunden, das ist schön und du hast drei Postings geschrieben ohne die Hilfe die du schon vor dir liegen hattest weiterzugeben? Ich verstehe so ein Verhalten so gar nicht... Hilfreich für AndreasWu ist das wohl kaum, hätte es aber sein können.
  3. Ich habe eher den Eindruck, dass du noch einiges lernen musst, was den Umgang mit anderen angeht. Wenn dir ein Moderator sagt dass du zurück zum Thema kommen sollst, was bringt dich dazu dann ihn dafür anzugreifen? Du gehörst wohl auch zu den Menschen, die den Türsteher in einem Club anblaffen und dann mit ihm diskutieren und sich beschweren warum sie nicht rein dürfen...
  4. So, den Link zur fehlenden Policy habe ich gelöscht, seitdem keine 1030 und 1058 mehr :) Kann ich auch noch das alte GPO selbst löschen (obwohl nicht existent, außer in den Tiefen des AD...?)
  5. Hallo, ich musste gestern alle FSMO-Rollen von unserem "Main"-DC auf einen anderen DC übertragen (bzw. zwangsübernehmen, Übertragung war nicht mehr möglich). Damit waren alle Probleme, die in der Woche zuvor aufgetreten waren (endlose DNS-Fehler, Zielkontoname nicht gefunden, userAccountControl des DCs auf 0x11000 heruntergestuft, ...) soweit behoben. Nach wie vor logt der neue "Main"-DC aber immer noch massenhaft 1030 und 1058 für den Benutzer "SYSTEM" und den Domänenadmin (bei Anmeldung am DC). Details 1058: Ereignistyp: Fehler Ereignisquelle: Userenv Ereigniskategorie: Keine Ereigniskennung: 1058 Datum: 26.10.2011 Zeit: 09:25:42 Benutzer: NT-AUTORITÄT\SYSTEM Computer: xyz Beschreibung: Auf die Datei gpt.ini des Gruppenrichtlinienobjekts cn={14DEEF9B-D9C3-4A2C-A895-202CB6837819},cn=policies,cn=system,DC=xxx,DC=yyy kann nicht zugegriffen werden. Die Datei muss im Pfad <\\xxx.yyy\SysVol\xxx.yyy\Policies\{14DEEF9B-D9C3-4A2C-A895-202CB6837819}\gpt.ini> vorhanden sein. (Das System kann den angegebenen Pfad nicht finden. ). Die Verarbeitung der Gruppenrichtlinie wird abgebrochen. Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp. Details 1030: Ereignistyp: Fehler Ereignisquelle: Userenv Ereigniskategorie: Keine Ereigniskennung: 1030 Datum: 26.10.2011 Zeit: 09:25:42 Benutzer: NT-AUTORITÄT\SYSTEM Computer: xyz Beschreibung: Die Abfrage der Liste der Gruppenrichtlinienobjekte ist fehlgeschlagen. Überprüfen Sie das Ereignisprotokoll auf frühere Fehlermeldungen des Richtlinienmoduls, die die Ursache für dieses Problem beschreiben. Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp. Es wird jedesmal die gleiche Policy {14DEEF9B-D9C3-4A2C-A895-202CB6837819} angemeckert. Korrekterweise, denn der Pfad existiert (zumindest auf dem DC) tatsächlich nicht (mehr). :( Angenommen, ich finde die Policy noch auf den weiteren DCs (2 am anderen Standort) oder in einem Backup - ist es sinnvoll, sie dann einfach stumpf wieder in den Pfad einzufügen? Oder lieber löschen und neu anlegen? [uPDATE] Ich habe gerade noch die anderen DCs kontrolliert, hier ebenfalls 1030 und 1058 für die gleiche Policy, handelt sich also vermutlich um eine Policy, die letzte Woche noch auf dem alten DC angelegt aber nicht mehr korrekt repliziert werden konnte... Wie bekomme ich die wieder sauber aus dem AD raus? Da ich noch weiss, welche Policy das sein müsste, kann ich die schnell neu anlegen...
  6. kein Problem, anbei die relevanten Daten aus der Config... sample.txt
  7. So, das ganze funzt jetzt wie gewünscht! :D Der Test-Router (1712) hat jetzt zwei ISPs, einmal als PPPoE-Dialer (hängt tatsächlich am Internet), einmal über ein VLAN-Interface (109) zu einem (SDSL) WAN-Router (nur in Lab-Umgebung simuliert). Darüber läuft jetzt Internet-Zugriff (über Dialer1), VPN zu Standort 1 (über Dialer) und VPN zu Standort 2 (über VLAN-IF 109). NAT funktioniert nach wie vor noch mit route-map und "match ip <ACL>", über ein "match interface XY" würde wie erwähnt der Tunnelaufbau nicht zustande kommen. Im großen und ganzen habe ich mich an die Anleitung NIL - Small Site Multi-Homing gehalten, und habe dann den Traffic über statische Routen gesteuert - hier müssen auch Routings für die internen Netze auf das jeweilige WAN-Interface gesetzt werden, sonst wechselt er lustig zwischen beiden Default-Gateways. Es gibt zwei verschiedene Crypto-Maps, eine ist an den Dialer gebunden, die andere an das VLAN-Interface. Sicherlich nichts für große Umgebungen, aber für Standorte mit 3-5 VPNs sicher eine interessante Lösung, wenn man für zwei ISP nur einen Router einsetzen will. UPDATE Beim weiteren Test bin ich nun doch noch auf eine Einschränkung gestoßen - NAT funktioniert nur für das erste Interface (in meinem Fall für den Dialer). Somit scheidet die Lösung für echten Dual-ISP Betrieb mit Internetzugriff über beide Provider aus. Zur Nutzung von zwei ISPs für VPNs und einem Def.-GW für Internetzugang ist die Lösung aber durchaus geeignet, solange nicht (z.B. per http) auf die publicIP(s) zugegriffen werden muss, die über den zweiten ISP angebunden sind...
  8. So, ein Problem sehe ich gerade hinsichtlich NAT: Dual-ISP unterstützt nur route-maps mit "match interface" - hier habe ich bisher "match ip" mit einer Access-List genutzt -> enthielt dann auch die lokalen Netze für die Tunnel. Da müsste ich erstmal erstmal eine andere Lösung dann für suchen...
  9. Statische Routen wären gar nicht mal das Problem dabei - feste IPs wären an allen Stellen vorhanden... Testaufbau steht auch noch nicht...
  10. Ich werd auf jeden Fall mal berichten - muss mir momentan erstmal eine Testumgebung dafür schaffen, wird wohl auf 1x DSL (mit fester IP) und 1x ISDN Dialer hinauslaufen
  11. Noch eine Frage dazu: Vorausgesetzt, zwei ISPs sind angebunden, Routing und NAT ist alles soweit korrekt eingerichtet - ist es möglich VPNs dann auch noch unterschiedlich zu terminieren? Also zwei Crypto-Maps einrichten, eine auf das eine ISP-IF, eine auf das zweite ISP-IF? Wäre super, dann könnte ich sukzessive VPNs umziehen... :)
  12. Ne, da besteht auch kein Zusammenhang - DATEV an sich ist der Grund, weswegen der Kunde von DATEV weg will - muss evtl. nur noch eine Zeitlang am Leben gehalten werden... Ich werde mal einen Versuch mit VMPlayer wagen - wenn Virtualisierung vom SBS nicht funktioniert, muss ich halt direkt den Datenbestand migrieren...
  13. Das sieht interessant aus, werde ich mir mal ansehen!
×
×
  • Create New...