none
Netzlaufwerke werden nicht verbunden RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    ich habe das Problem, dass einige Netzlaufwerke über Anmeldescript nicht verbunden werden.

    Konkret betrifft das Freigaben, die ich von einem Server2003 auf Server2008 umgezogen habe. Unsere Domäne läuft noch auf einem 2003er DC.

    Hier ein Beispiel für das Anmeldescript:
    (server15 = Server2003, sv-file01 = Server2008)

    net use i: /delete
    net use o: /delete
    net use p: /delete
    net use i: \\sv-file01\install$ /persistent:yes
    rem Vorher war i: mit \\server15\edvinst$ verbunden
    net use o: \\server15\dat-edv$ /persistent:yes
    net use p: \\server15\briefkasten /persistent:yes

    Der Fehler betrifft sowohl XP als auch Windows 7 Clients. Es ist auch egal, ob ich das Script über das Benutzerprofil oder über GPO ausführen lasse.

    Wird das Script allerdings nach der Benutzeranmeldung erneut manuell ausgeführt, funktioniert das Laufwerk-Mapping nach i: einwandfrei. Dieses Problem betrifft mehrere Freigaben und ich möchte nicht noch mehr Freigaben auf den 2008er Server umziehen, bevor das Problem nicht gelöst ist.

    Hat jemand eine Lösung?

    Donnerstag, 28. April 2011 09:17
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Winfried,

    ich glaube ich habe die Ursache gefunden. Sie liegt an ganz anderer Stelle.

    Unsere Domäne enthält einen zweiten DC. Offensichtlich funktioniert die Replizierung zwischen den Domänencontrollern nicht richtig. Das NETLOGON-Verzeichnis des zweiten DC ist vollkommen veraltet. Änderungen, die ich in den Scripts auf dem ersten DC vorgenommen habe, wurden seit 14.12.2010 nicht mehr abgeglichen.

    An diesem Tag wurden unsere Server virtualisiert! Folgende Meldung ist auf beiden DCs 2x täglich zu finden:

    ID 13559 - NtFrs

    Der Dateireplikationsdienst hat ermittelt, dass ein Replikatstammpfad von "c:\windows\sysvol\domain" in "c:\windows\sysvol\domain" geändert wurde. Falls diese Änderungen absichtlich vorgenommen wurde, muss die Datei NTFRS_CMD_FILE_MOVE_ROOT im neuen Stammpfad neu erstellt werden.
    Folgendes wurde für diesen Replikatsatz ermittelt:
        "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
     
    Die Replikat-Stammpfadänderung erfolgt in zwei Schritten, die durch das Erstellen der Datei NTFRS_CMD_FILE_MOVE_ROOT ausgelöst wird.
     
     [1] Bei der ersten Abfrage, die in 60 Minuten durchgeführt wird, wird dieser Computer vom Replikatsatz entfernt.
     [2] Bei der darauf folgenden Abfrage wird der Computer dem Replikatsatz erneut hinzugefügt. Durch das Hinzufügen wird eine vollständige Struktursynchronisierung ausgelöst. Nach der Synchronisierung befinden sich alle erforderlichen Dateien am neuen Ort.

    Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.


    Hab mal auf http://www.eventid.net/display.asp?eventid=13559&eventno=657&source=NtFrs&phase=1 nachgeschaut.

    Jetzt hab ich die Datei NTFRS_CMD_FILE_MOVE_ROOT wie beschrieben angelegt und den ntfrs-Dienst neu gestartet. Es wurde nun automatisch der Ordner NtFrs_PreExisting___See_EventLog erstellt und dort eine Sicherungskopie der vorhandenen Dateien angelegt. Dann sollte die Replizierung durchgeführt werden - aber nix wars! Der Ordner SYSVOL bleibt leer und die Freigabe SYSVOL existiert nicht mehr. In der Ereignisanzeige hab ich nun die Meldung 13508.

    Da auf dem ersten DC ebenfalls das Ereignis 13559 auftritt möchte ich hier nicht die gleiche Prozedur durchführen. Sonst hab ich gar kein SYSVOL mehr!!

    Wie soll ich nun am Besten vorgehen?

    Gruß
    Wolfgang

     

     

     

     

     


    Montag, 2. Mai 2011 13:45
    |
  • Question
    Anmelden
    0
    Anmelden

    So, Problem erkannt, Gefahr gebannt.

    Ein Mitarbeiter, unserer externen EDV-Systembetreuung hat das Problem in der Vergangenheit schon zweimal gehabt. Er hat SYSVOL komplett neu aufgebaut. Jetzt funzt wieder alles.

    Für alle die ähnliche Probleme haben:

    Siehe AD-Betriebshandbuch
    http://www.microsoft.com/germany/technet/prodtechnol/windowsserver/technologies/featured/ad/active-directory-betriebshandbuch-03.mspx#EOB

    Bereich "Wiederherstellen und Wiederaufbauen von SYSVOL"

    Gruß
    Wolfgang

    Dienstag, 3. Mai 2011 08:46
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Am 28.04.2011 schrieb Wolfgang Geiger:

    Wird das Script allerdings nach der Benutzeranmeldung erneut manuell ausgeführt, funktioniert das Laufwerk-Mapping nach i: einwandfrei. Dieses Problem betrifft mehrere Freigaben und ich möchte nicht noch mehr Freigaben auf den 2008er Server umziehen, bevor das Problem nicht gelöst ist.

    Beide Einstellungen der GPO-FAQ No. 36 setzen, die Clients zweimal neu starten lassen. http://www.gruppenrichtlinien.de/Grundlagen/faq.htm

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Donnerstag, 28. April 2011 09:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Servus Winfried,

    die Richtlinie "Bei Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" war bereits aktiviert. Das zweite Richtlinie "Anmeldescripts gleichzeitig ausführen" habe ich nun ebenfalls aktiviert und getestet. Ich habe auch mal mit wait.exe eine 20-sekündige Pause nach den /delete-Befehlen getestet. Leider alles ohne Erfolg.

    Das Problem besteht weiterhin.

    Gruß
    Wolfgang

    Freitag, 29. April 2011 06:48
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 29.04.2011 schrieb Wolfgang Geiger:

    die Richtlinie "Bei Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" war bereits aktiviert. Das zweite Richtlinie "Anmeldescripts gleichzeitig ausführen" habe ich nun ebenfalls aktiviert und getestet.

    Kommen die beiden Einstellungen auch am Client an?

    Ich habe auch mal mit wait.exe eine 20-sekündige Pause nach den /delete-Befehlen getestet. Leider alles ohne Erfolg.

    Dann muß es aber ordentliche Fehlermeldungen im Eventlog auf den
    Clients geben.

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Freitag, 29. April 2011 06:53
    |
  • Question
    Anmelden
    0
    Anmelden

    Die Gruppenrichtlinien kommen vollständig am Client an.

     

    Im Eventlog werden fast täglich folgende Ereignisse gemeldet:

    ID 5719
    Der Computer konnte eine sichere Sitzung mit einem Domänencontroller in der Domäne LRA-ND-SOB aufgrund der folgenden Ursache nicht einrichten:
    Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar.
    Dies kann zu Authentifizierungsproblemen führen. Stellen Sie sicher, dass der Computer mit dem Netzwerk verbunden ist. Wenden Sie sich an den Domänenadministrator, wenn das Problem weiterhin besteht. 

    ID 1129
    Bei der Verarbeitung der Gruppenrichtlinie ist aufgrund fehlender Netzwerkkonnektivität mit einem Domänencontroller ein Fehler aufgetreten. Dies kann eine vorübergehende Bedingung sein. Es wird eine Erfolgsmeldung generiert, wenn die Verbindung des Computers mit dem Domänencontroller wiederhergestellt wurde und wenn die Gruppenrichtlinie erfolgreich verarbeitet wurde. Falls für mehrere Stunden keine Erfolgsmeldung angezeigt wird, wenden Sie sich an den Administrator.

    und immer ca. 1 Min 30 Sek. Minuten später:

    ID 1502
    Die Gruppenrichtlinieneinstellungen für den Computer wurden erfolgreich verarbeitet. Es wurden neue 4-Gruppenrichtlinienobjekte erkannt und angewendet.
    oder
    ID 1500
    Die Gruppenrichtlinieneinstellungen für den Computer wurden erfolgreich verarbeitet. Es wurden keine Änderungen seit der letzten erfolgreichen Gruppenrichtlinienverarbeitung erkannt.

     

    Gruß Wolfgang


    Freitag, 29. April 2011 08:25
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 29.04.2011 schrieb Wolfgang Geiger:

    Im Eventlog werden fast täglich folgende Ereignisse gemeldet:

    ID 5719

    Ein Klassiker mit vielen Möglichkeiten:
    http://www.eventid.net/display.asp?eventid=5719&eventno=104&source=NETLOGON&phase=1

    Du kannst eine andere NIC probieren, evtl. reicht das schon.

    und immer ca. 1 Min 30 Sek. Minuten später:

    Und wenn Du vor dem Login 2 Minuten wartest, funktioniert alles?

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Freitag, 29. April 2011 08:30
    |
  • Question
    Anmelden
    0
    Anmelden

    NIC hab ich getauscht -> keine Veränderung.
    2 Minuten warten -> keine Veränderung.

    Dann hab ich den Laufwerksbuchstaben i: im Script durch j: ersetzt -> funzt.
    Dann wieder i: reingeschrieben -> funzt immer noch.

    Ich verstehs nicht...

    Das ganze hab ich auf Win7 getestet. Die anderen betroffenen Clients sind WinXP und woanders bei uns im Haus. Die teste ich am Montag.

    Gruß
    Wolfgang

    Freitag, 29. April 2011 10:34
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 29.04.2011 schrieb Wolfgang Geiger:

    NIC hab ich getauscht -> keine Veränderung.
    2 Minuten warten -> keine Veränderung.

    Bist Du die anderen Vorschläge auch durchgegangen?

    Dann hab ich den Laufwerksbuchstaben i: im Script durch j: ersetzt -> funzt.
    Dann wieder i: reingeschrieben -> funzt immer noch.

    Ich würde auch das net use i: /delete zu Beginn weg lassen, dafür das
    persistent:yes durch ein persistent:no ersetzen.

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Freitag, 29. April 2011 11:04
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Winfried,

    ich glaube ich habe die Ursache gefunden. Sie liegt an ganz anderer Stelle.

    Unsere Domäne enthält einen zweiten DC. Offensichtlich funktioniert die Replizierung zwischen den Domänencontrollern nicht richtig. Das NETLOGON-Verzeichnis des zweiten DC ist vollkommen veraltet. Änderungen, die ich in den Scripts auf dem ersten DC vorgenommen habe, wurden seit 14.12.2010 nicht mehr abgeglichen.

    An diesem Tag wurden unsere Server virtualisiert! Folgende Meldung ist auf beiden DCs 2x täglich zu finden:

    ID 13559 - NtFrs

    Der Dateireplikationsdienst hat ermittelt, dass ein Replikatstammpfad von "c:\windows\sysvol\domain" in "c:\windows\sysvol\domain" geändert wurde. Falls diese Änderungen absichtlich vorgenommen wurde, muss die Datei NTFRS_CMD_FILE_MOVE_ROOT im neuen Stammpfad neu erstellt werden.
    Folgendes wurde für diesen Replikatsatz ermittelt:
        "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
     
    Die Replikat-Stammpfadänderung erfolgt in zwei Schritten, die durch das Erstellen der Datei NTFRS_CMD_FILE_MOVE_ROOT ausgelöst wird.
     
     [1] Bei der ersten Abfrage, die in 60 Minuten durchgeführt wird, wird dieser Computer vom Replikatsatz entfernt.
     [2] Bei der darauf folgenden Abfrage wird der Computer dem Replikatsatz erneut hinzugefügt. Durch das Hinzufügen wird eine vollständige Struktursynchronisierung ausgelöst. Nach der Synchronisierung befinden sich alle erforderlichen Dateien am neuen Ort.

    Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.


    Hab mal auf http://www.eventid.net/display.asp?eventid=13559&eventno=657&source=NtFrs&phase=1 nachgeschaut.

    Jetzt hab ich die Datei NTFRS_CMD_FILE_MOVE_ROOT wie beschrieben angelegt und den ntfrs-Dienst neu gestartet. Es wurde nun automatisch der Ordner NtFrs_PreExisting___See_EventLog erstellt und dort eine Sicherungskopie der vorhandenen Dateien angelegt. Dann sollte die Replizierung durchgeführt werden - aber nix wars! Der Ordner SYSVOL bleibt leer und die Freigabe SYSVOL existiert nicht mehr. In der Ereignisanzeige hab ich nun die Meldung 13508.

    Da auf dem ersten DC ebenfalls das Ereignis 13559 auftritt möchte ich hier nicht die gleiche Prozedur durchführen. Sonst hab ich gar kein SYSVOL mehr!!

    Wie soll ich nun am Besten vorgehen?

    Gruß
    Wolfgang

     

     

     

     

     


    Montag, 2. Mai 2011 13:45
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 02.05.2011 schrieb Wolfgang Geiger:

    ich glaube ich habe die Ursache gefunden. Sie liegt an ganz anderer Stelle.

    Unsere Domäne enthält einen zweiten DC.

    Im OP hat sich das aber anders gelesen:
    | Unsere Domäne läuft noch auf einem 2003er DC.

    Offensichtlich funktioniert die Replizierung zwischen den Domänencontrollern nicht richtig. Das NETLOGON-Verzeichnis des zweiten DC ist vollkommen veraltet. Änderungen, die ich in den Scripts auf dem ersten DC vorgenommen habe, wurden seit 14.12.2010 nicht mehr abgeglichen.

    Oje, da gehören jemandem aber sauber die Ohren langgezogen. So lange
    nicht das Eventlog kontrollieren. Welche Dienste laufen zusätzlich auf
    dem zweiten DC? Ist Datum und Uhrzeit auf beiden DCs gleich?

    Jetzt hab ich die Datei NTFRS_CMD_FILE_MOVE_ROOT wie beschrieben angelegt und den ntfrs-Dienst neu gestartet. Es wurde nun automatisch der Ordner*NtFrs_PreExisting___See_EventLog* erstellt und dort eine Sicherungskopie der vorhandenen Dateien angelegt. Dann sollte die Replizierung durchgeführt werden - aber nix wars! Der Ordner SYSVOL bleibt leer und die Freigabe SYSVOL existiert nicht mehr. In der Ereignisanzeige hab ich nun die Meldung *13508*.

    Bist Du diese Vorschläge schon durchgegangen?

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Montag, 2. Mai 2011 17:20
    |
  • Question
    Anmelden
    0
    Anmelden

    So, Problem erkannt, Gefahr gebannt.

    Ein Mitarbeiter, unserer externen EDV-Systembetreuung hat das Problem in der Vergangenheit schon zweimal gehabt. Er hat SYSVOL komplett neu aufgebaut. Jetzt funzt wieder alles.

    Für alle die ähnliche Probleme haben:

    Siehe AD-Betriebshandbuch
    http://www.microsoft.com/germany/technet/prodtechnol/windowsserver/technologies/featured/ad/active-directory-betriebshandbuch-03.mspx#EOB

    Bereich "Wiederherstellen und Wiederaufbauen von SYSVOL"

    Gruß
    Wolfgang

    Dienstag, 3. Mai 2011 08:46
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 03.05.2011 schrieb Wolfgang Geiger:

    So, Problem erkannt, Gefahr gebannt.

    Ein Mitarbeiter, unserer externen EDV-Systembetreuung hat das Problem in der Vergangenheit schon zweimal gehabt. Er hat SYSVOL komplett neu aufgebaut. Jetzt funzt wieder alles.

    Freut mich für Dich und Danke für die Rückmeldung. ;)

    BTW: Wessen Ohren sind denn jetzt etwas länger als vorher? :)

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Dienstag, 3. Mai 2011 08:55
    |