If you see that from the ADSIedit Then fine, you already know who is the user and what you are looking for. You dont have to go through the manual way of converting the user name based on this KB http://support.microsoft.com/kb/291542.

So wats up? Here is a simple powershell way of converting them back to readable Username with the full DN as the output.

Step 1: You already have the MSexchmailboxGuid with you.(as per the screenshot above or from any error messages or from any excel files)

Step 2: Convert the guid by removing the spaces (that is all you have to do...)

step 3:

copy the Powershell script msexchmailboxGuid-Converter.PS1 in to your local drive. Run the Powershell script. You might have a error if you have not enabled your enabled your assembly "microsoft.visualbasic.dll" in powershell. Please do this before you proceed to execute the powershell script.

PS C:\>
[Reflection.Assembly]::LoadFrom("C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Microsoft.VisualBasic.dll")

GAC Version Location
--- ------- --------
True v2.0.50727
C:\Windows\assembly\GAC_MSIL\Microsoft.VisualBasic\8.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualB...

Step 4: Execute the Powershell script.

Step 5: Input the guid you have without the spaces.

Ste 6: Say OK and you are done, you can see the DN of the particular User as a Messagebox prompt.

you can find the script attached.

msexchmailboxGuid-Converter.PS1

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

Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 9646
Description:
Closing Mapi session "/o=Organization/ou=Administrative Group/cn=Recipients/cn=Recipient" because it exceeded the maximum of 32 objects of type "session".

(or)

Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 9646
Description:
Closing Mapi session "a3acaee7-cb14-4466-83ce-1dd117b546dc" because it exceeded the maximum of 32 objects of type "session".

If you see the Receipient you are fine, you can always go to that user and check out why is the particular user having so many sessions or you can terminate the sessions. I don't want to go in to the details of this event as lot of information is available on its occurence.

1. To solve this we Disable or Offload the TCP Chimney by running the following command in command prompt:

Netsh int ip set chimney DISABLED

2. More info:

Event ID 9646 is logged in the application event log of your Exchange Server 2003 computer when a client opens many MAPI sessions:  http://support.microsoft.com/kb/842022

so what if its a Guid how do you know which user is that and to go about troubleshooting. Here is the powershell script that helps you to convert the guid in to the respective DN of the user.

step 1:

You already have the error message from the event id.

Step 2:

You have to run the msechmailboxguid-converter(evnetid 9646).PS1  script. You might have a error if you have not enabled your enabled your assembly microsoft.visualbasic.dll in powershell. Please do this before you proceed to execute the powershell script.

PS C:\>
[Reflection.Assembly]::LoadFrom("C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Microsoft.VisualBasic.dll")

GAC Version Location
--- ------- --------
True v2.0.50727
C:\Windows\assembly\GAC_MSIL\Microsoft.VisualBasic\8.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualB...

Step 3:

