testperson

Hi, losgelöst von der eigentlichen Frage, wo und warum möchtest du partitionieren? Gruß Jan

Was für ein NAS mit was für Platten ist denn das Ziel? Die Disks im NAS sind i.O. und da läuft im Hintergrund auch kein Rebuild oder irgendein bremsender Task?

Hi, hab den Thread nur überflogen, werfe aber auch mal das Backend und kein gebundenes Zertifikat ins Rennen. Zumindest hatten das bei uns "zuletzt" eine Hand voll Kunden. Gruß Jan

Hi, wie erstellst du denn das Backup also mit welchem Befehl? Läuft das Script auf dem Hyper-V Host oder in der VM selber? D.h.: Laufwerk C: bis G: sind eine virtuelle Festplatte (VHDX) mit entsprechenden Partitionen und H: ist eine eigene Disk (VHDX)? Gruß Jan

Hi Nils, danke für die Antwort. Ich hatte halt Hoffnung, da der Artikel im Dezember 2019 aktualisiert wurde und relativ klar nur auf 2016 abzielt. :) Ein wenig Recherche ergibt, dass es zumindest 2017 noch ein Bug war: https://social.technet.microsoft.com/Forums/azure/en-US/3453b83e-c719-4bdf-a3cb-cc32c5316dfe/change-configstorerootpath-value?forum=winserverhyperv Hier findet sich auch noch ein wenig zum Thema: https://blog.workinghardinit.work/2018/09/27/live-migration-fails-due-to-non-existent-sharedstoragepath-or-configstorerootpath/ Auch wenn der Anblick jedes Mal weh tut, werden wir wohl bis zur nächsten Hardwaregeneration damit leben. Strafe muss halt sein. :) Gruß Jan

Hi, in den Anwendungen wirst du die IP-Adressen der DNS eingetragen haben. "Firma.de" nutzt die Anwendung vermutlich zur LDAP Authentifizierung. Dann sollte folgendes auf dich zutreffen: https://social.technet.microsoft.com/wiki/contents/articles/33547.load-balancers-and-active-directory.aspx I.d.R. funktioniert das auch über entsprechende Loadbalancer. Ist aber, wie im Artikel beschrieben, seitens MS nicht supported. Gruß Jan

Hi, kurze Frage, ob ich mich bl*d anstelle oder der MS Artikel (https://support.microsoft.com/en-us/help/4488568/cannot-change-configstorerootpath-of-hyper-v-cluster-after-population) ein Update benötigt. Da ich in einem Hyper-V 2019 Cluster die gleiche Fehlermeldung erhalte, gilt "This behavior is by design in Windows Server 2016." wohl auch für 2019? Oder lässt sich der Pfad unter 2019 supported und ohne Downtime des Clusters oder ohne Migration in ein neues Cluster anpassen? Gruß Jan P.S.: Wir haben kein Problem allerdings sieht es echt nicht schön aus, dass da ein CSV weiterhin den alten Namen trägt. Da haben wir bei der Einrichtung der Cluster bzw. eher von Veeam leider nicht weit genug mitgedacht. :)

Danke für die Rückmeldung. D.h. der oder die DCs stehen in unterschiedlichen Netzen und eine Firewall filtert dort? Das wäre dann so eine Info, die man sich direkt im Ausgangspost wünschen würde. Denn es ist immer die Firewall (auch wenn die Netzwerker sagen, es ist alles in Ordnung). :)

Das ist die "Info", dass das Ziel nicht erreichbar ist.

Auch bei Roaming Profiles könnte man AppData\Local inkludieren. Alternativ zu Sunnys Weg kannst du auch in einer "gpmc.msc" einen Richtlinienergebnissatz erzeugen.

Hi, wenn die Clients jetzt in der neuen Domain sind, dann melde dich mit deinem neuen (Client-) Admin-User an dem PC an und verschiebe die Daten. Ansonsten sollte es einen lokalen Admin Account geben, mit dem du die PCs in die neue Domäne bekommst. Gruß Jan

Den "Heartbeat" hatte ich doch hier implementiert: https://www.mcseboard.de/topic/219017-dauer-ping-aber-nur-wechsel-erkennen/?do=findComment&comment=1410343 ;)

Dann müsstest du jetzt einmal "händisch" nachgucken, ob die Windows Firewall im derzeitigen Profil RDP eingehend erlaubt.

Was sagt denn netstat -ano | findstr ":3389" Get-NetFirewallRule | ? Group -match "Microsoft.RemoteDesktop" | Select-Object DisplayName, Profile, Enabled, PrimaryStatus auf deinem Firmen Notebook? Kannst du dich per RDP verbinden, wenn der VPN Tunnel nicht aufgebaut ist?

