Solved

Disable SBS 2008 Outlook Autodiscovery

Posted on 2009-07-16
28
12,426 Views
Last Modified: 2013-04-16
We have SBS 2008 deployed and functional.  We are migrating to a Hosted Exchange environment and would like to eventually get rid of the SBS box.  Luckily the migration process can be done a few users at a time and we don't have to pull the plug on everyone at once.  We already have 2 users setup on the Hosted Exchange and everyone else is still on the internal SBS Exchange.  (The users who have been migrated have their mail forwarded to their new Hosting account so internal mail still gets sent/received like it needs to.)  This partial migration brings me to my problem.  

SBS 2008 automatically configures domain accounts' Outlook client for them.  Although I can change that configuration manually, it tries to "fix itself" every time the user opens Outlook.  Outside of the domain network things are fine.  We have a service record in our DNS pointing to the new Hosted Exchange and the autodiscovery actually works really well from the outside.  But inside the domain the user gets an authentication request every couple of minutes from Outlook trying to talk to the SBS machine and reconfigure Outlook.  As long as the user knows to ignore these messages their mail continues to work, but if they authenticate even once, the SBS does its job and Outlook gets reconfigured for the SBS, their OST cache changes, things re-sync, and I have to go back and fix them all over again.  

So here's the question... how can we disable (even temporarily until everyone gets changed over) the autodiscovery on the SBS machine so that users keep their manual configuration?  I'm not sure where SBS 2008 stores its settings for the autodiscovery and I want to make sure that changing it doesn't mess with any other SBS functionality.  I know that changing settings outside of the SBS Wizard interfaces can cause problems (like changing your IP without using the wizard... etc...) so I want to make sure that it is the "recommended" procedure for SBS, not just Exchange 2007 in general.  If you need any more information just ask.  I have full domain admin access to both the Hosted Exchange account and the SBS 2008.  Thanks!
0
Comment
Question by:lvcg
  • 11
  • 8
  • 6
  • +2
28 Comments
 
LVL 76

Expert Comment

by:Alan Hardisty
ID: 24870641
You need to setup autodiscover.yourdomain.com in DNS to break it and point this either to your new host, or somewhere completely random.
Please refer to this previous EE question:
http://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/Q_24279248.html
0
 

Author Comment

by:lvcg
ID: 24870734
Thanks for the quick response.  As I said, there is already an external DNS record pointing to our Hosted Exchange.  (autodiscover.mydomain.com)  It's while the user is inside the local domain network that the problem occurs.  It is something locally on the SBS, not on the public DNS.  
0
 
LVL 65

Expert Comment

by:Mestha
ID: 24871198
I don't think you can.
Outlook will look first at the AD domain for Exchange information. If it matches then that is far as it will go. The only way I can think of is to put the machines in to a workgroup or another domain and ensure that autodiscover.example.com resolves internally to the external IP address.

Simon.
0
 

Author Comment

by:lvcg
ID: 24873468
Thanks.  We can't put them in a workgroup.  They are domain managed machines.  We will eventually be moving all of our machines to hosted Exchange and they need to remain on the domain.  
0
 
LVL 65

Expert Comment

by:Mestha
ID: 24873578
I did read your question, and understood that you are moving to a hosted Exchange system. A waste of an SBS 2008 licence if you ask me, but there you go.

You are going to have to remove SBS. SBS is designed to work in one way, and that is SBS doing everything for you. The only way to stop that is to remove all SBS functionality and move to full product to maintain the domain. That will need to be a new domain that isn't Exchange aware.

Simon.
0
 

Author Comment

by:lvcg
ID: 24873729
We have Action Pack and this is our own internal domain so purchasing an unneeded SBS license isn't an issue.  It was more a matter of functionality.  SBS provided us what we needed at the time, but hosted Exchange makes more sense for our current situation.  The eventual plan is to move to a standalone Windows Server Standard as the PDC and just use it for AD and File Sharing primarily (Or to remove SBS from the current server, as you said...).  We will move these machines out of the domain at that point and put them in the new domain.  We will pretty much be following your above recommendations, but not for a while.  Finishing the migration is just a little way off and I was hoping for a solution in the interim.  There is a transition process getting everyone onto the Hosted Exchange.  I have read about how to remove the Autodiscover Service Virtual Directory in Exchange 2007, but that is for the standalone product.  I'm not so sure about making changes outside of the SBS scope and didn't want to cause ripples with other parts of SBS.  Thanks for all of the great input.
0
 
LVL 65

Expert Comment

by:Mestha
ID: 24873775
Removing the Autodiscover directly will not the stop the process.
Internally, when Outlook can see the AD, it gets its information from there. It doesn't use the Autodiscover web based system at all.

The only way, as I have said, is to remove Exchange and all traces of it. Until you do, Outlook will attempt to use your local Exchange 2007 server, because that is what it is designed to do.

Simon.
0
 
LVL 76

Assisted Solution

by:Alan Hardisty
Alan Hardisty earned 100 total points
ID: 24873814
Here is part of the AutoDiscover White Paper that describes what happens on the client:
http://technet.microsoft.com/en-us/library/bb332063.aspx#HowTheADSWorks
0
 

