Jack Bauer

Moin, danke für eure Antworten. @Nobbyaushb ich bin heute nicht vor Ort, kann das aber in Kürze nachliefern. @NilsK gute Idee, aber nein. Die Domäne hat einen "lokalen" Namen. Ich habe die Befürchtung, dass sich da irgendetwas eingenistet bzw. Änderungen vorgenommen hat und wieder verschwunden ist. Wo sollte man mal etwas genauer hinschauen? Schöne Grüße Jack

Hello, beim Troubleshooting von ausbleibenden Clientregistrierungen (Win10_22H2) am DNS-Server (Sever22_21H2) sind mir Einträge wie dieser aufgefallen: Die Clients möchten sich nach extern registrieren. Zusätzlich ist in der (Hardware-) Firewall zu erkennen, dass auch meine DNS-Server Anfragen dorthin weiterleiten möchten. Alle außer den gewünschten Zielen werden ausgehend geblockt. In der Config des DNS-Servers (und auch bei DHCP) lässt sich nichts Ungewöhnliches erkennen. Malware-Scans alle clean. Habt ihr vllt einen Tipp oder eine empfohlene Prüfreihenfolge für mich? Danke euch und schöne Grüße Jack

Hat funktioniert: Deaktivierung reichte aus, Datenbank ist weg, Exchange deinstalliert. Ihr beide seid top, danke euch!!

Aber eine der drei Mailboxen ist weg! (sehe ich gerade...) :)

Okay, immerhin eine neue Meldung: Das Vermittlungspostfach "domain.local/Users/SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}" wird von Exchange verwendet und kann nicht entfernt werde n. + CategoryInfo : NotSpecified: (domain.local...8-e6c29d823ed9}:ADObjectId) [Remove-Mailbox], RecipientTaskException + FullyQualifiedErrorId : 2B1D3B4E,Microsoft.Exchange.Management.RecipientTasks.RemoveMailbox Das Vermittlungspostfach "domain.local/Users/FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042" wird von Exchange verwendet und kann nicht entfernt werde n. + CategoryInfo : NotSpecified: (domain.local...bf-00a95fa1e042:ADObjectId) [Remove-Mailbox], RecipientTaskException + FullyQualifiedErrorId : 30A4F077,Microsoft.Exchange.Management.RecipientTasks.RemoveMailbox

Hallo Mikro, danke für die schnelle Antwort! zu 1) funktioniert leider nicht, gleiche Fehlermeldung zu 2) hat mich auf eine weitere Idee gebracht und der Tipp von https://blog.kopfteam.de/probleme-mit-internet-newsgroups-bei-der-deinstallation-von-exchange-2010/ funktioniert Hallo Norbert, habe deinen Hinweis gerade erst gesehen. An Pkt. 2 ist ein grüner Haken dran, danke. Hast du einen Tipp zu Pkt. 1?

