RPC over HTTP(S) werkt pas nadat eenmalig lokaal verbinden

[Verwijderd]

Het probleem met onze RPC over HTTPS opstelling is niet zo zeer dat het totaal niet werkt. Ik lees hier diverse mensen die hetzelfde probleem lijken te hebben, maar mogelijk niet zo snel de richting van de oorzaak hebben gevonden.

Situatie.

RPC over HTTP(S) is ingesteld volgens de bekende manier, gesitueerd bij Petri.

Tevens hebben wij een eigen SSL certificaat uitgegeven. Welke beiden zijn geinstalleerd.
Ook dit lijkt niet het probleem te zijn.

Per toeval kwamen wij erachter dat, het wel of niet werken van de RPC functie, komt doordat wij bij het testen, gebruik hadden gemaakt van een kabel welke vast zat in het bedrijfs netwerk.
Toen wij de tweede maal weer wilden testen, werkte het niet.
Ik heb toen de netwerk kabel van het bedrijfs netwerk er weer in gedaan, en direct werd de server en postvak gevonden.

Aangezien RPC bedoelt is om van buitenaf te worden benaderd is dit niet de gewenste oplossing.
Ik heb toen de netwerk kabel van het bedrijfs netwerk weer vervangen voor een die verbonden was met een extern/ander netwerk, en nog steeds bleek rpc te werken.

RPC werkt dus alleen als de laptop in kwestie eerst verbonden is geweest met het bedrijfs netwerk via VPN of direct via een netwerk kabel.

Mijn vraag nu, hoe los ik dit op?

[Question Mark]

Misschien handig als je verteld wat er precies niet werkt, en welke foutmelding je krijgt.

Check ook eens eea met rpcping:

How to use the RPC Ping utility to troubleshoot connectivity issues with the Exchange over the Internet feature in Outlook 2007 and in Outlook 2003

[Verwijderd]

Zoals ik al zei, het probleem zit hem in het verbinden met de server, nadat RPC is ingesteld op de client, indien er dus via een extern netwerk verbinding wordt gemaakt.
Als ik verbonden ben via het lokale netwerk, worden de postvak en server geresolved.

Vanaf dat moment kan ik ook weer een extern netwerk gebruiken om via RPC overal de mail binnen te halen.

In andere woorden, na het instellen van RPC op de client, dient er eenmalig, lokaal, verbinding worden te gemaakt met de server, zodat outlook de (interne netbios) naam en postvak kan vinden.
Als dit eenmaal is gedaan is het dus geen probleem meer om via externe netwerken/internet verbinding te maken en via RPC de mail binnen te halen.


Een foutmelding is in zo'n geval niet aanwezig. Er wordt simpel weg telkens opnieuw de inlog gegevens gevraagd, gepaard met de melding dat er geen verbinding kan worden gemaakt.

[ Voor 11% gewijzigd door Verwijderd op 03-12-2008 10:11 ]

[pennenlikker]

Ik gebruik altijd rpcdiag voor het troubleshooten van deze verbindingen.

Edit: er word in het begin ook gesproken over het verschil tussen wan en lan connectie met rpc.

[ Voor 25% gewijzigd door pennenlikker op 03-12-2008 10:05 ]

[Verwijderd]

Volgens mij lukt dit alleen in 2003 met een ISA server er voor. In Exchange 2007 kun je wel op afstand een profiel maken, maar ook dan gaat het niet helemaal lekker.

[Verwijderd]

pennenlikker schreef op woensdag 03 december 2008 @ 09:55:
Ik gebruik altijd rpcdiag voor het troubleshooten van deze verbindingen.

Edit: er word in het begin ook gesproken over het verschil tussen wan en lan connectie met rpc.

http://www.petri.co.il/testing_rpc_over_http_connection.htm

Zorgt er alleen maar voor dat ik kan zien dat er verbinding is.
Geweldig, deze is er, maar alleen zolang ik eerst lokaal verbonden ben geweest.

Nu nog een oplossing.
Het lijkt er in mijn ogen op dat er geen goede verbinding wordt gemaakt met het externe FQDN, welke ingesteld staat bij de outlook over http optie.

