philippr

Hallo, habe bei meinem Exchange 2013 CU3 folgendes problem was ich selbst nach Tagelanger Fehlersuche nicht beheben konnte: Bei der Sicherung mittels Mailstore über EWS kommt die Meldung "EWS Error Code: ErrorMessageSizeExceeded." bei Mails mit anhängen größer als 20.137 KB (19,6MB). Daraufhin überprüfte ich sämtliche Einstellungen der EWS , allerdings liegen die Standardwerte ja schon deutlich über diesen 19,6 MB (Base64 ca. 26,5MB) (maxAllowedContentLength="67108864"). Einstellungen der maxSendSize und receiveSize sind jeweils knapp 300MB Bei zugriffen über EWS oder OWA lassen sich keine Mails mit dateianhängen über 19,6 MB öffnen . Die Vorschau im OWA zeigt mir die korrekte Mail incl. Anhang an und ich kann aus der Vorschau heraus auch Anhänge bis zu der von mir eingestellten Maximalgröße (300MB) speichern. Senden und empfangen lassen sich ebenfalls Mails bis zur maxGröße. Beim Doppelklick auf eine Mail >19,6 MB kommt allerdings folgende Fehlermeldung: Error: Your request can't be completed right now. Please try again later. Beim Zugriff über Outlook tritt dieses Problem nicht auf. Da ich momentan echt nichtmehr weiss wo ich noch suchen soll hoffe ich das mir hier evtl. jemand einen Tipp geben kann. schonmal Danke im Vorraus

das hatte ich auch schon vermutet, allerdings ist im DNS der Eintrag in Kleinbuchstaben und nslookup liefert ja immer Kleinschreibung auch bei großgeschriebenem DNS Eintrag. @RoberWi, die Fehlermeldung bezieht sich direkt auf den Namen server.domain.local ... entspricht nicht SERVER.domain.local Die Ausgabe von Get-ClientAccessServer Name : SERVER Fqdn : SERVER.domain.local müßte eigentlich auch so aussehen: Name : SERVER Fqdn : server.domain.local irgendwoher muß er doch diesen falschen Fqdn Eintrag holen

ok, hab das gerade mal überprüft. Get-OutlookProvider | ft Identity,CertPrincipalName Identity CertPrincipalName -------- ----------------- EXCH msstd:server.domain.local EXPR msstd:server.domain.local WEB Get-OutlookAnywhere | ft Server,ExternalHostname,InternalHostname Server ExternalHostname InternalHostname ------ ---------------- ---------------- SERVER server.domain.local server.domain.local

"Rumgebastelt" hab ich schon zu lange , deswegen frag ich ja hier bis zu dem den Punkt "E-Mail-Autokonfiguration testen...." kommt es leider garnicht erst, da er sich die falschen Einstellungen ja bereits beim Neueinrichten des Clients zieht, und diese unter "Exchange Proxyeinstellungen" dann am Client einträgt "https://SERVER.domain.local". danach kommt sofort die Zertifikatswarnung das er "server" im Zertifikat erwartet allerdings "SERVER" im fqdn steht. Interne und externe URLs habe ich nun an diversen stellen in der Verwaltungskonsole in andere werte geändert, er übernimmt diese zwar, allerdings ändert er automatisch sämtliche Werte von Großschreibung in Kleinschreibung. Was vielleicht zur Problemfindung auch noch wichtig sein könnte: Auf unter XP mit Office 2007 funktioniert das ganze wunderbar, dort kommt der Servername in Kleinschreibung beim Client per Autodiscover an. Unter Windows 7 und Office 2010 nicht. Nun dachte ich mir erstell ich einfach als Übergangslösung ein Zertifikat mit "SERVER.domain.local", allerdings ist dies mit der Verwaltungskonsole nicht möglich da er alles durch Kleinschreibung ersetzt.

CU3 ist installiert. die Fehlerhafte einstellung scheint ja schon direkt am Server zu sein da er ja wie gesagt dort den Servernamen im fqdn in Großbuchstaben anzeigt, ebenso auch den iis Metabase Path. gibt es denn keine Möglichkeit den fqdn der dort hinterlegt ist zu ändern ?

bei "Get-ClientaccessServer | ft name,autodiscoverserviceinternaluri kommt die korrekte adresse zurück: https://server.domain.local/Autodiscover/Autodiscover... das ist es also leider nicht. und in RFC2459 steht das es case sensitve ist: (b) attribute values in types other than PrintableString are case sensitive (this permits matching of attribute values as binary objects);

