NilsK

Moin, musst du ja auch gar nicht. Du sollst dort angeben, welches Feld als Alternate Login ID verwendet werden soll. In dem Feld müssen dann die passenden Anmeldedaten stehen, die der Anwender nutzen soll. https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configuring-alternate-login-id Ob das dein organisatorisches Problem löst, lässt sich von außen nicht einschätzen. Gruß, Nils

Moin, diese Google-Abfrage sollte einige passende Treffer enthalten zu Grundlagen und Grenzen: https://www.google.de/search?q=office+365+alternate+login+id Gruß, Nils

Moin, na und? Dann forderst du für den anderen Host eben manuell ein Zertifikat bei der CA an. Gruß, Nils

Moin, ich verstehe auch nicht recht, wo jetzt das Problem ist. Wir haben ja nun einiges zu der Frage gesagt. Also noch mal ausdrücklich: Man kann ein AD problemlos mit einem Nicht-AD-DNS-Server betreiben, sogar mit einem BIND unter Unix. Es ist halt an einigen Stellen aufwändiger, aber es geht. Das ist ja aber, wenn ich das Szenario richtig verstehe, eigentlich auch nicht der Punkt, weil es hier ja nur um einen Secondary ginge. Der muss halt ausreichend aktuell sein, wozu man den Zonentransfer passend einrichten muss. Wenn jetzt noch was offen ist, bitte konkret fragen. Gruß, Nils

Moin, lass das Skript ein Protokoll schreiben, damit du siehst, was dort evtl. falsch läuft. Warum rufst du robocopy per PowerShell auf? Das macht einen Task nur unnötig kompliziert, daher würde ich an der Stelle ein Batch vorziehen. Gruß, Nils

Moin, das Zertifikat musst du dann in den Zertifikatsspeicher des Computerkontos einbinden. Da die Replikation im Zweifel ja eine beidseitige Angelegenheit ist, müssen beide Hosts je ein Zertifikat haben. Gruß, Nils

Moin, wenn ich es richtig sehe, beschreibt der folgende Artikel die Methoden zum Drucken. In VBScript sollte man dieselben Objekte und Methoden verwenden können. Bei .PrintOut kann man den Drucker ausdrücklich vorgeben. https://powerspreadsheets.com/excel-vba-print/ Gruß, Nils

Moin, das geht erst, wenn man die 2003-DCs aus der Domäne nimmt und den Domänenmodus hochsetzt. [Mehrere Kennwortrichtlinien in einer Domäne | faq-o-matic.net] https://www.faq-o-matic.net/2007/05/21/mehrere-kennwortrichtlinien-in-einer-domaene/ Seit Windows Server 2012 kann man diese Richtlinien dann mit GUI bearbeiten. Der Weg mit dem "Kennwort läuft nie ab" ist weder sinnvoll noch äquivalent, denn die Richtline umfasst auch die automatische Kontensperrung usw. Gruß, Nils

Moin, ah, OK. Danke für die Rückmeldung! Gruß, Nils ... what a difference a T makes ...

Moin, ja, die Vermutung ist zumindest nicht abwegig. Gruß, Nils

Moin, wenn du genau dieses INSERT-Kommando im SQL Studio ausführst, kommt dann auch der Fehler? Gruß, Nils

Moin, funktioniert es, wenn du den User aus der Admingruppe nimmst und neu anmeldest? Es gibt vereinzelt Berichte, dass Apps als Admin nicht starten. Möglicherweise hilft auch sowas: http://home.bt.com/tech-gadgets/computing/windows-10/has-your-windows-10-start-menu-stopped-working-here-are-four-ways-to-fix-it-11364000314532 Gruß, Nils

Moin, was genau ist jetzt das Problem? Geht es um die Millisekunden? Laut https://docs.microsoft.com/en-us/sql/t-sql/data-types/datetime-transact-sql?view=sql-server-2017 sollte als Trenner auch der Doppelpunkt akzeptiert werden, geht das von deinem VS-Code aus? Gruß, Nils

Moin, Client-Installationen erledigt man nicht als Domänen-Admin. Der ist zum Administrieren des AD da, für nichts sonst. User bekommen keine lokalen Adminrechte. Dafür gibt es separate Konten. Sind User lokale Admins, ist das gesamte Netzwerk aktiv gefährdet. Was genau passiert, wenn der User Apps zu starten versucht? Kann der User "normale" Programme starten? Gibt es sonst Auffälligkeiten? Gruß, Nils

