Alle Aktivitäten

Also es ist wirklich komisch, wochenlang geht es (bis auf einzelne Anmeldeprobleme) und dann kommt wieder Tag X wo quasi nichts mehr geht. Ein repadmin /replsummary hat bei Quell-DSA DC01 als Fehler angezeigt, bei Ziel-DSA DC02 als Fehler. Ein repadmin /showrepl hat immer das ausgegeben: CN=Schema,CN=Configuration,DC=domain,DC=xx Standort\DC01 über RPC DSA-Objekt-GUID: a514d08f-f9c3-4889-93a6-e6f5c4b9573e Letzter Versuch am 2025-09-30 11:46:46 ist fehlgeschlagen, Ergebnis 1908 (0x774): Der Domänencontroller für diese Domäne wurde nicht gefunden. 1 aufeinander folgende Fehler. Letzte Erfolg um 2025-09-30 10:52:07. Ein Repadmin /Syncall /APeD hat ohne Fehler funktioniert und plötzlich waren alle anderen Befehle auch wieder ohne Probleme. Danach konnten manche Server nicht mehr angemeldet werden (Benutzername Passwort falsch) -> da habe ich das MaschinenPasswort zurückgesetzt via Powershell augenscheinlich läuft jetzt alles wieder.. ABER ich kann von einem Server nicht auf einen anderen Server per SMB zugreifen. SMB-Freigabe = Server A SMB-Client Server = Server B irgendein dritter Server = Server C Server B auf Server A, kein Zugriff möglich. Es kommt, dass der Pfad nicht gefunden wurde von Server C kann ich auf Server A und Server B zugreifen, ohne Probleme Ich habe alles probiert... wenn ich den nicht funktionierenden Zugriff von Server B auf A starte, wird im DC folgendes ProtokollierT: Es wurde ein Kerberos-Dienstticket angefordert. Kontoinformationen: Kontoname: Administrator@domain.LOCAL Kontodomäne: domain.LOCAL Anmelde-GUID: {8d65f0ca-0efc-dc10-1223-182bee81e08b} MSDS-SupportedEncryptionTypes: N/A Verfügbare Schlüssel: N/A Dienstinformationen: Dienstname: AG-SRVCLNODE01$ Dienst-ID: domain\AG-SRVCLNODE01$ MSDS-SupportedEncryptionTypes: 0x1C (RC4, AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: AES-SHA1, RC4 Domänencontrollerinformationen: MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96) Verfügbare Schlüssel: AES-SHA1, RC4 Netzwerkinformationen: Client-Adresse: ::ffff:192.168.1.49 Client-Port: 49778 Beworbene E-Typen: AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC-NT RC4-HMAC-NT-EXP RC4-HMAC-OLD-EXP Zusätzliche Informationen: Ticketoptionen : 0x40810000 Ticketverschlüsselungstyp: 0x12 Sitzungsverschlüsselungstyp: 0x12 Fehlercode: 0x0 Übertragene Dienste: - Ticketinformationen Ticket-Hash anfordern: 032kGYblSyvg1A1USYrE5j9ozeSkarob0xy/zEN6NNk= Antwort Ticket-Hash: WvkSPncrq23CP8RQXMpg8q1714+GGZeBY48Es2cFVGg= Dieses Ereignis wird jedes Mal generiert, wenn Zugriff auf eine Ressource angefordert wird, wie z. B. auf einen Computer oder einen Windows-Dienst. Der Dienstname steht für die Ressource, auf die der Zugriff angefordert wurde. Dieses Ereignis kann mit Windows-Anmeldeereignissen korreliert werden, indem die Anmelde-GUID-Felder in jedem Ereignis verglichen werden. Das Anmeldeereignis findet auf dem Computer statt, auf den zugegriffen wurde, der oft ein anderer Computer ist als der Domänencontroller, der das Dienstticket ausgestellt hat. Vorauthentifizierungstypen, Ticketoptionen, Verschlüsselungstypen und Ergebniscodes sind in RFC 4120 definiert. Server B protokolliert in dem Moment folgendes: Fehler beim Anmelden eines Kontos. Antragsteller: Sicherheits-ID: NULL SID Kontoname: - Kontodomäne: - Anmelde-ID: 0x0 Anmeldetyp: 3 Konto, für das die Anmeldung fehlgeschlagen ist: Sicherheits-ID: NULL SID Kontoname: Administrator Kontodomäne: domain.LOCAL Fehlerinformationen: Fehlerursache: Bei der Anmeldung ist ein Fehler aufgetreten. Status: 0xC000006D Unterstatus:: 0x0 Prozessinformationen: Aufrufprozess-ID: 0x0 Aufrufprozessname: - Netzwerkinformationen: Arbeitsstationsname: - Quellnetzwerkadresse: 192.168.1.49 Quellport: 49775 Detaillierte Authentifizierungsinformationen: Anmeldeprozess: Kerberos Authentifizierungspaket: Kerberos Übertragene Dienste: - Paketname (nur NTLM): - Schlüssellänge: 0 Dieses Ereignis wird beim Erstellen einer Anmeldesitzung generiert. Es wird auf dem Computer generiert, auf den zugegriffen wurde. Die Antragstellerfelder geben das Konto auf dem lokalen System an, von dem die Anmeldung angefordert wurde. Dies ist meistens ein Dienst wie der Serverdienst oder ein lokaler Prozess wie "Winlogon.exe" oder "Services.exe". Das Anmeldetypfeld gibt den jeweiligen Anmeldetyp an. Die häufigsten Typen sind 2 (interaktiv) und 3 (Netzwerk). Die Felder für die Prozessinformationen geben den Prozess und das Konto an, für die die Anmeldung angefordert wurde. Die Netzwerkfelder geben die Quelle einer Remoteanmeldeanforderung an. Der Arbeitsstationsname ist nicht immer verfügbar und kann in manchen Fällen leer bleiben. Die Felder für die Authentifizierungsinformationen enthalten detaillierte Informationen zu dieser speziellen Anmeldeanforderung. - Die übertragenen Dienste geben an, welche Zwischendienste an der Anmeldeanforderung beteiligt waren. - Der Paketname gibt das in den NTLM-Protokollen verwendete Unterprotokoll an. - Die Schlüssellänge gibt die Länge des generierten Sitzungsschlüssels an. Wenn kein Sitzungsschlüssel angefordert wurde, ist dieser Wert 0. Genau die gleichen Logs wie wenn wir die "wir können uns nicht mehr Anmelden" Probleme haben, komisch ist das Sicherheits-ID in dem Moment immer NULL SID steht. Den Artikel von @testperson bin ich durchgegangen, der passt sehr gut zu "unseren Problemen" . Aber wir haben das geprüft, RC4 scheint bei uns nicht deaktiviert zu sein

