none
Gruppenrichtlinie für das festlegen der Authentifizierungsmethode für Remotedesktopgateway funktioniert nicht

    Frage

  • Hallo,

    ich versuche krampfhaft eine neue Gruppenrichtlinie für das festlegen der Authentifizierungsmethode für Remotedesktopgateways zu konfigurieren. Wie diese prinzipiell aussehen muss weiß ich aber sie wirkt nicht auf dem Client.

    Folgendes habe ich getan:

    1. Neue Richtlinie erstellt
    2. Richtlinie konfiguriert
            - Windows-Komponenten/Remotedesktopdienste/Remotedesktopgateway --> aktiviert
            - Benutzer können diese Einstellung ändern --> deaktiviert
            - Authentifizierungsmethode... --> Lokale Anmeldeinformation verwenden
    3. Richtlinie wirkt auf eine Gruppe in der sich alle Benutzer welche die Einstellung bekommen sollen sind

    Das Ergebnis ist das sie auf dem Client nicht ankommt. Konfiguriere ich jedoch den 2ten Punkt in die "Default Domain Policy" wird sie auf dem Client angewendet. Kann mir jemand den unterschied erklären bzw. mir sagen was ich hier falsch mache?


    Vielen Dank schon mal

    Donnerstag, 22. Dezember 2011 11:38

Antworten

  • Am 22.12.2011 12:38, schrieb 3nergizer:

    Richtlinie wirkt auf eine Gruppe

    Nein. Niemals. Du kannst sie höchstens für eine Gruppe filtern, aber
    nienals wird eine Gruppe die Richtlinie übernehmen, sondern immer nur
    der COmputer oder der Benutzer.

    Dein Zielobjekt ist nicht im Verwaltungsbereich der Richtlinie, deswegen
    klappt es in der DefDomPol un dnicht in deiner eigenen.

    In der OU, an der die GPO verlinkt ist, ist kein Benutzer oder Computer

    http://www.gruppenrichtlinien.de/HowTo/Erste_Schritte_zum_erstellen_einer_Gruppenrichtlinie.htm

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Donnerstag, 22. Dezember 2011 12:48
  • Hallo,

    wenn du einmal Zeit hast, lies dir doch das hier mal durch:

    http://www.msxfaq.de/verschiedenes/gpo.htm

    Der Name Gruppenrichtlinie ist für Anfänger oft etwas irreführend.

    Im Normalfall musst du die Richtlinien immer entsprechend ihrer Einstellungen verknüpfen.
    (es gibt Außnahmen, aber das lassen wir jetzt mal weg)

    Enthält eine Richtlinie ausschließlich Benutzereinstellungen => mit OU in der User vorhanden sind verknüpfen
    Enthält eine Richtlinie ausschließlich Computereinstellungen => mit OU in der Computer vorhanden sind verknüpfen

    Da die Default Domain Policy "ganz oben" hängt, wirk sie natürlich auf deine Benutzerkonten.


    MVP - Group Policy http://matthiaswolf.blogspot.com/

    Donnerstag, 22. Dezember 2011 15:03
    Beantworter
  • So jetzt habe ich endgültig meine Lösung gefunden. Der Kollege welcher vor mir das AD administriert hatte, hat die Richtlinie auf einen Standort wirken lassen. Das dies der Fall ist war jedoch in der Gruppenrichtlinie nirgendwo ersichtlich! Ich hätte gedacht das es bei dieser Konfiguration unter Bereich,Verknüpfung hätte drin stehen müssen. Dies war aber leider nicht der Fall. Des weiteren üssen die Standorte erst explizit angezeigt werden, sonst erscheinen auch die nicht in der Navigation. Lange Rede... ich habe für diese Woche gelernt das ich GPO´s an Oorganisationseinheiten und an Standorte verknüpfen kann.

    Noch mals vielen Dank für eure Unterstützung... Frohes Fest...

    • Als Antwort markiert 3nergizer Freitag, 23. Dezember 2011 09:13
    Freitag, 23. Dezember 2011 09:13

