NilsK

Moin,

Schon mal die Hardware getestet?

Gruß, Nils

Moin,

das führt doch hier in die Irre. Der zweite Server wird nicht nur beim Ausfall des ersten eingeschaltet, er muss immer laufen, das ist ja der Sinn der Replikation. Da die lizenzierte Einheit der Host ist, muss man diesen betrachten.

Meines Wissens hat sich an dem Prinzip, das ich oben benannt bzw. verlinkt habe, nichts geändert.

Gruß, Nils

Moin,

Ja, meines Wissens ist das immer noch korrekt:

https://www.faq-o-matic.net/2014/05/12/hyper-v-replica-wie-lizenziert-man-das/

Fair ist so eine Sache - du kannst die VMs auf den Zielserver jederzeit starten. Da könnte man es auch als unfair absehen, wenn du den Host dafür nicht lizenzierst.

Gruß, Nils

Moin,

mit "Ziel" meine ich nicht, dass du deine Frage einfach wiederholst. Ich kann im Browser scrollen.

Was steckt dahinter? Warum soll gelöscht werden, warum sollen bestimmte Verzeichnisse stehen bleiben? Dein Beispielcode löscht auch Dateien, ist das Teil der Aufgabe?

Vielleicht (bzw. wahrscheinlich) gibt es andere Wege, das Ziel zu erreichen. Dafür aber muss man das Ziel kennen.

Gruß, Nils

Moin,

warum erzeugst du dir zwei FSO-Objekte? Falls du im WSH-Scripting nicht firm bist, ist das Löschen von Daten vielleicht nicht der beste Einstieg ...

Wir werden dir hier kein Skript schreiben, aber wenn du uns mal sagst, was denn das eigentliche Ziel ist, können wir dir vielleicht besser den Weg weisen.

Gruß, Nils

Moin,

vor 27 Minuten schrieb uschmucker:

Obwohl die Zertifikate unter den "Windows-Einstellungen" verteilt werden (damit sollten Sie ja systemweit gelten) interessiert das den EDGE Chromium aber scheinbar nicht.

genau wie Norbert würde mich auch interessieren, was das denn genau heißt.

Gruß, Nils

Moin,

Die cim ist Geschichte.

Gruß, Nils

Moin,

da muss sich jedes Unternehmen selbst überlegen, wie es das nachweisen will. Es gibt da keine Vorgaben. Es gibt ja nicht mal Vorgaben, was denn technisch genau zu tun ist. Selbst wenn ihr sowas wie eine QM-Zertifizierung hättet oder anstreben würdet, hättet ihr an der Stelle erhebliche Freiheitsgrade.

Pauschal klingt es sinnvoll, was du beschreibst. Viel mehr wird man an dieser Stelle nicht sagen können. Positiv finde ich vor allem, dass (und wie) du dir darüber Gedanken machst - Daumen hoch dafür.

Gruß, Nils

Moin,

Nein.

Wobei du alle realen Risiken für die Rechner ohnehin mit Backups abfedern musst. Wahrscheinlicher als irgendwelche Magie sind langweilige Ausfälle.

Gruß, Nils

Moin,

kriegt "Microsoft" auch hin. Völlig problemlos. Um das dann zu nutzen, ist die IT-Administration oder der Dienstleister gefragt. 

Gruß, Nils

Moin,

der Kennwort-Sync ist eine Krücke, die aus Sicherheitssicht möglichst schnell überwunden gehört. Viel sinnvoller ist ein Federation-Konzept, bei dem nur im internen Netz des Kunden die Kennwörter liegen und auch nur dort die Authentisierung gemacht wird. Insofern ist dein Hinweis auf andere Produkte unpassend (oder auch einfach falsch).

Gruß, Nils

Moin,

im übrigen gibt es bei Software natürlich weder "Neuware" noch "Gebrauchtware". Diese Analogien taugen nichts. Das sind ganz andere Wirtschaftsgüter und ganz andere Vertragsformen.

