goat82

Hi Zusammen, ich habe viele Freigaben die per Zugriffsberechtigung auf die Freigabe und über die NTFS Ordersicherheitseinstellungen geregelt sind. Ich möchte nicht den einfachen erfolgreichen oder fehlgeschlagenen Dateizugriff loggen, sondern nur erfahren wenn auf eine Freigabe oder ein NTFS Ordner eine Berechtigung entfernt oder geändert oder wenn ein NFTS Ordner gelöscht wird. Funktioniert das irgendwie mit Hausmittel? Danke für euche Tipps. LG Gost

Das mit dem Jumphost und der Devicecal verstehe ich nicht. Ich bezahle eine Device CAL für ein Device an dem sich x User anmelden können. Soweit so gut. Vermutlich bedeutet diese Device cal nur, dass sich x User über das Device anmelden können aber nicht gleichzeitig korrekt ? Warum es nicht erlaubt sein sollte dies über einen virtuellen Jumphost zu realisieren verstehe ich nicht. Ein Device ist ein Device egal ob Blech oder Virtuell oder verstehe ich etwas falsch. Genau das wäre meine Lösung mit dem jump Host, vorausgesetzt es ist legal. Auf dem RDS Server ist eine Projektsoftware installiert die von mehreren Servicemitarbeitern für den Kundeneinsatz genutzt wird. Die Projekte und die Servicemitarbeiter sind hier aber nicht fest zugeteilt, die Projekte laufen auch unterschiedlich lang und haben auch unterschiedlich viele Servicemitarbeiter. Gibt es ein neuen Auftrag, benötigen neue Servicemitarbeiter Zugriff für X Wochen. Wird ein Kollege Krank, muß der Kollege einspringen usw.

puh, danke erstmal für die 2 Antworten. Wie wäre es wenn ich eine VM als Jump Host erstelle und zu den 10 USer Cals eine oder zwei Device Cals kaufe. Können sich dann alle User mit ihrem persönlichen AD Login auf dem Jump Host anmelden und von dort eine Verbindung mit dem RDS Server aufbauen sodass z.B: 10 User sich die beiden Lizenzen teilen ? Hintergrund ist nicht der Geiz, sondern, dass das System von mehreren Personen kurzfristig genutzt werden soll. Der Personenkreis ändert sich oft. Eine User Cal mit 60-90 Tagen Beschränkung ist daher nicht so zielführend.

Hi Zusammen, wir haben einen RDS Server mit 10 User cals. Da MS ja die Lizenz außer bei der Console oder mit /Admin beim einmaligen Anmelden für 60 Tage sperrt überlege ich einen Shared User "Gemeinsamer User" anzulegen. Dieser könnte dann von verschiedenen User jedoch nie gleichzeitig benutzt werden. Die Nachweispflicht bzw. wenn jemand etwas löscht oder Unsinn treibt kann bei dem Terminalserver vernachlässigt werden. Toll wäre wenn das A legal ist und B so funktioniert dass ich am Ende von 8 festen User CALS 2 für Shared Nutzer habe, welche sich wirklich nur selten anmelden werden. Arbeitet "Gemeinsamer Nutzer1", soll beim erneuten Verbinden mit einem anderen User mit dem selben Login "Gemeinsamer Nutzer1" die Meldung erscheinen. "Benutzer oder Session bereits aktiv, damit der neue Benutzer weiß dass ein Kollege bereits arbeitet und sich nicht am Terminalserver abgemeldet hat. So könnte er dann den Login mit dem eingerichteten "Gemeinsamer Nutzer2" versuchen. Kann mir jemand etwas zu A und B sagen ? Besten Dank LG Felix

