mwiederkehr

Wir haben einen ganz normalen Terminalserver installiert. (Bei uns war es nur einer, bei grösseren Institutionen werden es mehrere sein, entweder mit Windows Remote Desktop Services oder zusätzlich mit Citrix XenApp.) Die Clients für die Schüler sind Thin Clients. Das ist vergleichbar mit einem Windows mit automatischer Anmeldung und der RDP-Verknüpfung im Autostart. Die Lehrer haben ebenfalls eine RDP-Verknüpfung bekommen. (Der Server ist extern nicht erreichbar, da der kostenlose Internetzugang diese Möglichkeit nicht bietet. Ansonsten hätte man ein Web Interface in Betracht gezogen.) Wie bereits erwähnt: ein Terminalserver für eine Schule ist identisch mit einem Terminalserver für eine Firma. Nur die Lizenzen sind günstiger.

Als Ergänzung: Mit DHCP Policies sollte das gehen, die gibt es aber erst ab Server 2012. Falls die Telefone nur Kontakt zu bestimmten Hosts/Netzen aufnehmen, könnte man auf dem "primären" Gateway auch eine Route eintragen oder die Route gleich per DHCP verteilen. Getrennte Netze sind aber sicher die beste Lösung, auch bezüglich Sicherheit.

Für Schulen gelten (bis auf die Lizenzkosten) die gleichen Vor- und Nachteile eines Terminalservers wie für alle Unternehmen. Je nach Anwendungen muss man ein Augenmerk auf die Audio-/Video-Performance legen. Je nach Schulstufe üben die Schüler Videoschnitt und da ist ein Terminalserver dann kein Vorteil. Wir setzen an einer Schule seit Jahren auf eine Terminalserverlösung und sind zufrieden damit. Der Grund für den Terminalserver waren nicht alte Clients, sondern diverse Lernprogramme, für die es keine Installationspakete gibt. Die manuell auf einem Server zu installieren ist einfacher, als sie zu paketieren und auf den Clients auszurollen. Zudem sind Lehrer häufig starke Vertreter von BYOD, um es mal milde auszudrücken.

Wir haben mit PDQ gute Erfahrungen gemacht. Ist weit weniger komplex als der SCCM und kommt ohne Client aus. Die Kosten sind überschaubar, da man nach Admins lizenziert. Als grossen Vorteil empfinde ich die umfangreiche Bibliothek mit fertigen Paketen. Man muss so nicht bei jedem Tool raussuchen, ob der Parameter jetzt "/q", "/silent" oder was auch immer heisst. Man kann damit auch Windows Updates verteilen, die monatlichen Sicherheitsupdates sind in der Bibliothek drin. Updates für Office etc. muss man sich aber selbst zusammensuchen. Hier würde ich der Einfachheit halber beim WSUS bleiben.

Wenn die User auf dem Desktop des Terminalservers arbeiten, müssen sie sich am PC nicht personalisiert anmelden. Ein generisches Login (mit kleinem Profil) reicht. Falls die Rechner auch dafür zu langsam sind: es gibt Linux-Distributionen, die per USB-Stick gebootet werden und aus einem PC einen Thin Client machen. Der User beginnt dann gleich am Anmeldebildschirm des Terminalservers.

Jetzt wo Du es sagst... Bei Windows 2003 gab es ein Feature namens "Internet Printing". Da hatte man eine Website, über welche man die Drucker verbinden konnte. Siehe https://support.microsoft.com/en-us/help/323428/how-to-configure-internet-printing-in-windows-server-2003. Die Rolle gibt es soweit ich weiss auch bei aktuellen Versionen noch. Nur weiss ich nicht, ob das Verbinden noch funktioniert oder ob das damals etwas mit ActiveX oder so war, das nicht mehr unterstützt ist in neuen Browsern.

Bei einer grösseren Umgebung haben wir das mit einem Anmeldescript (PowerShell) gelöst. Es schaut, in welcher OU der Client ist und verbindet die entsprechenden Drucker. Welche es verbinden muss, erkennt es am Namen: Ist der Client in der OU "Zentrale", verbindet es alle Drucker, deren Name mit "Zentrale" beginnt. So kann ein User an verschiedenen Standorten arbeiten und hat immer die richtigen Drucker. Nachteil: Immer alle Drucker neu zu verbinden braucht Zeit. Wir haben dann das Script erweitert, dass es nur noch fehlende Drucker verbindet und überflüssige löscht. Dadurch ist das Script recht gross geworden, aber man muss es ja nicht mehr anpassen. Die Lösung von zahni ist auf jeden Fall besser. Man spart nicht nur Papier, sondern löst auch Datenschutzprobleme mit rumliegenden vertraulichen Dokumenten. Habe das schon ganz elegant gesehen: jeder User hat einen Chip, welcher die Eingangstüre öffnet, den PC entsperrt und die Dokumente aus dem Drucker lässt. Geht der User zum Drucker, wird automatisch der PC gesperrt. Liegen lassen kann er den Chip abends nicht, sonst kommt er nicht aus dem Parkhaus. Für so eine Lösung kann man mit der Sicherheit argumentieren, vielleicht stösst man da bei der GL auf offene Ohren.