Hi, kannst du per Script löschen oder auch ausschließen. Wir haben das bei uns in den Citrix UPM Ausnahmen (https://www.avanite.com/blog/roaming-edge-chromium). Gruß Jan

Hi, das solltest du evtl. mit eurer IT / deinem Vorgesetzten besprechen. Möglichkeit 1) Du bekommst weitere und benötigte Peripherie, damit du "arbeitsfähig" bist Möglichkeit 2) Sofern es gestattet ist und du damit kein Problem hast, klemmst du dein Firmen Notebook an deine private Peripherie Möglichkeit 3) Die IT segnet deinen Wunsch ab und richtet das entsprechend ein Möglichkeit 4) Die Arbeit in den nächsten Wochen wird zäher Gruß Jan

Hi, von wo nach wo kopierst du denn? Was kopierst du (viele kleine / oder größere Dateien)? Und was ist beim Kopieren alles involviert? Die Treiber sind alle aktuell? Gruß Jan

Ich winke mal (wieder) aus dem Wartungsfenster in die Runde... ... und die nächsten stehen auch schon "kurz bevor".

Bei OpenVPN gibt es doch AFAIK den Access Server, wo der User sich im Browser einloggen kann. Ist da kein Password Change machbar? Alternativ würde ich hier und/oder hier ansetzen.

Hi, das einfachste wäre vermutlich ein alternativer Datei-Explorer, den du als anderer Benutzer / als Administrator ausführen kannst. Alternativ ist natürlich nur die PowerShell / Kommandozeile das wahre Tool zur Verwaltung. ;) Gruß Jan

Hi, unterm Strich hast du in einem konkreten Fall immer den falschen Virenschutz. Derzeit würde ich beim Defender bleiben und - wie in einem anderen Thread erwähnt - in Richtung Applocker bzw. Software whitelisting schauen. Gruß Jan

Jetzt noch die Finale Rückmeldung zu den Umgebungen im "ersten Ring": Alle Server haben durchgebootet.

Im Auswahl Feld war einfach Leere. Bei der Konfiguration auf "<Kein>" wurde die Auswahl nicht gespeichert und ein Löschen der GPO ging auch nicht. Andere WMI Filter wurden in der Liste auch nicht angezeigt. Mein kleines Fix-It Script: $CurDomain = Get-ADDomain -Current LocalComputer $SOMContainer = [adsi]("LDAP://CN=SOM,CN=WMIPolicy,CN=System," + $CurDomain.DistinguishedName) foreach($WMIContainer in $SOMContainer.Children){ if([adsi]($WMIContainer.Path) | where { $_."msWMI-Name" -eq "PDC Domain Controller" }){ $WMICN = ([adsi]($WMIContainer.Path) | where { $_."msWMI-Name" -eq "PDC Domain Controller" }).CN } } $GPO = Get-GPO -Name "<Das betroffene GPO>" Get-ADObject -Identity $GPO.Path | Set-ADObject -Replace @{gPCWQLFilter=$("[" + $CurDomain.DNSRoot + ";" + $WMICN + ";0]")} Ich habe dann einfach im AD Objekt per PowerShell einen vorhandenen WMI Filter (PDC Domain Controller) ans GPO gepackt und danach erstmal den Link entfernt. Selbst ein angucken des AD Object Property "gPCWQLFilter" am GPO hat mir auf die Schnelle keine Erleuchtung gebracht.. Das GPO selber hatte auch keine Einstellungen, die nicht anderweitig schon in unseren "GPO Sets" enthalten sind. Das Erstell-Datum war auch neuer wie die GPO Sets.

Auf allen Servern die heute nicht gebootet haben, war nur ein Teil der WSUS GPO in der Registry angekommen. Jetzt die spannende Frage, wer an der Stelle genau was mit dem WMI Filter ausdrücken wollte. Und getestet / geprüft wurde das scheinbar auch nicht.. Da es scheinbar aus der Mode ist Leute mit Bambusstöcken oder Kanthölzern zu erziehen, werde ich es wohl (mal wieder) einfach hinnehmen und nach und nach korrigieren. -_- Danke nochmal für deinen Registry Auszug und Schubs in die richtige Richtung. Da war ich wohl etwas vertieft ins Problem und hab "die Basics" ignoriert ^^

Okay, sollte tatsächlich jemand zu der Zeit arbeiten, würde vorsichtshalber nicht gebooted. Die üblichen Kandidaten, die zum Feierabend "X-en" oder sich bewusst trennen, werden spätestens nach 4 Stunden entsorgt. In der ersten Umgebung habe ich jetzt jedenfalls bei einem "gpupdate" einen abhanden gekommenen WMI Filter(?) auf einer anderen Policy gefunden, der scheinbar die Verarbeitung gestört hat. Nachdem der Filter weg ist und einenm "gpupdate" habe ich auch die passenden Reboot Settings in der Registry. Ich schaue mir mal die weiteren Server an und könnte mir auch da das WMI Problem vorstellen..