Slifire

Vielen Dank das hat das Problem gelöst :)

Unter dem Zielpfad steht bei mir: %windir%\system32\rundll32.exe user32.dll,LockWorkStation

Hat leider nicht den gewünschten Effekt gebracht :/ Das Eventlog bringt den gleichen Fehler, vielleicht hilft der Fehlercode ja: Das Benutzer "Sperrung Testen"-Einstellungselement im Gruppenrichtlinienobjekt "Sitzung Sperren Verknüpfung {78F62570-D758-4BBF-983D-E5084E887055}" wurde aufgrund eines Fehlers nicht angewendet. Fehlercode: "0x80070002 Das System kann die angegebene Datei nicht finden." Dieser Fehler wurde unterdrückt. Ich habe das ganze auch mal in gleicher Konstellation auf einer anderen Domäne und DC getestet wo der Benutzer sich nicht auf einem Terminalserver einloggt, da funktioniert es allerdings genau so wenig.

Hallo das Log sagt das es die angegebene Datei nicht finden kann. Ich habe jetzt mal eine Zwischenlösung eingebunden, die funktioniert da es ja ein Terminalserver ist. Diese Zwischenlösung hat eine von Hand erstellte Verknüpfung in den C:User\Public\Desktop kopiert, das macht im Grunde das gleiche wie die GPO aber ist halt schlechter verwaltbar.

Hallo Community, ich habe folgende Situation, bei der ich Hilfe benötige: Benutzer greifen über Thin Clients auf einen Terminal Server zu, was soweit auch einwandfrei funktioniert. Sie sind Teil einer Domäne und die Firmenleitung hat beschlossen das bei einer Trennung der Verbindung von Thin Client zu Terminal Server der Thin Client sich automatisch abschalten soll, was soweit auch schon implementiert ist. Jetzt ist es allerdings so, das die Benutzer über eine Verknüpfung auf dem Desktop auch in der Lage sein sollen die derzeitige Sitzung einfach nur zu sperren wie man das unter Windows (Win + L) auch kennt. Bisher tuen sie dies über Strg + ALT + Ende, was jetzt allerdings über eine Verknüpfung gelöst werden soll. Ich habe mir im Internet eine kleine Anleitung gegooglet und eine entsprechende Verknüpfung bereits erstellt, jedoch ist es so das ich diese jetzt per GPO verteilen möchte, das funktioniert aber noch nicht so wie es soll. Das Problem ist das das Symbol auf dem Desktop schlichtweg nicht angezeigt wird. Der Terminal Server ist Windows Server 2012, der Domain Controller ebenfalls. Folgendes habe ich getan: - Anlegen einer neuen GPO und Verknüpfung selbiger mit der Domäne. - Die GPO Einstellungen laufen unter Benutzerkonfiguration, um momentan nur einem Testbenutzer das ganze zuzuweisen: -> Benutzerkonfiguration -> Einstellungen -> Windows Einstellungen -> Verknüpfungen - Dort habe ich zwei Aktionen angelegt, einmal erstellen und einmal aktualisieren. Diese sind genau gleich konfiguriert (siehe Bild) - Der Testbenutzer hat ein "gpupdate" und mehrmaliges an und abmelden erfahren. Per "Gpresult -r" kann ich sehen das die GPO zugewiesen wurde und nicht geblockt wird oder ähnliches. Problem ist nun allerdings das sich auf dem Desktop des Testbenutzers gar nichts tut :/

