mwiederkehr

Oh, aus Exchange wird doch noch ein richtiger Mailserver! (Als ich in meinen jungen Jahren an einer Präsentation von Exchange 2003 oder 2007 mal gefragt habe, wieso Exchange dieses und jenes Feature nicht habe, das mit jedem Postfix seit zehn Jahren gehe, war die Antwort "Exchange ist kein Mailserver, Exchange ist eine Groupware".) "Send from Alias" ist nett, erspart in einigen Fällen den Aufwand zur Einrichtung von Verteilergruppen. Auf das Plus Addressing freue ich jetzt aber so richtig. Nicht so sehr für meine Kunden, sondern für mich. Endlich nicht mehr Aliase für Newsletter und Shops erstellen und man sieht endlich, wer die Adresse weiterverkauft hat.

Hast Du da eine genaue Definition, was man ohne SA darf und was nicht, bzw. was als "Mobilität" angesehen wird? Live Migration darf man nicht machen, klar. Replica: generell nicht, oder nur im Fehlerfalle und nicht zu Wartungszwecken (also nur "unplanned failover", aber nicht "planned failover")? Wenn man mit Veeam repliziert? Mit Robocopy jede Nacht die virtuellen Disks kopiert? Verstehe die Unterscheidung zwischen "Mobilität" und "Disaster Recovery" noch nicht ganz.

Da ist wohl entscheidend, wem der Server im Rechenzentrum gehört. Ist er Eigentum des Kunden, sehe ich keine Probleme. Gehört er dem Provider und empfängt er noch Replikationen von anderen Kunden, muss er wohl über SPLA lizenziert werden (aber das wäre dann Sache des Providers). Bei einem einzelnen Exchange kann ich mir keine Probleme vorstellen. Bei einem unplanned Failover startet er neu wie nach einem Stromausfall. Ich frage mich eher, wieso man nur einen Exchange will, wenn man schon drei Hosts zur Verfügung hat.

Der RasPi 4 wird noch nicht offiziell unterstützt, aber die Insider Preview soll laufen: https://www.iottechtrends.com/install-windows10-iot-core-raspberry-pi/ Schliesse mich aber Sunny61 an und empfehle für die allermeisten Anwendungen Linux. Windows 10 IoT Core ist im Übrigen nicht mit dem "normalen" Windows 10 zu vergleichen. Man kann den RasPi damit nicht zu einem günstigen Bürorechner machen.

Ich habe dafür mal ein Tool geschrieben. Dieses wird mit dem Anmeldeskript ausgeführt und schreibt Computername, Benutzername und Uhrzeit in eine SQLite-DB. Im Abmeldescript kann man es wieder aufrufen, worauf der Datensatz gelöscht wird. (Dies, falls man wissen will, ob User XY gerade irgendwo angemeldet ist.) Bei Interesse kann ich es gerne raus-suchen.

Eigentlich solltest Du das vCenter auf dem neuen Server installieren und "vorhandene Datenbank verwenden" auswählen können. Dann allenfalls noch die SSL-Zertifikate kopieren. Die Einstellungen sollten ja alle in der Datenbank sein. Früher haben wir die Appliance jeweils mittels Veeam repliziert und hätten sie im Fehlerfall manuell gestartet. Aber wie ich gerade gesehen habe, unterstützt sie in der aktuellen Version Clustering: https://www.windowspro.de/thomas-drilling/vcenter-server-appliance-65-hochverfuegbar-konfigurieren

Ich habe schon länger keinen physischen Terminalserver mehr gesehen. Seit die Virtualisierung direkt auf der Hardware stattfindet, gibt es bei den meisten Anwendungen keine nennenswerten Performance-Einbussen mehr. Falls ihr keine Grafikbeschleunigung braucht, hätte ich keine Bedenken. Selbst für Grafikbeschleunigung gibt es mittlerweile Lösungen mit Virtualisierung, aber das bedarf dann umfassender Tests.

Hat man dann nicht das Problem, dass vMotion bis zum Aus- und wieder Einschalten aller VMs nicht geht, weil die Hosts nicht erkennen, dass die VMs in der gleichen Clusterkonfiguration gestartet wurden? Meinte, das Problem mal gehabt zu haben. Das war aber bei Version 5.1 oder 5.5, ist also schon etwas länger her.