Tevens ligt dit niet aan de FQDN of de porten, webmail werkt via dezelfde FQDN maar dan met /exchange erachter, en werkt perfect.

[Question Mark]

Je moet wel even testen met een machine die nog niet lokaal verbonden is, testen met een al werkende machine heeft weinig zin.

Test ook even met RPCping, die geeft wat meer feedback over wat er precies fout gaat.

[pennenlikker]

Verwijderd schreef op woensdag 03 december 2008 @ 10:53:
[...]


http://www.petri.co.il/testing_rpc_over_http_connection.htm

Zorgt er alleen maar voor dat ik kan zien dat er verbinding is.
Geweldig, deze is er, maar alleen zolang ik eerst lokaal verbonden ben geweest.

Nu nog een oplossing.
Het lijkt er in mijn ogen op dat er geen goede verbinding wordt gemaakt met het externe FQDN, welke ingesteld staat bij de outlook over http optie.

Tevens ligt dit niet aan de FQDN of de porten, webmail werkt via dezelfde FQDN maar dan met /exchange erachter, en werkt perfect.

Post eerst is de uitkomsten van rpcdiag en rpcping (daarvoor hebben ze deze tools gemaakt, om te troubleshooten) met een machine die nog niet lokaal verbonden is geweest... misschien kunnen we je dan helpen, zo heeft het ook weinig zin he

[ Voor 3% gewijzigd door pennenlikker op 03-12-2008 11:03 ]

[Verwijderd]

pennenlikker schreef op woensdag 03 december 2008 @ 11:01:
[...]


Post eerst is de uitkomsten van rpcdiag en rpcping (daarvoor hebben ze deze tools gemaakt, om te troubleshooten) met een machine die nog niet lokaal verbonden is geweest... misschien kunnen we je dan helpen, zo heeft het ook weinig zin he

RPCping geeft een direct response van 1ms.
Maar dat is ook niet raar, aangezien je de resource kit op de server zelf installeerd.
Ik denk dat je meer opzoekt bent naar een specifiek rpcping /commando?

RPCDiag toont bij het aansluiten van een lokale verbinding aan dat er verbinding is gemaakt.
Behoudt ik het venster open, en verwissel de kabel met het externe netwerk, kan er nog steeds verbinding worden gemaakt. Er wordt dan weliswaar over gegaan op HTTPS (perfect!).

Sluit ik nu outlook, en voer ik rpcdiag opnieuw uit, krijg ik telkens opnieuw de melding of ik wil proberen verbinding te maken, offline wil werken of annuleren.
Op de achtergrond werkt rpcdiag nog wel, maar toont raar genoeg alleen de openbare mappen die via HTTPS verbonden is.
Overige punten lijken niet te kunnen verbinden.


Om het nog iets uit te breiden:

In een leslokaal (welke verbonden is met een ander netwerk dan het lokale, oftewel naar buiten gaat via een andere provider) heb ik 2 pc's klaar gezet.

Op pc1:
Outlook 2003 zo ingesteld met als microsoft exchange server: lokale netbios server naam.
Postvak: account naam
Proxy instellingen van exchange: externe FQDN naam.
Vinkjes uit.

Melding 1, bij openen van outlook.

Melding 2, na vervolg van melding 1, hierna sluit outlook direct

Het draaien van de outlook.exe /rpcdiag vertoont geen mogelijkheid tot verbinding.

Op Pc2:
Outlook 2003 zo ingesteld met als microsoft exchange server: lokale netbios server naam.
Postvak: account naam
Proxy instellingen van exchange: externe FQDN naam.
Vinkjes uit.

Tevens op deze pc een VPN verbinding gemaakt naar het interne netwerk.
Outlook geopent, en direct verbinding.

Outlook.exe /rpcdiag toont aan dat er niet via de HTTPS verbinding wordt gemaakt maar via TCP/IP.
Dit lijkt dus ook te varieren.

En niet te vergeten, de eigen certificaten zijn niet vergeten geweest om te installeren. Dit kan dus niet de reden zijn dat er niet voor HTTPS gekozen wordt.

