john23

Danke für die Info

Wenn es viele User sind dann würde ich ein zentrales Gateway empfehlen z.B. NoSpam Proxy. Bei mehr als 5 Benutzern ist das in Outlook echt bescheiden. Ständig verliert Outlook irgendwelche Kontakte mit den öffentlichen Schlüsseln der Gegenaparteien. Zumindest mit 2010 macht des keinen Spaß. Gruß John23

Hast du versucht die Regel aufzuteilen und nicht alles in eine zu Packen?

Welche App verwendest du gerade auf welchem Mobilen Gerät? Du machst das nicht zufällig gerade mit einem Admin Account?

Na ja Ports alleine reichen ja nicht wenn der Dienst dahinter nicht läuft. Port 443 frei ist schon und gut. Sind die Virtuellen Verzeichnisse konfiguriert? Active-Sync ? Autodiscover? http://www.mustbegeek.com/configure-external-and-internal-url-in-exchange-2016/

Auch wenn schon behoben: Iich habe 1x folgendes gebraucht ( mit Micorosoft Support durchgeführt) get-servercomponentstate -identity ws12exchange Alle Komenenten müssen an sein bis auf ForwardSynchDeamon und ProvisioningRPS Bei deaktivierten Elementen kann man z.B. mit folgendem Befehl wieder aktivieren. set-servercomponentstate -component MApiProxy -identity ws12exchange -State Active - Requester Healthapi / Functional Der Support sagte nach Exchange Updates werden die einzelnen Komponenten nicht mehr auf Active gesetzt, was zu unterschiedlichen Problemen führen kann. Gruß John23

https://testconnectivity.microsoft.com/ Hilft mir immer - leg dir einen Testaccount an (ohne Admin Rechte) und teste mit der Seite. Ergebnisse auch gerne hier Posten wenn keine Idee besteht. Generell habe ich in letzter Zeit bemerkt, dass immer mehr mobile Geräte keine eigen signierte Zertifikate mehr zulassen. Unterschiedliche Mail Apps (zumindest Android + Samsung) streiken da regelrecht. Mfg John

Ok hier mal ein Update. Nach der Migration auf den neuen Exchange 2007 bleibt ja das Problem den alten Exchange zu entfernen. Nach ewigem suchen und viel hin und her war auf einmal folgender Log Eintrag sichtbar. Couldn't find local patch 'C:\Windows\Installer\xxxxx.msp'. Looking for it at its source. (id habe ich leider nicht mehr) Note : ASEntSig-x64-3.3.8515.123.MSP Google suche zu ASEntSig-x64-3.3.8515.123.MSP ist ziemlich leer, aber abgewandelt habe ich folgenden Thread gefunden - https://social.technet.microsoft.com/Forums/en-US/0d6e2341-9610-47f1-87a2-e66111fa82e7/exchange-2007-error-1635-installing-sp3?forum=exchangesvrdeploylegacy Dort ist folgendes in dem Lösungspost zu finden =>Installed windows cleanup utility and removed the below two applications + Microsoft Exchange 2007 Enterprise Anti-Spam Signature. + Microsoft Exchange 2007 Enterprise Block List Update. Da es eine SBS ist kann eigentlich auch kein Enterprise Mist installiert sein --> Also Windows Cleanup untitily runtergeladen und die beiden dinge entfernt. Danach konnte die Hub Transport Rolle deinstalliert werden, aber folgender Fehler noch: MIS Log erneut geprüft: I (s) (E0:E4) [13:45:09:686]: Couldn't find local patch 'C:\Windows\Installer\225cc0.msp'. Looking for it at its source. MSI (s) (E0:E4) [13:45:09:686]: Resolving Patch source. MSI (s) (E0:E4) [13:45:09:686]: User policy value 'SearchOrder' is 'nmu' MSI (s) (E0:E4) [13:45:09:686]: User policy value 'DisableMedia' is 0 MSI (s) (E0:E4) [13:45:09:686]: Machine policy value 'AllowLockdownMedia' is 0 MSI (s) (E0:E4) [13:45:09:686]: SOURCEMGMT: Media enabled only if package is safe. MSI (s) (E0:E4) [13:45:09:686]: SOURCEMGMT: Looking for sourcelist for product {AE563467-347F-4CFD-A70A-540C2EC5F0AE} MSI (s) (E0:E4) [13:45:09:686]: SOURCEMGMT: Adding {AE563467-347F-4CFD-A70A-540C2EC5F0AE}; to potential sourcelist list (pcode;disk;relpath). MSI (s) (E0:E4) [13:45:09:686]: SOURCEMGMT: Now checking product {AE563467-347F-4CFD-A70A-540C2EC5F0AE} MSI (s) (E0:E4) [13:45:09:686]: SOURCEMGMT: Media is enabled for product. MSI (s) (E0:E4) [13:45:09:686]: SOURCEMGMT: Attempting to use LastUsedSource from source list. MSI (s) (E0:E4) [13:45:09:686]: SOURCEMGMT: Trying source D:\. MSI (s) (E0:E4) [13:45:09:686]: Note: 1: 1402 2: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer 3: 2 MSI (s) (E0:E4) [13:45:09:701]: Note: 1: 2203 2: D:\Exchange2007-KB970162-x64-DE.msp 3: -2147287038 MSI Paket bei Google gesucht - Rollup 9 SP1 - oh Wunder. In den C:\Windows\Installer rein und umbenannt. --> Exchange deinstallation erfolgriech. An einen nicht produktiven Exchange fummelt es sich leichtfertiger. TLDR: Ich glaube das Problem war von Anfang an einige fehlende MSP Dateien - kann man durch Logs wohl raus bekommen und die falschen Enterprise Produkte welche nicht da waren er diese aber deinstallieren wollte.

