NilsK

Moin, hm, OK, dann steige ich langsam dahinter. Dadurch ist der Host der Router. Keine Konfiguration, die ich betreiben wollen würde. Gruß, Nils

Moin, nein, er macht ja momentan kein Cluster-in-a-Box. Sein Problem ist, dass Veeam keine VMs sichert, die LUNs/RDMs eingebunden haben. Und: Storage Replica ist eine nagelneue Technik, mit der es noch wenige Praxiserfahrungen gibt. Für einen Dateiserver-Cluster, wie er dir vorschwebt, halte ich die Funktion, wie ich schon sagte, für ungeeignet. Ganz abgesehen davon, würde ich sowas auch nicht bauen, wenn ich ein Storage der 3PAR-Kategorie hätte. Gruß, Nils

Moin, willkommen an Board! Bitte übernimm keine vorhandenen Threads mit einer neuen Frage, sondern eröffne einen neuen Thread und beschreibe dein Problem und deine Frage genau. Danke, Nils

Moin, Storage Replica ist dafür keine sinnvolle Option. Grundsätzlich würde ich da über einen Windows-Cluster nachdenken, der mit virtuellen Disks arbeitet - wenn es nicht um vSphere ginge. Soweit ich weiß, ist dort die gemeinsame Nutzung einer VMDK nur supported, wenn alle Clusterknoten auf demselben Host laufen. Wäre also ziemlich witzlos. In vSphere-Umgebungen mit Gast-Clustern arbeitet man daher üblicherweise mit LUNs in den VMs und muss die Datensicherung dann anders lösen. Wenn ich mich richtig erinnere, hat Veeam das auf der Liste, aber es gibt noch keine Ankündigung, ob und wann sie sowas unterstützen wollen. Gruß, Nils

Moin, was schwebt dir denn vor? Ich kann mir Storage Replica in dem Szenario jetzt nur eingeschränkt vorstellen. Gruß, Nils

Moin, zumindest gab es mal Paketlösungen, bei denen man über eine Schnittstelle automatisiert Personenzertifikate ausstellen lassen kann. Auf die Schnelle finde ich das nicht wieder, möglicherweise gibt es das auch nicht mehr. Selbst wenn, wäre aber die Frage, ob sich das mit Office 365 integrieren lässt - vermutlich nicht. Das ist eher was für Gateway-Lösungen. Was es aber gibt, sind Zertifikatspakete, mit denen man eine größere Zahl von Personenzertifikaten erwirbt. Die sind dann auch wieder nicht gar so teuer, zumal es dort Staffelrabatte gibt. Gruß, Nils

Moin, es gibt für sowas auch "Paketlösungen", bei denen man basierend auf einem kommerziellen Zertifikat die Einzelzertifikate selbst erzeugen kann. Ich weiß aber nicht, ob das auch mit Office 365 einsetzbar ist. Edit: Einen Überblick, wie man Office 365 mit einer internen PKI zusammenbringt, gibt es bei Frank Carius: http://www.msxfaq.de/cloud/exchangeonline/o365smime.htm Er beschreibt auch sehr schön einige der Hindernisse, die sich dabei auftun. Was dort aber fehlt, ist die Frage, wie man das "technische Vertrauen" zur Gegenstelle herstellt - und das ist eben meist mit kommerziellen Zertifikaten leichter herstellbar, weil man nicht neben dem Userzertifikat auch noch das Root-Zertifikat weiterreichen muss. Gruß, Nils

Moin, in dem Fall bestünde aber das Hauptproblem, das ich auch beim "Klonen" sehe: Name und Domain-SID sind identisch, sehr wahrscheinlich auch alle Kennwörter. Dadurch besteht nicht nur ein hohes Risiko, die Echtumgebung zu beeinträchtigen, sondern der Klon ist dadurch auch genauso sicherheitskritisch wie das Original. Aus meiner Sicht ein No-go. Gleichzeitig sehe ich den Nutzen so eines "Klons" als gering an. Alle wichtigen Parameter wird man kaum nachgebildet bekommen. Dann unterscheiden sich Original und "Klon" aber ohnehin, sodass jeder Test nur eingeschränkte Aussagekraft hat. Wenn das aber ohnehin schon so ist, dann kann man auch gleich das Risiko und die Einschränkungen eines "Klons" weglassen und mit einem Nachbau arbeiten, bei dem man die wichtigen Eckdaten sorgfältig nachbildet. Gruß, Nils

Moin, da deine Frage lautet: ist die Antwort "nein" korrekt. Man wird es technisch hinbekommen, aber problemlos wird es nicht sein. XP ist ein Sicherheits- und Stabilitätsrisiko. Gruß, Nils

