Jump to content

Horstenberg

Members
  • Content Count

    128
  • Joined

  • Last visited

Everything posted by Horstenberg

  1. Was sagt die Remotedesktop-Lizenzierungsdiagnose? Selbst wenn der Lizenzserver scheinbar überall richtig registriert ist, muss man dies noch in den Einstellungen des RD-Servers vornehmen. Hierzu etwa folgender Link: https://social.technet.microsoft.com/Forums/de-DE/0a044565-4585-4b43-80cc-d6f08077d082/remote-desktop-server-terminal-server-lizensierung?forum=windowsserver8de Ist nirgendwo dokumentiert, ich musste dies aber schon mehrfach so machen, zuletzt sogar unter Windows Server 2019.
  2. Nach sechs Jahren ist es jetzt tatsächlich preiswerter, insbesondere, wenn es jetzt noch ein paar Jahre läuft. Das war aber nicht mein Ziel. Ich beschäftige mich halt gerne mit Computern, mit der Hardware, der Software und der Programmierung, so als Hobby. Da ist eine Bastlerlösung halt interessanter. Manche haben zu schnelle Autos; das brauche ich glücklicherweise nicht.
  3. Mir geht es um den erweiterten (extended) Support. Windows Server 2019 hat extended Support bis Januar 2029. Scheint mir ein guter Deal zu sein. Exchange 2019 hat extended Support nur bis Oktober 2025. Gegenüber Exchange 2013 (extended Support bis April 2023) gewinne ich damit also nicht viel. Deswegen warte ich auf Exchange 20XX, es sei denn, die auch nicht mehr ganz zuverlässige Exchange/Outlook Support-Matrix ändert sich (was etwa sein kann, wenn Exchange 2013 nicht mehr mit Outlook 365 zusammenarbeitet). Mir wurde 2010 über ein Systemhaus ein Server von Tarox verkauft. Wenn ich mich recht entsinne (ist lange her und ich will auch niemandem Unrecht tun!), war dann 2013 eine Verlängerung des Server-Supports nicht mehr möglich, den Grund dafür weiß ich nicht mehr. Das führte bei mir zu Zorn (?!) und dem Entschluss, mich davon nicht mehr abhängig zu machen. Daher entwickelte ich die Strategie "kaufe überdimensionierte Hardware, das auch noch zwei Mal, habe weitere Ersatzteile bei Dir und spare Dir den Support". Das ist zum Nachmachen natürlich nicht empfohlen, aber es funktioniert bei mir bestens. Ein Problem kann ich eigentlich nur bekommen, wenn beide Motherboards gleichzeitig abrauchen. Für die Festplatten, Raid-Controller, Netzteile usw. habe ich Ersatz vor Ort (den ich selbst einbauen kann). Nach sechs Jahren hat sich die Investition übrigens mehr als gelohnt. Bis auf Ram-Erweiterungen und ab-und-an Festplatten-Defekte war sechs Jahre nichts. Ist aber als Bastellösung nur Leuten zu empfehlen, die gerne an Computern schrauben (wie mich).
  4. In 2010 habe ich Server gekauft mit 3 Jahren Support. Naiv wie ich war, wollte ich den 2013 verlängern, was natürlich verweigert wurde. Darüber habe ich mich geärgert, deswegen habe ich in 2013 meine eigene Lösung geschaffen: Zwei Mal die exakt (nahezu) exakt gleiche Hardware, komplett überdimensioniert, die aufeinander repliziert, so dass ich notfalls mit einem Server weitermache, wenn der andere abraucht. Hat mir gute Dienste geleistet. Eigentlich war für 2019 neue Hardware geplant, zusammen mit einem neuen Exchange. Bei 2019 hat mich aber der verkürzte Lifecycle enttäuscht, so dass ich jetzt auf Exchange 2022 warte (so es diesen geben wird) und die für diesen geltenden Hardware-Anforderungen. Die beiden Server aus 2013 laufen weiter brav, Ersatz-Festplatten habe ich zur Genüge bei mir liegen. Läuft also alles. Backups habe ich zur Genüge. Es bleibt also va das Risiko, dass beide Server innerhalb kurzer Zeit mit Hardware-Defekt abrauchen, ohne dass ich zwischenzeitlich Ersatz bekomme. Damit kann ich leben. P.S. Dass das jetzt alles OT ist, ist für mich völlig in Ordnung. Meine Ursprungsfragen hat man mir ja vollständig beantwortet.
  5. Eine Lösung wie die Hyper-V-Replication von Exchange wird Microsoft wohl schon deshalb nicht supporten, weil es für Microsoft total uninteressant ist. Interessant ist das nur für kleinere Umgebungen, die Microsoft ohnehin in die Cloud schieben möchte. Größere Umgebungen sollen das über DAG lösen, was ja sicherlich auch besser ist als Hyper-V-Replication. Jede kleinere Umgebung, die alles On-Premises lösen will, muss gucken, zu welchen Kompromissen man bereit ist. Da kann es manchmal erwägenswert sein, auch einen Weg zu gehen, bei dem es keinen Support von MS gibt. Übrigens an alle ein herzliches Dankeschön für die Beiträge hier! Die Hyper-V-Server habe ich jetzt auf Windows Server 2019 umgestellt, da die Lizenzen ohnehin da waren. Ich hatte etwas Bedenken, WS 2019 auf recht betagter Hardware zu installieren (sechs Jahre alt). Gefühlt war die Installation von WS 2019 aber sehr unproblematisch und problemloser als die vieler anderer früherer WS-Versionen. Und die Updates laufen plötzlich ziemlich schnell.
  6. ok und Danke für die Info. In irgendeinem Blog hatte ich mal gelesen, dass das mit der Replikation von Exchange in Hyper-V klappen kann, seit es Production-Checkpoints gibt. Zur Nachahmung war es aber sowieso nicht empfohlen.
  7. In den meisten Fällen dürftest Du damit Recht haben. Das Ausfallen eines physischen Hosts wäre bei uns dadurch zu kompensieren, dass im Wesentlichen nur die VMs, die für den Remotezugriff "zuständig" sind, ausgeschaltet bleiben. Das ist bei uns nicht systemkritisch und hat nur für wenige User Folgen. Das könnten wir tatsächlich verschmerzen.
  8. Stimmt, das ist keine Hochverfügbarkeit. Es ist aber eine gute Fallback-Option, mit der ich seit Jahren gute Erfahrungen mache. Stimmt. Da man für die Replikation ohnehin doppelte Lizenzen braucht, habe ich auf jedem Host einen DC (mit AD und DNS), die ohnehin aufeinander replizieren. Zum Exchange habe ich backups und eine separate Maschine mit Mailstore. (Stimmt, ist jetzt aber echt OT). Übrigens: Für Exchange ist Hyper-V-Replication nicht "unzulässig", es ist "nicht supportet". Das heißt nicht, dass es nicht funktioniert (und technisch müsste es es funktionieren, jedenfalls, seit Production-Checkpoints repliziert werden, das habe ich aber noch nicht probiert. Windows-Server-Backup sichert den Exchange auch nicht anders, und das funktioniert nun nachweislich gut.).
  9. Die beiden physischen Hosts sind hardwaretechnisch fast identisch. Ausfallsicherheit besteht durch Hyper-V-Replication, mit der die wichtigsten Server-VMs jeweils auf den anderen Host repliziert werden. Wenn ein physischer Host ausfällt, müssten ein paar VMs "ausgeschaltet" werden, die zentralen Dingen laufen dann aber dann auf dem verbleibenden Host weiter (DC, AD, Printserver, Exchange, Fileserver). Klappt bislang alles so ganz gut, immerhin seit ca. 6 Jahren ohne größere Probleme. Ist mehr so Hochverfügbarkeit und Clustern für Arme, angesichts der geringen Größe des Netzwerks aber akzeptabel.
  10. Vielleicht ist das aus Deiner Sicht kein Problem. Es dauert aber stundenlang. Das nervt, deswegen habe ich hier einmal in die Runde gefragt. Mit WS 2019 ist das Ganze vielleicht in 30 Minuten erledigt. Das ist dann ein Vorteil. Darum geht es mir, ob ein Upgrade der Hosts sinnvoll ist. Jetzt einen dritten Host anzuschaffen, wäre angesichts der Größe unseres Netzwerks übertrieben (und ist hier auch ziemlich OT).
  11. Das mag sein. Mir geht es hier um das Update-Verhalten von WS 2016.
  12. Wir haben zwei Hyper-V-Hosts, die sind sozusagen das Rückgrat der gesamten IT. Die würde ich nur ungern unbeaufsichtigt nachts updaten und neustarten.
  13. Hallo an alle, das Update-Verhalten von Windows Server 2016 erlebe ich als fast schon unerträglich. Allein der Download der monatlichen Updates dauert (nach Anzeige) über eine halbe Stunde, dazu kommen (gefühlt) ewige Installations- und Neustartzeiten. Das Thema ist auch schon an einigen Stellen thematisiert worden, zB https://social.technet.microsoft.com/Forums/en-US/7b412a7a-3377-46f7-95f8-cd42d24451a0/windows-server-2016-updates-slow?forum=ws2016 https://social.technet.microsoft.com/Forums/en-US/250914a1-b013-434a-baa0-639e31a839dd/whats-with-the-really-slow-windows-updates-on-2016?forum=ws2016 https://www.heise.de/newsticker/meldung/Windows-Server-2016-Update-Installation-braucht-Geduld-4316646.html Hinzu kommt bei mir noch das folgende Phänomen: Wenn das quälend langsame monatliche Update eingespielt ist (im Juli etwa KB4507460), dann fordert WS 2016 direkt noch einmal die Installation weiterer Updates (im Juli etwa (KB4507459). Fast jeden Monat das gleiche. Resultat ist wieder die gleiche, ewig lange Prozedur. Das nervt extrem. Weiß jemand, - ob es hierzu bald von Microsoft eine Lösung gibt? - ob ich etwas falsch mache? - ob insbesondere der doppelte Update-Aufwand durch zwei Kumulative Updates im Monat vermeidbar ist? Nerven tut dies natürlich insbesondere auf den Hyper-V-hosts. Hat jemand Erfahrung mit WS 2019 als Hyper-V-Host? Ist es dort besser? Danke für jede Hilfe! -- Gruß, Horstenberg
  14. Nach den vielen Tipps hier habe ich mich auch auf die Suche nach guten Artikeln zu SRPs gemacht. Mir hat - neben den Artikeln in der c't zu Restric'tor - bei der Einrichtung von GPOs dieser Artikel gut geholfen: https://trustedwindows.wordpress.com/2016/12/21/software-restriction-policies/
  15. Übrigens mal einen herzlichen Dank an Euch alle. Die Diskussion hier hat mich sehr weitergebracht und wird unser Netzwerk sicherer machen. Danke!
  16. Was heißt das? Wenn ich auf Windows Server 2016 eine entsprechende GPO kreiere, dann wird Applocker auf dem Win 10 Pro Client aktiviert?
  17. Applocker ist ein attraktives Tool, das stimmt. Nach meinen Recherchen muss auf dem Client aber Windows 10 Enterprise installiert sein. Oder stimmt das nicht mehr?
  18. Ok, dann habe ich es jetzt verstanden. Ich habe jetzt noch einmal mit dem Softwarehersteller Kontakt aufgenommen, dass er die Makro- und VBA-Sicherheit in Angriff nehmen soll. Mal sehen, ob es was bringt. Ich fasse mal zusammen, was ich aus dem Thread gelernt habe: 1. Es ist sinnvoll, das Remote Desktop Gateway hinter einer Firewall zu verstecken, insbesondere keine Portweiterleitung auf dieses zu machen. Die Nutzer müssen sich dann vorab per VPN einloggen, um an das Gateway zu gelangen. 2. Das VPN gehört eher auf die Firewall als das man es über eine Windows-Server-Maschine bereitstellt. Grund: Auch im Falle eines erfolgreichen Angriffs kann der Intruder dieses nur schwerer manipulieren, weil er die Firewall-Credentials nicht hat. 3. Bei Office im Unternehmensbereich empfehlen sich unbedingt Volumenlizenzen oder solche O365-Versionen, die über GPOs steuerbar sind. Dies kann im Einzelfall die Ausführung schädlichen Codes verhindern, wenn man über GPOs Makros und VBA entsprechend deaktiviert. Oder ist was falsch daran?
  19. Dennoch würde ich vermuten, dass es professioneller betreut sein dürfte als manch anderes, das von Emotet heimgesucht wurde.
  20. Wenn sich der Computer, von dem ich RDP mache, in einer anderen Domäne befindet (und an einem anderen Standort), und ich verbinde mich mit VPN, brauche ich dann kein Gateway?
  21. Ich glaube, ich verstehe Dich nicht vollständig. Wir sind auf einen Softwareanbieter angewiesen, der die gesamte Infrastruktur für die Texterstellung usw. bereitstellt und uns so auch zu bestimmten Einstellungen im Office zwingt. Einer von zwei oder drei Softwareanbietern in unserem Berufszweig, das hat nichts mit Kosten zu tun. Die anderen Anbieter sind jedenfalls meiner Meinung nach schlechter. Beispiel, was vor ein paar Tagen passiert ist: Ein Update dieses Herstellers erforderte auch, dass ein lokales Update im Office eines jeden Mitarbeiters eingespielt wurde. Dafür musste "temporär" dem VBA-Projekt vertraut und die Makro-Sicherheit heruntergestellt werden. Gestern habe ich mal wieder alle Maschinen durchgeguckt: An nur einem Arbeitsplatz war dann wirklich alles wieder zurückgestellt (nur signierte Makros und VBA-Häkchen weg). Bei allen anderen Arbeitsplätzen waren die Sicherheitseinstellungen im Office katastrophal. Der Kampf um Office-Sicherheit ist in solchen Umgebungen ein Kampf gegen Windmühlen. Wenn ich das mit Geld lösen könnte, ich würde es tun. Deswegen werde ich zB beim nächsten Mal Office über eine Volumenlizenz kaufen, wegen der GPOs. Ich kaufe auch zB immer mehr Windows-Server-Lizenzen, um die einzelnen Prozesse zu isolieren, auch wenn wir nur 10 Mitarbeiter haben. Ok. Dann habe ich jetzt folgende Idee: Bislang ist bei uns der Web Application Proxy zusammen mit dem Remote Desktop Gateway auf einer (virtuellen) Maschine. Das ist die Maschine, auf die der Port 443 geworwarded wird. Idee jetzt: Ich nehme das Remote Desktop Gateway von dieser Maschine runter. Das installiere ich dann auf einer neuen virtuellen Maschine, die dann ohne geforwardeten (?!) Port im Netz ist. Dann wäre das Remote Desktop Gateway von Außen gar nicht mehr erreichbar, sondern nur nach VPN-Login. Klingt gut?
  22. ja, das müsste gehen. In vielen Unternehmen kannst Du das aber nicht machen, weil die auf unsignierte Makros usw. zwingend angewiesen sind.
  23. Mit den GPOs, die vor ca. einem Jahr online waren, hatte ich es probiert. Die GPOs wurden von den bei uns installierten Home&Business-Office-Versionen nicht verarbeitet. Also habe ich alle Einstellungen von Hand machen müssen.
  24. Ich will nach dem Motto vorgehen: Never change a running system. Wenn ich im RDP gateway nur den "Haken" bei der Veröffentlichung über Port 443 wegnehme, scheint mir alles getan zu sein. Jeder andere Zugriff von extern scheitert ja schon an der Firewall. Oder mache ich da einen Denkfehler? Verstehe ich das richtig und sollen die in dem Artikel verlinkten GPO-Templates auch für Office-Versionen gelten, die nicht über Volume Licensing erworben wurden? Das wäre in der Tat ein Fortschritt.
×
×
  • Create New...