Nejčastěji odpovídající uživatel
0X8004010F Offline soubory adresáře nejsou stahovány. Server (adresu URL) nelze najít.

Dotaz
-
Zdravím, prosím o radu s následujícím problémem,
konfigurace : interní sít s Exchange 2007 na jednom stroji na windows 2003 a IIS.
V předchozích dnech jsem upravoval nastavení pro používání active sync a přístup přes owa.
Active sync a owa nyní jedou podle představ, ale někde jsem asi něco rozdrbal, protože mi začalo
na všchny outlooky v lokální síti chodit hlášení do podadresáře "nezdařené synchronizace"
13:13:57 Adresář offline aplikace Microsoft Exchange
13:13:57 Offline soubory adresáře nejsou stahovány. Server (adresu URL) nelze najít.
13:13:57 0X8004010F
Toto hlášení chodí kazdých 20 minut.
Samozřejmě sem hledal řešení na internetu ale to co jsem našel se vztahovalo k Ëxchange 2003.
Také jsou tam rady jak upravit Outlook, ale to není ono.
Číslo chyby se také vztahuje k nastavení OAB v IIS. Prohlížel jsem a skoušel upravovat nastavení
ve vlastnostech OAB, také jsem skoušel vytvořit v Exchange nový offline adress book ve kterém jsem
definoval provázanost na OAB. A nasledně v OAB basic autentikaci na vytvářené soubory.
Nic ale nepomáhá, chybové hlášení chodí stále dál.
No vypadá to dost složitě, ale snad mi s tím prosím někdo poradí, děkuji L.středa 10. února 2010 13:26
Odpovědi
-
Zdravím,
problém může být buď v samotné OAB službě nebo ve službě Autodiscover. Také může být problém s nastavením IIS.
Zkusil bych pomocí "Test e-mail autoconfiguration" testu v Outlooku 2007 zjistit, jaké přesně URL mi Autodiscover vrací pro OAB. Autodiscover vrací XML s konfigurací 3 profilů (za předpokladu, že máte nastavený Outlook Anywhere a OWA, jinak jich vrací méně.
Příklad:
<Account> <AccountType>email</AccountType> <Action>settings</Action> <Protocol> <Type>EXCH</Type> <Server>Exchange.firma.local</Server> <ServerDN>/o=FIRMA/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=Exch1</ServerDN> <ServerVersion>720180F0</ServerVersion> <MdbDN>/o=FIRMA/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=Exch1/cn=Microsoft Private MDB</MdbDN> <PublicFolderServer>Exch1.firma.local</PublicFolderServer> <AD>DC1.firma.local</AD> <ASUrl>https://Exch1.firma.local/EWS/Exchange.asmx</ASUrl> <EwsUrl>https://Exch1.firma.local/EWS/Exchange.asmx</EwsUrl> <OOFUrl>https://Exch1.firma.local/EWS/Exchange.asmx</OOFUrl> <UMUrl>https://Exch1.firma.local/UnifiedMessaging/Service.asmx</UMUrl> <OABUrl>http://Exch1.firma.local/OAB/25de3b2a-9c53-43be-8e3f-fd467c60f6a6/</OABUrl> </Protocol> <Protocol> <Type>EXPR</Type> <Server>mail.firma.cz</Server> <SSL>On</SSL> <AuthPackage>Basic</AuthPackage> <ASUrl>https://mail.firma.cz/EWS/Exchange.asmx</ASUrl> <EwsUrl>https://mail.firma.cz/EWS/Exchange.asmx</EwsUrl> <OOFUrl>https://mail.firma.cz/EWS/Exchange.asmx</OOFUrl> <OABUrl>https://mail.firma.cz/OAB/25de3b2a-9c53-43be-8e3f-fd467c60f6a6/</OABUrl> </Protocol>
V sekci EXCH se definuje "interní" profil, čili klasické RPC. V druhém, EXPR, je nastaven profil pro Outlook Anywhere.
Pokud máte problém s interními klienty, zkusil bych:
1. Zkontrolovat, zda Autodiscover vůběc vrací nějaké URL pro interní OAB.
2. Dané URL reprezentuje fyzický adresář (GUID OAB je název toho adresáře) na filesystému. Zkontroloval bych jeho existenci a zda obsahuje soubory a jak jsou staré.
Nejprve pomocí EMS a cmdletu get-offlineaddressbook |fl zjistíte GUID. Pak se na CAS serveru ve Windows Exploreru podívejte do instalačního adresáře Exchange (např. c:\program files\microsoft\exchange server\client access\OAB ), zda tam existuje podadresář s název toho GUIDu a zda obsahuje soubory.
3. Celé URL bych zkusil zadat do IE, jestli mi IIS něco vrátí. Například http://mail.firma.local/OAB/25de3b2a-9c53-43be-8e3f-fd467c60f6a6/oab.xml
4. Pokud mají problém interní klienti, ale externí (RPCoHTTPs) jsou v pořádku, neviděl bych to na problém s NTFS právy, protože oba typy klientů využívají stejný adresář.
5. Pomocí EMS bych zkusil cmdlety Test-OutlookWebServices a Test-WebServicesConnectivity
6. Zkusil bych v IIS Managerovi v Default Website v konfiguraci virt. adresáře OAB ověřit, zda máte vypnuté SSL. Alespoň z vaší reakce z 12.2. vidím, že https nepoužíváte.
Nějakou diskusi jsem našel na MSExchangeTeam.com: http://msexchangeteam.com/archive/2007/04/19/437902.aspx
//David Pazdera MCSE-M MCITP-Ex2007- Označen jako odpověď KFL-MSMicrosoft employee pátek 26. listopadu 2010 8:49
sobota 24. dubna 2010 8:40
Všechny reakce
-
Zkus zkontrolovat Exchange Management Console -> Server Configuration -> Offline Address Book Distribution -> OAB (Default Web Site) -> URLs
JŘ - www.rezab.eupátek 12. února 2010 21:13 -
Děkuji za radu, ale to mám vyplněné -
internal URL:
http://posta.domena.cz/OAB
external URL:
http://mail.domena.cz/OAB
otázka je jestli se ty adresy nemají někam přepsat v IISku, to ale netuším kam přesně. L.pondělí 15. února 2010 12:29 -
Zdravím,
mám stejný problém na SBS 2008. Z lokální sítě to hlásí stejnou chybu, neustále vyskakuje přihlašovací dialog. Ti, kteří přistupují k Exchange pomocí RPC/HTTPS, jsou bez problémů.
Nenašli jste už nějaké řešení? Vyzkoušel jsem snad vše, co jsem na internetu objevil...
Díky
pátek 26. března 2010 20:07 -
Dobrý den, podařilo se Vám vyřešit ten problém se SBS 2008 ?? Mám ten samý problém.pátek 23. dubna 2010 19:37
-
Zdravím,
problém může být buď v samotné OAB službě nebo ve službě Autodiscover. Také může být problém s nastavením IIS.
Zkusil bych pomocí "Test e-mail autoconfiguration" testu v Outlooku 2007 zjistit, jaké přesně URL mi Autodiscover vrací pro OAB. Autodiscover vrací XML s konfigurací 3 profilů (za předpokladu, že máte nastavený Outlook Anywhere a OWA, jinak jich vrací méně.
Příklad:
<Account> <AccountType>email</AccountType> <Action>settings</Action> <Protocol> <Type>EXCH</Type> <Server>Exchange.firma.local</Server> <ServerDN>/o=FIRMA/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=Exch1</ServerDN> <ServerVersion>720180F0</ServerVersion> <MdbDN>/o=FIRMA/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=Exch1/cn=Microsoft Private MDB</MdbDN> <PublicFolderServer>Exch1.firma.local</PublicFolderServer> <AD>DC1.firma.local</AD> <ASUrl>https://Exch1.firma.local/EWS/Exchange.asmx</ASUrl> <EwsUrl>https://Exch1.firma.local/EWS/Exchange.asmx</EwsUrl> <OOFUrl>https://Exch1.firma.local/EWS/Exchange.asmx</OOFUrl> <UMUrl>https://Exch1.firma.local/UnifiedMessaging/Service.asmx</UMUrl> <OABUrl>http://Exch1.firma.local/OAB/25de3b2a-9c53-43be-8e3f-fd467c60f6a6/</OABUrl> </Protocol> <Protocol> <Type>EXPR</Type> <Server>mail.firma.cz</Server> <SSL>On</SSL> <AuthPackage>Basic</AuthPackage> <ASUrl>https://mail.firma.cz/EWS/Exchange.asmx</ASUrl> <EwsUrl>https://mail.firma.cz/EWS/Exchange.asmx</EwsUrl> <OOFUrl>https://mail.firma.cz/EWS/Exchange.asmx</OOFUrl> <OABUrl>https://mail.firma.cz/OAB/25de3b2a-9c53-43be-8e3f-fd467c60f6a6/</OABUrl> </Protocol>
V sekci EXCH se definuje "interní" profil, čili klasické RPC. V druhém, EXPR, je nastaven profil pro Outlook Anywhere.
Pokud máte problém s interními klienty, zkusil bych:
1. Zkontrolovat, zda Autodiscover vůběc vrací nějaké URL pro interní OAB.
2. Dané URL reprezentuje fyzický adresář (GUID OAB je název toho adresáře) na filesystému. Zkontroloval bych jeho existenci a zda obsahuje soubory a jak jsou staré.
Nejprve pomocí EMS a cmdletu get-offlineaddressbook |fl zjistíte GUID. Pak se na CAS serveru ve Windows Exploreru podívejte do instalačního adresáře Exchange (např. c:\program files\microsoft\exchange server\client access\OAB ), zda tam existuje podadresář s název toho GUIDu a zda obsahuje soubory.
3. Celé URL bych zkusil zadat do IE, jestli mi IIS něco vrátí. Například http://mail.firma.local/OAB/25de3b2a-9c53-43be-8e3f-fd467c60f6a6/oab.xml
4. Pokud mají problém interní klienti, ale externí (RPCoHTTPs) jsou v pořádku, neviděl bych to na problém s NTFS právy, protože oba typy klientů využívají stejný adresář.
5. Pomocí EMS bych zkusil cmdlety Test-OutlookWebServices a Test-WebServicesConnectivity
6. Zkusil bych v IIS Managerovi v Default Website v konfiguraci virt. adresáře OAB ověřit, zda máte vypnuté SSL. Alespoň z vaší reakce z 12.2. vidím, že https nepoužíváte.
Nějakou diskusi jsem našel na MSExchangeTeam.com: http://msexchangeteam.com/archive/2007/04/19/437902.aspx
//David Pazdera MCSE-M MCITP-Ex2007- Označen jako odpověď KFL-MSMicrosoft employee pátek 26. listopadu 2010 8:49
sobota 24. dubna 2010 8:40 -
Dobrý den,
s největší pravděpodobností Vám na Exchange server neběží služba "Microsoft Exchange system Attendant".
středa 23. května 2012 11:53