Mein Gedächtnis sagt, das man DC‘s nicht von Trial auf RTM bringen kann Sind die VM DC?

Und hast du dann Dism /online /Set-Edition:ServerDatacenter /ProductKey:xxxH-GxxxQ-XWyyy-9aaaY-VQccc /AcceptEula getestet?

habe ich schon gemacht. Ergebnis: Zieledition: ServerDatacenter

Und du hast das schon gemacht?

Hallo, ich habe in eine HyperV-Umgebung mit Windows 2025 Datacenter drei VMs installiert. Beim Image handelt es sich um eine Eval-Version. VM1: Dism /online /Set-Edition:Datacenter /ProductKey:xxxH-GxxxQ-XWyyy-9aaaY-VQccc /AcceptEula; Vorgang wurde erfolgreich abgeschlossen. VM2: diese Fehlermeldung VM3: auch PS C:\Users\Administrator> Dism /online /Set-Edition:Datacenter /ProductKey:xxxH-GxxxQ-XWyyy-9aaaY-VQccc /AcceptEula Tool zur Imageverwaltung für die Bereitstellung Version: 10.0.26100.5074 Abbildversion: 10.0.26100.6584 Fehler: 50 Dieses Windows-Image kann nicht auf die angegebene Windows-Edition aktualisiert werden. Das Upgrade kann nicht fortgesetzt werden. Führen Sie die Option "/Get-TargetEditions" aus, um die für das Upgrade verfügbare Windows-Edition anzuzeigen. Die DISM-Protokolldatei befindet sich unter "C:\WINDOWS\Logs\DISM\dism.log". dism.log: 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=4916 GetReferenceCount hr: 0x0 - CSessionTable::RemoveSession 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=4916 Refcount for DismSession= 1s 0 - CSessionTable::RemoveSession 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=4916 Successfully enqueued command object - CCommandThread::EnqueueCommandObject 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=3960 ExecuteLoop: CommandQueue signaled - CCommandThread::ExecuteLoop 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=3960 Successfully dequeued command object - CCommandThread::DequeueCommandObject 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=3960 ExecuteLoop: Cancel signaled - CCommandThread::ExecuteLoop 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=3960 Leave CCommandThread::ExecuteLoop - CCommandThread::ExecuteLoop 2025-09-30 11:50:04, Info DISM PID=8976 TID=3960 Temporarily setting the scratch directory. This may be overridden by user later. - CDISMManager::FinalConstruct 2025-09-30 11:50:04, Info DISM PID=8976 TID=3960 Scratch directory set to 'C:\WINDOWS\SystemTemp\'. - CDISMManager::put_ScratchDir 2025-09-30 11:50:04, Info DISM PID=8976 TID=3960 DismCore.dll version: 10.0.26100.5074 - CDISMManager::FinalConstruct 2025-09-30 11:50:04, Info DISM Initialized Panther logging at C:\WINDOWS\Logs\DISM\dism.log 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=3960 Leave CCommandThread::CommandThreadProcedureStub - CCommandThread::CommandThreadProcedureStub 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=4916 Deleted g_internalDismSession - DismShutdownInternal 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=4916 Shutdown SessionTable - DismShutdownInternal 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=4916 DismApi.dll: - DismShutdownInternal 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=4916 DismApi.dll: <----- Ending DismApi.dll session -----> - DismShutdownInternal 2025-09-30 11:50:04, Info DISM API: PID=8976 TID=4916 DismApi.dll: - DismShutdownInternal

