einstein

Unglaublich, genauso ist es.... Die PSO greift nur die Anzeigen unter XP/2003 etc. sind die aus der DDP. *wuahhhaaa*

Na ja, danke allen für die Hilfe. Dieser Thread hilft vielleicht noch anderen dieses Phantom-Problem früher zu erkennen.

Hi Olc,

ich melde mich als der besagte User an einem XP Client an und schau mir via RSOP die Richtlinien an, ja! Ich weiß das die PSO´s keine GPO´s sind, aber ich weiß nicht ob im RSPO dann nicht was anderes unter den Kennwortrichtlinien stehen müsste als das was die DDP hergibt. Oder täusche ich mich hier und dort stehen immer die Einstellungen der DDP?

Außerdem stimmten die Angaben bezüglich Kennwortlänge etc. beim Kennwortänderungsdialog nicht. Sprich ich täusche in falsches neues Kennwort an und das System klärt mich über die Komplexitätsanforderungen, Kennwortlänge, Alter usw. auf.

Auch das stimmt nicht mit meinen FGPP Einstellungen überein.

Möglicherweise funktioniert ja alles und ich jage ein Phantom.... Bzw. es werden nur falsche Dinge angezeigt?

Danke für den report.html Tipp. Schau ich mir morgen mal an.

@samsam

Danke für die Info, das hatte ich berücksichtigt bzw. mit dsget erfolgreich ermittelt das die PSO dem Benutzer zugewiesen ist.

@olc

