Dutch_OnE

Und wie sieht das mit Teams und einer Office 365 Mail-Adresse von einer eigenen Domäne mit eigenem Exchange aus? Kann man das machen, oder passiert dann solche Nebeneffekte, dass z.B. am Exchange keine Mails mehr ankommen?

Erstmal Danke für den Tipp. Dann frage ich nochmal anders. Ein Bekannter meinte folgendes erlebt zu haben. einer seiner Kunden hat so einen Account auf seine vorname.nachname@firma.de Adresse registriert. Nun erstellt Microsoft ja dafür ein eigenes Mailkonto. Danach sollen dann an seiner eigentlichen Mail-Adresse keine E-Mails mehr eingegangen sein. ich kann das nicht glauben, denn der MX für firma.de zeigt ja weiterhin auf einen bestehenden Mailserver. Deswegen, die Frage, ob man den Office Key nicht lieber mit einer "pseudo Mailadresse" im Microsoft Account registrieren sollte. (Also anstatt seine echte Adresse in dem Microsoft Account zu verwenden)

Moin, bei den neumodischen Office Versionen (kein 365), muss man sich ja mit einer E-Mail Adresse registrieren, damit man sich das Installer Paket herunterladen kann. Nimmt man dafür jetzt eine generischen Account, oder verwendet man dafür seinen eigenen Mail-Account? Dieser Account bekommt doch bei Microsoft eine Mail-Funktion und aus meiner Sicht ist die selbe Mailadresse auf 2 verschiedenen Mailsystemen problematisch. Wie macht Ihr das immer? Gruß DO

Moin, bei einem Domänenrechner (W11) und einem bei allen anderen Clients funktionierenden Split-DNS, zeigt der W11 grundsätzlich die externe Adresse und nicht die interne an. Alle W10 Rechner dagegen zeigen die interne an. Der Tip, den DHCP nicht zu verwenden hat nichts gebracht. Hat Jemand eine Idee? Gruß DO

Nach Update von Windows auf neuesten Stand 22H2, wurde der Key sofort akzeptiert.

Gutes Argument. Ich habe auch noch gelesen, dass bestimmte Builds das nicht zulassen. Das teste ich nochmal, aber mit der Lizenz muss ich dann wohl neue W10 kaufen.

Moin, ich habe auf einem Windows Hyper-V Server eine VM mit Windows 10 Pro erstellt. Image von Microsoft. Beim Lizensieren bekomme ich aber keinen einzigen W7 Key aktiviert. Fehlercode: 0xc004f050 Geht das nicht mehr? Gruß DO

Tatsächlich habe ich gerade unter das Notebook geschaut. Da steht 07/2017 ... Wo ist nur die Zeit geblieben??? Dann wird wohl spätestens im kommenden Jahr was Neues fällig.

Also ist das tatsächlich so in Ordnung. Der Rechner wird dann bei aber merklich langsamer. I5 Gen7 mit 8GB RAM und SSD. Wollte eigentlich kein neues NB kaufen.

Moin, ist das normal, dass die Ege Prozesse von alleine immer mehr werden und die Speicherauslastung irgendwann das System langsamer werden lässt? Ich habe vielleicht 5 Tabs auf, aber eben z.B. 22 Edge Prozesse gehabt. Gruß DO

Microsoft hat gesagt, dass es deren Fehler ist und der bald gepatched wird. Danach habe ich dann aufgehört. Hat wohl was damit zu tun, dass das Ticket zur Passwortänderung ausgestellt, aber nicht genutzt wird.

Zu Testzwecken hat jeder Vollzugriff

Moin, ich möchte ein Kennwort von einem Cluster Computerkonto über die Repair Funktion updaten. Als Ergebnis kommt immer ein Access Denied 0x80070005. Daher habe ich einen Wireshark mitlaufen lassen. Dort sehe ich z.B. die LDAP Pakete und dass das Computerkonto auch gesucht / gefunden wird. Leider kann ich aber nichts über den Access Denied finden. Jemand eine Idee, wie ich weitere Infos über den Fehler / Grund bekomme. Mein Account hat Vollzugriff auf das CNO und das VCO Objekt. Gruß DO

Wir haben ein Ticket bei Microsoft eröffnet. Laut denen soll das gepatched werden. Zur Zeit ist nur ein Workaround möglich. Zu 95% muss ein lokale Sicherheitsrichtlinie angepasst werden. Wir sind natürlich die anderen 5%. Auch mit Wireshark ist nichts zu erkennen. Aktuelle Fehlermeldung beim manuellen Repair des Clusters: The specified directory service attribute or value does not exist

Alles klar. Dann bin ich erstmal etwas beruhigt und kann mich in Ruhe dem Problem widmen. Danke

OK, das Thema Vertrauensstellung an sich, hat sich dann erledigt. d.h. dass der Cluster, der ein Problem hat sein Kennwort zu ändern, auch nicht runterfällt, da sein lokales Kennwort immer noch das selbe ist, wie in der Domäne?

