wicksupport

Ich habe die Einstellungen für Windows Update in eine neue GPO gepackt und in der vorherigen (die aber auch angewendet wurde) auf nicht konfiguriert gesetzt. Seid dem wird es wie gewünscht angezeigt. Damit ist das Ziel erreicht.

Da es um Einstellungen von einzelnen Usern geht, die diese selbst in Programmen vornehmen können, ist die Vorgabe per GPO oder per Script keine Lösung. Wir haben auch keine Schwierigkeiten mit der momentanen Konstellation, da aber gut läuft. Es ging lediglich um die Frage, ob auch andere die gleiche Erfahrung gemacht haben, oder ob die Anmeldung auch bei der Konstellation wieder möglich ist, wie das bisher war. Trotzdem danke für die Ideen.

Vor allem geht es da um den CU Bereich der Registry, in dem für einige Programme Einstellungen für den jeweiligen User gespeichert werden.

Es wird eine Kombination von Ordnerumleitung und servergespeicherten Benutzerprofilen genutzt, was auch ohne Probleme funktioniert und an den verschiedenen Arbeitsplätzen die gleiche Umgebung garantiert. Lokale Kopien von den servergespeicherten Profilen werden über die GPO gelöscht, was alles keine Probleme macht. Es geht also nur um die Änderung, die MS scheinbar vorgenommen hat, die jetzt das Abmelden über die GUI erschweren.

Das hatte ich auch bereits gefunden. Der Wert war vorhanden mit 0. Habe den Eintrag gelöscht, den Windows Update Dienst neu gestartet und die Option ist immer noch nicht vorhanden.

Seit einiger Zeit ist bei den Clients mit Windows 11 die Benutzerabmeldung über das Startmenü nicht mehr möglich. Da sich an den Clients teilweise nichts geändert hat (auch keine Updates), kann das eventuell auch mit einem Serverupdate zusammenhängen. Der Username wird im Startmenü noch angezeigt, ein Klick darauf öffnet aber nicht das neue kleine Fenster, bei dem die Abmeldeoption normalerweise angezeigt wird. Eingrenzen konnten wir den Fehler inzwischen soweit, als das es nur servergespeicherte Benutzerprofile betrifft. Wird der gleiche Nutzer mit den gleichen Gruppenrichtlinien genutzt und der Pfad vom Benutzerprofil wird in der AD herausgenommen, dann geht auch die Abmeldung. Speicherplatz ist bei den Usern genug vorhanden, sodass ein Kontingent auch nicht das Problem sein kann. Aufgrund häufiger Wechsel der Benutzer an den Arbeitsplätzen kann auf die servergespeicherten Profile auch nicht verzichtet werden. Gibt es hierfür eine Lösung? Alternativen für die Abmeldung (Alt + F4, rechte Maustaste auf Windows-Start etc. sind bekannt, aber keine Dauerlösung).

Hallo zusammen, über GPO wird ein interner WSUS Server genutzt um die Updates vor der Installation prüfen und freigeben zu können. Für Treiber Updates etc. wird normalerweise die Funktion "Online nach Updates suchen" genutzt. Mit Windows 11 23H2 war das kein Problem. Wird der gleiche PC mit den gleichen Gruppenrichtlinien mit Windows 11 24H2 installiert, ist diese Option nicht mehr aufzufinden. Gab es hier von Microsoft eine Änderung?

Nach dem Eintragen von folgendem Schlüssel: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp] "UseCachedCRLOnlyAndIgnoreRevocationUnkownErrors"=dword:00000001 ging der Aufruf der Seite wieder ohne Probleme.

Ich habe noch folgendes getestet: Aufruf über https://realerservername.domäne1.de > Aufruf von RD Sitzung aus angelegter Sammlung geht ohne Probleme Aufruf über https://rds.domäne2.de > Aufruf von RD Sitzung aus angelegter Domäne gibt die Meldung "Ihre Sitzung wurde beendet, da der Remotecomputer ein unerwartetes Serverauthentifizierungszertifikat übermittelt hat. Wenden Sie sich an Ihren Administrator oder an den technischen Support." In den Bereitstellungseigenschaften ist bei Remotedesktopgateway unter Servername "rds.domäne2.de" angegeben. Das Wildcardzertifikat ist ausgestellt auf *.domäne2.de Der Eintrag rds.domäne2.de wird über einen CNAME Eintrag im DNS gesetzt und wird auch korrekt aufgelöst. Die gleiche Konfiguration lief bis das alte *.domäne2.de Zertifikat abgelaufen ist. Gibt es hier noch Lösungsansätze?