Wird man etwa an dem Aufschrei feststellen…

Interessant wär ja mal, wieviele Einwahlen da tatsächlich pro Monat/Jahr noch stattfinden.

Aktuell habe ich wieder das Problem, dass ich auf die c$ Freigabe eines Server nicht zugreifen kann, im Explorer passiert einfach nichts, per cd in Powershell erhalte ich folgende Fehlermeldung: cd : Der Pfad "\\[Servername]\c$" kann nicht gefunden werden, da er nicht vorhanden ist. In Zeile:1 Zeichen:1 Was habe ich geprüft: 1) auf Server und Client (auch ein Server) sind Uhrzeit mit dem DC synchronisiert und identisch 2) Auflösung kein Problem 3) Client sowie Server sagen bei Test-ComputerSecureChannel das alles iO ist 4) wenn ich auf dem Client ein "klist get host/[Servername]" ausführe, bekommt der Client ein Ticket ich bekomme einfach keinen Zugriff hin, nun habe ich den Server neugestartet und alles funktioniert wieder. Ich gehe mal den Artikel von dir durch @testperson, vielen Dank erstmal Wir haben auf einem Server ein dauerhaftes Powershell Skript laufen, welches Daten auf einen Fileshare kopiert. Über eine CSV wird das Share-Ziel ermittelt (unterschiedliche Server) -> auf manche Server klappt es grade, auf andere sagt er Benutzername oder Kennwort falsch. Gleicher Benutzer ... es ist wirklich zum Wahnsinnig werden

Tach an Board, so starte ich dann in den Tag und koche Kaffee Allen einen guten Dienstag, bleibt gesund! Hier freundlich bei 10°C, es wird ein meist sonniger Tag bis etwa 18°C

Moin, schau ggfs. einmal hier (auch wenn das Problem meiner Meinung nach nicht Windows Server 2025 als DC ist, sondern die vermutliche Missachtung aller Dinge, die mit RC4 zusammenhängen): Windows Server 2025 als DC: Finger weg, bei gemischten Umgebungen (RC4-Problem)Borns IT- und Windows-Blog HTH Jan

