SBS 2011 + Outlook 2010 Out of Office

[tel2]

Goedemiddag,

Wij hebben een probleem met het instellen van de afwezigheidsmelding in Outlook 2010. We krijgen de volgende fout: Your Out of Office settings cannot be displayed, because the server is currently unavailable. Try again Later.

Aangezien het in Outlook 2003 en OWA wel werkt vermoed ik dat het aan de autodiscover instellingen ligt.

Een autodiscover test op https://www.testexchangeconnectivity.com is succesvol.

Alle gebruikers hebben dit probleem, de pc's zijn in het domein aangemeld en intern met de server verbonden.

Bij mijn zoektocht op internet kwam ik tegen dat de volgende URL bereikbaar moet zijn: https://webmail.domein.nl/EWS/Exchange.asmx. Dit werkt bij ons niet, mogelijk zit hier het probleem?

Als ik in de Exchange Powershell het commando: Get-WebServicesVirtualDirectory invoer krijg ik onderstaande output.

Name Server InternalUrl
---- ------ -----------
EWS (Default Web Site) ONZESERVER https://webmail.domein.nl/EWS/Exchange.amsx

Moet ik hier nog een Internal en External URL toevoegen? Heeft dit nog verdere gevolgen voor andere services?

Ik hoop dat iemand me kan helpen.

[Killah_Priest]

Waar resolved bij jou (intern) webmail.domein.nl naar?
Als deze naar jouw externe IP verwijst dan zou je op je DNS server een A record aan kunnen maken welke naar het interne serveradres verwijst.

[tel2]

Killah_Priest schreef op donderdag 20 december 2012 @ 14:53:
Waar resolved bij jou (intern) webmail.domein.nl naar?
Als deze naar jouw externe IP verwijst dan zou je op je DNS server een A record aan kunnen maken welke naar het interne serveradres verwijst.

Deze resolved al naar het interne IP van de SBS server. Er staat ook al een A record naar het interne IP van de server. (automatisch, door wizard aangemaakt).

[Turdie]

Toevallig de update geinstalleerd voor het Windows Management Framework 3.0 (KB2506146 and KB2506143)? Die update kan behoorlijk wat problemen veroorzaken met Exchange 2007 en Exchange 2010.

[ Voor 9% gewijzigd door Turdie op 20-12-2012 17:22 ]

[marc181982]

Moet ik hier nog een Internal en External URL toevoegen? Heeft dit nog verdere gevolgen voor andere services?

Als je de wizard "internet address management" gebruikt zal deze automatisch de juiste internal/external url invullen, deze moet overeen komen met je publieke dns record. Zodra je de wizard hebt gedraaid, is het alleen een kwestie om een record aan te maken in je publieke dns. Dit kan zijn een a-record of een srv-record. Alleen een srv-record gebruiken mits het juiste servicepack is geinstalleerd voor office 2007.

De wizard zal daarnaast of het self-signed certificate correct configureren.

Gebruik je een self-signed certificate of een 3rd party certificate?

Daarnaast outlook 2003 maakt nog geen gebruik van de autodiscover functie, dit is word pas ondersteund in outlook 2007/2010

[ Voor 3% gewijzigd door marc181982 op 20-12-2012 20:24 ]

[asterixonline]

Gebruik je misschien een proxy? Ik heb dit ook gehad door gebruik van een proxy.
Anders even auto discovery testen via outlook ik geloof ctrl of shift inhouden rechts klik op kleine outlook pictogram in tray en dan test autodiscovery

[tel2]

shadowman12 schreef op donderdag 20 december 2012 @ 17:17:
Toevallig de update geinstalleerd voor het Windows Management Framework 3.0 (KB2506146 and KB2506143)? Die update kan behoorlijk wat problemen veroorzaken met Exchange 2007 en Exchange 2010.

Deze updates zijn niet geïnstalleerd.

Moet ik hier nog een Internal en External URL toevoegen? Heeft dit nog verdere gevolgen voor andere services?

Als je de wizard "internet address management" gebruikt zal deze automatisch de juiste internal/external url invullen, deze moet overeen komen met je publieke dns record. Zodra je de wizard hebt gedraaid, is het alleen een kwestie om een record aan te maken in je publieke dns. Dit kan zijn een a-record of een srv-record. Alleen een srv-record gebruiken mits het juiste servicepack is geinstalleerd voor office 2007.

De wizard zal daarnaast of het self-signed certificate correct configureren.

Gebruik je een self-signed certificate of een 3rd party certificate?

Daarnaast outlook 2003 maakt nog geen gebruik van de autodiscover functie, dit is word pas ondersteund in outlook 2007/2010

De "internet address management" wizard heb ik al gedraaid, ook heb ik een srv-record aangemaakt in mijn publieke dns en is er een cerificaat van een certificaat provider geïnstalleerd.

Aangezien https://webmail.domein.nl/EWS/Exchange.asmx niet te bereiken is vermoed ik dat het hier fout gaat. Als ik naar dit adres op de server browse krijg ik de volgende fout:

Configuratiefout
Beschrijving: Er is een fout opgetreden tijdens het verwerken van een configuratiebestand dat vereist is om aan deze aanvraag te voldoen. Raadpleeg de hieronder weergegeven details van deze fout en pas uw configuratiebestand overeenkomstig aan.

Parser-foutbericht: De waarde van de eigenschap maxRequestLength is ongeldig. De fout is: De waarde moet binnen het bereik 0-2097151 liggen.

Fout in bron:


Regel 2284:
Regel 2285: <system.web>
Regel 2286: <httpRuntime maxRequestLength="26214400" />
Regel 2287: <httpHandlers>
Regel 2288: <remove path="*.asmx" verb="*"></remove>

Misschien dat iemand hier iets mee kan? Kan ik deze waarde zomaar aanpassen?

@asterixonline er wordt geen gebruik gemaakt van een proxy.

[marc181982]

Draai eens een keer de best practice analyzer, en post de uitkomst

Je waarde voor de requestlenght is te hoog, deze moet liggen tussen de 0-2097151. In het eventlog staat dat deze momenteel 26214400. De waarde even aanpassen zou het moeten verhelpen.

[ Voor 106% gewijzigd door marc181982 op 23-12-2012 00:21 ]

[tel2]

marc181982 schreef op zondag 23 december 2012 @ 00:12:
Draai eens een keer de best practice analyzer, en post de uitkomst

Je waarde voor de requestlenght is te hoog, deze moet liggen tussen de 0-2097151. In het eventlog staat dat deze momenteel 26214400. De waarde even aanpassen zou het moeten verhelpen.

Bedankt (sorry beetje laat, maar zaten wat feestdagen tussen), het aanpassen van de requestlenght heeft het probleem inderdaad opgelost. Dit probleem kwam trouwens niet naar voren bij een scan met de best practice analyzer.

Ik heb de stappen op onderstaande website gevolgd.

http://www.aidinit.com/tag/maxrequestlength/