mwiederkehr

10 Cores und 32 GB RAM für 10 Benutzer tönt vernünftig. Wenn die Leute nur mit Office und einer schlanken Branchenanwendung arbeiten, rechne ich mit 0.5 Cores und 2 GB RAM pro Benutzer. Es ist aber leider so, dass Browser die letzten Jahre nicht sparen beim RAM, das sie sich genehmigen. Ein paar Tabs offen und man kommt auf über 1 GB pro Benutzer, nur für den Browser... Es kann deshalb nicht schaden, die Benutzer etwas zu sensibilisieren. Der Browser muss nicht gleich fünf Tabs mit allen Zeitungen aufmachen, die man dann doch nicht liest und auch Internetradio lässt man lieber lokal laufen. Das Surfen auf normalen geschäftlichen Seiten ist jedoch kein Problem.

Das sieht mir nach einem IPv6-Problem aus. Die Fritzbox bietet sich als DNS-Server an, was der Client gerne annimmt. Danach fragt er die Fritzbox statt den DC, welcher als DNS bei IPv4 eingetragen ist. Zeigt "ipconfig /all" IPv6-Adressen bei den DNS-Servern? Bei Windows 10 reicht "prefer IPv4 over IPv6" nicht mehr, man muss IPv6 deaktivieren. Würde es über die Registry machen und nicht einfach den Haken beim Protokoll rausnehmen bei der Netzwerkkarte: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows.

Das stimmt, aber den HTML5-Client gibt es noch nicht so lange. Warum RDG separat? Ich suche schon länger eine Lösung, um mehrere Server am gleichen Standort, aber in verschiedenen, getrennten Domänen bzw. Workgroups, anzubinden (Hoster). Das RDG ist ja auf eine Domäne limitiert. Für Adminzwecke läuft aktuell alles über einen "Jump-Host" mit RDG und 2FA und von dort aus dann intern weiter über RDP. Die Kunden selbst arbeiten per VPN. Es wäre schön, eine saubere Gateway-Lösung zu haben, ohne für jeden Kunden ein komplettes RD-Setup zu machen. Aktuell haben die kleinen Kunden nur einen Server (ohne Domäne).

Ja, aber es gab auch eine Lücke, die erst durch das Gateway ermöglicht wurde. Aber schon klar, habe ich verstanden. Oder mit den Ressourcen arbeiten, was ja quasi per Feed aktualisierte RDP-Dateien sind. Funktioniert auch ganz gut. Gutes Argument, das hatte ich so noch nicht bedacht, danke! Krass, das hätte ich so nicht vermutet. Noch eine letzte Frage: euch ist auch keine Firewall oder virtuelle Appliance bekannt, die ein RDP-Gateway integriert hat? Kemp macht nur TCP-Load-Balancing auf RD-Gateways, bei Citrix soll es gehen, aber nur in den teuren Versionen. Sonst habe ich nichts gefunden. Ausser Guacamole, aber das packt RDP dann gleich in HTML5. (Was für privat übrigens eine coole Lösung ist, falls ihr etwas Basteln wollt über die Feiertage.)

Danke für eure Antworten! Ja, es gab leider mehrere Lücken, wobei die soweit mir bekannt bei neueren Betriebssystemen nicht ausgenutzt werden konnten, wenn NLA aktiviert war. Deshalb hatte ich die Hoffnung, dass NLA die Komplexität des am Internet hängenden Codes soweit reduziert hat, dass er sicherheitstechnisch überschaubar ist. Der Webserver spricht ja auch mit dem Internet und wird nicht dauernd gehackt. Bei Farmen ist klar, dass alles über einen Gateway läuft. Der NetScaler kann die Anmeldungen direkt gegen das AD prüfen, noch bevor der potentielle Angreifer zu den Servern durchgelassen wird. Es ging mir mehr um kleine Umgebungen. Bei RDWeb mäkeln die Benutzer über fehlenden Komfort und VPN ist auch keine Freude, wenn die Leute von privaten Rechnern aus arbeiten sollen.

Hallo zusammen In der letzten Zeit hatte ich einige Diskussionen bezüglich "RDP über Internet" (für Terminalserver, nicht für Administrationszwecke). Die Bandbreite der Meinungen reicht von "geht gar nicht, nur über VPN oder man nimmt Citrix" bis "kein Problem bei neuen und aktuell gehaltenen Servern". Ich sehe folgende Risiken: 1. Passwort von Benutzer wird herausgefunden 2. Server wird durch Lücke in RDP "gehackt" 3. Kommunikation wird abgehört Punkt 1 ist sicher richtig, lässt sich aber durch starke Passwörter und allenfalls 2FA verhindern. Bezüglich Punkt 2 gab es in der Vergangenheit leider einige Vorfälle. Seit NLA kommt aber der komplexe und potentiell anfällige RDP-Code erst nach erfolgter Authentifizierung zum Einsatz. Punkt 3 sollte dank TLS kein Problem mehr sein. Wie seht ihr das? Ist RDP trotz aktiviertem NLA immer noch zu gefährlich, um es ins Internet geöffnet zu haben? Oder ist diese fixe Meinung überholt? Irgendwie wäre es eine Bankrotterklärung, wenn wichtige Dienste eines aktuellen Betriebssystems zu unsicher wären für den Zugriff über Internet. Selbst SMB macht man mitterlweile über Internet, siehe Azure. Vielen Dank für eure Meinungen!