Ja, der Hashwert stimmt überein.

Hatte vergessen dazuzusagen, dass es ein wildcard-Zertifikat ist, das wir dafür nutzen. Es gibt kein spezielles Zertifikat für den RDS oder den Exchange extra. Ja, bei der Default Web Site

Die gleiche .pfx Datei wurde importiert.

Umgebung: Windows Domäne mit RDS 2022 (kein Cluster - alle Rollen auf dem Server installiert). Der Server lief mit dem HTML5 Client ohne Probleme. Da die Zertifikate abgelaufen sind, haben wir die neuen Zertifikate hinterlegt. Dabei handelt es sich um eine .pfx Datei von unserem Exchange Server. Der Exchange Server hat die CSR Datei für die CA erstellt (offizielle CA mit Zwischenzertifikat, keine interne CA). Die .pfx Datei wurde sowohl in den Bereitstellungseigenschaften (alle 4 Rollendienste), als auch beim RDWebClientBrokerCert (Import-RDWebClientBrokerCert c:\temp\zertifikat.pfx -PromptforPassword) hinterlegt. Dennoch kommt die Meldung "Ihre Sitzung wurde beendet, da der Remotecomputer ein unerwartetes Serverauthentifizierungszertifikat übermittelt hat. Wenden Sie sich an Ihren Administrator oder an den technischen Support." Wo können wir ansetzen, um den Fehler zu beheben? Gruß wicksupport

Domäne2 vertraut der Domäne1, ja.

Hallo zusammen, wir sind auf der Suche nach folgender Lösung: Intranetseite soll erstellt werden, bei der verschiedene Inhalte nur für bestimmte Windows Benutzer freigegeben oder angezeigt werden sollen. Das CMS System für die Intranetseite ist noch nicht festgelegt, könnte z.B. Wordpress oder ähnlich sein. Die Problematik: Die Windows Benutzer kommen aus 2 verschiedenen Windows Domänen (domäne1.local, domäne2.test). Die Benutzer sollen sich per SSO anmelden können, also weder ihre Logindaten noch einmal eingeben müssen, noch eine separate Benutzerkennung für die Intranetlösung. Gibt es hierfür eine gute Lösung? Gruß Karl

Genau so etwas haben wir gesucht. Danke.

Hallo zusammen! Ziel: Clients den Zugriff auf veröffentlichte RemoteApp-Programme und den RemoteDesktop über einen Browser ermöglichen. Bisher: RDS 2016 mit allen erforderlichen Rollen auf einem separaten Server installiert. Webclient eingerichtet, um Zugriff nur für HTML5 Clients über Reverse-Proxy zu ermöglichen. Nach der Installation und der Erstellung der Sammlung wird bei Ressourcen: Remotedesktop angezeigt und der Zugriff funktioniert auch ohne Probleme. Sobald aber die erste App veröffentlicht wird, steht unter Ressourcen: RemoteApp-Programme und es ist kein Zugriff mehr auf den RemoteDesktop möglich (kein Icon für die Benutzer). Können RemoteApps und Remotedesktop (Sitzung auf dem Server) nicht parallel erfolgen? Kann die Zielsetzung anderweitig mit nur einem Server realisiert werden? Gruß

Hallo lefg, die Berechtigungen stimmen - wie gesagt, einige Dateien werden ja auch kopiert, aber nicht alle. Auch die Kontingenteinträge wurden überprüft, um einen vollen Speicher des Benutzers auszuschließen.