Hallo, danke für eure Antworten. War leider krank und das Problem spitzt sich zu ... auch server haben teilweise nun das Problem. Nach einem Neustart ist dann meißt alles wieder iO. @daabm: Wenn ich deinen Befehl an einen betroffenen Client / Server ausführe erhalte ich bei klist get host/%computername% nur folgende Ausgabe: Fehler bei klist. Fehler: 0xc000018b/-1073741429: Die SAM-Datenbank des Windows-Servers enthält kein Computerkonto für diese Arbeitsstationsvertrauensstellung. Die Probleme haben wir aus meiner Sicht seit dem wir den 2025er DC mit integriert haben. Davor gab es diese Problematik nie a) DNS geht ohne Probleme zu der Zeit, ich kann alles ordentlich auflösen am Client / Server b) es betrifft auch relative neue Clients / Server die vor nicht allzu langer Zeit in der Domain aufgenommen wurden

Moin Ein Internetsaurier trennt sich von einer Sauriertechnologie: https://www.n-tv.de/technik/AOL-beendet-ein-Stueck-Internet-Geschichte-article26064100.html VG Damian

Das geht mit einer Shared Mailbox identisch. Man darf halt kein Automapping konfigurieren. Versuchs doch erstmal. Versuchs doch erstmal, dann weißt du das nächstes mal mehr.

>Warum wurde ein gemeinsames Postfach das vorwiegend als gemeinsames Firmenadressbuch genutzt wird als Nutzerpostfach mit Benutzername/Kennwort im Outlook >hinzugefügt? Damit die User auf das AN FELD im Outlook Editor drücken können und den Empfänger aus dem Firmenadressbuch auswählen können. Die Kontakte einer Shared Mailbox kann man mittels STRG+UMSCHALT+B / Extras im Outlook Classic nicht hinzufügen soweit ich weiß. Soweit ich weiß kann der Outlook "neue Email" Benachrichtigungs-POP-UP ohne die CREDENTIALs auch nicht aufgehen. Edit: Ich vermute diese REG KEYs helfen eher nicht. Werde ich ggf. mal ausprobieren. https://www.managed-office.at/wissensdatenbank/item/outlook-suche-funktioniert-nicht HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\search DWORD: DisableServerAssistedSearch Value = 1 HKEY_CURRENT_USER\software\microsoft\office\16.0\outlook\search DWORD: DisableServerAssistedSuggestions Value = 1

Dann machst du was falsche oder deine Erinnerung trügt, oder beides. Nein.

Ich würd bei sowas ja eher im Online Mode arbeiten. Und warum credentials, wenn es doch ein gemeinsames (shared) Postfach ist, da wäre doch full access viel sinnvoller, oder welchen Grund habt ihr? Mal davon abgesehen, dass es in eurem Fall ja sogar noch zusätzliche Lizenzkosten verursacht.

Doch es darf was kosten. Ich weiß, öffentliche Zertifikate kosten unter 50€. Wenn der On-Prem-Exchange auf öffentliches Zertifikat gewechselt wird, dann bekommen alle User meiner Erinnerung nach die Outlookmeldung á la "temporäres Postfach oder altes Postfach verwenden". Will sagen, Wechsel auf öffentliches Zertifikat bedarf meines Wissens nach u.U. kurz ein neues Outlookprofil bei allen. Sorry - was meinst du mit SPLIT DNS- Split DNS Ist dies gemeint? > .das man im internen Netzwerk problemlos https://mail.contoso.com/owa aufrufen kann? Stimmt, noch kein WAF vorhanden, Geoblocker(/IPS sind aktuell nur aktiviert.

Hallo, stimmt es, dass ganz offiziell die Sofortsuche durchaus ein paar Stunden braucht um neue Einträge einzulesen? User XY hat sich zusätzlich zu seinem pers. Postfach noch das GEMEINSAM Nutzerpostfach im Outlook Classic hinzugefügt. (über Datei/Konto hinzufügen und die GEMEINSAM Credentials eingegeben) Er hat kein Vollzugriffsberechtigungen auf das Postfach. (weil es ja über Credentials eingeben gelöst wurde) (die Postfächer haben normalen Cache Modus aktiv) Er sagt, dass wenn er 5 neue Adressen im GEMEINSAM Postfcher unter Kontakte erstellt das die Outlook Sofortsuche die Adressen dann nicht findet. (wenn er manuell zu den Adressen scrollt sind sie da). Ihm ist das insofern wichtig, weil häufig Visitenkarten eingibt und das Arbeitsergebnis sozusagen direkt bemustern möchte. Kann man die Sofortsuche beeinflussen das solche neuen Adressen direkt gefunden werden? Es gab doch die Einschränkung, das unlizenzierte Shared Mailboxen keine Such-Indexierung unterstützen. Outlook Classic: meiner Wissens nach kann man bei tabellerischer Adresseansicht die Adressen nicht nach "erstelldatum" sortieren. (<<<< werde ich nochmal prüfen, das geht bestimmt) Es sind ca. 2000 Adressen, sein PC ist schon etwas älter. Die Windows Indexierung wurde noch nicht resetted. Kein Terminalserver bzw. kein FSLOGIC im Einsatz.

