Outlook clients using Delegates break when WINS is disabled and DNS Suffixes are not configured properly on the NICs.
When Outlook connects to a user’s mail profile, the FQDN of the email server the mailbox is hosted is used. When the same user is a delegate or has access to another mailbox, the client does a port 135 referral request using the NetBIOS name of the secondary mailbox server. MSX-Mail2 for example. The same is true for Public Folder referral requests. If the client fails this lookup using the NetBIOS or WINS lookup, the proxy\referral request is then made by the backend mail server on the users’ behalf.
In this example, the DHCP clients are configured to use WINS; however, they do not have the DNS Domain Suffixes defined on the TCP\IP NIC settings, which is causing the NetBIOS lookup failures. They need to include domain.com, user.domain.com, accounting.domain.com and so forth. Many users are attempting to access another mailbox or calendar and upon the WINS Lookup are failing. If you notice in the Outlook Client Configuration settings, the referral is using the NetBIOS and failing……eventually causing the Outlook client to fail. The other compounding issue is the backend mail server also had missing DNS suffixes, which was causing the mail server referrals to fail.
The Fix is to add the Domain suffixes to your desktop machines and backend Mail Servers.
@=”C:\\Program Files\\Microsoft Office\\OFFICE12\\OUTLOOK.EXE,1″
“OutlookSecureTempFolder”=”C:\\Users\\User1\\AppData\\Local\\Microsoft\\Windows\\Temporary Internet Files\\Content.Outlook\\PLSVBBBP\\”
I received a ton of these errors while syncing my Outlook 2007\Exchange 2007 Inbox. This article spells out the fix using the Inbox repair tool.
Once I ran the ScanOST.exe file against my Outlook Profile, the symptoms disappeared. It appears I had some type of corruptness in my mailbox.
As a proactive measure, I also ran the ScanPST.exe against my PST archives.