Mystical_Ice
asked on
Outlook 2007 to Excange 2007 via RPC over HTTP (outlook anywhere) - tough problem
So we've had an exchange 2007 server running, with several outlook anywhere (RPC over HTTP) clients for the past several years without incident. Well last night we moved to a new location (with new IP addresses obviously), and i forwarded our MX records, etc. to the Exchange server's new IP.
Users can now launch outlook, send and receive emails just fine, BUT when they try to add a contact, or print an email, they get the error shown in the picture.
Tried starting Outlook with the /rpcdiag paramater, and it shows the "mail" threads connecting, but the "directory" ones don't - wonder if that can be the problem?
We have a public SSL certificate, but to my knowledge that doesn't have any link to an IP address (right?) and since Outlook connects just fine, that can't be the issue.
rpcdiag.jpg
errormessage.jpg
Users can now launch outlook, send and receive emails just fine, BUT when they try to add a contact, or print an email, they get the error shown in the picture.
Tried starting Outlook with the /rpcdiag paramater, and it shows the "mail" threads connecting, but the "directory" ones don't - wonder if that can be the problem?
We have a public SSL certificate, but to my knowledge that doesn't have any link to an IP address (right?) and since Outlook connects just fine, that can't be the issue.
rpcdiag.jpg
errormessage.jpg
theras2000
The IP does matter. Certificates need the domain name to match the public IP. If you've chanded your public IP, then you need to create new certificates. Internally, with Exchange/Outlook, it doesn't matter, but externally it does.
@Mystical_Ice
I need to disagree with @theras2000 as long as you have change the DNS record to point to your new IP you should not rekey your certificate the IP doesn't matter at all
got to testexchangeconnectivity.c
I need to disagree with @theras2000 as long as you have change the DNS record to point to your new IP you should not rekey your certificate the IP doesn't matter at all
got to testexchangeconnectivity.c
ASKER
Theras2000: don't see how that's the case; at no point in the SSL creation process does even ask for an Ip address. And if that was the problem, then both the DIRECTORY AND mail threads would fail, not just one.
ASKER
I ran the outlook anywhere test, and it said two things:
Testing TCP Port 443 on host amcdoors.com to ensure it is listening and open.
The specified port is either blocked, not listening, or not producing the expected response.
Attempting to ping RPC Endpoint 6004 (NSPI Proxy Interface) on server amc-exchange1.AMCDoors.loc
The attempt to ping the endpoint failed.
That doesn't make sense - this all worked just fine before moving. The firewall was moved with the server, and all i did to teh firewall was change the IP address mapping.
Driving to the office right now to figure it out...
Testing TCP Port 443 on host amcdoors.com to ensure it is listening and open.
The specified port is either blocked, not listening, or not producing the expected response.
Attempting to ping RPC Endpoint 6004 (NSPI Proxy Interface) on server amc-exchange1.AMCDoors.loc
The attempt to ping the endpoint failed.
That doesn't make sense - this all worked just fine before moving. The firewall was moved with the server, and all i did to teh firewall was change the IP address mapping.
Driving to the office right now to figure it out...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
On the CAS server when you try
ping localhost;ping Netbios...is that resulting in the IPV6
In that case, we need to edit the HOST file of the CAS server
Add the IPv4 mapped to the localhost; Netbios and FQDN name of the CAS server
Then, try accessing the rpc over HTTPs profile.
Reason: the directory connection needs IPv4 to communicate propertly
ping localhost;ping Netbios...is that resulting in the IPV6
In that case, we need to edit the HOST file of the CAS server
Add the IPv4 mapped to the localhost; Netbios and FQDN name of the CAS server
Then, try accessing the rpc over HTTPs profile.
Reason: the directory connection needs IPv4 to communicate propertly
I see a couple of things.
1. you refer to host.amcdoors.com. the mx record for amcdoors.com is reported as mail.amcdoors.com.
2. Running an smtp test from mxtoolbox.com on the domain amcdoors.com gets a response from spam.amcdoors.com and shows that your reverse dns doesn't match. That may have something to do with it. Update your reverse dns. I'd get in touch with comcast and tell them to set your reverse dns.
It appears to me that the problem has something to do with your spam filter.
1. you refer to host.amcdoors.com. the mx record for amcdoors.com is reported as mail.amcdoors.com.
2. Running an smtp test from mxtoolbox.com on the domain amcdoors.com gets a response from spam.amcdoors.com and shows that your reverse dns doesn't match. That may have something to do with it. Update your reverse dns. I'd get in touch with comcast and tell them to set your reverse dns.
It appears to me that the problem has something to do with your spam filter.
Fair enough, I take your point ppl. I guess I've confused myself between the IP and DNS reqs of SSL.
ASKER
Guys - thanks so much for the assistance. Turns out Exchange 2007 has a weird problem where sometimes, upon restarting, not all services come up correctly. This was the case the last time i restarted it - the information store never mounted (service wasn't started), and the POP service didn't start either. I ended up just restarting the server, all services came up, and problem solved.
SO it was a service issue. Thanks so much :)
SO it was a service issue. Thanks so much :)
great what counts is that it is working now