17
Remotedesktop-Profile regelmäßig defekt unter Server 2012 R2
Hallo,
wir haben unter anderem einen 2012 R2 DC und 2 Remotedesktop-Sitzungshosts.
Alle laufen als VMs auf einen 2012R2 HyperV Host.
Die beiden Sitzungshosts bilden eine Farm.
Die Profile liegen in einer Freigabe auf dem DC und sind im AD als Remotedesktop-Profile angegeben.
(die Lösung mit den vhdx Datenträgern für die Profile unterstützt unser Softwarehersteller nicht)
Meistens funktioniert auch alles wie gewünscht.
1-3 Mal pro Woche tritt aber folgendes Problem auf:
- ein User meldet sich normal ab
- allerdings bleiben alle Dateien seines Userprofils im Schreiben Modus vom zuletzt verwendeten Remotedesktop Server aus geöffnet (in der Freigabeverwaltung auf dem DC zu sehen)
- meldet er sich jetzt wieder an, kann sein Profil natürlich nicht geladen werden, und er bekommt ein temporäres
- in der Hälfte der Fälle ist das Servergespeicherte Profil jetzt defekt und muss neu angelegt werden.
weitere Infos:
-das Problem tritt bei unterschiedlichen Usern auf
-die Sperre der Dateien bleibt unendlich lange bestehen. (Bis zum Serverneustart oder manuellen Trennen der geöffneten Dateien)
-Im Ereignisprotokoll tritt nur beim Anmelden die Fehlermeldung auf, dass nicht auf die Dateien zugegriffen werden kann (logisch, wenn sie im Schreiben Modus geöffnet sind)
-Im Ereignisprotokoll ist KEINE Meldung zu finden, die einen Grund oder Fehler beim Abmelden anzeigt, der auf die Sperrung der Dateien oder Probleme beim Abmelden oder Zurück-Schreiben des Profils hinweist
Es ist wie gesagt kein Grund ersichtlich, warum die Verbindungen zur Freigabe nach dem Abmelden nicht getrennt werden. Das Profil scheint komplett auf den Server zurück geschrieben zu sein, aber die Dateien bleiben im Schreiben Modus geöffnet.
Hat jemand noch einen Rat?
Vielen Dank!
wir haben unter anderem einen 2012 R2 DC und 2 Remotedesktop-Sitzungshosts.
Alle laufen als VMs auf einen 2012R2 HyperV Host.
Die beiden Sitzungshosts bilden eine Farm.
Die Profile liegen in einer Freigabe auf dem DC und sind im AD als Remotedesktop-Profile angegeben.
(die Lösung mit den vhdx Datenträgern für die Profile unterstützt unser Softwarehersteller nicht)
Meistens funktioniert auch alles wie gewünscht.
1-3 Mal pro Woche tritt aber folgendes Problem auf:
- ein User meldet sich normal ab
- allerdings bleiben alle Dateien seines Userprofils im Schreiben Modus vom zuletzt verwendeten Remotedesktop Server aus geöffnet (in der Freigabeverwaltung auf dem DC zu sehen)
- meldet er sich jetzt wieder an, kann sein Profil natürlich nicht geladen werden, und er bekommt ein temporäres
- in der Hälfte der Fälle ist das Servergespeicherte Profil jetzt defekt und muss neu angelegt werden.
weitere Infos:
-das Problem tritt bei unterschiedlichen Usern auf
-die Sperre der Dateien bleibt unendlich lange bestehen. (Bis zum Serverneustart oder manuellen Trennen der geöffneten Dateien)
-Im Ereignisprotokoll tritt nur beim Anmelden die Fehlermeldung auf, dass nicht auf die Dateien zugegriffen werden kann (logisch, wenn sie im Schreiben Modus geöffnet sind)
-Im Ereignisprotokoll ist KEINE Meldung zu finden, die einen Grund oder Fehler beim Abmelden anzeigt, der auf die Sperrung der Dateien oder Probleme beim Abmelden oder Zurück-Schreiben des Profils hinweist
Es ist wie gesagt kein Grund ersichtlich, warum die Verbindungen zur Freigabe nach dem Abmelden nicht getrennt werden. Das Profil scheint komplett auf den Server zurück geschrieben zu sein, aber die Dateien bleiben im Schreiben Modus geöffnet.
Hat jemand noch einen Rat?
Vielen Dank!
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: 257388
Url: https://administrator.de/contentid/257388
Ausgedruckt am: 25.11.2024 um 15:11 Uhr
17 Kommentare
Neuester Kommentar
Hallo!
Das Thema ist ja schon 3 Monate alt - ich habe genau den selben "Bug".
Hast du (oder jemand anders) eine Lösung gefunden?
Am schlimmsten ist es, wenn die Terminal Server neustarten und jemand noch angemeldet war (trotz vorher laufendem PowerShell Abmeldeskript / Task) dann ist der Profildatenträger definitiv hinüber! Ich habe noch keine Möglichkeit gefunden ihn dann wieder öffnen zu lassen (lässt sich auch nicht mounten).
Mittlerweile legt das Share Schattenkopien an - außer den Einstellungen der einzelnen Anwendungen liegt zum Glück nichts wichtiges bei uns in den Datenträgern. Die Kollegen können dann mit 6 - 12 Stunden "Datenverlust" leben. Alle wichtigen Daten liegen auf Shares oder in anderen Anwendungen.
Trotzdem mehr als ärgerlich.
Wenigstens bin ich damit nicht allein...
Danke!
Edit:
Unsere Umgebung ist soweit auch gleich.
- Member DC läuft mit Windows Server 2008 R2 (dort liegen die Datenträger)
- Windows Server 2012 R2 RDS Farm (3 Sitzungshosts)
- Alles virtualisiert auf Hyper-V 2012 R2.
Das Thema ist ja schon 3 Monate alt - ich habe genau den selben "Bug".
Hast du (oder jemand anders) eine Lösung gefunden?
Am schlimmsten ist es, wenn die Terminal Server neustarten und jemand noch angemeldet war (trotz vorher laufendem PowerShell Abmeldeskript / Task) dann ist der Profildatenträger definitiv hinüber! Ich habe noch keine Möglichkeit gefunden ihn dann wieder öffnen zu lassen (lässt sich auch nicht mounten).
Mittlerweile legt das Share Schattenkopien an - außer den Einstellungen der einzelnen Anwendungen liegt zum Glück nichts wichtiges bei uns in den Datenträgern. Die Kollegen können dann mit 6 - 12 Stunden "Datenverlust" leben. Alle wichtigen Daten liegen auf Shares oder in anderen Anwendungen.
Trotzdem mehr als ärgerlich.
Wenigstens bin ich damit nicht allein...
Danke!
Edit:
Unsere Umgebung ist soweit auch gleich.
- Member DC läuft mit Windows Server 2008 R2 (dort liegen die Datenträger)
- Windows Server 2012 R2 RDS Farm (3 Sitzungshosts)
- Alles virtualisiert auf Hyper-V 2012 R2.
Hallo,
leider haben wir noch keine Lösung gefunden, und das Problem besteht nach wie vor.
Allerdings arbeiten wir nicht mit den Profil-Datenträgern sondern mit den klassischen Servergespeicherten Profilen, die in einfachen freigegebenen Ordnern liegen.
Das Problem könnte natürlich trotzdem den selben Ursprung haben.
Außer dass unser DC ein 2012 R2 ist, ist die Umgebung tatsächlich identisch.
Ich war schon am überlegen, ob ich die Profile auf einen anderen Server verschiebe... aber da es bei Dir ein 2008 R2 ist, nimmt mir das etwas die Hoffnung, dass es dadurch behoben ist.
Was habt ihr für einen Virenscanner?
Läuft irgendwelche besondere Software auf dem System?
leider haben wir noch keine Lösung gefunden, und das Problem besteht nach wie vor.
Allerdings arbeiten wir nicht mit den Profil-Datenträgern sondern mit den klassischen Servergespeicherten Profilen, die in einfachen freigegebenen Ordnern liegen.
Das Problem könnte natürlich trotzdem den selben Ursprung haben.
Außer dass unser DC ein 2012 R2 ist, ist die Umgebung tatsächlich identisch.
Ich war schon am überlegen, ob ich die Profile auf einen anderen Server verschiebe... aber da es bei Dir ein 2008 R2 ist, nimmt mir das etwas die Hoffnung, dass es dadurch behoben ist.
Was habt ihr für einen Virenscanner?
Läuft irgendwelche besondere Software auf dem System?
Hallo,
also bei uns lassen sich dann die Datenträgerdateien / VHDX Dateien gar nicht mehr öffnen (weil der entsprechende TerminalServer - angeblich - noch darin liest).
Bisher waren die Dateien damit unbrauchbar (Neustarts etc. heben den Status nicht auf - bzw. zumindest die TerminalServer können die Datei nicht mehr mounten).
Ich denke mal die Hoffnung muss ich dir da leider auch nehmen - wird bei 2008 R2 genauso sein.
Wir verwenden auf den TerminalServern und unseren Clients McAfee Endpoint Protection.
Die restlichen Server inkl. Hyper-V selbst (4 Augen Prinzip) arbeiten ansonsten mit einer Sophos Server Protection Lösung - natürlich jeder für sich.
Da haben wir bestimmt keine Schnittpunkte oder?
Auf den Server Terminal Servern läuft abgesehen von Office 2010 und ein paar Java / Browserapplikationen nichts.
Starten eure Terminal-Server neu?
also bei uns lassen sich dann die Datenträgerdateien / VHDX Dateien gar nicht mehr öffnen (weil der entsprechende TerminalServer - angeblich - noch darin liest).
Bisher waren die Dateien damit unbrauchbar (Neustarts etc. heben den Status nicht auf - bzw. zumindest die TerminalServer können die Datei nicht mehr mounten).
Ich denke mal die Hoffnung muss ich dir da leider auch nehmen - wird bei 2008 R2 genauso sein.
Wir verwenden auf den TerminalServern und unseren Clients McAfee Endpoint Protection.
Die restlichen Server inkl. Hyper-V selbst (4 Augen Prinzip) arbeiten ansonsten mit einer Sophos Server Protection Lösung - natürlich jeder für sich.
Da haben wir bestimmt keine Schnittpunkte oder?
Auf den Server Terminal Servern läuft abgesehen von Office 2010 und ein paar Java / Browserapplikationen nichts.
Starten eure Terminal-Server neu?
Hallo,
Nein wir haben da Eset im Einsatz.
Bei uns läuft Datev auf den Terminalservern, im Moment haben wir das im Verdacht, da es bei der Installation sehr viel an den Windows Einstellungen ändert, vor allem was das Netzwerk angeht.
Ansonsten haben wir noch die Energieoptionen der Netzwerkkarten an den Clients angepasst, so dass diese nicht mehr zum Energiesparen deaktiviert werden können. Hier war die Vermutung, dass die Terminalsitzungen vielleicht nicht sauber getrennt werden, wenn die Karte plötzlich aus ist. Denn es scheint oft zu passieren, wenn der Benutzer länger nicht am Rechner sitzt. (stanby Modus etc ist auch deaktiviert)
Die Terminalserver laufen durchgehend.
Als Notlösung haben wir eine Geplante Aufgabe, die jede nach auf dem DC per openfiles.exe alle Freigabesitzungen der Benutzer trennt. Aber eine wirkliche Lösung ist das auch nicht.
Ansonsten habe ich noch keine neuen Erkenntnisse.
Nein wir haben da Eset im Einsatz.
Bei uns läuft Datev auf den Terminalservern, im Moment haben wir das im Verdacht, da es bei der Installation sehr viel an den Windows Einstellungen ändert, vor allem was das Netzwerk angeht.
Ansonsten haben wir noch die Energieoptionen der Netzwerkkarten an den Clients angepasst, so dass diese nicht mehr zum Energiesparen deaktiviert werden können. Hier war die Vermutung, dass die Terminalsitzungen vielleicht nicht sauber getrennt werden, wenn die Karte plötzlich aus ist. Denn es scheint oft zu passieren, wenn der Benutzer länger nicht am Rechner sitzt. (stanby Modus etc ist auch deaktiviert)
Die Terminalserver laufen durchgehend.
Als Notlösung haben wir eine Geplante Aufgabe, die jede nach auf dem DC per openfiles.exe alle Freigabesitzungen der Benutzer trennt. Aber eine wirkliche Lösung ist das auch nicht.
Ansonsten habe ich noch keine neuen Erkenntnisse.
Hi,
DATEV ist daran vermutlich und ausnahmsweise nicht schuld. Wir betreiben mehrere DATEVumgebungen in unserem RZ und leiden leider exakt unter gleichem Problem, allerdings haben wir auch ein paar Nicht-DATEV-Umgebungen die ebenfalls ab und an derlei Profilzicken machen. Haben eine DATEV Umgebung mit einem 2008R2 File und "nur" der WTS ist ein 2012R2 und bei dem kams bislang nicht vor.
Wäre happy wenn jemand bereits neue Infos hat, oder vielleicht über ein paar andere Links gestolpert ist - ich guck alle paar Wochen mal wieder nach dem Thema aber es scheint nicht genug Leidensgenossen zu geben, oder ich such nicht richtig....
Bei uns läuft übrigens entweder kein Virenscanner oder der DATEV Viwas auf dem RDS (Singlebetrieb, keine Farm).
DATEV ist daran vermutlich und ausnahmsweise nicht schuld. Wir betreiben mehrere DATEVumgebungen in unserem RZ und leiden leider exakt unter gleichem Problem, allerdings haben wir auch ein paar Nicht-DATEV-Umgebungen die ebenfalls ab und an derlei Profilzicken machen. Haben eine DATEV Umgebung mit einem 2008R2 File und "nur" der WTS ist ein 2012R2 und bei dem kams bislang nicht vor.
Wäre happy wenn jemand bereits neue Infos hat, oder vielleicht über ein paar andere Links gestolpert ist - ich guck alle paar Wochen mal wieder nach dem Thema aber es scheint nicht genug Leidensgenossen zu geben, oder ich such nicht richtig....
Bei uns läuft übrigens entweder kein Virenscanner oder der DATEV Viwas auf dem RDS (Singlebetrieb, keine Farm).
Hallo,
danke, dann können wir das wohl doch ausschließen.
Habt Ihr an den nicht-Datev Servern irgendwelche besonderen Einstellungen vorgenommen? Oder habt ihr eventuell die Grundinstallation der Server trotzdem nach Datev Anleitung durchgeführt?
Interessant wäre ja noch die Konstellation 2012R2 File und 2008R2 WTS. Ich denke aber, es liegt tatsächlich am Fileserver, da dort die Freigaben offen hängen bleiben.
Sind eure Server alle einzeln von Hand installiert, oder sind es geklonte Installationen bzw. ausgerollte Images?
Tritt das bei euch nur bei WTS-Farmen auf, oder habt Ihr auch einzelne WTS, die trotzdem Servergespeicherte Profile nutzen?
Liegen die Profilfreigaben bei Euch immer auf einem Domänencontroller, auf einem Datev Fileserver, oder einem separaten Server? Ich wollte sie mal auf einen völlig neutralen Server legen, hatte aber noch nicht die Zeit dazu.
Wir umgehen das ganze derzeit, indem wir jede Nach alle Freigaben trennen.
Das Problem an sich wird dadurch zwar nicht behoben, und es wirkt auch nur, wenn sich der Benutzer erst am Folgetag wieder anmeldet, aber einen Großteil der Defekte kann man so erstmal umgehen, bis es eine richtige Lösung gibt.
danke, dann können wir das wohl doch ausschließen.
Habt Ihr an den nicht-Datev Servern irgendwelche besonderen Einstellungen vorgenommen? Oder habt ihr eventuell die Grundinstallation der Server trotzdem nach Datev Anleitung durchgeführt?
Interessant wäre ja noch die Konstellation 2012R2 File und 2008R2 WTS. Ich denke aber, es liegt tatsächlich am Fileserver, da dort die Freigaben offen hängen bleiben.
Sind eure Server alle einzeln von Hand installiert, oder sind es geklonte Installationen bzw. ausgerollte Images?
Tritt das bei euch nur bei WTS-Farmen auf, oder habt Ihr auch einzelne WTS, die trotzdem Servergespeicherte Profile nutzen?
Liegen die Profilfreigaben bei Euch immer auf einem Domänencontroller, auf einem Datev Fileserver, oder einem separaten Server? Ich wollte sie mal auf einen völlig neutralen Server legen, hatte aber noch nicht die Zeit dazu.
Wir umgehen das ganze derzeit, indem wir jede Nach alle Freigaben trennen.
Das Problem an sich wird dadurch zwar nicht behoben, und es wirkt auch nur, wenn sich der Benutzer erst am Folgetag wieder anmeldet, aber einen Großteil der Defekte kann man so erstmal umgehen, bis es eine richtige Lösung gibt.
Hi,
die Server sind zum Großteil per Hand installiert, oder der Rest gesysprept und geclont via vSphere Center, da virtuelle Maschinen. Der DATEV-File ist gleichzeitig immer auch DC. Kein Farmbetrieb, dennoch setzen wir servergespeicherte Profile ein, u.a. wg. der Datensicherung, die wir von Fileservern länger vorhalten, als von einem Terminalserver auf dem eigentlich keine Daten zu liegen haben. Datev wird nach Anleitung installiert - bei allem anderen reagieren die Herren und Damen vom Datevsupport allergisch
Die Nicht-Datevumgebungen wurden ohne Anleitung erstellt, aber mir würde nun grad nix einfallen was da noch groß von abweichen würde, die größten Anpassungen gabs früher bei den TS mit dem userlogon, bzw. der späteren WTSanpassung, die Fileserver sind ja recht neutral und die NTFS-Berechtigungen nach MS-Empfehlung.
Ich hatte bei meiner letzten Googletour einen anderen Leidensgenossen gelesen, der schrieb, daß der Fehler dann zuschlägt wenn die Sitzung auf dem WTS etwa 10 Stunden alt wäre und sich der User dann abmeldet, wenn sie dann darüber hinaus geht, also bspw. 11 Stunden gäbe es wiederum keine Probleme mehr.
Bislang ist mir noch nichts eingefallen welcher Vorgang ein Zeitlimit von um die 10h hätte, der da reinfunken könnte. Ich hab das zwar noch nicht bewusst geprüft mit den 10h, aber so rein gefühlt könnte es tatsächlich auch bei uns hinkommen. Die Leute bei denen das Profil immer wieder zickt sind keine "Kurzarbeiter", sprich die die Dienst nach Plan tun und sich nach ~8h abmelden die sind eigentlich nie betroffen.
Unsere aktuell bislang noch nicht verworfenen Verdachtsmomente:
- Software die nicht korrekt oder schnell genug schließt. Hatten einen Kunden bei dem die Profilproblematik ganz massiv einsetzte, nachdem eine CTI-Anwendung in Betrieb genommen wurde.
- Anwender die den Abmeldevorgang nicht zuende laufen lassen, sondern dann zusätzlich auch noch das Kreuzlein betätigen, oder ihren eigenen PC schon runterfahren. Wenn ich die Anwender fragte haben die mir häufig auch bestätigt, daß sie einen Verbindungsabbruch, oder PCAbsturz (was der Anwender da eben so drunter versteht) hatten.
- Eine Besonderheit gäbs bei uns: Unsere Terminalserver haben 2 IPs auf der gleichen NIC, der DatevDBserver ist dann nur in einem dieser Netze. Bei euch vielleicht auch sowas ähnliches netzwerkseitig vom Standard abweichend?
die Server sind zum Großteil per Hand installiert, oder der Rest gesysprept und geclont via vSphere Center, da virtuelle Maschinen. Der DATEV-File ist gleichzeitig immer auch DC. Kein Farmbetrieb, dennoch setzen wir servergespeicherte Profile ein, u.a. wg. der Datensicherung, die wir von Fileservern länger vorhalten, als von einem Terminalserver auf dem eigentlich keine Daten zu liegen haben. Datev wird nach Anleitung installiert - bei allem anderen reagieren die Herren und Damen vom Datevsupport allergisch
Die Nicht-Datevumgebungen wurden ohne Anleitung erstellt, aber mir würde nun grad nix einfallen was da noch groß von abweichen würde, die größten Anpassungen gabs früher bei den TS mit dem userlogon, bzw. der späteren WTSanpassung, die Fileserver sind ja recht neutral und die NTFS-Berechtigungen nach MS-Empfehlung.Ich hatte bei meiner letzten Googletour einen anderen Leidensgenossen gelesen, der schrieb, daß der Fehler dann zuschlägt wenn die Sitzung auf dem WTS etwa 10 Stunden alt wäre und sich der User dann abmeldet, wenn sie dann darüber hinaus geht, also bspw. 11 Stunden gäbe es wiederum keine Probleme mehr.
Bislang ist mir noch nichts eingefallen welcher Vorgang ein Zeitlimit von um die 10h hätte, der da reinfunken könnte. Ich hab das zwar noch nicht bewusst geprüft mit den 10h, aber so rein gefühlt könnte es tatsächlich auch bei uns hinkommen. Die Leute bei denen das Profil immer wieder zickt sind keine "Kurzarbeiter", sprich die die Dienst nach Plan tun und sich nach ~8h abmelden die sind eigentlich nie betroffen.
Unsere aktuell bislang noch nicht verworfenen Verdachtsmomente:
- Software die nicht korrekt oder schnell genug schließt. Hatten einen Kunden bei dem die Profilproblematik ganz massiv einsetzte, nachdem eine CTI-Anwendung in Betrieb genommen wurde.
- Anwender die den Abmeldevorgang nicht zuende laufen lassen, sondern dann zusätzlich auch noch das Kreuzlein betätigen, oder ihren eigenen PC schon runterfahren. Wenn ich die Anwender fragte haben die mir häufig auch bestätigt, daß sie einen Verbindungsabbruch, oder PCAbsturz (was der Anwender da eben so drunter versteht) hatten.
- Eine Besonderheit gäbs bei uns: Unsere Terminalserver haben 2 IPs auf der gleichen NIC, der DatevDBserver ist dann nur in einem dieser Netze. Bei euch vielleicht auch sowas ähnliches netzwerkseitig vom Standard abweichend?
Hallo,
bei uns tritt es tatsächlich auch immer nur auf, wenn die Sitzung etwas mehr als 10 Stunden nach der Anmeldung abgemeldet wird.
(Die 10 Stunden Verbindungszeit werden übrigens nur erreicht, wenn zwischendurch dauerhaft Dateien geöffnet sind. Sonst läuft er nach 15Minuten Leerlauf ins autodisconnect, und zählt beim nächsten Zugriff von vorne.)
Es gibt zwei Einstellungen in der Default Domain Policy, die mir dazu spontan einfallen:
Max. Gültigkeit des Benutzertickets: 10h
Max. Gültigkeit des Diensttickets: 600min
Wir haben das jetzt testweise bei einem Netz auf 18 Stunden gestellt, und müssen erstmal abwarten.
Die Chance ist aber relativ hoch, dass es damit zu tun hat.
Vielleicht könnt Ihr das parallel auch mal versuchen? (Ich habe den DC nach der Anpassung neu gestartet, um sicher zu stellen, dass alles übernommen wird.)
Bei uns haben die Terminalserver normalerweise nur eine IP.
bei uns tritt es tatsächlich auch immer nur auf, wenn die Sitzung etwas mehr als 10 Stunden nach der Anmeldung abgemeldet wird.
(Die 10 Stunden Verbindungszeit werden übrigens nur erreicht, wenn zwischendurch dauerhaft Dateien geöffnet sind. Sonst läuft er nach 15Minuten Leerlauf ins autodisconnect, und zählt beim nächsten Zugriff von vorne.)
Es gibt zwei Einstellungen in der Default Domain Policy, die mir dazu spontan einfallen:
Max. Gültigkeit des Benutzertickets: 10h
Max. Gültigkeit des Diensttickets: 600min
Wir haben das jetzt testweise bei einem Netz auf 18 Stunden gestellt, und müssen erstmal abwarten.
Die Chance ist aber relativ hoch, dass es damit zu tun hat.
Vielleicht könnt Ihr das parallel auch mal versuchen? (Ich habe den DC nach der Anpassung neu gestartet, um sicher zu stellen, dass alles übernommen wird.)
Bei uns haben die Terminalserver normalerweise nur eine IP.
Hallo zusammen,
gibt es zu diesem Problem mittlerweile eine Lösung?
Bei uns tritt dieses Problem nämlich ebenfalls auf. Die Umgebung läuft ebenfalls unter 2012R2 als File- und Terminalserver sowie mit servergespeicherten Profilen.
Viele Grüße!
gibt es zu diesem Problem mittlerweile eine Lösung?
Bei uns tritt dieses Problem nämlich ebenfalls auf. Die Umgebung läuft ebenfalls unter 2012R2 als File- und Terminalserver sowie mit servergespeicherten Profilen.
Viele Grüße!
Hallo in die Runde
ich reihe mich mal in die Liste der "Betroffenen" ein ... gleiches Verhalten, sprich:
Servergespeicherte Profile unter 2012R2 RDS
Wenn der Profilserver 2008R2 ist läuft es, wenn der Profilserver 2012R2 ist haben wir die gleichen Probleme. Lustigerweise laut aktueller Vermutung wirklich bei den Leuten die lange arbeiten.
Ist bestimmt ne versteckte Sperre von MS wegen der maximalen Arbeitszeit pro Tag von 10h
Habe die zwei Einstellungen in der DefaultDomainPolicy mal angepasst, mal schauen was passiert.
Achja, und DATEV haben wir auch
Hat da jemand schon mehr Infos mittlerweile?
Gruss,
Michael
ich reihe mich mal in die Liste der "Betroffenen" ein ... gleiches Verhalten, sprich:
Servergespeicherte Profile unter 2012R2 RDS
Wenn der Profilserver 2008R2 ist läuft es, wenn der Profilserver 2012R2 ist haben wir die gleichen Probleme. Lustigerweise laut aktueller Vermutung wirklich bei den Leuten die lange arbeiten.
Ist bestimmt ne versteckte Sperre von MS wegen der maximalen Arbeitszeit pro Tag von 10h
Habe die zwei Einstellungen in der DefaultDomainPolicy mal angepasst, mal schauen was passiert.
Achja, und DATEV haben wir auch
Hat da jemand schon mehr Infos mittlerweile?
Gruss,
Michael
Sehr geehrte "Mitstreiter",
wir reihen uns auch mit in die Gruppe der Betroffenen ein, die bis dato auch noch keine Lösung gefunden haben. Monatlich fallen diesem Problem 1-2 Profile zum Opfer.
Kurz zur Umgebung:
- ESX-Serverumgebung
- alle Server sind 2012 R2 (1x AD, 1x SQL, 2x TS)
- Datev, Viwas und Office 2007
- Profile sind auf den TS abgelegt
Die User wurden zur Domainumstellung neu eingerichtet. Die User, die nun bereits einmal betroffen waren, sind aktuell nicht ein zweites Mal aufgetreten, was aber nichts zu heißen hat.
Anhand der Infos hier gehe ich davon aus, dass weder die Virtualisierungsmethode, Office, AV-Programme oder Datev schuld an diesen Umständen sind.
Die Policy habe ich noch nicht hinsichtlich der Zeit angepasst, da ein Profil bei ca. 9,25h betroffen war.
Beste Grüße!
wir reihen uns auch mit in die Gruppe der Betroffenen ein, die bis dato auch noch keine Lösung gefunden haben. Monatlich fallen diesem Problem 1-2 Profile zum Opfer.
Kurz zur Umgebung:
- ESX-Serverumgebung
- alle Server sind 2012 R2 (1x AD, 1x SQL, 2x TS)
- Datev, Viwas und Office 2007
- Profile sind auf den TS abgelegt
Die User wurden zur Domainumstellung neu eingerichtet. Die User, die nun bereits einmal betroffen waren, sind aktuell nicht ein zweites Mal aufgetreten, was aber nichts zu heißen hat.
Anhand der Infos hier gehe ich davon aus, dass weder die Virtualisierungsmethode, Office, AV-Programme oder Datev schuld an diesen Umständen sind.
Die Policy habe ich noch nicht hinsichtlich der Zeit angepasst, da ein Profil bei ca. 9,25h betroffen war.
Beste Grüße!
Guten Tag,
Als ebenfalls betroffener würde mich wirklich intressieren ob die Änderung der Default Domain Policy zu irgenteinem Ergebnis oder zumindest zu einer Erkenntnis geführt hat?
Als ebenfalls betroffener würde mich wirklich intressieren ob die Änderung der Default Domain Policy zu irgenteinem Ergebnis oder zumindest zu einer Erkenntnis geführt hat?
Hallo,
ich habe die Änderung an der Default Domain Policy durchgeführt (Gültigkeit auf 17 Std. bzw. 1020 Minuten) und seitdem ist ziemlich Ruhe.
Viele Grüße!
ich habe die Änderung an der Default Domain Policy durchgeführt (Gültigkeit auf 17 Std. bzw. 1020 Minuten) und seitdem ist ziemlich Ruhe.
Viele Grüße!
Hallo,
wie lautet das Script genau? Wir wollen über Nacht auch alle Freigaben vom ganzen Fileserver trennen.
Reicht openfiles.exe /disconnect?
VG,
Chris
wie lautet das Script genau? Wir wollen über Nacht auch alle Freigaben vom ganzen Fileserver trennen.
Reicht openfiles.exe /disconnect?
VG,
Chris
Openfiles /disconnect /a *
Max Gültigkeit des BenutzerTickets in der default domain policy auf 18Stunden hat das Problem behoben!
Max Gültigkeit des BenutzerTickets in der default domain policy auf 18Stunden hat das Problem behoben!
Das mit dem Benutzerticket hat bei uns auch geholfen
Danke!
