NilsK

Moin,
 
schon seit zehn Jahren reicht es aus, einen verwaisten DC im ADUC zu löschen. Danach noch im Standorte und Dienste sowie im DNS entfernen.
 
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,
 
die Computerrichtlinien gelten immer nur für die lokalen Konten des jeweiligen Rechners. Möchte man die Einstellungen für die Konten des AD vornehmen, dann geht das nur in einem GPO, das auf der Domänenebene definiert ist - und nur dort. GPOs auf OU-Ebene wirken nicht auf die Kennworteinstellungen von AD-Konten, sondern würden sich nur auf die lokalen Konten der Computer auswirken, deren Konten in der betreffenden OU gespeichert sind.
 
Aufgrund diverser Effekte sollten die Kennworteinstellungen für das AD ausschließlich in der Default Domain Policy definiert werden, nicht in einem eigenen GPO auf Domänenebene.
 
Die Einstellung "Kennwort läuft nie ab" bei einem Useraccount übersteuert für diesen einen Account das maximale Kennwortalter, das per Policy gesetzt ist. Gedacht ist das vor allem für Dienstkonten, damit nicht urplötzlich der SQL Server wegen eines Anmeldefehlers stehenbleibt. Alle anderen Einstellungen der Policy gelten dann aber weiter. Dies betrifft sowohl lokale als auch AD-Konten.
 
Gruß, Nils
 

Moin,
 
eiserner Grundsatz: Egal, mit welchem Hypervisor die Hosts laufen, werden niemals Windows-VMs lizenziert, sondern immer nur der Host. Auf diesem muss die eingesetzte Lizenz alle VMs mit umfassen.
Die Standard Edition umfasst zwei VMs (bei Mehrbedarf weist man mehrere Lizenzen dem Host zu), die Datacenter Edition beliebig viele.
 
Sofern der Satz
also bedeutet, dass einzelne Windows-Lizenzen für die VMs vorliegen, so ist das falsch lizenziert.
 
Eine "OEM-Lizenz" ist hinsichtlich ihrer Einsetzbarkeit i.d.R. eingeschränkt. Solche Lizenzen dürfen auch nur mit einer neuen Hardware vertrieben werden, also dürfte schon hier ein Lizenzverstoß in dem gegenwärtigen Vorschlag vorliegen. Ob diese OEM-Lizenz (die ja wie alle Lizenzen der Hardware zugewiesen ist) auch laufende VMs abdeckt, müsste man dann ggf. in deren Lizenzvertrag nachlesen (vermutlich ja).
 
Damit sind deine Fragen 1 bis 3 eigentlich obsolet. Die VMs selbst haben keine Lizenzen, sondern der Host muss diese haben. Im Falle eines Clusters müssen auf jedem Host so viele "inkludierte" VM-Lizenzen vorliegen, dass alle (Windows-Server-) VMs zu jeder Zeit auf allen Hosts vollständig lizenziert sind (was auch Frage 4 betrifft).
 
Wie 2019 die dann aktuelle SQL-Server-Lizenzierung aussieht, weiß selbst Microsoft noch nicht. Aktuell ist es so, dass die Lizenzmobilität für SQL Server (und Exchange) nur mit aktiver SA für die Applikationslizenz gegeben ist.
 
Mehr dazu:
https://www.youtube.com/watch?v=6tH3QGSRP00
 
Frage 6: Ja, geht, ist aber umständlich.
Frage 7: Kann ich aus dem Kopf leider nicht sagen. Aber ihr wollt ohnehin über das Konstrukt noch mal nachdenken. (Wenn dir der Hinweis zu abstrakt ist, ist das ein Kennzeichen dafür, dass ihr externe Beratung braucht. Ist nicht arrogant gemeint, sondern ernst.)
 
Gruß, Nils
 

Moin,
 
ja, leider ist das manchmal etwas anstrengend, eine Subdomäne loszuwerden. Auf schnellen Blick scheinen mir die Schritte zu passen, die der folgende Artikel angibt:
 
