locked
Intermittent 0x85010004 errors RRS feed

  • Question

  • UPDATE. SOLUTION ON PAGE TWO.  KEEP IN MIND THIS IS FOR INTERMITENT ERRORS, NOT CONSISTENT ERRORS - THERE IS A BIG DIFFERENCE. 

     

     

    I have searched everywhere and cannot find a solution.

    I intermittently get a 85010004 error on all of our WM5 pocket pcs and WM6 smartphones (9 T-Mobile MDAs,  20 T-Mobile Dash's and 34 Symbol MC70's).

    It seems totally random. I just manually synced 20+ times and it synced fine. Then I get the 85010004 error. I manually sync again and again and it fails each time with the same error. Eventually it will sync once again. Just now it failed about 6 times over a 10 minute period. This is without changing any settings on the phone or in Exchange server.

    It does the same whether over GPRS/EDGE or WiFi, so that should rule out cell signal strength etc. If it alway worked over wifi and only failed over GPRS/EDGE, I would attribute it to cell service. But it does the same over either radio.

    Not using direct push on the phone - since even if it does begin the sync, it may fail and not try again till the next email comes in.  I currently have it scheduled to sync every 5 minutes - which is as close to direct push as I can be - but have had it every 15 minutes. 

    Not using ssl on server. Not set to use ssl on phones. Not enforcing password on phones - although once did enforce, and phone received provision and used password.

    Please put some thought into any possible solutions since most solutions to 85010004 errors are for consistent errors - and the solutions usually recommend exchange settings that are already correctly set.

    I did find a 6 month old post in another forum where he had 3 seperate office locations and was having this problem at one of the three. Unfortunately the only reply gave the standard corrections for consistent 85010004 errors.

    Thanks in advance for any ideas that I can try. It successfully  syncs more often than not - but it is frustrating when it won't sync and won't sync and won't sync...

     

     

    Thursday, January 4, 2007 5:51 PM

Answers

  • Andy,

     

    I DISCOVERED THE SOLUTION!!!!!!

     

    Virtually all solutions offered in this thread were likely for consistent 0x85010004 errors (aka 403 forbidden)

     

    This was clearly for INconsistent errors as stated in the first post. The only thing consistent was that all 22 (soon to be 58) devices would fail at the same time for a period of about 10 minutes, only to have them all successfully sync for a variable amount of time.

     

    The answer leaves me with a few questions.... but I really don't care as much now that I can sync every single time without fail - even if manually sync every 15 seconds, or I am using internet sharing on my Dash to get online with my laptop while driving. Just kidding about driving.

     

    The server had multiple ip addresses, 5 to be exact. There were 4 websites along with the Default Website. I had read online somewhere that the ip for the Default Website (exchange) should be set to All Unassigned. I did try that but it made no difference so I changed it back to one of the 5 ip addresses. Each website had 1 ip address assigned to it. That's logical right?  I mean I never had one website return an error because it was trying to serve a page from one of the other sites. Apparently the Exchange Virtual directory is not that logical. Hell, it isn't even smart. Here's one of the questions I now have. Why on earth would exchange activesync, on a whim, send requests to one of the other sites? And why only some requests? During the sync failures, it would send POST and ocasionally OPTIONS requests to the correct site - so looking in the logs, it would appear that everything was working. But after looking into the logs for the other sites, I found that exchange activesync was, at the same time, sending all other rquests - GET, SEARCH, PROPFIND, and the all important X-MS-ENUMATTS - to the other websites. How dumb is that?

     

    Every few months I woud take another stab at solving this for a few hours - till the headache got too bad. But we are looking at more than doubling the number of users and I knew that things would likely just get worse, so I spent the last three days searching kb after kb after every exchange professionals website only to stumble upon the easiest solution possible myself. Move the other websites to another box and remove the additional ip addresses, leaving just one ip address on the exchange box so that exchange activesync doesn't get confused for some crazy reason. What seems strange is that OMA and OWA never got confused and started talking to the wrong site - and they are part of the same Default Website.

     

    So, the final solution - and reason it failed........  Only one IP address on the exchange box 'cause exchange activesync will frequently get confused and forget who it is talking to.

     

    Hope this helps others from spending hour after hour searching for the answer.

    Thursday, June 28, 2007 1:10 AM