Bezüglich Legalität gilt es zwei Aspekte zu betrachten: - Strahlung: Herkömmliche WLAN-Bridges haben nicht mehr Sendeleistung als ein normaler Access Point. Von daher braucht es keine Genehmigung. (Man darf ja auch einen Access Point in den Garten stellen.) - Baurecht: Hier kommt es auf die Gemeinde an, ob es eine Bewilligung braucht. Bei uns sind Rundantennen ("Satellitenschüsseln") mit einer Fläche bis 0.5m2 sowie Stabantennen bis 1m Höhe nicht bewilligungspflichtig, es sei denn, das Gebäude steht in einem schützenswerten Ortskern oder ist im Denkmalschutzinventar verzeichnet. Man hat häufig eine falsche Vorstellung der erforderlichen Sendeleistung. Mit den erlaubten 200mW kommt man mit guten Richtstrahlantennen problemlos mehrere Kilometer weit. Ubiquiti gibt für die LiteBeam 5km an. Maximal im Betrieb gesehen habe ich etwas mehr als einen Kilometer und das läuft problemlos. Für 300m reicht sogar evtl. eine gute Antenne am Haus. Dank guter Empfangsverstärkung sollte auch ein schwaches Signal vom Notebook im Garten zur Antenne am Haus reichen. Versuchen könnte man es mit einer NanoStation. Habe das mal nach der Installation der Richtantenne auf einer Seite probiert: das Notebook konnte sich ca. 300m entfernt ins WLAN einloggen. Muss man aber ausprobieren, kommt auf das Gerät an.

Wenn Du nur in ein paar Tabellen schauen willst, könnte HeidiSQL reichen. Für "richtiges" Servermanagement oder die komfortable Erstellung von Abfragen etc. kommst Du um das Management Studio nicht herum.

Ein "vollständiger" Mailserver (also mit Postfächern, Webmail etc.) ist nicht so einfach. Aber wenn eine Weiterleitung an die privaten E-Mailadressen der Schüler reicht, tut es schon ein Postfix oder sogar ein ordinäres Webhosting. (Falls man die Domäne "schule.de" für andere Mailkonten braucht, könnte man die Subdomain schueler.schule.de einrichten.) Falls die Schüler unter den Adressen auch mailen können müssen, ist mein Vorschlag natürlich unbrauchbar.

Falls es nur um Weiterleitungen in der Form "hans.muster@schule.de" nach "hans95@gmx.de" geht, könnte man es mit einem simplen Mailserver ohne Postfächer lösen. Sind die privaten Mailadressen der Schüler in der Schulverwaltungssoftware erfasst? Falls ja, könnte man jedes Schuljahr eine Liste "$vorname.$name@schule.de $privateAdresse" exportieren und auf dem Mailserver importieren.

Du hast das DataGridView wahrscheinlich an eine DataTable gebunden. Dann kannst Du Änderungen speichern, indem Du die DataTable über den DataAdapter zurück in die Datenbank schreibst. Auf https://khanrahim.wordpress.com/2010/04/13/combobox-with-datagridview-in-c/ ist ein Beispiel zu finden, inkl. ComboBoxen mit Daten aus anderen Tabellen. Falls Du etwas mehr als nur simple Datenauflistung und -bearbeitung machen willst, rate ich Dir, ein besseres Grid einzukaufen, zum Beispiel von Telerik: https://www.telerik.com/products/winforms/gridview.aspx. Das DataGridView ist recht limitiert in seinen Möglichkeiten.

Wenn die Dateien noch nicht überschrieben wurden, kann ein Tool wie Recuva helfen. Meiner Erfahrung nach wurden verschwundene Ordner aber meist nicht aus Versehen gelöscht, sondern irrtümlich verschoben. Hast Du schon mal danach gesucht?

Vermutlich routet der Router nicht nur, sondern macht auch NAT. Dann sind die Hosts dahinter "versteckt" und nicht ohne Weiteres erreichbar vom WAN her. Du solltest das NAT in den Einstellungen deaktivieren können.

Als Ergänzung: Der hMailServer ist ein kostenloser Mailserver für Windows, der Postfächer per POP3 und IMAP zur Verfügung stellen kann.

Die Authentifizierung geht nur über Kerberos (in Domäne) oder über Zertifikate (ohne Domäne). Es gibt leider keine Möglichkeit, einfach Benutzername/Passwort für die Replikation einzutragen.

Ja. Das solltest Du in der Konfiguration des Switches sehen. Standardmässig haben alle Ports VLAN 1 untagged.

Tagged, weil die Pakete aus dem Gast-WLAN ja vom Access Point VLAN 10 zugewiesen bekommen. VLAN 1 bleibt untagged bestehen, somit kommt Client1 immer noch raus. "Kein VLAN" ist quasi VLAN 1. Wo VLAN 1 rauskommen soll, müssen die Ports Mitglied sein. Soweit ich weiss können alle USGs VLAN. Habe das jedenfalls schon auf kleineren Modellen als der 310 konfiguriert. Es gibt dann pro VLAN einen virtuellen Port, den man ganz normalen Zonen hinzufügen etc. kann.