Hallo, ich habe folgendes Problem bei einem Exchange 2013 CU3 auf einem Server 2012. Bei einem Outlook Client wurde das Zertifikat abgelehnt da der eingetragene Name "server.domain.local" nicht mit dem vom Autodiscover zurückgegebenen Namen "SERVER.domain.local" übereinstimmt. Der vergebene Servername selbst ist Kleingeschrieben. Die Managementshell liefert folgendes: Get-ClientAccessServer Name : SERVER Fqdn : SERVER.domain.local Get-WebServicesVirtualDirectory MetabasePath : IIS://SERVER.domain.local/W3SVC/1/ROOT/EWS Server : SERVER InternalUrl : .ttps://server.domain.local/EWS/Exchange.asmx ExternalUrl : .ttps://server.domain.local/EWS/Exchange.asmx Sämtliche änderbare Einträge in der Verwaltungskonsole sind kleingeschrieben, außer in der Serverauswahl bei "virtuelle Verzeichnisse", dort habe ich 2 Exchange zur Auswahl und der Eintrag für den Exchange 2013 Servernamen ist auch dort komplett in Großbuchstaben. Ein nslookup liefert den korrekten Namen "server.domain.local" , im DNS ist ebenfalls alles in kleinbuchstaben. bei unserem alten Exchange 2007 liefert Get-ClientAccessServer die korrekte Ausgabe: Name : SERVER1 Fqdn : server1.domain.local Unter Name scheint wohl generell alles in Großbuchstaben geschrieben zu sein, allerdings stimmt es dann im fqdn wieder. Nach stundenlangem Suchen bin ich mit meinem Latein am Ende und Ich hoffe Ihr könnt mir bei diesem Problem helfen. mfg Phil

wenn ich Ping etc aufrufe bekomme "entweder falsch geschriebenich Befehl nicht gefunden" das mit den systemvariablem ist egal, da ich auch wie gesagt die ping.exe übers Netzwerk in p.exe kopiert hab und wenn ich dort im verzeichnis wo die exe liegt diese ausführe geht es auch nicht, also scheint nicht nur das anzeigen gewisser Netwerkbefehle (ping net netstat etc) sondern auch das ausführen irgendwie blockiert worden zu sein.

wenn du sagst so "sorglos" dann sag mir doch bitte was ich falsch gemacht habe ? sichere passwörter, nur die nötigsten Ports offen, sämtliche patches . mfg philipp

wie er gehackt worden ist wüßte ich auch mal gerne, passwörter sind alle mit groß/kleinbuchstaben zahlen und sonderzeichen >8 stellen. in zukunft soll dort ein linux firewall davor, da ja windows nicht so sicher zu sein scheint.

Hallo, unser Webserver W2k3 (alle patches) wurde gehackt, seitdem sind viele befehle im Command Prompt nicht mehr verfügbar, z.b. Net, Netstat,Ping,Tracert,Ipconfig etc. Die jeweiligen Dateien (ping.exe net.exe etc) sind am server selber nicht mehr auffindbar, auch nicht versteckt (habe mit attrib nachgeschaut) . wenn ich mich allerdings übers Netzwerk in das Verzeichnis (c:\windows\system32) begebe sind die dateien vorhanden. also müssen die so versteckt sein das ich die als lokal angemeldeter Administrator nicht sehen kann. Kopiere ich die jeweiligen dateien unter anderem namen auf den server z.b. ping.exe ->p.exe und versuche diese dann zu starten macht er dies auch nicht. kann mir jemand bei diesem Problem helfen ? mfg philipp

wie gesagt wenn ich die dateien direkt über eine Netzfreigabe Kopiere ist alles OK, auch andere Programme greifen über TCP/IP auf den server zu (Terminalclients, Interbase) Nur wenn ich von unserer Webseite über den iis dateien Downloade dann sind die manchmal fehlerhaft

In dem Server (Terminalserver) sind 4 GB ECC registered drin, Windows zeigt mir allerdings an das nur 3,5 GB Drin sein sollen, ich werd mal den Test durchlaufen lassen.

niemand einen Tip ?

Hallo, von unserem 2k3 Server mit iis6 sind seit einiger zeit immer wieder downloads fehlerhaft. d.h. wenn ein Kunde von unserer Webseite ein Update runterlädt kann es sein das einige Bytes in der Datei fehlerhaft sind, aber die dateigröße ist korrekt. Netzwerkkarten sind OK, denn alles andere funktioniert korrekt, selbst wenn ich die dateien intern über den iis runterlade kommt es manchmal zu diesem fehler(kopiere ich sie über eine Freigabe ist alles OK) Kennt jemand das Problem und kann helfen ? Danke