All outlook clients can't connect to exchange

Hi all,

I spent the weekend fixing some major IIS issues and Exhange OWA issues for a client.  They had removed IIS compeltely from the server, and I re set it up and made sure OWA was working for all users.  EMC and EMS at one point wouldn't connect to the (local) SBS server.  All that has been resolved.  OWA is working 100%.

What the issue is right now, is none of the outlook clients are working.  Setting them up resolves the local server instantly, but when they try to load I get prompted for the local account credentials.  Tried running different profiles, different users, etc.  Tried resetting permissions and passwords.  I get "Cannot start Microsoft....You do not have permission to log on".

Let me know if you need more details!
LVL 2
browningitSysadminAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jasvindar SinghOffice 365 AdministratorCommented:
In Exchange 2010, all kind of Client request - OWA, ActiveSync, Outlook Anywhere and Outlook inside the domain is processed by IIS on the server.

As you mentioned that you re-installed IIS, which means RPC virtual directory would be missing from IIS.

Because RPC virtual directory is not present by default when we install Exchange Server.

To resolve the issue,

a. Go to Server manager => Features => Install RPC over HTTP proxy feature.

Post it is installed, you should be able to view RPC virtual directory in IIS, make sure Basic Authentication is set for it.

b. Now make sure, in EMC => Server Configuration => Client Access => Server Name => Properties => Outlook  Anywhere tab => Outlook anywhere is enabled.

For External Host Name: mail.domain.com (basically your OWA URL) and authentication should be BASIC.

c. Services.msc => Restart "Microsoft Exchange Service Host" service.

Post performing above steps, https://testconnectivity.microsoft.com/ => Exchange Server tab => Outlook Connectivity test => Provide credential of any of the user => And make sure "Use Autodiscover to detect server settings" radio button is checked.

If the above test passes then we are good to go.
0
browningitSysadminAuthor Commented:
RPC HTTP was installed over the weekend, I verified it just not it's already in the feature list.

EMC shows OA is enabled, security is set properly to your notes.

Rebooted the service for fun, tried again, no love.

My connectivity tests are as follows:

"e Microsoft Connectivity Analyzer is testing Exchange ActiveSync.
 	The Exchange ActiveSync test failed.
 	
	Additional Details
 	
Elapsed Time: 6564 ms.
 	
	Test Steps
 	
	Attempting the Autodiscover and Exchange ActiveSync test (if requested).
 	Testing of Autodiscover for Exchange ActiveSync failed.
 	
	Additional Details
 	
	Test Steps
 	
	Attempting each method of contacting the Autodiscover service.
 	The Autodiscover service couldn't be contacted successfully by any method.
 	
	Additional Details
 	
	Test Steps
 	
	Attempting to test potential Autodiscover URL https://:443/Autodiscover/Autodiscover.xml
 	Testing of this potential Autodiscover URL failed.
 	
	Additional Details
 	
	Test Steps
 	
	Attempting to resolve the host name  in DNS.
 	The host name resolved successfully.
 	
	Additional Details
	Testing TCP port 443 on host mydomain.com to ensure it's listening and open.
 	The port was opened successfully.
 	
	Additional Details
	Testing the SSL certificate to make sure it's valid.
 	The SSL certificate failed one or more certificate validation checks.
 	
	Additional Details
 	
	Test Steps
	Attempting to test potential Autodiscover URL https://autodiscover.r:443/Autodiscover/Autodiscover.xml
 	Testing of this potential Autodiscover URL failed.
 	
	Additional Details
 	
	Test Steps
 	
	Attempting to resolve the host name autodiscover..com in DNS.
 	The host name resolved successfully.
 	
	Additional Details
	Testing TCP port 443 on host autodiscover..com to ensure it's listening and open.
 	The specified port is either blocked, not listening, or not producing the expected response.
 	 Tell me more about this issue and how to resolve it
 	
	Additional Details
 	
A network error occurred while communicating with the remote host.
Elapsed Time: 27 ms.
	Attempting to contact the Autodiscover service using the HTTP redirect method.
 	The attempt to contact Autodiscover using the HTTP Redirect method failed.
 	
	Additional Details
 	
	Test Steps
 	
	Attempting to resolve the host name autodiscover..com in DNS.
 	The host name resolved successfully.
 	
	Additional Details
	Testing TCP port 80 on host autodiscover..com to ensure it's listening and open.
 	The specified port is either blocked, not listening, or not producing the expected response.
 	 Tell me more about this issue and how to resolve it
 	
	Additional Details
	Attempting to contact the Autodiscover service using the DNS SRV redirect method.
 	The Microsoft Connectivity Analyzer failed to contact the Autodiscover service using the DNS SRV redirect method.
 	
	Additional Details
 	
	Test Steps
 	
	Attempting to locate SRV record _autodiscover._tcp.in DNS.
 	The Autodiscover SRV record wasn't found in DNS.
 	 Tell me more about this issue and how to resolve it
 	
	Additional Details
 	
