Jump to content

danieldd

Members
  • Gesamte Inhalte

    18
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von danieldd

Contributor

Contributor (5/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

12

Reputation in der Community

  1. Hi zusammen, gibt es eine Möglichkeit im Active Directory (unter Windows 2008 R2) in den Computer Object Eigenschaften die GUID bzw. Eindeutige Computer-ID des Clients automatisiert zu löschen? Die GUID wird bei der Installation mittels WDS automatisch abgelegt, ich möchte diese nach der Installation aber gerne per Tool löschen lassen. Bei DSMOD oder ADMOD bzw. ADModify bin ich hierzu bisher nicht fündig geworden. Kenn einer von euch eine Lösung hierzu? Danke für jeden Hinweis. grüsse daniel
  2. Hallo zusammen, hab auf einem Windows 2003 R2 x64 einen WDS installiert und vollständig eingerichtet. Clients tauchen auch bei "Pending Devices" auf und der Client wartet korrekt mit "Contacting Server". Wird versuch, das Pending Device zu benennen und frei zugeben, so erscheint folgende Meldung: "No mapping between account names and security IDs was done." Im AD hat sowohl der WDSServer als auch der User Account der ggf. benötigt wird, Vollzugriff auf die OU, wo das Konto erstellt werden sollte. Auch das RemoteIntall Verzeichnis wurde beim Einrichten des WDS vom System erstellt und die ACL entsprechend gefüllt. Auch hier hat der WDSServer und auch der Admin Account Vollzugriff. Wird das Computerkonto bereits vor dem PXE Boot des Clients im AD erstellt und die GUID des zu installierenden Clients hinterlegt, so findet der Client das vordefinierte Computer Objekt nicht und der PXE Boot wird abgebrochen. Mit einem WDS auf einem Win 2k8 R2 mit identischer Konfiguration funktioniert das Setup problemlos, nur unter Win 2k3 taucht oben stehender Fehler auf. Was läuft am WDS unter 2003 x64 anders al bei 2008 R2? Hatte dieses Problem schon mal wer? Danke im Voraus grüsse daniel
  3. Hallo zusammen, habe aktuell Probleme mit dem Domain Join einer Unattend Installation von Windows 7 Enterprise unter Windows 2008. Das Setup läuft bereits von einem anderen Server (Windows 2008 R2) problemlos und der Client hängt nach der Installation sofort korrekt in der Windows Domäne mit allen Gerätetreibern. Nur aus bisher unbekanntem Grund funktioniert der automatische Domain Join vom 2008er WDS mit dem identischen Boot- und Install-Image nicht. Die WDS sind grundsätzlich (soweit möglich) identisch konfiguriert. Es scheint als gäbe es hier einen Unterschied zwischen 2008 und 2008R2. Die erforderlichen Zugriffsrechte in der Domäne sind gesetzt: "Validated write to DNS host name" "Validated write to service principal name" Auffällig ist, dass laut DSACLS die ACEs auf diesen beiden Servern unterschiedlich angezeigt werden: 2008 R2: Beschr„nkter Zugriff für Validated write to DNS host name Selbst schreiben 2008: Beschr„nkter Zugriff für DNS Host Name Attributes Selbst schreiben Als Domänencontroller wurden bereits auch unterschiedliche DCs statisch im WDS hinterlegt, was aber ebenfalls zu keiner Änderung führt. Irgendwer Tipps, wodurch das Problem verursacht werden kann? Gibt es Unterschiede zwischen 2008 und 2008 R2? z. B. im DNS? Danke grüsse daniel
  4. Hi olc, ich hab die Replikation mittlerweile im LAN getestet, um das WAN als Verursacher ausschließen zu können. Ergebnis: Im LAN läuft die Replikation und alle Verbindungsabbrüche sind weg, alle Files werden korrekt repliziert. Grund für die Probleme sind also scheinbar doch die langsamen WAN Verbindungen (aktuell zwischen 3 und 10 MBit/s). Der nächste Schritt wäre also irgendwie in Richtung WAN Optimierung zu gehen. Gibt es irgendwo in DFS eine Einstellung zur Erhöhung von Timeouts oder sonstiges bei langsamen Verbindungen? Hat jemand hilfreiche Tipps bzgl. WAN Optimierung? Danke im Voraus grüsse daniel
  5. Hi, kurzes Update zu den in der Zwischenzeit vorgenommenen Änderungen. Der TCP Chimney-Abladestatus wurde auf allen Replikationspartner deaktiviert "Large Send Offload" in der NIC Konfiguration ebenfalls deaktiviert Änderungen in der Registry vorgenommen: DFSR RPC replication errors 5014 1726 with large files over VPN Die Eventlogs 5014 tauchen aber weiterhin auf: Protokollname: DFS Replication Quelle: DFSR Datum: 01.10.2012 09:31:24 Ereignis-ID: 5014 Aufgabenkategorie:Keine Ebene: Warnung Schlüsselwörter:Klassisch Benutzer: Nicht zutreffend Computer: gerätename.domänenname.local Beschreibung: Der DFS-Replikationsdienst beendet die Kommunikation mit Partner CONUS01 für Replikationsgruppe WDS_Name_allSites aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen. Weitere Informationen: Fehler: 1726 (The remote procedure call failed.) Verbindungs-ID: EE7BEFE0-4C39-4F7B-8778-C3D008EDAE36 Replikationsgruppen-ID: 8F1BFD12-DA84-4225-A7DB-679A2D652812 Auch die Timeouts im DFS Log: 20121001 09:36:40.674 1984 TASK 756 Task::Schedule task:000000000BE1A640 oldState:RUNNING newState:RUNSLEEP timeout:20000 NEW_SESSION Die Replikationsgruppe wurde komplett neu erstellt mit 25GB Staging Quota und ausreichend Zeitverzögerung, damit sich die Änderungen automatisch in der Domäne abgleichen können. Wodurch könnten die permanenten Timeouts und Verbindungsabbrüche noch verursacht werden? Welche Änderungen könnte man noch vornehmen? danke grüsse daniel
  6. Hi, danke für die Rückmeldung a) RDC ist im Normalfall aktiviert, nur testweise hab ich es deaktiviert -> keine Änderung b) Danke für die Info - wenn es stündlich passiert sollte es daran auch nicht liegen c) 2462352/424078 -- DFSR fails from a computer that is running Windows Server 2008 R2 to a computer that is running Windows Server 2003 R2 953325 -- A Windows Server 2003- or 2008-based computer becomes unresponsive because the paged pool memory is exhausted when an application calls the GetFileAttributesEx and MoveFileEx functions on lots of files 948496 -- Disable SNP (Scalable Networking Pack) 953325 -- A Windows Server 2003- or 2008-based computer becomes unresponsive because the paged pool memory is exhausted when an application calls the GetFileAttributesEx and MoveFileEx functions on lots of files d) SNP ist laut Registry auf dem 2003er deaktiviert - hab die Replikation aber testweise auch mit einem Win 2k8 R2 getestet, es zeigt sich aber das gleiche Verhalten e) Die Quota hab ich bereits auf 25 GB Beide Systeme ist eine physische Hardware, keine virtuelle Umgebung. Ich werde heute die Replikationsgruppe nochmal komplett löschen, alle Daten bereinigen und nächste Woche nochmal alles neu erstellen Gibt es evtl. weitere Debugging Tools oder ähnliches? Welches vielleicht weitere Meldungen ausgeben würde? Danke und ein schönes WE grüsse daniel
  7. Update: Seit dem Ändern des Loglevels sind jetzt folgende Meldungen vorhanden: + [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C A failure was reported by the remote partner] + [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C The content set is not ready] 20120920 17:18:01.706 6460 INCO 2813 InConnection::ProcessErrorStatus Restarting session on error. connId:{35DB2F3C-3EB4-4C91-B0E7-4EEBE5D90C70} csId:{50F27B17-4CA7-47EA-B0CE-A63DB9953904} state:CONNECTED Error: + [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4200 6460 C A failure was reported by the remote partner] + [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C A failure was reported by the remote partner] + [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C The content set is not ready] 20120920 17:18:01.706 6460 INCO 7487 InConnection::RestartSession Retrying establish contentset session. connId:{35DB2F3C-3EB4-4C91-B0E7-4EEBE5D90C70} csId:{50F27B17-4CA7-47EA-B0CE-A63DB9953904} csName:Boot 20120920 17:18:01.706 6460 INCO 1042 [WARN] SessionTask::Step (Ignored) Failed, should have already been processed. Error: + [Error:9027(0x2343) InConnection::EstablishSession inconnection.cpp:6172 6460 C A failure was reported by the remote partner] + [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4200 6460 C A failure was reported by the remote partner] + [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C A failure was reported by the remote partner] + [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 6460 C The content set is not ready] 20120920 17:18:01.706 6460 TASK 756 Task::Schedule task:000000000B362370 oldState:RUNNING newState:RUNSLEEP timeout:120000 NEW_SESSION Die letzte Zeile mit "oldState:RUNNING newState:RUNSLEEP timeout:120000 NEW_SESSION" hab ich zuvor nie gesehen. Habe die Replikation eines 4 GB Files auch mittlerweile in die umgekehrte Richtung dieser beiden Server getestet. Es scheint aber das gleiche Problem aufzutreten, d. h. es liegt nicht an einer bestimmten Richtung von einem Server zu dem zweiten. grüsse daniel
  8. Hi, anbei die Logfiles (nur von 5 Minuten aufgrund der Größe). Insgesamt wären ca. 10 GB zu replizieren, wobei 3 Files eine Größe von jeweils 3 GB haben. Prestaging wurde in diesem Falle nicht betrieben. Wenn ich eine Änderung in der Struktur oder oder den Replikationsgruppen vornehme, so warte ich, bis die Änderung zum Replikationspartner mittels AD / NTDS Replikation übertragen wird. Aktuell sind in der Replikationsgruppe welche die Probleme bereitet zwei Server eingebunden (in einer Multipurpose Gruppe). Die WAN Verbindungen sind relativ stabil, d. h. wir haben keinerlei Problem bei anderen Replikationen oder sonstigen Übertragungen. In der Registry wurde bisher auf keinem der beiden Server eine Änderung in den Tcpip Parametern vorgenommen. WAN Optimierer sind nicht im Einsatz. Danke für die Unterstützung. grüsse daniel Dfsr00253.txt Dfsr00253_02.txt Dfsr00253_03.txt
  9. Hi, die Staging Quotas sind ausreichend groß und werden während der Replikation auch nicht vollständig genutzt. Die Deinstallation des Virenscanners zeigte keine Änderung. Auch RDC wurde für diese Verbindung deaktiviert, aber die Meldungen (siehe oben) tauchen trotzdem auf. Auch die maximal nutzbare Bandbreite wurde bereits auf 2 MBit/s heruntergestuft, um ein Problem durch unterschiedliche WAN Anbindungen ausschließen zu können. Aktuell sollte eine Initial Replikation vom Primary Member zu einem Außenstandort stattfinden. Auch bei Verwendung eines anderen Gruppentyps (Multipurpose und Data Collection) ändert sich nicht. Gibts noch irgend welche Einstellungen, was die Verbindungsabbrüche auslösen kann? grüsse daniel
  10. Hi olc, danke für die Rückmeldung. Aktuell verwenden wir Avira Server Security 12. Wir haben mehrere Replikations-Gruppen, das Problem tritt aber nur bei einer Gruppe auf, wo größere Files (> 4 GB) übertragen werden sollten. Bei Avira online findet sich keine offizielle Freigabe für DFSR, ich habe Avira bereits diesbezüglich beim Support nachgefragt und warte aktuell auf Rückmeldung. Aber ich werde die Replikation testweise ohne AntiVir laufen lassen. Danke für den Tipp. grüsse daniel
  11. Hallo, wir verwenden DFSR für die Replikation von einzelnen Verzeichnissen zwischen mehreren Standorten weltweit. Bei einer Replication Group erscheinen im Sekundentakt auf beiden Servern (Sender und Empfänger) folgende Meldungen im DFS Log: + [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 4732 C A failure was reported by the remote partner] + [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 4732 C The content set is not ready] 20120913 09:45:25.809 4732 INCO 7487 InConnection::RestartSession Retrying establish contentset session. connId:{B6236B02-9C73-41A8-B799-37F455E58D45} csId:{46BEA95B-B66B-403C-9E8D-D78F06D02235} csName:xxx 20120913 09:45:25.809 4732 INCO 1042 [WARN] SessionTask::Step (Ignored) Failed, should have already been processed. Error: + [Error:9027(0x2343) InConnection::EstablishSession inconnection.cpp:6172 4732 C A failure was reported by the remote partner] + [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4200 4732 C A failure was reported by the remote partner] + [Error:9027(0x2343) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 4732 C A failure was reported by the remote partner] + [Error:9051(0x235b) DownstreamTransport::EstablishSession downstreamtransport.cpp:4179 4732 C The content set is not ready] Die Replikation bleibt dann hängen, d.h. es wird unendlich viel Traffic verursacht, aber die Files kommen nie am Ziel an. Sender: Win 2k3 R2 Empfänger: Win 2k8 Alle möglichen Hotfixes wurden bereits installiert. Hat hierzu jemand eine Idee wodurch oben stehende Meldungen verursacht werden können? Danke im Voraus grüsse daniel
  12. Lösung Die Berechtigung "Kennwort zurücksetzen" war der korrekte Ansatz. Jedoch mussten noch folgende zusätzliche Rechte wie folgt auf Domänen-Ebene mit Vererbung gesetzt werden: Dsacls "DC=Domäne,DC=local" /I:S /G Domäne\User:CA;"Reset Password"; Dsacls "DC=Domäne,DC=local" /I:S /G Domäne\User:WP;"Account Restrictions"; Dsacls "DC=Domäne,DC=local" /I:S /G Domäne\User:WS;"Validated write to DNS host name"; Dsacls "DC=Domäne,DC=local" /I:S /G Domäne\User:WS;"Validated write to service principal name"; Anschließend funktioniert der DomainJoin mittels WDS Installation problemlos. Danke für die Unterstützung. grüsse daniel
  13. Hallo Philipp, danke für deine Unterstützung. Ich habe die Berechtigungen "Kennwort ändern" und "Kennwort zurücksetzen" auf Domänen-Ebene im AD mittels DSACLS gesetzt. Der DomoinJoin funktioniert aber leider immer noch nicht. Habe mittlerweile zusätzlich auch die folgenden Rechte für den Account gesetzt: - "GUID hinzufügen" - "Abgelaufendes Kennwort wiederherstellen" Wird diesem Account auf Domänen-Ebene Vollzugriff gewährt, so funktioniert der Domain-Join, es wird also vermutlich an irgend einem fehlendem Extended Recht liegen. An welchen Rechten könnte es noch liegen? Gibt es von MS eine Dokumentation bzgl. erforderliche Zugriffsrechte für den DomainJoin. Danke. grüsse daniel
  14. Hallo zusammen, ich bräucht Unterstützung bzgl. automatisierter Erstellung eines AD Computer Kontos durch eine ImageUnattend.xml in Verbindung mit einem WDS Server. Domänen-Controller / WDS Server: Windows 2k8 Standard R2 Einstellungen am WDS: "Nur bekannten Client Computern antworten" ; d. h. die AD Computer Konten werden mittels GUID vor dem PXE Boot bereits im AD erstellt. Folgendes Problem / Szenario tritt auf: Wenn in der ImageUnattend.XML für den JoinDomain als Credentials der Domänen-Admin verwendet wird, wird der Client korrekt automatisiert in die Domäne aufgenommen. Wird aber hier ein anderer Domänen-User-Account verwendet, welcher die Berechtigung zum Hinzufügen von Computer Objekten hat, schlägt der Domain Join fehl, mit Meldung "Zugriff verweigert". Dem User-Account wurden die Rechte '"Computer"-Objekte erstellen' und '"Computer"-Objekte löschen' per Delegierung (testweise) auf Domänen-Ebene gewährt. Zudem ist dieser Domänen Account auch in der "Default Domain Controller Policy" bei Option "Hinzufügen von Arbeitsstationen zur Domäne" hinterlegt. Wird der Domänen Account (mit Recht zum Hinzufügen von Clients zur Domäne) verwendet, um Clients in die Domäne aufzunehmen, welche nicht mittels WDS installiert wurden, d. h. das Computerkonto wird physikalisch erst im AD während des Domain-Join erstellt, so funktioniert dies mit uneingeschränkter Anzahl problemlos. Wird das Computerkonto (mit hinterlegter GUID für RemoteInstall) manuell gelöscht, so kann mit diesem Domänen Account der Client ebenfalls korrekt in die Domäne aufgenommen werden. Dies würde bedeuten, dass die Delegierung für den User Account erfolgreich umgesetzt wurde. Es scheint, als ob Computer Objekte im AD welche mit RemoteInstall erstellt wurden, nur vom Domänen-Admin geändert bzw. überschrieben werden dürfen, aber nicht von anderen User Accounts mit ausreichend Berechtigungen durch die WDS Unattend Installation. Auch die Integration des Domänen Accounts in der Builtin Gruppe Server-Operatoren hat keine Veränderung gezeigt. In den Foren, bei Microsoft oder allgemein bei Google bin hierzu leider bisher nicht fündig geworden. Gibts es irgendwo spezielle Rechte für WDS zur Verwaltung der Domänen Konten mit GUID? Oder wodurch könnte das Problem sonst verursacht werden? Danke für jeden Hinweis :)
  15. Hallo olc, zur Info...die Lösung des Problems: Die Staging Verzeichnisse mussten nicht neu erstellt werden. Mit Hilfe des DFSR Logs aus C:\Windows\Debug am Empfänger (der Sender loggte hierzu leider nichts hilfreiches) konnte herausgefunden werden, dass vier Dateien (aus bisher unbekanntem Grund) nicht abgeglichen werden konnten. Der passende Ausschnitt eines betroffenen Files lautete dazu: 20110908 10:09:18.680 5468 INCO 6582 InConnection::LogTransferActivity Failed to receive RAWGET uid:{xxx}-vxxx gvsn:{xxx}-vxxx fileName:xxx.img connId:{xxx} csId:{xxx} stagedSize:22216704 Error: Nach manuellen Löschen dieser betroffenen Files wurden die Staging Informationen automatisch bereinigt und das Problem war behoben. Danke für deine Hilfe. grüsse daniel
×
×
  • Neu erstellen...