I'm having issues trying to log in to a CRM Online organization through the use of the latest version of the Xrm Tooling nuget package using the connection string constructor from a custom powershell cmdlet.
I'm receiving a rather unhelpful "Unable to Login to Dynamics CRM" error message and am attempting to enable tracing to troubleshoot but have not been able to enable it by modifying the .dll.config file like the below (taken from an XrmToolbox issue on GitHub):
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="Microsoft.Xrm.Tooling.Connector.CrmServiceClient"
switchName="Microsoft.Xrm.Tooling.Connector.CrmServiceClient"
switchType="System.Diagnostics.SourceSwitch">
<listeners>
<add name="console" type="System.Diagnostics.DefaultTraceListener" />
<remove name="Default" />
<add name ="fileListener" />
</listeners>
</source>
<source name="Microsoft.Xrm.Tooling.CrmConnectControl"
switchName="Microsoft.Xrm.Tooling.CrmConnectControl"
switchType="System.Diagnostics.SourceSwitch">
<listeners>
<add name="console" type="System.Diagnostics.DefaultTraceListener" />
<remove name="Default" />
<add name ="fileListener" />
</listeners>
</source>
</sources>
<switches>
<!--
Possible values for switches: Off, Error, Warning, Info, Verbose
Verbose: includes Error, Warning, Info, Trace levels
Info: includes Error, Warning, Info levels
Warning: includes Error, Warning levels
Error: includes Error level
-->
<add name="Microsoft.Xrm.Tooling.Connector.CrmServiceClient" value="Verbose" />
<add name="Microsoft.Xrm.Tooling.CrmConnectControl" value="Verbose" />
<add name="Microsoft.Xrm.Tooling.WebResourceUtility" value="Verbose" />
</switches>
<sharedListeners>
<add name="fileListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="XRMToolingLogs.log" />
<!--<add name="eventLogListener" type="System.Diagnostics.EventLogTraceListener" initializeData="XRMTooling" />-->
</sharedListeners>
</system.diagnostics>
</configuration>
I was able to work around this by configuring the listener programmatically through:
Microsoft.Xrm.Tooling.Connector.TraceControlSettings.TraceLevel = System.Diagnostics.SourceLevels.All;
Microsoft.Xrm.Tooling.Connector.TraceControlSettings.AddTraceListener(new TextWriterTraceListener("log.txt"));
Which pointed me to the actual error which was that the CrmServiceClient was expecting a URL with the organization unique name instead of the URL name.
I have SymbolSource Server Basic installed and running, following the instructions in Xavier Decosters blog entry.
I have set up Visual Studio as recommended by SymbolSource
The problem is that the Symbol Server returns 404's for all the url's that Visual Studio asks for.
Visual Studio accesses the following urls when trying to load the pdb:
http.../WinDbg/pdb/MightyLittleGeodesy.pdb/82A03D09EC754F5893C3806CDA329EC92/MightyLittleGeodesy.pdb
http.../WinDbg/pdb/MightyLittleGeodesy.pdb/82A03D09EC754F5893C3806CDA329EC92/MightyLittleGeodesy.pd_
http.../WinDbg/pdb/MightyLittleGeodesy.pdb/82A03D09EC754F5893C3806CDA329EC92/file.ptr
The SymbolServer website has the following:
\...\Data\MightyLittleGeodesy\1.0.0.0\Binaries\MightyLittleGeodesy\82A03D09EC754F5893C3806CDA329EC92\MightyLittleGeodesy.pdb
I have tried a large number of url variations in a browser, and I cannot get the Symbol server to return anything other than a 404 for any of them.
Does anyone know what to do here?
Thanks - Cedd
For any errors refer http://localhost/%your_app%/elmah.axd
If you faced with 404.* errors then you should check the following conditions:
Add write permissions onto 'Data' directory of application for IIS_IUSRS group
Create separate AppPool for application and enable 32bit option
Add MIME types for both .pdb (application/octet-stream) and .cs (text/plain) file types
Edit web.config and add the following lines:
<location path="Data">
<system.webServer>
<handlers>
<clear />
<add name="Deny" verb="*" path="*.config" type="System.Web.HttpForbiddenHandler" />
<add name="Allow" verb="GET,HEAD" path="*" type="System.Web.StaticFileHandler" />
</handlers>
<security>
<requestFiltering>
<fileExtensions allowUnlisted="true">
<clear />
<add fileExtension=".cs" allowed="true" />
</fileExtensions>
</requestFiltering>
</security>
</system.webServer>
<location path="WinDbg/pdbsrc">
<system.webServer>
<handlers>
<clear />
<add name="Deny" verb="*" path="*.config" type="System.Web.HttpForbiddenHandler" />
<add name="Allow" verb="GET,HEAD" path="*" type="System.Web.StaticFileHandler" />
</handlers>
<security>
<requestFiltering>
<fileExtensions allowUnlisted="true">
<clear />
<add fileExtension=".cs" allowed="true" />
</fileExtensions>
</requestFiltering>
</security>
</system.webServer>
My version of SymbolSource is 1.3.3
I am trying to issue a DELETE to an IIS7.5 resource:
DELETE http://198.252.206.16:48251/Test/foo.ashx HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)
Host: 198.252.206.16:48251
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache
And the server responds with:
HTTP/1.1 500 Internal Server Error
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Wed, 12 Feb 2014 01:01:30 GMT
Content-Length: 0
The damnedest thing is:
it works fine inside Cassini (the .NET based web-server used by Visual Studio)
nothing is logged in the Windows Event log
Custom errors are off in the site's web.config
No verbs are being filtered (or all verbs are being included)
WebDAV module is disabled
LiveStreamingHandler module is not installed
Why does IIS not work?
Steps to reproduce
Create a web-site with the generic handler:
Foo.ashx
<%# WebHandler Language="C#" Class="Foo" %>
using System;
using System.Web;
public class Foo : IHttpHandler
{
public void ProcessRequest(HttpContext context)
{
}
public bool IsReusable { get { return false; } }
}
and then issue a DELETE verb to the resource. You can use Fiddler to compose the request, if you like:
What about other verbs you ask?
You didn't try to reproduce it, did you? Well, i'll show you the results here:
GET: works
POST: works
PUT: works
HEAD: works
TRACE: 501 Not Implemented
DELETE: 500 Internal Server Error
SEARCH: 405 Method Not Allowed
PROPFIND: 500 Internal Server Error
PROPPATCH: 500 Internal Server Error
PATCH: 405 Method Not Allowed
MKCOL: 405 Method Not Allowed
COPY: 500 Internal Server Error
MOVE: 500 Internal Server Error
LOCK: 500 Internal Server Error
UNLOCK: 500 Internal Server Error
OPTIONS: 200 OK
IISUCKSFOO 405 Method Not Allowed
And just to be anal retentive, a snippet of the relevant portions from web.config:
<?xml version="1.0"?>
<configuration>
<system.web>
<httpRuntime/>
<!-- IISFIX: By default IIS hides errors-->
<customErrors mode="Off"/>
<!-- IISFIX: By default IIS ignores the browser's culture -->
<globalization culture="auto" uiCulture="auto"/>
<!--Doesn't work for ASP.net web-sites, only ASP.net applications-->
<trace enabled="true" requestLimit="40" localOnly="false" />
<compilation debug="true" targetFramework="4.0">
<assemblies>
<add assembly="System.DirectoryServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="System.DirectoryServices.AccountManagement, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Data.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
</compilation>
</system.web>
<!-- ASP.net web-sites do not support WebPageTraceListener (only ASP.net web-applications)
So this section doesn't work; and does nothing.
But if Microsoft ever fixes IIS, we will start working automagically. -->
<system.diagnostics>
<trace>
<listeners>
<add name="WebPageTraceListener" type="System.Web.WebPageTraceListener, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</listeners>
</trace>
</system.diagnostics>
<system.webServer>
<!-- IISFIX: By default IIS ignores custom error pages -->
<httpErrors existingResponse="PassThrough"/>
<defaultDocument>
<files>
<clear/>
<add value="Default.htm"/>
<add value="Default.asp"/>
<add value="index.htm"/>
<add value="index.html"/>
<add value="iisstart.htm"/>
<add value="default.aspx"/>
<add value="test.htm"/>
</files>
</defaultDocument>
<!--IISFIX: By default IIS doesn't understand HTTP protocol-->
<security>
<requestFiltering>
<verbs>
<add verb="OPTIONS" allowed="true" />
<add verb="GET" allowed="true" />
<add verb="HEAD" allowed="true" />
<add verb="POST" allowed="true" />
<add verb="PUT" allowed="true" />
<add verb="TRACE" allowed="true" />
<add verb="DELETE" allowed="true" />
</verbs>
</requestFiltering>
</security>
<modules runAllManagedModulesForAllRequests="true">
<!--IISFIX: Whatever this is, it causes 405 Method Not Allowed errors on IIS when using PUT. (Microsoft's broken by defult)-->
<remove name="WebDAVModule"/>
</modules>
</system.webServer>
</configuration>
Edit - forgot the screenshot of verbs:
The question was sufficiently asked in the title. The rest of the post is just filler to make it look like it shows research effort; which means you have to upvote it - the tooltip on the upvote arrow says so!
The answer turns out to be caused by more of Microsoft's Broken by default policy.
Rather than acting as a web-server, accepting requests and handling them, ASP.net by default decides to ignore the majority of requests - because it thinks the user shouldn't be doing them.
The solution is to rip everything related to ASP.net out of IIS, and then re-add it correctly:
web.config
<?xml version="1.0"?>
<configuration>
<modules runAllManagedModulesForAllRequests="true">
<!--IISFIX: Whatever this is, it causes 405 Method Not Allowed errors on IIS when using PUT. (Microsoft's broken by defult)-->
<remove name="WebDAVModule"/>
</modules>
<handlers>
<!--IISFIX: ASP.net is broken by default. By default they will not accept verbs from the client.
First we have to rip out everything related to ASP.net-->
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit"/>
<remove name="ExtensionlessUrlHandler-Integrated-4.0"/>
<remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit"/>
<remove name="SimpleHandlerFactory-ISAPI-2.0-64"/>
<remove name="SimpleHandlerFactory-ISAPI-2.0"/>
<remove name="SimpleHandlerFactory-Integrated"/>
<remove name="SimpleHandlerFactory-Integrated-4.0"/>
<remove name="SimpleHandlerFactory-ISAPI-4.0_64bit"/>
<remove name="SimpleHandlerFactory-ISAPI-4.0_32bit"/>
<!-- IISFIX: Now that we're ripped out everything related to ASP.net, put them back correctly.-->
<add name="SimpleHandlerFactory-ISAPI-4.0_32bit" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0"/>
<add name="SimpleHandlerFactory-ISAPI-4.0_64bit" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0"/>
<add name="SimpleHandlerFactory-Integrated-4.0" path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0"/>
<add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode"/>
<add name="SimpleHandlerFactory-ISAPI-2.0" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" responseBufferLimit="0"/>
<add name="SimpleHandlerFactory-ISAPI-2.0-64" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness64" responseBufferLimit="0"/>
<add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0"/>
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0"/>
<add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0"/>
<!--IISFIX: WebDAV is also buggy, and interferes with client requests-->
<remove name="WebDAV"/>
</handlers>
</system.webServer>
</configuration>
The problem now is that the web-site will not work on anyone else's machine; there are now hard-coded paths to files in web.config.
Why, oh why, couldn't Microsoft just do things right.
For completeness
For my own reference, here are the other things that i need to add to web.config every time because the defaults are wrong:
<system.web>
<httpRuntime/>
<!-- IISFIX: By default IIS hides errors-->
<customErrors mode="Off"/>
<!-- IISFIX: By default IIS ignores the browser's culture -->
<globalization culture="auto" uiCulture="auto"/>
</system.web>
<!-- ASP.net web-sites do not support WebPageTraceListener (only ASP.net web-applications)
So this section doesn't work; and does nothing.
But if Microsoft ever fixes IIS, we will start working automagically. -->
<system.diagnostics>
<trace>
<listeners>
<add name="WebPageTraceListener" type="System.Web.WebPageTraceListener, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</listeners>
</trace>
</system.diagnostics>
<system.webServer>
<!-- IISFIX: By default IIS ignores custom error pages -->
<httpErrors existingResponse="PassThrough"/>
</system.webServer>
I found that removing webDav references from handlers and modules in the above solution still resulted in IIS 7.5, IIS 7 Windows server 2008 r2 (I never tested IIS 8) for http methods PUT, DELETE
HTTP Error 500.21 - Internal Server Error
Handler "ExtensionlessUrlHandler-Integrated-4.0" has a bad module "ManagedPipelineHandler"
This server error is misleading and also given for improper .net installations where a handler is missing, and can be fixed by re-installing .Net, but that's probably not a solution, if it only affects PUT or DELETE requests to the extension-less route handler (GET, POST, and OPTIONS were fine). I read so many posts about enabling put and delete methods in MVC and Web api that seemed to claim this was a fix so I tried it anyway several times, restarted IIS etc, no change in the error.
the problem did not no go away until I added runManagedModulesForWebDavRequests="true" attribute to the modules element.
< modules runAllManagedModulesForAllRequests="true" runManagedModulesForWebDavRequests="true" >
http://www.iis.net/configreference/system.webserver/modules
By default runManagedModulesForWebDavRequests ="false" which means any webDav request is routed to WebDav. So far as I can deduce, A webdav request is all http PUT or DELETE requests as far as IIS is concerned, even if you have removed the webdav handler from web config and your request body doesn't conform to a webdav request. It's possible that uninstalling webDav might also correct the problem, but I never tried that; I have other sites running on the same server that depend on it.
I found the answer here:
ASP.NET Core with IIS - HTTP Verb Not Allowed
This is the web.config
<configuration>
<!-- To customize the asp.net core module uncomment and edit the following section.
For more info see https://go.microsoft.com/fwlink/?linkid=838655 -->
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="aspNetCore" />
<remove name="WebDAV" />
<!-- I removed the following handlers too, but these
can probably be ignored for most installations -->
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="aspNetCore"
path="*"
verb="*"
modules="AspNetCoreModule"
resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%"
arguments="%LAUNCHER_ARGS%"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout" />
</system.webServer>
Something to note on this in the future is when you code gets deployed to anything not local, that you change possible hard coded credentials to you generic access accounts. I had this exact issue for a full day and a half and saw that a DELETE .net request that worked with an LDAP was using a hard coded employee ID of a former employee as the UserPrincipalName. It worked fine until his ID finally got removed from our system then everything went bad. Again after a day and half we found the hard coded credentials used for testing purposes. Simple example to illustrate the different things that have to be accounted for on different testing environments.
I'm trying to modify the web.config with powershell to add a smtp section. I saw this post :
http://ybbest.wordpress.com/2012/02/28/how-to-add-configuration-settings-using-spwebconfigmodification-and-powershell-script/#comment-1070
which add some appsettings defining smtp section. But I want to know if these line:
<add key="businessSupportEmailAddress" value="contosointergenfax#gmail.com" />
<add key="copyMoveTempFolder" value="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS\SharePointProducts" />
<add key="faxEmailAddress" value="contosointergenfax#gmail.com" />
<add key="fromEmailAccount" value="contosoAdmin" />
<add key="fromEmailAddress" value="contosointergenfax#gmail.com" />
<add key="smtpServerName" value="build.contoso.local" />
<add key="smtpServerPort" value="25" />
are the same as this :
<system.net>
<mailSettings>
<smtp deliveryMethod="Network" from="testuser#domail.com">
<network defaultCredentials="true" host="localhost" port="25" userName="kaushal" password="testPassword"/>
</smtp>
</mailSettings>
</system.net>
Thanks
Nope.
First block represents key,value pairs that will be loaded in the default hash by the Configuration Manager (appSettings, see http://odetocode.com/Articles/345.aspx).
The other one is the .NET system config for mailing, mostly used in ASP webapps : http://msdn.microsoft.com/en-US/library/w355a94k.aspx
Thanks for visiting my blog and my solution is specific to a SharePoint project we are working on.In the end we actually end up putting the configuration settings into a list as we need the SharePoint timer job to access the configuration settings too.
If your solution is asp.net application , you should use the latter.
I have got a Web.Release.config that is successfully transforming a connection string.
When I add a microsoft.identityModel section I get a warning saying
The 'http://schemas.microsoft.com/XML-Document-Transform' attribute is
not declared
And the transform doesnt work on that section.
What am I missing to get the transform to work?
Complete Web.Release.config here
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="MYNAME"
connectionString="metadata=res://*/Models.MYCOMPANY-Sales-Demo.csdl|res://*/Models.MYCOMPANY-Sales-Demo.ssdl|res://*/Models.MYCOMPANY-Sales-Demo.msl;provider=System.Data.SqlClient;provider connection string="data source=.;initial catalog=MYCOMPANYDemo;UID=MYCOMPANYDBUser;Password=********;multipleactiveresultsets=True;App=EntityFramework""
xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
</connectionStrings>
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>
<microsoft.identityModel>
<service>
<audienceUris>
<add value="http://MYCOMPANY-sales-demo.cloudapp.net/" xdt:Transform="Replace"/>
</audienceUris>
<federatedAuthentication>
<wsFederation realm="http://MYCOMPANY-sales-demo.cloudapp.net/" xdt:Transform="SetAttributes(realm)" />
</federatedAuthentication>
</service>
</microsoft.identityModel>
</configuration>
I've run into this also but have gotten it to work. What I did was a "RemoveAll" and an "Insert" instead of a replace/match:
<audienceUris>
<add xdt:Transform="RemoveAll" />
<add value="http://example.com/" xdt:Transform="Insert" />
</audienceUris>
When I do it that way I get the desired transform and output config file.
This appears to be working now with Visual Studio 2012 (v4.5.50709). I still get the 'attribute is not declared' warning in the editor, but the xdt:Transform="Replace" directive is working for me.