locked
Extrem langsame Anmeldung falls Domänenrechner in fremdem Netzwerk RRS feed

  • Allgemeine Diskussion

  • Hallo,

     

    wir haben hier folgendes Problem.

    In einer SBS2003  Domäne mit servergespeicherten Profilen befinden sich auch mehrere Laptops, die natürlich auch mal außer Haus gehen. Solange sie dort nicht an ein anderes Netzwerk angeschlossen sind, gibts kein Problem. Es wird eine Fehlermeldung ausgegeben das der Server nicht erreichbar ist und dann das lokale gespeicherte Profil geladen. Soweit so gut. Das Problem fängt an sobald ein Benutzer bereits bei der Anmeldung mit einem fremden Netzwerk verbunden ist, z.B. durch ein WLAN das er vorher schon mal konfiguriert hatte. In diesem Fall dauert es extrem lange bis die Fehlermeldung erscheint und das lokale Profil geladen wird.

    Kann man dieses Verhalten irgendwie ändern? So das z.B. abhängig vom Netzwerk (bei WLAN, nach IP-Adresse, ping zum Server, etc.) erst gar nicht versucht wird den Server zu kontaktieren sondern gleich das lokale Profil geladen wird? Und kann man diese Einstellung am besten per GPO verteilen?

    Vielen Dank

    Gruß

    Mittwoch, 1. September 2010 10:33

Alle Antworten

  • Hi MaFrei,

    vielleicht hilft dir der Link weiter, um dem Problem auf die Schliche zu
    kommen:
    http://blogs.technet.com/b/deds/archive/2010/07/01/verzoegerung-beim-laden-des-gecachten-roaming-user-profiles-wenn-man-zum-internet-provider-verbunden-ist.aspx

    Werden normalerweise Userverzeichnisse umgelenkt?

    Viele Grüße
    Christian

    Freitag, 3. September 2010 05:09
  • Nein, umgelenkte Userverzeichnisse werden nicht verwendet. Nur servergespeicherte Profile und ein Server-Stammverzeichniss.

     

    Und vielen Dank für deinen Link, bin noch am durchlesen aber die Fehlerbeschreibung passt ja schon mal. Melde mich zurück sobald ich mehr weiß.

    Montag, 6. September 2010 15:04
  • Hallo,

    ist das Problem noch aktuell? konnten dir die im Link enthaltenen Infos weiterhelfen?

    Gruß,
    Andrei

    Donnerstag, 9. September 2010 07:40
  • Hallo,

     

    ja, das Problem ist weiterhin vorhanden. Der verlinkte Artikel hat mir nu zwar erklärt wie das Problem entsteht, aber ich habe weiterhin keine Ahnung wie ich das vermeiden kann.

    Workaround wäre das der User konsequent vermeidet beim Anmelden am Laptop in einem Netz zu sein. Bei einem Ethernet ist das ja noch einfach zu befolgen (Stecker raus), bei einem WLAN weniger da er dann jedes mal bevor er den Rechner ausschaltet, die WLAN Konfiguration löschen müsste und das ist für Ihn indiskutabel.

    Donnerstag, 9. September 2010 12:14
  • Hi <realname please>,
     
    > ja, das Problem ist weiterhin vorhanden. Der verlinkte Artikel hat mir nu
    > zwar erklärt
    > wie das Problem entsteht, aber ich habe weiterhin keine Ahnung wie ich das
    > vermeiden kann.
    >
    > Workaround wäre das der User konsequent vermeidet beim Anmelden am Laptop
    > in einem
    > Netz zu sein. Bei einem Ethernet ist das ja noch einfach zu befolgen
    > (Stecker raus), bei einem
    > WLAN weniger da er dann jedes mal bevor er den Rechner ausschaltet, die
    > WLAN
    > Konfiguration löschen müsste und das ist für Ihn indiskutabel.
     
    sollte es sich um das geschilderte Problem aus dem Artikel, hier:
     
    http://blogs.technet.com/b/deds/archive/2010/07/01/verzoegerung-beim-laden-des-gecachten-roaming-user-profiles-wenn-man-zum-internet-provider-verbunden-ist.aspx
     
    handeln, wäre auf dem SBS (der vermutlich eher selten eine interne
    IP-Adress-Änderung unterworfen ist) eine Umstellung des Pfades der
    betroffenen Benutzern für deren servergespeicherten Profile auf die IP-
    anstatt des FQDN-Adresse ein möglicher Workaround.
     
    Nicht schön, aber würde evtl. das (benutzer-freundliche, jedoch
    admin-feindliche) Verhalten der DNS-Provider umgehen.
     
    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net
     
     
     
    Sonntag, 12. September 2010 15:17