DocData

Für den Empfang und Versand von Mails ist HTTPS, aus Sicht des Exchange-Servers, unnötig. Wichtig ist 25/tcp. Der sollte ein- und ausgehend für den Exchange frei sein.

Es tut mir leid, aber damit bist du total auf dem Holzweg. Deine Abneigung gegen Lösungen wie Exchange Online basiert wahrscheinlich auf der Angst, dass du keine Kontrolle mehr hast, die Server eben nicht unter deinem Schreibtisch stehen usw. Ein ähnliches Verhalten habe ich vor vielen Jahren hinsichtlich Virtualisierung erlebt. Ich denke wir müssen nicht darüber diskutieren, was sich durchgesetzt hat, oder? Deine Abneigung einer angebotenen Lösung beschränkt dich und deine Kunden. Ich weiß nicht, ob du damit auf Dauer erfolgreich bist.

Warum kein LVM? Ist OT, daher Antwort gerne per PM.

Viele Clients bieten die Möglichkeit, den Computer zu einer bestimmten Uhrzeit zu starten. Die RTC läuft ja weiter, auch wenn der Computer aus ist. Diese Einstellung habe ich aber ebenso wenig bei einem Server gesehen, wie Wake-on-LAN. Was für Hardware hast du denn da stehen? btw: Als Dienstleister darf man sich seine Kunden ebenso aussuchen, wie als Kunde den Dienstleister. Man muss auch nicht jeden Mist des Kunden mitmachen. Möglicherweise ist so eine Idee ein guter Anlass, die Kundenbeziehung zu überdenken. Energetisch mag das sinnvoll sein, aber finanziell? Wenn du dem Kunden deine Zeit zur Lösungsentwicklujg in Rechnung stellst, dann wird die Planung und Implementierung wohl mehr kosten, als er über 5 Jahre an Strom spart...

Äh... das sind VLAN Basics...

Nein, dein Problem ist, dass du essentielle Grundlagen nicht verstanden hast. Ein VLAN hat niemals eine IP-Adresse. Ein VLAN hat auch keine Mac-Adresse. Ein VLAN wird lediglich über eine ID (VLAN-Tag) identifiziert. Dazu gibt es ein 4 Byte langes Feld im Ethernet Frame. Was du evtl. meinst, ist ein sog. Switch Virtual Interface, bei dem ein Switch ein IP Interface hat, welches in einem bestimmten VLAN liegt. Dieses wird i.d.R. für das Inter-VLAN Routing verwendet.

Kopier die Sachen von der Festplatte, die du noch brauchst. Anschließend formatieren.

Es gibt keinen Common Practice zum Abschalten von Funktionen. Funktionen werden aktiviert oder deaktiviert, aufgrund einer konkreten Anforderung und nicht "proaktiv". Ich erlebe das bei etlichen Kunden. Fürchterlich was bei manchen im Kopf so rumspukt.

Ganz ehrlich: In so einem Fall hast du ganz andere Sorgen, als ein BMR. Was viele Kunden gerne mal vergessen: Es ist keine HW mehr da, auf die man etwas zurücksichern könnte. Und glaube mir (ich habe es in der Praxis zwei Mal erlebt): Das ist das echte Problem.

Kostenvorteile sind aber nicht alles, und aus der operativen Perspektive betrachtet, können Lösungen auf Basis von Storage Spaces die Pest sein. Aber ich will damit nicht ausschließen, dass es gute Anwendungsfälle für Commodity Hardware in Verbindung mit Storage Spaces gibt! Aber das geht nun wirklich am Thema vorbei.

Es tut mir leid, aber selbstverständlich hast du da eine Wahl. Und ja, ich habe auch den Eindruck das du hier sämtliche Lösungshinweise gepflegt ignorierst und eher auf die Bestätigung deines kruden Designs hoffst. Beim aktuellen Stand des Threads weiß ich nicht was schlimmer ist: Das in dem Unternehmen Entscheidungen ohne Absprache getroffen werden, oder das fachliche Knowhow des Administrators.

Passt denn die Anzahl der Ordner und Objekte?

Bevor du eine Lösung gegen eine andere Lösung austauscht, solltest du nicht nur die Nachteile der bestehenden Lösung ins Auge fassen, sondern auch die möglichen Nachteile der neuen Lösung. SOFS ist nett, hat aber, ähnlich wie shared VHDX, so seine Tücken.