Angenommen, das Gäste-WLAN ist VLAN 10 und die Firewall unterstützt keine VLANs (weshalb Du einen zweiten Port verwendest), wäre die Switchkonfiguration wie folgt: SW1, Port 1: VLAN 1 untagged, VLAN 10 tagged SW1, Port 5: VLAN 10 untagged Der Rest bleibt ja im Default-VLAN 1.

Wenn ein Client in einer Domäne ist, wird er von der Organisation verwaltet und nicht mehr vom Benutzer. Domänen-Admins können sich auf alle Dateien Zugriff verschaffen. Nicht einmal EFS hilft, da der Administrator standardmässig als Data Recovery Agent eingetragen ist. Man muss den Domänen-Admins also vertrauen. Ich habe schon Geschäftsführer gesehen, die extrem vertrauliche Daten separat verschlüsselt haben, entweder in einem VeraCrypt-Container oder mittels AxCrypt. Aber selbst da kann der Administrator theoretisch das Passwort aus dem Arbeitsspeicher auslesen.

Normalerweise erstellt man kein neues Zertifikat, sondern verlängert das bestehende. Dann bleibt der Private Key gleich und man kann auch die alten Mails noch entschlüsseln. Aber die Thematik "verschlüsselte Daten im Backup/Archiv" ist trotzdem zu beachten. Hier haben Gateway-Lösungen den Vorteil, dass die Mails erst verschlüsselt werden, wenn sie das interne Netzwerk verlassen, und beim Empfang gleich entschlüsselt werden. Ist die Verschlüsselung auf dem Client terminiert, funktionieren auch diverse andere Sachen nicht: Exchange-Transportregeln, Gateway-Antivirus, DLP...

Wenn man nur die Kosten für CPU, RAM etc. vergleicht, ist lokal immer günstiger als Cloud. Man muss aber die Unterschiede berücksichtigen: einen lokalen Server 1:1 mit einem virtuellen Server in der Cloud zu vergleichen ist nicht fair: man müsste lokal schon zwei Server (und ein SAN etc.) rechnen, um schon nur die Verfügbarkeit angemessen vergleichen zu können. Wie schon geschrieben wurde, sollte der Kunde zuerst seine Anforderungen definieren und danach vergleicht man Lösungen, welche diese Anforderungen erfüllen.

Es geht, macht aber keinen Spass. Habe das im Einsatz beobachten dürfen: Hauptserver steht in Zentrale, Ersatzserver an zweitem Standort, verbunden über ein VPN mit DSL 100/20. Dem Hyper-V sind die Latenzen und auch gelegentliche Unterbrüche egal. Man darf aber nicht meinen, dass man das Replikationsintervall nur ansatzweise einhalten kann. Die Überwachung zeigt folgendes: am Morgen und tagsüber reicht es meist, um innerhalb der 15 Minuten zu bleiben. Wenn ein Benutzer eine grosse Datei (CAD-Plan mit Luftbild zum Beispiel) speichert, verpasst man aber auch mal einen Zyklus. Abends, wenn die Datenbank-Sicherungen geschrieben werden, dauert der Abgleich dann bis in die Nacht. Fazit: An zweitem Standort einsatzbereiten Server vorhalten: Ja. Dem Kunden irgend eine Garantie geben können, ob die Daten darauf 15 Minuten oder einen Tag alt sind: Nein.

Es sind zwei verschiedene Probleme: - Das März 2018-Update löscht auf Windows Server 2008 R2 unter VMware die Netzwerkkarte und erstellt eine neue. Diese ist dann auf DHCP eingestellt. Ein korrigiertes Update gibt es noch nicht, aber ein Script, welches man vor der Installation des Updates ausführen muss. - Wenn ein Update neue Integrationskomponenten enthält, bootet ein Server 2012 R2 mit Exchange unter Hyper-V extrem langsam und es ist keine Netzwerkkarte mehr vorhanden. Nach einem erneutem (langsamen) Reboot werden die Updates rückgängig gemacht und die Netzwerkkarte ist wieder vorhanden. Auch hier gibt es noch kein korrigiertes Update. Es hilft, vor der Installation die Exchange-Dienste zu beenden, zu deaktivieren und erst nach dem Reboot wieder zu aktivieren und zu starten.

Würde auch zu einer Gateway-Lösung raten. Die Verwaltung ist einfacher und die Handhabung ebenfalls. Man will normalerweise keine verschlüsselten Mails in Benutzerpostfächern, da es die Archivierung erschwert. Kenne eine Firma, die SEPPmail (https://www.seppmail.ch) einsetzt. Das kann verschlüsseln und signieren. Die Zertifikate kann es direkt bei einer CA anfordern, wenn das erste Mail verschickt wird. Preislich weiss ich nicht wie es aussieht, kann mir aber vorstellen, dass sich die CAs die "Managed PKI"-Lösung gut bezahlen lassen.