Das lässt sich relativ einfach umsetzen, wenn man die Drucker mit einem Script verbindet statt per Policy. Oder im DNS einen CNAME "printserver" mit kurzer TTL machen, welcher im Normalfall auf "Print01" verweist, aber auf "Print02" umgestellt werden kann (entweder manuell oder von der Systemüberwachung). Die Clients verbinden dann zu "\\printserver".

Das ist doch jetzt endlich mal ein Einsatzzweck für Nested Virtualization!

Der von Nils beschriebene Weg sollte funktionieren. Es sollte reichen, die vmguest.iso von einem Server mit Windows Server 2012 R2 zu kopieren und bei der VM anzuhängen, um die Integration Services zu installieren. Bei einem Kunden wird auch noch hie und da auf eine VM mit Windows 2003 zugegriffen. Die wurde mal auf Hyper-V 2012 R2 virtualisiert und kürzlich auf 2019 verschoben. Da funktionieren Tastatur und Maus.

Das geht schon, aber erfahrungsgemäss ist der zweite Internetzugang dann ein einfacher Router und es geht nicht lange, bis das von Leuten entdeckt und fleissig darüber gesurft wird, da ungefiltert. Hänge den zweiten Internetzugang doch an ein Interface der Firewall, trage dort eine Route zum 3CX-Server ein und beschränke den Verkehr auf diesem Anschluss auf diese Ziel-Adresse. Oder mach gleich eine ordentliche Multi-WAN-Konfiguration, dann könnten die Telefone im Notfall auch den normalen Internetanschluss nutzen oder die Rechner den für die Telefonie.

Kommt darauf an, was ihr unter Newsletter versteht. Falls "wir sind eine kleine Firma und möchten unsere 100 - 200 Kunden hie und da über Neuigkeiten informieren": Das geht gut über den eigenen Mailserver. Direkt aus Outlook, aus dem CRM oder mit einem Tool wie SuperMailer. Falls "wir betreiben einen Online Shop und möchten unsere 10'000 Kunden regelmässig über Sonderangebote informieren": Da kann ich mich meinen Vorrednern anschliessen und rate ganz klar zu einer externen Lösung. Nehmt einen externen Mailserver und eine eigene Domain oder zumindest Subdomain. Es kommt immer wieder vor, dass Leute auch bei legitimen Newslettern nicht auf den Abmelde-Link klicken, sondern die E-Mail in Gmail & Co. als Spam markieren. Wenn das ein paar Wenige machen, seid ihr auf der Blacklist. Da runter zu kommen ist je nach Anbieter nicht so einfach... Zudem haben externe Lösungen wie SendGrid, Mailjet & Co. den Vorteil, dass sie falsche Adressen automatisiert speichern können. Bei einem manuellen Versand müsste die Sekretärin alle unzustellbaren E-Mails durchforsten und den Datenbestand nachführen.

Mit "netcfg -d" kannst Du die gesamte Netzwerkkonfiguration zurücksetzen. Ich würde Hyper-V deinstallieren, die Konfiguration zurücksetzen und danach Hyper-V wieder installieren. Allenfalls auch in der Registry prüfen, ob noch alte Einträge vorhanden sind nach der Deinstallation von Hyper-V: https://rlevchenko.com/2014/07/28/hyper-v-3-0-interaction-with-registry-and-how-it-was-in-2008-r2/ Einen offiziellen Link von Microsoft zum Thema habe ich leider nicht gefunden. Müsste ja schon irgendwie zu erfahren sein, wo die Konfiguration vom Hyper-V gespeichert ist...

a.) Technisch ist das kein Problem. In der Praxis kommt es aber vor, dass empfangende Mailserver den PTR auflösen und schauen, ob die gleiche IP-Adresse rauskommt wie die von der die Verbindung kommt. So würden über die zweite Leitung versandte E-Mails als Spam markiert. Schön wäre es, einen PTR pro IP-Adresse zu haben und den Helo-String von der Firewall je nach aktivem Interface anpassen zu lassen. So weit ich weiss geht das mit der WatchGuard nicht, da man dort nur eine Regel hat für alle Interfaces. b.) Die Umschaltung liesse sich scripten. Oder aber man verwendet eine Cloud-Lösung wie den Azure Traffic Manager. Der prüft die Verbindungen und gibt nur verfügbare IP-Adressen zurück.