Hallo Community, bei meinen Recherchen bin ich des öfteren über dieses Forum gestolpert und da ich meist das gefunden habe was ich suchte, dachte ich mir das mir hier vielleicht am besten geholfen werden kann. Um es ganz kurz auf den Punkt zu bringen, Ziel ist es einen Exchange 2010 in der Domäne contoso.com mit einem Exchange 2013 in der Domäne xxx.local so vertraut zu machen das die beiden sich kennen, Kontakte und Kalender austauschen können usw. Die beiden Domänen contoso.com und xxx.local haben bereits eine funktionierende Vertrauensstellungen zueinander, falls dies von belang ist. Exchange Server 2010 läuft auf einem Windows Server 2008 R2 Exchange Server 2013 läuft auf einem Windows Server 2012 R2 Beide Exchanges können den jeweils anderen pingen, egal ob ich den FQDN oder die IP direkt nehme. Bisher habe ich folgendes getan: Exchange Server 2010 -> Organisationskonfiguration -> Verbundvertrauensstellungen -> Das Microsoft Federation Gateway sollte eingerichtet sein, ich habe einen Anwendungsbezeichner, Anwendungs-URI sowie ein aktuelles Zertifikat. Das Zertifikat ist gültig und der Verteilungsstatus zeigt mir keine Fehler an. Bei Organisationsbeziehungen gibt es die xxx.local mit "Freigabe aktiviert = Wahr" und "Kalender aktiviert = Wahr". Ich musste dort allerdings die Konfigurationsinformationen manuell eingeben, da es sonst nicht möglich war diese Beziehung zu erstellen. Desweiteren ist das Feld für den Endpunkt der externen Exchange-Organisation noch leer, da ich nicht weiß was ich dort eintragen muss. Ebenfalls habe ich auf dem Exchange Server 2010 momentan die Standardfreigaberichtlinie ein wenig konfiguriert und benutze momentan diese. Exchange Server 2013 -> Organisation -> Freigabe -> Hier habe ich unter dem ersten Punkt die xxx.local als Primäre freigegebene Domäne definiert. Der Kontonamespace deckt sich mit der Anwendungs-URI des Exchange 2010. Unter dem Punkt Organisationsfreigabe befindet sich die contoso.com, allerdings hatte ich da gehörige Probleme die Anwendungs-URI sowie den Endpunkt der AutoErmittlung einzustellen. Die Anwendungs-URI ist momentan der FQDN des Exchange 2010, oder war die Anwendungs-URI den mir der Federation Gateway angezeigt hat, beides hat nicht funktioniert oder keinen Unterschied gemacht. Als Endpunkt der AutoErmittlung habe ich den MetabasePath genommen der mir der Befehl "Get-AutodiscoverVirtualDirectory |fl" über die Exchange Verwaltungsshell auf dem 2010 ausgegeben hat. Hier habe ich allerdings keine Ahnung ob das stimmt. Desweiteren sind auf den Internen DNS Servern "txt" Einträge vorhanden die als AppID den Anwendungsbezeichner des Microsoft Federation Gateways beinhalten. Auf dem öffentlichen DNS Server wurde ebenfalls ein DNS Eintrag der Marke "TXT" eingetragen wo ich den Code eingegeben habe der mir unter dem Punkt "Proof:" ausgegeben wird nachdem ich in der Verwaltungsshell den Befehl: Get-FederatedDomainProof -DomainName xxx.local oder contoso.com eingegeben habe. Was fehlt mir jetzt noch, oder wo habe ich einen Fehler gemacht? Denn bisher fühlt sich alles wie vorher an, was die Kommunikation unter den Exchange Servern anbelangt. Sprich überall sind die oben genannten Punkte scheinbar ohne Fehler eingerichtet aber die Kommunikation klappt genausowenig wie vor der ganzen Konfiguration. Bin über jede Hilfe dankbar. Kleiner Nachtrag: Wenn ich den Befehl Get-FederatedDomainProof -DomainName auf den unterschiedlichen Exchanges ausführe bekomme ich beim Proof seltsame Werte heraus. Wenn ich also bspw. auf 2010 den Befehl für die xxx.local eingebe, erhalte ich etwas wie 1234.... Führe ich den Befehl aber auf 2013 aus erhalte ich 67890... genau derjenige der auch im TXT eintrag im öffentlichen DNS steht. Ist das normal oder warum gibt mir der 2010 einen anderen Proof raus?