Hallo zusammen! Folgendes Problem: Windows Domäne mit Windows 2012 R2 Server und Gruppenrichtlinien (Clients hauptsächlich Windows 7). Ordnerumleitung für Dokumente, Bilder, Videos, AppData etc sind eingerichtet und funktionieren ohne Probleme (schon seit Jahren). Jetzt müssen aufgrund von Änderungen neue Ziele für die Umleitungen definiert werden. Dies wurde in den Gruppenrichtlinien hinterlegt (Option exklusiver Zugriff ist deaktiviert, Option Dateien verschieben ist aktiviert). Beim User steht im Ereignisprotokoll unter Ordnerumleitungen, dass alle erfolgreich durchgeührt wurden. Beim Prüfen der Anzahl der Dateien gibt es aber teilweise große Unterschiede. Auf dem "Server-alt" sind mehr Dateien vorhanden, als beim "Server-neu" und das ohne Fehlermeldung. Es könnte teilweise eventuell an zu langen Dateinamen bzw. Ordnernamen liegen. Wie kann es sein, dass dann keine Fehlermeldungen erzeugt werden? Die Dateien werden außerdem nicht verschoben, sondern kopiert, so dass sie auf "Server-alt" auch noch vorhanden sind. Wie ist am Besten damit umzugehen, um sicherzustellen, dass alle Benutzer wieder alle ihre Dateien haben, ohne händisch für jeden Benutzer Verzeichnisse zu synchronisieren? Gruß Karl

Der Fehler konnte lokalisiert werden. Da nach der Wartezeit alles funktioniert hat, musste der Fehler wo anders liegen. Ein externes NAS mit Benutzeranmeldung hat in einem Skript für einen Timeout gesorgt - das wurde geändert und jetzt geht die Anmeldung wieder schnell. Gruß Karl

Immer bei diesen Benutzern. Nachtrag: Inzwischen ist es bei allen Benutzern - auch bei den neuen.

Hallo zusammen! Folgende Umgebung: Migration von Windows 2008 DC auf Windows 2012 DC (als Hyper V Host). Dabei wurden die Benutzerdateien und Benutzerprofile (servergespeichert) auf einen neuen DFS gelegt. 3 FSMO Rollen in der Domäne auf den neuen Server übertragen - die anderen beiden sind auf der übergeordneten Domäne. Der alte DC ist aus dem Domäne raus und offline. Die Rückstände sind auch aus den Standorten entfernt. netdiag /test:dns zeigt keine Fehler. Folgende Problematik: Die Anmeldung an einem Client mit einem migrierten (im AD vorhandenen) Benutzer dauert ca. 3 Minuten (es erscheint ein schwarzer Bildschirm, bevor der Desktop angezeigt wird). Danach wird der Desktop korrekt mit Hintergrund, Verknüpfungen etc angezeigt. Keine Fehler im Ereignis-Log. Wird ein Benutzer neu angelegt und hat dieser das gleiche Startskript, die gleichen Angaben bei dem Benutzerprofil und den Benutzerdaten geht die Anmeldung schnell. Auch das Löschen eines Profils eines migrierten Benutzers schafft keine Lösung. Was kann die Ursache sein? Vielen Dank Karl

Ja, das ist bei beiden der Fall.

Hallo RobertWi 1. Ja, der TMG hat das Zertikat der CA hinterlegt und vertraut dieser. 2. Die IP Adressen des TMG sind manuell eingegeben - sowohl die interne als auch die externe. Hinter dem TMG kommt noch einmal eine Appliance, die für den Internetzugang zuständig ist.

Hallo zusammen! Es soll eine Exchange 2010 OWA Seite über einen TMG 2010 veröffentlicht werden. Folgende Umgebung: Hyper V Server: Windows 2012 Core Host1: TMG 2010 auf Windows 2008 R2 Host2: Exchange 2010 SP3 auf Windows 2012 Die interne Seite von OWA lautet: mail.domäne.de (Exchange) Die externe Seite lautet: owa.domäne.de (TMG) Wobei beides im DNS Host A Einträge sind. Die Namensauflösung funktioniert korrekt. Der Aufruf vom TMG oder einem anderen Client aus auf https://mail.domäne.de/owa funktioniert. Wenn man dann versucht, die https://owa.domäne.de/owa aufzurufen, dann erscheint die Fehlermeldung: Seite kann nicht angezeigt werden. Beim TMG erscheint im Protokoll die Meldung: 0x80074e21 FWX_E_ABORTIVE_SHUTDOWN Das Zertifikat wurde von einer eigenen CA ausgestellt, die auch auf dem Exchange läuft. Der Name lautet: owa.domäne.de – dieses Zertifikat wurde sowohl bei Exchange ausgewählt – auch den Diensten zugeordnet, als auch im IIS und im Listener auf dem TMG. Bisher konnten wir keine Lösung für dieses Problem finden. Wie ist die beste Vorgehensweise? Die CAS Rolle wurde auch schon neu installiert. Danke und Grüße Karl