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

Hallo, wir haben eine Vertrauensstellung zwischen zwei Gesamtstrukturen eingerichtet. Die Netzwerke befinden sich an unterschiedlichen Standorten und sind per VPN miteinander verbunden. Es soll nicht die gesamtstrukturweite, sondern die ausgewählte Authentifizierung genutzt werden, in der die Berechtigungen nicht automatisch erteilt, sondern nach Nutzungswunsch vergeben werden sollen. In der ersten (nicht gewünschten) Variante funktioniert alles problemlos. Bei der ausgewählten Authentifizierung lässt sich das entfernte AD aber nicht browsen, es wird nach Anmeldeinformationen von dort gefragt. Diese Variante bringt natürlich mit sich, dass diese Berechtigung explizit (im Netzwerk 2 an User aus Netzwerk 1) erteilt werden muss. Doch welche? Vielen Dank für einen Tipp und schöne Grüße Jack

Hallo, wir haben das Problem, dass alle empfangenen und per S/MIME signierten E-Mails mit einem roten Balken angezeigt werden. Die Zertifikate sind gültig und die Zertifikatskette ist durchgängig. Es wird angezeigt: "Signiert von: Probleme mit der Signatur. Klicken Sie auf die Signaturschaltfläche, um Details anzuzeigen." In diesen Details steht: "Fehler: Der Nachrichteninhalt wurde möglicherweise verändert.". Ich gehe davon aus, dass von Firewall und/oder Virenscanner eine Änderung stattgefunden hat. Im Header der Mail wurde natürlich Informationen ergänzt, wie z.B. Received from/by/time unseres Mailservers und weitere Einträge der Firewall. Ergänzungen im Header sind imo erlaubt/erforderlich und können nicht als signaturrelevante Änderung angesehen werden. Ich habe leider keine Idee, wie ich in diesem Thema weiterkomme. Habt ihr einen Tipp für mich? Schöne Grüße Jack

Super, vielen Dank. Hatte den ganzen Tag recherchiert, doch nichts gefunden was diese Level-Kombi bestätigt. Gibt es da eine Regel, bspw. "n-3 geht, aber n-4 nicht mehr"?

Hallo, ist es möglich, zwischen Gesamtstrukturen der Funktionsebenen 2008 und 2012R2 eine Vertrauensstellung aufzubauen? Schöne Grüße Jack

Hallo, wir setzen einen Fileserver mit W2012R2 und einem Share mit etwa 1,8TB Dateien ein. Das Feature Windows Search ist installiert und alles wurde erfolgreich indiziert, und funktioniert gut. Nun stellen wir fest, dass die Indizierung sporadisch erneut anläuft um (wahrscheinlich) zwischenzeitlich geänderte und neu erstellte Dateien nachzupflegen. Immer dann kommt es zu Performanceproblemen, die sich am Client durch verzögertes Öffnen und Speichern von Dateien (auch bei kleinen Größen >20sec.) und Einfrieren des Explorer-Fensters zeigen. Auf Ressourcenseite (CPU/RAM/HDD/LAN/...) ist der Server währenddessen nicht annähernd ausgelastet. Nun meine Fragen: Ist dieses Phänomen bekannt? Kann man es beheben? Kann man es (vielleicht durch Planung der Indizierung in den Nachtstunden) umgehen? Gibt's eine bessere Lösung, bspw. die eines Drittanbieters, ohne dass Softwareinstallationen am Client notwendig werden? Ich weiß, dass der Sachverhalt bereits oft thematisiert wurde. Habe vieles gelesen, doch letztendlich keine Lösung gefunden. Danke euch! Jack

1:0 für zahni - doppelte IP im Netz! Ein Altgerät heute Morgen testweise in Betrieb genommen. Konnte das vom IP-Report nicht ableiten, früher gab es doch diese "Konflikt-Blasen" im Tray.... Danke und sorry Leute - nächste Runde geht auf mich! Schöne Grüße Jack

Hi, damit meine ich Server mit ähnlicher Konfiguration weil gleicher Einsatzbereich. Hier die Daten eines anderen: Ethernet-Adapter LAN: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : vmxnet3 Ethernet Adapter Physische Adresse . . . . . . . . : 00-50-56-80-XX-YY DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja IPv4-Adresse . . . . . . . . . . : 192.168.1.101(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.1.1 DNS-Server . . . . . . . . . . . : 192.168.1.2 192.168.1.3 NetBIOS ber TCP/IP . . . . . . . : Aktiviert thx...

Hallo, ich habe hier ein Problem mit der Netzwerkkonfiguration eines Servers. Bei zwei weiteren Zwillings- (oder heißt es dann Drillings-?) Servern werden die Zeilen "IPv4-Adresse (Auto. Konfiguration)" und dazugehörige Subnetzmaske (Zeilen 8+9) nicht angezeigt, obwohl auch da die Autokonfiguration (Zeile 7) aktiviert ist. Ethernet-Adapter Ethernet 2: Verbindungsspezifisches DNS-Suffix: Beschreibung. . . . . . . . . . . : vmxnet3 Ethernet Adapter #2 Physische Adresse . . . . . . . . : 00-50-56-A8-XY-YZ DHCP aktiviert. . . . . . . . . . : Nein Autokonfiguration aktiviert . . . : Ja IPv4-Adresse (Auto. Konfiguration): 169.254.195.253(Bevorzugt) Subnetzmaske . . . . . . . . . . : 255.255.0.0 IPv4-Adresse . . . . . . . . . . : 192.168.1.100(Dupliziert) Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.1.1 DNS-Server . . . . . . . . . . . : 192.168.1.2 192.168.1.3 NetBIOS ber TCP/IP . . . . . . . : Aktiviert Ein Netzwerkzugriff ist damit nicht möglich. Hat das jemand vielleicht schon einmal gehabt und einen Tipp für mich? Schöne Grüße Jack

Alles klar, also Loganalyse oder 3rd-Party. Vielen Dank an euch! Bzgl. des Patchstandes musste ich einmal wg. Kompatibilitätsproblemen zurück. Ist aber etwas her, muss ich nochmal checken. Schöne Grüße Jack

Hallo, Standard Edition in der Version 14.3.123.4. Out-Of-The-Box, keine Drittanbietersoftware drauf. Davor ist ein Smarthost in der DMZ, dem kann ich diese Infos aber nicht entlocken... Danke. Jack