Alle Antworten

  • Am 22.12.2011 12:38, schrieb 3nergizer:

    Richtlinie wirkt auf eine Gruppe

    Nein. Niemals. Du kannst sie höchstens für eine Gruppe filtern, aber
    nienals wird eine Gruppe die Richtlinie übernehmen, sondern immer nur
    der COmputer oder der Benutzer.

    Dein Zielobjekt ist nicht im Verwaltungsbereich der Richtlinie, deswegen
    klappt es in der DefDomPol un dnicht in deiner eigenen.

    In der OU, an der die GPO verlinkt ist, ist kein Benutzer oder Computer

    http://www.gruppenrichtlinien.de/HowTo/Erste_Schritte_zum_erstellen_einer_Gruppenrichtlinie.htm

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Donnerstag, 22. Dezember 2011 12:48
  • Vielen Dank Mark.

    Okay also MUSS ich unbedingt diese Richtlinie einer OU zuweisen? (Ich hoffte es einfach nur allen Benutzern der Gruppe überhelfen zu können)

    Beim testen ist mir grad noch aufgefallen das ich die Richtlinie wenn ich sie direkt auf Ebene der "Default Domain Policy" verknüpfe sie auch wirkt. Wenn ich sie aber auf eine OU in der sich alle Clientcomputer-Konten befinden verknüpfe wirkt sie wieder nicht.

    Wo habe ich hier den Denkfehler?

    Donnerstag, 22. Dezember 2011 13:13
  • Ich glaub ich habs verstanden. Ich muss die Richtlinie auf den Ordner verknüpfen in dem sich alle Benutzer befinden... manchmal sieht man den Wald vor lauter Bäumen nicht...
    Donnerstag, 22. Dezember 2011 13:23
  • Hallo,

    wenn du einmal Zeit hast, lies dir doch das hier mal durch:

    http://www.msxfaq.de/verschiedenes/gpo.htm

    Der Name Gruppenrichtlinie ist für Anfänger oft etwas irreführend.

    Im Normalfall musst du die Richtlinien immer entsprechend ihrer Einstellungen verknüpfen.
    (es gibt Außnahmen, aber das lassen wir jetzt mal weg)

    Enthält eine Richtlinie ausschließlich Benutzereinstellungen => mit OU in der User vorhanden sind verknüpfen
    Enthält eine Richtlinie ausschließlich Computereinstellungen => mit OU in der Computer vorhanden sind verknüpfen

    Da die Default Domain Policy "ganz oben" hängt, wirk sie natürlich auf deine Benutzerkonten.


    MVP - Group Policy http://matthiaswolf.blogspot.com/

    Donnerstag, 22. Dezember 2011 15:03
    Beantworter
  • Danke ich glaube soweit habe ich das Verständnis jetzt auch aufgebaut.

    Irritiert hat mich das ganze durch eine GPO in unserem AD die von einem ehemaligem Admin gesetzt wurde. In dieser wird ein Skript ausgeführt welches die lokalen Intranetsites um einige Einträge ergänzt. Auch bei dieser Richtlinie war lediglich ein Eintrag in der Sicherheitsfilterung (eine Gruppe mit den Zielbenutzern) zu finden. Ansonsten unterschied sich die GPO lediglich in den Einstellungen welche gesetzt wurden. Ich vermute aber mal das ich hier eine Sonderlocke habe die mich womöglich mehr irritiert als sie mir hilft. Mit den Tips von euch habe ich auf jeden Fall erst mal meine Einstellung mit dem Remotedesktopgateways auf die Clients gebracht....

     

    Vielen Dank

    Donnerstag, 22. Dezember 2011 15:26
  • >Auch bei dieser Richtlinie war lediglich ein Eintrag in der Sicherheitsfilterung (eine Gruppe mit den Zielbenutzern) zu finden

    Das ist auch der eigentliche Zweck warum sich hier User bzw. Gruppen eintragen lassen.

    So kannst du wie der Name schon sagt, filtern.

    Nehmen wir an du hast eine OU in der Meier, Müller, Schmitt vorhanden ist.
    Wenn du nicht filterst, würde die Richtlinie für alle drei User gelten.

    Verweigerst du jedoch Müller und Schmitt das Recht die Richtlinie zu übernehmen, so gilt die Richtlinie nur für Meier.

    Aber das nur am Rande.


    MVP - Group Policy http://matthiaswolf.blogspot.com/
    Donnerstag, 22. Dezember 2011 21:03
    Beantworter
  • So jetzt habe ich endgültig meine Lösung gefunden. Der Kollege welcher vor mir das AD administriert hatte, hat die Richtlinie auf einen Standort wirken lassen. Das dies der Fall ist war jedoch in der Gruppenrichtlinie nirgendwo ersichtlich! Ich hätte gedacht das es bei dieser Konfiguration unter Bereich,Verknüpfung hätte drin stehen müssen. Dies war aber leider nicht der Fall. Des weiteren üssen die Standorte erst explizit angezeigt werden, sonst erscheinen auch die nicht in der Navigation. Lange Rede... ich habe für diese Woche gelernt das ich GPO´s an Oorganisationseinheiten und an Standorte verknüpfen kann.

    Noch mals vielen Dank für eure Unterstützung... Frohes Fest...

    • Als Antwort markiert 3nergizer Freitag, 23. Dezember 2011 09:13
    Freitag, 23. Dezember 2011 09:13
  • Am 23.12.2011 schrieb 3nergizer:
    Hi,

    nirgendwo ersichtlich! Ich hätte gedacht das es bei dieser Konfiguration unter Bereich,Verknüpfung hätte drin stehen müssen. Dies war aber leider nicht der Fall. Des weiteren üssen die Standorte erst explizit angezeigt werden, sonst erscheinen auch die nicht in der Navigation.

    Korrekt. Einer von diversen Gründen, warum man Site-GPOs nur einsetzen
    sollte, wenn man weiß, was man tut. ;)

    Bye
    Norbert

    PS: Du hast gelernt, dass man sie an Standorte verknüpfen kann, aber nicht
    sollte. ;)


    Dilbert's words of wisdom #34:
    When you don't know what to do, walk fast and look worried.

    Freitag, 23. Dezember 2011 14:03
    Moderator
  • Am 23.12.2011 schrieb 3nergizer:

    Lange Rede... ich habe für diese Woche gelernt das ich GPO´s an Oorganisationseinheiten und an Standorte verknüpfen kann.

    An Standorten verknüpft man sie einfach nicht. Nein, es gibt keinen
    Grund. Ich hatte auch schon sehr lange Zeit mit suchen verbracht.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Freitag, 23. Dezember 2011 18:10
  • Am 23.12.2011 schrieb Winfried Sonntag [MVP]:
    Hi,

    An Standorten verknüpft man sie einfach nicht. Nein, es gibt keinen
    Grund. Ich hatte auch schon sehr lange Zeit mit suchen verbracht.

    Es gibt keinen Grund Site-GPOs zu benutzen, oder es gibt keinen Grund sie
    nicht zu verknüpfen? ;)

    Bye
    Norbert


    Dilbert's words of wisdom #32:
    If it wasn't for the last minute, nothing would get done.

    Freitag, 23. Dezember 2011 20:35
    Moderator
  • Am 23.12.2011 schrieb Norbert Fehlauer [MVP]:

    Am 23.12.2011 schrieb Winfried Sonntag [MVP]:

    An Standorten verknüpft man sie einfach nicht. Nein, es gibt keinen
    Grund. Ich hatte auch schon sehr lange Zeit mit suchen verbracht.

    Es gibt keinen Grund Site-GPOs zu benutzen, oder es gibt keinen Grund sie
    nicht zu verknüpfen? ;)

    Es gibt keinen Grund sie zu benutzen. ;)

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Sonntag, 25. Dezember 2011 23:34
  • >Es gibt keinen Grund Site-GPOs zu benutzen

    Naja gut, das kommt darauf an ;)

    Es gibt immer wieder User die zwischen den verschiedenen Standorten wechseln,
    jedoch im AD natürlich immer der gleichen OU zugeordnet sind.
    (z.B. weil die Admins nicht einmal wissen dass der User gerade in den USA ist und nicht in Deutschland).

    In solchen Fällen macht es Sinn, wichtige standortspezifische Settings in eine Site-GPO zu packen.

    Diese greift aufgrund des Subnetzes, auch ohne manuelle Eingriffe.

     


    MVP - Group Policy http://matthiaswolf.blogspot.com/
    Montag, 26. Dezember 2011 12:19
    Beantworter
  • Am 26.12.2011 schrieb Matthias Wolf [MVP]:

    Es gibt keinen Grund Site-GPOs zu benutzen

    Naja gut, das kommt darauf an ;)

    Es gibt immer wieder User die zwischen den verschiedenen Standorten wechseln, jedoch im AD natürlich immer der gleichen OU zugeordnet sind. (z.B. weil die Admins nicht einmal wissen dass der User gerade in den USA ist und nicht in Deutschland).

    In solchen Fällen macht es Sinn, wichtige standortspezifische Settings in eine Site-GPO zu packen.

    Diese greift aufgrund des Subnetzes, auch ohne manuelle Eingriffe.

    Da würde ich lieber auf einen WMI-Filter setzen.
    http://www.tech-archive.net/Archive/Windows/microsoft.public.windows.group_policy/2007-01/msg00288.html
    select * from Win32_IP4RouteTable where Name like "192.168.22.%"

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Montag, 26. Dezember 2011 12:39
  • WMI Filter verwende ich nur, wenn es wirklich nicht anders geht.

    WMI Filter sind nicht gerade performant.

    └───domain.intern pos 1
        ├───germany    pos 2 
        │   ├───com
        │   └───usr
        └───usa
            ├───com
            └───usr

    Was erschwerend dazu kommt, in dem Beispiel mit WMI Filter musst du die Policies "überhalb" der OU Struktur verlinken.
    In diesem Beispiel pos 1.

    Beispiel:

    ├───domain.intern
       --- policy-10.20.2.0
       --- policy-10.20.1.0
        ├───germany
        │   ├───com
        │   └───usr
        └───usa
            ├───com
            └───usr

    Dies ist aber normalerweise nicht der Fall. Verlinkt wird z.B. an pos 2.
    Wenn der Rechner nun plötzlich sich in den USA ans Netz steckt, nützt auch der WMI Filter nichts.
    Da dieser trotzdem noch in der OU germany / com zugeordnet ist.

    Zusätzlich muss der WMI Filter immer nur das Interface betrachten, dass auch wirklich mit dem Netzwerk der Domäne verlinkt ist.

     


    MVP - Group Policy http://matthiaswolf.blogspot.com/


    Montag, 26. Dezember 2011 14:26
    Beantworter
  • Am 26.12.2011 schrieb Matthias Wolf [MVP]:

    WMI Filter verwende ich nur, wenn es wirklich nicht anders geht.

    Ich schon auch. Das von mir gepostete Beispiel war produktiv im
    Einsatz und hatte durchaus seine Berechtigung.

    WMI Filter sind nicht gerade performant.

    Stimmt, auch das weiß man und beachtet es. Trotzdem sind mir WMI
    Filter lieber als Standort GPOs.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Montag, 26. Dezember 2011 15:07
  • Am 26.12.2011 15:26, schrieb Matthias Wolf [MVP]:

    WMI Filter sind nicht gerade performant.

    Können wir bitte mit diesem Unsinn aufhören und dieses 10 Jahre alte
    Statement zu Grabe tragen? Wir reden nicht mehr von P3-500MHz, sondern
    von seit 6 Jahren von "irgendwas" Core und jetzt i"zahl"

    Powershell:
    measure-command {Get-WmiObject -query "select * from Win32_IP4RouteTable
    where Name like '192.168.22.%'"}

    irgendwo zwischen 30 und 120 Millisekunden

    Selbst mit 20 Queries in dieser Art reden wir von 2 Sekunden.
    Die Frage ist: Was die Querie abfragt. Das ist das gleiche Problem mit
    den Richtlinien. Richtlinien sind nicht langsam, aber evtl. die Aktion
    die damit ausgelöst wird.

    Standortrichtlinien haben das Problem, das sie im System aktiv sind, bis
    ich an einen anderen Standort komme, was bei Offline Clients (Notebooks
    im Hotel) zu sehr unangenehmen Seiteneffekten führen kann.
    Ich verteufel sie nicht generell, aber ich nutze sie nie.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Montag, 26. Dezember 2011 22:06
  • >Können wir bitte mit diesem Unsinn aufhören und dieses 10 Jahre alte
    >Statement zu Grabe tragen?

    Ähm, ne.

    Mach doch einfach mal diesen Klassiker:

    measure-command {Get-WmiObject -query "Select * from Win32_Product where Name like '%Adobe Reader%'"}

    Derartiges habe ich schon oft gesehen.
    Measure machen natürlich nur die Wenigsten vorm erstellen des WMI Filters.
    Bei meinem nicht gerade leistungsschwachen Notebook dauert dieser Mist 66 Sekunden.

    >Wir reden nicht mehr von P3-500MHz

    Leider, Leider ist oft in den Produktionsumgebungen die Zeit stehen geblieben.
    Dort stehen (zumindest bei uns) noch Rechner, denen ich definitiv derartiges nicht zumute möchte.

    >irgendwo zwischen 30 und 120 Millisekunden
    Ja in diesem Falle ist das natürlich nicht viel.

    Bei 40-50 Standorten und sagen wir jeweils 5 Policies sind wir dann schon bei 50 x 40ms x 5 = 10000 ms = 10s.

    Ansichtssache.

    >Standortrichtlinien haben das Problem, das sie im System aktiv sind, bis
    >ich an einen anderen Standort komme, was bei Offline Clients (Notebooks
    >im Hotel) zu sehr unangenehmen Seiteneffekten führen kann 

    Aber das Problem hast du doch mit jeder Policy, so lange der Client offline ist.

    Wenn du für deine VPN-Clients (und deren Subnet) eine eigene AD-Site definierst, so kannst du das Problem
    zumindest etwas eindämmen.

     


    MVP - Group Policy http://matthiaswolf.blogspot.com/




    Montag, 26. Dezember 2011 22:24
    Beantworter
  • Am 26.12.2011 23:24, schrieb Matthias Wolf [MVP]:

    measure-command {Get-WmiObject -query "Select * from Win32_Product where Name like '%Adobe Reader%'"}

    gähn kopier doch einfach mal bei jeder Anmeldung 50MB im Anmeldescript
    ... das macht auch keinen Sinn.

    Das Argument "es kann langsamer sein, weil ..." ist völlig sinnlos, weil
    das für jede Struktur und jeden Befehl gilt, der schlecht gemacht ist.

    WMI ist kein Performancekiller, wenn er genau wie der Rest der
    Richtlinien richtig eingesetzt wird. Ich kann es nicht mehr hören, daß
    WMI das System ausbremst, das tut es nicht.
    Warum verteufelt keiner robocopy im AnmeldeScript?

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Montag, 26. Dezember 2011 22:46
  • Wenn man weiß was man tut, kann man auch mit 250 unangeschnallt mit Handy am Ohr barfuß durch den Nebel fahren...

    Aber leider ist das oft nicht der Fall.

    Vielleicht sind wir einfach wieder beim Punkt "Pauschalaussagen".

    Was wiederum ich nicht mehr hören kann...

    >Warum verteufelt keiner robocopy im AnmeldeScript?

    Weil ich da oft keine Alternative sehe.
    Was muss, das muss.

    (ich weiß, es gibt BITS, Softwaredistribution etc.)

    Um nochmal das Beispiel Adobe Reader zu nehmen,
    wenn möglich bin ich hier per ILT um ein x-faches schneller.

    Kommt natürlich auf die Policy an.

    >Ich kann es nicht mehr hören

    Da ham wir aber wieder einen wunden Punkt getroffen ;)


    MVP - Group Policy http://matthiaswolf.blogspot.com/

    Dienstag, 27. Dezember 2011 10:03
    Beantworter
  • Am 27.12.2011 11:03, schrieb Matthias Wolf [MVP]

    Warum verteufelt keiner robocopy im AnmeldeScript?

    Weil ich da oft keine Alternative sehe.
    Was muss, das muss.

    Siehste. Darum gehts. Wenn es "muss" dann machst du es und nimmst auch
    10 Sekunden lächelnd in Kauf.

    Deswegen setze ich WMI ein, denn bis sich der WMI auf mehr als 5
    Sekunden aufaddiert hat, muss ich mich schon richtig dolle anstrengen
    und in so einem Netzwerk träumen die Leute meistens von Anmeldezeiten
    unter 2 Minuten, da falle ich dann mit 5 Sekunden garnicht mehr auf.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Dienstag, 27. Dezember 2011 10:51
  • >und in so einem Netzwerk träumen die Leute meistens von Anmeldezeiten
    >unter 2 Minuten

    Gut wäre man böse könnte man auch sagen, ist doch egal ob der Rechner jetzt schon 13 oder 15 Minuten fertig ist
    bevor die Mitarbeiter mit ihrer Tasse Kaffee wieder in den Raum kommen :)


    MVP - Group Policy http://matthiaswolf.blogspot.com/
    Dienstag, 27. Dezember 2011 11:31
    Beantworter
  • Am 26.12.2011 23:24, schrieb Matthias Wolf [MVP]:

    50 x 40ms x 5 = 10000 ms = 10s.

    jetzt mal mit echten Zahlen. Ich habe mir mal Arbeit gemacht.

    Eine OU, daran 200 GPOs (wmi-test-xxx), 200 WMI Filter (zz-wmi-test-xxx)
    darin als Anfrage: select * from Win32_IP4RouteTable
    where Name like '192.168.xxx.%'.
    "xxx" in allen 3 Stellen durchgezählt von 1 - 200.

    Test in einer VM auf einem DC, Anmeldung über RDP als Benutzer.
    Logauswertung mit dem PolicyReporter.
    Übernahme GPO Prozess mit 5 "Standard" GPOs: 0,6 - 0,7 Sekunden
    Übernahme GPO Prozess mit 200 WMI GPOs: 4,3 - 4,7 Sekunden

    Also eine Differenz von 3,5 - 4 Sekunden, Also nahezu nichts.

    Eine Struktur in der ein einzelnes Objekt 200 GPOs übernimmt und wo dann
    auch noch 200 WMI Filtern zur Anwendung kommen, muss man aber
    auch erst mal suchen. Da würde ich spontan behaupten, da ist
    Optimierungsbedarf.

    WMI ist kein Performancekiller. Da stirbt eher das Anmeldescript an dem
    Copyjob oder an einem Timeout, weil ein Rechner nicht erreichbar ist
    oder oder oder.

    QED
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Dienstag, 27. Dezember 2011 17:31
  • >WMI ist kein Performancekiller

    Einigen wir uns einfach darauf, man sollte den WMI-Filter vorher messen.

    Und darauf, dass sinnvolle WMI-Filter das System nicht ausbremsen.

    In diesem konkreten Beispiel macht es das Kraut nicht fett.

    >200 WMI Filter (zz-wmi-test-xxx)

    Mal was anderes, wie kopierst du die WMI Filter?

    Hast du ein Script?
    Mir fällt nämlich adhoc kein cmdlet oder ähnliches ein, dass WMI Filter kopiert.

     


    MVP - Group Policy http://matthiaswolf.blogspot.com/
    Dienstag, 27. Dezember 2011 20:05
    Beantworter
  • > measure-command {Get-WmiObject -query "Select * from Win32_Product where
    > Name like '%Adobe Reader%'"}
     
    Witzbold (: Das macht jeder Admin genau einmal (in einer Testumgebung
    hoffentlich) und dann nie wieder.
     
    Seit SP2 (Vista) und SP1 (Win7) gibts da übrigens nen werksseitig
    eingebauten Notnagel (separater WMI Filter Provider), der dafür sorgt,
    daß lang laufende Abfragen nach spätestens 30 Sekunden (mit "unwahr")
    abgebrochen werden. (Nein, nicht konfigurierbar.)
     
    Dein Posting zeigt, daß Du das noch nie wirklich als WMI-Filter
    ausprobiert hast, sondern immer nur (eigentlich lobenswert!) vorher...
    Die tatsächliche Laufzeit und das Ergebnis kannst dann im gpsvc.log
    schön nachvollziehen.
     
    Und warum dauert das überhaupt so lange? Weil der WMI MSI-Provider bei
    der Abfrage eine Reparaturinstallation aller MSI-Pakete auslöst (soweit
    ich das nachvollziehen konnte).
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Dienstag, 27. Dezember 2011 20:41
    Beantworter
  • > *gähn* kopier doch einfach mal bei jeder Anmeldung 50MB im Anmeldescript
    > ... das macht auch keinen Sinn.
     
    Deshalb startet man die auch asynchron (:
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Dienstag, 27. Dezember 2011 20:41
    Beantworter
  • > Mal was anderes, wie kopierst du die WMI Filter?
     
    mofcomp (und vorher ne neue GUID und nen anderen Namen ins MOF rein).
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Dienstag, 27. Dezember 2011 20:42
    Beantworter
  • > darin als Anfrage: select * from Win32_IP4RouteTable
    > where Name like '192.168.xxx.%'.
     
    Das klappt, weil das eine rein lokale Eigenschaft ist - WMI kann in
    gewissen Grenzen cachen. Bei einem Filter auf (auch wenn blödsinnig)
    Win32_Account geht das nicht mehr, da jedesmal das ganze AD durchsucht wird.
     
    Die Evaluierungszeiten der jeweiligen Filterabfrage kann man im
    gpsvc.log nachvollziehen. Bei der ersten Abfrage sieht man hier Zeiten
    von (etwa) 300 ms bis zu 5 Sekunden. Alle weiteren Abfragen (wenn
    lokal!) gehen signifikant schneller.
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Dienstag, 27. Dezember 2011 20:44
    Beantworter
  • Der Thread wird immer besser :)

    >Witzbold (: Das macht jeder Admin genau einmal (in einer Testumgebung
    >hoffentlich) und dann nie wieder

    Darum ging es ja gar nicht.
    Es ging lediglich darum zu zeigen, dass es bei unkorrekter Anwendung sein kann, das ein
    WMI-Filter die Abarbeitung der GPOs deutlich verzögern kann.

    >Seit SP2 (Vista) und SP1 (Win7) gibts da übrigens nen werksseitig
    >eingebauten Notnagel

    Ich weiß. Wenn du dich erinnerst, wir hatten diese Diskussion schon einmal:

    http://social.technet.microsoft.com/Forums/de/gruppenrichtliniende/thread/305051de-ad04-4fcc-9efb-dc5d1d1ba3a0

    Damals war es für uns beide eine neue Information.
    Aber leider laufen nur die "neuen" Systeme in diesen Timeout.

    >Und warum dauert das überhaupt so lange? Weil der WMI MSI-Provider bei
    >der Abfrage eine Reparaturinstallation aller MSI-Pakete auslöst

    Ja, korrekt.
    Das Verhalten ist unter anderem auch hier dokumentiert:

    http://support.microsoft.com/kb/974524

    Ein Grund mehr, diesen Filter nicht zu nutzen!
    >Dein Posting zeigt, daß Du das noch nie wirklich als WMI-Filter
    >ausprobiert hast

    Ich arbeite selten mit WMI Filtern.
    Seit sich viele Einstellungen per GPP mit ILT regel lassen noch weniger.

    Ich habe allerdings schon einige dieser Konstellationen gesehen, deshalb auch der Ausdruck "der Klassiker".
     
    >mofcomp (und vorher ne neue GUID und nen anderen Namen ins MOF rein)

    GUID und Name ändern, ja... Aber was machst du mit mofcomp an dieser Stelle?
    Die Frage bezog sich natürlich auf WMI-Filter kopieren innerhalb der GPMC, bzw.
    scriptbasierend.
    PS:

    Nur noch am Rande, die Grundaussage dieser Monsterdiskussion war einfach nur:

    Nutze doch Site-GPOs anstatt GPOs mit WMI-Filter für jedes Subnetz :)

    MVP - Group Policy http://matthiaswolf.blogspot.com/





    Dienstag, 27. Dezember 2011 23:25
    Beantworter
  • Am 27.12.2011 21:05, schrieb Matthias Wolf [MVP]:

    Mal was anderes, wie kopierst du die WMI Filter?

    Notepad :-)

    Ich exportiere eine leere OU mit "CreateXMLfromEnvironment.wsf" da sind
    immer alle WMI Filter enthalten.

    <WMIFilter Name="whatever" Description="ganz wichtig, ohne kein Import">
     <Query>root\CIMv2;SELECT * FROM ... </Query>
    </WMIFilter>

    Die Zeilen lassen sich leicht vermehren, gleiches gilt für die
    Verbindung WMI zu GPO, danach das ganze wieder per
    CreateEnvironmentfromXML.wsf importieren, fertig.

    Gnaz wichtig: Ohne Beschreibung im WMI import es nicht.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Mittwoch, 28. Dezember 2011 19:06
  • Am 27.12.2011 21:05, schrieb Matthias Wolf [MVP]:

    Und darauf, dass sinnvolle WMI-Filter das System nicht ausbremsen.

    Das war alles, worum es ging, ich wollte nur das generelle "Digma"
    endlich mal beiseite schaffen.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Mittwoch, 28. Dezember 2011 19:51
  • >Notepad :-)

    Wie langweilig :)

    Aber funktioniert. Danke.


    MVP - Group Policy http://matthiaswolf.blogspot.com/
    Mittwoch, 28. Dezember 2011 22:29
    Beantworter
  • Achja, habe ich noch gefunden:

    http://gallery.technet.microsoft.com/scriptcenter/f1491111-9f5d-4c83-b436-537eca9e8d94

    Allerdings hatte ich bisher keine Zeit es zu testen.
    MVP - Group Policy http://matthiaswolf.blogspot.com/
    Mittwoch, 28. Dezember 2011 22:46
    Beantworter
  • Am 28.12.2011 schrieb Matthias Wolf [MVP]:

    PS:

    Nur noch am Rande, die Grundaussage dieser Monsterdiskussion war einfach nur:

    Nutze doch Site-GPOs anstatt GPOs mit WMI-Filter für jedes Subnetz :)

    Ist doch cool was dabei alles diskutiert wurde. ;)

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Mittwoch, 28. Dezember 2011 23:02
  • Am 28.12.2011 23:46, schrieb Matthias Wolf [MVP]:

    Achja, habe ich noch gefunden:
    http://gallery.technet.microsoft.com/scriptcenter/f1491111-9f5d-4c83-b436-537eca9e8d94

    Den kannte ich, aber da ich keine Powershell verwende fand ich das XML
    wesentlich einfacher, zumal man die notwendige Zeile als Echo in die
    XML-Text Datei über eine for /l Schleife mit Zähler schreiben kann ;-)

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:       www.gruppenrichtlinien.de - deutsch
    GPO Tool:       www.reg2xml.com - Registry Export File Converter
    NetworkTrayTool www.gruppenrichtlinien.de/tools/Networktraytool.htm

    Donnerstag, 29. Dezember 2011 08:51
  • >Ist doch cool was dabei alles diskutiert wurde. ;)

    Auf jeden Fall!

    Ich glaube ich fasse doch noch mal in einem Blogeintrag zusammen ;)

     


    MVP - Group Policy http://matthiaswolf.blogspot.com/
    Donnerstag, 29. Dezember 2011 10:16
    Beantworter
  • Am 27.12.2011 schrieb Matthias Wolf [MVP]:
    Hi,

    Wenn man weiß was man tut, kann man auch mit 250 unangeschnallt mit Handy am Ohr barfuß durch den Nebel fahren...

    Naja, nicht alles was hinkt ist ein Vergleich, oder wie war das? ;)

    Aber leider ist das oft nicht der Fall.

    Vielleicht sind wir einfach wieder beim Punkt "Pauschalaussagen".

    Ja, und die hast du getroffen. ;) Wenn man weiß, was man tut kann man sowohl
    site GPOs als auch WMI Filter problemlos einsetzen. Das Problem bei Site GPO
    ist aber meines Erachtens, dass die noch schneller in Vergessenheit geraten
    und gerade bei mobilen Clients dann, zu den von Mark erwähnten, Quereffekten
    führen. Denn zumindest ich boote mein Notebook selten bis noch seltener, so
    dass Site-GPOs dann mich nur sporadisch wenn überhaupt sinnvoll treffen
    würden.

    Noch interessanter werden Site-GPOs übrigens in Multidomain-Umgebungen. ;)

    Bye
    Norbert


    Dilbert's words of wisdom #04:
    There are very few personal problems that cannot be solved by a suitable
    application of high explosives.

    Donnerstag, 29. Dezember 2011 12:02
    Moderator
  • > Der Thread wird immer besser :)
     
    Ja, wir sind auf nem recht hohen Niveau angekommen (:
     
    > Ich weiß. Wenn du dich erinnerst, wir hatten diese Diskussion schon einmal:
     
    Drum kam mir das so bekannt vor - Alzheimer light... Aber Du hast ja
    noch ein paar Jahre bis dahin ((:
     
    > Ich habe allerdings schon einige dieser Konstellationen gesehen, deshalb
    > auch der Ausdruck "der Klassiker".
     
    Hoffentlich nur "kurze Zeit"...
     
    mfg Martin
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Donnerstag, 29. Dezember 2011 20:14
    Beantworter
  • >Alzheimer light... Aber Du hast ja
    >noch ein paar Jahre
     
    Keine Sorge, das Vergessen bekomm ich jetzt auch schon hin :)
     

    MVP - Group Policy http://matthiaswolf.blogspot.com/
    Donnerstag, 29. Dezember 2011 20:24
    Beantworter
  • > Keine Sorge, das Vergessen bekomm ich jetzt auch schon hin :)
     
    <eg> Und was wir übermorgen erst noch alles wissen, was wir in 3 Tagen
    dann vergessen haben...
     

    A bissle "Experience", a bissle GMV... Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Donnerstag, 29. Dezember 2011 20:30
    Beantworter
  • So, um das nun zum Abschluss zu bringen:

    http://matthiaswolf.blogspot.com/2011/12/lies-of-gpo-4.html

    Der ein oder andere Grammatik- und Rechtschreibfehler ist noch auszumerzen,

    aber ich hoffe ich habe nichts vergessen.


    MVP - Group Policy http://matthiaswolf.blogspot.com/
    Samstag, 31. Dezember 2011 15:04
    Beantworter
  • Am 31.12.2011 schrieb Matthias Wolf [MVP]:
    Hi,

    So, um das nun zum Abschluss zu bringen:

    http://matthiaswolf.blogspot.com/2011/12/lies-of-gpo-4.html

    Gute Zusammenfassung. :)

    Frohes neues Jahr alle zusammen übrigens.

    Bye
    Norbert


    Dilbert's words of wisdom #34:
    When you don't know what to do, walk fast and look worried.

    Sonntag, 1. Januar 2012 18:46
    Moderator
  • Danke ;)

    Auch von mir ein gutes neues Jahr!
    MVP - Group Policy http://matthiaswolf.blogspot.com/
    Sonntag, 1. Januar 2012 19:38
    Beantworter