H3C IST seit einiger Zeit HP und die Switches von 3COM und H3C werden fleißig in das Portfolio integriert, wobei es auch einige gegensätzliche Entwicklungen gibt. Die 3COM/ H3C können software-basiertes Stacking (IRF), während mittlerweile einige ProVision basierte Switches das per HW und speziellen Kabel und Modulen machen. Da wird quasi die Data und Control Plane erweitert. Juniper EX haben natürlich einen großen Vorteil: Junos. Mehr muss man dazu wohl nicht sagen. Cisco hat sich IMHO überholt. Die Nexus sind sehr nett, aber alles darunter ist vom Preis-/ Leistungsverhältnis ziemlicher Quatsch. Man bezahlt einen Namen und Marktanteile.

Ein weiterer Punkt ist der Coordinator Node. Mit einem Volume hast du nur einen Coordinator Node. Wenn du z.B. vier CSV hast, dann ist die Chance sehr hoch, dass vier deiner sechs Nodes Coordinator Nodes sind und die Last ein wenig verteilt ist. Den Einfluss kann man in diesem Artikel gut nachvollziehen.

Es ist zu bedenken, dass eine LUN eine sog. LUN Queue hat. Habe ich nur ein CSV auf einer LUN, dann habe ich nur eine LUN Queue. Habe ich meine Maschinen auf mehrere LUNs verteilt, dann kann ich auch von mehreren LUN Queues profitieren. Des Weiteren sollte man immer bedenken, dass man mit dem EInsatz mehrerer CSV auch die Failure Domains verkleinert. Fällt einem das einzige CSV aus, dann sind alle VMs betroffen. Verteilt man seine VMs auf mehrere CSV, dann überlegt immerhin noch ein Teil der Maschinen. Aus diesem Grund geht meine Empfehlung klar in Richtung mehrerer CSV. Was spricht gegen vier CSV mit je 3 TB?

Warum wird das eigentlich immer vernachlässigt? Da brauche ich mich ja nicht wundern, was da teilweise in Kundennetzwerken verbrochen wird oder hochzertifizierte Leute Haufenweise Netzwerkkarten in Server stopfen, weil sie VLANs für Voodoo halten.

Du hast eine CA und das Zertifikat des Exchange Servers. Dein Client bekommt vom Exchange Server das Zertifikat gezeigt. Damit der Client das Zertifikat vom Exchange Server als gültig ansieht, müssen unterschiedliche Dinge korrekt sein. So muss z.B. der Name, mit dem der Exchange Server angesprochen wird, im Zertifkat enthalten sein. Das Zertifikat darf nicht abgelaufen sein und es muss von einer CA ausgestellt sein, die der Client kennt und die er als gültig anerkennt. Hier liegt dein Problem. Dein Client bekommt als Mitglied der Domäne das CA Zertifikat automatisch. Wenn du aber an einem Rechner außerhalb der Domäne sitzt, dann kennt dieser deine interne CA nicht. Dementsprechend erkennt der Client das Zertifikat des Exchange Server als ungültig (es wurde von einer CA ausgestellt, für die er kein CA Zertifikat hat). Du musst also das CA Zertifikat exportieren und es am gewünschten Client in die vertrauenswürdigen Stammzertifizierungsstellen importieren. Dann verschwindet die Zertifikatswarnung.

Einverstanden. Völlig verständlicher Ansatz. Nur bezweifele ich, dass der TO einen SCVMM hat, geschweige denn das Knowhow ein BMD zu bauen. Die Frage kommt bei mir immer mal wieder auf, insbesondere dann, wenn es um Betriebshandbücher etc. geht.

Das würde ich so nicht unterschreiben wollen. Gerade im Hinblick auf die Interpretation, dass ein Hostausfall eine Störung ist und Störungen innerhalb einer gewissen Zeit behoben sein müssen, hat man da nicht mehr Zeit. Klar, die virtuellen Maschinen laufen weiter, trotzdem fehlen mit Ressourcen im Cluster. Und bezüglich "auf den Maschinen läuft ja nichts": Was ist mit Agenten für Monitoring etc.?

Hast du es mal mit Windows Backup versucht? Alternativ kannst du dir den Microsoft DPM mal anschauen.

Nicht i.d.R. HP tut es. Ich empfehle einen HP Systems Insight Manager mit Insight Remote Support zu installieren. Ich habe das bei ein paar Mandanten laufen und da melden die Server auch predicted failures von Platten. HP schickt jedes Mal, ohne Rückfragen o.ä. Platten raus.

HP Support anrufen, Ticket eröffnen, ADU Report schicken, Platte wird ausgetauscht.

Darf ich dann mal ungeniert fragen, wie du das lizenzierst?

Ist das eine Homeuser-Umgebung von der du da sprichst? Oder will das ein Kunde in seinem Unternehmen betreiben?