[ Voor 36% gewijzigd door Verwijderd op 03-12-2008 12:29 ]

[pennenlikker]

En je hebt Outlook echt zo geconfigureerd?
Heb nu al drie van deze verbindingen opgezet voor klanten, maar jou probleem nog nooit tegen gekomen, dus je moet ergens iets vergeten aan te vinken zijn oid. op de server of op de client.

Bekijk anders nog een de petri guide en controleer alle stappen die je gevolgd heb en of je deze wel precies hebt opgevolgd.
Want als je die handleiding volgt moet het gegarandeerd werken

[Question Mark]

Verwijderd schreef op woensdag 03 december 2008 @ 11:29:
[...]RPCping geeft een direct response van 1ms.
Maar dat is ook niet raar, aangezien je de resource kit op de server zelf installeerd.
Ik denk dat je meer opzoekt bent naar een specifiek rpcping /commando?

Het is wel de bedoeling om rpcping vanaf een client te draaien. De resourcekit kan nl. gewoon op een client geinstalleerd worden (misschien volstaat het kopieren van de executable ook wel).

[Qwerty-273]

Question Mark schreef op woensdag 03 december 2008 @ 10:58:
Test ook even met RPCping.

Eventueel kan je zelfs https://www.testexchangeconnectivity.com/ gebruiken om het een en ander uit te testen, hoef je niet elke keer een remote verbinding op te zetten

[Verwijderd]

pennenlikker schreef op woensdag 03 december 2008 @ 12:31:
En je hebt Outlook echt zo geconfigureerd?
Heb nu al drie van deze verbindingen opgezet voor klanten, maar jou probleem nog nooit tegen gekomen, dus je moet ergens iets vergeten aan te vinken zijn oid. op de server of op de client.

Bekijk anders nog een de petri guide en controleer alle stappen die je gevolgd heb en of je deze wel precies hebt opgevolgd.
Want als je die handleiding volgt moet het gegarandeerd werken

Exact zoals op Petri staat. Maar ik zal jouw site ook nog eens doorlopen.
Ik heb zelfs, de registry handmatig doorgelopen om te zien of de porten wel goed via het programma zijn geconfigureerd. Dit bleek zo te zijn.
Opzich is het probleem specifiek, het doet zich pas voor op het WAN.

Qwerty-273 schreef op woensdag 03 december 2008 @ 12:52:
[...]

Eventueel kan je zelfs https://www.testexchangeconnectivity.com/ gebruiken om het een en ander uit te testen, hoef je niet elke keer een remote verbinding op te zetten

Werkt niet helemaal.
Ik vink het "ignore trust for SSL" aan, aangezien wij zelf het certificaat maken.

Alles is ok op het volgende na:
Testing NSPI "Check Name" for user [e-mail] against server REMOVED
An error occured while attempting to resolve the name
Additional Details
An RPC Error was thrown by the RPC Runtime. Error 0 Ok

[ Voor 53% gewijzigd door Verwijderd op 03-12-2008 13:07 ]

[pennenlikker]

Heb je wel je CA toegevoegd aan de trusted CA's?

Ennuuhh:

The last thing to verify is that you can connect to the RPC Proxy via an SSL connection. Depending on which service pack level the base OS is on, you can test the connection by opening up Internet Explorer and pointing the browser to:

Windows Server 2003 RTM and SP1 – https://fully.qualified.domain.name/RPC
Windows Server 2003 SP1 – https://fully.qualified.domain.name/RPC/rpcproxy.dll

[ Voor 85% gewijzigd door pennenlikker op 03-12-2008 13:51 ]

[Verwijderd]

pennenlikker schreef op woensdag 03 december 2008 @ 13:50:
Heb je wel je CA toegevoegd aan de trusted CA's?

Verwijderd schreef op woensdag 03 december 2008 @ 11:29:
[...]
En niet te vergeten, de eigen certificaten zijn niet vergeten geweest om te installeren. Dit kan dus niet de reden zijn dat er niet voor HTTPS gekozen wordt.

Ennuuhh:

The last thing to verify is that you can connect to the RPC Proxy via an SSL connection. Depending on which service pack level the base OS is on, you can test the connection by opening up Internet Explorer and pointing the browser to:

Windows Server 2003 RTM and SP1 – https://fully.qualified.domain.name/RPC
Windows Server 2003 SP1 – https://fully.qualified.domain.name/RPC/rpcproxy.dll

Beide urls zijn te benaderen. Ik weet alleen niet wat jij verwacht te zien?
Bij URL 1 krijg ik een 401.3 error waarin vermeld staat dat ik niet in de ACL list staat. Volgens petri is dit normaal. Error message 401.3 when setting up RPC over HTTP/S on Exchange 2003, after installing SP1 for Windows Server 2003

Bij url 2, krijg ik een blance pagina.

[Verwijderd]

Even een eigen ingeving wat het mogelijk kan zijn:

Onze FQDN/exchange werkt (mail.external.nl/exchange). Welke tevens via HTTPS/SSL verbinding maakt.
Wat dus inhoudt dat FQDN, welke gebruikt wordt voor RPC, ook werkt.

Als ik kijk naar de IIS instellingen op de server, (dit is een back-end server, er wordt geen gebruik gemaakt van een front end server welke de aanvraag van buiten, binnen in door verbind naar een andere server) dan is er een SSL certificaat ingesteld op de default webpage. De bovenste laag van IIS, laat maar zeggen.
Dit certificaat staat ingesteld voor de externe FQDN naam.

Het verbinden met RPC gebeurt via de proxy server/rpc server, oftewel hier voer je de externe FQDN naam in.
Het probleem zit hem in het verkrijgen van de interne netbios naam, welke weer ingesteld staat bij de exchange server.

Misschien dat iemand kan bedenken of ik in de juiste richting zit?
Edit: schijnbaar niet.
Ik heb de certificaten op de server uitgezet, maar de situatie blijft hetzelfde. Alleen lokaal is er verbinding.


Tevens rpcping werkt perfect vanaf een externe pc:


C:\Program Files\Windows Resource Kits\Tools>rpcping -t ncacn_http -s INTERNALFQDN -o RpcProxy=EXT.FQDN -P "user,domain,*" -I "user,domain,*" -H 2
-u 10 -a connect -F 3 -v 3 -E -R none
RPCPing v2.12. Copyright (C) Microsoft Corporation, 2002
OS Version is: 5.1, Service Pack 3
Enter password for server:
Enter password for RPC/HTTP proxy:

RPCPinging proxy server EXT.FQDN with Echo Request Packet
Sending ping to server
Response from server received: 200
Pinging successfully completed in 1422 ms

C:\Program Files\Windows Resource Kits\Tools>

[ Voor 38% gewijzigd door Verwijderd op 03-12-2008 16:06 ]

[Verwijderd]

Nog steeds geen stap verder.
Ik ben nu maar simpelweg alle websites na gaan lopen m.b.t. rpc die ik tegenkom en ik kan gewoon geen duidelijke fouten ontdekken.
Niet in de registry, niet in de instellingen...

Wat ik nog wel steeds raar vind wat ik eerder plaatste, het probleem

Testing NSPI Interface on Exchange Mailbox Server
An error occured while testing the NSPI Interface.

Ik heb volgens How to troubleshoot connectivity issues that are caused by RPC client protocol registry entries , de rpcdump.exe gecheckt.
Intern geeft dit geen problemen. Hoewel je een gigantisch waslijst krijgt kun je zo te belangrijke punten eruit filteren: The Name Service Provider Interface (NSPI) with the UUID of f5cc5a18-4264-101a-8c59-08002b2f8426.

Even zoeken op de UUID, en ik kreeg.
192.0.0.1 [49106] [f5cc5a18-4264-101a-8c59-08002b2f8426] MS Exchange Directory NSPI Proxy :YES

Wat dus inhoudt dat intern geen probleem is. Extern is het rpcdump commando blijkbaar niet te gebruiken, er komt 0,0 reactie terug.
(rpcdump.exe /s EXT.FQDN
0 regitered endpoints found
completed successfully)