https://blog.runas.me/2014/10/27/ntudstil-remove-stubborn-domain/
 
Gruß, Nils

Moin,
 
Remote-Abfragen per WMI brauchen Adminrechte. Möglicherweise kann man das ändern, aber das wird auch Adminrechte brauchen.
 
Gruß, Nils

Moin,
 
eine direkte Einbindung der Virtual FC kann natürlich performanter sein. In geschätzt 99 Prozent aller Umgebungen kommt es auf diesen kaum messbaren Unterschied aber gar nicht an. Dafür ist eine vFC-Anbindung dann auch sehr komplex und erfordert spezielle Features in der FC-Infrastruktur. Das ist prinzipiell in vSphere und Hyper-V identisch.
 
Leg die virtuellen Disks auf das CSV, dann macht der Cluster alles, was du brauchst. Die Performance reicht aus, sofern das Storage leistungsfähig genug ist. Sollte es das nicht sein, dann würde es auch mit vFC nicht reichen.
 
Gruß, Nils

Moin,
 
du musst nun das Root-Zertifikat neu veröffentlichen und an der passenden Stelle ablegen. Die Daten brauchst du auch für die Root-CA, damit Clients sie überprüfen können. Best Practice ist, eine zentral erreichbare Stelle für all diese Daten auf einem Webserver zu haben (per http erreichbar, nicht per https, damit keine Zertifikatsprüfungsschleife entsteht).
 
Gruß, Nils

Moin,
 
für den Zweck ist eine herkömmliche Freigabe (SMB) geeignet, iSCSI nicht.
 
iSCSI ist eine blockorientierte Punkt-zu-Punkt-Verbindung zwischen genau einem Rechner und genau einem Volume (genauer: einer LUN). Eine solche LUN einem anderen Rechner zuzuweisen, ist ein Ausnahmefall und erfordert genaue Kontrolle des Vorgangs.
 
Gruß, Nils

Moin,
 
ja, seit geraumer Zeit werden DNS-Zonen in einer eigenen Partition gespeichert. Die bei dir noch in der Domänenpartition vorhandenen Zonen dürften älteren Datums sein.
 
Wenn du in ADSI Edit den Eintrag "rootDSE" verbindest und in dessen Eigenschaften schaust, siehst du unter namingContexts die vorhandenen AD-Partitionen. Die kannst du dann wiederum in ADSI Edit öffnen, um die Zonen und deren DNs ausfindig zu machen.
 
Gruß, Nils

Moin,
 
nein, so etwas sieht Outlook nicht vor.
 
Gruß, Nils

Moin,
 
und selbst wenn es das könnte, wäre Norberts Frage ja noch zu klären, was denn das werden soll. Also @calimero92, bitte beschreib mal, was du eigentlich vorhast.
 
EDIT: OK, hat sich überschnitten.
In dem Fall musst du einen Cluster einrichten. Die Details dazu finden sich in der Literatur, grundsätzliches Vorgehen:
 
Alle drei Hosts grundinstallieren Auf allen Hosts Hyper-V installieren und grundkonfigurieren LUNs an den ersten Host anbinden auf dem ersten Host den Failover-Cluster einrichten und die LUNs als Cluster-Storage einbinden LUNs den anderen Hosts präsentieren, dort aber nicht online nehmen Die anderen Hosts dem Cluster hinzufügen Die Cluster-LUNs in CSVs konvertieren  
Gruß, Nils

Moin,
 
versuch mal:
foreach ($ExportUser in $MailExportUser.AcceptMessagesOnlyFrom) Du hast es ja mit einer Eigenschaft des ursprünglichen Objektes zu tun, die ihrerseits Objekte enthält.
 
Gruß, Nils

Moin,
 
dafür brauchst du eine eigene Zertifikatsvorlage und musst den Prozess dann manuell durchführen. Der vordefinierte Prozess geht nur mit AD-Mitgliedern.
 
