Update #2 – July 28th 2014 –
Removing the EXPR while Autodiscover is being utilized (which is probably the case in most deployments) will achieve preventing Outlook Anywhere from being used.
With that being said, a few commentators stated that they would like to continue using Outlook Anywhere and with Autodiscover enabled and the EXPR removed this will result in constant “removal” of the Outlook Anywhere settings that were statically configured.
If you want only specific users to be able to use Outlook Anywhere while others don’t I would advice considering the Set-CasMailbox -MAPIBlockOutlookRpcHttp:$true cmdlet to allow/block specific users.
Update – June 29th 2013 –
If you’re going to deploy Exchange 2013 anytime soon – work your way to adapt autodiscover, and bring back the EXPR value. See Exchange 2013 Outlook Anywhere Considerations for more.
This is an unsupported method, use at your own risk!
Once “Outlook Anywhere” is configured on a client access server an EXPR entry is created. Then the autodiscover application picks up the change and publish it, along with the url’s for OAB,EWS & Availability.
This basically “force” the automatic propagation of settings into the profile, including the checkbox for “Connect to Microsoft Exchange using HTTP” and filling the information for the HTTP proxy and authentication methods.
Microsoft documented Deployment Considerations for the Autodiscover Service in:
http://technet.microsoft.com/en-us/library/aa997633(EXCHG.80).aspx – Where only Site Affinity is can be configured.
The Outlook provider setting and autodiscover relation are referenced quite good in the Exchange team blog:
http://msexchangeteam.com/archive/2008/09/26/449908.aspx
A client of mine needed the possibility to disable the automatic propagation of the “Connect to Microsoft Exchange using HTTP” setting in an Exchange 2007 environment .
he did of course wanted to keep the ability to connect using “Outlook Anywhere” if desired when configuring that manually.
Because autodiscover was made to auto-configure clients that are inside & outside the corporate network disabling this feature disables the ability for external outlook clients, that not domain joined to automatically connect using “Outlook Anywhere” . it does, however does not affect the configuration of a profile.
Within the exchange shell:
Get-outlookprovider –identity EXPR | remove-outlookprovider
Once this is done, recycle the application pool of AutoDiscover in IIS.
This solution will keep the outlook clients from automatically propagate the settings for “Outlook Anywhere” , but retains the possibility for configuring it manually.
All web services and autodiscover information other then the proxy information itself are intact.
Updates (Thanks for all commentators)
- I’ve written another article related on the subject, highly recommended reading:
Authentication pop ups and annoyances with Exchange 2007 / 2010 and Outlook Anywhere - The above applies also for Exchange 2010
- To restore the EXPR provider, run the following:
New-OutlookProvider -Name:EXPR
I have done the required testing to make sure this solution works.
This is an unsupported method, use at your own risk!
Cool, dude!
This is very good, however, if I wanted it to reverse this after removing it, how would I do so?
one should note the EXPR setting when running the get-outlookprovider and could later run the add-outlookprovider command with the same parameters, backup is always a good strategy 🙂
When the article says;
“Once this is done, recycle the application pool of AutoDiscover in IIS.”
What exactly does he mean? Just stop and start the autodiscovery iis pool?
Well I meant the recycle option from the context menu when right clicking the app pool.
Stop/Start will work just as good 🙂
Hello Ilanzt,
Great weblog!!!
Is there a method to block outlook 2007 by omiting the EXPR provider settings that exchange 2007 autodiscover is sending to them?
I don’t want to remove EXPR provider, only block outlook clients from accepting this settings because I want to configure manually the proxy settings in outlook profile for static PC’s users and for the rest ( laptops ) is good the autoconfigure.
Thanks.
Hi Joan,
Thanks, glad you like my blog 🙂 !
This configuration – removing the EXPR is actually the only method to “block” the automatic proxy setting with outlook 2007/2010..
if you remove it, it does not mean you will lose the option to connect using RPC over HTTP ! just the auto configuration with autodiscover is stopped.
Hi Ilantz,
We are using outlook 2007 with exchange 2007.
Removing the EXPR provider works in Exchange 2010 also?
Best regards.
Yes! Flawless 🙂
Is there a way to change to parameters in the autodiscover so the Authentication parameter in autodiscovery can be set to Basic?
Hi,
The authentication method is driven from the outlook anywhere configuration,
when you enable a CAS server for outlook anywhere, you select the authentication method.
If you wish to deploy the settings manually you can use the office customization tool to create a PRF file.
the tool is available for office 2003/2007 and 2010.
ilantz
Great post, solved my problem exactly! Thanks!!!
Hello,
I would like to make some observations (my case Exchange 2010).
To add back the provider: new-outlookprovider -name EXPR
Also removing this outlook provider will stop “to automatically propagate the settings for “Outlook Anywhere” and retains the possibility for configuring it manually” but will have trouble (sync errors) downloading OAB. I think Outlook 2007 is using autodiscover to get OAB url.
Thank you.
Thanks for your comment Chip,
IMHO, OAB sync issues is not directly related to this method.
The autodiscover service will continue to provide with the relevant information, OAB,EWS and the rest http links respectively. This is based on numerous production environments I’ve configured with removing the EXPR.
Hi, great post
How do you add the EXPR back in?
It seems to have worked but I need to know how to add back in
Running Get-outlookprovider –identity EXPR | add-outlookprovider is not a recognized command, please advise
Thanks in advance
Hello Ricky,
I’ve now included the method to restore the EXPR back in the article.
The line you ran failed because the provider is no longer exists, hence the “get” doesn’t return anything to pipeline the “new” command.
Anyways, use the following:
New-OutlookProvider -Name:EXPRWorked for me – many thanks!
hi,
Running this command: Get-outlookprovider –identity EXPR | remove-outlookprovider
solved my issue. Thanks
Nice fix..thank you!!
is it possible to do it only for few users?, my goal is to give only few users the option to manually configure outlook anywhere on their outlook 2007, currently the checkbox is gray….
Well, you can control these settings using Group Policy as well, just grab the office ADM / ADMX files and configure this as you need.
The EXPR settings “push” themselves once Outlook Anywhere is enabled.
Following my post will disable the automatic configuration allowing you to manually configure this for your users, or deploy GPO for them.
But you must first Enable Outlook Anywhere on a CAS server.
Good Luck!
Seem to work graet for me.
Many thanks
Happy to hear that Asaf ! You’re welcome!
hi,
i have to 2 exchange server with client access role installed. sometimes users with mailbox on server1 gets automatically configured with the outlook anywhere settings of server2….
is there any way to restrict client access server to push outlook anywhere settings on specific mailboxes or databases ?
Double check that the users mailbox is indeed located and activated in the correct site.
a mailbox will always be configured automatically with the CAS server setting which serves it’s mailbox server where the mailbox is located.
If you have multiple sites, with multiple CAS servers with different external names enabled for Outlook Anywhere , this scenario might happen when a mailbox or a database will be activated or moved to a different site, and a “new” CAS will be serving the mailbox/database.
Hope this clears up your question.
ilantz
Dude, you are a life saver. I have been looking for the solution to this problem forever!!!
You’re welcome Kyle!
stop by more often for more 😉
Thanks looks like it fixes me up. Did this start after a service pack. This seems like a new problem for me.
Thanks this has been helpful – however I find the setting keeps coming back, has anyone experienced this?
Have you performed the article steps?
Remove-OutlookProvider ?
Yes and it works great, however it keeps coming back. I ran the command again yesterday and this morning when I checked with the get-outlookprovider command, it is back.
Hi Christina,
I believe you should double check for any AD Replication issues you might have.
The setting should not “come back”, defiantly if no one created it back… 🙂
It seems someone was creating it back – thanks for your reply!
ilantz,
I am having this issue now. My users all of a sudden gets the ‘Connect to Microsoft Exchange over HTTP’ setting enabled. This setting breaks Symantec Enterprise Vault. My Exchange admin swears to me that Autodiscover is not enabling this setting. If we create a new Outlook Profile, The setting is not enabled by default. So somehow, users are getting this setting enabled. The users we fixed have not have the setting automatically re-enabled yet. What do you think caused this setting to be enabled out of no where?
What does the output of get-outlookprovider looks like ?
perhaps you have installed a new Exchange CAS server lately ?
My Exchange Admin said the CAS servers are clean. Is the output of get-outlookprovider can only be done from the Exchange server?
If you have external URLs set on your CAS server, this is what is pushed to the Outlook profiles when the EXPR provider is enabled. If it is removed as above, the URL will not be pushed to user profiles, however once it has been set, they would need to manually remove the setting.
I have not touched MS Exchange since version 5.5. So I will need to ask my Exchange admin about EXPR and what URLs are set.
If the output of the get-outlookprovider will include an EXPR entry, follow this post method.
As Christina noted, if it was already pushed to clients, you will need to manually remove the outlook anywhere settings.
ilantz
ilantz,
Thanks for the post. the solution you have provided seems to have worked for the users inside our network as the Outlook Anywhere no longer automatically applies. After running the “remove-outlookprovider” command, recycle pool, and then manually unchecking the “Outlook Anywhere”, all is well. The problem I am having now is with the remote users. After manually configuring Outlook Anywhere for our remote clients, the setting does not stay in place after some period of time. Any suggestions? I really appreciate your time. Thank!
Hi Edward,
Sorry for the late response, when you wrote “the setting does not stay in place” what exactly do you mean ?
what is exactly being changed ?
ilantz
My output actually came back with blank fields however we are experiencing exactly what you’ve described. Even if we unchecked Outlook Anywhere it’s automatically rechecked just moments after an Outlook restart. My question is even though both of my servers output is blank should I still run the command above?
Name Server CertPrincipalName TTL
—- —— —————– —
EXCH 1
EXPR 1
WEB 1
The “blank” output is the default setting, the post suggests a method to disable the check-box from being automatically re-checked,
you need to run the commands Get-outlookprovider –identity EXPR | remove-outlookprovider and then recycle the application pool of AutoDiscover in IIS on your cas server/s.
You should be set from that point forward. the check-box won’t come back 🙂
Thanks for the article.
I have a question about the msstd. my SSL will not allow me to have “msstd:server.domain.com” I have a multi name cert with domain.com, mail.domain.com, autodiscover.domain.com, server.domain.com but it will not let me use msstd:server.doman.com or anything with the msstd:
I ran the following command from the Exchange Shell
Set-OutlookProvider -id EXPR -Server [server] -CertPrincipalName “mail.domain.com” and
Get-OutlookProvdier returns an EXPR CertPrincipleName of mail.domain.com (minus the msstd)
But my external clients cannot connect, they get a prompt to input the username and password but it does not go through.
PS Exchange 2007 Outlook 2010
Thanks
Hello Danny,
The “msstd:” does not needs to be included within the certificate,
it is a reference to the certificate “Subject Name” or “Common Name”.
You need to view your issued certificate details and just add the “msstd:” as a prefix.
Hope this answers your question,
ilantz
Hey ilantz,
thanks for your great article. Worked like a charm + I can enable Outlook Anywhere only for those users, who really need it.
I’m currently having an issue that an external autodiscover does not return the external EWS URL to Outlook Anywhere and Lync users. Could this be related to the Provider I removed?
This is the xml result for autodiscover:
https://SRV-EX.dp.intern/owa/
EXCH
https://SRV-EX.dp.intern/EWS/Exchange.asmx
https://mail.dp.de/owa/
Thanks for your support.
Cheers
Micoud
Hi Micoud,
I’m happy to hear the post helped you 🙂
Regarding the EWS, just run the Set-WebServicesVirtualDirectory -ExternalURL https://ilantz.com/EWS/Exchange.asmx (for example)
Recycle the autodiscover pool within IIS and this should fix this issue.
ilantz
Hi,
the ExternalURL and InternalURL are set correctly. Anyway, the EWS is only provided to external users once the Outlook Provider EXPR is active 🙁
Thats why I added the Outlook Provider back to Exchange…
And now EWS is again published to external autodiscover users… :-/
Well that is a behavior that I am not familiar with.. I got EXPR removed on dozens of my clients and EWS is working great 🙂
The URL’s are retrieved from the Autodiscover web service and has nothing to do with the EXPR as far as I know..
ilantz
Is there a way to simply uncheck the “connect to microsoft exchange using http” box and leave the settings intact? I would like to do so for people who might need it.
Hello ilantz,
Sorry for not specifying that. What I meant is that Outlook Anywhere does not remain enabled. First the issue was with users inside our network where Outlook Anywhere automatically enables itself. After applying your solution, it worked for our internal users. Afterwards, our remote users were experiencing the exact opposite. Outlook Anywhere would now disable automatically. When I would remote into their pc , I noticed all settings associated with Outlook Anywhere was removed. I went ahead and ran the command New-Outlookprovider -Name:EXPR which solved that issue. But now I am at square one with the problem I originally had with internal users. Thank you for your reply!
Hi Edward,
After running the Remove-OutlookProvider cmdlet, you should manually configure the outlook anywhere settings, that’s the only it will stick.
note your “correct” settings and fill them manually to the users’ profile.
That should stick.
ilantz
Hi Ben,
Per my current experience, un-checking that box will clear out all configuration related to Outlook Anywhere, so basically no.
removing the EXPR will just disable the automatic configuration, but will allow you to configure Outlook Anywhere manually, so your covered with that.
You might look into handing out outlook PRF files to allow easy “self service” configuration if you like..
you ca read more about it here: http://technet.microsoft.com/en-us/library/cc179062.aspx
Hi,
from my experience, Exchange will automatically check the box again everyday.
Been through this..
Cheers
Micoud
Hi, if you dsay Exchange automatically checks off the box again. have you found out how to auto disable that from happening.
Hi Trevis,
This issue seems to happen only with some configurations,
I will try to reproduce this in my lab and hopefully come with a solution.. I’ll update the post if I find any new information.
ilantz
Super advices, thank You very much, it works :-))))
You are most welcome 🙂
Nice Article and it has worked like a charm.
but a question to ask, i am having 2007 and 2010 outlook in my setup. I want to enable the setting of Outlook Anywhere 2010 and after i enable it gets clear on each restart.
both check box and url is disappeared from the outlook automatically.
can you please help me in this regard.
ilantz,
Thank you for this Blog. We have been battling the authentication pop-ups for months and this has been the best resource by far.
Would the following command be just as effective to keep clients from autoconfiguring Outlook Anywhere settings?
Set-OutlookProvider -Identity msExchAutoDiscoverConfig -TTL 0
It looks like the TTL parameter is there for just this purpose.
Thanks
WillyMatt
Hi Eric,
As far as I know, the TTL will have no effect on the auto configuration, but please come back with any updates you might have !
ilantz
HI Ilantz,
I got big network bandwidth issues. All my 4 sites IPVPN clients are connecting to exchange 2010 via http?
Some laptop users work outside and need this outlookanywhere. but how do i let all internal client to connect via tcp/ip ?
Net DMZ (TMG BOX) /SQUID Proxy Exchange Outlook clients
Outlook client
Exchage server: exchange.internal.com
RPC/HTTP: outlook.external.com
outlook.external.com—- resolve to TMG box IP ( External)
TMG Rules are ok and client connects but big usage?
What can i do?
Hi Mocsy,
Internal clients should be able to connect to Exchange using tcp/ip as long as the required TCP ports are open,
read this post to have your life easier – http://social.technet.microsoft.com/wiki/contents/articles/864.configure-static-rpc-ports-on-an-exchange-2010-client-access-server-en-us.aspx use the script in the bottom of the post for even easier configuration.
You’ll basically need to open the ports you’ve configured, along with TCP 135, and you should be good to go.
Good luck !
ilantz
Hi,
Thanks, So i just run that PS and i’ll check tomorrow and let u know. I can see lots are connect using 443 not 135 ?
TCP 10.1.181.9:443 10.254.2.5:20465 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20466 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20467 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20468 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20469 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20470 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20471 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20472 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20473 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20474 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20475 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20476 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20477 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20478 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20479 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20483 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20484 ESTABLISHED
TCP 10.1.181.9:443 10.254.2.5:20485 ESTABLISHED
AS
Yes, this makes sense because the ports required for TCP/IP are still blocked 🙂
Hi, i have a scenario where some users work fine, and some do not! I have looked all over but havent found a similar problem. Please I need help!
Best Regards to all.
Hi Eric,
Can you please explain? What exactly does not work ?
Sorry Ilan, I thought I was not clear enough after reading the post. Let me try to be more specific.
We have a scenario where all Exchange services are hosted on the same server. Everything works well, but we seem to be having problems with some random users when they are trying to use their Outlook from a location other than our LAN. Again, this only happens with some users. We have correctly configured our Outlook Anywhere through the Outlook Web Access, (Acct Settings -> Advanced -> Connection -> “Connect to Microsoft Exchange using HTTP checked”, Exchange proxy settings -> webmail address on the URL, and also de correct setting on the msstd portion of the configuration. Basic Auth.”
Most of the users work fine… and here is where we go nuts.
We have tested a particular user to troubleshoot his problem.
*Outlook connects OK from his computer on our LAN. (so we make sure the outlook anywhere settings are ok)
*We unplug his network cable and connect to a testing LAN we have (other than our intranet). No Connection, it keeps asking for password.
**At this point, we try configuring his account on another computer that I know it works remotely, and BAM!, Connection Successful via Http Proxy.
Nothing changed on the computers that it does not work anymore, we have tried upgrading and updating the Office versions to the latest 2010 we have licensed, and nothing still from those computers. However, it works on the others.
Thanks for your blog, its great.
Best Regars.
Eric.
Hi Eric,
Following your explanation I would tend to think that you should make sure you eliminate any network conditions, that is DNS, proxy, firewalls etc…
My personal opinion is that there’s always an explanation, thus troubleshooting an issue might take more then a no-brainier solution – aka “format” 🙂 so you’ll have to consider your efforts.
If you’re still up for troubleshooting ill suggest using fiddler2.
Good luck, I’ll be happy to hear what came out.
Ilantz
I know this is an ancient post – but HELL YEAH IT WORKED!!!!!!!!!!!!!!!!!
Busy doing a manual (non MS idea) swap from local SBS 2011 Exchange to Exchange Online and my profile kept on changing the details back to the onsite RPC… This did the trick, thank you!
Glad you found this useful!
Ilantz
Maybe this is as good a place as any to ask the question:
How/Where/What do I change in order to be able to get the guys inside the domain to use autoconfig when setting up new mailboxes? I can setup manually now and it sticks with the config, but inside the domain it still throws the autoconfig for local Exchange…
Thanks for the help!
I’m a little confused.. Does auto-configuration works inside the internal network? (On domain joined computers) or does not?
Sorry should have expanded – problem i had was SBS kept on after 1st manual setup populating the RPC settings for the local Exchange.
Still cannot setup automatic in domain, but at least when it’s setup manually now, SBS doesn’t just go and change the settings the whole time…
What makes my situation more fun, is the fact that we are moving users one by one, manually, so whatever the solution, it cannot happen on a global scale until later when it can be made permanent…
Am I making sense?
Are you migrating into the SBS or out of it?
Out of it…
Gotcha! Then you should run the following cmdlet, it will prevent internal users from being auto configured.
Set-ClientAccessServer -Identity ServerName -AutoDiscoverServiceInternalURI $null
Thanks Ilan!, Would this affect any current users still connected to the domain Exchange while new users are being moved?
Oh.. Well yeah. Don’t run it if you have live users there. It might cause you issues.
OK, so, how do I go about it if I’m moving users in stages, want to set up autoconfig so they have it easy, and not leave the users on local Exchange in the dust?
If you will run the command clients will be forced to use the other Autodiscover methods (http,https,SRV) so if that works your are good to go. If your destination is already configured correctly I guess your fine. Do a test… and report back.
I am having the same issue as Edward Salgado (above):
Quote: “What I meant is that Outlook Anywhere does not remain enabled. First the issue was with users inside our network where Outlook Anywhere automatically enables itself. After applying your solution, it worked for our internal users. Afterwards, our remote users were experiencing the exact opposite. Outlook Anywhere would now disable automatically. When I would remote into their pc , I noticed all settings associated with Outlook Anywhere was removed. I went ahead and ran the command New-Outlookprovider -Name:EXPR which solved that issue. But now I am at square one with the problem I originally had with internal users.”
However, this is only affecting Windows 7 users! Everyone is on Outlook 2007 and the Windows XP users have no issue (any manual change to their Outlook profile sticks after your great fix). But any remote (external) user on Windows 7 has his/her “Connect to Exchange Using HTTP” box automatically unchecked once exiting Outlook and they have to re-enter the Outlook Anywhere info every time they go back into Outlook. What in Windows 7 could be causing that?
Thanks for the tip though! Worked great on all internal users and all external users on XP. Just those few Windows 7 stations….
Hi Glen,
Sorry for the delayed response… I’m aware of this “back-fire” issue with Windows 7, as far as i know the only workaround is to work with a static XML file while disabling all other HTTP / SRV methods via registry for Autodiscover. You can try to utilize this tool to pull this off.. (not tested thus) http://www.agileit.com/news/office-365-autodiscover-xml-tool-released/
I should issue a new post with Exchange 2013 in mind with regards to autodiscover / outlook anywhere, and will update this post with the XML manual workaround as well.
Good luck !
Hello,
I have 4 clients thats have different mailboxes (3 Exchange accounts, rcp over http) they al pointing to the same url. Not a problem but windows is only holds one authentication because he thinks it is the same location. Windows passwords popups two times for connection can be made. When i look in Windows (7) under Users, Referencemanager also only one user reference is saved. When i want manualy add another the old one is replaced (same url)
What we have (3 accounts same location, differentdomains).
1.exchange.com
What i want to do is (3 accounts different location, different domains).
1.exchange.com
2.exchange.com
3.exchange.com
Pointing al to the same IP, then Windows thinks it are different urls. So Windows saving al the three, i hope… 🙂
In short, i want manualy configure the other 2 exchange mailboxes with a other url (pointing to the same ip).
Running Exchange 2013 on Windows 2012, Windows 7 running Office 2010.
Thx
My problem was not the urls of the rcp. But i have 3 accounts in different ad”s with the same username. Windows remeber only one because in the password manager the urls is the same.
MS.Outlook:henk@autodiscover.domain.nl:PUT
When i make connection to a another exchange account the above will be overwritten because the user is the same.
When i make three different username’s WIndows is remember the passwords.
MS.Outlook:henk_service@autodiscover.selecsys.nl:PUT
MS.Outlook:henk_sales@autodiscover.selecsys.nl:PUT
That solved my problem 🙂
Thanks for sharing!
Hi I love reading the post on this blog.
I just dont find same as my problem of exchange 2007 sp3/Windows 2003SP2.
Owa is working fine but not activesync.
When I run get-outlookprovider I dont get any results.
So, I try to add using new-outlookprovider -name EXCH. It return an error “The parent object of EXCH cannot be found”.
After hrs of reading post and blog, I decided to reinstall the CAS role by:
1. Remove CAS role
2. Uninstall IIS
3. Reinstall IIS
4. Reinstall CAS.
Error on reinstalling CAS role.
“The parent object EXCH could not be found. Check if the outlook exists”
When I tried to see on event viewer. I saw only Error on Set with ID: 1002 which is a general error.
Any opinion or idea are welcome.
Hi James,
With ADSI – open configuration partition,
locate the Services > Microsoft Exchange > Organization > Client Access > AutoDiscover
Do you got the Outlook container there ?
Hi Illan,
No, I dont have an Outlook container. I dont have either Autodiscover.. Only Client Access
This is strange.. My OWA is working fine but not active-sync..
This is also what I get from:
[PS] C:\Documents and Settings\Administrator>Test-ActiveSyncConnectivity
| fl
ClientAccessServer : cas.somedomain.com
Scenario : Options
ScenarioDescription : To retrieve the Exchange ActiveSync protocol version,
issue an HTTP OPTIONS command.
PerformanceCounterName :
Result : Success
MailboxServer : cas.somedomain.com
StartTime : 6/26/2013 11:00:11 PM
Latency : 00:00:00.0937512
SecureAccess : True
Error :
UserName : CAS_41383e7ee5d94617
VirtualDirectoryName :
Url :
UrlType : Unknown
EventType : Success
Port : 0
ConnectionType : Plaintext
ClientAccessServer : cas.somedomain.com
Scenario : FolderSync
ScenarioDescription : Issue a FolderSync command to retrieve the folder hier
archy.
PerformanceCounterName : DirectPush Latency
Result : Failure
MailboxServer : cas.somedomain.com
StartTime : 6/26/2013 11:00:11 PM
Latency : -00:00:01
SecureAccess : True
Error : [System.Net.WebException]: The remote server returned
an error: (500) Internal Server Error.
HTTP response headers:
X-MS-RP: 1.0,2.0,2.1,2.5,12.0,12.1
MS-ASProtocolVersions: 1.0,2.0,2.1,2.5,12.0,12.1
MS-ASProtocolCommands: Sync,SendMail,SmartForward,Smar
tReply,GetAttachment,GetHierarchy,CreateCollection,Del
eteCollection,MoveCollection,FolderSync,FolderCreate,F
olderDelete,FolderUpdate,MoveItems,GetItemEstimate,Mee
tingResponse,Search,Settings,Ping,ItemOperations,Provi
sion,ResolveRecipients,ValidateCert
Content-Length: 0
Cache-Control: private
Date: Wed, 26 Jun 2013 19:00:13 GMT
Server: Microsoft-IIS/6.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
UserName : CAS_41383e7ee5d94617
VirtualDirectoryName :
Url :
UrlType : Unknown
EventType : Error
Port : 0
ConnectionType : Plaintext
I would suggest you to setup.com /prepareAD again first. Just in case.
Then I would suggest you to prepare a new server, and install it as a CAS server.
Work your way to copy/move/recreate your current certificates and see if that new server solves your issue.
Good luck!
Ok I will do that this weekend since I cannot take down the whole exchange.
I will let you know what happen.
A second side-by-side exchange won’t affect your current setup.
Neither will /prepareAD
Good luck anyway 🙂 keep me posted
Using GUI on the installation of Exchange 2003 sp3, I selected CAS role only and on the process there is a error. It is looking for the EXCH..
I will try to reinstall now with the setup.com /prepareAD..
Let you know the result.
sorry. its Exchange 2007 SP3
This problem is now resolved.
For those people that is experiencing the same problem, these are the steps below.
On the problematic Exchange server:
1. Insert Installation CD of Exchange and run setup.com /prepareAD (if it returned success go to step (2.d.) otherwise continue step 2.)
2. For me, I got an error on step 1.
a. I prepare new server with latest updates.
b. Insert installation CD for Exchange.
c. run setup.com /prepareAD (should return success)
d. run setup.com /prepareschema (should return success)
e. run setup.com /pl (should return success)
3.Going back to the problematic server. Using adsiedit, I can find now the Outlook object which I dont have before.
4. create new outlook provider EXCH, EXPR, WEB
a. new-outlookprovider -Name EXCH
b. new-outlookprovider -Name EXPR
c. new-outlookprovider -Name WEB
5. set the certprincipalname SSL using
a. Set-OutlookProvider EXCH -Server $null -CertPrincipalName msstd:extern.fqdn
b. Set-OutlookProvider EXPR -Server $null -CertPrincipalName msstd:extern.fqdn
c. Set-OutlookProvider WEB -Server $null -CertPrincipalName msstd:extern.fqdn
6. Uninstall CAS role using add/remove program
7. Uninstall IIS using add/remove windows components and restart server
8. Install IIS using Add role wizard.
9. Install RPC over HTTP proxy using add/remove windows components.
10. remove existing virtual directory so that no errors on CAS setup.
a. Remove-WebServicesVirtualDirectory -Identity “EWS (Default Web Site)” -Confirm:$false
b. Remove-ActiveSyncVirtualDirectory -Identity “Microsoft-Server-ActiveSync (Default Web Site)” -Confirm:$false
c. Remove-UMVirtualDirectory -Identity “UnifiedMessaging (Default Web Site)” -Confirm:$false
d. Remove-AutodiscoverVirtualDirectory -Identity “Autodiscover (Default Web Site)” -Confirm:$false
FYI: On successful CAS setup, those virtual directories will be created automatically.
11. Install CAS role using add/remove program (click change and select client access role)
12. install SSL certificate, your internal and external url of other services that is enabled (example activesync,etc)
and viola problem solve. All are working now using test-outlookwebservices
I cannot thank you enough Ilan Lanz for pointing me to the right direction. I was almost bald pulling my hair for the couple of days, reading all google search blogs, microsoft site, manuals, etc)
More power to your blog…
Thanks for the update James! I was happy to help and glad to hear that you solved your issue.
Best regards!
Great post!!
Thank you Ilan
You’re welcome!
any idea why were are getting an outlook hourglass on local copies of OL 2007 to Exchange 2007. Balloon box comes up saying “Outlook is trying to reach Exchange Server Domain1”. domain1 is the PDC. MS Tech Support incident opened and closed: they could not figure it out. 1 gig network. delay happens trying to access the GAL or clicking To: or Reply To: buttons (GAL lookups)
Well George, most cases I’ve handled this specific description were related to FW being in between clients and servers.
the trigger for the popup is either a slow RPC response or a timeout with TCP.
Try to configure exchange with static ports http://support.microsoft.com/kb/270836 and make sure you pay extra attention to session timeout for those specific ports.
You can read more about this topic in another post I’ve written –
ilantz
Hi Ilan,
This is a great blog.
I have an interesting question for you 🙂
We are getting ready to move to Exchange 2010 but are not ready yet! We are deploying Outlook 2010 to our users as part of Office 2010 as a prelim and are currently using Exchange 2003.
We have a set of users that have mandatory profiles set on the network and we used a prf file to configure the Outlook profile each time the user logs on.
Now we have Outlook 2010 this does not work. I believe this is due to Outlook 2010 using Autodiscover whcih obviously doe not work as we only have Exchange 2003.
Can I use the prf file to stop the Autodiscover from running?
Many thanks for any suggestions.
Rob
Hi Rob,
You can still use PRF files with Outlook 2010. Just use the setup /admin on an 2010 install and create an updated PRF.
To stop the Autodiscover from reverting the PRF configuration – and I guess you mean that you need specific mailboxes instead if the actual logged-on users’ mailbox – just configure the ExcludeSCPLookup – follow http://support.microsoft.com/kb/2212902 and you should be good.
Let me know if this solves your issue.
ilantz
Hi ilantz,
Thanks for the info and the link.
I have tried this and what I get is Outlook opens and reads the prf file.
However the outlook screen to enter exchange server and username pops up.
This has the FQDN of the configuration container for our exchange server listed in the server box such as 0u=domain, ou=configuration, etc. This does have the correct exchange server listed but as the configuration container does not exist on our domain it fails. If I manually take out all but the netbios name of the exchange server then it works fine. It has the correct username in the username field.
I can’t seem to find a way to stop this trying to look for the autoconfiguration path.
Rob
Have you tried a “clean” fresh install of Office ?
Sounds like you are bound to a customized office install aka the office maintenance tool.
ilantz
We have used a customized office install as this is done via our deployment tool.
I could not find any options in there to alter the way Outlook finds the Exchnage server.
I will have another look.
Rob
Hi Ilantz
Here is my scenario
a) OA enabled
b) Can’t remove the provider
c) Can configure GPO to disable HTTP settings in Outlook Profile
and still want Outlook settings not affected
Would that work?
Hi Sid, which outlook settings exactly you want intact?
If the provider is enabled information will be received and updated.
You can however work with ExcludeScpLookup and the others and create a static XML file with all your settings.
Hope this helps,
Ilantz
Hi ilantz,
Please help me with the following:
We use TMG 2010 to publish exchange.
Cas servers are set to NTLM, because TMG needs NTLM on the backend.
However TMG uses Basic on the frontend, to create as much compatibility as possible.
Were facing the fact that Autodiscover is setting the profile back to NTLM.
But this is correct. because the internaluri are set to cas, and thats set to NTLM.
If i remove the URL, autodiscover breaks and that resolves the issue of the authentication changes.
If i set autodiscover to point to TMG it will prompt passwords for each time the discovery runs.
I am thinking about removing the EXPR entry. But i am not sure on what other options i have, we are planning to migrate to 2013 in the next year.
What are my options in your opinion. Thanks
Michell
Hi Michell,
As far as my experience goes I choose basic on TMG for all virtual directories including outlook anywhere unless a good reason exists…
Removing the EXPR setting especially if you’re looking on exchange 2013 is not the way to go.
Ilantz
Hi Ilantz,
Thank you, you`re fast in replying 🙂
This was my though also, either set it to NTLM or set it to Basic all the way.
This will always break if you set it up like this.
Glad to help 🙂 good luck!
Don’t try this in production. I tried in a test environment and if you have to roll back the settings using new-outlookprovider -name expr, it does not revert it to original settings. This is very risky
Hi Darren, I did stated that this is “at your own risk…” sorry if you’ve missed that.
Does this modification affects autoconfiguration of Outlook 2007 clients? What is the impact of this modification in production?
Regards
Hi John,
This affects the result by removing the EXPR part from the XML data, following my last updates on the subject ( see the post ) I tend to recommend not to perform this nowadays – looking forward with exchange 2013..
Ilantz
Thanks for this. Saved me a lot of trouble!
I have removed EXPR but now whenever the proxy is enabled it is unchecked within a minute of starting outlook. So set the proxy and settings, restart outlook, connect, go back into settings and the proxy is unchecked. This makes any new restart of outlook not be able to connect. I’m at a loss.
Hi Robert,
This is “normal” because removing the EXPR results in removing that whole section from Autodiscover’s XML response, hence the constant removal of the Outlook Anywhere settings.
A while after this article was first published some changes in the Outlook clients were applied that caused the settings to be removed even if you statically configured them.
If you want only specific users to be able to use Outlook Anywhere while others don’t i would advice considering the
Set-CasMailbox -MAPIBlockOutlookRpcHttp:$truecmdlet to allow/block specific users.The other way will be to fully adopt Autodiscover and Outlook Anywhere Internally and Externally, as this is the method for Exchange 2013 and will probably be the better approach here.
see also the “official recommendation” here – http://blogs.technet.com/b/exchange/archive/2013/05/23/ambiguous-urls-and-their-effect-on-exchange-2010-to-exchange-2013-migrations.aspx
hope this helps you out.
ilantz
Thank you Ilan. We have switched back to EXPR and group policy excluding the proxy settings for domain members.
Awesome. Thanks for the feedback!
I reverted this original change with New-OutlookProvider -Name:EXPR which works fine but now I notice authentication always seems to be set as “Basic Autehntication” shouldnt it be NTLM by default and if so any idea what I might need to fix to set it to be NTLM for the SBS domain?
Hi Robert,
It is actually turned off by default in out of the box Exchange deployments, but to set to NTLM just run the following:
Set-OutlookAnywhere -Identity:CAS01\Rpc (Default Web Site) -ClientAuthenticationMethod:Ntlm
We have an Exchange 2013 single server that services internal and external clients. We had to renew the SSL cert and with the new cert could not have any “local” SANs. I reconfigured the AutoDiscoverServiceInternalUri, EWS (Default Web Site)” -InternalUrl , and changed the URL for the OAB. I set them to the name on the certificate and can ping it from inside. All the internal clients get an error “Problem with the proxy server’s security certificate. The name on the security certificate is invalid or does not match. (Error code 10).
Any suggestions??
How about the get-outlookanywhere / set-outlookanywhere commands?
Work your way with the test autoconfiguration windows within your outlook client to troubleshoot the autodiscover urls you get to see what you’ve missed.
Ilantz
It is all set correctly. And the Autodiscover test on Outlook all the autodiscover urls are correct with no errors. Yet the Microsoft Proxy settings are still pointing to exchange.domain.local. Is there any way to clear that? When we change it manually it reverts back to the incorrect settings.
How about the get-outlookproviders results?
Here are the results;
Name Server CertPrincipalName TTL
—- —— —————– —
EXCH msstd:mail.domain.com 1
EXPR msstd:mail.domain.com 1
WEB 1
Looks okay I guess. Try this post I’ve wrote and see if you’ve missed anything http://ilantz.com/2013/06/29/exchange-2013-outlook-anywhere-considerations/
Well maybe I was just impatient, it seems as though the clients needed to refresh overnight.
Waiting 5 or 6 hours wasn’t long enough. In checking the clients this morning they are all coming up with no errors. I thought I read that Outlook refreshed every 5 minutes.
The problem seems to have disappeared.
Thanks for the update 🙂 good to hear it works
Exchange 2010 SP1 doesn’t have this command remove-outlookprovider. So what to do if not upgrading to sp2?
Hi Cliff,
That command was present also with Exchange 2007… if you do miss that command – make sure that you have the Organization Management Role assigned to you. this might be an RBAC issue…
ilantz
I have an interesting one, if you could assist….
Exchange version is 2010, SP3 RU10. 3 CAS Servers in an array, going through F5 load balancer. Databases are in a 1 DAG configuration. Overall Exchange health is good.
We have sporadic internal Outlook 2010 clients connecting via HTTPS instead of TCP, when the option “On slow connections, use http first..” is checked in Outlook. I can reproduce this issue on my machine easily. When I have the option “on FAST connections, connect via https first…” it connects via TCP. When all options are unchecked, it connects via TCP.
However, my test virtual machine with the same Outlook 2010 client, and same “on slow networks…” option checked, ALWAYS connects via TCP first. I can get my TEST client o connect via HTTPS only when the option “on FAST networks, connect via http first…” is checked.
At first I would think Outlook is somehow seeing the network as slow and connecting via HTTPS…however, we have a 100Mbps link. So speed isn’t a factor.
Why would outlook attempt HTTPS first for internal clients as opposed to TCP? We’ve tried to create a new VIP on F5, but the results are the same.
Any help is appreciated. BTW…Outlook 2013 clients work just fine, connecting via TCP on the local LAN.
You should work with a network sniffer to troubleshoot this.
The whole point of the “on slow” is just to make outlook try first TCP, if that fails it will try the http proxy.
Make sure that the client can reach the exchange CAS with TCP 135, followed by the RPC dynamic port range. You should be able to trace this with a sniffer.
Ilantz
Hi Ilan,
great blog.
For migrations from Exchange 2007 who do not have outlook anywhere enabled on 2007 – do you recommend enabling that prior to introducing Exchange 2013?
How does the migration process handle it when OA is not enabled on 2007 but (obviously) is enabled on 2013?
cheers
dave
Hi Dave, thanks 🙂
I’ve actually wrote about that in a newer post regarding 2013, http://ilantz.com/2013/06/29/exchange-2013-outlook-anywhere-considerations/
Definitely – do enable outlook anywhere before.
Let me know if you have any follow ups on that matter.
Ilan
thank you for sharing. This is definitely going to help me.
This really worked for me on my old system. Thanks man