Author Comment

by:lvcg
ID: 24873950
Wow, I'm learning a lot about autodiscover.  This is good.  I guess what I'm trying to find out is if there is a way to remove or change the ADS information in Active Direcory, since that is where it is stored on the local domain level.  Could I point it to a nonexistent client access server so it isn't pulling in the old info?  Or can I disable the virtual directory within IIS where the XML data is stored so that the Outlook Client doesn't get what it is looking for?
0
 
LVL 65

Expert Comment

by:Mestha
ID: 24874065
There is no way of removing, disabling or whatever autodiscover, either Exchange or Outlook side. Your ONLY option is the complete removal of Exchange. How many more times do I need to say that?

As I have already said, internally Outlook doesn't get the information from the autodisocver virtual directory, it comes out of the domain. However it does connect to the autodiscover virtual directory as part of the availability service.

Run the autoconfig test (hold down CTRL while right clicking on the Outlook icon in the system tray). You will see no reference to autodiscover under the RPC configuration.

Simon.
0
 

Author Comment

by:lvcg
ID: 24874082
It looks like I may have found my answer.  

I opened IIS looking for the autodiscover virtual directory.  Under the Application Pools I found the MSExchangeAutodiscoverAppPool and stopped it.  The Outlook client is no longer picking up its configuration information from the internal server.  Can any one of you think of another reason why this Application Pool needs to be running?
0
 
LVL 76

Expert Comment

by:Alan Hardisty
ID: 24874161
I don't know Exchange 2007 (SBS 2008) that intimately enough to comment - I guess time will tell.
0
 

Author Comment

by:lvcg
ID: 24874173
After running the "Test Email Autoconfiguration" with the Autodiscover app pool stopped, I only get the public DNS information for our new Hosted Exchange.  It appears that stopping it prevents Outlook from picking up its configuration information from the local domain, so it goes to the next option (the public DNS for autodiscover.mydomain.com) and pullis its information from there.  I will continue to run it like this and keep an eye on it to find out if there are any adverse "side effects" of stopping the app pool.  I'll keep you all posted.  
0
 
LVL 76

Expert Comment

by:Alan Hardisty
ID: 24874189
Would be interested to see if all goes well.  I have seen lots of questions about this on the web with no real answers (yet).
Fingers crossed.
0
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 

Author Comment

by:lvcg
ID: 24874198
Yeah, wouldn't that be a great find to have "stumbled" on...  Fingers crossed here too...
0
 
LVL 76

Expert Comment

by:Alan Hardisty
ID: 24874215
Oh yes - that would be a great find indeed.
0
 

Accepted Solution

by:
lvcg earned 0 total points
ID: 24879290
Ok, here's a summary of what I've found so far:

By opening IIS on the SBS and stopping the MSExchangeAutodiscoverAppPool I have prevented Outlook from picking up its autodiscover settings from the SBS.  

We have a public DNS record for autodiscover.mydomain.com pointing to our Hosted Exchange provider.  Clients now see the public DNS record and update using the Hosted Exchange settings.  

Just for kicks, If I remove both the public DNS record and stop the AppPool, the Outlook client will see the autodetect service on the SBS and attempt to update, but will fail the autodetect process.  So even though you get a request to update using that server, the update does not return any information and the Outlook configuration remains unchanged.  

As far as I can tell there are no adverse effects of disabling the MSExchangeAutodiscoverAppPool.  It has been stopped all day and clients with both configurations are still receiving mail as expected.  All other SBS functionality seems to be operational as well.  

This is a perfect solution for what I was trying to accomplish.  I can make a manual change to an Outlook client configuration and it will remain that way as long as I want it to.  Now I have control of which source the Outlook client gets its information from.  
1
 
LVL 76

Expert Comment

by:Alan Hardisty
ID: 24879304
Sounds good - let's hope it stays that way.  Hope that the White paper helped.
Alan
0
 

Author Comment

by:lvcg
ID: 24879482
Yes, it did.  It got me pointed in the right direction, anyway.  It helps to have a roadmap of how the autodiscover process flows.  I had very little understanding about how autodiscover works until I had to make it NOT work.  ;)  Sources like that are always good information.  Thanks.  
0
 
LVL 65

Expert Comment

by:Mestha
ID: 24883731
For anyone else who reads this question - if you follow the above then you basically break all of the Exchange web features, not just autodiscover. It breaks OWA, EAS, Outlook Anywhere etc.
This is NOT a solution to stop autodiscover from working where you want Exchange to be fully operational.

Simon.
0
 

Author Comment

by:lvcg
ID: 24884442
Simon,
I beg to differ.  I am logged into OWA currently and my colleagues are logged into Outlook Anywhere and using Active Sync wirelessly on their Windows Mobile based PDAs.  All features are working perfectly... WITH the AppPool stopped.  The only thing not working is Autodiscover, which is what I was going for.  The other IIS applications are running and funcioning normally.  