Probiert da jemand Passwörter durch? Dann kann es vorkommen, dass man sich zeitweise nicht anmelden kann und die "interner Fehler"-Meldung erscheint.

Es gibt auch ein Tool für .NET, falls Dir das in eurer Umgebung lieber ist: https://unosquare.github.io/passcore/ Habe allerdings keine Erfahrung damit.

Dass bei MySQL der ganze Dienst abstürzt, hatte ich bisher nur bei korrupten Datenbanken. Was sagt denn die Logdatei? Die liegt im Data-Verzeichnis und heisst "%hostname%.err".

Schade. Es wurde ja schon länger eine Lösung versprochen und ich hatte die Hoffnung, etwas verpasst zu haben. Auf jeden Fall vielen Dank!

Doch, aber die lokalen Benutzer hätten keine Exchange-Attribute. Das Azure AD könnte also die Hoheit über diese Attribute haben, da es sie lokal im Schema gar nicht gibt. Deshalb dachte ich, es könnte evtl. anders gehen. Aber für ADSIEdit müsste das lokale Schema die Exchange-Attribute doch kennen? Also müsste ich im Minimum "/preparead" ausführen?

1.) Geschäftliche Sachen über den Browser auf dem TS, damit die Benutzer nicht immer zwischen lokal und TS umschalten müssen. Private Sachen wie Webradio, Stream von Tennismatch etc. lokal, um den TS zu schonen. 2.) Wenn Du keine richtige Farm willst, kannst Du evtl. pro Nutzerkreis einen TS erstellen. Wenn die Verwaltung eine Anwendung braucht, mit der sonst niemand arbeitet, kannst Du denen einen eigenen TS zur Verfügung stellen etc. Mehr als maximal drei solcher "Einzel-TS" würde ich aber nicht machen, dann lieber gleich eine richtige Umgebung.

Hallo zusammen Dass man einen lokalen Exchange zur Verwaltung braucht, wenn man bestehende Benutzer mittels Azure AD Connect synchronisiert, ist ja bekannt. Nirgends gefunden habe ich allerdings den Fall, dass man bei einer Neugründung auf der grünen Wiese anfängt und die Benutzer synchronisieren will. (Oder ich sehe den Wald vor lauter Bäumen bzw. Doku nicht mehr...) Also wie folgt: Firma mit ca. 100 Benutzern, welche (da das Unternehmen nur kleine Filialen und keinen Hauptsitz hat) auf einer gemieteten Terminalserver-Infrastruktur arbeiten werden. Es soll Office 365 eingesetzt werden und der Einfachheit halber sollen die Benutzerkonten aus der lokalen Domäne synchronisiert werden. Single Sign-On ist Pflicht, Password Writeback wäre schön, muss aber nicht sein. Braucht es da wirklich einen lokalen Exchange? Es wäre auch vorstellbar, die Benutzer in Azure AD getrennt anzulegen und einfach über ein gemeinsames Attribut zu "verknüpfen", so dass SSO geht. Welche der vielen Möglichkeiten würdet ihr empfehlen?

