[nharvey]

Originally Posted by Havelock

It's certainly been a learning experience

To clarify, from the terminal server on the domain, forcing Outlook Anywhere as the connection method, it works fine, mailbox and all mail appears - looking at the connections by launching outlook with outlook.exe /rpcdiag, you see 2 connections with a connection type of HTTPS to a directory service and one with a type of TCP/IP to a mail service.

From outside the domain, i.e. my home PC, the "directory service" connection establishes, mail tries and then errors. There are maybe about 4-5 Sales people who use this functionality - when in the office all works fine, outside, problem occurs.

My guess is that in addition to the first remote.somedomain.co.uk certificate, the client machine is also trying to authenticate srvsbs01.domain.local against the same cert, which is a no-no (for self-signed).

As an aside, I've spoken with this customer and their reluctance to purchase an additional cert is clearer - they're currently paying just under £300 a year for their citrix.somedomain.co.uk certificate - as a workaround we've set their reps up to use VPN/Outlook and when their citrix cert expires they're going to buy a 10 domain UCC cert to cover all their sub-domains.

I'll return to this post to confirm this resolves the issue in a couple of months should anyone come across it with their google-fu

Again - thanks for the assistance on clarifying this setup for me

Mark

eh, mostly I use ss certs.
The directory service establishes then errors, what error does it give?

[Havelock]

No errors - just a failure to connect. Event viewer nothing, IIS logs on server nothing, Transport log for Outlook nothing.

I've even attempted resorting to Wireshark to watch what its doing but the SSL stream is obfuscated so its pretty hard to follow

[nharvey]

Have you tried turning off any & every firewall you have?

Maybe the mail pointer for the domain?
..nevermind. if it was that, owa wouldn't work.
..right? lol

[Havelock]

Windows firewall was disabled for testing - though if this was the problem I wouldn't have expected to be able to get to https://somedomain.co.uk/rpc/rpcproxy.dll, which we could, and I would have expected RPCPing to ports 6001, 6002 and 6004 to fail, and they all succeeded.

The way I understand this stuff to work is that the outlook client only "sees" the RPC/CAS/Web server, and the webserver interfaces with the exchange box (or in this case itself) through something called DSProxy to do its mail and active directory stuff. If I'm mistaken on this please correct me as I find this stuff interesting.

My general feeling about this problem now is that we could probably - if we spent enough time messing around with it - be able to fudge this into working, but when all's said and done this would be an unsupported deployment should the customer ever have to call PSS, is harder to manage when adding more clients and there would be nothing stopping Microsoft from releasing a security update that nobbled whatever workaround system we came up with in the future anyway.

For now the customer is happy using VPN/Outlook in place of Outlook Anywhere - with the added bonus (for them) of being able to get to some additional internal resources they didn't realise would be accessible via VPN

Mark

[Virtual]

Not sure if this is of use.

http://www.petri.co.il/forums/showthread.php?t=58175

Last post shows you some technical aspects. I had to re-write URLs to suit the certificate being used.

[Havelock]

Morning Virtual,

Thats an interesting though and something I hadn't even through about - so if a customer has configured their own domain name (let say for some reason they called their local domain PETRI.CO.IL) that's resolvable externally it will break OA config, and disallow the creation of SSL Certs (and I presume break lots of other stuff...)

I think I was pretty much at that stage (apart from the certificate) - though this setup is much simpler:

>>>Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl
Identity : SERVER\EWS (Default Web Site)
InternalUrl : https://sub.somedomain.co.uk/EWS/Exchange.asmx
ExternalUrl : https://sub.somedomain.co.uk/ews/exchange.asmx

>>>Get-AutodiscoverVirtualDirectory
Name Server InternalUrl
---- ------ -----------
Autodiscover (Default Web Site) SERVER https://sub.somedomain.co.uk/

>>>Get-ClientAccessServer |fl identity,autodiscoverserviceinternaluri
Identity : SERVER
AutoDiscoverServiceInternalUri : https://sub.somedomain.co.uk/Autodis...todiscover.xml

Pinging SERVER.somedomain.co.uk and SERVER.domain.local from the client PC fail, pinging sub.somedomain.co.uk resolves to the public IP in the external DNS.

Pinging SERVER.somedomain.co.uk, SERVER.domain.local and sub.somedomain.co.uk from the LAN resolves to the private IP.

So I'm guessing all this is right, and they just need a UCC cert with sub.somedomain.co.uk and SERVER.domain.local in it.

Mark

[Virtual]

In my case, their AD domain was resolvable on the internet and they didn't own the address. Their registered external domain used by Exchange was the SMTP address and providing external access, hence having to make some changes.

It does allow you to reduce the entries for the cert. I have even used a Wildcard certificate before as have used the same for a number of systems. I tend to also include netbios name etc as well on the cert but it depends how you configure the URLs.

Also, using a wildcard can give limitations in Exchange, so one to be tested.

How about try a free trial with a Certificate provider at some point and test this on a test system representative of the Production one. Maybe even P to V the current.

[Havelock]

Morning All,

Just a quick update on this - customer purchased a full, externally verified SSL certificate - all problems with OA are resolved as a result

Cheers for the assist everyone

Mark

[Virtual]

Good to hear and thanks for posting back.