Elapsed Time: 97 ms."

Open in new window


While not running perfectly, I don't see why it would cause local issues in that case, but not OWA issues.  Just to reiterate, OWA is 100%.  That's the part that is baffling (and I haven't looked at the connectivity test yet at this point, this is news to me that some parts are failing).  Ideas on what to trudge forward with?
0
Jasvindar SinghOffice 365 AdministratorCommented:
Thanks for providing test result, it shows that it tried even looking SRV record for Autodiscover. Means lookup for Autodiscover A record failed and then it fall back to SRV.

If you have, UCC certificate or wild card certificate containing entry for "autodiscover.domain.com" then make sure => We have DNS => Host A record "autodiscover.domain.com" pointing to IP Address of your SBS server.

If its single Name certificate containing only OWA URL then,
Need to create SRV record for Autodiscover.

2.Use the following parameters to create a new SRV record:

http://support.microsoft.com/kb/940881
Service: _autodiscover
Protocol: _tcp
Port Number: 443
Host: mail.contoso.com
0
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

browningitSysadminAuthor Commented:
Created a new SRV record, which was missing in the DNS on the local server.  Still have the same failures in the test connectivity for SRV record.  Restarted the services.  Restarted IIS.  Check client outlook, issue persistent.

Any other ideas?
0
browningitSysadminAuthor Commented:
Just noted that when I ran Get-CAS internaluri I returned a null result, so I am checking that their mail server is configured correctly with some of these commands:

http://mshiyas.wordpress.com/2010/07/06/how-to-configure-and-verify-autodiscover-for-exchange-2007-and-2010/

If you have other ideas I should track down outside of this, let m eknow,
0
browningitSysadminAuthor Commented:
I just now removed the autodiscovervirtualdirectory, readded it.  That ran fine.  I then run:

Set-ClientAccessServer -Identity SERVERNAME -AutodiscoverServiceInternalURi https://servername.domain.local/autodiscover/autodiscover.xml

And then run a get command:

Get-ClientAccessServer | fl name,autodiscoverserviceinternaluri

That comes back with an answer of:

Name: SERVERNAME

And nothing else.  What am I missing?
0
browningitSysadminAuthor Commented:
In fact, if I run:

Get-AutodiscoverVirtualDirectory "SERVERNAME\*" | fl

It shows nothing on the internal or external URL.  Why?!?  I've told it to set each, but it's not listening.
0
browningitSysadminAuthor Commented:
But then I found this command:

Get-ClientAccessServer casserver1 | fl *InternalUri*

Which displays the proper location. So now I am back at square one.  Help!
0
browningitSysadminAuthor Commented:
I've set up an outlook profile this time around using the IP of the serve rinstead of the FQDN.  On saving and exiting, I now get "cannot start microsoft outlook cannot open the outlook window the set of folders cannot be opened microsoft exchange is not available. either there are network problems or the exchange server is down for maintenance"

I ran and nslookup on a client computer internally, and they still return the external IP for autodiscover.domain.com

Ideas?
0
Gareth GudgerCommented:
Hey BrowningIT,

I just checked your URL [ you missed one ;) ] and it looks like the certificate is a self-signed certificate. This will not work. You need to either switch to an SSL cert (can do this if you have an SRV record in place) or, a UCC/SAN certificate if you plan to use autodiscover.yourdomain.com.

Certificates and install guides for Exchange
http://supertekboy.com/certificates-for-microsoft-exchange/

You may also wish to review this article. It discusses everything from certificates, to configuring your Exchange URLs to configuring split-brain DNS for a simple namespace design in 2010.
http://supertekboy.com/2014/05/27/designing-a-simple-name-space-for-exchange-2010/
0
browningitSysadminAuthor Commented:
Thanks Gareth, after I looked at the (sorry) state of affairs at the SSL side - since up to this point I had not needed to review it I noted that it was a complete mess of self signed in there.  I'm going to have their IT general support resolve it since that's the easy bit.

However, for today's magical issues, it wasn't the case.  I'm going to edit this comment tomorrow morning with the full solution I followed, including the above research and drilling I did.

Short story:  RPC Client Access service was the last step that fixed it - reason?  Who it was logging on as.  I noted a discrepancy between all my happy other client servers compared to my new clients one.  Theirs was using a local system account and not the Network Service account.  Changed that, rebooted the services for Exchange and magic.

Details to come.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Gareth GudgerCommented:
Glad you got it resolved. Yep. I was just going through your EXRCA report for earlier and noticed the SSL was wrong.
0
browningitSysadminAuthor Commented:
Noted a misconfigured item in the services on my own, outside of what was being discussed.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.