[ Voor 3% gewijzigd door Verwijderd op 04-12-2008 13:10 ]

[Rudie_V]

Ik heb zelf ook met RPC/HTTPS van zowel Exchange 2003 als Exchange 2007(outlook anywhere) gewerkt welke beide geen problemen gaven. Wat ik wel had is dat als ik op een pc van buitenaf een nieuw outlook profiel aan wou maken door gelijk gebruik te maken van RPC/HTTPS dan werkte dit niet. Ik moest eerst lokaal op het netwerk een outlook profiel aanmaken en éénmalig over het lokale netwerk gebruik maken van het profiel. Daarna werkte RPC/HTTPS ook van buiten af, zonder problemen.
Mocht er problemen zijn met je certificaat krijg je meestal een foutmelding die ook over het certificaat zeurt, dit heb ik ook wel eens meegemaakt. Heel simpel gezegt als je gebruik maak van eigen certificaten en het certificaat is bij gebruik van webmail volledige vertrouwd door je browser dan zit dat voor RPC/HTTPS ook goed. Geeft je browser bij webmail aan dat je certificaat niet vertrouwd is dan zal je dit op moeten lossen, zorg dat je CA Root certificaat in je computer account in de trusted root certification authorities staat. Dit kan gewoon een .cer zijn zonder private key.

Het profiel wat je probeert aan te maken(zie plaatjes tinypics met foutmeldingen) is dat van buitenaf of lokaal op het netwerk?

[Verwijderd]

Rudie_V schreef op donderdag 04 december 2008 @ 14:00:
Ik heb zelf ook met RPC/HTTPS van zowel Exchange 2003 als Exchange 2007(outlook anywhere) gewerkt welke beide geen problemen gaven. Wat ik wel had is dat als ik op een pc van buitenaf een nieuw outlook profiel aan wou maken door gelijk gebruik te maken van RPC/HTTPS dan werkte dit niet. Ik moest eerst lokaal op het netwerk een outlook profiel aanmaken en éénmalig over het lokale netwerk gebruik maken van het profiel. Daarna werkte RPC/HTTPS ook van buiten af, zonder problemen.
Mocht er problemen zijn met je certificaat krijg je meestal een foutmelding die ook over het certificaat zeurt, dit heb ik ook wel eens meegemaakt. Heel simpel gezegt als je gebruik maak van eigen certificaten en het certificaat is bij gebruik van webmail volledige vertrouwd door je browser dan zit dat voor RPC/HTTPS ook goed. Geeft je browser bij webmail aan dat je certificaat niet vertrouwd is dan zal je dit op moeten lossen, zorg dat je CA Root certificaat in je computer account in de trusted root certification authorities staat. Dit kan gewoon een .cer zijn zonder private key.

Het profiel wat je probeert aan te maken(zie plaatjes tinypics met foutmeldingen) is dat van buitenaf of lokaal op het netwerk?

Ik kan dit allemaal verifïëren.
CA's zijn geinstalleerd, bevestigd in de browser.

Het profiel is getest zowel intern (vpn) als extern.
Intern werkt het dus wel, laat ik outlook open en verwissel te kabel(extern netwerk), blijft het werken, volgens rpcdiag gaan we dan ook ineens van tcp/ip naar het HTTPS protocol over.
Sluit ik outlook (met in het achterhoofd dat er dus nu een extern netwerk achter zit) en open deze dan weer, komt er niets meer.
Ook dit is trouwens vreemd, want ik heb hier eerder een laptop gehad die inderdaad eerst een profiel nodig had wat intern is opgehaald, waarna er op elk gewenst van de dag, extern gewerkt kon worden via RPC.
Helaas heb ik deze nu niet tot mijn beschikking om te checken of dit nog steeds zo is bij deze laptop, of dat ik dat nu om zeep heb geholpen.
Hoewel ik er wel bij blijf dat de settings goed staan!

[ Voor 4% gewijzigd door Verwijderd op 04-12-2008 14:24 ]

[Rudie_V]

