robiche
Tue Apr 20 16:38:48 CDT 2004
Actually, our organization has been having the same exact issue.
We've had cases open with MBS support as well as Microsoft IIS support
and Microsoft Exchange support for over 2 months now, and none of them
have been able to resolve the issue. The problem stems from having
run IISLockdown using the Exchange template on the Exchange server
when it was first installed. The problem is, no one at MS Support can
figure out what specific permission that was changed by IISLockdown is
the culprit.
Also, unlike Outlook Web Access there is no document as yet from
Microsoft that states EXACTLY what permissions the CRM and IUSR
accounts require to function properly. No one at MBS support knows,
either.
So, for the time being, there is a workaround, albeit a HORRIBLE one.
Make the IUSR account on the Exchange server a member of the local
administrators group, and the email functionality will work like a
charm. In our organization, this isn't the worst thing we could do,
since we have a frontend/backend OWA setup, so the actual Exchange
server (and it's IUSR account) isn't accessible from the Internet.
It's still not a great idea. Unfortunately, nothing other than the
Administrators group will do. Even Power Users won't work. At least
that helps a little to narrow down where the permissions problem is.
Here's what I do know, however:
-It has nothing to do with permissions on any of the Exchange
directories, vsi mailroot directories or NT system directories.
-It has nothing to do with permissions on any of the CRM virtual
directories or permissions on the .srf files
- Granting "Everyone-full control" to all volumes and replacing
inherited rights does not fix the problem, so it's not a filesystem
permission problem.
So, some right that is not filesystem related that is granted to
Administrators but not Power Users is the key here. Unfortunately not
even two months of working with Microsoft Support has yielded an
answer.
Hopefully this will shed some light on what the problem is.
Matt Parks <mattp65@RemoveToX_XYahoo.com> wrote in message news:<tqda80d2823mgecgcq7ecgg1qlce03p3jt@4ax.com>...
> Andrew,
>
> Actually, just did a Google search on this group and found the following:
>
> Issue
>
> Error - "80070005 Access is denied" occurs when attempting
> to send an email from the Microsoft CRM web application.
>
> Potential Cause
>
> Proper permissions were not created within Exchange Server
> 2000 to allow the Microsoft CRM web application to send
> email.
>
> Resolution
>
> 1. On the Exchange server, use Windows Explorer and
> browse to this location: %systemroot%\Program
> Files\Exchsrvr\Mailroot
>
> 2. Within this folder, there should be at least one
> folder starting with 'vsi.' Right-click on the first
> folder, select Properties and then select the Security tab.
>
> 3. On the Security tab, verify the Everyone group has
> Full Control. If this group does not, please grant the
> group Full Control access.
>
> 4. If the Everyone group is missing, click Add... and
> select the Everyone group, then click OK. After clicking
> OK, verify this group has Full Control.
>
> 5. Repeat steps for 2-4 for the remaining folders that
> start with 'vsi' in the Mailroot folder.
>
> 6. Once these steps are completed, start the Microsoft CRM
> web application again (close first if it is still open)
> and send a CRM email from the web application. The email
> should send successfully
>
> Matt Parks
>
> ----------------------------------------
> ----------------------------------------
> On Tue, 20 Apr 2004 10:50:24 +0700, Andrew Simontsev <andrew@aurigma.com> wrote:
>
> Yes, if I go to
http://server/MSCRMConnector/ICrmEmailDispatch.srf (as
> specified in
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM\mailserverurl->SERVER
> registry value) using browser I get something like this:
>
> This XML file does not appear to have any style information associated
> with it. The document tree is shown below.
>
> - <SOAP:Envelope xmlns:SOAP="
http://schemas.xmlsoap.org/soap/envelope/">
> - <SOAP:Body>
> - <SOAP:Fault>
> <faultcode>SOAP:Client</faultcode>
> <faultstring>SOAP Invalid Request</faultstring>
> <detail />
> </SOAP:Fault>
> </SOAP:Body>
> </SOAP:Envelope>
>
> I believe Invalid Request here is ok it does not assume that someone
> will call this web service through the browser.
>
> MSCRMConnector virtual folder has anonymous user enabled. Should I
> change enable anonymous user for some other folder?
>
> By the way, what CrmEmailDispatch.dll does? As far as I understand it
> connects to Exchange and uses it to send the e-mail. Maybe I should
> configure some extra permissions for Exchange too?
>
> Andrew
>
> Matt Parks wrote:
> > Did you verify that you could browse to the URL? Also, make sure that the
> > Virtual Directory on the Exchange box is set to allow anonymous access.
> >
> > Matt Parks
> >
> > ----------------------------------------
> > ----------------------------------------
> > On Sat, 17 Apr 2004 11:40:11 +0700, Andrew Simontsev <andrew@aurigma.com> wrote:
> >
> > Matt,
> >
> > Thank you for direction. I found out the reason of the 404 error. On
> > Exchange server .srf extension in IIS settings was redirected to wrong
> > ISAPI filter (it specified in DOS-compatible format like
> > C:\PROGRA~1\MI6E08~1\...). I specified full path to "C:\Program
> > Files\Microsoft CRM\MSCRMConnector\CrmExIsapi.dll" and now I get SOAP
> > response.
> >
> > However e-mail still cannot be sent. According to Event Viewer, the
> > problem is in lacking permissions (see log below). How to specify proper
> > permissions? I have followed IG instructions with CRMEmailEnabled value
> > in Exchange settings...
> >
> > -------------------------------------------------
> > MSCRM Platform Error Report:
> > --------------------------------------------------------------------------------------------------------
> > Error: <description>An unexpected error
> > occurred.</description><details>An error occurred attempting to dispatch
> > the email : A SOAP error occurred:
> > '<error><code>80070005</code><description>Access is denied.
> > </description></error>'</details><file>D:\mscrm\Build\3017\src\platform\include\proxy\proxyutil.h</file><line>47</line>
> >
> > Error Message: An unexpected error occurred.
> >
> > Error Details: An error occurred attempting to dispatch the email : A
> > SOAP error occurred: '80070005Access is denied.
> > '
> >
> > Source File: D:\mscrm\Build\3017\src\platform\include\proxy\proxyutil.h
> >
> > Line Number: 47
> >
> > Stack Trace Info: at System.Web.UI.Page.HandleError(Exception e)
> > at System.Web.UI.Page.ProcessRequestMain()
> > at System.Web.UI.Page.ProcessRequest()
> > at System.Web.UI.Page.ProcessRequest(HttpContext context)
> > at
> > System.Web.CallHandlerExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute()
> > at System.Web.HttpApplication.ExecuteStep(IExecutionStep step,
> > Boolean& completedSynchronously)
> >
> > For more information, see Help and Support Center at
> >
http://go.microsoft.com/fwlink/events.asp.
> > -------------------------------------------------
> >
> > Andrew
> >
> >
> > Matt Parks wrote:
> >
> >>Try browsing to that URL directly from a browser on the CRM Server. Do you get
> >>a response? You may have to use the ICrmEmailDispathSDL.srf file instead. You
> >>should get an XML SOAP response when you browse to one of these files. In my
> >>experience, I've always had to use the SDL, but others have gotten the response
> >>from the main file itself.
> >>
> >>This should give you some more information about the problem.
> >>
> >>If you are using SSL on you server, you will need to disable the need for
> >>encryption on the MSCRMConnector virtual directory.
> >>
> >>Matt Parks
> >>
> >>----------------------------------------
> >>----------------------------------------
> >>On Fri, 16 Apr 2004 19:07:16 +0700, Andrew Simontsev <andrew@aurigma.com> wrote:
> >>
> >>Hello Matt,
> >>
> >>I got the same problem. When I fixed MailServerUrl->Server value, I got
> >>error either HTTP 400 (bad request) or HTTP 404 (file not found)
> >>depending on if I specify URL or IP. The file on this URL
> >>(ICrmEmailDispatch.srf) does exist in MSCRMConnector folder. What could
> >>be done next?
> >>
> >>
> >>Matt Parks wrote:
> >>
> >>
> >>>Check the registry for the CRMMailServerURL value. It can be found under local
> >>>machine\software\microsoft\mscrm. Sometimes, this key gets both the IP & the
> >>>URL put in it. Also, check to see if you have SSL installed on the Exchange
> >>>server. If so, disable encryption on the MSCRMServices virtual directory.
> >>>
> >>>Matt Parks
> >>>
> >>>----------------------------------------
> >>>----------------------------------------
> >>>On Thu, 15 Apr 2004 15:57:54 -0400, "Andrew Judge"
> >>><ajudge@grovenetworks_NOSPAM_.com> wrote:
> >>>
> >>>I have the following error and have fixed it once by reinstalling the
> >>>exchange mail router, but this can't be right. Reboots dont help either.
> >>>Any help appreciated.
> >>>
> >>>MSCRM Platform Error Report:
> >>>
> >>>----------------------------------------------------------------------------
> >>>----------------------------
> >>>
> >>>Error: <description>An unexpected error occurred.</description><details>An
> >>>error occurred attempting to dispatch the email : Could not connect to
> >>>host</details><file>D:\crm\Build\3297\src\platform\include\proxy\proxyutil.h
> >>></file><line>47</line>
> >>>
> >>>Error Message: An unexpected error occurred.
> >>>
> >>>Error Details: An error occurred attempting to dispatch the email : Could
> >>>not connect to host
> >>>
> >>>Source File: D:\crm\Build\3297\src\platform\include\proxy\proxyutil.h
> >>>
> >>>Line Number: 47
> >>>
> >>>Stack Trace Info: at System.Web.UI.Page.HandleError(Exception e)
> >>>
> >>>at System.Web.UI.Page.ProcessRequestMain()
> >>>
> >>>at System.Web.UI.Page.ProcessRequest()
> >>>
> >>>at System.Web.UI.Page.ProcessRequest(HttpContext context)
> >>>
> >>>at
> >>>System.Web.CallHandlerExecutionStep.System.Web.HttpApplication+IExecutionSte
> >>>p.Execute()
> >>>
> >>>at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean&
> >>>completedSynchronously)
> >>>
> >>>
> >>
> >>
> >