Zu Frage 1 habe ich noch gefunden, dass das Computerkonto willkürlich die Änderungen durchführen kann. Zu Frage 2, muss es doch einen Wert geben, ab wann die Vertrauensstellung verloren geht oder nicht? Irgendwann kommt ja die Meldung Macht es einen Unterschied ob das System 24/7 online im Netz ist, oder ein Gerät nur ab und zu mal an ist? Bezogen auf einen Fehler beim Kennwort ändern.

Moin, per Default sollte das Intervall in einer Domäne doch auf 30 Tage eingestellt sein. 1) Ab welchem Tag versucht das Computerkonto sein Kennwort zu ändern? Versucht er das beispielsweise schon ab Tag 15? 2) Was passiert nach 31 Tagen oder Änderung? Kann sich das System dann nicht mehr anmelden, da die Vertrauensstellung nicht mehr hergestellt werden kann? 3) Konkretes Beispiel. Ein System (in diesem Fall ein Windows Cluster) hat eine Fehlermeldung, dass sich die Passwörter der Computerkonten nicht mehr ändern lassen. Die Anmeldung am System klappt aber noch . Gibt es da eine weitere Frist ab wann der Cluster komplett auf die Bretter geht? In einem anderen Thema habe ich gelesen, dass NTML noch geht, aber Kerberos nicht mehr. Ich bin auch der Meinung, dass es nun schon mehr als 30 Tage sind, die Anmeldung aber noch funktioniert. Vielleicht kann das Thema von jemanden kurz aufgeklärt werden. Gruß DO

Nun haben wir folgendes gemacht: 1) Cluster abgerissen 2) Computeraccount (CNO / VCO) und Zweites Computeraccount (VCO) gelöscht 3) Cluster neu erstellt 4) CNO Computerkonto wurde automatisch auch angelegt 5) Zweiten VCO noch nicht erstellt, da der SQL HA Cluster noch nicht einrichtet war 6) Cluster-ident-01$ auf dem CNO/VCO Computerkonto Cluster-ident-01 temporär Vollzugriff gegeben- 7) Im Failover Cluster Manager geprüft, ob man den Cluster offline und wieder online schalten kann. Hat funktioniert 8) Dann den Cluster nochmal offline geschaltet und die Reparatur Funktion ausgewählt. 9) Ergebnis: There was an error repairing the active directory object for 'Cluster Name' 10) The specified directory service attribute or vaue does not exists Frage 1: Kennt jemand diese Fehlermeldung? Frage 2: Was genau macht die Repair Funktion? Leider wird die ja nicht mit einem Powershell Script aufgerufen werden Also zur Zeit vorhandene Computerkonten: Cluster-ident-01 (CNO/VCO) Node-01 VM mit Win2022 Node-02 VM mit Win2022

Um das nochmal genauer darzustellen. cluster-ident-01 ist das CNO und ein VCO. cluster-ident-02 ist ein weiterer VCO. beide können ihr Kennwort im AD nicht mehr aktualisieren. Das CNO Konto ist cluster-ident-01$ Das, sowie auch Jeder haben Vollzugriff auf den beiden Computerkonten cluster-ident-01 und cluster-ident-02. Die Windows Notes funktionieren und können unberücksichtigt bleiben. Das Problem tritt auch bei einem anderer HA SQL Cluster auf. Einmal auf Windows 2019 und einmal auf Windows 2022 Basis.

Tatsächlich haben wir zum Testen sogar "jeder" Vollzugriff gegeben. The cluster identity 'cluster-ident-01$' may lack permission required to update the object ... Bei server01 und server02, den Cluster Nodes funktioniert es. Nur bei den Cluster Objekten cluster-ident-01 und cluster-ident-02 geht es nicht mehr. In den beiden Cluster Objekten hat zum Test, jeder Vollzugriff. Außerdem das oben genannte Konto cluster-ident-01$.

Also, gibt es für DSID keine genaue Bezeichnung? SECERR bedeutet Security Error?

Moin, beim Ändern eines Passwort für ein Computerkonto bekommen wir "beispielhaft" die obere Meldung. Wir haben das mit Wireshark ausgelesen. Was genau bedeutet die DSID-12345678? Die Schwierigkeit ist das Objekt zu finden, welchem die Berechtigung findet. gruß DO

Fehler ist seit dem 17.9 aufgetreten. Der Cluster wurde im Januar nach Vorgabe von Microsoft aufgesetzt. Windows Updates wurden am 30.8 und am Ende September eingespielt. Meiner Meinung nach, kann das nicht der Grund sein. Die beiden virtuellen Server (Node1 und Node2) können ihr Computerkonto updaten. Die beiden virtuellen Cluster dagegen nicht. Am 14.9 hat der eine Cluster sein Computerkonto noch updaten können. Der andere hat das am 17.9 dagegen erfolglos versucht. Gruß DO

Nein, da wurde nichts geändert. Auch keine GPO Veränderungen. Es scheinen auch nur die SQL Hochverfügbarkeitscluster zu betreffen. 464 TCP ist an den DCs erreichbar. Die Berechtigungen der Konten sehen auch soweit gut aus. Das Cluster Objekt hat auf den beiden Knoten sogar Vollzugriff. Der UserAccountControl steht auf 0x1000. Das ist eigentlich auch soweit in Ordnung.