Another option involves user interaction. On a new message or a reply type the name explicitly, do not let autocomplete do it's thing; click the X in the little window that pops up. Then remove the now-identified bad address from the Address Book. Yeah, I know, getting users to reliably perform steps is not reliable.
From: [email protected] To: [email protected] Subject: RE: [Exchange] Server Migration: Quick Contacts Failing Date: Tue, 16 Sep 2014 14:33:05 +0000 Okay, what’s odd is we have FIM synchronizing the GAL in both locations (which populates the x500 addresses). We had to add them on the company2.com mailboxes so users could reply/forward internal emails pre-dating the migration. I’ll have to see if FIM syncs that data, as I am pretty confident it does. But if it’s a matter of updating the Mail Contacts on company1.com to include that info, we should be able to handle that. Thank you everyone. Very sincerely appreciated. -Geoff From: [email protected] [mailto:[email protected]] On Behalf Of Michael B. Smith Sent: Tuesday, September 16, 2014 7:16 AM To: [email protected] Subject: RE: [Exchange] Server Migration: Quick Contacts Failing You should be able to add contract records for them, and then add X500 address objects to the contacts. From: [email protected] [mailto:[email protected]] On Behalf Of Orlebeck, Geoffrey Sent: Tuesday, September 16, 2014 10:05 AM To: '[email protected]' Subject: RE: [Exchange] Server Migration: Quick Contacts Failing Excuse my lack of clarity, I misused some terminology I think. "Quick Contacts" was meant to be "Address Book Cache" or "Cached Address Book" from what I'm seeing it described as online. Sorry for any confusion. We did use NirSoft NK2 Editor for the "company2.com" destination side of things. So if User1 migrated from "company1.com" to "company2.com" we modified their AutoStream.dat file so they have all their Address Book cache, etc. The problem is for users at "company1.com", their Address Book Cache has the user's old information (from when they were housed on company1.com Exchange servers). The problem is while there are only ~20 users in Company 2, our company has ~3,000 users and I don’t know of a way to script the removal of these addresses from users’ Address Book Cache. So again, our issue is that we migrated users from our Exchange server to their own. Now our users are unable to reply/forward to emails prior to the migration or send to the users from their Address Book Cache for ‘company2.com’ email addresses. I’m wondering if there is anything we can do on our Exchange server to point those ~20 addresses so replying/forwarding those old emails will still resolve and send successfully to their own Exchange server. I didn’t think there was anything we could do on the source domain side (outside of modifying Address Book Cache on a user-by-user basis). But I know there is a fair number of people that are a lot smarter than me on here, so wanted to pick their brains before I fall back on the advisory email/instructions we have already sent out. Thanks, Geoff From: [email protected] [mailto:[email protected]] On Behalf Of Gavin Wilby Sent: Tuesday, September 16, 2014 1:27 AM To: '[email protected]' Subject: RE: [Exchange] Server Migration: Quick Contacts Failing We use Nirsoft’s NK2 editor for this, it takes a second to load and then delete the old contacts off the machines in one swoop. (ignore the name is NK2, it works with all version’s of Outlook). Gavin Wilby IT Support Engineer From: [email protected] [mailto:[email protected]] On Behalf Of Daniel Chenault Sent: 15 September 2014 23:20 To: [email protected] Subject: Re: [Exchange] Server Migration: Quick Contacts Failing By your description a "quick contact" is an Outlook-local contact. It's failing for the reason you note and, more importantly, will _never_ look to the server to re-resolve this address. Outlook contacts are locally-managed only; no server-side fix. Since there are so few re-create them properly on the server and continue to have users delete them as the problem comes up. On Sep 15, 2014, at 14:11, "Orlebeck, Geoffrey" <[email protected]> wrote: All: We performed a migration where we took a domain that was previously hosted on our company’s Exchange server (Company1.com) and migrated them to their own AD/Exchange environment (company2.com). We migrated the x500 addresses from when Company 2 was on our network so company2.com so users could reply/forward internal email (or use quick contacts) without issue. The problem is that users in our Org (company1.com) have quick contacts pointing to the x500 address information from when company2.com was still hosted on our (company1.com) Exchange servers. Now that Company 2 is “external” these emails fail (which we would expect). We sent out an advisory email and whenever a user calls, we’ve shown them how to delete the quick contact and add user from Global Address List (we have FIM 2010 running GALSync) and emails work. There are only ~20 addresses for company2.com, so if we can manually update the proxyAddress attribute or something else, that’s fine. But we’re a little unsure on how to allow company1.com to accept the old x500 address and still forward it out to company2.com Here’s the network details in case it helps: *Exchange 2010 SP3 on both sides *Two-way Forest trust established *FIM 2010 running GALSync w/ Cross-Forest Delegation to sync GAL and allow delegation w/in Outlook *Both Forests are housed in our datacenter, so while they are separated, they can be hit via internal IPs w/o traversing WAN Thank you for your time. -Geoff Confidentiality Notice: This is a transmission from Community Hospital of the Monterey Peninsula. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. Thank you. SMP Partners Limited, SMP Trustees Limited and SMP Fund Services Limited are licensed by the Isle of Man Financial Supervision Commission. SMP Accounting & Tax Limited is a member of the ICAEW Practice Assurance Scheme. SMP Partners Limited registered in the Isle of Man, Company Registration No: 000908V Directors: M.W. Denton, M.J. Derbyshire, P.N. Eckersley, S.E McGowan, O. Peck, J.J. Scott, S.J. Turner SMP Trustees Limited registered in the Isle of Man, Company Registration No: 068396C Directors: A.C. Baggesen, M.W. Denton, O. Peck, J.J. Scott, J. Watterson, J. Cubbon SMP Fund Services Limited registered in the Isle of Man, Company Registration No: 120288C Directors: V. Campbell, M.W. Denton, P.N. Eckersley, D.A. Manser, S.E McGowan, O. Peck, J.J. Scott, R.K. Corkill SMP Accounting & Tax Limited registered in the Isle of Man, Company Registration No: 001316V Directors: I.F. Begley, A.J. Dowling, P. Duchars, P.N. Eckersley, J.J. Scott, S.J. Turner SMP Capital Markets Limited registered in the Isle of Man, Company Registration No: 002438V Directors: M.W. Denton, M.J. Derbyshire, D.F Hudson, S.E McGowan, O. Peck, J.J. Scott. SMP Partners Limited, SMP Trustees Limited, SMP Fund Services Limited, SMP Accounting & Tax Limited and SMP Capital Markets Limited are members of the SMP Partners Group of Companies. This email is confidential and is subject to disclaimers. Details can be found at: http://www.smppartners.com/disclaimer.html ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ Confidentiality Notice: This is a transmission from Community Hospital of the Monterey Peninsula. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. Thank you. Confidentiality Notice: This is a transmission from Community Hospital of the Monterey Peninsula. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. Thank you.
