Exchange 2010 activesync broke

We are starting to have sync issues with some phones, mainly iPhone and ran the sync test and got these results.

Anyone dealt with this and know where to start?
Exchange-activesync-broke.png
Exchange-activesync-broke-2.png
LVL 1
HaroldNetwork EngineerAsked:
Who is Participating?
 
Alan HardistyCo-OwnerCommented:
0
 
Alan HardistyCo-OwnerCommented:
You currently have mail.domain.com pointing to IP Address 209.xxx.xxx.41 but you have autodiscover.domain.com pointing to IP 209.xxx.xxx.42.

Your SSL certificate only includes mail.domain.com not autodiscover.com so if you are using an A record for autodiscover you need to change that to a CNAME record and point that to mail.domain.com and make sure your exchange URL's point to mail.domain.com not autodiscover.domain.com.

Alan
0
 
HaroldNetwork EngineerAuthor Commented:
Alan: these DNS settings with our registrar where the domain name sites or internal DNS. I don't see any autodiscover configured internally. Exchange URLs are set where?
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
Simon Butler (Sembee)ConsultantCommented:
Internal DNS doesn't matter - it is external DNS that is the source of the problems here, so have to be resolved at your DNS host.

You can set internal DNS records, and I would encourage you to do so, particularly if you have a wireless network the mobile devices connect to.
http://semb.ee/hostnames2010

Simon.
0
 
HaroldNetwork EngineerAuthor Commented:
Looking at our receiver connector noticed we had only private IPs for remote servers, this correct? We're sending and receiving mail, so it's not broke, just logically doesn't look right.
Exchange-connector-config.png
0
 
Alan HardistyCo-OwnerCommented:
Whatever you have in your Receive Connector isn't related to the Activesync question, so if you are having separate issues with receiving emails, you should open up a separate question  to troubleshoot that as troubleshooting anything non Activesync related in this question is only going to confuse the question / solution.

Alan
0
 
HaroldNetwork EngineerAuthor Commented:
Sorry, went through all the settings per Simones link, which got me looking at that. Now I'm waiting on someone to give me access to DNS configs.
0
 
Alan HardistyCo-OwnerCommented:
No problems - just helps to focus on a single problem in a question rather than venture down different paths as it can get very confusing for all concerned.
0
 
HaroldNetwork EngineerAuthor Commented:
ok...added autodiscover.domain.com CNAME and pointed to the mail server.

C:\Users\hdoolittle>nslookup autodiscover.domain.com 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    mail.domain.com
Address:  209.xxx.xxx.42
Aliases:  autodiscover.domain.com

correct?  they both resolve to .42
0
 
Alan HardistyCo-OwnerCommented:
I would expect they should point to the .41 IP address as that is where your OWA resolves to and thus your Exchange server.

The autodiscover CNAME record should point to mail.domain.com

Alan
0
 
HaroldNetwork EngineerAuthor Commented:
DNS...
mail server is pointing to .42
SMTP points to                   .41

so should CNAME point to SMTP?

autodiscover.domain.com doesn't exist in DNS currently...not sure how it comes in.

How did you test mail.steelnetwork.com/owa

C:\Users\hdoolittle>nslookup mail.domain.com 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    mail.domain.com
Address:  209.xxx.xxx.42


C:\Users\hdoolittle>nslookup smtp.steelnetwork.com 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    smtp.domain.com
Address:  209.xxx.xxx.41
0
 
Alan HardistyCo-OwnerCommented:
Sorry - just re-checked and I got your IP's the wrong way around!!  They should both point to the .42 IP Address.

If they are now - then please re-test on the test site and report back.

Alan
0
 
HaroldNetwork EngineerAuthor Commented:
No go, added the users profile to my phone, which is a Droid and it will not authenticate there nor the iPhone.

Still failing Microsoft sync test too.
0
 
Alan HardistyCo-OwnerCommented:
I tested OWA using https://mail.domain.com/owa which took me to your login screen.

Can you post an updated sync test output please.

Thanks

Alan
0
 
HaroldNetwork EngineerAuthor Commented:
sure....

Do I need to do this??   http://support.microsoft.com/?kbid=940726

We only have 1 DC and 1 mail server, so the CAS would be the mail server yes?
RCATestResult.html
0
 
Alan HardistyCo-OwnerCommented:
Not necessary at this point, but it may be later.  Just depends on getting past the SSL error at the moment.

Do you still have an Autodiscover A record in DNS?  If you do - please delete it.

Thanks

Alan
0
 
HaroldNetwork EngineerAuthor Commented:
There was not an A record at all for autodiscover.

(Info removed to protect your privacy)

Alan Hardisty
EE Zone Advisor
0
 
Alan HardistyCo-OwnerCommented:
Okay - then can you zap the CNAME record for AUTODISCOVER and add an SRV record please as per:

http://support.microsoft.com/kb/940881

Point the SRV record to mail.domain.com

Then we need to let DNS settle for an hour or so and then please re-test and post the results from the test site again.

Thanks

Alan
0
 
HaroldNetwork EngineerAuthor Commented:
So this SRV is internally created, not externally? Reason I is the following...

    Open the DNS Management MMC snap-in.
    Expand Forward Lookup Zones.
    Locate and right-click the external DNS zone, and then click Other New Records.
    Click Service Location (SRV).
    Enter the parameters by using the required values.
    Click OK.

We have no external DNS Zone.
0
 
Alan HardistyCo-OwnerCommented:
Nope - all externally created.
0
 
HaroldNetwork EngineerAuthor Commented:
Ok, well the SRV was added about 20 minutes ago then.
0
 