Danke für die Info :)

Der SBS ist schon eine VM aber der Server ist 2TB groß. Mal ganz davon abgesehen, ob das rumgeteste jemand auch noch bezahlen will. Glaube dann bin ich schneller dran wenn ich eine migration von Exchange 2007 nach Exchange 2007 mache und dann nach 2013. Das ganze ist nun erst mal etwas nach hinten verschoben. Ich berichte dann wie es ausgegangen ist.

Die Supporten auch noch Exchange 2007? Wir haben als Microsoft Partner auch 20 kostenlose Calls im Jahr. Dachte nur nicht daran, da Exchange 2007 aus allen Support raus ist.

Habe ich befürchtet. Ist auch immer schon an live Systemen rumzutesten. Gibt ein paar Threads dazu, selbst hier im Forum. Werde wohl das hier versuchen https://community.spiceworks.com/topic/289210-exchange-2007-sp3-update-fails-with-network-resource-is-not-available

Laut Systemsteuerung SP1 RU9 - MSI Log sagt aber er kann das Paket für RU10 nicht in Windows/installer finden. Powershell sagt es ist nur SP1 RU1 drauf ( wobei das von einem Fix versuch von mir stammen kann - Es gab auch einen Ordner in Windows/installer - welcher ihm fehlte, den habe ich mir von einer anderen SBS installation geholt C:\Windows\Installer\{24B2C164-DE66-44FE-B468-A46D9D5E6B31} da ist eine Powershell.exe drin vom Exchange) . MSI Log - Unable to create a temp copy of patch 'Exchange2007-KB949870-x64-DE.MSP'

Kann was putte gehen wenn ich ein RU Update wieder via Systemsteuerung deinstalliere? Das wäre noch ein Versuch wert. Installieren kann ich kein RU mehr wie oben steht. Link 2 trifft nicht zu. Link 1 wäre auch ein versuch wert.

