I have two CAS servers behind a pair of F5 BIG-IP boxes. I have a cert on the F5 boxes with names mail.domain.com and autodiscover.domain.com. I do not have public certs on my two CAS servers. All my clients connecting from the Internet work great. Outlook 2010 clients connecting from inside connect directly to one of the CAS servers and get a cert error. Should I buy two more certs for the two CAS servers or is there a way to force the use of the certs on the F5 boxes?--Patrick

Are all of the internal CAS URLs pointed to the F5 VIP? Also, are the interal URLs configured to use mail.domain.com (matching the external URLs)? If not, they should be. Also do you have SSL Offloading configured?Tim Harrington | MVP: Exchange | MCITP: EMA 2007/2010, MCITP: Server 2008, MCTS: OCS | Blog: http://HowDoUC.blogspot.com | Twitter: @twharrington

Yes on all of that. My internal and external URLs all point to mail.domain.com. I have run through the doc for offloading SSL for each service. I forgot a couple of steps from the F5 E2010 guide. I just added these commands. New-ClientAccessArray -Name "First Array" -FQDN mail.domain.com Set-MailboxDatabase "DB1" -RPCClientAccessServer mail.domain.com I restared Outlook 2010 but still got the cert warrning. I should probably restart some services and test again. --Patrick

The CAS array should NOT be the same as your external name. It should be a name that is internal only and does not have to be on the SSL certificate because nothing connects to the CAS array using SSL. Therefore you would have mail.example.com as your public name, on the SSL certificate etc and then something like outlook.example.local would be your CAS array host. Furthermore this wouldn't have resolved the issue because the CAS array host is only updated either when the Outlook profile is first created, or when it is repaired. Outlook doesn't update on the fly. You need to see which element they are connecting to the CAS server for. It is probably OAB or something like that. Hold down ctrl and right click on the Outlook icon in the system tray. Choose test email autoconfiguration. This will run a test and you can see what URLs are returned. SimonSimon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

You could be getting cert errors internally if you set your internalURL your external name and your CAS server only has the default self signed certs with it's host nane. get-clientaccessserver dcexcasp01 |fl Autodiscoverinternaluri get-webservicesvirtualdirectory |fl InternalUrl get-oabvirtualdirectory |fl InternalUrl James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

The CAS array should NOT be the same as your external name. It should be a name that is internal only and does not have to be on the SSL certificate because nothing connects to the CAS array using SSL. Therefore you would have mail.example.com as your public name, on the SSL certificate etc and then something like outlook.example.local would be your CAS array host. Furthermore this wouldn't have resolved the issue because the CAS array host is only updated either when the Outlook profile is first created, or when it is repaired. Outlook doesn't update on the fly. You need to see which element they are connecting to the CAS server for. It is probably OAB or something like that. Hold down ctrl and right click on the Outlook icon in the system tray. Choose test email autoconfiguration. This will run a test and you can see what URLs are returned. Simon Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me. I'm not seeing the logic of having two different URLs if I run everyone, both internal and external users, through the same hardware load balancers. The test e-mail autoconfig shows the non-mail.domain.com names for OOF and OAB. --Patrick

Does the CAS servers still have valid self signed certs for their hostnames?James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Does the CAS servers still have valid self signed certs for their hostnames? James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com Yes. That seems to be the problem. They are self signed so they have no valid trusted root. I can tell users to install the cert when they see the message but I really don't like that option. I have an internal CA infrastructure so I could create my own certs for these two CAS servers. --Patrick

I'm not seeing the logic of having two different URLs if I run everyone, both internal and external users, through the same hardware load balancers. From Technet: "It's important that the (FQDN) specified in the command be only resolvable internally. If the name is also resolvable externally, these external clients will attempt to connect to the array via a TCP connection instead of HTTPS. " http://technet.microsoft.com/en-us/library/ee332317.aspx Basically using the same name internally and externally breaks Outlook Anywhere. What you will find is that things will work correctly now, because the Outlook clients are using the old information. This is due to the way that the host name being used is updated (or not as the case may be). Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Okay, I'm changing my RPC CAS array to outlook.domain.com and will use mail.domain.com for outside. I'm assuming then that all of my services should have the inside URL changed to reflect the outlook.domain.com name and keep the external URL as mail.domain.com. I'm also changing my F5 VIP for RPC connections to a different IP address since it will have a new name. mail points to 10.1.7.20 and outlook points to 10.1.7.19. Both on the same subnet but only 10.1.7.20 has an external NAT entry and outside access. --Patrick

The CAS array is for RPC traffic only. Do not change any of the other URLs to match it, because no SSL traffic will use it. The existing configuration is fine. It is only the CAS array that has to be changed. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Alrighty then. Internal AND external URLs for OWA, ECP, AS, and OAB are all set to https://mail.domain.com plus whatever their respective folder paths were set to. --Patrick

I just looked at my Outlook 2010 client AutoConfig stuff: Protocol: Exchange RPC Server: outlook.domain.com Look right?--Patrick

If the URL is what you had set, then it would be correct. You should find that if you hold down CTRL while right clicking on the Outlook icon and then choosing Connection Status, all of the elements will be that "virtual" name, rather than the real name of an Exchange server. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

When I look at the Outlook connection status, the server name is reported as outlook.domain.com on three lines. Only public folders point to the old 2007 server because I haven't moved them yet. I did change the self signed cert for both of my mailbox servers to cert from my internal CA servers. I'm not sure this was the right thing to do. Should I go back to the self signed certs? I have all four of my new databased configured. I'm concerned about the results of this command. Is there a problem or is this to be expected? I ran these on both mailbox servers with the same results. [PS] C:\>Set-MailboxDatabase "DB1" -RPCClientAccessServer outlook.domain.com WARNING: The command completed successfully but no settings of 'DB1' have been modified. [PS] C:\>Set-MailboxDatabase "DB2" -RPCClientAccessServer outlook.domain.com WARNING: The command completed successfully but no settings of 'DB2' have been modified. [PS] C:\>Set-MailboxDatabase "DB3" -RPCClientAccessServer outlook.domain.com WARNING: The command completed successfully but no settings of 'DB3' have been modified. [PS] C:\>Set-MailboxDatabase "DB4" -RPCClientAccessServer outlook.domain.com WARNING: The command completed successfully but no settings of 'DB4' have been modified. --Patrick

This just means that your mailbox databases are pointing towards the CAS Array name you created instead of the individual FQDNs of the CAS servers. Since you want to load balance your internal CAS traffic this is all fine and dandy. The -RPCClientAccessServer is just a pointer for Outlook to know where to establish its sessions to connect to the Exchange mailbox.Jesper Bernle | Blog: http://xchangeserver.wordpress.com