7
AD Anmeldung via VPN dauert lange
Hi,
für ich nenne es mal Remote-Standorte (in unserem Fall Entwickler die von zuhause aus in einer VM arbeiten) sollen sich die User via VPN mit unserem Netzwerk verbinden und über einen AD Account an der Domäne (Server 2012 R2) anmelden. In der VM läuft Windows 8.1. Microsoft hat ja sinnvollerweise die Netzwerkanmeldung vor der Anmeldung eingebaut, sodass dies problemlos möglich ist. Ich habe also die VPN-Verbindung eingerichtet und die VM in unsere Domäne aufgenommen.
Auf dem Anmeldebildschirm klicke ich auf der Seite mit den Benutzeraccounts links unten auf "Netzwerkanmeldung", gebe meinen Benutzername (Anmeldename@Domäne.de) und Kennwort ein. Anschließend meldet mich Windows am VPN und danach automatisch an meinem AD Account an der VM an. Das Problem ist, dass die Anmeldung recht lange dauert, manchmal sogar extrem lange.
Ich habe mal 3 Neustarts gemacht und mittels Stoppuhr gemessen, wie lange die Anmeldung dauert:
1. Messung: Nach 3 Sekunden erscheint der Willkommens-Bildschirm, nach 40 Sekunden der Desktop.
2. Messung: Nach 3 Sekunden erscheint der Willkommens-Bildschirm, nach 3 Minuten der Desktop.
3. Messung: Nach 3 Sekunden erscheint der Willkommens-Bildschirm, nach 37 Sekunden der Desktop.
40 Sekunden finde ich für die Anmeldung schon recht lange, zumal er diese wie gesagt bei "Willkommen" verbringt. Aber 3 Minuten ist ein Bereich der eindeutig viel zu lange ist.
Das Problem tritt auch nur im VPN auf. Der Host ist virtualisiert, wenn ich ohne VPN per RDP auf den Host verbinde dauert die gesamte Anmeldung maximal 5 Sekunden, d.H. ich gebe meine Anmeldedaten ein und nach 5 Sekunden bin ich auf dem Desktop.
EDIT zu Anbindung und Ressourcen:
Die VM ist über DSL 50.000 (Kabelanbieter) angebunden, ein Speedtest bescheinigt 53MB/s Download und 2,2MB/s Upload, die quasi keine Last hat. Der Server ist mit 100MB/s angebunden, sowohl Leitung als auch generelle Systemressourcen (CPU/RAM/HDD) sind ausreichend dimensioniert und keinesfalls überladen. Das Active Directory wird momentan nur von mir und einer weiteren Person genutzt, allerdings bislang nur als zentrale Authentifizierung für verschiedene Interne Systeme (Wiki etc), ich bin also der Einzige wo das zur Anmeldung per VPN nutzt und auch nutzen kann.
Aus dem Grund hatte ich das nicht extra erwähnt da es auf jeden Fall nicht an der Anbindung oder den Ressourcen liegen kann, sorry mein Fehler.
für ich nenne es mal Remote-Standorte (in unserem Fall Entwickler die von zuhause aus in einer VM arbeiten) sollen sich die User via VPN mit unserem Netzwerk verbinden und über einen AD Account an der Domäne (Server 2012 R2) anmelden. In der VM läuft Windows 8.1. Microsoft hat ja sinnvollerweise die Netzwerkanmeldung vor der Anmeldung eingebaut, sodass dies problemlos möglich ist. Ich habe also die VPN-Verbindung eingerichtet und die VM in unsere Domäne aufgenommen.
Auf dem Anmeldebildschirm klicke ich auf der Seite mit den Benutzeraccounts links unten auf "Netzwerkanmeldung", gebe meinen Benutzername (Anmeldename@Domäne.de) und Kennwort ein. Anschließend meldet mich Windows am VPN und danach automatisch an meinem AD Account an der VM an. Das Problem ist, dass die Anmeldung recht lange dauert, manchmal sogar extrem lange.
Ich habe mal 3 Neustarts gemacht und mittels Stoppuhr gemessen, wie lange die Anmeldung dauert:
1. Messung: Nach 3 Sekunden erscheint der Willkommens-Bildschirm, nach 40 Sekunden der Desktop.
2. Messung: Nach 3 Sekunden erscheint der Willkommens-Bildschirm, nach 3 Minuten der Desktop.
3. Messung: Nach 3 Sekunden erscheint der Willkommens-Bildschirm, nach 37 Sekunden der Desktop.
40 Sekunden finde ich für die Anmeldung schon recht lange, zumal er diese wie gesagt bei "Willkommen" verbringt. Aber 3 Minuten ist ein Bereich der eindeutig viel zu lange ist.
Das Problem tritt auch nur im VPN auf. Der Host ist virtualisiert, wenn ich ohne VPN per RDP auf den Host verbinde dauert die gesamte Anmeldung maximal 5 Sekunden, d.H. ich gebe meine Anmeldedaten ein und nach 5 Sekunden bin ich auf dem Desktop.
EDIT zu Anbindung und Ressourcen:
Die VM ist über DSL 50.000 (Kabelanbieter) angebunden, ein Speedtest bescheinigt 53MB/s Download und 2,2MB/s Upload, die quasi keine Last hat. Der Server ist mit 100MB/s angebunden, sowohl Leitung als auch generelle Systemressourcen (CPU/RAM/HDD) sind ausreichend dimensioniert und keinesfalls überladen. Das Active Directory wird momentan nur von mir und einer weiteren Person genutzt, allerdings bislang nur als zentrale Authentifizierung für verschiedene Interne Systeme (Wiki etc), ich bin also der Einzige wo das zur Anmeldung per VPN nutzt und auch nutzen kann.
Aus dem Grund hatte ich das nicht extra erwähnt da es auf jeden Fall nicht an der Anbindung oder den Ressourcen liegen kann, sorry mein Fehler.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 261128
Url: https://administrator.de/forum/ad-anmeldung-via-vpn-dauert-lange-261128.html
Ausgedruckt am: 22.12.2024 um 01:12 Uhr
7 Kommentare
Neuester Kommentar
Hallo ASP,
wenn wir nun mal beim kleinen 1*1 (oder 1+1) anfangen: Wie schnell ist denn die Leitung und wie stark ist die Auslastung - außerdem, welche Technik steckt dahinter - ist die UTM/das GW zu schlecht dimensioniert?
Bei Bedarf kann ich dir anbieten das ganze Konstrukt mal direkt anzuschauen um die Probleme zu isolieren und entsprechende Lösungswege zu finden, in dem Fall bitte per PN.
Schönen Sonntag,
Christian
certified IT
wenn wir nun mal beim kleinen 1*1 (oder 1+1) anfangen: Wie schnell ist denn die Leitung und wie stark ist die Auslastung - außerdem, welche Technik steckt dahinter - ist die UTM/das GW zu schlecht dimensioniert?
Bei Bedarf kann ich dir anbieten das ganze Konstrukt mal direkt anzuschauen um die Probleme zu isolieren und entsprechende Lösungswege zu finden, in dem Fall bitte per PN.
Schönen Sonntag,
Christian
certified IT
Hallo certifiedit.net,
das habe ich völlig vergessen zu erwähnen weil diesbezügliche Probleme ausgeschlossen sind. Der Server ist für das was bisher drauf läuft überdimensioniert und kaum ausgelastet. Habe es oben ediert, sorry.
Ich möchte das Problem gerne selbst finden und lösen. Zur weiteren Diagnose habe ich VerboseStatus über eine GPO aktiviert, sodass ich ausführlichere Infos erhalte. Er steht nach wie vor um die 10 Sekunden bei "Willkommen", aber den größten Anteil der Wartezeit nimmt "Warten auf Benutzerprofildienst" ein. Seit kurzem erscheint auch eine Meldung beim abmelden, dass das Roamingprofil nicht vollständig synchronisiert wurde (wir verwenden servergespeicherte Profile).
Ein Blick in die Ereignisanzeige brachte folgende Meldung zu Tage:
"Das Roamingprofil konnte nicht vollständig aktualisiert werden. Details erhalten Sie in den vorhergehenden Ereignissen."
"Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u. U. nicht mehr ordnungsgemäß. Kein Benutzereingriff erforderlich.
DETAIL -
1 user registry handles leaked from \Registry\User\S-1-5-21-1107009087-2515811915-3103359273-1105_Classes:
Process 840 (\Device\HarddiskVolume1\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-1107009087-2515811915-3103359273-1105_CLASSES"
"Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u. U. nicht mehr ordnungsgemäß. Kein Benutzereingriff erforderlich.
DETAIL -
2 user registry handles leaked from \Registry\User\S-1-5-21-1107009087-2515811915-3103359273-1105:
Process 1296 (\Device\HarddiskVolume1\Windows\System32\spoolsv.exe) has opened key \REGISTRY\USER\S-1-5-21-1107009087-2515811915-3103359273-1105
Process 840 (\Device\HarddiskVolume1\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-1107009087-2515811915-3103359273-1105"
"CoID={2ED062F2-1B38-46D0-BA3E-F4964F86AB0A}: Der Benutzer "SYSTEM" hat eine Verbindung mit dem Namen "VPN" gewählt, die Verbindung wurde jedoch getrennt. Der bei der Trennung zurückgegebene Ursachencode lautet: 830."
Was der Druckerdienst da zu suchen hat ist mir schleierhaft. Ich habe testweise auch meine RDP-Session beendet im Verdacht, dass die da irgendwas sperrt, aber ändert sich nichts.
Verdächtig finde ich aber, dass die Verbindung laut Logs getrennt wird (unterste Meldung), und die Fehlermeldung bzgl. des Roamingprofiles erst danach erscheint, und zwar ganze 9 Sekunden später! Da stimmt doch etwas nicht?
Hab grade mal bzgl des Fehlercodes recherchiert, andere scheinen dasselbe Problem zu haben und dort wurde meine Vermutung bestätigt, dass hier zeitlich etwas nicht stimmt. Leider wurde dort über keinerlei Lösungsmöglichkeiten diskutiert, sondern lediglich die Umstellung auf Ordnerumleitungen genannt. Ist für mich keine wirkliche Alternative.
Mein Gedanke hinter den servergespeicherten Profilen ist, dass neben Windows-Einstellungen (Taskleiste, Verknüpfungen etc) vor allem sämtliche Einstellungen der verwendeten Anwendungen (z.B. Entwicklumgsumgebungen) serverseitig gespeichert und natürlich auch regelmäßig gesichert werden. Dadurch soll der Aufwand für den Fall der Fälle möglichst gering gehalten werden, wenn z.B. die VM mal zurückgesetzt werden muss oder ähnliches. Dementsprechend geht es auch nicht um übermäßig große Datenmengen. Um das zu verhindern habe ich Ordner wie Downloads auch bereits per GPO zur Synchronisation ausgeschlossen, damit die Abmeldung nicht 2h dauert wenn beispielsweise eine IDE zur Installation heruntergeladen wird und natürlich auch damit der Server nicht mit unnötigem Zeugs zugemüllt wird.
das habe ich völlig vergessen zu erwähnen weil diesbezügliche Probleme ausgeschlossen sind. Der Server ist für das was bisher drauf läuft überdimensioniert und kaum ausgelastet. Habe es oben ediert, sorry.
Ich möchte das Problem gerne selbst finden und lösen. Zur weiteren Diagnose habe ich VerboseStatus über eine GPO aktiviert, sodass ich ausführlichere Infos erhalte. Er steht nach wie vor um die 10 Sekunden bei "Willkommen", aber den größten Anteil der Wartezeit nimmt "Warten auf Benutzerprofildienst" ein. Seit kurzem erscheint auch eine Meldung beim abmelden, dass das Roamingprofil nicht vollständig synchronisiert wurde (wir verwenden servergespeicherte Profile).
Ein Blick in die Ereignisanzeige brachte folgende Meldung zu Tage:
"Das Roamingprofil konnte nicht vollständig aktualisiert werden. Details erhalten Sie in den vorhergehenden Ereignissen."
"Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u. U. nicht mehr ordnungsgemäß. Kein Benutzereingriff erforderlich.
DETAIL -
1 user registry handles leaked from \Registry\User\S-1-5-21-1107009087-2515811915-3103359273-1105_Classes:
Process 840 (\Device\HarddiskVolume1\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-1107009087-2515811915-3103359273-1105_CLASSES"
"Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u. U. nicht mehr ordnungsgemäß. Kein Benutzereingriff erforderlich.
DETAIL -
2 user registry handles leaked from \Registry\User\S-1-5-21-1107009087-2515811915-3103359273-1105:
Process 1296 (\Device\HarddiskVolume1\Windows\System32\spoolsv.exe) has opened key \REGISTRY\USER\S-1-5-21-1107009087-2515811915-3103359273-1105
Process 840 (\Device\HarddiskVolume1\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-1107009087-2515811915-3103359273-1105"
"CoID={2ED062F2-1B38-46D0-BA3E-F4964F86AB0A}: Der Benutzer "SYSTEM" hat eine Verbindung mit dem Namen "VPN" gewählt, die Verbindung wurde jedoch getrennt. Der bei der Trennung zurückgegebene Ursachencode lautet: 830."
Was der Druckerdienst da zu suchen hat ist mir schleierhaft. Ich habe testweise auch meine RDP-Session beendet im Verdacht, dass die da irgendwas sperrt, aber ändert sich nichts.
Verdächtig finde ich aber, dass die Verbindung laut Logs getrennt wird (unterste Meldung), und die Fehlermeldung bzgl. des Roamingprofiles erst danach erscheint, und zwar ganze 9 Sekunden später! Da stimmt doch etwas nicht?
Hab grade mal bzgl des Fehlercodes recherchiert, andere scheinen dasselbe Problem zu haben und dort wurde meine Vermutung bestätigt, dass hier zeitlich etwas nicht stimmt. Leider wurde dort über keinerlei Lösungsmöglichkeiten diskutiert, sondern lediglich die Umstellung auf Ordnerumleitungen genannt. Ist für mich keine wirkliche Alternative.
Mein Gedanke hinter den servergespeicherten Profilen ist, dass neben Windows-Einstellungen (Taskleiste, Verknüpfungen etc) vor allem sämtliche Einstellungen der verwendeten Anwendungen (z.B. Entwicklumgsumgebungen) serverseitig gespeichert und natürlich auch regelmäßig gesichert werden. Dadurch soll der Aufwand für den Fall der Fälle möglichst gering gehalten werden, wenn z.B. die VM mal zurückgesetzt werden muss oder ähnliches. Dementsprechend geht es auch nicht um übermäßig große Datenmengen. Um das zu verhindern habe ich Ordner wie Downloads auch bereits per GPO zur Synchronisation ausgeschlossen, damit die Abmeldung nicht 2h dauert wenn beispielsweise eine IDE zur Installation heruntergeladen wird und natürlich auch damit der Server nicht mit unnötigem Zeugs zugemüllt wird.
Hallo,
Router?
Ganz verstehe ich dein Aufbau nicht und habe das Gefühl du hast VPN und AD etwas durcheinander gebracht und leitest deine AD Daten 3 mal um sich selbst bevor du die zum Mars und zurück schickst.
Gruß,
Peter
Router?
Anschließend meldet mich Windows am VPN und danach automatisch an meinem AD Account an der VM an.
?!? VPN mit der VM innerhalb deiner Domäne und dann die Windows AD Anmeldung am Client, hier die VM mit Win 8.1?Das Problem tritt auch nur im VPN auf.
Was hat jetzt VPN hier zu tun? Mit VPN wird doch nur dein LAN zum Entwickler nach hause verlängert. Das hat doch mit der VM nichts zu tun.Der Host ist virtualisiert,
Oder meinst du den Gast? Der Host ist doch eher immer der Virtualisierer und nicht das Virtualisierte OS, oder?gesamte Anmeldung maximal 5 Sekunden, d.H. ich gebe meine Anmeldedaten ein und nach 5 Sekunden bin ich auf dem Desktop.
Sollte bei einer RDP über einen VPN Tunnel von Extern nicht länger dauern. Wie lange die Bildschirminhalte und Tastatur/Maus eingaben zum übertragen brauchen ist hier allerdings nicht mit eingerechnet. Am Virtuellen Gast OS (Hier dein Win 8.1) sollte der Vorgang immer gleich schnell ablaufen. Oder muss das Virtuelle Gast OS erst noch selbst eine VPN Verbindung irgendwohin schalten und dann darüber allen Datenverkehr leiten?quasi
Quasi?Das Active Directory wird momentan nur von mir und einer weiteren Person genutzt,
ich dachte deine Virtuellen VMs sind dort als Computer eingebunden und du nutzt das AD zum Anmelden an der Domäne?Ganz verstehe ich dein Aufbau nicht und habe das Gefühl du hast VPN und AD etwas durcheinander gebracht und leitest deine AD Daten 3 mal um sich selbst bevor du die zum Mars und zurück schickst.
Gruß,
Peter
Zitat von @Pjordorf:
Ganz verstehe ich dein Aufbau nicht und habe das Gefühl du hast VPN und AD etwas durcheinander gebracht und leitest deine AD
Daten 3 mal um sich selbst bevor du die zum Mars und zurück schickst.
Ganz verstehe ich dein Aufbau nicht und habe das Gefühl du hast VPN und AD etwas durcheinander gebracht und leitest deine AD
Daten 3 mal um sich selbst bevor du die zum Mars und zurück schickst.
Nene das kann ich mir (noch) nicht leisten ;)
Das Missverständnis kommt wohl daher, dass auf beiden Seiten virtualisiert wird und ich das zugegebenermaßen nicht immer 100% eindeutig differenziert habe: Der Windows-Server ist ein Hyper-V Host, dort laufen also Server als VMs (Der AD DC beispielsweise). Clientseitig wird ebenfalls virtualisiert, hier sollen sich die User per VPN mit ihrem AD Account über ihr serverseitiges Profil (Gründe siehe letzte Antwort von mir) anmelden können.
Mein Beispiel bezog sich darauf, dass die Anmeldung per RDP am Hyper-V Host über unsere Domäne sehr schnell geht und nur wenige Sekunden dauert. Stelle ich clientseitig in der User-VM am Anmeldebildschirm eine Verbindung mit dem VPN her, dauert es im besten Falle ca. 40 Sekunden bis zum Desktop, teilweise auch deutlich länger.
Daher auch meine anfängliche Vermutung, dass es etwas mit dem VPN zutun hat, die sich scheinbar ja immer mehr bestätigt. Wie ich eben bereits schrieb ist es seltsam, dass die VPN-Verbindung erst getrennt wird und anschließend die Synchronisierung des Profiles fehlschlägt. Meine momentane Theorie lautet daher, dass die Synchronisierung eben mangels Verbindung hinfällt. Wie erwartet werden die Bibliotheken nämlich nicht synchronisiert.
Ich verstehe nur nicht warum? Die Möglichkeit, vor der Anmeldung eine VPN-Verbindung herzustellen, scheint doch genau für solche Szenarios entworfen worden zu sein. Wenn die VPN-Verbindung dann aber gekillt wird bevor synchronisiert werden kann, schränkt das die Sinnhaftigkeit des ganzen doch deutlich ein...
Allerdings kommt mir gerade ein düsterer Verdacht bzgl GPOs, wenn sich der bestätigt werde ich zwar noch verwirrter als vorher sein aber ich probiere es mal aus, ansonsten bin ich nämlich gerade ziemlich ratlos wo das Problem liegen könnte.
Hallo,
Und da wunderst du dich das die Anmeldung über VPN lange dauert?
LG Chris
Und da wunderst du dich das die Anmeldung über VPN lange dauert?
LG Chris
Zitat von @chrisiweber:
Hallo,
> Zitat von @GNULinux:
>
> (wir verwenden servergespeicherte Profile).
>
Und da wunderst du dich das die Anmeldung über VPN lange dauert?
LG Chris
Hallo,
> Zitat von @GNULinux:
>
> (wir verwenden servergespeicherte Profile).
>
Und da wunderst du dich das die Anmeldung über VPN lange dauert?
LG Chris
Du merkst doch schon anhand der Beschreibung, dass das ziemlich gefrimelt ist
Hallo,
ich verstehe nicht richtig wieso die Anmeldung wegen einer VPN-Verbindung per se "lange dauern" sollte. Mir ist natürlich bewusst, dass die VPN-Verbindung erst aufgebaut werden muss und der Client bei der Anmeldung das Benutzerprofil synchronisiert was natürlich etwas an Zeit in Anspruch nimmt. 40 Sekunden scheinen mir aber etwas lang (ganz abgesehen von 3 Minuten), zumal das aktuelle Profil kaum Daten enthält. Der gesamte Profilordner umfasst 28MB und die Daten werden zurzeit ja überhaupt nicht verändert. Soweit ich weiß und auch erwarte wird seit XP nicht mehr der gesamte Ordner geladen sondern eben nur noch inkrementell die Dateien welche sich verändert haben, d.H. wegen den Daten sollte keine enorme Verzögerung auftreten außer logischerweise beim ersten Mal wenn diese initial geladen werden müssen.
Momentan gestaltet sich die Situation so, dass die Synchronisierung clientseitig auf der VM im VPN überhaupt nicht mehr funktioniert. Beim Starten erscheint zwar keine Fehlermeldung, aber Teständerungen in den Bibliotheken die ich per RDP am Hyper-V Host eingeloggt vorgenommen habe wurden nach Abmeldung vom Host + Neustart der Client-CM nicht übernommen. Melde ich mich von der Client-VM ab, erscheint die Fehlermeldung "Ihr Roamingprofil wurde nicht erfolgreich synchronisiert".
In der Ereignisanzeige wird weiterhin wie in diesem Beitrag AD Anmeldung via VPN dauert lange bereits genauer erläutert angezeigt, dass die VPN-Verbindung zwecks herunterfahren beendet wurde, Registry-Schlüssel noch geöffnet sind (da bin ich mir mittlerweile nicht sicher ob das wirklich was damit zutun hat) und ein paar Sekunden später eben die Fehlermeldung, dass mein Roamingprofil nicht vollständig aktualisiert werden konnte und man in den vorherigen Ereignissen Details findet (das sind die geposteten).
Das kuriose an der Sache ist, dass es anfangs ja funktioniert hat. Ich habe servergespeicherte Profile eingerichtet, das funktionierte, auch auf der Client-VM via VPN. Dann wollte ich einzelne Bibliotheks-Ordner von den servergespeicherten Profilen ausschließen (Downloads z.B.) damit keine unnötigen Daten synchronisiert werden. Dafür habe ich mich in GPOs eingearbeitet und dies via GPO versucht einzurichten. Seit dem tritt dieser Fehler bzgl. der Synchronisation auf. Die GPO habe ich deaktiviert, testweise sogar alle (auch die Standardmäßig vorhandenen) aber es tritt nach wie vor auf.
Ich bin mittlerweile ratlos und werde es mal mit einem neu erstellten Account versuchen, vielleicht ist durch die Änderungen dort etwas durcheinander gekommen.
AD wurde bisher noch nicht für diesen Zweck eingesetzt, diese Anforderung hat sich aus verschiedenen Gründen ergeben. Unter anderem weil Entwicklersysteme in der Regel "vermurkst" sind wodurch es zu speziellen Fehlern und Problemen kommt die anschließend nur schwer nachvollziehbar sind und desweiteren für externe Entwickler natürlich auch eine gewisse Trennung zwischen Privat und Entwicklung bestehen soll.
Für Alternativen bin ich natürlich gerne offen, mir scheint es allerdings nur 3 zu geben:
Ordnerumleitungen
Erfüllt die Anforderungen nicht vollständig da neben Windows-Einstellungen eben auch jene von Programmen auf dem Server gespeichert werden sollen. Ich habe auch bedenken ob das nicht zumindest Performanceprobleme verursachen kann (von weitreichenderen ganz zu schweigen) wenn Ordner wie AppData auf den Server ausgelagert werden.
Terminalserver
Ist aus Performance-Gründen ebenfalls keine Alternative, da mehrere User mit Entwicklungsumgebungen wie etwa Visual Studio arbeiten, was natürlich entsprechend Ressourcen zieht. Außerdem werden wir voraussichtlich auch User mit schwächerer Internetleitung haben. Da dauert die Synchronisierung des Profiles natürlich etwas länger, aber dafür kann danach auf jeden Fall mit vernünftiger Geschwindigkeit gearbeitet werden da alles lokal kopiert wurde.
DirectAccess
Scheint mir grundsätzlich von der Funktion her als Alternative in Frage zu kommen, ist allerdings so momentan nicht nutzbar da hierfür clientseitig Ultimate oder Enterprise-Lizenzen benötigt werden und momentan Windows 8.1 Pro vorhanden ist. Würde ich daher gerne als letzte Möglichkeit in Betracht ziehen.
ich verstehe nicht richtig wieso die Anmeldung wegen einer VPN-Verbindung per se "lange dauern" sollte. Mir ist natürlich bewusst, dass die VPN-Verbindung erst aufgebaut werden muss und der Client bei der Anmeldung das Benutzerprofil synchronisiert was natürlich etwas an Zeit in Anspruch nimmt. 40 Sekunden scheinen mir aber etwas lang (ganz abgesehen von 3 Minuten), zumal das aktuelle Profil kaum Daten enthält. Der gesamte Profilordner umfasst 28MB und die Daten werden zurzeit ja überhaupt nicht verändert. Soweit ich weiß und auch erwarte wird seit XP nicht mehr der gesamte Ordner geladen sondern eben nur noch inkrementell die Dateien welche sich verändert haben, d.H. wegen den Daten sollte keine enorme Verzögerung auftreten außer logischerweise beim ersten Mal wenn diese initial geladen werden müssen.
Momentan gestaltet sich die Situation so, dass die Synchronisierung clientseitig auf der VM im VPN überhaupt nicht mehr funktioniert. Beim Starten erscheint zwar keine Fehlermeldung, aber Teständerungen in den Bibliotheken die ich per RDP am Hyper-V Host eingeloggt vorgenommen habe wurden nach Abmeldung vom Host + Neustart der Client-CM nicht übernommen. Melde ich mich von der Client-VM ab, erscheint die Fehlermeldung "Ihr Roamingprofil wurde nicht erfolgreich synchronisiert".
In der Ereignisanzeige wird weiterhin wie in diesem Beitrag AD Anmeldung via VPN dauert lange bereits genauer erläutert angezeigt, dass die VPN-Verbindung zwecks herunterfahren beendet wurde, Registry-Schlüssel noch geöffnet sind (da bin ich mir mittlerweile nicht sicher ob das wirklich was damit zutun hat) und ein paar Sekunden später eben die Fehlermeldung, dass mein Roamingprofil nicht vollständig aktualisiert werden konnte und man in den vorherigen Ereignissen Details findet (das sind die geposteten).
Das kuriose an der Sache ist, dass es anfangs ja funktioniert hat. Ich habe servergespeicherte Profile eingerichtet, das funktionierte, auch auf der Client-VM via VPN. Dann wollte ich einzelne Bibliotheks-Ordner von den servergespeicherten Profilen ausschließen (Downloads z.B.) damit keine unnötigen Daten synchronisiert werden. Dafür habe ich mich in GPOs eingearbeitet und dies via GPO versucht einzurichten. Seit dem tritt dieser Fehler bzgl. der Synchronisation auf. Die GPO habe ich deaktiviert, testweise sogar alle (auch die Standardmäßig vorhandenen) aber es tritt nach wie vor auf.
Ich bin mittlerweile ratlos und werde es mal mit einem neu erstellten Account versuchen, vielleicht ist durch die Änderungen dort etwas durcheinander gekommen.
Zitat von @certifiedit.net:
Du merkst doch schon anhand der Beschreibung, dass das ziemlich gefrimelt ist
Du merkst doch schon anhand der Beschreibung, dass das ziemlich gefrimelt ist
AD wurde bisher noch nicht für diesen Zweck eingesetzt, diese Anforderung hat sich aus verschiedenen Gründen ergeben. Unter anderem weil Entwicklersysteme in der Regel "vermurkst" sind wodurch es zu speziellen Fehlern und Problemen kommt die anschließend nur schwer nachvollziehbar sind und desweiteren für externe Entwickler natürlich auch eine gewisse Trennung zwischen Privat und Entwicklung bestehen soll.
Für Alternativen bin ich natürlich gerne offen, mir scheint es allerdings nur 3 zu geben:
Ordnerumleitungen
Erfüllt die Anforderungen nicht vollständig da neben Windows-Einstellungen eben auch jene von Programmen auf dem Server gespeichert werden sollen. Ich habe auch bedenken ob das nicht zumindest Performanceprobleme verursachen kann (von weitreichenderen ganz zu schweigen) wenn Ordner wie AppData auf den Server ausgelagert werden.
Terminalserver
Ist aus Performance-Gründen ebenfalls keine Alternative, da mehrere User mit Entwicklungsumgebungen wie etwa Visual Studio arbeiten, was natürlich entsprechend Ressourcen zieht. Außerdem werden wir voraussichtlich auch User mit schwächerer Internetleitung haben. Da dauert die Synchronisierung des Profiles natürlich etwas länger, aber dafür kann danach auf jeden Fall mit vernünftiger Geschwindigkeit gearbeitet werden da alles lokal kopiert wurde.
DirectAccess
Scheint mir grundsätzlich von der Funktion her als Alternative in Frage zu kommen, ist allerdings so momentan nicht nutzbar da hierfür clientseitig Ultimate oder Enterprise-Lizenzen benötigt werden und momentan Windows 8.1 Pro vorhanden ist. Würde ich daher gerne als letzte Möglichkeit in Betracht ziehen.