Moin, wenn du Mail verschlüsseln willst, braucht der Kommunikationspartner dein Zertifikat und muss diesem vertrauen. Das bedeutet in aller Regel, dass ein kommerzielles Zertifikat besser ist. Sonst hast du jedes Mal das Problem, dass das Root-Zertifikat der eigenen PKI zum Endanwender auf der anderen Seite muss. Gruß, Nils

Moin, Bei "Klonen" bin ich immer skeptisch. Lieber ein guter Nachbau. Auf faq-o-matic habe ich Anleitungen dafür. Gruß, Nils

Moin, mir ist unklar, was Hetzner damit meint, dass man "dem virtuellen Switch" eine IP-Adresse geben solle. Da es sich um einen Layer-2-Switch handelt, hat der keine IP-Adresse. (Genau genommen, hat ein Switch nie eine IP-Adresse.) Ich denke, du solltest eine VM als Router einrichten. Gruß, Nils

Moin, Vor allem ist ein Chromevolk (hähä, Autokorrektur) kein Notebook. Offline ist es nahezu nutzlos. Gruß, Nils

Moin, ja, witzig finde ich das auch. War aber tatsächlich bei den bisherigen Releases (auch beim Server) auch so. Daran kann man schön sehen, wie so ein Release funktioniert: Die Version wird festgelegt und muss danach noch rund gemacht werden. Gruß, Nils

Moin, das Volume ist als CSV im Cluster eingebunden? Der zweite Server ist schon in den Cluster aufgenommen? Das sind die Voraussetzungen, dass du den Mountpoint siehst. Gruß, Nils

Moin, NetInstall? Du meinst nicht das, was seit Jahren DSM heißt, oder? Setzt ihr da eine Uralt-Version ein, oder wie? Gruß, Nils

Moin, äh - ernsthaft? Ist das dort die einzige Option? Der Browserdienst war noch nie zuverlässig. Auch mit WINS lässt er sich nur unter günstigen Bedingungen zu belastbaren Aussagen bewegen - oft genug aber auch dann nicht. Gruß, Nils

Moin, das ist im Prinzip egal. Da die LUN ja von einem Clusterknoten kontrolliert wird, koordiniert der Cluster den tatsächlichen Zugriff. Wenn man die LUN auf dem neuen Server anbindet, darf man nur nicht versuchen, sie online zu nehmen. Gruß, Nils

(entfernt)

Moin, das ist ein klassisches Thema, das nicht in ein Forum gehört. Sowas ist Designaufgabe, die von den Anforderungen abhängt. Ob es beispielsweise Sinn ergibt, Teile des "internen" Netzwerks voneinander zu trennen und mit welcher Technik man das macht, ist praktisch ausschließlich eine Frage des IT-Sicherheitskonzepts, das individuell für ein Unternehmen ist - und das aus guten Gründen nicht öffentlich diskutiert gehört. Gruß, Nils

Moin, in dem Fall wäre zu erwarten, dass du im Log des Taskplaners einen Hinweis findest, warum es nicht geht. Gruß, Nils

Moin, das kann man sich, wenn man viel Zeit hat, sicher ansehen. Aber mit welchem Ziel? Das solltest du vielleicht dazu sagen. Für den Einstieg würde ich eher das Buch von Edward Horley empfehlen - das ist auch englisch, aber praxisnah. Es geht hier ja nicht um die Anatomie möglicher Angriffe, sondern um praktische Fragen. Solange es keine Provider-Anbindung per IPv6 gibt, stellt das Protokoll keinen Einfallsweg dar. Die Tunneltechniken (6to4, ISATAP und Teredo) sollte man abschalten, was per GPO, PowerShell oder netsh geht. Gruß, Nils

Moin, nur, damit ich mit meiner eingeschränkten Sichtweise es vielleicht noch verstehe: Wenn du ohnehin der Meinung bist, dass diese Berechtigung nutzlos ist, weil du keine Apps brauchst und willst und das ja alles Teufelswerk ist - warum entfernst du nicht einfach den Eintrag dort, wo die Vererbung beginnt (%ProgramFiles% und %ProgramFiles(x86)%)? Dann bist du ihn ohne weitere Klimmzüge einfach los. Oder geht es dir gar nicht um eine sinnvolle Lösung, sondern nur um den Weg, den du einmal eingeschlagen hast? Gruß, Nils

Moin, ach je. Nicht schon wieder diese Diskussion. Wenn du wüsstest, wie oft wir hier an irgendwas rumlaborieren, nur um hinterher festzustellen, dass man mit Kenntnis der Hintergründe viel schneller zu einem besseren Ergebnis gekommen wäre. Du kannst uns glauben, dass wir auch unsere Erfahrungen haben. Gruß, Nils

Moin, wenn man rangehen will: Als Best Practice gilt, im Unternehmen die IPv6-Tunneltechniken abzuschalten, weil man die in aller Regel nicht haben will. Ausnahme ist DirectAccess. Gruß, Nils