Jump to content

RackZack

Members
  • Gesamte Inhalte

    16
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von RackZack

  1. Hallo,

     

    ja prinzipell kannst Du das Upgrade verhindern wenn du die Rechner über den WSUS verwaltest.

    Allerdings haben die "normalen" Version nur einen begrenzten Supportzeitraum. Das heist, Du wirst für deine Pro Version relativ zeitnah dann keine Sicherheitsupdates mehr bekommen ohne auf eine höhere Version zu gehen.

    Die LTSB werden hier länger versorgt.

  2. Guten Morgen,

     

    der Eintrag wird eigentlich über die ADMX Vorlagen von Windows 10 1511 gesetzt. Waren die betroffenen Clients vorher Version 1511 und wurden aktualisiert? Waren die ADMX Vorlagen im Central Store vorher aus der Version 1511 mit der die GPO für Windows Update verteilt wurde?

    Wenn die Einstellung in den Vorlagen der Version 1511 gesetzt wurde und anschließend die Vorlagen auf Version 1607 oder 1703 aktualisiert werden, dann bleibt die Einstellung auf den Clients erhalten.

    Die neuen Vorlagen verwenden hier andere Einträge, daher wird dann hier auch die Einstellung nicht angezeigt. Mann müsste dann mit den "alten" Vorlagen die Einstellung wieder rückgängig machen.

     

    Gruß

  3. Gibt es unter HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate einen Eintrag mit "DeferUpgrade"? Wenn ja, dann diesen entfernen.

     

    Ansonsten hier vielleicht noch einmal reinschauen. https://docs.microsoft.com/de-de/windows/deployment/update/waas-configure-wufb


    Wir hatten bei uns das gleiche Verhalten, allerdings betraf es hier nur fünf Rechner. An den Rechnern waren jeweils an den oben genannten zwei Stellen die Einstellungen nicht korrekt. 

    Nach manueller Korrektur rufen sie nun auch wieder die Windows 10 1703 Updates ab. Der WSUS läuft auch hier unter 2012, also prinzipell funktioniert es mit den.

     

    Gruß

  4. Hallo Franz,

     

    danke für die Antwort.

    Auf dem Servern sind ausschließlich unsere eigenen Anwendungen installiert, Office, ect. sind nur auf den jeweiligen Arbeitsstationen installiert.

    Jeder Benutzer hat eine Windows CAL und eine RDS CAL.

    Aber alle Benutzer würden für die RDS Verbindung nur einen Benutzeraccount nutzen. Die restlichen RDS Lizenzen würden dann im Lizenzmanager als verfügbar darstellt und nicht genutzt werden.

    Das wäre dann so noch OK?

     

    Gruß

    Danny

  5. Hallo,

     

    ich bräuchte einmal eine Info ob dies lizenztechnisch noch sauber ist, oder eventuell ein Lösungsvorschlag.

     

     

    Wir haben mehre Entwickler, die eigene Software enwickeln und diese auch auf virtuelle Server testen. Da Sie ja auf den Servern arbeiten haben wir die entsprechende Anzahl an RDS User CALs beschafft sowie die RDS Rolle auf den Servern installiert und den Lizenzserver mit den Lizenzen eingerichtet.

    Jeder Benutzer kann sich mit seinen Zugangsdaten auf den Servern einloggen und der Lizenzserver zählt auch fein die User.

     

    Technisch gibt es nun aber das Problem, dass wenn mehrere Benutzer eingeloggt sind, sich gegenseitig die Anwendungen beenden oder zum Absturz bringen, weil diese in einer anderen Session eines anderen Benutzers schon liefen.

     

    Die Überlegung war nun, das alle Entwickler sich mit einen Account auf den Servern einloggen um zu sehen welche Anwendungen gerade laufen. Diesen Account würden wir auf eine Session begrenzen so das nicht mehrere geöffnet werden können. Es ist und klar, dass dann immer nur "einer" am Server arbeiten kann.

    Der Lizenzserver würde dann aber auch nur noch eine Lizenz immer Zählen.

     

    Wäre dieses von der Lizenzierung her noch im grünen Bereich, oder gibt es einen anderen Lösungsvorschlag?

     

    Gruß

     

    Danny

  6. Hallo,

     

    wir haben ca. 15 Testserver auf denen die Entwickler in Zukunft mit RDP arbeiten / testen sollen. Für diese Entwickler wollen wir die nötige Anzahl an RDS CALs beschaffen.

    Rein technisch gesehen reicht es uns, wenn auf diesen Servern die einfachen Remotedesktopdienste (ohne RDS Rolle) aktiviert sind, da nie mehr als zwei Entwickler gleichzeitig auf einen Server arbeiten.

    Die Frage ist aber, ob es lizenztechnisch noch sauber ist, wenn man hier zwar die Lizenzen hat, aber auf den Server die RDS Rolle nicht installiert.

     

    Gruß

     

    Danny

  7. Dann hoffe ich wenn sie den Fehler beheben auch wieder die Einstellung in den Gruppenrichtlinien "TPM-Sicherung in den Active Directory-Domänendiensten aktivieren" wieder zurückbringen.

    Diese gibt es nämlich seit Windows 10 1607 nicht mehr.

     

    https://social.technet.microsoft.com/Forums/en-US/c8ad5825-ecc7-4873-a2c0-d6b51789e12e/turn-on-tpm-backup-to-active-directory-domain-services?forum=winserverGP#

  8. Hallo Nils,

     

    ja OK das die PIN nicht für die ganze Domäne gilt sondern nur für den Rechner ist mir schon klar. Nur wenn ein Mitarbeiter mit seinen Notebook außerhalb arbeitet und sein Domänen Login auf diesen Notebook mit der Pin verknüpft hat ist das Mist. Er kann hier einfach vier Mal die Null wählen und sich damit in Zukunft an diesen Rechner anmelden.

    Aus meiner Sicht ist das nicht gerade sicher und schon gar nicht, wenn man dieses nicht unterbinden kann.

    Ist dir etwas bekannt, das man dieses mit zusätzlichen GPOs verhindern kann?

    Die GPO unter "Computerkonfigurtion\Administratve Vorlagen\System\Anmelden\PIN Anmeldung aktivieren" hat hier keine Wirkung, egal welche Einstellung.

     

    Gruß

     

    Danny

  9. Hallo,

     

    bei Windows 8.1 war die Anmeldung über PIN bei Domänen PCs standardmäßig deaktiviert. Alternativ konnte man dieses über GPOs wieder aktivieren.

    Bei Windows 10 habe ich das Problem, dass die PIN Anmeldung standartmäßig auch bei Domänen PCs aktiv ist und ich es über GPOs nicht deaktivieren kann.

    So kann ein Domänenbenutzer sein komplexes Kennwort einfach in eine vierstellige Zahl ändern und sich anmelden.

    Eventuell habe ich aber auch etwas übersehen. Könnte dieses mal bitte jemand überprüfen, ob das bei Ihm auch so ist?

    Vielen Dank im voraus.

     

    Gruß

×
×
  • Neu erstellen...