Pfuscher

Kleiner Nachtrag zum eigentlichen Problem. Wir haben viel rumgespielt u.a. mit neuem DFS Stamm und sind dann zufällig über folgenden Workaround gestolpert: Man hat zwar AD DFS Stamm/Namespace, aber die (aktiven/aktivierten) Namespace Server dürfen keine DCs mit 2022/2019 sein. File Server mit 2016/2019 dagegen schon...

Danke für den Hinweis, der Support sagt, die Software wird nicht mehr unterstützt oder angeboten. Wurde entsprechend entfernt.

Moin! Dankeschön, hatte ich gestern auch festgestellt, aber gut als Bestätigung. Hat mich kurz dezent verunsichert. Ahoi, habe ich kein Problem mit. Ich kaufe sogar IrfanView und TotalCMD. Leider funzt die Registrierung nicht, läuft ins leere. Hätte ja klappen können.

Hab dann doch was irritierendes gefunden. Ich bin mir SEHR sicher, daß die Migration erfolgreich war, hatte ich über ne Woche ganz in Ruhe verteilt. In der DFS-Verwaltung in der Replikation ist "Domain System Volume" gelistet. Laut Handbuch sollte es [drive:\]Windows_folder\SYSVOL_DFSR als Folder sein, aber es ist [drive:\]Windows_folder\SYSVOL. Und ich würde schwören, daß das alles korrekt war. For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state Bringt als State "4".

Kurz Herzkasper bekommen, aber ja, hatte ich letztes Jahr irgendwann gemacht.

Ahoi Kolleginnen und Kollegen, ich steht im Moment auf dem Schlauch. Wir haben über die letzten 4 Wochen 3x DCs von 2008R2 auf 2x 2022 (Blech) und 2x 2019 (Hyper-V VMs) migriert. Leider etwas zu spät, als wir gerade anfingen vom letzten 2008R2 (PDC/FSMO) die Rollen auf 2022 zu schwenken, ist aufgefallen, daß einige Clients keine Software mehr installiert haben. Wir nahmen an, liegt am Schluckauf durch die Migration und nix drauf gegeben. Nun ist es aber so, das die simple Softwareverteilung per GPO nicht mehr funzt. DFS (AD integriert) haben wir auf Verdacht von 2000-Modus auf 2008-Modus geändert (import/export). Auch die Berechtigungen der Shares für die Softwareinstallation kontrolliert. Testweise alternative Quellordner mit "Jeder" Rechten anstellen "Authentifizierte Benutzer" und "Domänencomputer" konfiguriert. Grundsätzlich haben sich die Shares, die Server die diese hosten und die Rechte nicht geändert vor/während der Migration. Der Forest und Domain Level ist weiterhin 2008R2. Haben wir jetzt zur Sicherheit noch nciht angefasst. Primäre Eventlog Fehler sind abwechselnd GroupPolicy (Microsoft-Windows-GroupPolicy) - ID 1085 - Die Installationsquelle für dieses Produkt ist nicht verfügbar. Stellen Sie sicher, dass die Quelle vorhanden ist und Sie Zugriff darauf haben. - {c6dc5466-785a-11d2-84d0-00c04fb169f7} und GroupPolicy (Microsoft-Windows-GroupPolicy) - ID 1112 - Die Gruppenrichtlinienumgebung sollte die Erweiterung in der synchronen Vordergrundrichtlinienaktualisierung aufrufen. - {c6dc5466-785a-11d2-84d0-00c04fb169f7} Ich seh vor lauter Bäumen den Wald nicht. Ich vermute auch, daß wir einfach irgendwas simples bei der DC-Migration übersehen oder überlesen haben. Ninja-Edit: Das DFS per se funktioniert! Also Benutzerlaufwerke, Projekt und Datenlaufwerke, DFS-Backup-Halden funktionieren einwandfrei nach aktueller Erkenntnis. Es ist quasi nur die Softwareverteilung beim Computerstart betroffen. Benutzerbasierte Verteilung wird nicht genutzt.

Jupp. In dem Moment wußte ich auch wieder, warum ich über 10 Jahre lang den MS Support nicht mehr angerufen habe. War beim letzten Mal auch so bei einem DB Fehler Exchange 2007 oder 2010. Wo sich später rausstellte, ist nen MS Bug. Ich warte jetzt wieder 10 Jahre. Oder länger. Eventuell wenn ich in Rente gehe, mache ich mir nochmal Spaß draus.

Ahoi, wir möchten nachträglich für alle Nutzer (einer Gruppe z.B.) das Theme ändern, also mit angepassten Themes arbeiten. Z.B. für Leute mit Sehschwäche etc und mit "Corporate Design". Hab schon bissl rum gegooglet und auch mal Microsoft angerufen. Die Theme-GPO ist nur für neue Profile. Microsoft empfiehlt die komplette Domäne neu aufzusetzen mit angepassten Images, jedes mal, wenn das Theme sich ändert bzw angepasst wird. Also so richtig mit DCs und Exchange und so. Wegen einheitlich und so. Super Tipp! Gibt's eine andere Möglichkeit? Also was sinnvolles via Batch/Powershell?