Und darüber hinaus bringen Diskussionen darüber in einem Forum wie diesem genau gar nichts. Tatsächlich würde nicht mal eine Diskussion mit einem versierten Anwalt irgendwas nützen. Wenn Microsoft der Meinung ist, dass der Kunde nicht richtig lizenziert hat, dann hat der Kunde ein Problem und in jedem Fall erhebliche Kosten. Da hilft auch ein Gericht nicht, das steigert nur das Kostenrisiko.

Gruß, Nils

Moin,

dann ist dein Verteiler nur von intern erreichbar. Er nimmt nur Mails von authentifizierten Absendern an. Wenn du das ändern willst, findest du das Häkchen dafür in den Eigenschaften des Verteilers.

Gruß, Nils

Moin,

sorry, euch das sagen zu müssen - aber ihr seid heftig auf dem Holzweg. Der Default Switch in Client Hyper-V (also unter Windows 10) ist nicht "Grütze", sondern sinnvoll. Es handelt sich um einen NAT-Switch, mit dem man VMs sehr einfach "ins Internet" bekommt, auch bei wechselnder Anbindung des Hosts (ein Notebook etwa ist ja manchmal über LAN und manchmal über WLAN verbunden). Den zu löschen, ist eine ganz, ganz blöde Idee.

Zu dem eigentlich gewünschten Szenario kann ich mangels eigener Erfahrung mit so einem Setup nichts sagen. Aber ihr seid falsch abgebogen. Wenn man den Default Switch nicht nutzen will, dann nutzt man ihn halt nicht. Hat man den mal entfernt oder manipuliert, bekommt man ihn kaum noch repariert.

Gruß, Nils

Moin,

tatsächlich kommen zwei heiße Kandidaten in der lokalen Suche, wenn man ins Suchfeld einfach "maus" eintippt.

Gruß, Nils

Moin,

jo, versteh ich. Schön sind dabei auch Kunden, die mal schnell mehrere Lösungen parallel eingeführt haben und sich darin nun verheddern.

Gruß, Nils

Moin,

"wenn man Teams richtig nutzen möchte", sollte man sowieso viel mehr als nur ein paar technische Details betrachten. Eine Teams-Einführung ist ein Organisationsprojekt, kein technisches.

Gruß, Nils

Moin,

wozu werden die Zertifikate verwendet? Wozu sollen die Werte da drinstehen?

Gruß

Moin,

in "einem Buch" zum Thema auf Seite 483. 

Dort habe ich dann vorgeschlagen:

Zitat

Sollten Sie sich dazu entschließen, die MAC-Adressen Ihrer virtuellen Maschinen statisch zu konfigurieren, sorgen Sie für eine adäquate Dokumentation der verwendeten Adressen. Die MAC-Adressen müssen nicht weltweit eindeutig sein, sondern nur innerhalb Ihres eigenen Netzwerks. Es spräche also nichts gegen ein Verfahren, in dem Sie sich an einem der MAC-Adress-Pools Ihrer Hyper-V-Host-Server orientieren, diesen durch Manipulation des letzten Bytes verkleinern und die so gewonnenen Adressen dann manuell statisch vergeben.

Und der Vollständigkeit halber hier noch der "Algorithmus" für den Pool. Da gibt es keine "Abstimmung".

Zitat

Den Pool, aus dem diese Adressen kommen, erzeugt Hyper-V bei der Installation des Host-Servers selbst. Das Prinzip bei der Erzeugung ist dabei recht simpel:

• Die ersten drei Bytes 00-15-5D sind das IEEE-Herstellerkürzel für Microsoft.
• Die nächsten beiden Bytes sind die beiden letzten Oktette der ersten IPv4-Adresse, die Hyper-V bei der Installation auf dem Host-Server ausgelesen hat.
• Das letzte Byte reicht von 00 bis FF, stellt also 256 Adressen bereit.

Gruß, Nils

Moin,

vor 1 Stunde schrieb NorbertFe:

Warum? Über die anfragende IP sollte sich eine Zuordnung doch entsprechend eingrenzen lassen.

damit sehe ich, dass ein bestimmter Computer anfragt. Ich habe aber keinen Hinweis, ob die Applikation dort "gut" konfiguriert ist oder "schlecht". Das muss ich auf dem System prüfen. Wenn das schon die gewünschte Erleichterung ist - prima. Mehr wird man aber nicht erreichen können.

Gruß, Nils

Moin,

dann haben wir bislang nicht aneinander vorbeigeredet. Es scheint mir eher so, als würden dir die Antworten nicht passen - was verständlich ist, weil es eben leider nicht so einfach ist, wie du dir das denkst.

In deinem Beispiel könntest du testen, ob du dort einfach den DNS-Namen der Domäne eintragen kannst und nicht den Namen oder die IP-Adresse eines DCs. Meist funktioniert das. Der DNS-Server gibt dann die Adresse eines der vorhandenen DCs zurück (vereinfacht gesagt nach Round Robin). Wenn dein AD also ordentlich gepflegt ist, machst du dich damit unabhängig von konkreten Servern.

Wo und wie du die Applikationen findest, wirst du selbst herausfinden müssen. Ob das Eventlog oder die Firewall dabei wirklich helfen, wage ich zu bezweifeln. Am Ende bleibt es so, wie ich oben geschrieben habe: Diese Stellen sehen nur, dass eine Verbindung stattfindet. Was dahintersteckt, können sie nicht unterscheiden.

Abschließend rate ich noch von dem Load-Balancer-Konstrukt entschieden ab.

Gruß, Nils

Moin,

dann ist mir das Problem nicht klar, das du lösen willst. Beschreibe bitte noch mal.

Und bitte nie-, nie-, niemals bei DCs mit Alias-Namen arbeiten. Das ist aus gutem Grund nicht supportet.

Gruß, Nils

Moin,

hm ... klingt alles nicht plausibel. Wenn der Hersteller VMs in Hyper-V unterstützt und keine Erfahrung mit Hyper-V-Clustern hat, aber Live Migrations zulässig sind - warum sollte er seine Software dann ausdrücklich den Regkey prüfen lassen?

Jans Hinweis dürfte die betreffende Schnittstelle abschalten, aber ich glaube nicht, dass es das ist.

Ergänzung: Falls die VM nach der Live Migration neu gestartet wird und keine Vorkehrungen getroffen wurden, hat sie nach dem Reboot eine neue MAC-Adresse auf jeder Netzwerkkarte. Die dynamischen MACs werden vom Host verwaltet und beim Starten einer VM zugewiesen. Abhilfe wäre dann, eine MAC statisch zuzuweisen.

Gruß, Nils

Moin,

mag sein, aber das hilft dir ja nicht. Du siehst dann, dass Computer X eine Abfrage gestellt hat. Ob Die Applikation auf Computer X aber auf einen festen Servernamen zugreift (und dann fehlschlägt, wenn es den Namen nicht mehr gibt) oder ob die Applikation den Namen aktuell aufgelöst hat, siehst du auf die Weise nicht,

Du wirst dir also die Applikationen auf den Endgeräten ansehen müssen. Da normalerweise eine Applikation X immer auf dieselbe Weise konfiguriert ist, auch wenn sie auf 2000 Clients eingerichtet wurde, ist der Prüf-Aufwand typischerweise nicht so groß. Der Aufwand zum Ändern kann aber schon beträchtlich sein.

Man könnte auch dem neuen DC einfach den Namen und die IP-Adresse des alten geben, sobald dieser entfernt wurde. Das ist aber keine Lösung des Problems, sondern verschiebt es nur in die Zukunft.

Gruß, Nils

Moin,

okay, danke für die Rückmeldung.

Das Konstrukt spricht jetzt wirklich nicht für die Software. Aber gut, wenn es dem Kunden das wert ist ... immerhin muss er sich keinen Mainframe hinstellen, auch wenn es nah dran ist.

Gruß, Nils