meinerjunge

Danke Norbert, dass hat geholfen. Anschließend müssen nur noch die Rechteeinstellungen überprüft werden, auch die der Vorlagen. Hier beschrieben: Event ID 91 — AD CS Active Directory Domain Services Connection | Microsoft Learn Bzgl. nicht Sichtbarer Vorlagen: https://www.gradenegger.eu/?p=3916 Vielen Dank!

Hallo Forum, nach dem Umzug unserer Domain CA auf einen neuen Server, erhalte ich bei Anfrage auf die CA, von einem Domain-Member (DC oder normaler Server), immer die Fehlermeldung: Die Zertifikatregistrierung für Lokales System konnte sich nicht für ein Zertifikat DomainController mit der Anforderungs-ID N/A von CAServer\CAName (Der RPC-Server ist nicht verfügbar. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)) registrieren. Die Berechtigung für den PKIEnrollmentService habe ich bereits neu gesetzt, die Zertifikatvorlage (hier für den DC) sehe ich beim beantragen. Firewall und Netzwerkeinstellungen passen soweit. Lokal auf dem CAServer funktioniert auch alles. Kann mir einer von euch einen Tipp geben wonach ich noch schauen kann? Vielen Dank! MfG Meiner

Hat bei uns auch keiner absichtlich bzw. wissentlich gemacht (intern wie extern). Aber irgendwer hat sich bei MS mit unserer Domain als Mail-Adresse (Arbeitskonto) registriert und dann hatten wir den Salat. Einzige Lösung laut MS-Support, war die Autorisierung unserer Domain. Edit: Selben Fehler/Fehlerbild erhielt ich auch

Hallo, das gleiche Problem hatten wir auch. Ich versuch es mal zusammen zu bekommen (Achtung kann falsch sein) Eure Domain scheint mit Office365 verknüpft zu sein (Arbeitskonto) aber noch nicht autorisiert. Ich habe mich damals bei Office365 registriert und dann unsere Domain autorisiert. Auszug aus einer Mail vom Support welche ich gefunden hab. "Versuchen Sie nach der Registrierung, auf das Office 365 Portal zuzugreifen. Wenn Sie angemeldet sind, sollten Sie aufgefordert werden, den TXT-Datensatz als Administrator einzugeben." Administratorübernahme eines nicht verwalteten Verzeichnisses – Azure AD | Microsoft Docs Diesen dann im Domain DNS eintragen. MfG Meiner

Ich hab das aus der Erklärung im Gruppenrichtlinienverwaltungs-Editor (ist wohl mal wieder schlecht übersetzt): Dann mach ich mich mal auf die Suche nach einem Tool. Vielen Dank an alle! MfG Meiner

Da hab ich ja was losgetreten.. Also noch mehr Zeichen sind besser als mehr Zeichen, das ist klar. Aber mit den Komplexitätsvoraussetzungen komme ich dann trotzdem nicht weiter, da diese ja auch beinhalten "Das Kennwort darf nicht den Kontonamen des Benutzers oder mehr als zwei Zeichen enthalten, die nacheinander im vollständigen Namen des Benutzers vorkommen.". Wie soll man das bei einer Zeichenlänge von 10+ verhindern? D.h. ich kann diese Komplexitätsvoraussetzungen in der Richtlinie nicht aktivieren und dann auch nicht verhindern, das jemand 20 x ein "a" als Passwort vergibt. MfG Meiner

Großbuchstaben, Kleinbuchstaben, Zahlen, min 1 Sonderzeichen und min 10 Stellen Die Komplexitätsvoraussetzung verlangt ja nur 3 der 4 Zeichenarten.

Unsere Vorgabe beinhaltet leider beides.

Ok, hätte es wohl besser so schreiben sollen. "Bo(a)rdmittel" Eine Azure Anbindung ist nicht vorhanden. Es geht vor allem um schützenswerte Konten welche mit hochkomplexen und langen Passwörtern versehen sein sollen. Was gibt es denn da für kommerzielle Software und ggf. Community-Projekte? MfG Meiner

Hallo Forum, gibt es eine Möglichkeit die Komplexitätsvoraussetzungen in den Gruppenrichtlinien (mit "Boardmittel") zu editieren, die von MS vorgegebene Einschränkungen sind uns zu "dünn". Vielen Dank! MfG Meiner

Nunja, den neuen KMS kann ich ja per Telefon aktivieren, den Migrierten ja eben nicht. VM herunter gefahren, auf gemeinsamen Share migriert, dann auf dem neuen Cluster die VM registriert (Option verschobene VM angeklickt) und die Tools aktualisert. Fertig.

Hallo Forum, Ergebnis nach der Migration des Server mit KMS-Rolle auf den neuen ESX-Cluster ist wie folgt. Das Server-OS, der KMS und alle eingetragenen Schlüssel (Office usw.) sind nicht mehr lizenziert bzw. aktiviert. -> keine Aktivierung der Clients per KMS mehr Möglich Eine tel. Aktivierung des KMS ist nicht mehr möglich (Windows kann nicht tel. aktiviert werden - Wenden sie sich an den Admin...) Onlineaktivierung geht auch nicht, da hinter einem Proxy. (mag MS wohl nicht) Man benötigt wohl direkt Access zum Interwebs (netsh winhttp.... hilft auch nicht) Konsequenz: KMS aus dem Backup wieder auf den alten Cluster zurück geholt. -> läuft glücklicherweise noch Muss ich wohl einen neuen KMS auf dem neuen ESX-Cluster installieren. Das dauert genau so lang, wie das Erlangen der Erkenntnis, dass das Migrieren nicht geht. MfG Meiner

Danke für Eure Antworten. MfG Meiner

Hallo, es ging mir nicht primär um die VM nach dem umhängen, sondern um den KMS, ob dieser dann auf der neuen Hardware ohne Probleme startet oder neu registriert/aktiviert werden muss. Weil wenn dieser nicht läuft, kann ich ja gleich einen neuen aufsetzen. Denn zu diesem Thema ist google relativ maulfaul und bietet einem zu 99% einen so genannten KMS-Activator an. MfG Meiner

Das mein ich mit "wenn´s klemmt".