From: Markus Weber on
I've tested it now with Exchange 2007 SP1/Office 2007 and
there it seems to be ok. But no luck yet with Exchange 2010 ...

Anyone successfully used Import-Mailbox on Exchange 2010 with
external addresses in To:/Cc: fields not getting messed up?

TBC. Markus

"Markus Weber" wrote in message
> Just to add: This also happens to emails in PSTs generated
> with Export-Mailbox on the same server and then re-imported
> with Import-Mailbox, while reading the same PST with Outlook
> 2010 beta or other versions show the emails as they should.
> Anyone else seen this? Or can someone say, it's working for
> him?
> Thanks, Markus
> "Markus Weber" wrote in message
> news:hi7vjp$1gv$1(a)
>> Hi everyone,
>> did anyone ever came across the problem, that addresses in the
>> To:/Cc: field of external addresses showing up as
>> =SMTP:user(a)domain.TLD
>> after a pst has been imported with Import-Mailbox on Exchange
>> 2010?
>> Effect would be, that users would not be able to reply on these
>> addresses (reply all). The From: address is ok.
>> Opening the pst directly with the client does not expose this
>> problem, but that's not a real migration option ...
>> Lab environment is based on Windows Srv Std 2008R2, Trail version
>> of Exchange 2010 (Build 639.21), on the import host Outlook 2010
>> x64 Beta (Pro Plus, only Outlook installed, 14.0.4536.1000) is used
>> and the client is on Win7 Pro 32bit/Outlook 2007 or/and OWA of the
>> Exchange server itself.
>> Any idea? Many thanks, Markus
>> Background: We prepare a inter forest migration from a W2K domain
>> with Exchange Server 2003 SP2 to W2K8R2 and Exchange 2010. No in-
>> tention to use ADMT , "same" accounts will be manually entered in
>> the new domain and X500 addresses added so replies to "internal"
>> users will work.
>> Not sure if New-MoveRequest would be an option at all (I think I
>> remember having read somewhere, that it would require a 2K3 DC in
>> the source domain) - it looks like it's doing a bit too much ...
>> I only need the content copied in the target org, sometimes to a
>> different user name, no perms/attrs migrated at all ...