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. ;)

Ahoi Kollegen, ich habe ein Verständnisproblem. Wir haben ein paar Windows Tablets, da liegt der Powerknopf so ungünstig, daß die Mitarbeiter im Außendienst die Geräte immer wieder aus Versehen abschalten/herunterfahren. Meine Idee war nun, Desktop Verknüpfungen zu pushen für abmelden, runterfahren und neustarten. Und den Powerknopf über die Energieverwaltung umzulegen. shutdown /s und /l (L) machen keine Probleme. Für /r kommt die Benutzerkontensteuerung hoch. Kapier ich nicht. :) LG Henry

Könnte ich keinen Schwur drauf leisten, möchte ich aber ausschließen. Hyper-V Umgebung, andere RDS Farmmember auf dem gleichen Host haben keine Probleme. Alle 10 RDS-Farmmember sind über 5 oder 6 Hostserver verteilt die wiederum auf 2 Switche verteilt sind. Nix gefunden was mich direkt drauf stößt.

Dankeschön! Hilft aber leider nicht weiter. :)

Morsche, eventuell hat ja jemand eine Idee bzw Hinweis. Umgebung: Server: 10x RDS 2008R2, NLB IP, Multicast, Broker-Cluster, Hyper-V Clients: XP/10, unterschiedliche Subnetze Wir haben alle paar Monate das Problem, daß RDP-Clients (egal welche Version, egal welches Subnetz) komplett von einem der RDS Host trennen. Nach 1-2 Minuten Wartezeit bekommen die Broker mit, das was nicht stimmt, dann kann man sich wieder auf die alte Sitzung verbinden. Ist man zu schnell beim Wiederverbinden, bekommt man neue Session, was eigentlich durch die Broker unterbunden werden sollte. Zusätzlich tritt hin und wieder das Phänomen auf, daß das WMI-Repo auf den RDS Servern defekt ist und repariert werden muss. Virenscanner (Symantec Endpoint) wurde schon ausgeschlossen. Da wir nächstes Jahr nach 2019 migrieren wollen, würde ich gern dem Problem nochmal richtig auf den Grund gehen, um gegebenfalls gemachte Fehler nicht zu wiederholen.

Sorry, ist da wohl reingerutscht. Ist das relevant? - AV: Symantec Endpoint Protection 14.1.x - GPO: (Eigentlich) Nein. Habe hier auch etwas herumexperimentiert. - Standard DL Image, alle Treiber + BIOS Aktuell, WSUS und Online Update aktuell, jeweil 1803 und 1903 Es scheint, zumindest bis jetzt, an Windows zu liegen, 1803 auf 1903 hatte zuerst keine Besserung gebracht, erst nachdem das aktuell Monatliche Rollup drauf war, gabs eine Änderung im Verhalten. Man konnte, nachdem man alle WLAN Verbindungen per Hand getrennt hatte, trotzdem Mobilfunk und VPN nutzen. Deaktiviert man das WLAN (Infocenter), werden alle RAS-Verbindungen deaktiviert/gelöscht. Aktiviert man WLAN, kommen sie wieder. "WLAN aus" ist quasi Flugmodus light. LG Henry

Kleiner Nachtrag. #1 Es ist auch nicht möglich VPN Verbindungen zu erstellen wenn WLAN deaktiviert ist oder die Verbindungen per Hand getrennt werden. #2 1903 bringt keinen Unterschied. remote access phonebook 623

Black Screens hab ich auch. Da hilft nur Affengriff, Abmelden und wieder anmelden (ohne Reboot). Sobald das Profil lokal richtig erstellt wurde, funzt es in aller Regel ohne Probleme. Single Core Probleme hab ich auch. Liegt nach meinen Erkenntnissen am Trusted Installer und Appx Installer (wie genau der Prozess heisst weiß ich grad nicht), die beide oft bei aN- wie Abmeldung laufen. Möglich das diese nicht mit Single Core klarkommen bzw deren Priorität "above normal" liegen und somit alles andere lahmlegen. Dual Core behebt das Problem, ansonsten hilft nur warten. LG Henry

Guten Morgen, ich bekomme seit ca 3 Wochen das Problem nicht in den Griff, das Windows 10 1803 die VPN Verbindung weglöscht, wenn man z.B. WLAN deaktiviert um Mobilfunk zu nutzen. Das Problem besteht seit ca 4 Wochen. Ich konnte das dafür möglicherweise in Frage kommende Windows Update nicht identfizieren. Läuft die Mobilfunkverbindung, kommt trotzdem die VPN Verbindung nicht wieder, erst wenn man WLAN wieder aktiviert. Das ist äußerst hinderlich, wenn man in gemischten Umgebungen arbeiten muss. Ein paar Kollegen hatten auch schon den Effekt beim Homeoffice im privaten WLAN. Es ging ohne Probleme bis mindestens August 2019. Eventuell hat ja jemand einen Tipp. Ich Update gerade einen Muster-Client auf 1903 zur Gegenprobe. LG Henry

Ist schon alles ersetzt, ein Protierrung macht keinen Sinn mehr. Da kann man mit der Krücke leben.

Da mein einer Kunde in einer alten VM-Umgebung noch ne alte Software zu Archivzwecken hat: September 2019 Patch https://support.microsoft.com/en-us/help/4464566/security-update-for-office-2010-september-10-2019 Ist halt so. :)