Habe damit gespielt aber nur ohne der Option „-scope onelevel“ einen Export geschafft. Das Tool stresst mich irgendwie. Jedenfalls ist dieser Export dann sehr umfangreich und fast nicht zu anonymisieren... :(

Weiterhin habe ich inzwischen in einer weiteren brandneuen Subdomain, welche von Haus aus unter 2008R2 installiert wurde, denselben Effekt. Ein rsop.msc liefert mir unter den Kennwortrichtlinien als Quell-Gruppenrichtlinienobjekt immer nur die DefaultDomainPolicy.

Noch eine andere Idee. Kann es sein das der Hinweis den ein User beim Kennwort ändern bekommt nicht die PSO Einstellungen wiederspiegelt?

Ist es möglich das auch RSOP.msc nur die Ergebnisse der DDP darstellt?

dn: CN=Tester,OU=Benutzer&Computer,OU=MeineOU,DC=firma,DC=de,DC=RootDomain

changetype: add

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: user

cn: Tester

description: Reiner Testuser

givenName: Tester

distinguishedName:

CN=Tester,OU=Benutzer&Computer,OU=MeineOU,DC=firma,DC=de,DC=RootDomain

instanceType: 4

whenCreated: 20050426085206.0Z

whenChanged: 20100920095704.0Z

displayName: Tester

uSNCreated: 24465

memberOf::

Q049R0ctS2VubndvcnRyaWNodGxpbmllLVByb2R1a3Rpb24sT1U9S2VubnfDtnJ0ZXIsT1U9R3J1cH

BlbixPVT1tZWlsbGVyLERDPWRlLVNBRCxEQz1jb3JwLERDPWRpcg==

memberOf::

Q049TEctU0FETldUSzAxLVdhcnR1bmdzdmVydHJhZWdlLVZvbGx6dWdyaWZmLE9VPUZyZWlnYWJlbi

ZSZWNodGUsT1U9TG9rYWxlR3J1cHBlbixPVT1HcnVwcGVuLE9VPW1laWxsZXIsREM9ZGUtU0FELERD

PWNvcnAsREM9ZGly

memberOf::

Q049eHh4LE9VPXByb3h5LE9VPUdydXBwZW4sT1U9bWVpbGxlcixEQz1kZS1TQUQsREM9Y29ycCxEQz

1kaXI=

memberOf::

Q049c3BvcnQsT1U9cHJveHksT1U9R3J1cHBlbixPVT1tZWlsbGVyLERDPWRlLVNBRCxEQz1jb3JwLE

RDPWRpcg==

memberOf::

Q049Ym9lcnNlLE9VPXByb3h5LE9VPUdydXBwZW4sT1U9bWVpbGxlcixEQz1kZS1TQUQsREM9Y29ycC

xEQz1kaXI=

memberOf::

Q049TEctSGludGVyZ3J1bmRiaWxkLVNlcnZlclVzZXIsT1U9RnJlaWdhYmVuJlJlY2h0ZSxPVT1Mb2

thbGVHcnVwcGVuLE9VPUdydXBwZW4sT1U9bWVpbGxlcixEQz1kZS1TQUQsREM9Y29ycCxEQz1kaXI=

memberOf::

Q049TEctc2FkZHMwMi1QTV9TQUQsT1U9RnJlaWdhYmVuJlJlY2h0ZSxPVT1Mb2thbGVHcnVwcGVuLE

9VPUdydXBwZW4sT1U9bWVpbGxlcixEQz1kZS1TQUQsREM9Y29ycCxEQz1kaXI=

memberOf::

Q049ZG93bmxvYWQsT1U9cHJveHksT1U9R3J1cHBlbixPVT1tZWlsbGVyLERDPWRlLVNBRCxEQz1jb3

JwLERDPWRpcg==

memberOf::

Q049ZmFocnpldWdlLE9VPXByb3h5LE9VPUdydXBwZW4sT1U9bWVpbGxlcixEQz1kZS1TQUQsREM9Y2

9ycCxEQz1kaXI=

memberOf::

Q049cmFkaW92aWRlbyxPVT1wcm94eSxPVT1HcnVwcGVuLE9VPW1laWxsZXIsREM9ZGUtU0FELERDPW

NvcnAsREM9ZGly

memberOf::

Q049d2VibWFpbCxPVT1wcm94eSxPVT1HcnVwcGVuLE9VPW1laWxsZXIsREM9ZGUtU0FELERDPWNvcn

AsREM9ZGly

memberOf::

Q049aW50ZXJuZXQtc3VyZmVycyxPVT1wcm94eSxPVT1HcnVwcGVuLE9VPW1laWxsZXIsREM9ZGUtU0

FELERDPWNvcnAsREM9ZGly

memberOf::

Q049ZWJheSxPVT1wcm94eSxPVT1HcnVwcGVuLE9VPW1laWxsZXIsREM9ZGUtU0FELERDPWNvcnAsRE

M9ZGly

uSNChanged: 2494496

name: Tester

objectGUID:: lf/AHhhC00+SVVoCxdeNrA==

userAccountControl: 512

badPwdCount: 0

codePage: 0

countryCode: 0

badPasswordTime: 129295089546397551

lastLogoff: 0

lastLogon: 129296410983603992

pwdLastSet: 129294502248195053

primaryGroupID: 513

userParameters::

ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUAUaCAFDdHhDZm

dQcmVzZW5045S15pSx5oiw44GiGAgBQ3R4Q2ZnRmxhZ3Mx44Cw44Gm46Cy44C5EggBQ3R4U2hhZG93

44Sw44Cw44Cw44CwKgIBQ3R4TWluRW5jcnlwdGlvbkxldmVs44SwIEIBQ3R4V0ZQcm9maWxlUGF0aO

aMteaMteOMt+OEtuOQtuOYtuOktuaMtuOUtuOIt+OAs+OEs+aMteOUt+OMt+OUtuOIt+aMteOQt+OU

tuOMt+OQt+OUtuOIt+aMteOAt+OIt+aYtuOYtuOktuaMtuOUtuOAsA==

objectSid:: AQUAAAAAAAUVAAAAJBlPg9a3HkwmDulW+QcAAA==

accountExpires: 9223372036854775807

logonCount: 31

sAMAccountName: tester

sAMAccountType: 805306368

userPrincipalName: tester@firma.de

lockoutTime: 0

objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=RootDomain

dSCorePropagationData: 20100921114242.0Z

dSCorePropagationData: 16010101000001.0Z

lastLogonTimestamp: 129294502249305053

msDS-SupportedEncryptionTypes: 0

msDS-PSOApplied:

CN=Standard,CN=Password Settings Container,CN=System,DC=firma,DC=de,DC=RootDomain

Hi olc,

also secedit will bei mir nicht. Anbei die beiden anonymisierten Exports.

Was ich noch sagen wollte, die Domain ist eine SubDomain unserer RootDomain. Welche auch Funktionsebene 2K8R2 hat. Aber die Gesamtstrukturfunktionsebene ist noch 2003 da ich noch eine andere Subdomäne habe welche unter 2003 läuft.

dn: CN=Standard,CN=Password Settings Container,CN=System,DC=firma,DC=de,DC=RootDomain

changetype: add

objectClass: top

objectClass: msDS-PasswordSettings

cn: Standard

distinguishedName:

CN=Standard,CN=Password Settings Container,CN=System,DC=firma,DC=de,DC=RootDomain

instanceType: 4

whenCreated: 20100917135541.0Z

whenChanged: 20100922145639.0Z

uSNCreated: 2413942

uSNChanged: 2580039

name: Standard

objectGUID:: oQBkGzSHnUCjr9BoaYsXHg==

objectCategory:

CN=ms-DS-Password-Settings,CN=Schema,CN=Configuration,DC=RootDomain

dSCorePropagationData: 20100921114243.0Z

dSCorePropagationData: 16010101000001.0Z

msDS-MaximumPasswordAge: -36288000000000

msDS-MinimumPasswordAge: -864000000000

msDS-MinimumPasswordLength: 18

msDS-PasswordHistoryLength: 24

msDS-PasswordComplexityEnabled: TRUE

msDS-PasswordReversibleEncryptionEnabled: FALSE

msDS-LockoutObservationWindow: -18000000000

msDS-LockoutDuration: -18000000000

msDS-LockoutThreshold: 10

msDS-PSOAppliesTo:

CN=Tester,OU=Benutzer&Computer,OU=MeineOU,DC=Firma,DC=de,DC=RootDomain

msDS-PasswordSettingsPrecedence: 10

Hallo olc,

es werden wohl überhaupt keine Kriterien angewendet bzw. exakt diejenigen aus der DDP.

Meine Einstellungen in der PSO entsprechen den Beispielen der MS Hilfe. Wobei ich inzwischen schon einige verschiedene angelegt habe mit unterschiedlichen Einstellungen. Aber hier siehe selbst:

AppliesTo : {CN=Tester,OU=Benutzer&Computer,DC=firma,DC=de}

ComplexityEnabled : True

DistinguishedName : CN=Standard,CN=Password Settings Container,CN=Sys

tem,DC=firma,DC=de

LockoutDuration : 00:30:00

LockoutObservationWindow : 00:30:00

LockoutThreshold : 10

MaxPasswordAge : 42.00:00:00

MinPasswordAge : 1.00:00:00

MinPasswordLength : 8

Name : Standard

ObjectClass : msDS-PasswordSettings

ObjectGUID : 1b6400a1-8734-409d-a3af-d068698b171e

PasswordHistoryCount : 24

Precedence : 10

ReversibleEncryptionEnabled : False

User habe ich inzwischen verschiedene getestet, ebenso mehrere Computer. Mit deinen vorgeschlagenen Exports bin ich im Moment etwas überfordert....

@NilsK

Das Tool hatte ich schon verwendet.

Die Zuordnung usw. habe ich schon mit ADs Powershell geprüft.

@olc

Ja Die Domäne ist im 2008R2 Modus und besteht nur aus 2008R2 DC´s.

Die PSO habe ich erst nach dem hochstufen angelegt. Genauer erst Wochen danach..

Danke erst mal für Eure Hilfe. Bisher tappe ich noch im Dunkeln wieso das nicht funktioniert wobei es doch relativ klar ist wie das einzurichten ist etc..

Auch die verzweifelte Hoffnung das es per PowerShell Kommando im Gegensatz zu ADSI-Edit funktionieren würde hat sich nicht bestätigt. Diese Hoffnung war auch eher unwahrscheinlich.

PSO hatte ich schon vorab mit Gruppen und mehreren Usern verknüpft ohne Erfolg. Selbst andere XP Client´s brachten nix.

Die Idee mit einem neu angelegten User war gut, leider auch hier kein Erfolg obgleich die Policy entsprechend zugewiesen ist. Habe ich erneut mit "Get-ADUserResultantPasswordPolicy" überprüft.

Aus irgendeinem Grund zieht immer noch die DDP und nicht die PSO obgleich die offensichtlich zugewiesen ist. Aktuell habe ich dafür keine Erklärung und auch keine Idee woran das liegen könnte? Ich meine das Prinzip dahinter verstanden zu haben, habe ja deinen Artikel ausführlich gelesen. Ich arbeite mit ADSI-Edit, vielleicht liegt es daran?

Zum Test erstelle ich nun mal die PSO neu via PowerShell.

Danke für deine Antwort. Zunächst dachte ich das wäre der Fehler gewesen, denn "Kennwort läuft nie ab" war tatsächlich noch aktiviert...... :(

Aber es funktioniert auch nachdem ich diese Option rausgenommen habe nicht. Das Kennwort lief erwartungsgemäß sofort ab usw. aber an meinem Problem ändert das nix.

Das ist für mich sehr ärgerlich da genau diese Möglichkeit einer der Hauptgründe waren um unser AD auf 2008R2 zu migrieren. (Die Migration erfolgte hier komplett durch neue Domaincontroller.)

Hallo Yusuf, exakt so ist es. Er zeigt mir hier die korrekte PSO inkl. der entsprechenden Werte etc. an.

Ich habe mich genau an Deine Anleitung gehalten und bin am verzweifeln. Verstehe derzeit echt nicht woran das liegen könnte.. :(

Hallo Leute,

unter 2008R2 sind ja nun mehrere Kennwortrichtlinien möglich. Ich habe nun ein PSO erstellt und explizit Benutzern zugewiesen. Das entsprechende Attribut ist beim user auch hinterlegt, dass habe ich extra kontrolliert. Nun ist es aber dennoch so, dass die DDP "zieht" und nicht meine eigens PSO.

Ich finde aber auch keinen Fehler, es gibt ja einige Anleitungen wie es einzurichten ist und genau das habe ich getan.

Es handelt sich um eine W2K8R2 Domäne welche bis auf das fehlerlos arbeitet.

Hat jemand eine Idee was ich falsch mache oder wo der Fehler liegen könnte?

Danke!

Hallo,

ich frage mich gerade ob das wohl nur mit dem Storage Server nutzbar ist?

Wer weiß das oder wer nutzt das ggf. schon?

ciao

Und schon was Neues zu diesem Thema?

Hallo Leute, ich schon wieder.... :p

Habe hier viele Server welche über Loginscripte gemappt werden, nun ist es so das sobald ich die Mappings via FQDN mache Sicherheitswarnungen auftauchen. Diese lassen sich ja in den Sicherheitsoptionen des IE verhindern.

Nur ist die Frage wieso kann ich das nicht für die komplette Domäne verhindern? Ich meine im Moment ich müsste hier jeden Server einzeln eintragen.

Test´s mit file:\\*.domäne oder eben nur *.domäne funktionieren leider nicht. Wie macht ihr das, wie ist das bei euch?

@Sunny61

Danke für die Info, an den WSUS habe ich hier gar nicht gedacht. Aber updatet der nicht "nur" vorhandene Installationen? Welche dotNet ist denn Standardmäßig bei Windows XP dabei, weist du das zufällig?

@Stephan

Dachte mir schon das es über GPO nicht so 100% läuft.

Hallo Leute,

nachdem ich mit der Softwareverteilung via GPO durch die Hilfe einiger Mitglieder hier zurechtkomme habe ich dennoch eine Frage zum .Net und dessen Verteilung.

Hat das schon jemand so realisiert?

Es gibt eine Anleitung von MS nach welcher hier eine bestimmte Reihenfolge der einzelnen Komponenten eingehalten werden muss bzw. bestimmte Pakete welche aus dem extrahierten dotnetfx35.exe stammen installiert werden sollen.

Nun funktioniert das nicht da er zwar hier zunächst .Net2.0 SP2 und .Net3.0 SP2 installiert aber beim 3.5er dann im Ereignislog des Clients meint es müsse vor der 3.5er zunächst die 3.0 SP1 installiert werden.

Aber es wurde ja schon automatisch die 3.0 SP2 Version installiert?

Wenn ich nun testweise händisch über eine dotnetfx35.exe (237MB Microsoft .NET Framework 3.5 Service pack 1 Full Package) installieren möchte fängt er an was von MS nachladen zu wollen was ich aber unterbinde.

Wieso will der Installer denn was nachladen wenn ich ein Full Package habe, enthält das nicht alle erforderlichen Daten? Was mich auch irritiert ist das es offensichtlich inkrementell aufeinander aufbaut, also erst 2.0 dann 3.0 und dann 3.5. Ein sagen wir mal Standalone 3.5er gibt es wohl nicht?

Wer weiß Rat?

Danke!

@Sunny61

Wenigstens einer der mich versteht... :-)

Ich meinte den Computernamen, wie gesagt, erst das Umbenennen brachte die Lösung.

@unst

Wollte ich schon, aber die haben mich nicht gelassen. *hehe*

Nun funktioniert es, ich nehme nach dem Motto "was interessiert mich mein Geschwätz von gestern.." meine Behauptung wieder zurück. :p

@Sunny61

RSOP.MSC zeigte mir an das der betreffende Testclient keinerlei Computerrichtlinien zieht, sprich überhaupt keine.

Der Client hatte ein Problem mit seiner Domänenmitgliedschaft welches ich erstaunlicherweise erst lösen konnte als ich diese umbenannt hatte. Ein Raus stufen aus dem AD und Kontolöschung/DNS/WINS brachte nix, erst das Umbenennen löste diesen Konflikt. Nun übernahm der Client auch wieder Computerrichtlinien.

Leider muss ich zugeben, dass ich einen Anfängerfehler gemacht habe und zunächst noch mehr verschiedene Clients testen hätte sollen bevor ich die Funktion generell anzweifle. :(

@NorbertFe

Sorry für meine Provokante Aussage, manchmal ist man wohl etwas genervt....

@all

Dennoch war dieser Thread in jeder Hinsicht sehr sehr lehrreich für mich, nicht nur technischer Natur. :-) Danke für die Hilfe von jedem.

@Sunny61

Ne so einfach is es nicht, klar habe ich hier einen FQDN UNC Pfad hinterlegt welcher auch vom Client aus erreichbar ist.

@Ilem

Der Ansatz ist gut, werde ich auch ausprobieren. gpupdate /force ist Standard und das mache ich sowieso dauernd... :cool:

@all

Es deutet derzeit darauf hin das es wohl am Client liegt, ich habe nun diverse VMs getestet und merke doch das es auf einigen Funktioniert. Sprich irgendwas stimmt mit manchen Clients dahingehend nicht. Was kann ich aber derzeit noch nicht sagen. Das Problem liegt wohl nicht an der Sache an sich sondern wie gesagt deutet es derzeit auf ein Clientproblem bei mir hin. Sobald ich konkret sagen kann woran es lag teile ich dies natürlich mit.

Trotzdem danke erst mal für die Hilfe bisher.... :)

/a??

Den Link werde ich testen und berichten... ;-)