Okay, ist eventuell etwas peinlich, aber Fehler gefunden. In den Logs sind "komische" Kerberos Einträge aufgetaucht. Nach diversen Glaskugeln ist aufgefallen, das ein Teil der Server IPs (via DHCP) hat, die diese nicht haben dürften. Der andere Teil der Server hatte nämlich ebenfalls diese IPs. Korrekter weise... Kurzum, wir haben mehrere neue Hostserver für Hyper-V gekauft und mit 2019 installiert (kein Cloning etc). Genau 2 dieser Hostserver, einer für einen Teil der RDS 2019 Farm, und der Andere für einen Teil der Server/Anwendungen hatten genau den gleichen MAC-Bereich... Den Rest kann man sich dann denken. Alle anderen neuen 2019er (1809/1909) Hostserver hatten wie gewohnt unterschiedliche MAC-Bereiche. Eine Doppelung hatte ich noch nie. Internet sagt: Each Hyper-V server has a MAC address range that it uses for generating new dynamic MAC addresses. You can also configure this range yourself if you want to. Each Hyper-V host generates a default pool. They all use the same first three octets: (00-15-5D), as Microsoft owns that prefix. The next 2 octets (14-22) are generated by the last two octets of the IP address that was first set up on the Hyper-V server. The last octet (FF) is generated from the range 0x0 – 0xFF. Also müssen diese beiden Server bei der Installation zufällig die gleiche IP gehabt haben. Wieder was gelernt.

Ahoi, ich bekomme bei fast allen 2019er Server folgende Meldung wenn ich RDP dort hin mache. Das Problem ist zuerst bei einigen RDS-Servern aufgepoppt. Aber eben nicht bei allen. Nun habe ich mehrere VMs neu aufgesetzt, die haben das gleiche Problem. Ich hatte den 2020-12er Patchday zwar getestet, aber das ist mir nicht aufgefallen. Die Verbindung kann nicht hergestellt werden, da es sich bei dem erreichten Remotecomputer nicht um den angegebenen Computer handelt. Dies kann durch einen veralteten Eintrag im DNS-Cache verursacht werden. Verwenden Sie statt des Namens die IP-Adresse des Computers. Deaktivere ich die Option "Verbindungen nur von Computern zulassen, auf denen RD mit Authentifizierung auf Netzwerkebene ausgeführt wird.", kann ich mich zumindest erstmal wieder verbinden. Ist man dann eventuell drin, "flackert" die RDP. Manchmal kann man das "Windows sperren..." Bild sehen, kurz danach ist man wieder drin. Scheint irgendwo mit dem Kerberos zusammen zu hängen. Das Problem tritt nur von/nach 2019 (v1809) auf. Alle anderen Konstellationen sind ohne Fehler, bist jetzt... Und es sind auch nicht alle Server betroffen. Alle Installationen sind identisch und holen Updates via WSUS. Steh aufm Schlauch.

Kleiner Hinweis. Bei mir funktionierte das erstellen der Romaing-Datei erst nachdem ich die automatische Browseranmeldung aktiviert hab. Ich nutze Folder Redirection. ChromiumEdge legt dann die Datei profile.pb bei mir in "${roaming_app_data}\Microsoft\Edge\User Data" ab. Leider werden aber keine Kennworter mit synchronisiert. Habs noch nciht rasubekommen wie das funktioniert. Im Chrome muss man übrigens nicht die Anledung automatisieren, der legt die Datei auch so an.

GPO für WU. Ich schaue gerade in diversen Kombinationen, was das Problem auftritt.

Windows 10 Pro. Primär 1809 (paar hängen auf 1803 fest), teilweise 1909. ADMX-Templates müsste ich kontrollieren. Mindestens 1809, werde 1909 direkt (noch mal) mal laden. Okay ich schaue nochmal wegen dem Reboot Zeitraum. GPO ist für Updates auf 2 Tage und für Feature auf 7 Tage gestellt. Eventuell gibts da ne Kollision. Werde mich mal checken falls ich das reproduzieren kann.

Aloha, meine Clients werden per GPO und WSUS versorgt. Nun bekommen einige Clients nach überschreiten der Neustartfrist z.B. die Meldung "Sie erhalten ein Update - Ihre Organistation startet ihr Gerät um 15:18 neu,..." Ist auch so oaky, nur das die Arbeitszeiten (08-17Uhr) nicht eingehalten werden. Drückt man OK, kommt kurz danach das Fenster mit der Meldung erneut, nur mit um zumeist 3-4h verkürzte Zeit, also 11:53 in diesem Beispiel. Ist mir nicht ganz schlüssig, was das soll. Hab die WSUS GPO schon durchgeschaut, und kann nix erkennen was falsch läuft. LG Henry

Ja ist richtig, aber nicht das Problem. ;)