Was verwendet ihr denn für Switche und Firewalls? Ich würde wenn möglich den Router/die Firewall von einem dieser Hersteller einsetzen. Je nach Anforderungen kommen da viele Geräte in Frage, von einem routenden Switch bis zu einer Firewall.

Was möchtest Du genau haben? Eine Box, an die Du Bildschirm und Tastatur anschliessen kannst und somit "vor Ort" über einen Browser die Konsolen steuern kannst? Oder suchst Du eine Box, die von extern über das Netzwerk erreichbar ist und die dann die Anfragen an die Konsolen weiterleitet? Im ersten Fall: Raspberry Pi mit Chromium (allenfalls dauerhaft im Vollbild- bzw. Kioskmodus). Im zweiten Fall: Raspberry Pi, entweder erreichbar per SSH und die benötigten Ports tunneln, oder (falls der Konsole HTTPS reicht) als Reverse Proxy. Wobei ich da den Nutzen nicht ganz sehe. Zumindest bei einem aktuell gepatchten HP iLO sehe ich es nicht als Problem an, wenn er vom Admin-Netzwerk aus erreichbar ist.

Ich sehe folgende Möglichkeiten: - Speicherung der Kontakte in einem freigegebenen Postfach: kostenlos, muss aber über die Outlook App eingebunden werden. - Speicherung der Kontakte in einem normalen Postfach: kostenpflichtig, kann dafür ohne zusätzliche App eingebunden werden. - Speicherung der Kontakte in einem öffentlichen Ordner: kostenlos, aber Drittanbieter-App erforderlich (welche unter Umständen nicht kostenlos ist).

So wie ich es verstanden habe, braucht man Lizenzen (oder SA) für Replikate, weil diese startbare VMs sind. Das gilt auch für andere Lösungen: man darf zum Beispiel mit Veeam regelmässig ein Backup einer VM auf einem anderen Server ablegen, aber man darf die VM nicht replizieren, obwohl Veeam unabhängig von Hyper-V Replica ist. Was wohl gehen würde, wäre eine regelmässige Replikation, ohne dass die VM im Hyper-V auf dem zweiten Server importiert wird. (Also dass nur die Maschine kopiert und aktuell gehalten wird, ohne dass sie im Hyper-V Manager sichtbar ist.) Das ist aber auch mehr eine theoretische Diskussion, denn die VMs auf der anderen Hardware starten darf man nur, wenn die primäre Hardware ausfällt. Und wer macht schon eine Replikation, ohne diese hin und wieder zu testen (=> VMs einschalten)? Ich versuche den Kunden deshalb jeweils von Datacenter zu überzeugen. Ist nicht günstig, aber wenn man den eingesparten Aufwand durch die Nutzung von Live Migration, Replica etc. über vier bis fünf Jahre anschaut, ist es nicht mehr so schlimm. Zudem "verleitet" die Standard-Lizenzierung dazu, Sachen auf einer VM zu installieren, die besser getrennt wären. "Wenn wir nur einen DC machen, sparen wir eine Lizenz", "wir können ja auf dem Dateiserver den IIS aktivieren, um unsere Website zu hosten" etc...

"Hochverfügbarkeit" und "weniger als drei Nodes" widersprechen sich. Zwei Hosts reichen für den Fall, dass einer ausfällt. Aber: was, wenn der zweite Host dann gerade im Wartungsmodus ist wegen Updates etc.? Deshalb macht man ja auch RAID 6 statt RAID 5 und das Rechenzentrum hat drei Dieselgeneratoren statt zwei. Wenn man einfach den Fall "Ausfall einer einzelnen Komponente während Bürozeiten" abfangen will, wäre folgende Umgebung recht kostengünstig zu haben: 2x Server (HP ProLiant DL360 zum Beispiel), 1x MSA 2052 mit zwei SAS-Controllern. (Oder natürlich die gleiche Konfiguration mit Hardware eines anderen Herstellers.)