Ich kenne wirklich keinen Betrieb der eine VMwareumgebung hat und keine VM Snapshots einsetzt. Insbesonde vor wichtigen, kritischen Softwareupdates oder sonstigen Installationen. Diese Revertmöglichkeit mit einem Rollback in Sekunden bietet glaube ich kein anderes System, von demher ein absoluter Pluspunkt. Klar ist ein Snapshot kein Backup und ein ESX, Storage und Vcenter gehört immer überwacht und bestenfalls redundant ausgelegt, wenn es das Budget hergibt. Und logisch kosten Snapshots immer performance und sind unflexibel, da man die VM nicht ändern kann, wenn Snapshots existieren. Bei uns werden Snapshots automatisch gelöscht wenn Sie älter als 2 Wochen sind, zumindest im Vcenter. Auch ich kenne das Problem mit vollem Storage oder ESX durch Snapshot, hatte ich auch schon 3-4mal erlebt aber hier sehe ich das als keinen Fehler an auch kein Nachteil am System VM oder "Snapshot" sondern eben ein Fehler des Admins wenn er den Speicher oder seine Aufgaben nicht im Auge hat. Alles Theorie und Praxis, der Rest ist Lehrgeld. @Daabm. GPO und Logonscripte haben mit DFS miteinander zu tun, zumindest in meinem Fall. Wenn Gpos und Logonscripte auf Freigaben auf Server B zeigen welcher via DFS-R auf Server A repliziert wird. 60% der User aber diese GPO nicht haben und per Namespacereferal auf Server A gehen ist logisch das es unpassend ist die Daten auf beiden Servern im doofsten Fall gleichzeitig zu laden und hin und herreplizieren und wenn dann noch gleichzeitig ein Backup streiklen sollte auf einem Server ist der Datenverlust und das Geschrei groß......... Ich bin hier um Lösungen zu erfragen, mehr nicht. Das die derzeitige Umgebung höchst unprofessionell und strittig ist ist, weiß ich ja selbst Gibt es nun eine gute Alternative ?

Also so langsam glaube ich ist alles auf einem guten Weg. DFS läuft nun seit 3 Tagen zwar mit jede Menge Warnungen, siehe unten, aber es läuft. Es dauert eben Tage bis die Backlogs abgearbeitet sind. Ich habe es nur hinbekommen indem ich das NTFS Journal erhöht habe. Hier war noch 512MB eingestellt, eindeutig zu wenig für x Millionen Daten. Zudem habe ich einzelne Replikationsgruppen nach und nach auf eine höhere Statinggröße gezogen. Dies konnte ich nicht gleichzeitig machen, da die Backlogs und Konflikte im DFSPrivate Ordner sich angesammelt haben und so wäre mir die Disc vollgelaufen - Ein Todesstoß von hinten , sozusagen. Ich hoffe, dass nun alle Ordner abgearbeitet werden und es nun hoffentlich eine Zeit lang läuft. Spätestens nach 10 Tagen ist aber wieder die DFS Datenbank zerschossen und ich muss 7h ein chkdsk machen. Mal sehen ob es nun besser läuft. Wenn ja, habe ich Zeit die gemachten Fehler zu korrigieren. Es existiert natürlich ein funktionelles Backup, welches aber nicht performt, denn der Restore der 25 TB dauert >24h. Ein Chkdsk /F dauert ca. 5-7h Bevor man an ein Konzept geht muss man erst mal reverse engeneering machen und das alles sauber analysieren und dokumentieren. Es gibt hunterte GPOs, login Scripte usw. die da reinwursteln. Natürlich würde ich niemals so viele Daten auf einem Volume und auch niemals mit DFS-R synchronisieren aber hier ist bzw. war es immer so. Ich würde im ersten Schritt, wenn die Daten via DFS-R hoffentlich synchron sind erstmal die direkten Freigabeberechtigungen von Server B nehmen, dann läuft DFS-R sicherlich auch mit weniger Konflikten. Dann kann man schauen was möglich ist. Aufgrund den Broadcom Vmware Mondpreisen überdenken ja auch viele Ihre Infrastruktur oder schauen sich andere Anbieter an. In diesem Fall ist es auch gerechtfertigt, da es ein Stand Alone ESX ist mit nur 3 Vms ist (File, DNS,DHCP). Hier würde sich ggf. eine Windowsmaschine / Cluster/Storage Replica / Andere Lösung mit dem anderen Stand alone Host anbieten. Die Vorteile von ESX (Snapshots, HA, Vmotion usw.) wurden auf diesen beiden Stand alone ESXi nie genutzt. The DFS Replication version vector size has exceeded acceptable limits. The DFS Replication version vector size has reached back to the acceptable limits. )

