locked
Certificate Issue RRS feed

  • Question

  • I have CRM 2011 setup with IFD. Both on the CRM server and the server hosting ADFS I have the same wildcard certificate. When I  internally access CRM I get an error depending on the URL

    https://[OrgName].[Domain].com/  --> works fine both internally and externally

    https://[NameOfCrmServer]/[OrgName] --> "There is a problem with this website's security certificate"

    I need the latter one for the Deployment settings in the Email Router Manager. I think the reason is because the certificate obviously is for *.[Domain].com rather than [NameOfCrmServer]. But how do I get the latter to work? I guess I could locally install the certificate but that does not quite sound like the right approach.

    Saturday, May 19, 2012 3:59 AM

Answers

  • Yes, you are receiving the certificate error because the domain name for which the certificate was created does not match the URL via which you are accessing the website.

    You do not need to access the CRM via the server name to make the Email Router work.  If you have installed and are configuring the Email Router within the internal network, you can use the internal URL that you setup during the Claims Based configuration process.  It is usually something like:

    https://crm.domain.com/OrgName

    or

    https://crminternal.domain.com/OrgName

    Using the internal URL, you can authenticate using AD, rather than IFD.


    --pogo (pat) @ pogo69.wordpress.com

    • Marked as answer by hfaun Sunday, May 20, 2012 6:27 AM
    Saturday, May 19, 2012 5:52 AM