Wegen der Lebensdauer der SSD würde ich mir keine Sorgen machen. Auch Consumer-SSDs sind kaum mehr kaputt zu schreiben, jedenfalls nicht bei normaler Auslastung im Server eines Kleinbetriebs. Da kommt man kaum auf 1 DWPD. Besonders nicht, wenn man die Grösse ausreichend dimensioniert. Es stimmt auch, dass sich Markenhersteller besonders den Speicher gut bezahlen lassen. Das sieht man schon an den Rabatten, die man über Projektpreise bekommt. Aber es ist trotzdem nicht alles "Abzocke" ohne Mehrwert. Man muss die Entscheidung für oder gegen Markenhardware abhängig von der Umgebung treffen. Ein grosser Vorteil von Markenhardware ist die Kompatibilität. Hatte schon einen Kunden mit zusammengewürfelter Hardware: Server von Supermicro, Switch von Cisco, SFPs gemischt (von eBay), SAN ebenfalls Supermicro mit diversen Disks. Das gab immer wieder Probleme und Unterbrüche. Seit er alles von HP hat, gab es keine Probleme mehr und man hat auch keine Bedenken mehr, mal ein Treiberupdate einzuspielen. Ein weiterer Vorteil ist, dass der Hersteller die Arbeit macht. Stell Dir vor, der Kunde ist weiter weg und nach einem Monat geht ein RAM-Modul kaputt. Bekommt man auf Garantie ausgetauscht, aber den Austausch muss man bei Eigenbau-Systemen selbst vornehmen und ich möchte den Kunden sehen, der einem den Aufwand dafür zahlt. Die Verfügbarkeit ist hingegen nicht mehr so ein Problem. Dank Virtualisierung kann man da häufig in die Breite gehen, also zwei günstige Systeme anstelle eines teuren mit redundanten Komponenten einsetzen. Mit zwei normalen Rechnern erreicht man unter Umständen eine höhere Verfügbarkeit als mit einem Markenserver (für den man dann nur das "next business day"-Supportpaket kauft). Aber eben, wie heisst es doch so schön: kommt darauf an.

Die Firmware ist aktuell. Es handelt sich um Access Points der Firma Ubiquity, Produktreihe UniFi. Es hat ältere sowie ganz neue Geräte darunter, welche alles das gleiche Verhalten zeigen.

a.) Ich wüsste nicht, wieso das sein sollte. Man kann manchmal beobachten, dass der sekundäre MX mehr Spam erhält als der primäre. Dies, weil Spammer davon ausgehen, dass auf dem Backup-MX weniger Filter installiert sind. Bei nur einem MX geht alles an diesen. b.) Händisch erlauben ist eine Möglichkeit. Je nach Proxy kann dieser die Adressen per LDAP oder SMTP verifizieren und Absender blockieren, die zu viele ungültige Adressen durchprobieren. (Die -inzwischen eingestellte- WatchGuard XCS konnte das zum Beispiel. Die WatchGuard Firewalls können es soweit ich weiss nicht.)

Habe unter Windows Server 2012 R2 mal einen IPsec-Tunnel zwischen zwei Servern aufgebaut. Wie beschrieben mit der Windows Firewall. Fazit: Hat funktioniert. Das Logging war aber quasi nicht vorhanden, was eine allfällige Fehlersuche erschwert hätte. Deshalb habe ich es nie einem Kunden für den Produktiveinsatz empfohlen und habe keine Langzeiterfahrungen damit. Was Du Dir sonst noch anschauen könntest: SFTP, WebDAV über HTTPS (das liesse sich als Laufwerk einbinden und mit Robocopy verwenden) oder allenfalls WireGuard. Um Letzteres ist ein rechter Hype entstanden, da es viele Nachteile von IPsec nicht hat. Aber es ist noch Beta.

Mir fallen zwei Lösungen mit mehr oder weniger grossem "Gebastel"-Faktor ein: - Die Firewall spielt DNS. Anfragen an die interne Domäne leitet sie an den internen DNS-Server um, Anfragen an externe Adressen löst sie direkt auf oder leitet sie an den DNS-Server des Internetproviders weiter. - Du installierst auf den Rechnern im Lab lokal einen DNS. Da der Windows DNS leider nicht auf Clients läuft, musst Du auf den BIND oder eine sonstige Alternative ausweichen. Der lokale DNS löst dann auch die interne Domäne intern auf und den Rest extern. Auf dem Client trägst Du 127.0.0.1 als DNS-Server ein. Besonders die zweite Lösung kommt natürlich nur für ein Lab in Frage, nicht für den produktiven Einsatz.