Wat ik nog eens kan zeggen is check de registry settings nog eens. http://www.petri.co.il/co...ps_on_a_single_server.htm onder het kopje Configure the RPC proxy server to use specific ports . Wees zeker dat je zowel de netbios namen, en de interne als externe! FQDN's in je registry heb staan. Vooral de externe FQDN is voor gebruik over het internet natuurlijk belangrijk.
Wat is de uitkomst van het commando: rpccfg /hd En klopt dit met wat het moet zijn? Ook hier weer de externe FQDN belangrijk. Klopt deze FQDN ook met het externe IP adres?

De outlook settings als in http://www.petri.co.il/co..._to_use_rpc_over_http.htm . Zoals het bij mij werkt is inderdaad bij punt 7 de interne netbios naam, daarna mailbox controleren(server naam veranderd dan naar de interne FQDN naam). Punt 10 als http://www.petri.co.il/images/test_rpc_over_http_8_.gif met de externe FQDN naam, en andere settings als in het plaatjes. Controleer binnen IIS of je basic authentication wel aan heb staan. Zie http://www.petri.co.il/images/rpc_over_http_rpc_proxy3.gif op je RPC proxy virtual directory en maak zeker dat je het op de juiste RPC proxy VD zet!

De internet verbinding die je gebruikt, staat deze wel volledig los van je interne netwerk. Heb je misschien de mogelijkheid om via modem, ISDN of losse ADSL verbinding te testen?

[Verwijderd]

Rudie_V schreef op donderdag 04 december 2008 @ 14:53:
Wat ik nog eens kan zeggen is check de registry settings nog eens. http://www.petri.co.il/co...ps_on_a_single_server.htm onder het kopje Configure the RPC proxy server to use specific ports . Wees zeker dat je zowel de netbios namen, en de interne als externe! FQDN's in je registry heb staan. Vooral de externe FQDN is voor gebruik over het internet natuurlijk belangrijk.
Wat is de uitkomst van het commando: rpccfg /hd En klopt dit met wat het moet zijn? Ook hier weer de externe FQDN belangrijk. Klopt deze FQDN ook met het externe IP adres?

De outlook settings als in http://www.petri.co.il/co..._to_use_rpc_over_http.htm . Zoals het bij mij werkt is inderdaad bij punt 7 de interne netbios naam, daarna mailbox controleren(server naam veranderd dan naar de interne FQDN naam). Punt 10 als http://www.petri.co.il/images/test_rpc_over_http_8_.gif met de externe FQDN naam, en andere settings als in het plaatjes. Controleer binnen IIS of je basic authentication wel aan heb staan. Zie http://www.petri.co.il/images/rpc_over_http_rpc_proxy3.gif op je RPC proxy virtual directory en maak zeker dat je het op de juiste RPC proxy VD zet!

De internet verbinding die je gebruikt, staat deze wel volledig los van je interne netwerk. Heb je misschien de mogelijkheid om via modem, ISDN of losse ADSL verbinding te testen?

C:\Program Files\Windows Resource Kits\Tools>rpccfg /hd
Server Name Port Settings
--------------------------------------------------------
mail.domain.nl 6001-6002 6004
server 6001-6002 6004
server.domain 6001-6002 6004

Klopt allemaal.

Er zijn 2 internet verbindingen aanwezig. Zoals al eerder aangegeven switch ik constant tussen deze 2 verbindingen (intern/extern), zie de eerdere posts voor mijn bevindingen.

Heb zojuist ook het programma Port Query gebruikt van Microsoft.
Extern wordt aangegeven dat port 443 en 80 naar de server open staan...

[Rudie_V]

Ok, nog eventjes, intern werkt het. Wat als extern over het internet outlook opstart, welke melding krijg je dan? (evt ff screenshot via tinypic) Krijg je al wel een inlogscherm bij het starten van outlook, want deze hoor je normaal te krijgen in een rpc/https situatie, je wordt dan via basic authentication over een SSL verbinding geauthenticeerd.

In dit scherm http://www.petri.co.il/images/rpc_over_http_rpc_proxy3.gif , haal bij default domain het domein eens weg, je kan het daarna leeglaten.