Hallo Leute, ich habe hier einen sehr blöden SBS 2008 - Exchange 2007 SP1 ru9 ( zumindest sagt mir das Programme und Funktionen / installierte Updates ( Die logs sagen The locally installed version is 8.1.240.6. - was SP1RU1 wäre) Powershell sagt 08.01.0393.001 - RU9. Ich kann kein RU 10 installieren und auch kein SP3 - welches ich für die Migration auf Exchange 2013 brauche. Laut dem SP3 Setup kann er ein Produkt nicht entfernen ( sieh Bild) - in den Logs ist das gleiche zu finden. Goggle sagt mir das die Produktid von dem RU10 von Exchange 2007 ist. Erst hatte ich auch den Fehler, dass Setup konnte den Pfad 'C:\Program Files\Windows Small Business Server\Bin\CMPNENTS\EXCHSRVR80' nicht finden.Die Logs ergaben dann, dass die 11df0.msi in Windows/installer fehlt - Ich konnte diese Datei aber über die SBS CDs finden und in das Vezeichniss legen. Danach ist die EXCHSRV80 Meldung auch verschwunden - wirklich weiter gebracht hat mich das aber leider nicht. Nach der Fehlerbehebung mit der 11df0.msi kann ich kein RU Setup mehr starten - Stellen Sie sicher, dass das Paket existiert und versuchen Sie es erneut".. Jemand eine Idee wie ich an das Ziel kommen kann? Zusätzlichen Exchange 2007 in der Umgebung installieren? Irgendwie noch eine reperatur idee? Mit dem aktuellen Patch stand komme ich leider nirgends hin. ExchangeSetup.txt ExchangeSetupMSILog.txt

Patch Stand ist eine gute Frage - ich habe den Exchange nicht installiert nur die öffentlichen Ordner migriert. Ich prüfe mal - CU20 , also aktuell. Mapi ist auch auf Outlook.domain.de Split DNS passt. Clients sollten gepatched sein - werde da aber nochmal speziell fragen / drauf hinweisen. Exchange 2007 ist mitlerweile deinstalliert. Public Folders habe ich mit einigen Schwierigkeiten rübermigrieren können.

ECP - https://outlook.domain.de/ecp OWA - https://outlook.domain.de/owa Active Sync https://outlook.domain.de/Microsoft-Server-ActiveSync OBA https://outlook.domain.de/OAB EWS https://outlook.domain.de/ews/exchange.asmx Outlook Anywhere outlook.domain.de AutoDiscoverServiceInternalUri : https://outlook.domain.de/Autodiscover/Autodiscover.xml SCP = https://outlook.domain.de/Autodiscover/Autodiscover.xml Autodiscover (Default Web Site) exchange internalurl --> leer Set-AutodiscoverVirtualDirectory -Identity “Autodiscover (Default Web Site)” -InternalUrl ”https://outlook.domain.de/Autodiscover/Autodiscover.xml” Es wurde kein Parameter gefunden, der dem Parameternamen "InternalUrl" entspricht. Übrigens zeigt auch die Verbidungsliste in Outlook, dass alle Verbidungen auf outlook.domain.de gehen. Der Exchange 2007 existiert noch. Es ist aber schon alles auf Ex2013.

Hallo Leute, ich hatte da schon mal bei einer Exchange Installation und nun taucht es wieder auf und ich weiß nicht so recht wo es herkommt. Exchange wurde von 2007 auf 2013 migirert und alle URLs auf outlook.domain.de umgestellt. Es gültiges Zertifikat gibt es auch. Einige Clients (Outlook 2010) erhalten nun folgende Meldung - siehe Bild. Der Fehler beinhaltet den lokalen Exchange Namen exchange.domain.local - ich habe alle Konfigurationen nochmals geprüft und bekomme nicht raus woher das nun noch kommen mag. Jemand noch eine idee? In der anderen Umgebung wo ich das Problem hatte ist der Fehler irgendwann von selbst verschwunden. Lediglich wenn ich dort den Exchange neu starte, taucht die Proxy Fehlermeldung noch im Outlook auf, wenn Outlook am Client geöffnet ist.

Danke - Manchmal ist es schwer dir etwas zu entlocken ;)

Das erste habe ich ja mit dem neuen Namen - da alles für den neuen Namen durchkonfiguriert ist. Hilf mir auf die Sprünge, an welcher Stelle die Trennung zu den Legacy Protokollen stattfindet.

Je nach dem wie groß die Umgebung ist tauchen eventuell nach und nach Systeme auf wo noch der alte Server eingetragen ist. Aber gibt hier wohl nur eine richtige Lösung - Umstellen. Vollständige Dokumentation wäre ja ein feuchter Traum, wenn man dann im vorhinein weiß wo man überall was anpassen muss...

Ich habe den Alias erst mal entfernt. Es ist auch nur eine kleine Umgebung. Gibt es eine Möglichkeit den alten Exchange Namen mitzunehmen?

Den alten Server gibt es nicht mehr und das Computerobjekt auch nicht mehr - nur noch einen Alias mit dessen Namen im DNS.

Autodiscover ist auch durchkonfiguriert und hatte bisher auch keine Probleme damit. Zustand seit Dezember 2017. Für Outlook ergbit das auch keinen Sinn für mich. Andere Geräte - Drucker - Systeme die via SMTP anmelden sollte das ja egal sein. Die sollten über den Alias eigentlich an den neuen Exchange kommen oder nicht? Mein Problem ist aber Outlook momentan.

Hallo Leute, ich wollte nach Erfahrungen fragen. Ist es möglich einen Exchange 2016 mit einem Alias vom alten Exchange zu betreiben ohne Fehler? Ich habe hier eine Umgebung wo der neue Exchange den alias vom alten Exchange mitbekommen hat, falls es noch Systeme gibt die mir nicht bekannt sind welche den alten Namen verwenden. Nun habe ich bereits 3 Clients welche teilweise schwierigkeiten hatten den Exchange Server zu kontaktieren. Im Eventlog habe ich den Kerberos Fehler 4 gefunden welcher sagt, dass der Name nicht übereinstimmt und das Token dadurch nicht entschlüsselt werden kann. Ich bin mir hier aber nicht 100% sicher ob es der Grund ist. The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server ws16ex$. The target name used was cifs/exchange2010.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOMAIN.COM) is different from the client domain (DOMAIN.COM), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.