Hallo, ich möchte unseren einzigen Exchange-Server aus der Gesamtstruktur entfernen. Alle Rollen bis auf die Postfachrolle sind bereits deinstalliert. Zwei Datenbanken verhindern aber ein weiteres Vorgehen. Postfachdatenbank Hier besagt die Fehlermeldung, dass sich noch Postfächer in der Datenbank befinden. Nach Ausweitung der Sicht auf den gesamten Forest mit Set-AdServerSettings -ViewEntireForest $True wurden mir diese auch angezeigt: [PS] C:\Windows\system32>Get-Mailbox -Arbitration -Database MailBox1 Name Alias ServerName ProhibitSendQuota ---- ----- ---------- ----------------- FederatedEmail.4c1f4d8... FederatedEmail.4c... ex 1 MB (1,048,576 bytes) SystemMailbox{1f05a927... SystemMailbox{1f0... ex unlimited SystemMailbox{e0dc1c29... SystemMailbox{e0d... ex unlimited Allerdings kann ich diese nicht entfernen, weil die korrespondierenden AD-Objekte nicht existieren würden. Das stimmt aber nicht - sie sind da, wenn auch deaktiviert. [PS] C:\Windows\system32>get-mailbox -arbitration -database mailbox1 | remove-mailbox Der Vorgang konnte nicht ausgeführt werden, weil das Objekt 'domain.local/Users/FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042' nicht auf 'dc.domain.local' gefunden wurde. + CategoryInfo : NotSpecified: (domain.local...bf-00a95fa1e042:MailboxIdParameter) [Remove-Mailbox], ManagementObjectNotFoundException + FullyQualifiedErrorId : C16539E1,Microsoft.Exchange.Management.RecipientTasks.RemoveMailbox Der Vorgang konnte nicht ausgeführt werden, weil das Objekt 'domain.local/Users/SystemMailbox{1f05a927-9d7c-4131-8dba-1ee39743ca91}' nicht auf 'dc.domain.local' gefunden wurde. + CategoryInfo : NotSpecified: (domain.local...a-1ee39743ca91}:MailboxIdParameter) [Remove-Mailbox], ManagementObjectNotFoundException + FullyQualifiedErrorId : 1876BC75,Microsoft.Exchange.Management.RecipientTasks.RemoveMailbox Der Vorgang konnte nicht ausgeführt werden, weil das Objekt 'domain.local/Users/SystemMailbox{e0dc1c29-89c3-4034-b678-e6c29d823ed9}' nicht auf 'dc.domain.local' gefunden wurde. + CategoryInfo : NotSpecified: (domain.local...8-e6c29d823ed9}:MailboxIdParameter) [Remove-Mailbox], ManagementObjectNotFoundException + FullyQualifiedErrorId : DADCF2D8,Microsoft.Exchange.Management.RecipientTasks.RemoveMailbox Public Folder-Datenbank Diese kann ich leider auch nicht entfernen, es wird folgende Fehlermeldung gegeben: Ich weiß leider bei beiden Datenbanken nicht weiter und würde mich auf hilfreiche Tipps freuen. Alles muss weg, es braucht und kann auch nichts an eine andere Stelle migriert/verschoben werden. Schöne Grüße Jack

Nachtrag: Das Problem steht definitiv in Zusammenhang mit der SIDhistory. Wird diese manuell aus den Userkonten entfernt, dann funktioniert alles tadellos. Eine Lösung für den umfassenden Postfachzugriff bei gleichzeitiger SIDhistory-Nutzung habe ich leider nicht.

Hallo Nils, danke für deinen Tipp. Zunächst dachte ich "sehr abwegig", doch im Nachhinein lagst du gar nicht so weit weg: Der Befehl netdom trust domain.local /domain:domain.weitweg /enablesidhistory:yes wurde zwar mit "ausgeführt" quittiert, doch funktional geändert hat sich nichts, wie in deinem Hinweis. Nach wie vor wurde "Der SID-Verlauf ist für diese Vertrauensstellung deaktiviert." angezeigt. Nach stundenlanger Suche habe ich die Lösung nun gefunden. Mit einem deutschsprachigen Betriebssystem ausgeführt muss der Befehl heißen: netdom trust domain.local /domain:domain.weitweg /enablesidhistory:ja Abgesetzt und alles geht - manchmal sind's die kleinen Dinge.... Schöne Grüße Jack

Hallo, wir haben Probleme beim Zugriff auf Ressourcen in einer Vertrauensstellung. Folgendes Szenario: Standort 1 mit den Domänen a.local und b.a.local, bidirektionale Vertrauensstellung, läuft seit Ewigkeiten. Domäne c.local an Standort 2 wurde mit transitiver Gesamtstrukturvertrauensstellung an a.local angebunden. Ressourcen und Benutzerkonten liegen in b.a.local, User inkl. SID-History migriert nach c.local. auf DC a.local netdom trust a.local /domain:c.local /quarantine => SID-Filterung ist für diese Vertrauensstellung nicht aktiviert. netdom trust a.local /domain:c.local /enablesidhistory => Der SID-Verlauf ist für diese Vertrauensstellung deaktiviert. auf DC c.local netdom trust c.local /domain:a.local /quarantine => SID-Filterung ist für diese Vertrauensstellung nicht aktiviert. netdom trust c.local /domain:a.local /enablesidhistory => Der SID-Verlauf ist für diese Vertrauensstellung deaktiviert. auf DC b.a.local netdom trust b.a.local /domain:c.local /quarantine => Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden. netdom trust b.a.local /domain:c.local /enablesidhistory => Das System kann die angegebene Datei nicht finden. Auf den beiden ersten DCs lässt sich die SID-History durch die Option /enablesidhistory:yes nicht aktivieren, die Status bleiben unverändert. Auf dem dritten DC kann die Vertrauensstellung nicht erkannt werden, weil sie nur transitiv "vererbt" wird und nicht direkt besteht. Wie kann ich nun dafür sorgen, dass die mit SID-History ausgestatteten, aus b.a.local migrierten User in c.local auf Ressourcen in b.a.local zugreifen können? Wo kann ich mit dem Troubleshooting ansetzen? Vielen Dank und schöne Grüße!

Für die Berechtigungsvergabe wurde ECP und PS getestet. Rechte hängen mit großer Mehrheit an Usern, nicht an Gruppen. Die alte Domäne ist noch in Verwendung. Es besteht eine bidirektionale und transitive Vertrauensstellung zwischen a.de und b.de. Migriert wie initial beschrieben wurden die User (als Kopien mit SIDhistory) von c.b.de nach a.de. Dann die Postfächer rüber auf den neuen Exchange. Das AD-Attribut ‚Mail‘ der Quell-User (in c.b.de) wurde an das Zielsystem angeglichen, so dass Autodiscover funktioniert. Diese User aus der Quell-Domäne sind weiter in Verwendung. Geht auch aufgrund von zahlreichen Abhängigkeiten vorerst nicht anders. Also: username.c.b.de meldet sich mit seinen Windows-Anmeldedaten (an c.b.de) an, verbindet sich in Outlook aber mit mailserver.a.de.

Hallo Sunny, es gibt keinen Proxy. Die Firewall zwischen den Netzen ist auf Durchzug konfiguriert, hier gibt es keine Blocks im Log. Für das Autodiscover haben wir eine Forward-Lookupzone (autodiscover.domain.de) erstellt, welche einen Host-Eintrag mit der IP des neuen Exchange enthält. Zertifikate sollten hier auch passen. Den Outlook-Verbindungsstatus habe ich mal überflogen, muss ich aber noch etwas Zeit reinstecken, melde das Resultat dann zurück. Bei der Authentifizierungsproblematik konnte ich folgendes feststellen: User mit ausschließlich persönlichen Postfächern benötigen keine Authentifizierung, läuft. (Wie du beschrieben hast.) User mit zusätzlich eingebundenen ebenfalls migrierten Postfächern haben dort keinen Zugriff drauf und werden auch nicht zur Authentifizierung aufgefordert. User mit Berechtigungen auf zusätzliche Postfächer, die bereits auf dem Zielsystem vorhanden waren, bekommen diese automatisch hinzugefügt und werden beim Öffnen zur Eingabe von Benutzername/Kennwort aufgefordert. Danach ist ein Zugriff möglich - aber dann auch auf die migrierten zusätzlichen Postfächer, die "solo" nicht zur Authentifizierung aufforderten. Soweit der Zwischenstand - ich hoffe das produziert Geistesblitze... :)

Neue Windowsprofile lösen das Problem leider nicht.

Outlookprofile wurden bereits mehrfach bei unterschiedlichen Usern erneuert, danach immer gleiches Verhalten wie vorher. Windowsprofile sind wir noch noch angegangen, machen wir sofort morgen früh! Was meinst du genau mit deinem letzten Satz? Ist eine Passworteingabe bei der Erstverbindung zum persönlichen Postfach erforderlich? Und wenn ja: Wie kann ich das erzwingen, wenn‘s jetzt ohne geht?

Hallo, wir haben ein Problem beim Zugriff auf zusätzlich in Outlook 2010 eingebundene Postfächer. Sie erscheinen links im Menü (per Autodiscover oder auch manuell), doch es erscheint die Meldung "Der Ordner kann nicht erweitert werden. Ein Clientvorgang ist fehlgeschlagen." wenn man einen aufklappen möchte. Die Benutzer- und Gruppen-Konten sowie deren Postfächer wurde von Exchange 2010 auf 2016 cross-forest migriert. Konten mit ADMT inkl. SIDhistory und Passwörtern, Postfächer mit einem Drittanbieter-Tool. Die Vollzugriff-Berechtigungen sind korrekt gesetzt, zur Konfiguration wurden wahlweise das Exchange Admin Center oder PowerShell genutzt. Ein Zugriff auf die Gruppen-Postfächer per OWA ist möglich, so dass kein Zweifel an der Berechtigungskonfiguration der Postfächer besteht. Leider lässt sich dies nicht hundertprozentig reproduzieren. Der weitaus größte Teil der Postfächer lässt sich nicht öffnen. Uns aufgefallen ist allerdings, wir wissen dies aber nicht zu deuten, dass es eine Abhängigkeit zur Authentifizierung an Outlook zu geben scheint. Die meisten User werden bei einer Neuanlage eines Outlookprofils nicht zur Passworteingabe aufgefordert. Der Zugriff auf das persönliche Postfach funktioniert dann, doch aus weitere nicht. Bei wenigen Usern wird bei jedem Outlookstart ein Passwort abgefragt. Dann ist auch der Zugriff auf weitere Postfächer möglich. Ich freue mich auf Hinweise, die uns der Lösung etwas näher bringen. Vielen Dank! Jack