Dan hebben we nog die NSPI error die je kreeg bij www.testexchangeconnectivity.com , die [e-mail] gebruiker, bestaat deze ook echt in je AD of is hier het externe domein gebruikt (*.nl) terwijl je intern een ander domein gebruikt?

Indien niet gebruikt naar je Exchange server kan je die poort 80 wel dichtzetten.

[Verwijderd]

Rudie_V schreef op donderdag 04 december 2008 @ 15:58:
Ok, nog eventjes, intern werkt het. Wat als extern over het internet outlook opstart, welke melding krijg je dan? (evt ff screenshot via tinypic) Krijg je al wel een inlogscherm bij het starten van outlook, want deze hoor je normaal te krijgen in een rpc/https situatie, je wordt dan via basic authentication over een SSL verbinding geauthenticeerd.

In dit scherm http://www.petri.co.il/images/rpc_over_http_rpc_proxy3.gif , haal bij default domain het domein eens weg, je kan het daarna leeglaten.

Dan hebben we nog die NSPI error die je kreeg bij www.testexchangeconnectivity.com , die [e-mail] gebruiker, bestaat deze ook echt in je AD of is hier het externe domein gebruikt (*.nl) terwijl je intern een ander domein gebruikt?

Indien niet gebruikt naar je Exchange server kan je die poort 80 wel dichtzetten.

Als ik via een extern netwerk outlook start, krijg ik de vraag gebruikersnaam/wachtwoord.
Hier voer ik (wat tevens al ingevuld stond doordat ik intern ingelogd ben geweest) domain\user en mijn wachtwoord.

Ik krijg dan na enkele seconden (niet direct) de melding terug:
De server van microsoft exchange is niet beschikbaar.
Opnieuw, Offline werken, annuleren.


Die gebruiker waarmee ik test werkt.. te verifieren door even via OWA (extern) in te loggen (komt uit op dezelfde server..)


Even nog als aanvulling, als ik via het lokale netwerk outlook.exe /rpcdiag uitvoer (en daarna de kabel verwissel naar extern) zie ik dat de types e-mail (3x) en openbare mappen (1x) verbonden zijn, maar de adressenlijst kan niet worden opgehaald.

[ Voor 8% gewijzigd door Verwijderd op 04-12-2008 16:37 ]

[Rudie_V]

Log anders in het interne inlognaam, als je interne domein domain.local heet, log dan in met [e-mail] en het wachtwoord. Maar dit werkt denk ik dan ook niet hoor...
Kijk anders in de eventviewer op je exchange server welke security melding je krijg. Ook binnen exchange kan je je logging richting je DC verhogen, pas deze eens aan.
Alles lijkt wel goed te staan gezien je al wel netjes het inlogscherm krijg, dus de verbinding naar de server lijkt goed te zijn, alleen het laatste stukje authenticatie nog niet. Kijk anders daarna even met ethereal of network monitor wat er precies over de lijn gaat tijdens je authenticatie. Gezien de basic authenticatie moet je hier wat voorbij zien gaan.
Ik heb wel zoiets meegemaakt toen ik eens aant kloten was om ipv basic authentication NTLM authenticatie te gebruiken. Netjes inlogscherm, maar niet kunnen inloggen. Ik kan ze ff niet zo voor me halen hoe ze precies heten, maar binnen IIS het je twee RPC virtual directories, 1 normale en 1 secure. De instelling in je outlook profiel als de authenticatiemethode van de non-secure RPC VD moet basic zijn.

[Verwijderd]