Make sure you run the msechmailboxguid-converter(evnetid 9646).PS1 (The reason being the guid that you see from the ADSIEDIT for the user will be manipulated and will look a bit different in the error with the first 3 strings being reversed, you can read more about that from the article http://support.microsoft.com/kb/899663)

Step 4:Paste the GUid that you have copied from the event id in to the textbox pop up.

Step 5:

You are done, you can see the DN of the respective user as a pop up.

You can find the script attached.

msexchmailboxGuid-Converter(Eventid 9646).PS1

Lately with lot of organizations in the mixed mode I thought this would be much valuable information to share.  I have seen this in a large customer environment with Exchange 2003 and Exchange 2007 Mixed mode organization and Journaling (Envelope) was enabled for both Exchange 2003 and Exchange 2007 Recipients.

In a mixed mode environment where journaling is enabled for both Exchange 2003 and Exchange 2007 recipients, if the journal mailbox is located on an Exchange 2003 Server and a message has to traverse through multiple Exchange 2007 Hub Servers to get to EXCHANGE 2003 recipients, EXCHANGE 2003 will re-journal the message resulting in what appears to be duplicate journal reports.

EXCHANGE 2007 handles journaling differently than EXCHANGE 2003. EXCHANGE 2003 keeps track of a “JournalRecipientList” which serves two purposes. To identify that journaling has occurred and to identify which journal recipients a message has been delivered to. EXCHANGE 2007 simply keeps track that a message has been journaled via an x-ms-Exchange-Organization-Processed-By-Journaling header and monitors whether the recipients change between Submission and Post Categorization.

When a message is received by an EXCHANGE 2007 Hub, the journaling agent will stamp the message with the x-MS-Exchange-Organization-Processed-By-Journaling header. It will also build out a JournalRecipientList. This JournalRecipientList is part of the extended properties of a mail message (EXCH50). In EXCHANGE 2007, however, we specifically designed our system to NOT transmit EXCH50 between Hubs. This isn’t to say that the information in EXCH50 isn’t useful, but that we worked around having to pass this information either via custom X headers or better logic in handling messages via

the Transport Pipeline.

Unfortunately, because the JournalRecipientList has no use in EXCHANGE 2007, and because we don’t transmit EXCH50 data between Hubs, the information in the JournalRecipientList becomes lost if the second hop is another Hub. On subsequent transfers of the message into EXCHANGE 2003, there will be no JournalRecipientList and therefore EXCHANGE 2003 will take action on the message as if it had never been journaled.

Troubleshooting steps we followed to get to the basics of the problem:

Lab:

======

Site 1:

1 Exchange 2003 mailbox server with journaling enabled on the mailbox store

1 Exchange 2007 Mailbox+Hub+Cas role

Site 2:

1 Exchange 2007 Mailbox+Hub+Cas role

Mail flow:

Mailbox server in site 2 --> Hub in site 2 --> Hub in site 1 --> Exchange 2003

It turns out that in when sending a email from Exchange 2007 to Exchange 2003, if message traverses more than 1 hub transport, we get a duplicate journal message -- 1. Exchange 2007 envelop journal and 1 ex2k3 envelop journal.

1. Check journaling. On one HUB server, run the following command and analyzed the output.

Get-JournalRule | fl

2. Check transport rules. On one HUB and on EACH Edge server, run following command respectively and analyzed the output. The reason you need to check each Edge is because the transport rule you configure on one Edge server only applies to that Edge server.

Get-TransportRule | fl

Get the message tracking logs and start analyzing from the respective servers. By checking the logs on Exchange 2007 Hub server and we only see one copy of message sent to <mailto:mbxserver@contoso.com>

By checking the logs on the next EXCHANGE 2003 server, and we can see two copies of message sent to

mbxserver@contoso.com <mailto:mbxserver@contoso.com> and

Journal-MBX @contoso.com <mailto:Journal-MBX@contoso.com>.  So we could conclude from the above facts that the second copy was generated on Exchange 2003 BH server.

It seems the second journaling report was generated on the Exchange 2003 BH server even though the first journaling report had already been generated on Exchange 2007 HUB server. Normally Exchange 2007 Hub server stamps the X-EXCH50 BLOB on the original message with the address of the journaling mailbox where the journal report was sent. When an Exchange 2003 server receives the message from the Exchange 2007 Hub server, the Exchange 2003 server examines the X-EXCH50 BLOB to see whether the message has been journaled. If it has been journaled, Exchange 2003 doesn't generate another journal report.

However, for some reason, Exchange 2003 doesn’t realize that the message has already been journaled. So it journals the message again. This is the primary result of the duplicate journal mails.

To summarize,

1. XEXCH50 is not transferred between HUB servers. When the message is transferred through two HUB servers, the first HUB server will journal the message and stamp the XEXCH50. But the second HUB server will drop it.

2. When the mail is transfer to Exchange 2003 via RGC, we do see a successful transfer of XEXCH50 data. However, this XEXCH50 doesn’t containing any journaling

information.

3. Exchange 2003 don’t see the journaling information from XEXCH50 in the message and

re-journaling the message. This is the second duplicate copy.

Read more on setting the transportconfig cmdlet on XEXCH50 BLOB here.

http://technet.microsoft.com/en-us/library/bb124151.aspx

Read more on the Exchange 2007 Transport journaling here

http://technet.microsoft.com/en-us/library/bb738122.aspx

 So the bigger question how do I solve it, Please contact the premier support services to get a fix for this.

Exchange 2007 Service Pack 2 introduces several new features, but in order to utilize Exchange 2007 SP2, you must perform the following steps:

1.       Extend the Schema

2.       Prepare Active Directory

3.       Install Windows Installer 4.5

4.       Uninstall Interim Updates

Most of us must have read from various blogs and websites on the new exciting features (hey …. VSS Backup again) that Exchange 2007 sp2 brings us. But for customers who are large scale enterprises who tend to separate out their AD schema updates and Exchange upgrades you have to read this.

"We understood where most of the schema changes document as per AD schema changes SP2 below where any particular sessions belongs to PrepareAD steps as we split the steps to perform health check where Acitve Directory team would like to find out more details on what’s the main changes as the logs file activity showed quite lots of changes. This will be critical to determine on going forward to production environments"

If you are a large scale enterprise and want to know exact details (like the one above) and provide sufficient time to update your organization with the AD before doing the Exchange 2007 sp2 Upgrade you might probably want to finish off the Extend the schema and Prepare Active directory step with the help of your Active Directory Team. To answer their question on what is this change for you might probably point them back to the ldf files available and to the release notes. Please do remember that if you don’t need this sort of breakdown on the schema changes you can directly run the SP2 upgrade and the schema changes (prepareAD & PrepareDomain) are automatically completed in the background for you. Almost all changes to AD are listed in the ldf files and you can read through them at http://technet.microsoft.com/en-us/library/ee221142.aspx

Am providing an extract of the SP2 upgrade and you will be surprised to see that even though the release notes says there isn't much change to the active directory apart form the Dynamic schema validation (Read more about the Dynamic schema validation here http://technet.microsoft.com/en-us/library/ee221169.aspx ) and the Exchange trusted subsystem group you will see a lot of objects being touched in the SP2 setup logs.

These are basically verification on the object whether it exists before proceeding with the upgrade. For example,

[10/12/2009 2:26:36 PM] [2] Beginning processing.

[10/12/2009 2:26:36 PM] [2] Fixing all mail-enabled recipients in the Exchange 2007 administrative group.

[10/12/2009 2:26:36 PM] [2] Setting the Exchange version of recipient "<DomainName>/User Directory/User Accounts/<RecipientName>" to Exchange 2007.

[10/12/2009 2:26:39 PM] [2] Setting the Exchange version of recipient "<DomainName>/User Directory/Service Accounts/<RecipientName>" to Exchange 2007.

[10/12/2009 2:26:42 PM] [2] Verifying the existence of container object "Exchange Administrative Group (FYDIBOHF23SPDLT)".

[10/12/2009 2:26:42 PM] [2] Fixing the objects under container object "Exchange Administrative Group (FYDIBOHF23SPDLT)" with filter "(|((&((ObjectCategory Equal msExchOwaVirtualDirectory)(OwaVersion Equal Exchange2007)))(!((ObjectCategory Equal msExchOwaVirtualDirectory)))))".

[10/12/2009 2:26:42 PM] [2] Verifying the existence of container object "Client Access".

[10/12/2009 2:26:42 PM] [2] Fixing the objects under container object "Client Access" with filter "$null".

[10/12/2009 2:26:42 PM] [2] Verifying the existence of container object "ELC Folders Container".

The very obvious thing that you can see from the Exchange setup logs is that the Design Templates and Address Templates are being upgraded to the exchange 2007 SP2 version.

10/12/2009 2:25:16 PM] [2] Deleteting DS object /dc=com/dc=Orgname/dc=Domain/cn=Configuration/cn=Services/cn=Microsoft Exchange/cn=Orgname/cn=Addressing/cn=Display-Templates/cn=816/cn=2

[10/12/2009 2:25:16 PM] [2] Deleteting DS object /dc=com/dc=shell/dc=Domain/cn=Configuration/cn=Services/cn=Microsoft Exchange/cn=Orgname/cn=Addressing/cn=Display-Templates/cn=816/cn=3

[10/12/2009 2:25:16 PM] [2] Deleteting DS object

-Ram 

-Ram