Jump to content

mcdaniels

Premium Member
  • Gesamte Inhalte

    1.891
  • Registriert seit

  • Letzter Besuch

2 Benutzer folgen diesem Benutzer

Profile Fields

  • Member Title
    Board Veteran

Letzte Besucher des Profils

5.430 Profilaufrufe

Fortschritt von mcdaniels

Veteran

Veteran (13/14)

  • Passioniert Rare
  • 20 Jahre dabei! Rare
  • Immens engagiert Rare
  • Erste Antwort
  • Engagiert

Neueste Abzeichen

33

Reputation in der Community

8

Beste Lösungen

  1. Hi, perfekt - am Testrechner hat es schon mal funktioniert. Ich hätte ja wetten können, dass ich das bereits so gemacht hatte (manuell - ohne Script mit GPO), aber mit deinem Script und der GPO Ausrollung läuft das. DANKE!
  2. Hallo zusammen, ich habe hier einen Terminalserver aktiv, der über den FQDN angesteuert wird. SRV-TERMINAL.DOMAIN.LOCAL. Nachdem nun für .rdp - Verknüpfungen neue (und meiner Meinung nach sinnvolle) zusätzliche Sicherheitsrichtlinien gelten (CU April 2026), wirft das Öffnen der .RDP Verknüpfung zum Server eine Sicherheitswarnung. Vorsicht: UNBEKANNTE REMOTEVERBINDUNG Publisher: unbekannter Herausgeber Remotecomputer: Srv-terminal.domain.local Der Remotecomputer kann auf folgende Ressourcen dieses Computers zugreifen (Liste, die anzuhaken ist): Smartcards Webauth Zwischenablage Drucker Ich habe keine lokale Zertifizierungsstelle mit der ich z.B. über das AD Zertifikate ausstellen könnte und habe gelesen, dass die .RDP Verbindung signiert sein muss und der Fingerprint dann z.b. per GPO auf die Clients ausgerollt werden muss. Ich frage mich nun, wie ich das anstelle, wenn ich keine eigene CA habe. Ich hatte zuletzt versucht, ein auf meinem Client erstelltes Code Signing Zertifikat zu verwenden, um die .RDP Verknüpfung zu signieren und habe dann den Fingerprint (des Code Signing Zertifikats) auf meinen Client ausgerollt (GPO: Administrative Vorlagen\\Windows-Komponenten\\Remotedesktopdienste\\Remotedesktopverbindungs-Client\\SHA1-Fingerabdrücke) Das hat aber nicht geklappt. Die Meldung kommt noch immer. Gibt es hier eine empfohlene Vorgangsweise bzw. ein How To für "nicht so ganz Zertifikats-Affine"? Danke!
  3. @WeingeistDanke werde ich mal ausprobieren. Müssten die Drucker aber dann nicht zumindest via Word ansteuerbar sein? (Selbst wenn man sie in der tollen "Druckerverwaltung" nicht sieht).
  4. Ich hoffe ich verstehe deine Frage richtig: Ich gehe am Client auf: Systemsteuerung -> Hardware und Sound -> Geräte und Drucker Hier habe ich normalerweise von der Windows 10 Installation (vor dem Upgrade auf 11) ja Drucker angezeigt, die installiert sind. Jetzt fällt mir auf, dass z.B. nach dem Upgrade ein Drucker weg ist, der schon installiert war. Dann fängt das Spiel mit der Installiererei an, wie beschrieben.
  5. @Weingeist wenn es allerdings die Härtung wäre, dann würde es ja auf diesem Wege gar nicht funktionieren. Die Krux ist ja, dass der (verschwundene) Drucker nach Installation eines beliebigen anderen Druckers (auf gleichem Wege), plötzlich wieder da ist.
  6. Okay verstehe, weshalb es dann aber auf dem von mir beschriebenen Weg läuft, ist dennoch unerklärlich, oder?
  7. Hallo @zahni ich kann dir nicht ganz folgen. Was meinst du konkret damit - bezogen auf das von mir durchgeführte Windows 11 24h2 inplace Upgrade?
  8. Hallo zusammen, ich habe ein (aus meiner Sicht) sehr ominöses Problem. Ich betreibe einen Printserver (Server 2016). Auf diesem Printserver habe ich mehrere Netzwerkdrucker freigegeben. Bei einigen meiner Windows 11 24H2 Clients (nach einem inplace Upgrade von Windows 10) geschieht nun Folgendes: Zuvor vorhandene Netzwerkdrucker verschwinden aus der Druckerverwaltung. Wenn ich versuche, den (zuvor vorhandenen) Netzwerkdrucker via \\SRV-PRN --> danach Wahl des Druckers --> Kontextmenü "Verbinden" zu verbinden, bekomme ich die Meldung "Drucker nicht vorhanden". Wenn ich dann einen beliebigen anderen vorhandenen Drucker (der noch nicht verbunden ist) zu verbinden versuche, dann funktioniert dies meist. (In dem Fall kann das auch ein komplett anderer Druckertyp sein, wie der oben erwähnte Drucker). Nach dieser Aktion ist dann plötzlich der andere verschwundene Drucker auch wieder vorhanden. Was ich bereits versucht habe: Printserver neu starten Treiber am Druckserver aktualsieren & danach neu verbinden (=Drucker nicht vorhanden) Client durchstarten Druckspooler auf Client und Server neu starten Was grundsätzlich funktioniert: Drucker via IP direkt am Client installieren. Allerdings will ich das nicht in dieser Art installieren, denn ich fahre ja über den Druckserver. Habt ihr eventuell eine Idee? Danke!
  9. Guten Morgen, um die Sache nun zu einem Abschluss zu bringen: Nach weiterer Recherche und Studium der Logdateien auf dem NAS, habe ich nun festgestellt, dass offenbar die an der Außenstelle tätige externe Firma mit einem Client, der nicht zu unserer Domäne gehört - mit Namen HOME_DS (oh Wunder!) - alle Sekunden mit fehlerhaften lokalen (NAS) Credentials auf das NAS zugreifen will. Ich nehme an, das NAS (Da Domainmember) leitet diese Anfrage dann an unseren DC weiter.... Das also löste das Problem aus. Hab das NAS aus der Domain geworfen, bis die externe Firma das löst (jetzt ist Ruhe).
  10. Hallo, das war nicht das Problem. Hat sich bei mir einfach nicht geöffnet... Seite wurde halb geladen. Vielleicht hab ich auch schon zu viele Protokolle deaktiviert....
  11. Alles klar, dann hänge ich meine GPOs für LLMNR und MDNS auch an die DCs, in der Hoffnung, dass mir nix um die Ohren fliegt.
  12. Danke! Mal schauen was jetzt passiert... Sollte man diese grundsätzlich diese Protokolle auch auf den Servern abdrehen (MDNS LLMNR), oder ist das ev. in diesem Kontext nicht anzuraten?
  13. Hallo und danke, geht der Link bei dir normal auf? Bei mir nämlich nicht.
×
×
  • Neu erstellen...