Hi Daabm, das Konzept war vor 15 Jahren sicher angemessen. Nun sind die Daten halt mehr als angewachsen und das ganze wurde mehr als Stiefmütterlich behandelt. Der Grund liegt an den fehlenden Resourcen. Nun kann man natürlich meckern und die Ferrilösung anbieten, aber ich kann beim besten Willen auf die Schnelle kein Ferari herzaubern. Es handelt sich um ein produktives System und um keine Spielewiese. Selbst wenn ein Storage Replica oder anderes umgesetzt werden würde, müsste ich zuvor die Datenkonsistenz von Server A und B wiederherstellen. Die Daten sind von beiden Server in Zugriff (>400 User). Ich kann hier auch nicht einfach mal rumspielen, Replikationspartner oder Freigaben löschen und das Ganze auf die Harte Tour gerade biegen bis ein angemessenes, natürlich besseres Konzept angewendet werden kann. Daher möchte ich erstmal die Daten von Server A und B auf einen Stand bringen (am liebsten via DFS wenn es vernünpftig und performant laufen würde), Server B vom Zugriff und von den Replikationsgruppen entfernen und dann ein neues, sauberes Konzept erstellen und umsetzen mit den MIttel die da sind. Hier nehme ich gerne Rat und Vorschläge an und behare nicht auf das alte und langsame DFS-R. Ein gespiegeltes Rechenzentrum, Vsphere Cluster oder ähnliches steht aber nicht zur Verfügung. Ebenso ist primäre Aufgabe die Datenkonsistenz wiederherzustellen auch wenn ich nicht denke das dies mit DFSR erreicht werden kann, weil es einfach zu viele Daten sind. (Delta ist nur 400GB und nur ca. 0,5Mio Daten aber das reicht anscheinend DFS-R um den Dienst zu verweigern. Ich werde mal versuchen am Wochenende mit Robocopy die Daten von Server A auf Server B zu kopieren in der Hoffnung, das DFS-R dann wieder auf die Beine kommt damit man das ganze endlich vernünftig angehen kann.

Leider nein. Beide Server laufen auf getrennten, unverwalteten Stand alone ESX Server ohne Vsphere und ohne Vmotion oder ohne Speicherreplikation. Ursprünglich war die Idee vor mind. 15 Jahren so, dass Auf Server A gearbeitet wird, die Freigaben via DFS-R auf Server B repliziert werden. Fullbackup wird dann auf Server B gefahren, weil dort keine Zugriffe/Änderungen sind. Heute sind es knapp 23TB und die Synchronisierung will nicht mehr richtig, weil die DFSR Datenbank wahrscheinlich zu groß ist. Mein Ansatz ist DFSR auf neue Volumes zu unterteilen, sodass nicht mehr als 4TB / Partition (& DFS Datenbank) Daten repliziert werden. Ein neues Konzept wäre natürlich besser aber es gibt derzeit kein Platz um die 23TB auszulagern oder zu puffern. Weiß jemand ob VSC mit DFSR zu vielen Problemen führt. VSC läuft leider auch 3x täglich auf dem großen DFSR Volume mit 23TB. ISt sicher nicht best practise aber die Strukturen sind so und ich muss erst eine Alternative haben bwvor ich die vielen verwöhnten User davon entwöhnen kann.

so einfach ist es nicht, er sagt die Daten werden auf beiden Freigaben geändert, dies habe ich aber geprüft und stimmt nicht. Auch wird nur noch von B auf A repliziert, der Rest landet dann im Conflictand Deleted DFSR_Private Ordner auf Server A. Manuell den Sync antriggern hilft nicht. Nach ca. 10 Tagen funktioniert es dann irgendwann. Vermutlich ist die Datenbank oder die Datenmenge einfach zu groß. Ich habe den Mist nicht erstellt aber es geht hier um 22Tb auf einem Volume, also 1DFSR Datenbank für 22TB was wahnsinn ist. Eine neue Replikationsgruppe auf einem neuen Volume klappt natürlich einwandfrei. Nur habe ich 8TB frei wo ich umlagern kann. 16TB würden so dennoch auf der großen Disk liegen. Und die Disk in Vmware verkleinern ist auch nicht mit Boardmitteln möglich und führt zu einer längeren downtime von Server B

Hi daabm, vielen Dank für die 3 Tipps, das hilft sicher gut weiter. Ich sehe es so, dass die Referals funktionieren, aber aus unerklärlichen Gründen wird eine Session zum Server B auf die DFSRoots aufgemacht, auch wenn am Server B (deaktiviertes Referral) keine Daten geöffnet werden. Am besten wäre natürlich wenn DFS-R auf Server B wieder läuft da, dass ganze sehr Zeitaufwändig ist und es auch um sehr viel Daten geht die wir nicht wirklich weniger bekommen (23TB), daher wäre es mir am liebsten wenn es wieder läuft, denn es gibt genug andere Dinge zu erledigen Kannst du mir den Befehl zum Tree connect geben ? Anbei die Ergebisse der Befehle. Befehle.txt

Hi Dukel, was passiert denn bei Storage Replica wenn Daten auf einem Volume gelöscht werden. Hierzu steht im Artikel nichts. Im Synchronen Modus, wird es sicherlich dauert wenn ich mal 3TB lösche, bis alles auf dem anderen Server repliziert ist. (Wir haben mehrere Millionen Daten). Kann Storage Replica einfach mit DFS-N kombiniert werden und ist es möglich wie bei DFS auf Freigaben beider Server auf beiden Volumen zuzugreifen, je nach aktiven Namespace Referal ? So wäre Storage Replica einfach nur eine andere Synchronisierung (ohne ewigen DFS-R Datenbamnkcheck bei einem Crash). Wichtig wäre natürlich dass man direkt mit dem aktuellen Datenstand weiterarbeiten kann Wenn Server A mal ausfällt oder gewartet werden muss.

Hi Dukel, Es soll ein erreicht werden, dass die Datenstände von Server A+B synchron sind und bei Ausfall 7Neustart durch Updates usw. von Server A das Referal auf Server B ohne Downtime umgestellt werden kann. Hast du eine Antwort wegen der merkwürdigen Anzeige in den Shares zu dem DFSRoot Ordner ?

Hallo Zusammen, ich habe ein komisches DFS-R Verhalten und freue mich wenn mich ein Profi hier aufklärt. Wir haben 2 Server A und B welche DFS-R Replikation eines Ordners O im Full Mesh machen. Der Replikationsordner O ist auf Server A und B freigegeben. DFS-N wird ebenfalls umgesetzt wobei das Referal von Server B auf Ordner O deaktiviert ist. Daher sollten die Mitarbeiter über den Namespace \\domain.local\0 immer nur auf die Freigabe von Server A kommen. Ein direkter Zugriff über die Freigabe \\Server B\O ist natürlich ebenfalls möglich, da die Freigabe nicht deaktiviert ist. (Sollte aber nicht umgesetzt werden weil dies ja zu Problemen führt) Ist es normal, dass ich auf Server B (DFS-N Referal deaktiviert) im Computermanagement auf C:\DFSRoots\O "User Sessions" Verbundene User sehe ? Ist es normal das hier teilweise Open Files mit z.B.) 2 angzeigt werden ? Unter Open Files sehe ich aber nur die Ordner C:\DFSRoot\O und andere aber keine geöffneten Dateien Auf Server B (Referal enabled) sehe ich viel mehr User auf das Verzeichnis C:\DFSRoots\O unter "Sessions" zusätzlich werden unter "Open Files" aber auch User mit geöffneten Datein mit vollständigen Pfad angezeigt. Auf Server A steht zwar unter Sessions Open Files 2 aber unter Open Files steht nur der C:\DFSRoot\O Ordner und andere aber keine geöffnete Datei, geschweige denn ein Dateipfad. Eventuell werden auf Server B auch nur die Namespace Ordnerzugriffe, trotz deaktiviertem DFS-N Referal von Server B angezeigt, was ggf normal ist. Es würde mir sehr helfen zu verstehen, wie das trotz deaktiviertem DFS-N Referal sein kann da ich ein weiteres größeres Problem habe: Ich habe eine defekte DFS-R Datenbak auf Server B welche alle paar Tage an die Wand fährt (Er sagt Laufwerk wurde getrennt und die Datenbank macht dann eine Autowiederherstellung). DFS-R wurde nie richtig geplegt und die Datenmenge ist auch viel zu groß, daher muss ich das alles neu aufteilen damit es wieder sauber läuft. Daher möchte ich die Replikation auf Server B stoppen und dort eine neue Partition anlegenen damit eine neue DFS-R Datenbank für die Entsprechenden ORdnerreplikationsgruppen angelegt wird. Danach will ich den Server B erneut unter dem neuen Pfad (Neue Partition) hinzufügen damit Server A den Inhalt mit Server B wieder repliziert. Schlecht wäre natürlich wenn es exklusiven Zugriff auf eine DFS-R Freigabe auf Server B gäbe denn das führt ja zu Konflikten da die User ja immer mit dem Referal (Namespace) arbeiten sollen, Eventuell ist das aber auch normal, da C:\DFSRoot auf beiden Server ja identisch ist. Merkwürdig ist die Anzahl der geöffneten Dateien schon. Eventuell sind die Anzahl Open Files unter Session welche auf C:\DFSRoot\ zeigen auch nur die ORdneranzahl? Das würde Sinn machen. (Es gibt natürlich mehr wie der O Ordner!) Weiß jemand auch ob es bei DFS-R Probleme mit Volumen Schatten Kopie VSC oder Backups gibt ? Ich suche ein Zusammenhang warum die Datenbank immer an die Wand fährt werde aber nicht wirklich fündig. Vielen Dank für die Hilfe Lieben Gruß Felix