[Windows-PKI: Computerzertifikat manuell anfordern | faq-o-matic.net]
https://www.faq-o-matic.net/2017/09/13/windows-pki-computerzertifikat-manuell-anfordern/
 
Gruß, Nils

Moin,
 
na, da steht es doch auch noch mal ausdrücklich dabei: Der WAP kann entweder "claims-based" ADFS oder Kerberos. Wenn Kerberos, dann Domänenmitgliedschaft. Wenn Claims-based ADFS, dann keine Domänenmitgliedschaft.
 
Für die Auswahl der passenden Authentifizierung ist das gewünschte Szenario wichtig: Wer soll denn von wo aus auf den Exchange zugreifen? Vermutlich geht es ja um den Zugriff von außen, wo der User ohnehin kein Kerberos-Ticket übermitteln kann. Da ist dann Claims-based ADFS das Mittel der Wahl: Der User bekommt eine Anmeldeseite von ADFS präsentiert, an der er sich mit seinem Domänenkonto anmeldet. Damit erhält er ein SAML-Token und kann dann auf den Exchange zugreifen. Und dafür muss der WAP kein Domänenmitglied sein, weil er dann nur Reverse Proxy für den ADFS-Server im LAN spielt.
 
In dem von dir beschriebenen Artikel wird zwar Kerberos verwendet - aber da der User eben nicht mit einem gültigen Kerberos-Ticket ankommt, muss WAP dann doch die Anmeldeseite des ADFS anzeigen. Also kein Vorteil für den User, dafür ein Nachteil für die Sicherheit (weil eben der WAP Domänenmitglied sein und daher mit dem DC im LAN kommunizieren muss). Man könnte auch sagen: Hübscher Artikel, aber am Thema vorbei.
 
Um Claims-based ADFS zu machen, dürfte diese Anleitung hilfreich sein:
https://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx
 
Gruß, Nils
 
 
Gruß, Nils

Moin,
 
ein Zertifikat weist nach, dass der Name wirklich zu dem Server gehört. Naheliegenderweise funktioniert das nicht, wenn ein Name zu jedem Computer gehört. Auf ein Zertifikat gehört ein eindeutiger FQDN, nichts anderes.
 
Nicht zuletzt aus diesem Grund stellen kommerzielle CAs seit einigen Jahren keine Zertifikate mehr für Namen aus, die nicht zu einer öffentlich erreichbaren Domain gehören.
 
Gruß, Nils

Moin,
 
OK, dann könnte man in die Richtung Vertrauensstellung und gemeinsamer Tenant überlegen.
 
Gruß, Nils

Moin,
 
nein, das Management von IPv6 funktioniert vollständig anders als das von IPv4. Versuche nicht, die bekannten Mechanismen zu übertragen, das wird nicht gehen.
Zum Thema Speedport und IPv6 findest du hier im Board schon einiges.
 
Kurze Erläuterungen zu IPv6 sind nicht zielführend. Ich finde das Buch "Practical IPv6 for Windows Administrators" von Edward Horley sehr nützlich. Muss man sich aber Zeit für nehmen, und da rede ich nicht von ein paar Stunden.
 
Gruß, Nils

Moin,
 
vor 15 Monaten hat Microsoft die Anwendungslogik geändert.
 
https://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/
 
Gruß, Nils

Moin,
 
Windows schaut hier auf das Backup-API des Systemstate. Wenn dort keine aktuelle Sicherung verzeichnet ist, kommt diese Meldung. Ob man Veeam so konfigurieren kann, dass es das API passend bedient, weiß ich nicht. Die Frage wäre im Zweifel an Veeam zu stellen.
 
Allgemein empfehle ich, das AD aufgrund seiner Bedeutung stets auf mindestens zwei Arten zu sichern: Einmal mit dem Systemstate und einmal mit dem "sonst" eingesetzten Tool. So gibt es im Zweifel immer eine Sicherung, die auch von Microsoft von vorn bis hinten unterstützt wird.
 
Gruß, Nils

Moin,
 