Gerade Citrix liefert super Möglichkeiten um das angepaßte msi für die unattended Installation mittels GPO zu erstellen. Hast du das getan?

 

Warum? Domänencomputer sind per default "Authentifizierte Benutzer". ;)

 

 

 

Am Client steht nichts im Eventlog? Das läßt wie gesagt nur die Vermutung zu, dass irgendwas mit deiner GPO nicht stimmt.

 

 

 

Client Side Extension.

 

Bye

Norbert

Welche Möglichkeiten sind das denn welche Citrix liefert? Die habe ich wohl bisher übersehen.

Das mit den Authentifizierten Benutzern weiß ich auch, aber das klappt eben trotzdem nicht was ich in einigen anderen Threads recherchiert habe. Deswegen hatte ich die DomComp explizit berechtigt.

Das mit dem Log verstehe ich auch nicht, er müsste ja "irgendwas" loggen? Und obwohl er die Richtlinie laut gpresult auch "zieht".

Erstaunlicherweise findet sich auch sehr viel zu diesem Problem bezüglich in google. Also die Anwendung auf Computer... Was mich zu der gewagten Aussage trieb das dies wohl generell problematisch zu sein scheint. Gut wenn es bei Stephan Betken und dir läuft muss es an irgendwas anderem liegen. Aber welche AD´s laufen wiederum bei euch etc...?

