niemandanders
Goto Top

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!

Content-Key: 257388

Url: https://administrator.de/contentid/257388

Ausgedruckt am: 28.03.2024 um 11:03 Uhr

Mitglied: cronixs
cronixs 02.03.2015 aktualisiert um 21:12:30 Uhr
Goto Top
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.
Mitglied: niemandanders
niemandanders 03.03.2015 um 14:35:01 Uhr
Goto Top
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?
Mitglied: cronixs
cronixs 05.03.2015 um 09:38:04 Uhr
Goto Top
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?
Mitglied: niemandanders
niemandanders 13.03.2015 um 10:44:46 Uhr
Goto Top
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.
Mitglied: Tabara
Tabara 21.04.2015 um 15:54:58 Uhr
Goto Top
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).
Mitglied: niemandanders
niemandanders 23.04.2015 um 11:17:16 Uhr
Goto Top
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.
Mitglied: Tabara
Tabara 23.04.2015 um 16:21:59 Uhr
Goto Top
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 face-wink 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?
Mitglied: niemandanders
niemandanders 27.04.2015 aktualisiert um 16:08:49 Uhr
Goto Top
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.
Mitglied: zg1496118
zg1496118 09.06.2015 um 13:54:57 Uhr
Goto Top
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!
Mitglied: geordi1978
geordi1978 05.08.2015 um 14:13:28 Uhr
Goto Top
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 face-smile

Habe die zwei Einstellungen in der DefaultDomainPolicy mal angepasst, mal schauen was passiert.

Achja, und DATEV haben wir auch face-smile

Hat da jemand schon mehr Infos mittlerweile?

Gruss,
Michael
Mitglied: pfechtner
pfechtner 14.10.2015 um 14:44:27 Uhr
Goto Top
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!
Mitglied: Weazel
Weazel 06.11.2015 um 10:58:06 Uhr
Goto Top
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?
Mitglied: zg1496118
zg1496118 12.11.2015 um 18:41:42 Uhr
Goto Top
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!
Mitglied: Anulu1
Lösung Anulu1 15.09.2016 um 17:24:40 Uhr
Goto Top
Hallo,
wie lautet das Script genau? Wir wollen über Nacht auch alle Freigaben vom ganzen Fileserver trennen.

Reicht openfiles.exe /disconnect?

VG,
Chris
Mitglied: niemandanders
niemandanders 15.09.2016 um 22:12:12 Uhr
Goto Top
Openfiles /disconnect /a *


Max Gültigkeit des BenutzerTickets in der default domain policy auf 18Stunden hat das Problem behoben!
Mitglied: geordi1978
geordi1978 16.09.2016 um 08:09:14 Uhr
Goto Top
Das mit dem Benutzerticket hat bei uns auch geholfen
Mitglied: Anulu1
Anulu1 16.09.2016 um 16:30:04 Uhr
Goto Top
Danke!