Managing our Exchange 2007 server is just one of the many hats I wear, so I'm nowhere near an expert on it. I'm hoping that one of you who ARE experts can help. :-) This morning I noticed that my Exchange server was fussing about an expired internal certificate. Actually, both of our servers were (we have a separate Edge server). So I did the "New-ExchangeCertificate" thing and got rid of the error and patted myself on the back for a job well done. Now I've come home and launched Outlook, and I see that RPC over HTTP has stopped working. I feel confident that this is related to my new certificate. Is there a step I missed to keep this feature working after getting a new certificate? OWA is still working fine, if that makes a difference. John

If you were not using a commercial SSL certificate then the certificate that is now on the server is no longer trusted. Furthermore, the self signed certificates that are created by Exchange are not supported for use with Outlook Anywhere. Your best option is to complete your Exchange 2007 deployment with a commercial SSL certificate. That will avoid problems in the future. http://blog.sembee.co.uk/post/Exchange-2007-and-SSL-Certificates-Take-2.aspx Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

We actually have a commercial SSL cert on that server--it's used by OWA. So, is there something I can do to make RPC over HTTP use that certificate rather than the self-signed ones?

On Sun, 6 Mar 2011 00:26:23 +0000, ParrotHead wrote: >We actually have a commercial SSL cert on that server--it's used by OWA. So, is there something I can do to make RPC over HTTP use that certificate rather than the self-signed ones? Sure. Enable-ExchangeCertificate. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks, Rich. As I mentioned in my original post, though, I'm not an expert on Exchange by any stretch of the imagination. So, three questions. 1. How can I determine which certificate RPC over HTTP is currently using? 2. If RPC over HTTP is running on the same server as OWA, would they not already be using the same certificates? 3. What parameters would I need to use with the Enable-ExchangeCertificate command to get RPC over HTTP to use the same certificate as OWA (i.e., the commercial certificate)?

On Sun, 6 Mar 2011 12:46:15 +0000, ParrotHead wrote: >Thanks, Rich. As I mentioned in my original post, though, I'm not an expert on Exchange by any stretch of the imagination. So, three questions. > >1. How can I determine which certificate RPC over HTTP is currently using? Use get-exchangecertificate. Which one has the appropriate services? If you have only one Exchange server you probably want to see "IP.WS" in the "Services" column. The "W" represents "Web". >2. If RPC over HTTP is running on the same server as OWA, would they not already be using the same certificates? If you have one machine you probably have a SAN/UCC certificate. That certificate should have the name of your server in then set of SAN names, and the CN of the certificate should be whatever you use ad the domain name in OWA and the Outlook profile for the Exchange proxy settings. >3. What parameters would I need to use with the Enable-ExchangeCertificate command to get RPC over HTTP to use the same certificate as OWA (i.e., the commercial certificate)? enable-exchangecertificate <thumbprint> -services "IMAP,POP,IIS,SMTP" If you're using unified messaging you should add "UM" to that list. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I'm a little thrown off by this, because the old cert that expired wasn't using the "W" service--so the new one shouldn't have, either. Only our wildcard 3rd party cert had/has "W" enabled for it. That's working fine for Outlook Web Access, and I don't want to break anything. When I use testexchangeconnectivity.com to test RPC over HTTP, everything looks good until I get a fail at the final part: === Testing SSL mutual authentication with the RPC proxy server. Verification of mutual authentication failed. Tell me more about this issue and how to resolve it Additional Details The certificate common name *.taylor.k12.fl.us doesn't validate against the mutual authentication string that was provided: msstd:mail.taylor.k12.fl.us === Earlier in the test process is "Testing the SSL certificate to make sure it's valid," and that part passes (saying things like, "The host name that was found, mail.taylor.k12.fl.us, is a wildcard certificate match for common name *.taylor.k12.fl.us.")--so something must be right. Following the help associated with the mutual authentication error, I ran this command and got these results: [PS] C:\>get-outlookprovider Name Server CertPrincipalName TTL ---- ------ ----------------- --- EXCH 1 EXPR 1 WEB 1 Figuring this was the problem, I ran this: Set-OutlookProvider EXPR -CertPrincipalName:"msstd:mail.taylor.k12.fl.us" However, RPC over HTTP is *still* failing the mutual authentication test. I don't know what else to do.

In the world of SSL, mail.example.com and *.example.com are NOT the same. The MSSTD value has to match the SSL certificate exactly. Therefore you need to set the MSSTD value to *.example.com and then restart IIS. Then it should work. That is why you are getting an error in the tests, because it doesn't match. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Yeah, I figured that out shortly after making the post. :-) HOWEVER... I rebooted the Exchange server, and RPC over HTTP started working despite that error. But because the error annoyed me, I ran this: Set-OutlookProvider EXPR -CertPrincipalName:"msstd:*.taylor.k12.fl.us" I confirmed it was right by using Get-OutlookProvider, then restarted IISAdmin. RPC over HTTP is *still* failing the test, though: Testing SSL mutual authentication with the RPC proxy server. Verification of mutual authentication failed. Tell me more about this issue and how to resolve it Additional Details The certificate common name *.taylor.k12.fl.us doesn't validate against the mutual authentication string that was provided: msstd:mail.taylor.k12.fl.us I'm stumped. But I don't know whether to worry... That error bugs me, but RPC over HTTP is actually working in the real world even though it's failing Microsoft's test...

When you did that test in testexchangeconnectivity.dom did you manually enter in the msstd or did you let autodiscover find it? If you right click the outlook icon on bottom right tray and do ctrl+right click test email autoconfiguration and run the autodiscover test does the results for the protocol HTTP say msstd:*.taylor.k2.fl.us? The outlookprovider is a AD setting, maybe there was replication delay when you did the test as well.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

I did autodiscover--I didn't put in anything other than the test e-mail address, domain\username, and password. On the right-click test, it says "Server: mail.taylor.k12.fl.us" and "Certificate Principal Name: msstd:*.taylor.k12.fl.us" And now, just to keep things interesting, TestExchangeConnectivity.com is failing the test with a NEW error: Testing the Name Service Provider Interface (NSPI) on the Exchange Mailbox server. === An error occurred while testing the NSPI RPC endpoint. Test Steps Attempting to ping RPC endpoint 6004 (NSPI Proxy Interface) on server Exchange-Core.taylor.k12.fl.us. The attempt to ping the endpoint failed. Tell me more about this issue and how to resolve it Additional Details The RPC_S_SERVER_UNAVAILABLE error (0x6ba) was thrown by the RPC Runtime process. === But I've tested RPC over HTTP on multiple machines, and it seems to be working. So I think I'm packing it in. In the end, I don't think my initial problem had anything to do with my license renewal--I think it was just Exchange acting flaky, and a reboot fixed it. Why Microsoft's web-based test is still failing, I don't know. But things seem to be working correctly on real-world machines, so I'm satisfied.