Jump to content

Horstenberg

Members
  • Content Count

    128
  • Joined

  • Last visited

Posts 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. vor 43 Minuten schrieb NorbertFe:

    Naja das ist jetzt auch nicht zwingenderweise preiswerter und von sinnvoll (wegen doppelt) rede ich da gar nicht erst. Läuft man halt nicht klöppelserver von Tarox, sondern irgendwo bei den drei großen. Auch da kann man in die sch... greifen, aber zumindest ist der Support sehr genau geregelt. 

    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. vor 51 Minuten schrieb Nobbyaushb:

    Exchange 2019 hat schon nur noch 5 Jahre, ebenso wie Server 2019... es sei denn, ich lese das falsch raus...

    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).

     

    vor einer Stunde schrieb NorbertFe:

    Sehr pauschal. Keine Ahnung was du gekauft hast und welche umgebungsfaktoren zur Ablehnung führten.

    Wieso auch?

    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. vor einer Stunde schrieb NorbertFe:

    Also eigentlich sind bis zu 7 Jahre Support schon seit längerem üblich. Zumindest bei Dell.

    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. vor 8 Stunden schrieb NilsK:

    Moin,

     

    als "unzulässig" könnte Microsoft es nur bezeichnen, wenn es gegen Lizenzbestimmungen verstößt. "Nicht supported" bedeutet: wenn "sowas" gemacht wird, leistet der Hersteller keine Unterstützung dafür - typischerweise weder für Probleme, die direkt aus "sowas" entstehen (hier etwa: die Replikation funktioniert nicht), meist aber ausgedehnt auf jede Art von Problem, auch wenn sie nur sehr indirekt mit "sowas" zu tun hat (Beispiel: der Mailversand klappt nicht).

     

    Wenn man Lust hat, "sowas" dann selbst zu supporten, hält einen Microsoft nicht davon ab. Nur kann man dann eben nicht bei Microsoft anrufen, wenn was klemmt (um vorzubeugen: doch, kann man schon, die werden aber sehr bald das Gespräch beenden). Da ein solcher Zustand für die meisten Unternehmen indiskutabel ist, kommt "nicht supported" schon nah an "unzulässig" heran.

     

    Gruß, Nils

     

    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. vor 21 Stunden schrieb MurdocX:

     

    Hallo,

     

    deine Aussage ist technisch nicht richtig, deshalb auch nicht deine Schlussfolgerung. Ich zitiere von Microsoft: https://docs.microsoft.com/de-de/exchange/plan-and-deploy/virtualization?view=exchserver-2019

     

    Snapshots (Checkpoints) sind nicht "Application Aware". Die Windows Server Sicherung aber schon. Das ist ein großer unterschied :achtung:Daraus resultiert die Möglichkeit eines Datenverlustes und das erklärt auch warum Microsoft das nicht unterstützt. ;-)

     

    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. vor 43 Minuten schrieb testperson:

    Klingt jetzt aber doch so, als wäre ein dritter Host angesagt.

    Meistens fallen halt die Dinge, die ausgeschaltet bleiben können / unwichtig sind, genau dann aus, wenn sie ganz ganz dringend benötigt werden. ;)

    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. vor 6 Minuten schrieb Dukel:

    Auch bei Hyper-V Replica kann man die Maschinen verschieben. Bei der manuellen Tätigkeit gibt es keinen Datenverlust.

    Das ist übrigends keine Hochvefügbarkeit, das ist eine DR Lösung!

     

    Stimmt, das ist keine Hochverfügbarkeit. Es ist aber eine gute Fallback-Option, mit der ich seit Jahren gute Erfahrungen mache. 

    vor 4 Minuten schrieb Nobbyaushb:

    OT on - nicht für alles ist Replica zulässig! AD nein, Exchange nein, SQL unter bestimmten Voraussetzungen - OT off

    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. vor 1 Minute schrieb Sunny61:

    Was spricht gegen die Erstellung eines Clusters? Dann das ganze per PS-Script. Wartungsmodus einschalten, Maschinen werden verschoben, anschließend die WUA_SearchDownloadInstall.vbs passend aufrufen, schon wird automatisch gedownloadet, installiert und gebootet. Am nächsten Tag dann den zweiten Node aktualisieren.

     

    Und wenn die beiden Hosts wirklich das Rückgrat sind, solltest Du dir in Sachen Ausfallsicherheit etwas überlegen. Sind die Hosts mit den vorhandenen VMs denn ausgelastet oder kann 1 Host alle VMs hosten?

     

    Nett wie bei solch einfachen Fragen zu WU dann solche Konfigurationen zu Tage kommen.

     

    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. vor 3 Minuten schrieb testperson:

    Hi,

    Da hast du doch schon gemerkt, dass das teils ziemlich dürftig ist.

     

    Ich verstehe aber auch so wirklich das Problem nicht:

     

    Host1 -> Wartungsmodus an -> Update (auch wenn es x Stunden dauert) -> Reboot (ggfs. nochmals Updaten) -> Wartungsmodus aus -> "Test" -> "zurück in Produktion" -> "Warten" -> Mit Host2 vorne anfangen.

     

    Wenn euch die Zeit ohne Redundanz zu lange ist, dann muss eben ein Host3 her.

     

    Gruß

    Jan

    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. vor 5 Minuten schrieb Sunny61:

    Wir haben ein GPO das die Updates um 3 Uhr in der Nacht installiert. Die Server werden tagsüber in eine Gruppe auf dem WSUS verschoben, für die die Updates zur Installation freigegeben sind. In 99% der Fälle funktioniert das Installieren der Updates auch auf W2016 damit problemlos. Wenn ihr Hyper-V Hosts im Cluster habt funktioniert die Vorgehensweise mit der Installation in der Nacht AFAIK ebenfalls.

    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.


  12. 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


  13. vor 11 Stunden schrieb daabm:

    Ich bin voll bei den beiden Norberts :-) Makros gehören deaktiviert (nur signierte zulassen), und Applocker sollte dringend aktiviert sein. Notfalls SRP - die c't stellt da was halbwegs brauchbares bereit...

    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?


  14. vor 22 Stunden schrieb NorbertFe:

    Ich bezog mich auf "müßte gehen". Denn das ist ja eben das Problem mit den nicht VL Lizenzen seit O2013, dass wie oben geschrieben die Policies Zweige nicht ausgewertet werden und ein Import per Reg dann eben nicht zum Verbot führt, sondern zu einer Einstellung, die der Nutzer ggf. auch einfach wieder ändern kann. Der Rest bzgl. deiner Aussage und diversen Softwareherstellern ist mir auch schon begegnet und man fragt sich, ob die in den letzten 10-15 Jahren irgendwo unterm Stein gewohnt haben bzgl. Sicherheit und moderner Software.

    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?


  15. vor 3 Stunden schrieb NorbertFe:

    Nein eben nicht, weil diese Office Versionen eben die /policies Zweige nicht auswerten in denen ein User nicht schreiben darf. Also bleibt bei Office nur die registry im User hive und rate mal, wer da schreiben darf. Aber muss ja immer alles billig sein. ;)

    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. 

    vor 4 Stunden schrieb Sunny61:

    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?


  16. vor 9 Stunden schrieb Nobbyaushb:

    Wenn du nur via VPN Zugang zulassen willst, warum dann nach extern veröffentlichen?

     

    Dicht und gut.

    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?

    vor 10 Stunden schrieb xrated2:

    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...