We worked on a CRM 4.0 environment, where the Email router was not tracking incoming email, it turn out is was a problem with the configuration, we were also getting incoming status failure message.
To fix the Tracking issue the following settings were changed to correct the configuration:
- Open CRM 4.0 in the browser, click on the Tools button in the top menu.
- Then click on Options in the dropdown.
- Now click on Email tab.
- The “Track” setting was change from “E-mail message in response to CRM e-mail” to “All e-mail messages”
The following setting also changed:
- Open CRM 4.0 in the browser, click on the Settings button in the left menu.
- Then click on Business Management menu item.
- Now click on Queues on the right.
- Double Click on the Queue used to for tracking.
- Change the setting for “Convert to email activities” option from “E-mail message in response to CRM e-mail” to “All email messages”
After setting the above two setting the tracking started working.
To resolve the incoming status failure the following commands were run to set the correct permission for access and impersonation:
- The following to allow CRM to access the user mailbox:
Add-MailboxPermission “Mailbox” -User “username” -AccessRights FullAccess
- The following to allow CRM to impersonate the users mailbox:
Add-ADPermission -Identity “Mailbox” -User “username” -extendedRight ms-Exch-EPI-May-Impersonate
- Finally the following to allow CRM to impersonate the exchange CAS server:
Add-ADPermission -Identity “ClientAccessServer” -User “username” -ExtendedRights ms-Exch-EPI-Impersonation
When you install Live Essentials or Office 365 Single Sign in Assistant they install Security Support Providers of their own, “liveSSP” and “msoidSSP” respectively. These value are added to the “Security Packages” key in: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\”
Removing the “liveSSP” and/or the “msoidSSP” entry from the security packages key does temporary fix the problem, but if an update to office 365 or live essentials is applied then the SSP values are written back to the Security Package key and the issue occurs all over again.
Msoidssp is a SSP used to align the SSPI interface with the client so that the client can connect with the server in the secure channel, more information about this SSP in the following link: http://community.office365.com/en-us/w/office/534.aspx
In office 365, it’s already using the secure channel, msoidSSP was a second secure channel from the windows 7 client for it to drop back on to like a safety net if the it was unable to secure communicate using the normal method. Removing the registry should not impact the usage of office 365 services as long as it is able to communicate successfully without the need to drop back to the second SSP.
The bug fix should be available in App-V client 4.6 SP2.
App-V 4.6 SP2 Release notes, please read before updating to SP2: http://technet.microsoft.com/en-us/library/jj729866.aspx
Download Link: http://www.microsoft.com/en-us/download/details.aspx?id=35513
Right we are hoping some of these posts actually help.
We are mostly going to post about IT problem, errors encountered when depolying, seting up and using Microsot products.
More to come.