ja, das wird nicht funktionieren. Zum Umbenennen, wenn kein Exchange genutzt wird, könntest du rendom nutzen. Alternativ müsstest du in eine neue Domäne migrieren.
 
rendom funktioniert bei manchen völlig problemlos, bei anderen nicht. Ein gewisses Risiko besteht. Das würde ich mit jemandem in Ruhe bewerten, der sich mit der Materie gut auskennt.
 
Gruß, Nils

Moin,
 
dass es klappen kann, wenn du viel Glück hast, wurde dir hier schon gesagt. Dass der Aufbau erfahrungsgemäß nicht besonders zuverlässig sein wird, haben wir auch schon geäußert.
 
Mehr Sinnvolles kann man dazu nicht sagen. Ich bin dann mal raus.
 
Gruß, Nils

Moin,
 
also: Es geht hier um die Lizenzen, nicht um die Aktivierung.
 
Du hast eine Datacenter-Lizenz gekauft und darfst damit beliebig viele Windows-Server-VMs mit dieser Version und der Datacenter Edition betreiben. Ältere Windows-Server-Versionen sind dann zulässig, wenn deine Lizenz ein Downgrade-Recht enthält. Da Standard und Datacenter im Wesentlichen funktionsgleich sind (mit Ausnahme einiger Storage-Features in Datacenter), ist es für nahezu alle Anwendungen technisch egal, welche der Editionen du nutzt. Meist empfiehlt man daher, auch in den VMs die (bereits lizenzierte) Datacenter Edition zu nutzen.
 
Rein lizenzrechtlich ist es m.W. auch zulässig, in den VMs die Standard Edition einzusetzen, wenn der Host mit Datacenter lizenziert ist. Das kann in speziellen Situationen ein Vorteil sein, wenn man etwa einen Host-Ausfall hat und eine VM auf einem Host bereistellen muss, der nur mit Standard lizenziert ist - läuft in der VM auch Standard, dann ist das konform. Ob man das so braucht, steht auf einem anderen Blatt. Ich empfehle meist, Datacenter in den VMs zu installieren, wenn man Datacenter lizenziert hat. Das auch deshalb, weil man meist ja gar keinen Standard-Key hat ...
 
Früher gab es meiner Erinnerung nach mal eine Einschränkung, dass nur eine der VMs mit Standard laufen durfte, aber das gilt, glaube ich, nicht mehr. Habe in den Product Terms auf die Schnelle jedenfalls nix dazu gefunden.
 
Gruß, Nils

Moin,
 
 
ah, OK, das erklärt es. Wenn die SAMAccount-Namen verschieden sind und die Gruppen in verschiedenen OUs liegen, kann der Objektname tatsächlich gleich sein. Dann sind die DNs ja unterschiedlich.
 
Gruß, Nils

Moin,
 
kurz: das geht nicht. Jede Hyper-V-Version hat eine feste VM-Version, die sich nicht absenken lässt. Eine VM, die auf 2012 R2 läuft, kannst du nur auf einen anderen 2012 R2 oder auf einen 2016 verschieben. Das ist auch unabhängig von der Methode (Export, Backup oder wie immer). Erst mit Windows Server 2016 hat Microsoft diesen Mechanismus angepasst, sodass ein 2016-Host eine verschobene VM nicht automatisch anpasst. Dadurch kann man eine 2016-VM auf einen 2012-R2-Host verschieben, aber eben auch nicht weiter in den Versionen zurück.
 
[Das Geheimnis der VM-Version in Hyper-V | faq-o-matic.net]
https://www.faq-o-matic.net/2014/12/01/das-geheimnis-der-vm-version-in-hyper-v/
 
Als Workaround könntest du die VHDX-Datei deiner VM nehmen und versuchen, ob du diese in eine VHD-Datei konvertieren kannst. Diese VHD-Datei könntest du dann (mit etwas Glück) an eine neue VM anhängen, die du auf dem 2008 R2 erzeugst.
 
Gruß, Nils