Ebenezer
-
Gesamte Inhalte
229 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von Ebenezer
-
-
Hi, ich habe das Szenario gestern in einem Lab durchgespielt... also das umbenennen via GUI führte auch hier zu dem Anmeldefehler "Die Sicherheitsdatenbank auf diesem Server verfügt über kein Computerkonto"! Ich hatte zuvor via wbadmin ein systemstate backup ausgeführt. Dieses habe ich dann wiederhergestellt und konnte mich dann auch wieder anmelden! Wenn man das nicht hat, dann ist mir kein Weg bekannt aus der Nummer wieder rauszukommen! Anschließend habe ich dann das umbenennen via netdom (wie auch hier beschrieben https://www.der-windows-papst.de/2021/06/24/rename-domain-controller/) ausgeführt und es gab keine Probleme! Danke für Euren Input!
-
Ich konnte das leider nicht mehr ausprobieren, weil wir uns dazu entschlossen haben die Domain neu einzurichten. Diese ist glücklicherweise sehr klein und da neue Computer angeschafft wurden (Wechsel von Windows 10 auf 11) mussten wir diese ohne in die Domain aufnehmen!
Ich war mir so sicher, dass es keine Schwierigkeiten macht einen DC (ohne Exchange) wie beschrieben umzubenennen, dass ich dazu im Vorfeld auch nichts mehr nachgelesen habe! Das war ein Fehler! Doppelt ungünstig wenn dann auch so schnell kein Backup einspringen kann. Aber alles eigenes verschulden! Danke für Eure Hilfe-Versuche!
-
Ich habe das Computerkonto des DCs via GUI umbenannt (Einstellungen -> Info -> Diesen PC umbenennen)! Seitdem besteht das Problem!
-
Ja ich habe das Computerkonto umbenannt und kann es aber scheinbar via DSRM nicht wieder rückgängig machen!
-
Ich bin als Administrator im DSRM angemeldet! Ein umbenennen des Computerkontos ist in diesen Kontext scheinbar nicht möglich!
-
Wie denn? Er sagt das geht nicht im DSRM Modus! Wir haben es vergeblich via GUI und PowerShell probiert (rename-computer)!
-
Im DSRM kann ich mich anmelden, da sind wir auch gerade drin, aber was sollen wir hier genau machen?
-
ja, den Artikel habe ich auch gesehen, aber der hilft uns leider im aktuellen Fall auch nicht weiter oder meinst Du etwas konkretes?
-
Hi, ich habe im Zuge einer DC Migration (2016 -> 2022) den Fehler gemacht ganz am Ende den neuen DC über den klassischen Weg umzubenennen! Jetzt ist keine Anmeldung mehr weder auf dem DC (Die Sicherheitsdatenbank auf diesem Server verfügt über ein Computerkonto) noch in der Domäne möglich! Gibt es noch irgendeinen Weg den DC wieder umzubenennen? Via DSRM geht das ja auch nicht, aber kann man z.B. die NTDS.DIT offline editieren und hierüber den Namen umbenennen? Ein VM Backup wieder gerade parallel zurückgeholt, aber das dauert leider mehrere Stunden... ich danke Euch!
Nico
-
Ich dachte zuerst das mit der SA war ein Scherz.. unglaublich! Steht schon fest welche cloud license vorausgesetzt wird damit man den On-Prem Exchange auch aktualisieren darf?
-
-
Hi, ich plane gerade die Umstellung zu M365 für ein paar kleinere Exchange 2016 Umgebungen (nie mehr als 50 Postfächer) und bin auf folgenden Ablauf gekommen. Entra ID Connect ist bereits aktiv. Seht Ihr eine Möglichkeit den Vorgang zu vereinfachen oder würdet Ihr es anders angehen?
1. Klassische Hybridbereitstellung
2. Migration Postfächer / Public Folder
3. Anpassen DNS / Routing
4. Installation Exchange 2019 (kostenlose Lizenz für Hybrid) für das spätere Benutzer-Management
5. Deinstallation Exchange 2016
Weiß Jemand ob es für Exchange Server SE auch eine kostenfreie Lizenz für dieses Szenario geben wird?
Danke!
-
Wir haben eine Lösung gefunden! Ziemlich unglaublich, aber der neue Druckdialog unter Windows 11 scheint für die KoCoBox zu viele Broadcasts zu produzieren, so dass diese irgendwann dicht macht! Meldet man sich ab und wieder an, funktioniert es sofort wieder! Hier wird das Problem beschrieben:
Die Lösung besteht darin den alten Druckdialog wieder zu aktivieren:
[HKEY_CURRENT_USER\Software\Microsoft\Print\UnifiedPrintDialog]
Add a DWORD 32-bit named "PreferLegacyPrintDialog" and set it to 1.Seitdem gab es keine Abbrüche mehr! WTF!
-
2
-
2
-
-
Hi, in einer Arztpraxis wurden zwei PCs getauscht. Auf den alten lief Windows 10 und auf den neuen Windows 11 (24H2). Auf den PCs ist die Praxissoftware Medistar installiert und neben beiden PCs stehen Kartenleser die via LAN angebunden sind. In der Praxis befindet sich eine KoCoBox (als Konnektor zur Telematik Infrastruktur). So viel zum Setting. Das Problem: beide PCs verlieren mehrmals täglich die Verbindung zur KoCoBox, so das keine Gesundheitskarten eingelesen werden können. Sowohl der Medistar Partner als auch der Anbieter der Praxissoftware konnten das Problem bisher nicht lösen. Ich habe mir das jetzt einen Tag angesehen und folgendes festgestellt:
- Startet man die PCs neu, dann funktioniert die Verbindung erst mal wieder
- Ist die Verbindung unterbrochen dann kann man die KoCoBox weder pingen (die KoCoBox kann den PC aber pingen) noch das Webinterface aufrufen; alle anderen internen und externen Ressourcen sind aber weiterhin erreichbar
- Auf der KocoBox sieht man sehr viele geblockte UDP Pakete von den beiden PCs (größtenteils Broadcasts / 255.255.255.255) -> ich hatte dann die Vermutung, dass die Box die Verbindung irgendwann dynamisch sperrt
- Wir haben dann auf einem der beiden PCs in der Windows Firewall ausgehende UDP-Broadcasts verboten (zuvor dem PC eine statische IP zugewiesen) -> es kam am nächsten Tag trotzdem zu Unterbrechungen aber deutlich weniger als auf dem zweiten PC, wobei aber der zweite PC deutlich intensiver genutzt wurde, also auch mehr Karten eingelesen wurden
- Netzwerkkabel und Switch unterm Tisch haben wir schon getauscht
- Mit Wireshark haben wir versucht den Traffic zu analysieren... der Ping scheint anzukommen wird aber m.E. nicht beantwortet
Was würdet Ihre noch probieren? Wo vermutet Ihr das Problem?
Danke!
-
Am 23.11.2024 um 20:57 schrieb Squire:
mal Frage am Rande ... die Sysvol Replikation wurde auf DFSR umgestellt?
Klappt die Replikation überhaupt? Probier mal auf dem 2012er im Netlogon Verzeichnis einfach eine Textdatei zu erzeugen ... ist die auch auf dem 2022er im Netlogon?
Am 23.11.2024 um 20:57 schrieb Squire:mal Frage am Rande ... die Sysvol Replikation wurde auf DFSR umgestellt?
Klappt die Replikation überhaupt? Probier mal auf dem 2012er im Netlogon Verzeichnis einfach eine Textdatei zu erzeugen ... ist die auch auf dem 2022er im Netlogon?
Hi, auf DFSR war zwar bereits umgestellt, aber ich hatte den Fehler (DFSR / 2212) im Eventlog übersehen:
Der DFS-Replikationsdienst hat ein unerwartetes Herunterfahren auf Volume C: erkannt. Ein unerwartetes Herunterfahren kann auftreten, wenn der Dienst nicht normal beendet wurde (zum Beispiel aufgrund eines Stromausfalls) oder wenn auf dem Volume ein Fehler aufgetreten ist. Der Dienst hat automatisch den Wiederstellungsprozess initiiert. Der Dienst erstellt die Datenbank neu, wenn er erkennt, dass die Datenbank nicht zuverlässig wiederhergestellt werden kann. Es ist keine Benutzeraktion erforderlich.
Das konnte ich beheben und anschließend auch die Rollen wie gewohnt übertragen! Der Fehler hätte mir aber schon sehr viel schneller auffallen müssen, da auf dem neuen DC auch keine NETLOGON und SYSVOL Freigaben vorhanden waren... danke an Alle!
-
vor 2 Minuten schrieb NilsK:
Moin,
wieso, was passiert denn dann?
In den Feldern neuer und alter Server steht jeweils nur der alte Server!
vor 2 Minuten schrieb NilsK:Falls es tatsächlich nicht gehen sollte, kannst du bei so einer kleinen Umgebung aber auch den alten DC abschalten und die Rollen dann offline übertragen (seize). Danach das alte DC-Konto aus dem AD und dem DNS löschen, dann bist du (im wesentlichen) fertig.
Na gut, vorher würde ich noch probieren den alten Server herunterzustufen... ich werde berichten!
vor 2 Minuten schrieb NilsK:Gruß, Nils
Danke!
-
vor einer Stunde schrieb Nobbyaushb:
Moin,
das geht nicht?
https://4sysops.com/archives/transfer-fsmo-roles-using-powershell/
Fehlermeldung?
Das kann ich heute nicht mehr probieren! Aber es ist doch schon unverständlich, warum es nicht via GUI funktioniert ... auf diesem Weg habe ich es bestimmt schon 100x gemacht! Deshalb dachte ich es liegt an einer Inkompatibilität!
-
vor 6 Minuten schrieb cj_berlin:
Moin,
hast Du es denn versucht? Wenn Du einen 2022 promoten konntest, hat das ADPREP ja zumindest geklappt.
Ja, das promoten hat funktioniert! Wenn ich auf dem alten DC (mit den FMSO Rollen) das Netzwerkkabel ziehe dann kann der neue DC z.B. AD Benutzer und Computer nicht öffnen, obwohl 127.0.0.1 als DNS eingetragen ist! Die Clients können sich zwar anmelden, aber %logonserver% zeigt noch auf den alten DC und das Netzlaufwerk funktioniert auch nicht, obwohl der neue DC als DNS eingetragen ist! Wenn ich die FSMO Rollen via AD Benutzer und Computer übertragen möchte, steht an beiden Stellen nur der alte Server!
vor 6 Minuten schrieb cj_berlin:Und die Kompatibilitätstabelle in Deinem Link ist ja unvollständig - die ist bei 2012R2 einfach abgeschnitten. So sah es in 2022 aus:
Das ist ja interessant... hmm dann ist das also gar nicht mein Problem?! Das sieht ja sehr nach einem DNS Problem... best practise ist doch, dass beide DCs sich überkreuz eingetragen haben, oder? Danke!
-
Weil nur R2 mit neueren Betriebssystemen kompatibel ist:
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels
-
Hi, ich habe hier eine kleine Umgebung mit 5 Benutzern mit einem DC auf dem noch Windows Server 2012 (ohne R2) installiert ist! Das haben wir leider übersehen und nun einen Windows Server 2022 als zweiten DC zur Domäne hinzugefügt! Das hat auch problemlos funktioniert und auch im Eventlog gibt es keine Fehler! Jetzt kann ich aber keine FMSO Rollen übertragen ... müssen wir jetzt den Windows Server 2012 auf R2 upgraden (hat Jemand noch das Image?) oder können wir den alten DC rausschmeißen und die FMSO Rollen via NTDSUTIL übertragen? Danke!
-
Hallo, seit ca. zwei Tagen registriert sich ein Bot auf tausenden Seiten mit einer Kunden Adresse. Dieser erhält nun minütlich die "Welcome" und "Activate your account" E-Mails. Wir haben übergangsweise in Outlook die wichtigsten Kontakte zur Liste der "Sicheren Absender" hinzugefügt und eingestellt, dass der Rest im Junk landet.
Hat Jemand das Thema schon durch? Müssen wir die Adresse jetzt wegschmeißen oder hört das meistens nach ein paar Tagen wieder auf? Gibt es in MS365 noch irgendwas was wir probieren können?
Wir haben probeweise Defender for Office 365 Plan 2 gebucht, aber die Mails sind ja leider valide und kommen auch immer von anderen IPs und unauffälligen Domains.
Copilot löst das bestimmt, oder?
:=)
Danke! Nico -
Hi, das sieht nach round robin aus, das brauchst Du nicht. Der Broker ist für die Verteilung zuständig und der kennt seine Session Hosts! Ich lege im internen DNS lediglich eine neue Zone an, die so auch im offiziellen Zertifikat steht.
-
Am 17.2.2024 um 14:46 schrieb testperson:
Dann schreibe notfalls die SID in die "GptTmpl.inf" unter "\\%USERDNSDOMAIN%\sysvol\%USERDNSDOMAIN%\Policies\{Id des GPOs}\Machine\Microsoft\Windows NT\SecEdit"
... SeServiceLogonRight = *S-1-5-80-0 ...
Ggfs. kannst du auch einen "Dummy Eintrag" in der GPMC hinzufügen und im Anschluss diesen in der Datei einfach durch die SID ersetzen.
Hallo Jan, vielen dank für Deine kreative Lösung! Alle anderen Ansätze haben leider nicht geholfen!
-
Zitat
Ja dann nimm's halt rein, was hindert Dich daran?
Das Konto wird nicht gefunden!
Keine Anmeldung an DC nach umbenennen
in Active Directory Forum
Geschrieben
Ich wüsste nicht wie! Ich habe den DC soeben erneut falsch umbenannt und anschließend im DSRM-Modus gestartet. Jetzt frag ich den neuen DC Namen ab:
Ergebnis: NeuerDC.testlab.local (Der Befehl wurde ausgeführt)
Frage ich den alten DC Namen ab erhalte ich:
Der Netzwerkpfad wurde nicht gefunden!
Versuche ich dann mit dem u.a. Befehl den alten DC Namen als Alternativen Namen zu setzen, erhalte ich folgenden Fehler:
AlterDC.testlab.local konnte nicht als alternativer Name für den Computer hinzugefügt werden! Fehler: Eine vorhandene Verbindung wurde vom Remotehost geschlossen.