Ja du hast recht Das Problem war aber auch mega komplex. Einige identische Server, wo auch die betroffene Softwarekomponennte installiert sind, waren hingegen nicht betroffen. Darum habe ich hier erstmal keinen Zusammenhang gesehen. Das ein Programm die Windowsupdatekeys ändert, ist mir bisher auch noch nie begegnet. Vielen Dank an Alle. Btw: Weißt du wie man Bilder/Anhänge hier entfernen kann? ich kann leider gar nix mehr anhängen, da die 5MB voll sind.

Vielen Dank an alle für die bisherige Hilfe und Gedult. Ich habe den Fehler mit sehr hoher Wahscheinlichkeit, dank dem Tipp mit Procmon herausfinden können. Die Überwachungssoftware Solarwinds hat die Wsuseinstellungen automatisch umgehend in der Registry geändert. Dach dem Deaktivieren der Dienste und dem bisherigen Vorgehen (loakle GPOS löschen, gpsv neu starten und Gpupdate /force) wurden die Werte richtig übernommen. Ich hätte niemals gedacht, dass das Problem an einem Fremdprodukt liegt, da die GPO ja einwandfrei angewand wurde nur von dem Produkt aber umgehend überschrieben worden. Ohne Procmon wäre da niemals dahinter gekommen. Die beiden GPOS sind nach Neuinstallation zwar immernoch da, aber solange die automatischen Updates laufen, juckt mich das nicht. Vermutlich sind die beiden Einstellungen in Windows engebrand, da nach einer Neuinstallation noch keine Software drauf ist. Ich werde nun beobachten ob die reports wirklich auch geschickt werden. Wenn es schon mal auf automatisch steht, dann wird es sicher auch funktionieren. Vielen Dank an alle für dier Tipps und die Geduld