RC<-->RC

Hallo Gemeinde, mir ist vor kurzem folgendes Problem von einem unserer MA zugetragen worden. Wir haben einen Exchange 2016. Alles läuft bisher tadellos nach der Migrierung von 2010 ! In Bezug auf die OWA gibt es das Problem, das die Mitarbeiter aber keine Mails löschen können. Sie gehen also in Posteingang, löschen eine Mail, und die Mail ist auch zuänächst weg. Wird der Posteingang aktualisiert, ist die Mail wieder da. Löscht ein Mitarbeiter aus Outlook eine Mail und stellt sie aus den gelöschten Elementen in OWA wieder her, funktioniert das auch. Habe einiges in Bezug auf IIS und bestimmten Berechtigungen gelesen, was aber bisher nicht zur Lösung geführt hat. Die OWA Richtlinie ist Default. Mitarbeiter die Ihre Postfächer über das Handy angebunden haben, können am Handy die Mails löschen. Eben nur in der OWA nicht. Habt ihre eine Idee, wonach ich schauen könnte, Wäre natürlich wie immer sehr Dankbar :- ) Grüße, Rolf !

Funktioniert auch so ohne Probleme Aber ich denke das eine hat nichts mit dem anderen zu tun

Danke

Einen Wunderschönen Guten morgen. Ich habe folgendes "Problem" und hoffe das mir dabei geholfen werden kann Zur Umgebung: Zuvor hatten wir in jedem unserer Standorte einen Exchange 2010. Die Standorte haben auch alle einen DC. Nun habe ich Postfächer und Öffentliche Ordner erfolgreich auf eine Exchange 2016 VM, die auf einem Strato Root Server liegt, und per VPN an unseren Standort gebunden ist migriert. Der Exchange 2016 oder besser gesagt der Root Server verfügt über eine Feste IP. Wir haben eine Subdomain an den Exchange gebunden, sodass er über Subdomain.domain.de erreichbar ist für OWA und ECP ! Zum eigentlichen Problem: Die Öffentlichen Ordner haben Kontakte, die mit Bildern versehen sind, auch Kalender mit sehr vielen einträgen. Nach der Migration habe ich das Gefühl, das es schon merklich länger braucht. Die Bilder kommen nur so nach und nach, der Kalender brauch auch etwas länger ! Zudem habe ich festgestellt das im Verbindungsstatus, der lokale weg zum Exchange 2016 als Servername steht, also Servername.domain.local. Dort sollte aber die öffentliche Domain stehen. Was darauf schließen lässt, das alles über die VPN geht. Ich möchte aber, das dies alles direkt über das Internet geht, und nicht über die VPN. Get-WebServicesVirtualDirectory EWS (Exchnage Back end) = mit nichts belegt EWS ( Default) = Subdomain -------------------------------------------------------------------------------------------- Get-ClientAccessServer | fl Name,AutoDiscoverServiceInternalUri https://subdomain.domain.de/Autodiscover/Autodiscover.xml --------------------------------------------------------------------------------------------- Get-WebServicesVirtualDirectory -server servername Name Server InternalUrl Microsoft-Server-ActiveSync (Default... Servername https://subdmain.domain.de/ ------------------------------------------------------------------------------------------------------------------------- Also es deutet nichts darauf hin, das er den internen Weg gehen soll, aber im Verbindungsstatus steht der lokale Servername! Muss ich dazu nun unbedingt das Split DNS einrichten, indem ich auf die Subdomain.Domain.de verwaise, oder liegt der Hund noch irgendwo anders begraben ? Wenn ich die Email Autokonfiguration teste, kann ich auch nichts feststellen...alles deutet auf den Subdomain.domain.de und nicht auf den lokalen Weg ! Vielen dank für eure Mühe im voraus !