Hi, ich kann keine DNS Probleme bemerken: auf dem Exchange server selbst: C:\Users\administrator.firma.local> nslookup firma-exc03 Server: firma-exc03.firma.local Adress: 192.168.11.63 von einem Nachbarserver aus: C:\Users\administrator.firma.local>nslookup firma-exc03 Server: domaincontroller.firma.local Address: 192.168.11.62 Name: firma-exc03.firma.local Address: 192.168.11.63

Hallo zusammen, mal hier angehängt, da es auch für den neuen Exchange Server Subscription Edition gilt !!!!! Lizenzierungshinweis aus einem aktuellem Auditfall ( leider hat mich die betroffene Firma zu spät eingeschaltet und durfte heftig/teuer nachzahlen!) Großer Kunde kommt aus dem Agentur/Versicherungsbereich. Kunde betreibt mehrer Exchange-Server und massig viele selbständige Agenturen/Vermittler(also "externe") greifen auf diese zu (Kommunikation). Kunde meinte, es sei ja kein Kostenfaktor, da IHM ja gesagt wurde: Nutzungsrechte; "Voraussetzung für Externen Nutzungszugriffe" = Lizenziert mit Server Da im Laufe der Zeit der Kunde dann aber den Exchange-Server intensiver nutzte und zusätzliche Funktionen etablierte/nutzte, wie teilweise In-Situ-Archiv, In-Situ-Speicher (unbestimmt, abfrage- und zeitbasiert) Datenschutz und Richtlinientreu, nutzerdefinierte Aufbewahrungsrichtlinien, Pro Nutzer/Verteilerlistenaufzeichnung, Websitepostfächer-Regeleinhaltung, Datenverlustvorbeugung, etc.) Gilt dann aber der Passus aus den PURs > für den Zugriff auf „Zusätzliche Funktionalität“ sind Basis- und Zusätzliche CALs erforderlich, also die Exchange-Standard-CAL + Exchange-Enterprise-CAL (Zusätzliche CAL) (auch bei den ABO-Plänen aufpassen, checken!) Leider hatte das der Kunde und auch sein betreuendes Systemhaus "übersehen" und er durfte für seine "Externen" heftig zahlen (nachlizenzieren)... Das mal bedenken! Viele Grüße, Franz

Warum das? Nehme mir auch einen Pott Kaffee Guten Start in die Woche, bleibt gesund!

Danke für den Kaffee. Ich lag die halbe Nacht wach.

Moin! Die Woche beginnt, der Kaffee hat schon fertig. Eine Tüte Buttercroissants liegt auch bereit, greift zu. Das Wetter hier ist herbstlich-trübe, aber trocken. Noch... VG Damian

Hi, unter diesen Umständen würde ich mir derzeit die Frage gar nicht stellen. Der Exchange hängt ja scheinbar (direkt) am Internet und Mitte Oktober ist es mit dem Support vorbei. Evtl. sollte man hier über eine Migration zu Exchange Server SE (oder in Exchange online) nachdenken und in diesem Step direkt nach Best Practices vorgehen, die sich im Falle von ExO von alleine erledigen: Split DNS öffentliches Zertifikat Falls es nichts "kosten" darf -> Let's Encrypt oder ähnlich Generell würde ich beim Vorfinden eines solchen Exchanges einen Fahrplan in Richtung Split DNS + öffentliches Zertifikat aufstellen bzw. dankend ablehnen. (Zusätzlich wäre zu beleuchten, ob der Exchange wirklich direkt und ohne Web Application Firewall im Internet hängen muss, sofern er dies denn derzeit tut.) Gruß Jan