Ich werde daraus nicht schlau und zielte eher darauf ab ob das ein Thema ist welches total fest etabliert ist oder eher eines von der Sorte wo Theorie und Praxis nicht übereinstimmen. Letztere gibt es ja einige in der IT.

Also ich versuchte schon folgende SW.

citrix online plugin

adobe reader

support tools

Firefox-3.5.3

VMWare msi Pakete

Im Grunde würde ich wie gesagt zum testen auch irgendwas nehmen da nicht jedes msi auch funktioniert. Primär geht es mir um das neue citrix online plugin....

An den GPO Berechtigungen habe ich nicht geschraubt sondern eben nur die DomänenComputer ergänzt, wie auch auf die Share/NTFS Permissions.

Die Richtlinie hatte ich schon mehrfach neu angelegt, daran sollte es auch nicht liegen. Aber was mich stutzig macht das es keine Log´s gibt...

Was meinst du mit CSE?

@NorbertFw

Die Fakten habe ich schon genannt, hier noch Mal.

Rechner in OU verschieben auf welcher die SW installiert werden soll

GPO auf dieser OU einrichten (Rechte auf die GPO für DomänenPCs)

In dieser GPO auf das Netzwerk warten einstellen / Erhöhte installer Rechte

MSI Pakete in ein Share auf welches via Share/NTFS DomänenPCs Zugriff haben.

MSI Paket zuweisen (Rechte auf das Paket für DomänenPCs)

Mit „gpresult“ prüfen ob die Richtlinie übernommen wurde

Als Software habe ich verschiedenste Pakete ausprobiert, daran kann es nicht liegen.

Was fehlt hier noch, bin bereit alles zu geben? *hrhr*

@Dukel,

Was´n das für eine Antwort? Sorry aber wenig hilfreich. Es gibt sehr wohl den Fall das man alles richtig macht und es trotzdem nicht funktioniert. Außerdem ist das nur eine Formulierung und sonst nix!