All replies

  • Yes, you are receiving the certificate error because the domain name for which the certificate was created does not match the URL via which you are accessing the website.

    You do not need to access the CRM via the server name to make the Email Router work.  If you have installed and are configuring the Email Router within the internal network, you can use the internal URL that you setup during the Claims Based configuration process.  It is usually something like:

    https://crm.domain.com/OrgName

    or

    https://crminternal.domain.com/OrgName

    Using the internal URL, you can authenticate using AD, rather than IFD.


    --pogo (pat) @ pogo69.wordpress.com

    • Marked as answer by hfaun Sunday, May 20, 2012 6:27 AM
    Saturday, May 19, 2012 5:52 AM
  • Thanks pogo. My OrgName is crm. During setup of claims-based authentication I used

    Federation metadata URL = https://sts.[domain].com:444/federation... 

    resulting in URL = https://internalcrm.[domain].com/Federation.... for the relying party (shown on the last screen)

    The former one (https://sts....) results in "404 - File or directory not found". With the latter (https://internalcrm...) I get the pop-up screen to log in which is strange. So I think something is still wrong. Having said that, I did try https://internalcrm.[domain].com/crm for the Email Router Manager and when testing the accounts I did get success. However, while the emails are being sent to the user defined in incoming and outgoing profiles, the emails are delivered to the Draft folder once every 30 minutes without ever being delivered. So I still have two issues

    1) Do I really use the https://internalcrm... (or https://sts...) and if so why do I get the popup screen for login?

    2) Why are the email going into the Draft folder and are not being delivered?

    Saturday, May 19, 2012 7:25 AM
  • The authentication challenge when using the internal URL is merely because by default, automatic use of the logged in User credentials is only enabled for the Intranet zone.  The internal URL will, by default be part of the Internet zone.

    In order to get rid of the authentication challenge, you can:

    1. Add the internal domain to the 'Trusted Sites' zone
    2. Enable automatic use of logged in credentials in the 'Trusted Sites' zone

    With respect to your 2nd question; it will be due to the fact that your Email Router is not yet properly configured.  What happens when you "Test" the configuration within the Email Router configuration tool?  If you are not properly authenticating against the CRM, the Email Router will never have an opportunity to do its job.


    --pogo (pat) @ pogo69.wordpress.com

    Saturday, May 19, 2012 7:47 AM
  • I have added both https://sts.[domain].com and https://internalcrm.[domain].com to the trusted sites. Anyways, it looks like this is just an inconvenience and not something causing issues.

    As for the email router, I get

    Name: ....
    Incoming Status:Succeeded
    Server: https://pod?????.outlook.com/EWS/Exchange.asmx(crmadmin@[domain].com)
    Outgoing Status: Succeeded

    Deployment is set to:
    -My company
    -https://internalcrm.[domain].com/crm
    -Access Credentials: Other Specified
    -User Name: [domain]\[admin]
    -Profiles: Incoming, Outgoing

    The profiles are:
    - E-mail Server Type: ExchangeOnline
    -Location: https://pod????.outlook.com/EWS/Exchange.asmx
    -User Type: Administrator
    -User Name: crmadmin@[domain].com
    -Access Type: Send as permission

    The emails end up in the draft folder of crmadmin@[domain].com

    Saturday, May 19, 2012 8:06 AM
  • After trying different things I finally got the login popup solved. I had to enter both https://sts.[domain].com and https://internalcrm.[domain].com to Internet Options->Security->Local intranet->Sites->Advanced

    The issue with the emails going into the draft folder remains, though.

    Saturday, May 19, 2012 9:07 AM
  • That would do it.  URLs either have to be in the Intranet Zone to automatically authenticate via Integrated Windows authentication, or you have to enable automatic use of logged on User's credentials for the Zone in which the URLs are already allocated.

    If the Email Router is not working properly (evidenced by the fact that the CRM Users' emails are still in Pending status), there are likely errors being logged that can give you hints towards the underlying issue.  I forget what the exact name of the file is, but there is a file in the Server (I think) directory called something.SystemState.Xml that will contain the most recently logged error.  You should also see Error events in the Application Event Log.

    Your CRM Users are configured to use the Email Router for Outgoing mail, yes?


    --pogo (pat) @ pogo69.wordpress.com

    Saturday, May 19, 2012 11:45 AM
  • Thanks for the responses. To answer the questions:

    * The CRM user is configured for Email Router for both Incomding and Outgoing mail.
    * The email address for the CRM user has been verified
    * Immediately after "Send" (not Save) and Email Activity the "Activity Status" is Completed
    * The (second) admin crmadmin@[domain].com (used for the profile) had full access to the email box through PS get-mailbox | add-mailboxpermission -user crmadmin@[domain].com -accessrights fullaccess -inheritancetype all

    Some interesting observations:

    * In Settings->Business Management->Queues->Active Queues the email access rights for the user were set as "None". However, going into Settings->Administration->Users I can confirm it is set to E-mail Router and the email is confirmed. Maybe the Queue has it's own settings. I set it to E-mail Router but the emails still end up in the Draft folder of crmadmin@[domain].com

    * I added some additional logging as described on http://support.microsoft.com/kb/907490 under "Microsoft Dynamics CRM E-mail Router" but nothing was added in http://support.microsoft.com/kb/907490 even after rebooting the system. I also created the directory d:\crmdrop\logs as there was an event saying it can't write to that directory.

    Problem:

    * I found an error message in the Event log which was not there before. It must have been triggered by one of the above actions. Anyways, it says Event 61042 MSCRMEmailLog An error occurred while processing the outgoing e-mail message with subject "..." for ExchangeOnline https://internalcrm.[domain].com/crm for delivery through https://pod?????.outlook.com/EWS/Exchange.asmx. Microsoft.Crm.Tools.Email.Providers.EmailException: Error. The user account which was used to submit this requests does not have the right to send mail on behalf of the specified sending account.

    As mentioned above I did set AccessRights=(FullAccess) for crmadmin@[domain].com Is this the wrong setting?

    Saturday, May 19, 2012 4:31 PM
  • Pongo, thanks A LOT!!! I finally got it to work. Well, short of that File->Options->E-mail->Track = "E-mail messages from CRM leads, Contact and Accounts" does NOT enter activities to the lead when that lead is sending an email to the user (it does if it's a response but not if the email was initiated by the lead).

    As for the solution, it turns out it was not enough to set full access rights. You also have to separately set send as rights. You do this with the following

    add-mailboxpermission -identity user@[domain].com -user crmadmin@[domain].com -accessrights fullaccess -inheritancetype all

    add-recipientpermission -identity user@[domain].com -AccessRights SendAs -Trustee crmadmin@[domain].com

    For others who might read this, you don't need "-identity". This will allow you to apply the command to a list of email accounts. See the example in my post above. Also you can just say "user" instead of user@[domain].com as long as "user" is unique (which it will be if the domain is the same for all).

    On another note, you don't really need to give full access rights. Receive-As would be sufficient. However, Exchange on Office 365 does not have the "receive-as" as an option, hence you need to give full access.

    On a final note, the trace of the email router does not actually go into a file for which I was looking in vain. Instead it creates MSCRMEmailLog in Event Viewer->Applications and Services Logs->MSCRMEmailLog. The MS documentation actually mentions this but the first time around I did not properly understand what they were saying. I guess I was too much fixed on having the logs in a file.

    Sunday, May 20, 2012 6:26 AM