mwiederkehr

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.

Hallo zusammen Ein Kunde betreibt DHCP und WDS auf verschiedenen Servern. Seit der Installation von WDS bekommen einige Netzwerkgeräte (alle vom gleichen Hersteller, wohl aber basierend auf Linux) keine IP-Adresse mehr. So viel konnte ich herausfinden: - Gerät sendet DHCPDISCOVER - WDS sendet DHCPOFFER mit Vendor-Class-ID "PXEClient" und ohne IP-Adresse ("yiaddr" = "0.0.0.0") => logisch, er sendet ja nur die Informationen für PXE-Boot - einen Tick später schickt der DHCP einen DHCPOFFER ohne Vendor-Class-ID und mit IP-Adresse - das Gerät entscheidet sich für die Antwort vom WDS und nimmt die IP "0.0.0.0" bzw. geht auf die als Fallback hinterlegte fixe IP zurück Nun ist die Frage: - Verbockt es das Gerät, indem es sich für den DHCPOFFER ohne IP entscheidet und nicht (wie alle anderen Clients mit Windows, Android und iOS) die Antwort mit IP nimmt? oder - Hält sich der WDS nicht an den Standard, indem er immer eine Antwort schickt, obwohl die Anfrage nicht die Vendor-Class-ID "PXEClient" enthält? Ich werde aus RFC 2131 nicht ganz schlau. Dort steht eigentlich, dass "yiaddr" immer eine IP enthalten muss und dass herstellerspezifische Parameter nur mitgesendet werden, wenn der Client eine entsprechende Vendor-Class-ID mitliefert. Kennt ihr solche Probleme? Lasst ihr euren WDS den DHCP-Port gar nicht abhören, sondern habt alles auf dem DHCP-Server konfiguriert?

Das sind aber schon einige Anforderungen... Eigentlich schade für den ganzen Aufwand, wenn die Clients dann nur "dumm" Citrix ausliefern. Zum Thema Kosten: so habt ihr den Aufwand für die Verwaltung der lokalen Clients sowie auch dem Betrieb der Server im RZ. Deshalb würde ich noch einmal das Gespräch mit dem Server-Verantwortlichen suchen bezüglich Thin Clients. Ich verstehe, dass er Vorbehalte hat. Aber ihr würdet ja nicht einfach ein Linux und einen alternativen Citrix-Client aus dem Internet nehmen, sondern Clients eines etablierten Herstellers, welcher von Citrix zertifiziert ist und Support bietet. Ich verstehe wirklich nicht, weshalb man sich da so strikte verweigern kann.

Bei mir zeigt es mit einem Domänenbenutzer, der lediglich lokale Adminrechte hat, die gesamte Domain an. Ist evtl. die Admin-Filterung ein Problem? Versuch es doch mal ohne Domain-Admin.

Du könntest das Stylesheet (CSS) anpassen: https://docs.microsoft.com/en-us/exchange/clients/outlook-on-the-web/customize-outlook-on-the-web?view=exchserver-2019 Achtung: Updates nehmen auf das angepasste CSS keine Rücksicht. Also immer sichern und nach Updates allenfalls zurück kopieren.

Umleitung in anderes Postfach ist heikel bezüglich Datenschutz, besonders wenn die private Nutzung von E-Mail gestattet ist. Besser ablehnen mit einer kurzen Info, dass die Mail an quarantine@domain.de oder so gesendet werden soll. Es ist eine mühsame Geschichte: docm, exe etc. kann man gut verbieten, aber wenn alle docx vom Admin freigegeben werden müssen, hat der viel zu tun... Leider können aber auch docx ausführbare Inhalte enthalten, Microsoft hat das nicht so genau getrennt. Der Punkt "Benutzer schulen" ist übrigens nicht von Erfolg gekrönt. Hatte kürzlich den Fall, dass über jemandes E-Mail-Konto eine Rechnung.docx verschickt wurde. Er ist nicht in der Buchhaltung tätig und die Firma verschickt ganz allgemein keine Rechnungen per E-Mail. Fazit: 80 Mails gingen raus, von zehn (!) Leuten kam die Antwort, man könne das Dokument nicht öffnen.

und Quelle: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197552(v=ws.10) Das würde heissen, wenn der erste DNS sich mal länger als eine Sekunde Zeit lässt mit der Antwort, wird er danach ignoriert. Das kann schon mal vorkommen, wenn er einen Namen im Internet auflösen muss und der zuständige DNS-Server keine Antwort gibt. Das Problem ist dann, dass er nicht wieder den internen DNS fragt, wenn ihm der externe logischerweise die interne Domäne nicht aufgelöst hat. In der Praxis habe ich schon viele solche Konfigurationen gesehen. Meist funktioniert es. Manchmal werden nach einigen Stunden die Gruppenrichtlinien nicht mehr aktualisiert, aber das merkt der Benutzer meist nicht. Die verbundenen Laufwerke und Drucker bleiben ja verbunden. Jedenfalls bis irgendwann das Ticket abläuft, aber das hält schon einen Arbeitstag. Würde ich so nicht konfigurieren. Wenn die Firewall verfügbarer ist als der DC, kann man auf der Firewall einen Forwarder zum DC einrichten und dann die Firewall als DNS bei den Clients eintragen.

Da die Aufgabe exakt definierbar ist und ohne Zugriff auf Datenbanken etc. im Firmennetz gelöst werden kann, könnte man für die Entwicklung einen Freiberufler suchen. Allenfalls findet sich an einer Uni ein Student, der damit neben dem Studium etwas Geld verdienen möchte.