[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 311
  • Last Modified:

Exchange 2007 Synchronization Error

We have a few users that are receiving a synchronization error in Outlook 2003 or Outlook 2007 that states "Microsoft Exchange offline address book.  Not downloading Offline address book files.  A server (URL) could not be located.  0X8004010F".  They receive this message every hour based on when they start outlook in the morning.  I have attempted to open this questions before on here, and can not get this issue resolved.  Any suggestions are appreciated.
0
TomPro
Asked:
TomPro
  • 10
  • 9
  • 2
1 Solution
 
gupnitCommented:
Hi,
Follow this: http://support.microsoft.com/kb/939765
Thanks
Nitin Gupta (gupnit)
0
 
TomProAuthor Commented:
Unfortunately, we are not using a proxy so the first one is not the answer.  Also, I have tried all of the second post also.  Any other ideas?
0
Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

 
gupnitCommented:
Did you try recreating the profiles of users
0
 
TomProAuthor Commented:
Just locally on the PC, or actually deleting and recreating the account in exchange?
0
 
gupnitCommented:
Also, Try downloading MFCMAPI and see what is going on.
http://support.microsoft.com/kb/906557
http://support.microsoft.com/kb/291794
Cheers
Nitin
0
 
gupnitCommented:
Well Profile on PC, if that does not work, then use MFCMAPI
Else try creating a new user and move mails of this user there and try
Cheers
Nitin
0
 
TomProAuthor Commented:
The user has already deleted the local profile from the PC, and for that matter has actually rebuilt the PC due to hardware failure at one time, and the issue it still happening.  I have compared anything and everything in regards to exchange profiles on the server, and do not see a difference between ours.  Any other ideas?
0
 
gupnitCommented:
Hi,
How about creating another Mailbox for user and testing, if that works fine, move mails to that mailbox.
Did you try MFCMAPI?
Cheers
Nitin
0
 
TomProAuthor Commented:
The only problem with creating a mailbox is this, we are talking about a few users that were on the old exchange server.  There were others on the old exchange server that were moved at the same time, that are not having the problem.  Therefore I do not believe that it is a specific persons account issue.  

To your second question, no I have not tried MFCMAPI.  I have never used this before, so what are you looking for me to test with this to produce?
0
 
gupnitCommented:
It is pretty easy...install and use, I have also provided links
0
 
TomProAuthor Commented:
I will be honest, I have installed MFCMAPI, and have no idea what I am looking for.  Can you please point me in the right direction for what we are having a problem with and how to fix the issue.
0
 
Rajith EnchiparambilOffice 365 & Exchange ArchitectCommented:
I have seen this before.

Try this in your PC and if it is successful, confgure a group policy to update all your systems.

Click Start, click Run, and then type regedit.
Locate the following subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\BITS
Right-click BITS, point to New, click DWORD Value, type UseLmCompat, and then press ENTER.
In the right pane, right-click UseLmCompat, and then click Modify.
In the Value data box, type 0, and then click OK.
Quit Registry Editor.
Restart the BITS 2.0 service.

Rajith.
0
 
TomProAuthor Commented:
We have attempted to change this, and the PC is still continuing to give the same error on the hour every hour.  Any other ideas?
0
 
Rajith EnchiparambilOffice 365 & Exchange ArchitectCommented:
"""We have attempted to change this""

Have you changed it? Did you verify about putting in the DWORD?

It should fix this issue.

Rajith.
0
 
TomProAuthor Commented:
We did change it.  We even confirmed that the DWORD was created correctly.  It did not fix the problem.

Actually the problem, it turns out is that the user was logged into the computer under a local computer account.

Outlook 2007 apparently updates the public folders and OAB using an updater that requires domain rights to access the server information.  As it works out all the users that are having the problem were having it because they use a local computer account on their workstation.  The local computer accounts don't have the rights necessary to properly sync with the server.

We checked with Microsoft, and they seem to think that that is the expected function.  That seems like that's a failure on the part of their communication process, but they don't agree.
0
 
gupnitCommented:
NO....I do not agree !!!!! Once authentication has taken place via Outlook and configured, then it got to work.
Anyways....
Cheers
Nitin
0
 
TomProAuthor Commented:
I don't understand your comment gupnit.

Are you disagreeing with me or Microsoft?
They gave me sufficient evidence to prove the solution:
I used the same user account, same computer, same outlook, but used one user account that is a member of the domain, and another that was only a local computer user.
Local computer user always fails...domain account always works.

Checked other 2 users who was having the problem (2 others) and both fixed it by using a domain account instead.

Even went thru the process of taking a user who WASN'T having the problem, and logged onto THAT computer with a local computer account, and was able to CREATE the problem.
0
 
gupnitCommented:
Well, I am not sure how this is possible, we never make a User a local admin on any PC and Outlook works great.
It is not supposed to be like that, it is the AD auth and account that matters, and suffcicient privileges on user's own profile on PC, local group membership does not matter.
Anyways, like I said, good it worked for you
Cheers
Nitin
0
 
TomProAuthor Commented:
Sorry, maybe I'm confusing you.
The problem has nothing to do with whether the logged-in user has proper rights over the workstation (admin vs standard user).  The problem is that the logged-in user does NOT have rights in the DOMAIN (because it's not a domain account, it's a local computer account)

Example:
Outlook is running on a workstation WKSTN
User is logged onto WKSTN with account WKSTN\Bob
Exchange Server is part of domain DOMAIN.

When trying to update the OAB, the Outlook's communication protocol requires that Outlook send a UID/Pass pair to the Exchange server that must be authenticated.
Outlook automatically uses UID/Pass pair of whoever is logged onto WKSTN.
Therefore  Outlook sends WKSTN\Bob and associated password to Exchange server.
When Exchange tries to authenticate the UID/Pass pair against the DOMAIN, DOMAIN replies "I have no idea who that is," so Exchange refuses to send OAB info back to Outlook.
Outlook returns an error saying "Exchange didn't agree to give me the files you requested."

WKSTN\Bob's right's on the computer don't matter, he can be an admin, or just a standard simple rights user.  But since WKSTN\Bob has no right in DOMAIN, Exchange does not allow transfer of OAB files.

Does that make more sense?

This is how Microsoft explained the problem to me, and our empirical data seems to suggest that this is true.
0
 
gupnitCommented:
Aaahhhh....I re-read your previous comment....I was actually confused with local group membership. Apologies...for the same.
Thanks for the clarification
Cheers
Nitin
0

Featured Post

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

  • 10
  • 9
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now