Rudie_V schreef op donderdag 04 december 2008 @ 16:28:
Log anders in het interne inlognaam, als je interne domein domain.local heet, log dan in met [e-mail] en het wachtwoord. Maar dit werkt denk ik dan ook niet hoor...
Kijk anders in de eventviewer op je exchange server welke security melding je krijg. Ook binnen exchange kan je je logging richting je DC verhogen, pas deze eens aan.
Alles lijkt wel goed te staan gezien je al wel netjes het inlogscherm krijg, dus de verbinding naar de server lijkt goed te zijn, alleen het laatste stukje authenticatie nog niet. Kijk anders daarna even met ethereal of network monitor wat er precies over de lijn gaat tijdens je authenticatie. Gezien de basic authenticatie moet je hier wat voorbij zien gaan.
Ik heb wel zoiets meegemaakt toen ik eens aant kloten was om ipv basic authentication NTLM authenticatie te gebruiken. Netjes inlogscherm, maar niet kunnen inloggen. Ik kan ze ff niet zo voor me halen hoe ze precies heten, maar binnen IIS het je twee RPC virtual directories, 1 normale en 1 secure. De instelling in je outlook profiel als de authenticatiemethode van de non-secure RPC VD moet basic zijn.

Even een gedeeltelijke terug koppeling.
Het inloggen met een UPN inlog maakt lokaal niet uit. Werkt allemaal perfect. Extern, zelfde, zolang ik outlook geopent houdt.

Ik krijg tevens geen security melding op de server. Ik zie geen enkele melding voorbij komen.
Kan je wat specifieker zijn met wat voor soort audits ik moet loggen om wat meer informatie te zien?

Ik zal morgen op de client ethereal installeren om te zien wat de communicatie is.

Die basic authentication staat zowel op de default website als de RPC directory goed.
Die andere heet tevens RPCSECURE o.i.d. die laat ik gewoon voor wat hij is, net zoals in alle how-to's wordt vermeld.

[pennenlikker]

Haal je dns file eens leeg van je client en probeer dan opnieuw zonder op het interne netwerk te komen.

ipconfig /flushdns

[Verwijderd]

pennenlikker schreef op donderdag 04 december 2008 @ 23:28:
Haal je dns file eens leeg van je client en probeer dan opnieuw zonder op het interne netwerk te komen.

ipconfig /flushdns

Heb het geprobeerd. Niets..

Vergeet niet dat ik meerdere pc's al tot mijn beschikking heb.
Ik test dit met 1 die verbonden is met het interne netwerk.
1 die extern is
en 1 die is verbonden via vpn.


Edit:
heb tevens een klein punt opgelost.
BIj het verwisselen van de kabel kwam ik er telkens achter dat, extern, de adreslijst niet gevonden werd (outlook.exe /rpcdiag).
Het bleek dat onze hoofd DC geen global catalog server was. Dit is hij nu wel, en bij het open laten van outlook, en het verwisselen van de kabel, wordt de adressenlijst netjes van de juiste DC gehaald.
Maar nog steeds niet veel verder.

[ Voor 31% gewijzigd door Verwijderd op 05-12-2008 09:44 ]

[Verwijderd]

Update 2..

het werkt.

Zelfs op de pc waar geen profiel opgehaald is doormiddel van eerst een VPN op te zetten.

[Jazzy]

Niet opgelost dus... Echt ontzettend lastig, ik zit hier zelf ook mee te prutsen op het moment.

[Verwijderd]

Jazzy schreef op vrijdag 05 december 2008 @ 09:57:
Niet opgelost dus... Echt ontzettend lastig, ik zit hier zelf ook mee te prutsen op het moment.

Wel opgelost.

Was dus puur en alleen de global catalog server. (oftewel een vinkje)

[Jazzy]

Verwijderd schreef op vrijdag 05 december 2008 @ 10:00:
[...]


Wel opgelost.

Ah, ik las je bericht verkeerd. Ik dacht dat je bedoelde dat het was opgelost door eerst een VPN verbinding te maken.

[Verwijderd]

Nee gelukkig is zelfs dat dus niet nodig.

Dus voor de mensen waarvan ik lees dat er eerst een VPN opgezet moet worden; nee dit is niet nodig, daar is iets anders mis.

[pennenlikker]

Verwijderd schreef op vrijdag 05 december 2008 @ 10:43:
Nee gelukkig is zelfs dat dus niet nodig.

Dus voor de mensen waarvan ik lees dat er eerst een VPN opgezet moet worden; nee dit is niet nodig, daar is iets anders mis.

Nee idd, dan is rpc over internet ook lekker nutteloos kun je net zo goed via je vpn met exchange connecten