Moin, auch das gehört zu den Grundproblemen der Mailverschlüsselung, die eine Verbreitung der Technik effektiv verhindern. Wie mwiederkehr schon sagt, kann man grundsätzlich das bestehende Zertifikat mit dem bestehenden Private Key verlängern - dann nutzt man dieses Zertifikat auch, um auf die "alten" Mails zuzugreifen. Es kann aber sein, dass man diese Form der Verlängerung nicht nutzen kann, weil z.B. die CA das nicht zulässt. In dem Fall muss man den privaten Schlüssel selbst archivieren, um ihn bei Bedarf zu nutzen. Dass das Zertifikat irgendwann abgelaufen ist, ist in dem Szenario nicht von Relevanz. Den privaten Schlüssel zu archivieren, ist ohnehin notwendig, denn der kann ja vom System verloren gehen (Profil gelöscht, Rechner kaputt ...) - lösen muss man das Problem also ohnehin. Sobald man Ende-zu-Ende verschlüsselt, wird es kompliziert und aufwändig. Das lässt sich nicht ändern. Daher prüfe man genau, ob man das wirklich braucht und baue vorher (!) die zugehörigen Prozesse auf. Bei der Gateway-Verschlüsselung darf man übrigens berechtigt die Frage stellen, welchen Vorteil man gegenüber der reinen Transportverschlüsselung hat. Das hängt vom Szenario ab, aber auch hier sollte man den Bedarf prüfen. Gruß, Nils

Moin, typischerweise führt eine Betrachtung, die das lokal Vorhandene 1:1 in die Cloud überträgt, in die Irre. Einerseits hat man meist lokal viel mehr "Dampf", als man tatsächlich braucht (was in der Cloud praktisch nie nötig ist), andererseits ist der Witz an der Cloud, dass man dort (fertige) Dienste beziehen kann und nicht alles auf Basis von VMs selbst machen muss. Auf der anderen Seite muss man, wenn man tatsächlich etwas wie Terminalserver in der Cloud bereitstellen will, auch die Infrastruktur als Dienst berücksichtigen (etwa die AD-Anbindung). Eine einfache Antwort wird man dir also nicht recht geben können - nur dass eben diese 1:1-Betrachtung aus Kostensicht meist sehr ernüchternd ist, weil "die Cloud" dann sehr teuer aussieht. Lass dich in Ruhe von jemandem beraten, der dir auch konzeptionelle Wege aufzeigen kann, dann bekommst du ein realistischeres Bild. Gruß, Nils

Moin, wer führt hier wen aufs Glatteis? Microsoft sagt an vielen Stellen sehr deutlich, dass Pass-through Disks nicht empfohlen sind. Den Support dafür einzustellen, hieße aber, dass Kunden, die das nutzen, auf einen Schlag ein Problem haben - kaum angemessen. Zumal die Technik ja nicht irgendwie fehlerhaft ist, sondern die Einschränkungen prinzipieller Natur sind. Genau wie mit RDMs bei VMware. Zu deiner anderen Frage lässt sich auf diesem Abstraktionsgrad nicht mehr sagen als "kann sein, muss aber nicht". Gruß, Nils

Moin, du sagst ja, dass dir die Argumente gegen Pass-through Disks bekannt sind. Viel mehr gibt es dazu eigentlich auch nicht zu sagen. Rein technisch geht es, auch in Cluster-Konstrukten. Die Nachteile und Fehlermöglichkeiten sind aber so umfangreich, dass man das nicht machen will. Für Guest-Cluster nutzt man üblicherweise per iSCSI (oder seltener vFC) in die VMs eingebundene LUNs. Oder man setzt auf Shared-VHDX (2012/R2) bzw. VHD Sets - von denen liest man aber leider auch oft, dass sie nicht so zuverlässig sind, wie man das braucht. Wie ist denn das Storage bei dem derzeitigen physischen Cluster angebunden? Wenn es eine LUN aus dem Storage ist, kann man die vielleicht sogar so lassen, wie sie ist, um sie an die VMs durchzureichen. Gruß, Nils

