Jump to content

Sunny61

Expert Member
  • Gesamte Inhalte

    26.056
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Sunny61

  1. Betrifft es nur einen Benutzer oder alle? Hast Du alle beteiligten Terminalserver schon einmal neu gestartet? Auf Basis welcher OS-Version von Igel sind die Profile erstellt worden? Seit wann funktioniert es nicht mehr? Was wurde kurz vor dem Zeitpunkt geändert?
  2. Im ersten Bild ist bei uns das hier aktiv: Und hier die DCs eintragen: Und für das zweite Problem mach bitte einen neuen Thread auf, das verwirrt hier nur.
  3. Hast Du schon getestet ob es an 24H2 oder an KB5051987 liegt? Falls nein, dann wäre das der nächste Schritt das zu testen. Das ist eines der simpelsten Produkte von MS, ein klein wenig Geduld hilft immer.
  4. Ausprobieren hilft an der Stelle.
  5. Keine Nerven für einen WSUS oder für den Test? Hier rumpoltern ist auch nicht besser.
  6. Hast Du schon getestet ob es an 24H2 oder an KB5051987 liegt? Falls nein, dann wäre das der nächste Schritt das zu testen. Und wenn Du einen WSUS hast und DualScan abgeschaltet ist, hast Du in der Hand wann 24H2 installiert wird.
  7. Wenn ein Benutzer angemeldet ist, kann sich ja ein anderer anmelden, einfach nur anmelden. An der Konsole kann nur einer arbeiten. Wir hatten so auf einem PC mal 16 verschiedene User angemeldet, arbeiten konnte natürlich nur einer.
  8. Na dann weißt Du ja wie schnell du sein musst. ;)
  9. Gott sei Dank sind wir der Lage, für jede Rolle einen Server zu installieren. ;) Eine gewisse Zeit sollte RDP auch ohne Lizenzserver funktionieren, genaueres weiß ich aber nicht.
  10. Ohne es zu wissen, evtl. könnte ein Loadmaster von KEMP das sein, was ihr braucht.
  11. Der DC hat damit natürlich nichts zu tun. Du solltest den TS neu installieren.
  12. Einen TS sollte man mehrmals pro Woche neu starten. Bau dir eine Aufgabe und lass den Server Die, Do und So in der Nacht neu starten. Kontrollieren ob der Reboot auch erfolgt ist. Start > Ausführen > eventvwr.msc [ENTER] auf dem TS dann kommst Du ins Ereignisprotokoll. Hier findest Du sicherlich weitere Informationen. Bis jetzt, aber eben jetzt nicht mehr. Namen verwenden, und zwar vollständige, keine IP-Adressen. Servername.dom.tld
  13. Namen vom Connectionbroker eintragen, vergiss die IP-Adressen. Kannst Du das mit einem Server 2022/2025 verifizieren? Wann hast Du den TS das letzte mal neu gestartet? Und beantworte bitte die Fragen von @testperson, die sind nicht umsonst gestellt worden.
  14. Den Dienst NLA (Network Location Awareness) nach Herstellung der Verbindung einmal neu starten könnte helfen.
  15. Stimmt natürlich. :)
  16. Du kannst es natürlich so ähnlich wie bisher machen, das erfordert IMHO 2 Freigaben, einmal für die Normalos und einmal für die Testpersonen. Den Pfad zur Freigabe kannst Du ja auch in 2 verschiedenen GPOs eintragen, die dann eben die jeweils benötigten Mitarbeiter zugewiesen bekommen. Download immer in Freigabe 1. Du kopierst manuell in Freigabe 2, die bekommen die Testpersonen zugewiesen. Nach der Testphase kopierst Du in Freigabe 3, die haben die Normalos per GPO zugewiesen.
  17. Dann leere nochmal %windir%\Softwaredistribution und starte den Client neu.
  18. Das ist auch noch eine gute Alternative: https://www.mythicsoft.com/agentransack/
  19. Chocolatey in Kombination mit Ansible funktioniert recht gut. Haben wir hier für ein paar ganz spezielle Clients im Einsatz.
  20. @testperson Ansible fehlt noch in der Aufstellung. :)
  21. Den LUP: https://sourceforge.net/projects/localupdatepubl/ Code downloaden und anpassen, fertig.
  22. Einfach hinsetzen und selbst machen, ganz so einfach ist es. Ja, das einzige was sich geändert hat, sind die Befehle um ein W10 zur Mitarbeit zu zwingen. Da kann man sich aber mit eigenen Updates selbst behelfen. Aber ansonsten macht das Tool was es verspricht, nicht mehr und nicht weniger. Was nützt es wenn auf der gleichen Codebasis alle 3 Monate eine neue Build erstellt wird, sich aber kein Buchstabe im Code geändert hat. Genau, nichts nützt es.
  23. Du könntest hier mal anfragen: https://www.db-berater.de/
  24. Das ist nur zum Teil richtig. Wenn im GPO Policies eingestellt werden, dann werden die auf Standard zurück gesetzt. Sobald Du in einem GPO mit Preferences arbeitest, hast Du recht. Alles was Du in den Administrativen Vorlagen einstellst, ist nach dem Löschen des GPO wieder weg, alles was in Einstellungen gesetzt wird, musst du selbst wieder entsorgen. Du setzt einen Wert auf 1 und löscht das GPO, der Wert 1 steht immer noch drin. Du musst zuerst den Wert löschen und dann erst das GPO entfernen. https://www.gruppenrichtlinien.de/artikel/was-sind-gruppenrichtlinien Richtlinien (Policies) unterscheiden sich im Verhalten von Einstellungen (Preferences). Das ist einer der Gründe, warum sie auch im GP Editor als jeweils eigene Knoten in der Baumstruktur dargestellt sind. Du kannst das mit den Policies einfach selbst schnell testen. Auf einem Client ohne Domain GPEDIT.MSC aufrufen, z.B. eine Einstellung für den WSUS setzen, in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate nachsehen ob der Wert vorhanden ist. Jetzt aus GPEDIT.MSC die Änderung wieder entfernen, und schon ist es in der Registry weg. Genauso funktioniert es auch in der Domain, da nur mit gpupdate, übrigens ohne /force. ;)
  25. Funktioniert die Option 3 bei dir tatsächlich wie gewünscht? Wenn Du einem Client die GPO entfernst, kriegt er dann W11 angeboten? Außerdem ist der Installationstag auf Donnerstag gelegt, stell doch mal auf täglich um. BTW: Du kannst den Clients auch einen WSUS angeben, ohne dass die Clients die Updates beim WSUS holen müssen. Dann gibst Du die Updates frei und die Clients holen sich die Updates bei Microsoft Update.
×
×
  • Neu erstellen...