Ich habe nur einen ganz einfachen Tester, der nur auf Durchgängigkeit und Kurzschlüsse prüft (dieser ist es: https://www.conrad.de/de/p/kabeltester-laserliner-lan-check-netzwerk-1697325.html). Gebraucht habe ich den nur in den seltenen Fällen, in denen ich Dosen selbst montiert habe. Das war hauptsächlich privat. Den Durchsatz messe ich "praxisnah" mit iperf. Wenn es mal ein Problem gab, das der Durchgangstester nicht angezeigt hat, habe ich den Elektriker angrufen und der kam mit dem Fluke-Gerät. Kam aber noch nicht oft vor.

Ergänzend zu Jan: Mal mit einem anderen Browser getestet? Error 1006 wäre nämlich eigentlich ein clientseitiger Verbindungsabbruch.

Je länger der Key, desto länger dauert der Handshake für den Schlüsselaustausch. Der Unterschied zwischen 2048 und 4096 Bit ist messbar, aber nicht spürbar: https://expeditedsecurity.com/blog/measuring-ssl-rsa-keys/ Wenn Du nicht gerade den Load Balancer für google.com oder facebook.com betreibst, ist die Schlüssellänge bezüglich Performance nicht relevant.

Wenn Du im Browser die Developer Tools aufmachst, wie sieht der Fehler denn genau aus? wss ist WebSockets, irgendwo dort hat er ein Problem. Auf welchen Port versucht er zu verbinden? Ist der vom Client erreichbar?

Es sollte eigentlich schon funktionieren, aber ich muss zugeben, dass ich es noch nie probiert habe. Habe den Webclient erst an einem Ort im Einsatz und dort läuft er mit öffentlichem Wildcard-Zertifikat. Dort hat die Installation problemlos funktioniert. (Ist allerdings Server 2019, nicht 2016, aber das sollte keinen Unterschied machen.)

Beim Webclient ist eben speziell, dass der Server bzw. die RDP-to-HTML-Komponente auf sich selbst zugreift. Über RDWeb funktioniert es auch? Vertraut der Server selbst dem Zertifikat?

Kommst Du vom Server selbst auf "remote.domain.de"? Wenn das extern auflöst, könnte es ein Problem mit NAT-Loopback geben.

Vielen Dank für eure Antworten. Die Tablets sind iPads, das hätte ich genauer spezifizieren sollen. Der Kunde möchte die Dateien auf seinem Server belassen, um die Datenhaltung und -sicherung im Griff zu haben. OneDrive soll nur als "Frontend" für die Tablets eingesetzt werden. Der Kunde ist begeistert von OneDrive, weil damit Fotos vom Tablet einfach übertragen werden können. Dies wäre bei SharePoint nicht so einfach. Habe noch weiter gesucht und es scheint wirklich so, als sei das Szenario von Microsoft nicht vorgesehen. Temporär mache ich einen Abgleich (eine Richtung) per rclone. Laut einigen Berichten soll der Layer2 Cloud Connector geeignet sein. Werde das mit dem Kunden besprechen. Oder ich bekomme den Kunden doch noch dazu, das per Nextcloud zu machen. Das könnte direkt per SMB auf die Daten zugreifen und die Tablets könnten ihre Fotos mit der App hochladen...

Hallo zusammen Habe gerade eine Anfrage, für die mir keine schlaue Lösung einfällt: ein Kunde (Baufirma) hat Tablets gekauft für die Projektleiter. Nun wollen sie ihr Verzeichnis mit den Referenzfotos über OneDrive for Business auf die Tablets bringen. Man soll auch unterwegs Fotos machen können und diese dann im Büro auf dem Netzlaufwerk haben. Also: 2-Wege-Synchronisation zwischen Verzeichnis auf Fileserver und OneDrive. Das Problem: OneDrive kann nur Verzeichnisse aus dem Profil synchronisieren. Mittels mklink kann man da tricksen, aber laut diversen Quellen im Internet merkt er nicht zuverlässig, wenn eine Datei über eine Freigabe geändert wurde. Die Überwachung auf Änderungen läuft wohl nur in der aktuellen Sitzung. Privat arbeite ich mit rclone, aber für 500 GB Daten ist das wohl nichts, da der Abgleich zu lange dauert. Bei Synology ging es mit Cloud Sync. Kennt ihr eine ähnliche Lösung für Windows? Vielen Dank für eure Tipps!

VMs sind bei Azure tatsächlich sehr teuer, besonders, wenn sie 24/7 laufen. Wobei man für einen Vergleich mit anderen Anbietern schon den Rabatt für dauerhafte Nutzung einberechnen muss und der ist recht happig. Trotzdem bezahlt man für die Verfügbarkeit und Skalierbarkeit einen Aufpreis. Meine Kunden nutzen in Azure deshalb nur sehr selten VMs, sondern hauptsächlich andere Dienste wie DNS, Storage oder die (genialen und extrem günstigen) Functions. "Server betreiben" ist vom Konzept her halt nicht wirklich "Cloud". Sobald man Anwendungen hat oder entwickelt, die "serverless" laufen, ist man preislich in einer ganz anderen Region und kann die Vorteile der Cloud voll nutzen. Da Du SQL erwähnst: hast Du Performance und Preis von Azure SQL serverless angeschaut? Habe es noch nicht getestet, aber wenn die Leistung stimmt, könnte das preislich interessant sein. Besonders in Szenarien, in denen die Datenbank nicht dauernd viel zu tun hat, sondern nur stundenweise für Reports oder so.

Bei mir hat es nie länger als drei oder vier Tage gedauert, aber evtl. haben sie jetzt mehr Anfragen als normal. Ich wüsste nicht, wie man das beschleunigen kann (ausser natürlich, von Anfang an alle benötigten Daten vollständig einzureichen).

Du könntest den Host in die Domäne nehmen und auf dem Laufwerk eine Freigabe erstellen. Das ist aber keine gute Idee, ein Host sollte neben Hyper-V keine anderen Rollen ausführen. Sobald er das tut, brauchst Du für ihn auch eine Lizenz, sparst also nichts gegenüber einer weiteren VM. Dafür machst Du die Datensicherung komplizierter. In einer so kleinen Umgebung wäre es aber wohl auch vertretbar, die Daten direkt auf dem Terminalserver abzulegen.