Moin, dann sag das doch gleich. Leider ist es in Foren üblich, nur eine Detailfrage zu stellen, statt zu sagen, worum es geht. Das behindert die Sache unnötig - der Thread hätte schon viel schneller eine Antwort liefern können. Also: Natürlich geht das, es ist in solchen Szenarien sogar durchaus üblich. Du kannst einen DNS Secondary einrichten, der sich die DNS-Daten (und nur diese) von einem DC/DNS holt. Solange es sich um einen Nur-Lese-Zugriff handelt, ist das auch ein gangbarer Weg. Ob sich damit allerdings die Anforderungen erfüllen lassen, lässt sich aufgrund der eher unscharfen Äußerungen dazu nicht ablesen. Der beschriebene Secondary würde alle DNS-Einträge enthalten und abfragbar machen, da können durchaus personenbeziehbare Daten dabei sein (z.B. Namen von PCs, die zu bestimmten Mitarbeitern gehören - etwa "PC-MEYER"). Hier wäre also ggf. ein Blick auf die genauen Anforderungen und die Details der Umgebung relevant. Gruß, Nils

Moin, das kommt darauf an, wie das Storage die Disk bzw. LUN bereitstellt. Theoretisch könnte man die LUN im Storage als Cluster-LUN definieren und dann an zwei Hosts anbinden, um sie von dort aus als Pass-through in VMs weiterzuleiten. Voraussetzung ist dann allerdings, dass die VMs den Zugriff so koordinieren, dass keine gleichzeitigen Schreibzugriffe nötig sind - was in der Praxis bedeutet, dass die VMs einen Cluster bilden müssen (sofern wir von Windows sprechen). In dem Fall wäre es aber nicht sinnvoll, mit Pass-through zu arbeiten - wenn es eine Cluster-LUN im Storage gibt, sollte man die stattdessen über iSCSI oder vFC direkt an die VMs anbinden, statt den (fehlerträchtigen) Umweg über die Hosts zu gehen. Mit lokalen Disks dürfte das überhaupt nicht mögllich sein. Geht es nur um einen Host und lokale Disks, dann bedeutet das Zuweisen einer Pass-through Disk, dass diese exklusiv der betreffenden VM zur Verfügung steht. Jetzt wäre natürlich wichtig zu wissen, was denn die dahinterstehende Anforderung ist ... Gruß, Nils

Moin, vielleicht können wir hier ja einfach mal das Missverständnis aufklären. Die lokalen Peer-to-Peer-Updates sind für Netzwerke gedacht, in denen es keinen WSUS gibt. Kleine Netze oder z.B. kleine Außenstellen. Da spart man Traffic und eben den Aufwand eines WSUS. Wenn ein WSUS vorhanden und gut angebunden ist, ergeben die Peer-to-Peer-Updates keinen Sinn. Gruß, Nils

Moin, das verstehe ich durchaus. Aber dafür ist die verfügbare Bandbreite sehr wahrscheinlich zu knapp, um wirklich ein zuverlässiges Verfahren dieser Art aufzubauen. Es bringt ja auch nichts, wenn wegen der Einschränkungen ständig manuell nachgebessert werden muss und man sich im Fall des Falles nicht darauf verlassen kann. Daher würde ich, wenn ich verantwortlich wäre, die Idee nicht weiter verfolgen, jedenfalls nicht, wenn die Änderung der Rahmenbedingungen keine Option ist. Gruß, Nils

Moin, und die 20 Mbit sind übrig? Oder hat der Kunde die evtl. deshalb, weil er sie bereits braucht, z.B. für "Internet"? Nee, da wird kein Schuh draus. Für was für ein Desaster plant ihr denn, dass es ein anderer Standort sein soll? Und wenn das eintritt, können die Leute in der Zentrale dann wirklich noch arbeiten? Was macht der Kunde, wenn kein Ausfall vorliegt, sondern ein logischer Fehler, der Original und Replikat beschädigt? Falls in dem Fall das Recovery vom Backup reicht, warum nicht in anderen Fällen? ... so die Richtung ... Gruß, Nils

Moin, und was genau sagt er auf den Hinweis, dass selbst mit einem Kennwort auf dem Dateiserver ohne die Sperrung des Desktops jeder auf die lokalen Daten seines Rechners zugreifen kann? Sollte es sich hier um den einzigen User weltweit handeln, der nur auf dem Dateiserver arbeitet und keine Daten lokal hält? Gruß, Nils

Moin, der Beschreibung nach sollte Get-WinEvent in der PowerShell auch mit den Dateien klarkommen. Vielleicht geht's damit. Gruß, Nils