Moin Moin. Dort steht im Prinzip das was dort stehen soll. Also unter HTTP Proxyserver steht (https://subdomain.de --> nicht *.dyndns.org) wie im Fehler zu sehen ist Das interessante, unter Outlook 2010 in einem anderen Standort steht genau das selbe, dort kommt aber nichts von der Fehlermeldung *.dnydns.org ! Zum anderen, da der Exchange sowohl intern über VPN als auch extern über die Subdomain mit seiner externen IP erreichbar ist, würde ich gern das die Clients in den Standorten wie bei Outlook 2010 zu sehen vorrangig über HTTP/HTTPS gehen, also über die Subdomain. Wenn ich mir bei Outlook 2016 aber den Verbindungsstatus ansehe, wird mir dort der Lokale Domänen Pfad zum Exchange angezeigt, und nicht wie bei Outlook 2010 die Subdomain ?! Kann mir das jemand erklären ?Geht er bei Outlook 2016 bevorzugt den internen, bzw den schnelleren Weg, und warum ist das bei Outlook 2010 nicht so ? Was mir noch auffiel: unter dem Verbindungsstatus bei Outlook 2010 sowohl an den standorten wo der Fehler kommt und dort wo er nicht kommt, steht als Servername (Lange-Zahl-mit-Buchstaben@domainname.de) DNS Auflösung bisschen falsch ? Noch etwas: Wenn ich : Get-WebServicesVirtualDirectory -server servername| fl *url* eingebe Ist die Interne URL : https://Servername.Domäne.local Ist die externe URL: https://ÖffentlicherServername.Domäne.de Wenn ich die interne URL = externe URL ändere, würden doch alle Clients nicht mehr über den internen Weg gehen (Outlook2016) sondern nur noch den öffentlichen Weg oder ? Viele Grüsse, Rolf !

Die sind auf die externe Subdomain eingestellt, mit verwais auf die Externe IP des Exchange. https://Subdomainname/Autodiscover/Autodiscover.xml" Get-OutlookProvider ist mit keinem Zertifikat hinterlegt ! Outlook-Anywhere auch Name der Subdomain mit dem Verwais auf die öffentliche IP des Exchange Warum, weil wir unseren Exchange gern über eine Öffentliche IP erreichbar machen wollten. Zur Umgebung. 5 Standorte, bisher in jedem ein Exchange, die dann abgelöst werden sollen. Der öffentliche Exchange ist per OWA/ECP usw richtig konfiguriert. Er ist per VPN an unsere Domäne angebunden und kein DC ! Was mir aufgefallen ist, bei den Standorten bei denen der Fehler mit dem Dyndns nicht kommt, zeigt er im Outlook unten rechts (Verbunden mit Exchange an und in den Kontoeinstellungen unter anzeige des Servers MailboxID@domain.de) an Bei den Standorten wo es nicht funktioniert, steht (Online mit Exchange) und unter den Kontoeinstellungen unter anzeige des Servers (Subdomain/mapi/emsmdb/MailboxID@domain.de) Beide Seiten mit jeweilis Outlook 2010 probiert ! Die scheinen unterschiedliche wege zum Postfach zu gehen oder seh ich das Falsch ?! Hoffe ich habe mich halbwegs klar ausgedruckt . Grüße, Rolf !

Hallo Liebe Gemeinde, wie im Thema leicht angedeutet, hier die Konkrete Fehlermeldung: Es ist dabei völlig egal ob ich es mit Outlook 2010 oder 2016 teste. Es betrifft vereinzelte Locationen, was heißt, das es an Rechnern eines Standortes nicht auftritt, aber dafür an einem anderen Standort Das Testpostfach liegt dazu auf dem Exchange 2016 welcher auf einem Strato Root liegt ! Die Fehlermeldung klickt man weg, und alles läuft wie gewohnt, bis zum neustarten von Outlook. Das Zertifikat des Exchange welches selbst signiert ist, wird per GPO ausgerollt, natürlich an alle Standorte! Habe an den Rechnern an denen es auftritt mit den Rechnern wo es nicht auftrifft verglichen. Die Zertifikate sind die selben (Vertrauenswürdige Stammzertifizierungsstellen) was Fingerabdruck und Namen usw. betrifft. Wenn ich die OWA öffne und mir das Zertifikat anschaue, ist das auch das selbe was ausgerollt wird ! Das *Name.dyndns.org* welches in der Fehlermeldung steht, ist im Zertifikat unter Alternativer Antragstellernamen eingetragen. Über Dyndns.org gehen die Rechner zum Exchange nicht mehr (rührt aus alten Zeiten, und wird anderweitig noch gebraucht) da er ja direkt mit fester IP Ansprechbar ist. Sollte ich das aus dem Zertifikat heraus nehmen ? Ist das der Fehler ? Könnt ihr mir einen Tipp geben ? In Foren les ich, das dass Zertifikat nicht im Zertifikatsspeicher des Rechners liegt. Das ist es aber, und das richtige dazu. Wie gesagt, in manchen Standorten funktioniert ist regelkonform. Die Zertifikate werden in jeden Standort ausgerollt. Die Rechner bei denen es nicht funktioniert haben die Zertifikate, wie auch die, bei denen es funktioniert ! Vielen dank. Rolf !

Moin Norbert, zum einen, vielen dank für die PS. Hatte das wohl bei der Sequentiellen Abarbeitung 1.Enable-Mailbox -Arbitration -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" 2. Set-Mailbox “Migration.8f3e7716-2011-43e4-96b1-aba62d229136” -Arbitration -Management:$true Einfach nach der Fehlermeldung der 1. PS nicht ausprobiert. Also Danke Zum anderen, Knackpunkt: Naja, ich finde die Öffentlichen Ordner aus 2010 auf 2016 schon ein bisschen mehr Tricky als nur Mailpostfächer von A,B,C,D,E zu Z zu verschieben Gern kannst du da einer anderen Meinung sein :-D Grüsse, Rolf ! Habe im übrigen noch 2 Fehler festgestellt :-( Zum einen gibt es wohl ein Kerberos Problem was die Warteschlangenanzeige betrifft, wofür ich bisher noch keine Lösung gefunden habe : Zum anderen wird desöferten der Transportdienst nicht gestartet nach einem Neustart: Konfiguation hierbei ist : Starttyp:Automatisch Anmeldung : Konto: Netzwerkdienst Wiederherstellung: erster, zweiter, weitere Fehler: jeweils Dienst neu starten. Trotzdem bleibt der Dienststatus beendet. Wie gesagt, bisher wie mir aufgefallen ist, immer nach einem Neustart. Sobald manuell gestartet, bleibt er auch an ! Werde selbstverständlich recherchieren, aber wenn jemand eine sofortige Antwort dazu hat, werde ich der sehr gern nach gehen Grüsse, Rolf !

UPDATE: Enable-Mailbox -Arbitration -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" Dieser Task unterstützt keine Empfänger dieses Typs. Der angegebene Empfänger ist vom Typ UserMailbox Kann ich jetzt nicht so richtig nachvollziehen :-( Erstellt wurde die Migrationsmailbox ja vom Setup des Exchange !

Die Lösung wird sein, alle Postfächer nach und nach in den jeweiligen Standorten auf den neuen Exchange 2016 umzuziehen, die alten Exchanger aus dem AD zu kratzen, und die DCs runter zu stufen um diese folglich genau so aus dem AD zu werfen Knackpunkt nach dem Umziehen der Postfächer werden die Öffentlichen Ordner sein, die auf den neuen Exchange Migriert werden müssen. Aber Frankysweb hat dazu sehr sehr gute Schritt für Schritt Anleitungen, die ich im Testnetz recht gut nachempfinden konnte Ein Problem habe ich dann doch noch. Und zwar das Migrationsbatch für Postfächer. In der ECP unter Migration erstellen, beschreibt er mir, das meine Organisation kein gültiges Migrationspostfach besitzt. Wie Franky hier folglich richtig beschreibt https://www.frankysweb.de/exchange-2016-systempostfaecher-neu-erstellen/ sind die Systempostfächer nicht richtig ausgewiesen. Aber über die Befehle : get-mailbox -Arbitration get-mailbox -AuditLog werden alle richtig angezeigt. Sie sind im AD unter Users auch vollständig. Auch das Migrationspostfach. Hatte diese auch schon wie Franky beschreibt neu angelegt ! über einen New-Moverequest Per Shell funktioniert das verschieben auf den neuen Exchange tadellos !

Hallo. Ich habe 2 VMs im Hyper V. Eine davon startet sofort im Erweiterten Sitzungsmodus. Die andere Nicht, also nicht sofort Na circa genau 8-9 Minuten bietet mir die andere VM dann an, mich im erweiterten Sitzungsmodus anmelden zu können. Melde ich mich ohne erweiterten Sitzungsmodus an, kann ich weder die LAN Einstellung noch die Systemsteuerung öffnen, erst sobald ich den Erweiterten Sitzungsmodus starten kann, funktioniert wieder alles Tadellos... Kennt jemand das Phänomen der verzögerten Sitzungserweiterung ? Die ganzen Einstellungen zum Erweiterten Sitzungsmodus in Hyper-V sind richtig ! Bilde mir ein, das dies erst nach der Installation des Exchange 2016 anfing ! LG. Rolf !

Ja :-D Das erübrigt sich aber dann mit den DCs, da dort schon neue stehen, aber auf den DCs mit 2008 fälschlicherweise auch der Exchange installiert wurde Noch eine kleine andere Frage, die ich im VM Umfeld zu Hyper V habe: Ich habe 2 VMs im Hyper V. Eine davon startet sofort im Erweiterten Sitzungsmodus. Die andere Nicht, also nicht sofort Na circa genau 8-9 Minuten bietet mir die andere VM dann an, mich im erweiterten Sitzungsmodus anmelden zu können. Melde ich mich ohne erweiterten Sitzungsmodus an, kann ich weder die LAN Einstellung noch die Systemsteuerung öffnen, erst sobald ich den Erweiterten Sitzungsmodus starten kann, funktioniert wieder alles Tadellos... Komisch oder ? Die ganzen Einstellungen zum Erweiterten Sitzungsmodus in Hyper-V sind richtig !

UPDATE : ES FUNKTIONIERT :-D Diese KACK (entschuldigt diesen Ausdruck) Microsoft.Exchange.Services.Json.dll habe ich einfach aus der CU6 DVD gesucht und in das BIN Verzeichnis des EXCHANGE Server kopiert. Danach in der CLIENTACCESS und HTTPPROXY in der SharedWebConfig folgendes hinzugefügt : <dependentAssembly> <assemblyIdentity name="Microsoft.Exchange.Services.Json" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <codeBase version="15.0.0.0" href="file:///D:\Exchange-Server\\bin\Microsoft.Exchange.Services.Json.dll" /> </dependentAssembly> Genau das, was er eben vergeblich nicht finden konnte. Man sollte einfach mal das machen was da steht :-D Trotzdem Vielen dank für eurer Feedback und eure Hilfen !

UPDATE: Hat nun doch funktioniert : Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint Set-AuthConfig –PublishCertificate Zertifikate werden nun wieder richtig angezeigt ohne Fehler ! Die UpdateCAS und die UpdateConfigfiles.ps1 habe ich auch ausgeführt nachdem ich den IIS neugestartet habe. Auch habe ich den Server neu gestartet ! Leider ohne Erfolg ! :-( Gibt es weitere Möglichkeiten ? Bisher habe ich noch das Framework 4.7.1 drauf, das müsste ich noch auf 4.6.2 machen richtig ? Der Fehler bleibt der gleiche ... Ereignis ID 1309 ASP.NET 4.0.30319.0 Application Virtual Path: /owa Application Path: D:\Exchange-Server\ClientAccess\owa\ Process ID: 7020 Process name: w3wp.exe Account name: NT-AUTORITÄT\SYSTEM Die Datei oder Assembly "Microsoft.Exchange.Services.Json, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden. bei System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app) bei

Moin Moin Norbert Ich habe die 3 Exchange Zertifikate : Das erste für den SMTP Dienst gegenüber anderen Exchange Servern nehm ich an Das Zweite gegenüber der Authentifizierung der Benutzer (Dienste IMAP,POP und IIS und SMPT) Keines der Zertifikate enthält den Fingerabdruck den er gern möchte zur Veröffentlichung ! Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint Ein spezieller RPC-Fehler ist auf Server SERVERNAME aufgetreten: Das Zertifikat mit dem Fingerabdruck '7685D2B5CCB4E278CB416218E719072A3DCB892D' wurde nicht gefunden. Das Exchange Server Auth Certificate existiert ja bereits ! Was muss ich denn tun, das er nicht mehr nach dem nicht mehr vorhandenen Zertifikat sucht, um dann per Befehl : Set-AuthConfig -PublishCertificate diese Fehlermeldung nicht mehr zu erhalten ? : "Das Zertifikat, das als Nächstes verwendet werden kann, muss eingerichtet sein, bevor es veröffentlicht werden kann" Vielen dank zunächst für deine/eure Hilfreichen Links, aber so ganz hilft es mir leider nicht weiter, da ich damit zwar neue Zertifikate erstelle, sich der Fehler nach einem nicht mehr vorhanden Zertifikat, was er möchte nicht erübrigt :-(

Nach Erstellung des neuen Zertifikats und der Eingabe von Set-AuthConfig –PublishCertificate kommt nun folgender Fehler ?! Das Zertifikat, das als Nächstes verwendet werden kann, muss eingerichtet sein, bevor es veröffentlicht werden kann. Puh, da muss ich mich wohl nochmal ein wenig belesen

Gut, den gleichen Fehler wie auf der Seite bekomm ich auch :-( Ich werd es mal probieren und berichte !

könntest du mir das näher erklären ? Ich mach das CU7 denk ich jetzt mal drüber und mach die Framework 4.7.1 weg und die 4.6.2 drauf, denk ich

Lad es mir gerade, ohne für mich verifiziert zu haben, ob es mit 2008 ohne R2 funktioniert

Moin Moin, habe die UpdateCas.ps1 wie zuvor schon erwähnt ausprobiert ! Ohne Erfolg ! Aufgefallen ist mir, das dass Framework 4.7.1 schon drauf ist, und nicht wie fälschlicherweise behauptet, die 4.0 ! Zudem kann ich nicht auf die CU8 , da die DomänenFunktionsEbene mit dem CU8 auf auf 2k8 R2 Steigt, und ich noch 2 Domänencontroller in anderen Standorten habe, die leider nur Win Server 2008 inne haben. Somit kann ich das CU8 nicht einfach drauf machen, sondern müsste diese erst auf R2 bringen ! Bin kurz davor die Maschine einfach neu zu machen, und von vorn zu beginnen, anstatt noch ewig zu suchen :-( Zumal noch nicht viel drauf ist, und das ding ja über den ADSI recht schnell wieder raus gekehrt ist ! Also die Postfächer sind alle von mir geerbte Test Administratoren ( Im AD von meinem Account kopiert) Also die AD Konten stammen alle von meinem Konto ab, falls du das meinst ?! @MRCOCKTEIL ExchangeLegacyDN ist korrekt? ADCDisabledMail Flag? Die Self Berechtigungen stimmen? Puhh, damit kann ich leider nix anfangen, das müsst ich mir erst anschauen, was du damit überhapt meinst, es sei denn du erklärst es mir gern, dann les ich es gespannt, und verinnerliche gleichzeitig

Wie gesagt, der root server sowie die vms sind lizenziert. Der exchange bisher nicht. Bedenken habe ich da aber keine. Es ist eben nur komisch das es die owa unter den Postfächern des 2016 betrifft. Und warum sollte es unter der CU6 nicht auch laufen?! Ich werd die Updates erst mal drüber bügeln, aber bin keiner grossen Hoffnung. Vielleicht gibt es ja noch andere Ideen. Wäre natürlich weiteren Erfahrungen sehr dankbar.

Dann hab ich sie wohl nicht richtig verstanden Der 2012R2 ist lizenziert. Der exchange bisher nicht.

@norbert... Ist ein root server, auf dem 2 hyper v vms laufen. Unter anderem eben der exchange2016... Und ja das funktioniert ganz gut... Viel rum gefummel aber es funktioniert tadellos... Bis eben auf die OWA der Postfächer vom 2016 :-(

Hi Doso, Die Exchange 2010 sind auf dem Rollup 18 vom Juli 17 14.03.0361.001 Framework Version 4.0 ...Auch etwas älter :-( Der Exchange 2016 ist somit zeitlich gleich, bzw etwas hinter her. Aber sollte es daran liegen ?

Hallo an die Exchange Gemeinde, ich habe folgendes Problem, was mich seit ein paar Tagen kontinuierlich beschäftigt Wir haben einen Exchange 2016 CU6 auf einem virtuellen 2012R2 der auf einem Strato Host liegt und per VPN ins Unternehmen gelangt, und so auch mit anderen Exchange Servern (2010) kommuniziert All die jenigen die sich über den neuen Exchange über die OWA anmelden, und deren Postfach noch auf dem 2010er liegen, bekommen diese auch normal angezeigt ! All die jenigen(bisher nur ich und 2 Test-Postfächer) die sich über die OWA des neuen Exchange anmelden und deren Postfach auch schon auf dem neuen Exchange liegt, bekommen nachstehende Fehleranzeige ! Es funktioniert eigentlich alles Tadellos, bis auf das bei der OWA immer kommt --> da hat etwas nicht geklappt ! Fehler ist im übrigen um eine Stunde versetzt, da es zu dem Zeitpunkt eigentlich 16:40 Uhr war in der Fehlermeldung aber 15:40 Uhr angezeigt wird ! Alle Server laufen aber zeitlich syncron ! #Die ECP funktioniert einwandfrei ! #Die beiden CONFIG Dateien (SharedwebConfig unter ClientAccess und HTTPProxy) sind vorhanden ! was mir dabei aufgefallen ist, ist das der Pfad in den Dateien zunächst komisch aussah, Beispiel : href="file:///D:\Exchange-Server\\bin\BigFunnel.Common.dll Zu erkennen ist, das er nicht auf dem StandardPfad installiert ist, was auch stimmt, aber er 2 \\ vor bin hat. Sobald ich dies mit einem \ für alles ersetzte funktioniert gar nichts mehr, auch keine ECP. #Die UpdateCas.ps1 habe ich schon einmal drüber laufen lassen, ohne Erfolg ! #Das Ereignisprotokoll sagt, sobald ich die OWA im Explorer ausführe für Exchange Postfächer die schon auf ihm selbst liegen folgendes : ------------------------------------------------------------------------------------------------------------------------------- Event code: 3005 Event message: Es ist eine unbehandelte Ausnahme aufgetreten. Event time: 02.02.2018 16:19:33 Event time (UTC): 02.02.2018 15:19:33 Event ID: f7102678d4ef45ada06dcb9120de0778 Event sequence: 2 Event occurrence: 1 Event detail code: 0 Application information: Application domain: /LM/W3SVC/2/ROOT/owa-61-131620583689220000 Trust level: Full Application Virtual Path: /owa Application Path: D:\Exchange-Server\ClientAccess\owa\ Machine name: MAILGATE Process information: Process ID: 6876 Process name: w3wp.exe Account name: NT-AUTORITÄT\SYSTEM Exception information: Exception type: HttpException Exception message: Die Datei oder Assembly "Microsoft.Exchange.Services.Json, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden. ------------------------------------------------------------------------------------------------------------------------------------------------------------ Also ziemlich eindeutig, leider weiß ich nicht wie ich den Fehler so einfach beheben kann und bitte um Hilfe !