Have you tried this personally to verify that those services you listed don't work?  I can speak from experience that things are working normally.  Suggestions and information are good, flaming and trolling are not.  Your comments are not apreciated.  If I find something not working properly I will be sure to post it, but as of now things ARE working normally.  
0
 
LVL 27

Expert Comment

by:shauncroucher
ID: 24885180
Hi Ivcg

I've been following this post with Interest. Whilst I have read that stopping the AppPool Virtual Directory may have achieved the sort of behaviour you desire, the behaviour is nonetheless behaviour caused by a fault. The fault is that the Virtual Directory with the information it requires is not running, when in a normal operating environment this virtual directory should be running.

Of course it may work fine like that forever in your environment, but I would second what Simon is saying. This is not really an appropriate way of controlling an Exchange feature. What happens when the next service pack comes out and re-enables the directory for others to follow. What happens when the next update fails continuously because it finds the virtual directory stopped when it should be started? In a years time, exchange release a popular feature that relys on the functionality that in this environment is unusually not available.

So in summary, in your environment I guess you can intimately manage any fall out, and it may do what you require, but I don't think it should be followed by others looking for the same thing.

Shaun
0
 
LVL 76

Expert Comment

by:Alan Hardisty
ID: 24885202
If you refer to the original question it states "We are migrating to a Hosted Exchange environment and would like to eventually get rid of the SBS box" and "how can we disable (even temporarily until everyone gets changed over) the autodiscovery on the SBS machine "
There was never the suggestion that this was going to be a permanent solution and this thread should be read with this in mind and not referred to as a suitable solution for others to follow to disable AutoDiscovery unless they wish to do exactly the same and only do it as a temporary measure whilst migrating or for a similar reasons.
0
 
LVL 27

Expert Comment

by:shauncroucher
ID: 24885214
Yes, this is probably acceptable for a very temporary solution.

The reason I wanted to reiterate what Simon has said is because there are a lot of people that come in from a google search, and don't read questions and answers carefully, just quickly scan to the solution and replicate.

Shaun
0
 
LVL 65

Expert Comment

by:Mestha
ID: 24885650
It isn't what I have seen myself - I asked Microsoft. There are perks to be an MVP. ;-)

The only reason I can think it is still working is because the server hasn't been cycled. If you restart the server I would expect things to start to break. Lots of the Exchange functionality is inter-linked, so while it is in its own app-pool there may be a connection to something elsewhere in Exchange.
When you start fiddling around with the guts of Exchange, like app pools in IIS or permissions, a small change can have significant consequences.

Simon.
0
 
LVL 76

Expert Comment

by:Alan Hardisty
ID: 24885824
Would everyone be happier if this question got deleted because of the problems that following this thread might pose?
I am happy to do whatever the majority think and I am leaning towards removing it for safety's sake.  LVCQ has a workaround that might go wrong after a reboot, but he knows how to resolve it again by re-enabling the Application Pool, rebooting and then disabling it again, so we are all a little wiser for the questions and will no doubt be able to answer similar questions from a better grounding next time.
Thoughts please.
Alan
0
 

Author Comment

by:lvcg
ID: 24886149
Yes, as has been said, this was primarily intended as a temporary solution until we can finish the migration.  I just wanted to mke sure that clients didnt revert back to their original configuration.  I won't be keeping the SBS in this state for long.

I also see where you are coming from in terms of a permanent solution.  This was never intended as one.  I'd hate for someone to follow the thread and end up having problems like the ones you are describing.  

Mestha:  sorry about the trolling comment.  I see where you are coming from.  This is not a recommended solution under normal circumstances.  

I can see the reason in making sure that future readers don't assume it to be one and cause other problems with Exchange.  This really is a very specific scenario with a specific reason for what was done.  I'm open to whatever the community thinks.  I've got what I was hoping for.  Thanks for all of the good input and direction on this as I worked through it.  
0
 

Expert Comment

by:bjor12
ID: 36009093
Hi, can Outlook autodicovery be disabled by policy?

We have a similar case were som domain users will be migrated to an external exchange. Every time the user restarts his PC, and starts Outook, the domain Exchange settings are reinserted and manual settings in outlook overrided. I cannot find any policy responsible of this, thus my only logical explanation must be that Autodiscover is making this problem appear.

Any comments on this ?

Regards,
B.
0

Featured Post

Promote certifications in your email signature

Has your company recently won an award or achieved a certification? They'll no doubt want to show it off. Email signature images used to promote certifications & awards can instantly establish credibility with a recipient and provide you with numerous benefits.

Join & Write a Comment

We are happy to announce a brand new addition to our line of acclaimed email signature management products – CodeTwo Email Signatures for Office 365.
Follow this checklist to learn more about the 15 things you should never include in an email signature from personal quotes, animated gifs and out-of-date marketing content.
This tutorial will give a an overview on how to deploy remote agents in Backup Exec 2012 to new servers. Click on the Backup Exec button in the upper left corner. From here, are global settings for the application such as connecting to a remote Back…
This tutorial will walk an individual through the steps necessary to configure their installation of BackupExec 2012 to use network shared disk space. Verify that the path to the shared storage is valid and that data can be written to that location:…

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now