Alan HardistyCo-OwnerCommented:
Perfect - did you lose the CNAME record at the same time?
0
 
HaroldNetwork EngineerAuthor Commented:
Yes removed CNAME from external DNS.  This is going to take 24-48 to propagate?
0
 
Alan HardistyCo-OwnerCommented:
Depends on the TTL values of your DNS records.  Give it an hour or two and try the test site again and if no joy, try after again a few hours later.  It should eventually resolve and hopefully you will get some progress on the site.

Alan
0
 
HaroldNetwork EngineerAuthor Commented:
Test how, with phone.
0
 
Alan HardistyCo-OwnerCommented:
On the test site.

Just one other question - did anything change recently that you can think of that would have caused Activesync to break?  Any updates to the server / DNS record changes etc?
0
 
HaroldNetwork EngineerAuthor Commented:
We had to update our SSL cert. This was done about 2 weeks ago.
0
 
HaroldNetwork EngineerAuthor Commented:
These are the results now.
RCATestResult2.html
0
 
HaroldNetwork EngineerAuthor Commented:
autodiscover is resolving to .41 again
0
 
Alan HardistyCo-OwnerCommented:
That will be because of your 'default' DNS record:

* (All Others)       7200              .41

Without that, autodiscover would resolve using the SRV record, but because of that, anything not specified will resolve to 41.
0
 
HaroldNetwork EngineerAuthor Commented:
Figured that had something to do with it resolving up to this point, just not sure. What now?
0
 
Alan HardistyCo-OwnerCommented:
Delete it and stop DNS resolving anything not named to the wrong IP, or change that record to point to .42.

Only you know what else may be hanging off that * record and what's best to change.

Be prepared for other things breaking as a result though!!
0
 
HaroldNetwork EngineerAuthor Commented:
Delete this = * (All Others)       7200              .41   ????

Actually, I don't really know everything, as I didn't set it up and IIS is as convoluted as trouble shooting this.

I added the CNAME back, when I saw the error about the CNAME not resolving, should I take it back out?
0
 
Alan HardistyCo-OwnerCommented:
The ideal situation is that you have autodiscover.domain.com included in your SSL certificate (which you don't), so you can't use the Autodiscover A record.

With the CNAME record, I was hoping that it would resolve the issue, but seems like it hasn't, so the alternative is the SRV record, but that means you must not have autodiscover resolving which it currently does because of the * record.

If you don't want to delete the * record, then you need to purchase a SAN / UCC SSL Certificate and install that, then you can add the Autodiscover A record in DNS and get past that problem.

Once we are over that hurdle, then optimistically Activesync will work, but if not, then we can work out what else needs to be changed to make it work, but we have to get past the Autodiscover hurdle, which other aspects of Exchange utilise (such as Out Of Office) so, that definitely needs to be fixed in whatever way you feel is best for your environment.

Alan
0
 
HaroldNetwork EngineerAuthor Commented:
Not sure why this stopped working and it is only phones we're activating now. Mine and other still sync, just the ones added.  It is the same type SSL cert. just purchased through godaddy.
0
 
HaroldNetwork EngineerAuthor Commented:
When I get to work tomorrow, I'll check it out. Thanks
0
 
Alan HardistyCo-OwnerCommented:
No problems.
0
 
HaroldNetwork EngineerAuthor Commented:
OH MY GOD! 3 days and it was just this little check box! There are a lot more permissions displayed under this Security<tab>, a lot of Exchange permissions that I see. Can you explain why this makes such a huge difference and/or why some phones were working and other not?
0
 
Alan HardistyCo-OwnerCommented:
Yep - that's all it can be.

It basically gives Exchange the permissions to be able to create objects under the account in AD which it needs in order for Activesync to work properly.  It's crazy - but that can often be all that causes it not to work, especially if it is working for other users on the same server.

Alan
0
 
Alan HardistyCo-OwnerCommented:
If it was working for the user and then stopped, they may be in the Admin groups mentioned and thus the permissions will get removed hourly.  Check my article for info.

Alan
0
 
HaroldNetwork EngineerAuthor Commented:
Man there are so many groups created on this server, I wouldn't know where to start. I do have a user that I check the box and it was now unchecked, so this is happening. We're running Win Server 2003, guess it's the same. Since it's occurring.
0
 
Alan HardistyCo-OwnerCommented:
Read my article - they are probably a member of an Admin group and thus the SDPROP hourly clean-up removes the permissions from the account.

Microsoft's suggestion is to have one account for Admin tasks and another for User tasks with Mobile phones for emails on the user account.

There is a workaround though (buried at the end of my blog http://alanhardisty.wordpress.com/2010/03/05/activesync-not-working-on-exchange-2010-when-inherit-permissions-not-set/) !!

Alan
0
 
HaroldNetwork EngineerAuthor Commented:
I guess I'm asking is, how would one figure out what group is doing what or can I?
0
 
Alan HardistyCo-OwnerCommented:
The groups are listed in my article:

The built in groups that are affected with Windows 2008 are:
Account Operators
Administrators
Backup Operators
Domain Admins
Domain Controllers
Enterprise Admins
Print Operators
Read-only Domain Controllers
Replicator
Schema Admins
Server Operators

The built in users that are affected with Windows 2008 are:
Administrator
Krbtgt
0
 
HaroldNetwork EngineerAuthor Commented:
Thank you very much!!
0
 
Alan HardistyCo-OwnerCommented:
You're welcome - glad I got there in the end ;)

Alan
0
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.

All Courses

From novice to tech pro — start learning today.