
goat82
Members-
Gesamte Inhalte
322 -
Registriert seit
-
Letzter Besuch
Alle erstellten Inhalte von goat82
-
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
-
Danke du hast recht, wer lesen kann ist im Vorteil. Das hat MS hier echt saudoof gemacht und ich bin drauf reingefallen. Entschuldigung für meine Unachtsamkeit, also wir haben dann zum Glück kein Insider, hätte mich auch gewundert, da Wsus immer nur den Standard anbietet. Leider kann ich hier keine Bilder mehr Posten da die 5MB belegt sind und ich die Bilder auch nachträglich nicht löschen kann. Zum Problem: Nach Neuinstallation ist die oberste GPO weg: Automatische Updates deaktivieren. Das ist der wichtigste Punkt, denn so greiffen sicherlich auch die anderen GPOs wo sagen, dass alle 4h nach Updates gesucht werden sollen. Die beiden unteren Punkte sind leider noch da. Die Ordner GroupPolicy/User in System32 sind da aber leer. Ordner habe ich mit erhöhten Rechten gelöscht und gpvsc neu gestartet, leider ergebnislos. gpresult /r ist ebenfalls ergebnislos, da der neue Server nicht in der Domaine ist. Es kann doch nicht sein, dass ich die ganzen Registrycodes auf einem brandneuen Sytsem manuell löschen muss, das nicht mal aktiviert wurde um die beiden GPOs weg zu bekommen ? PS: Lokale Richtlinien, insbesondere das Windows-Update unter User und Benutzer stehen alle auf nicht konfiguriert PS2: Habe alle Registrykeys von Sunny gelöscht und neu gestartet. Im Status Manager steht bei Windowes Update nun 3x Status unbekannt und Windows Update geht gar nicht mehr, Fehler (0x80080005). @Sunny und alle anderen. Ich habe das System komplett neu aufgesetzt und die Registrys gelöscht und das Vorgehen 1:1 durchgeführt, ergebnislos. Was soll/kann ich denn noch machen außer den Beruf wechseln ? Und an alle Besserwisser: Die beiden GPO Einstellungen sind sofort direkt nach der Neuinstallation OHNE NETZWERK / Internetzgriff automatisch da. Also ist es ein generelles problem mit dem Image oder sehe ich das falsch ?
-
Hab nun ein neues Ticket aufgemacht wegen dem MS Insiderprogram aber bisher hat niemand geantwortet. MS hat das Insiderprogram wohl in ihrem Image wohl eingebrandet, da das Insider und die GPOs nach der Neuinstallation direkt wieder kommt. Wohlgemerkt mit dem neusten ISO Image von MS (nicht Trial) und der PC war nicht mal in der Domaine und nicht mal aktiviert! 1x Windowsupdate ausführen hat gereicht. Hat mir jemand eine Idee wo das Insiderprogram hinterlegt ist ?
-
Hallo Zusammen, wir haben einen Volumenlizenzvertrag und ich hatte in Vergangenheit Probleme mit dem MS Insiderprogramm und nicht angewendeten Windows Update GPOs. Ich habe mich nun über https://www.microsoft.com/Licensing/servicecenter/home.aspx angemeldet und die aktuellste Server 2019 Datacenter ISO (03/21) heruntergeladen und auf den ESX hochgeladen und keinerlei Info/Einstellung zum Insider Program auf der Webseite gefunden. Die neue VM wird korrekt erstellt (ohne Netzwerkverbindung). Sobald ich jedoch eine IP hinzufüge (ohne Domaine) und Windowsupdate Starte läd er brav die Updates von MS herunter, anschließend (nach einem Rebbot) zeigt er einige Einstellungen werden von Ihrer Organisation verwaltet und Sie enehmen am MS insider Program teil. Quelle: Andministrator; Typ: GPO. GPOs: Windows Update installieren und Optionen für automatische Updates festlegen. Gpresult /r : Angewandete Benutzer und Computerrichtlinien: beides Nicht zutreffend, PC ist NICHT in der Domaine! Was zu Teufel läuft hier verkehrt ? Ich vermute die Einstellungen sind in der ISO von MS gebrandet. Wie bekomme ich das sauber von Anfang an hin ?? Bitte hilft mir das Problem von Anfang an zu lösen. Weder ich noch meine Kollegen haben das Insider Programm wissentlich aktiviert. Vielen Dank PS: Windows noch nicht aktiviert, Produkt: Windows Server 2019 Datacenter Version 1809 Build:17763.1817 Product ID: 00043-00000-00000-AA571
-
Du hast ja recht Sunny, ich habe nur schon so viel Zeit verbraten und komme einfach nicht weiter. Leider sind es 7 Maschinen, daher suche ich hier noch weiter nach einer Lösung. Wohnach sollte ich in Procmon denn suchen: Nach dem lokalen GPO Pfad %Windir%\system32\grouppolicy ? Hat jemand eventuell auch einen anderen eher schlechten Lösungsansatz: Wenn ich usoclient startscan ausführe dann sucht er nur 1-2 Sekunde nach Updates und sagt dann nix gefunden, was auch ok ist. Ein Report wird an den Wsus aber nicht geschickt. Klicke ich manuell auf Updates suchen, dann sucht er deutlich länger, ca. 20-30 Sekunden Sekunden und schickt auch einen Report an Wsus , manchmal direkt nach 10 Minuten, manchmal muss ich 2-3x Suchen. Kann ich diese manuelle Suche nicht irgendwie über einen task triggern? Usoclint startscan sucht ja kurz, schickt aber keinen Report. Wie lautet der Befehl für Suche und Report ?
-
Mit Progmon sehe ich hundert Dingew und bin da nicht geschult Da müsste ich ja ein Trace laufen lassen, dass beim Neustart überprüft. Danke Weingeist, ich denke mit deiner Anleitung kann ich den Fehler herausfinden. Ich berichte gleich.... Schritt 1 reg keys löschen, lokale gpo löschen,gpsvc neu starten leider erfolglos. Keys umgehend sofort wieder da. So eine scheiße Ich glaube die ganze Anleitung brauche ich nicht durchführen, wenn ich in regedit als Admin die Schlüssel lösche, sind Sie nach F5 gleich wieder da in 10 ms! Wie kann das sein. Netzwerkverbindung ist getrennt! Auch wenn ich in der Registry Windowsupdate Auoption auf 0 und no autoupdate auf 0 stelle ändert es sich umgehend wieder auf 1 nach F5
-
Danke, für den Hinweis. Es lassen sich 2 Keys nicht löschen. Bin als Domainadmin an der Kiste angemeldet, regedit als Admin, Ordner Berechtigung geändert, Besitz übernommen als Domainadmin. Domainadmin auf Order Vollzugriff, Vererbung deaktiviert. Löschen weiterhin nicht möglich. Ich bin doch nicht b***d, irgendetwas passt da nicht. Andere Keys konnte ich mit den selben Berechtigungen (Besitz übernehmen) löschen Als lokaler Admin konnte ich ENDLICHALLE Keys löschen, leider immer noch keine Abhilfe. 3 Einstellungen sind immernoch aktiv, wenn ich Windows Update öffne. Dann habe ich nach Updates gesucht und die gelöschten Ordner in der Registry überprüft. Folgende gelöschte Einstellungen sind erneut wieder da: HKEY_CURRENT_USER\Software\Policies HKEY_LOCAL_MACHINE\SOFTWARE\Policies HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Policies HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate
-
Zu den Keys: Kann nicht gelöscht werden / Fehler beim Löschen des Schlüssels. Insbesondere Windows Update Ordner kommt nach dem Löschen und F5 direkt wieder HKEY_LOCAL_MACHINE\SOFTWARE\Policies HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Policies Kann nicht gelöscht werden / Fehler beim Löschen des Schlüssels HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\WindowsUpdate HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate Alle anderen Keys können problemlos gelöscht werden
-
Ich nutze vmware 6.7 und ms datacenter volume Lizenzen die auf auf unsere CPU angepasst ist und natürlich 2019er cals. Es ist ein Produktivsystem. Insider haben wir nie bewusst aktiviert. Es kann sein, dass dies im Image bereits enthalten war. Vorabversion oder so bekommen wir aber nie. Es muss ja eh alles über Wsus freigegeben werden. Insider kann auch nicht deaktiviert werden. Kann man das Isider beimn Imageherunterladen von MS bereits aktiviert worden sein ? Ich bin mir sicher, dass wir niemals es bewusst aktivert haben, es war aber immer aktiviert. Das 2019er Datacenter image haben wir direkt bei MS im Lizenzportal passend zu unserem Lizenzvertrag heruntergeladen, es ist eine offizielle und keine Evo Version/Image. So genau habe ich mir das Image aber nie angesehen, daher wäre es gut möglich, dass im Image das Insiderprogramm bereits aktiviert wurde? Ich dachte immer das muss man aktiv machen und muss da auch Rückmeldung usw geben und bekommt immer die neusten, ungetesteten Updates. In Wsus kommen nur die aktuellsten, keine Beta usw. Kanns ein dass ich das in Wsus aber auch explizit so eingestellt habe. Ich bin mir nicht sicher ob ich Previews usw in Wsus aktivieren kann. Generell gebe ich Updates immer erst nach einer Woche frei. In meiner Laufbahn kam es bereits zu 2 größeren Vorfällen wo MS durch ein defektes Update die Lan Verbindung usw. gekappt hat. Darum gebe ich die Updates immer erst nach einer Woche frei. Wenn es etwas kravierendes ist, dann schießt MS gleich ein Hotfix hinterher. Bei Featureupdates bin ich sogar noch vorsichtiger, hier warte ich deutlich länger und gebe erstmal in einer Test-OU frei bevor ich das Featureupdate auf alle loslasse.
-
ja, ich gebe aber nur den Standard über Wsus frei. Also nix zu neues, bin ja kein Versuchskaninchen. Ein echtes Insiderprogram ist es eigentlich nicht. Es war einfach da, ich bekomme aber keine neuen Updates, die andere ohne Insider nicht bekommen. Auch kann ich das Programm nicht verlassen und ich habe mich hierfür auch nie registriert, es wird einfach angezeigt. Kann man das irgendwie einsehen ? Ich sehe zwar das ich teilnehme, aber nicht an welchem Kanal
-
Danke Sunny, hat leider nichts geholfen. Ich werde nun erstmal versuchen Windows 2019 bei den aufwändigen Servers nach einem Snapshot drüber zu installieren ohne Neuinstallation. Wenn das nicht hilft mache ich alle 4h einen usoclient startscan task. Gpos werden einwandfrei applied, auch funktioniert die Verbindung zum Wsus einwandfrei aber wegen den 3 Gpos die nicht weg gehen eben nicht automatisch, Da Automatische Updates deaktiviert sind. Hab nun 3 Tage lang probiert, komme aber nicht weiter. Habe noch nie erlebt, dass Gpos funktionieren aber bestehende Gpos nicht weggehen, wenn man die Ziel OU mit verknüpften Gpo wechselt. Eventuell liegt es auch am aktiven Insider Program, wer weiß wobei andere Server dieses Problem nicht haben. Ein Usoclient startscan task wäre das einfachste, wobei ich nicht weiß was sonst noch so nicht funktioniert.
-
der Gpordner ist doch leer, wie soll ich da in Procmon etwas herausfinden ? Ich kann ja nix löschen was es nicht gibt. Es steht in Windows Update 3 GPOs aktiv und ich will herausfinden woher diese Info kommt oder wie ich das löschen oder verändern kann.
-
MurdocX, da hast du wahrscheinlich recht. Schade dass niemand eine Idee mit dem Ordner hat. Ich hätte gedacht dass man irgendwo nachvollziehen kann, woher die GPo einstellungen in Windows Update kommen, aber anscheinend weiß das niemand hier. Ich werde die Server so laufen lassen. Bei jedem Update muss ich halt manuell nach Updatessuchen, neustarten und für den Report erneut suchen.
-
schade, dass niemand noch eine Idee hat oder mir zumindest sagen kann warum der Ordner wo die Policys local sind bei mir nicht vorhanden ist und er dennoch Gpos anwenden tut :-(
-
gpresult /r sagt: Usereinstellungen: Default Domain Policy, Benutzereinstellungen: Default Domain Policy Inhalt Default Domain Policy im Anhang geht leider nicht, da Quota voll. Da steht 100% nix mit Wsus drinnen. Kann die Dateianhänge leider nicht entfernen, geht das irgendwie? Quota von 5MB erreicht! Wo ist hier der Bug bei meinem Problem ? Es kann doch nicht sein, dass der GPO Ordner nicht erstellt wird. Die WSUS Gpos funktionieren an sich ja fast alle, aber die 3 Wsus Gpos blockieren die Wsus Automatik, d.h. ich muss immer Updates in Wsus freigeben (normal) und bei den betroffenen Server manuell suchen und nach dem Einspielen erneut suchen, damit der Report übertragen wird. Wie können die Gpos überhaupt gehen, wenn der GPO Ordner nicht erstellt wird ?
-
Regedit Ordner gelöscht und neu gestartet,keine Änderung. Windows Update zeigt immernoch die 3 Gpos an. Gpresult /h zeigt keine angewendete Wsus GPO an (außer default domain policy aber nix was mit wsus zusammenhängt). Ordner %WinDir%\System32\GroupPolicy weiterhin nicht vorhanden. Ist es normal dass der Ordner fehlt ? Woher bekommt WindowsUpdate die Info, dass 3 Richtlinien angewendet wurden ?
-
Neuer Fehler: Server wieder verschoben, GPO angewendet (funktioniert natürlich nicht) aber der Ordner WinDir%\System32\GroupPolicy existiert nicht mehr.Wahrscheinlich ist das dass Problem. Wo ist der Pfad definiert ? Vielleicht stimmt hier etwas nicht ? Werde nun mal die Registry manuell bearbeiten und sehen ob ich damit das Windowsupdate ändern kann.
-
Hab den Server verschoben und sogar 3x neu gestartet der Ordner Grouppolicy unter %WinDir%\System32\ existiert nicht und die 3 Einstellungen werden leider weiterhin in Windowsupdate angezeigt. Irgendein Idee von dem blauen Screenshot ? MS Update habe ich eigentlich schon resettet, aber ohne Erfolg.Irgendwoher muss er sich die 3 Einstellungen ja ziehen, sonst würde es da nicht stehen. Hab mal in der lokalen GPO alles auf konfiguriert gesetzt, da wurde mir in Windowsupdate gar nichts angezeigt. Vielleicht liegt der Hund an der Registry ? Wenn ich den PC in die Wsus Ou verschiebe, dann werden die Einstelllungen ja übernommen, aber die 3 bestehenden Einstellungen überschreiben die Wsus GPOs der OU, daher vermute ich das hier der Hund begraben liegt.
-
@Sunny und MurdocX RD /S /Q %WinDir%\System32\GroupPolicy erfolgreich ausgeführt //Ordner wurde gelöscht RD /S /Q %WinDir%\System32\GroupPolicyusers // Ordner nicht gelöscht da nicht vorhanden Sfc/scannow // Keine Fehler gefunden. Gpupdate und Neustart durchgeführt, %WinDir%\System32\GroupPolicy existiert weiterhin nicht Aktueller Stand: Windows Update: weiterhin 3 GPOs konfiguriert. Außer Default domain Policy (nur Kennwortrichtninien, keine WSUS Einstellungen!) ist keine GPO am Client aktiv PS: Sorry für den Screenshot mit dem falschen Befehl