All replies

  • I wish I had a solution for you.  I've been getting the same intermittent error.  It works fine one minute and then I'll start getting this error repeatedly, only for it to go away again for a while.  I haven't been able to find a solution... wishing someone will step up here with one. 
    Tuesday, January 30, 2007 2:11 AM
  • Well, at least I am not the only one. Although I suspect that there are many people having the same issue and try a few changes which appears to correct it... only to have it come right back - when in reality it never was corrected. Intermittent errors are such a pain to diagnose to fix.
    Tuesday, January 30, 2007 3:15 PM
  • Hi davekmi,

    this error has more to do with IIS for the exchange server

    checked the virtual directories in IIS for exchange-oma permission

    checked mailbox permission for that user

    Tuesday, January 30, 2007 10:36 PM
  • It is intermittent though. If it were a problem with permissions, it would either work or not work. It wouldn't work sometimes and not others. Unless permissions are randomly enforced - which is far too unrealistic to even fathom.
    Wednesday, January 31, 2007 2:55 PM
  • Any Update on this?  I seem to be having the Issue.

    http://support.microsoft.com/default.aspx?scid=kb;en-us;919864&sd=rss&spid=1773 

    Does not seem to reference the Intermittent part of the issue.

    Thanks,

     Scott<-

     

    Tuesday, February 6, 2007 4:04 PM
  • No update yet.  As with most "solutions" I have found, the above article also seems to be for consistent 0x85010004 errors.

    But thanks for input. I am willing to try anything I haven't tried yet.

    Tuesday, February 6, 2007 6:13 PM
  • Just an update on this issue, i spent 1 1/2 hours on the phone to microsoft to try and resolve this issue which ended in them sending me a hotfix as discribed in KB919864 but not supprisingly this didnt work, so back to square one. Has anyone else had any success with this hotfix? or come up with any other solution?

    Will.

    Tuesday, March 6, 2007 12:06 PM
  • I checked that hotfix out as well. Like most other "solutions" that seems to be for consistent errors. I guess like many MS problems, this is one that we will have to learn to live with.

    Still hoping for a fix though.

    Tuesday, March 6, 2007 3:07 PM
  • Hello all,

    I am also having this problem on my T-Mobile Dash (Windows Mobile 5.10-build 342). 

    Our environment

    Exchange 2003 SP2 Front End - Windows Server Standard 2003 SP1

    Excange 2003 SP2 Back End - Windows Server Standard 2003 SP1

     

    The strange thing is that a colleage of mine, who also uses the same device, is not having any problems with EAS.  This just started happening sometime after we applied DST OS and Exchange patches.

    We desperately need a resolution.

    Friday, March 16, 2007 2:30 AM
  • Hi Guys,

        I have been having this problem recently as well and in the end I gave up and rang Microsoft. This problem seems to be related to IIS and ISA if you are running it. I had been recieving the error on all wm5 ppc if the device security options were enabled in exchange. If I then added the users to the exceptions list all was fine.

    Microsofts come back on this was a registry key on the ISA machine which altered the way ISA responds to a published website - "However, if you use Web publishing to make this site available, ISA Server filters the Options field and returns a canned response to the requesting browser"
    The KB article is 304340.

    This registry change solved it instantly and all is working.

    Hope this helps some others with the same frustrating problem

    Cheers
    Craig
    Thursday, March 22, 2007 10:35 AM
  • Not sure whether this helps but for my case, my colleague starts receiving this problem when his password is about to expire (14 days before password expire). It seems that since my server has two names, one server name and one for internet access (DNS name) and my colleague is somehow redirected to a page using the internal name and hence, certificate problem. The problem gone once he changes his password.
    Friday, March 23, 2007 1:49 AM
  • All,

     

    For one reason or another, some users, including myself, have not been prompted to change our AD account passwords, however, we run a script that lets us know who is close to their expiration date, and it turns out I was.  For those individuals, we reset all AD passwords, and all problems went away. 

     

    I hope this is the case for some of you also.

     

    thanks.

    Wednesday, March 28, 2007 5:31 PM
  •  

     

    What resolved this for me was to open IIS 6.0

     

    Open properties of the Microsoft-Server-ActiveSync Virtual Directory

     

    opened the 'directory Security' tab

     

    click 'Edit' on Secure Comms

     

    'Tick' Require secure Channel (SSL) checkbox

     

    I have previously added the hotfix 919864 and also created a new certificate for the designated FQDN

     

    This works, now I only need to get my GPRS working and I can test Direct Push tech.

     

    Hope this helps :-)

     

    Tuesday, April 3, 2007 12:31 PM
  • I've been having the same issue only I don't have access to our corporate exchange server.

     

    My password expired a couple days ago.  I performed a hard reset on my device and setup my connection again and it worked.  It seems to be something with the password on the device.

     

    Jesse

    Thursday, April 19, 2007 4:52 AM
  • The solution for me was to give domain users read and execute permission on "Microsoft Active Sync" application in IIS 6.0 ...

     

    Tuesday, June 5, 2007 10:25 PM
  • Dave, same problem here, sometimes stops for a few hours with this error, today it's been since 9.26pm last night.  It's really frustrating and I can't see how it can be permissions related, but like you will give anything a go.  People with Blackberries must be laughing.... fingers crossed someone comes up with a solution soon.
    Wednesday, June 20, 2007 6:46 PM
  • This is so frustrating.  I've tried every offered solution that seems logical.  We will soon have another 30 users using over the air sync (currently have 19).

     

    I did a little testing today and discovered something. Not sure how useful in diagnosing... but.

     

    One T-Mobile MDA (WM5) connected over gprs. One T-Mobile Dash (WM6) connected over WiFi.

    Attempting manual sync, every 30 seconds or so, on both devices at the same time. They will both sync successfully, repeatedly, multiple times - it may be 10 minutes or over half an hour. Then they will both get the damn error at the same time.  Then they both succeed at the same time.

     

    Let them sit - both set to sync every 5 minutes.  

    This does not seem like a permissions issue - those would be consistent.

    This is not a cell tower or wifi signal issue.

    The server network utilization is under 1% - with occasional bursts to under 10%

    The CPU is idle over 95%

    I does not appear to be some kind of timeout - because of random amount of time that sync fails.

     

    The only consistentcy is that they both sync, or they both don't. 

     

    This thread is now number 2 on Google when searching for 0x85010004 - Hopefully we'll have an answer soon.

     

     

     

    Wednesday, June 20, 2007 7:42 PM
  • DaveKmi and All,

     

    For those of you still having the same problem, please change your Windows password and see if this problem resurfaces.  I've spoken with Colleagues, who also run Windows Mobile (v 5 & 6) with exact issues.  We have came to the conclusion that when your Windows password is about to expire (exact timeframe dependent on domain GPO), the Exchange ActiveSync on your Windows Mobile device will throw these 0x85010004 errors intermittently.  It's likely that you'll see this problem re-occur when your password expiration date approaches again. 

     

    Also, I've seen at least 2 posts in this exact discussion topic that mention the same "solution" to this problem - changing your Windows password.  

     

    This is not the final solution, however, only a work around.  We'll be troubleshooting this further; I'll post any other relevant information as it becomes available.

     

     

    Thursday, June 21, 2007 1:04 PM
  • Well. My password is set to not expire. But I thought I would give it a shot. I reset the password and it did sync fine... for awhile. After about 10 minutes it failed - and failed repeatedly for about 4 to 5 minutes before succeeding again.

     

    I have been taking a look into the ExchangeApplicationPool in IIS. So far I haven't found any changes that make a difference.

     

    The amount of time that it takes to return the error to the mobile device varies. Sometimes "Synchronizing folders" will show for a very short time, and sometimes it takes a few seconds. When - If - it then shows "Looking for changes" it will sync.

    Thursday, June 21, 2007 10:35 PM
  • Your issue is not intermittent - it syncs fine till password is about to expire, then will never sync till password is changed. Not really the solution we are looking for in this thread. However...

    For problems syncing when passwords are about to expire, see http://support.microsoft.com/kb/916958/en-us

     

     

    Friday, June 22, 2007 5:17 PM
  • Dave,

     

    We only have two mobile devices connecting through GPRS to the server, but I have checked and the errors in Activesync show that they both get the errors at EXACTLY the same time, each and every time it fails.  They are set up to receive Push email and although I am not 100% sure how that works (does the PDA poll every couple of seconds or is there a connection the server contacts the PDA to say mail has arrived?) it does look as though the error is originating on the server; but I can't believe that both accounts receive a new mail at the same time, so why are the times of the error and last good sync always the same?

     

    I have received an email from the Microsoft tech guys to do with recreating virtual directories etc - I'll give it a go once I have sorted the kids out and will let you know how I get on.

     

    Andy

    Saturday, June 23, 2007 8:43 AM
  • Dave

     

    Sorry to say that I went through all the options and to no advantage - most of them were covered by SP 2 anyway.  I have just had 3 hours of blissful receiving emails out and about, and just when I needed to receive an urgent one, it went down.  Fingers crossed for a solution to this quickly.

     

    Best wishes,

     

    Andy

    Tuesday, June 26, 2007 12:36 PM
  • I just rebuilt the virtual directories for the third time.

     

    I did more testing of the sync and failed to sync times. It seems that the time period that they will successfully sync varies. However, the time period during which they fail to sync is always 12 to 14 minutes. 

    Here are the results of the 5 minute sheduled syncs:

    3:00 sync

    3:05 sync

    3:10 sync

    3:15 syn

    3:20 failed to sync

    3:26 failed to sync

    3:31 sync

    3:36 failed to sync

    3:41 failed to sync

    3:46 sync

    3:51 sync

    3:56 sync

    4:02 sync

    4:07 sync

    4:12 sync

    4:17 failed to sync

    4:22 failed to sync

     

    IISRESET makes no difference.

    Vebose logs on the device show HTTP/1.1 401 Unauthorized and HTTP/1.1 403 Request+Forbidden

     

     I turned on logging on the Default Website.

    Looking through the log, I see that EVERY DEVICE fails during the same time frame.

     

     

     

     

     

    Tuesday, June 26, 2007 3:42 PM
  • Dave

     

    Yes, same here.  Have also just tried resetting my password with no effect.  I couldn't see how this would work when two different users devices fail to sync at exactly the same time...  are you and I the only peeople with this exact error?  everyone else seems to be able to cure it!

     

    Best wishes,

     

    Andy

    Tuesday, June 26, 2007 7:02 PM
  • Andy,

     

    I DISCOVERED THE SOLUTION!!!!!!

     

    Virtually all solutions offered in this thread were likely for consistent 0x85010004 errors (aka 403 forbidden)

     

    This was clearly for INconsistent errors as stated in the first post. The only thing consistent was that all 22 (soon to be 58) devices would fail at the same time for a period of about 10 minutes, only to have them all successfully sync for a variable amount of time.

     

    The answer leaves me with a few questions.... but I really don't care as much now that I can sync every single time without fail - even if manually sync every 15 seconds, or I am using internet sharing on my Dash to get online with my laptop while driving. Just kidding about driving.

     

    The server had multiple ip addresses, 5 to be exact. There were 4 websites along with the Default Website. I had read online somewhere that the ip for the Default Website (exchange) should be set to All Unassigned. I did try that but it made no difference so I changed it back to one of the 5 ip addresses. Each website had 1 ip address assigned to it. That's logical right?  I mean I never had one website return an error because it was trying to serve a page from one of the other sites. Apparently the Exchange Virtual directory is not that logical. Hell, it isn't even smart. Here's one of the questions I now have. Why on earth would exchange activesync, on a whim, send requests to one of the other sites? And why only some requests? During the sync failures, it would send POST and ocasionally OPTIONS requests to the correct site - so looking in the logs, it would appear that everything was working. But after looking into the logs for the other sites, I found that exchange activesync was, at the same time, sending all other rquests - GET, SEARCH, PROPFIND, and the all important X-MS-ENUMATTS - to the other websites. How dumb is that?

     

    Every few months I woud take another stab at solving this for a few hours - till the headache got too bad. But we are looking at more than doubling the number of users and I knew that things would likely just get worse, so I spent the last three days searching kb after kb after every exchange professionals website only to stumble upon the easiest solution possible myself. Move the other websites to another box and remove the additional ip addresses, leaving just one ip address on the exchange box so that exchange activesync doesn't get confused for some crazy reason. What seems strange is that OMA and OWA never got confused and started talking to the wrong site - and they are part of the same Default Website.

     

    So, the final solution - and reason it failed........  Only one IP address on the exchange box 'cause exchange activesync will frequently get confused and forget who it is talking to.

     

    Hope this helps others from spending hour after hour searching for the answer.

    Thursday, June 28, 2007 1:10 AM
  • I'm experiencing sync problems as well ... but in reviewing ISA firewall logs it appears that my rules are blocking access.

     

    What do I need to enable in order to connect to Exchange for sync'ing??

     

    Phil

     

    Friday, August 10, 2007 6:53 PM
  •  

    Exchange Activesync uses ports 80 for HTTP unsecured access, and 443 for HTTPS access. No other ports are needed for EAS.
    Friday, August 24, 2007 2:21 PM
  • I have been having this issue for weeks now, small fleet consist of 5 Treo 700wx's, 2 Moto Q's, 1 Mogul on Sprint and 1 T-Mobile Dash.

     

    It all started with my Moto Q.  I am running a single Windows SBS 2003 server w/ Exchange 2003 SP/2, configured use for Direct Push, and had the intermittent issues described here.  On the same server I was running Hamachi (a VPN software).  We are a small business, so I simply use a dynamic dns service and a self assigned/issued SSL cert. to accomplish EAS, the dyndns service updater tool had us registered with 2 private IP addresses, the servers local IP address and the VPN assigned 5.x.x.x address used by Hamachi.  I stopped Hamachi, disabled its network connection and have been syncing successfully ever since. 

     

    Anyone have a way I can direct the Exchange virtual directory or EAS directory to only use our LAN IP and disregard the server Hamachi IP address if Hamachi is indeed running?

     

    Thanks for any thoughts, I appreciate the post and everyone's thoughts, sorry if I haven't been clear in my thoughts.

    Tuesday, September 18, 2007 1:56 AM
  • Dear All,

     

    I was having an absolute nightmare trying to get OMA to work and went round and round to no avail.

     

    I was consistantly getting the dreaded 0X85010004 error saying authentication failed and to contact your exchange administrator. (I know this thread is for intermittent problems but this may help)

     

    I called Microsoft and opened a case to try and solve the issue.

     

    We tried everything and these are some of the knoledge base articles that were useful:

     

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

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

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

     

    We also applied an active sync exchange hotfix KB919864. You will need to contact MS to get this but it did not help.

     

    In the end the problem was located. ISA! What a nightmare!

     

    This is what you need to do if your implementing OMA and have ISA Server in the way.

     

    1. Open ISA Server Manager

    2. Click on Firewall Policy under the computer name.

    3. Click on your Mail Publishing rule.

    4. Right Click and select Properties

    5. Click on the Paths tab

    6. Add to your list of OWA paths the following three

        /Microsoft-Server-ActiveSync/*

        /oma/*

        /exchange-oma/*

    7. Click Apply and commit the changes to ISA.

     

    This solved the problem immediatley for me and now it is working fantastically.

     

     

    Note:

    During the analysis of the problem and after following KB883380 I started to receive the following events in my event log:

    Event ID 1040

    Source MSExchangeMU

    It was going on about corrupt metadata and was appearing every 15 mins.

     

    The solution to fix this is as follows: (You will need IIS6 Resources kit installed for this)

     

    - Backup the Metabase using KB : http://support.microsoft.com//kb/324277
    - Stop the MSExchangeSA
    - Using Metaedit (or Metabase Explorer) delete the "DS2MB" key
    - Using Metaedit delete the "SMTPSVC/1/domain" key
    - Restart the MSExchangeSA

     

    After restarting the system attendant it will recreate the keys that were deleted.
    Now make sure that the Metabase has the right values.

    Please recreate the exchange-oma Virtual directory using KB : http://support.microsoft.com/kb/817379

     

    Warning: You must only delete the Metabase keys shown above and no others. If you delete any other metabase keys you will kill your exchange and a complete reinstall will be required.

     

    I hope you find this helpful and that this assits others in getting OMA functioning.

     

    Best wishes

    Neal

    Friday, September 21, 2007 8:39 AM
  •  

    Sunday, April 27, 2008 5:58 PM