Migration DCs 2008R2 -> 2019/2022 kein GPO Softwareinstallation per DFS-Shares möglich

[Pfuscher 12]

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.

bearbeitet 8. Mai 2023 von Pfuscher

[zahni 521]

Hast Du vor der Migration FRS zu DFS-R migriert:

https://learn.microsoft.com/de-de/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr

bearbeitet 8. Mai 2023 von zahni

[Pfuscher 12]

vor 6 Minuten schrieb zahni:

Hast Du vor der Migration FRS zu DFS-R migriert:

https://learn.microsoft.com/de-de/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr

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

 

Zitat

C:\Windows\system32>dfsrmig /GetGlobalState

Aktueller globaler DFSR-Status: "Entfernt"
Erfolgreich

C:\Windows\system32>dfsrmig /GetMigrationState

Alle Domänencontroller wurden erfolgreich zum globalen Status (""Entfernt"") migriert.
Die Migration hat auf allen Domänencontrollern einen konsistenten Status erreicht.
Erfolgreich
 

 

[NorbertFe 1.799]

Unabhängig vom aktuellen Problem, solltest du keine software per gpo verteilen. 

[Pfuscher 12]

vor 21 Minuten schrieb zahni:

Hast Du vor der Migration FRS zu DFS-R migriert:

https://learn.microsoft.com/de-de/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr

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".

[zahni 521]

vor einer Stunde schrieb Pfuscher:

 

 

Laut Handbuch sollte es [drive:\]Windows_folder\SYSVOL_DFSR als Folder sein, aber es ist [drive:\]Windows_folder\SYSVOL.

 

 

Das ist nur auf migrierten DC's so. Werden sie mit DFS-R neu installiert, ist der Ordner wieder Sysvol. Eigentlich logisch. Bei der Migration kann es den gleichen Ordner nicht 2x geben.

Die Frage ist, wo die GPO ihre MSI-Pakete herholt. Schaue dir mal die GPO-Daten mal nativ in einem Text-Viewer an.

bearbeitet 8. Mai 2023 von zahni

[daabm 1.184]

Gibt von SDM-Software auch einen Viewer für die AAS-Dateien, die bei den entsprechenden GPOs im Sysvol liegen: https://sdmsoftware.com/library/group-policy-software-installation-viewer-utility/

Ja, man muss sich registrieren - aber Darren (der CEO von SDM) - gehört zu den guten, war selbst jahrzehntelang MVP.

[Pfuscher 12]

vor 18 Stunden schrieb zahni:

Das ist nur auf migrierten DC's so. Werden sie mit DFS-R neu installiert, ist der Ordner wieder Sysvol. Eigentlich logisch. Bei der Migration kann es den gleichen Ordner nicht 2x geben.

Die Frage ist, wo die GPO ihre MSI-Pakete herholt. Schaue dir mal die GPO-Daten mal nativ in einem Text-Viewer an.

Moin! Dankeschön, hatte ich gestern auch festgestellt, aber gut als Bestätigung. Hat mich kurz dezent verunsichert.

vor 17 Stunden schrieb daabm:

Gibt von SDM-Software auch einen Viewer für die AAS-Dateien, die bei den entsprechenden GPOs im Sysvol liegen: https://sdmsoftware.com/library/group-policy-software-installation-viewer-utility/

Ja, man muss sich registrieren - aber Darren (der CEO von SDM) - gehört zu den guten, war selbst jahrzehntelang MVP.

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.

[daabm 1.184]

Kannst Darren ja mal direkt anschreiben - bestimmt ein Versehen

 

[cj_berlin 1.133]

Oder ich stupse ihn intern an 😎

Darren sagt, schreib support@sdmsoftware.com an.

[Pfuscher 12]

Am 9.5.2023 um 23:36 schrieb cj_berlin:

Oder ich stupse ihn intern an 😎

Darren sagt, schreib support@sdmsoftware.com an.

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

Am 8.5.2023 um 17:44 schrieb daabm:

Gibt von SDM-Software auch einen Viewer für die AAS-Dateien, die bei den entsprechenden GPOs im Sysvol liegen: https://sdmsoftware.com/library/group-policy-software-installation-viewer-utility/

Ja, man muss sich registrieren - aber Darren (der CEO von SDM) - gehört zu den guten, war selbst jahrzehntelang MVP.

 

Wurde entsprechend entfernt.

[Pfuscher 12]

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

 

 

bearbeitet 12. Mai 2023 von Pfuscher