locked
CustomerPortal WebsiteCopy cannot connect to CRM On-Prem RRS feed

  • Question

  • I have CRM 2011 RTM on-prem configured for internal and IFD access, which both work consistently and correctly. I have imported the portal solution into an org that is accessible at http://crm/orgname

    I have tried both the GUI and the CMD line methods of the websitecopy utility. (This is the version released most recently on the Marketplace.)

    When I try to connect with the GUI, I get a Connection Failed message. When I use the command line below, I get the error:

    "Unhandled Exception: System.InvalidOperationException: The provided uri did not return any Service Endpoints!"

    Here's the cmd line I've tried:

    WebsiteCopy /sourceFile:CustomerPortal.xml /sourceWebsiteName:"Customer Portal" /targetWebsiteName:"Customer Portal" /targetConnectionString:"Url=http://crm/orgname/; Domain:MYDOMAIN; Username:MyUserName; Password:password;"

    I've also tried to use the ServiceUri parameter in the connection string instead of Url as is used in the sample ImportWebsite.cmd file with the same results.


    Matt Wittemann CRM MVP C5Insight.com
    Friday, March 25, 2011 3:05 PM

Answers

  • We have found a bug in the source code for CrmSvcUtil as well.  This only affects on-prem, claims-enabled deployments.  This is being triaged and will be fixed and available in a future SDK update.  In the meantime, there is a temporary workaround that you can use with the current SDK.  It is documented here:

    http://community.adxstudio.com/Default.aspx?DN=9a7499fb-4e9a-408c-8096-6d658f9509a2


    Shan McArthur www.shanmcarthur.net Check out the commercial edition of xRM portals @ www.adxstudio.com
    Friday, May 6, 2011 8:40 PM
    Moderator

All replies

  • In doing more testing, I found that I can connect to the discovery service thru https (which then uses claims-based auth), but can't hit it via http with integrated auth. So I must have something misconfigured with AD FS. It's weird that I can get to all my orgs in CRM in IE via http locally, but not the discovery service.


    Matt Wittemann CRM MVP C5Insight.com
    Friday, March 25, 2011 3:17 PM
  • IE doesn't use the service endpoints like the portal does, so I am not surprised that IE works but the portal fails.  You do have to have IFD and claims set up properly.  Now that said, we found a bug recently in the portal connection code that affects a claims-based environment.  The good news is that it is fixed and will be available in the next drop, and more good news is that there is a workaround.  The workaround is to use the command line options on WebsiteCopy instead of the GUI to connect to CRM.  You also have to add the orgname after the url in addition to including it in the url in the connection string.  For example, the connection string might be: "Url=https://orgname.contoso.com/orgname; Username=jsmith; Password=passcode"

    Here is some additional information on the format available for CRM 2011 connection strings:
    http://community.adxstudio.com/Default.aspx?DN=8c4ce1a6-25f4-4ae6-b917-63cdb49f4fd0

    You know where to find me Matt, so if you still have problems call me and I will help.


    Shan McArthur www.shanmcarthur.net Check out the commercial edition of xRM portals @ www.adxstudio.com
    Saturday, March 26, 2011 1:36 AM
    Moderator
  • Thanks, Shan. I gave that connection string format a try and I'm getting a different error:

    "Unhandled Exception: System.ArgumentException: Format of the initialization string does not conform to specification starting at index 41."

    I think I need to get the internal/external ADFS piece working before troubleshooting this further.

    -Matt


    Matt Wittemann CRM MVP C5Insight.com
    Monday, March 28, 2011 5:36 PM
  • Hey Shan: I'm still unable to connect with the GUI or from the command line. Still getting the following error from the command line:

    "Unhandled Exception: System.ArgumentException: Format of the initialization string does not conform to specification starting at index 41."

     

    The portal website itself is throwing an error: An error occurred when processing the security tokens in the message.

    I'm guessing that's because the connection string in the web.config is also unable to connect to CRM. This environment is the one that I've set up for ADFS internal/external access. Integrated auth is passing through ADFS correctly, so it should work for applications the same way it does for IE users.

    Any pointers?

    Thanks!


    Matt Wittemann CRM MVP C5Insight.com
    Tuesday, March 29, 2011 2:49 PM
  • Send me the exact command line that you are using.  You can send it to my personal email or post it here.  If you need to hide information, use 'x', but keep the exact number of letters you are replacing because I am going to need to look at what is at character 41 in the string.
    Shan McArthur www.shanmcarthur.net Check out the commercial edition of xRM portals @ www.adxstudio.com
    Tuesday, March 29, 2011 4:02 PM
    Moderator
  • Hi, Shan: I just now was able to get back to this. I got past the above error - my stupid mistake. I was mistyping the connection info in the CMD line. (I had a colon instead of an equal sign, like "DOMAIN:MYDOMAIN" instead of DOMAIN=MYDOMAIN"). Anyway, I got past that problem, only to encounter the error below. It looks like a problem with ADFS and not being able to get the token. Below is the whole shebang from the cmd prompt. It looks to me like I've still got some work to do on getting claims working internally. I tried it with internal and external addresses, as well as by trying to format the URL as https://orgname.mydomain.com/orgname as was suggested as a possible workaround.

     

    Microsoft Windows [Version 6.1.7600]
    Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
    
    c:\inetpub\wwwroot\portal>WebsiteCopy /sourceFile:CustomerPortal.xml /sourceWebsiteName:"Customer Portal" /targetWebsiteName:"Customer Portal" /targetConnection
    String:"Url=https://crm/myorg/; Domain=MYDOMAIN; Username=username; Password=************;"
    
    Unhandled Exception: System.ServiceModel.Security.MessageSecurityException: An unsecured or incorrectly secured fault was received from the other party. See the
     inner FaultException for the fault code and detail. ---> System.ServiceModel.FaultException: An error occurred when processing the security tokens in the message.
    
       --- End of inner exception stack trace ---
    Server stack trace:
       at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChann
    el.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState
    , TimeSpan timeout)
       at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChann
    el.Request(Message message, TimeSpan timeout)
       at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean on
    eway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan tim
    eout)
       at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCall
    Message methodCall, ProxyOperationRuntime operation)
       at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
    
    Exception rethrown at [0]:
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage req
    Msg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa
    ta, Int32 type)
       at Microsoft.IdentityModel.Protocols.WSTrust.IWSTrustContract.Issue(Message m
    essage)
       at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannel.Issue(RequestSecu
    rityToken rst, RequestSecurityTokenResponse& rstr)
       at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1.Issue(IssuerEndpoint issue
    rEndpoint, String appliesTo, String requestType, String keyType, ClientCredentia
    ls clientCredentials, SecurityToken securityToken)
       at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1.Authenticate(TokenServiceC
    redentialType endpointType, String appliesTo, String keyType, IssuerEndpointDict
    ionary issuerEndpoints, ClientCredentials clientCredentials, SecurityToken secur
    ityToken)
       at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1.Authenticate(TokenServiceC
    redentialType endpointType, String keyType, ClientCredentials clientCredentials,
     SecurityToken securityToken)
       at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1.Authenticate(ClientCredent
    ials clientCredentials)
       at Microsoft.Xrm.Client.Services.OrganizationService.CreateUserTokenResponse(
    CrmConnection connection, IServiceConfiguration`1 config)
       at Microsoft.Xrm.Client.Services.OrganizationService.GetUserTokenResponse(Crm
    Connection connection, IServiceConfiguration`1 config)
       at Microsoft.Xrm.Client.Services.OrganizationService.ToOrganizationServicePro
    xy(CrmConnection connection)
       at Microsoft.Xrm.Client.Services.OrganizationService.ToOrganizationService(Cr
    mConnection connection)
       at System.Lazy`1.CreateValue()
    
    Exception rethrown at [1]:
       at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage req
    Msg, IMessage retMsg)
       at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDa
    ta, Int32 type)
       at Microsoft.IdentityModel.Protocols.WSTrust.IWSTrustContract.Issue(Message m
    essage)
       at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustChannel.Issue(RequestSecu
    rityToken rst, RequestSecurityTokenResponse& rstr)
       at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1.Issue(IssuerEndpoint issue
    rEndpoint, String appliesTo, String requestType, String keyType, ClientCredentia
    ls clientCredentials, SecurityToken securityToken)
       at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1.Authenticate(TokenServiceC
    redentialType endpointType, String appliesTo, String keyType, IssuerEndpointDict
    ionary issuerEndpoints, ClientCredentials clientCredentials, SecurityToken secur
    ityToken)
       at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1.Authenticate(TokenServiceC
    redentialType endpointType, String keyType, ClientCredentials clientCredentials,
     SecurityToken securityToken)
       at Microsoft.Xrm.Sdk.Client.ServiceConfiguration`1.Authenticate(ClientCredent
    ials clientCredentials)
       at Microsoft.Xrm.Client.Services.OrganizationService.CreateUserTokenResponse(
    CrmConnection connection, IServiceConfiguration`1 config)
       at Microsoft.Xrm.Client.Services.OrganizationService.GetUserTokenResponse(Crm
    Connection connection, IServiceConfiguration`1 config)
       at Microsoft.Xrm.Client.Services.OrganizationService.ToOrganizationServicePro
    xy(CrmConnection connection)
       at Microsoft.Xrm.Client.Services.OrganizationService.ToOrganizationService(Cr
    mConnection connection)
       at System.Lazy`1.CreateValue()
       at System.Lazy`1.LazyInitValue()
       at Microsoft.Xrm.Client.Services.OrganizationService.InnerOrganizationService
    .UsingService[TResult](Func`2 action)
       at Microsoft.Xrm.Sdk.Client.OrganizationServiceContext.Execute(OrganizationRe
    quest request)
       at WebsiteCopy.WebsiteImporter.GetEntityMetadataLookup(OrganizationServiceCon
    text serviceContext)
       at WebsiteCopy.WebsiteImporter.ImportWebsite(OrganizationServiceContext crm,
    String websiteName, XElement websiteElement, Boolean isSubscriber, IDictionary`2
     keyMapping)
       at WebsiteCopy.WebsiteImporter.Import(XElement element, String websiteName)
       at WebsiteCopy.WebsiteImporter.Import(Stream input, String websiteName)
       at WebsiteCopy.WebsiteImporter.Import(String inputXml, String websiteName)
       at WebsiteCopy.Copier.Copy(String[] args)
       at WebsiteCopy.Program.Main(String[] args)

     


    Matt Wittemann CRM MVP C5Insight.com
    • Proposed as answer by Rashmi Baliga Wednesday, April 20, 2011 7:28 AM
    Friday, April 1, 2011 7:01 PM
  • I would suspect https is causing you some grief here.  The url you used was https://crm/orgname.  Can you get there on your machine with NO browser security warnings?  The other thing is that you MUST use the exact urls that are registered in the deployment manager.  ie: http://crm is different than http://crm.mydomain.com.  The web UI doesn't seem to care much, but the SDK endpoints are very particular about this.  Another consideration is that you have to have the orgname in the host name plus the path in the url (due to a small bug that will be fixed in next week's drop of the SDK).  For example, if your internal url for CRM is https://crm.mydomain.com, then your url in the connection string must be https://orgname.mydomain.com/orgname).  Please pay extra careful attention to urls - they are very particular and you have to get everything exactly right, and your SSL certs have to match as well.  There is no easy cheats around these restrictions.
    Shan McArthur www.shanmcarthur.net Check out the commercial edition of xRM portals @ www.adxstudio.com
    • Proposed as answer by Jim Glass Jr Monday, April 4, 2011 7:17 PM
    Friday, April 1, 2011 7:09 PM
    Moderator
  • Thanks for the quick response:

    1) Yes, I can get to https://crm/orgname with no browser security warnings whatsoever. Integrated Windows auth is seamlessly passed through ADFS and the CRM website loads.

    2) In Deployment Manager, in the Microsoft Dynamics CRM Properties dialog, on the Web Address tab, I've specified HTTPS and crm for the 4 servers (Web Application Server, Organization Web Service, Discovery Web Service, and Deployment Web Service).

    3) I tried with various combinations of the URL, including https://orgname.mydomain.com/orgname, https://server.mydomain.com/orgname, 

    I'm going to keep experimenting with my ADFS and Deployment Settings to see if I can figure out what the right combination is.

    Thanks.


    Matt Wittemann CRM MVP C5Insight.com
    Friday, April 1, 2011 7:37 PM
  • IF you specify https://crm/ in your urls you are going to be in trouble as they will not be visible outside.  I also assume that you have used self-signed certficates because it is not a standard name.  This isn't supported in my opinion.  Try using a fully qualified domain name, which is going to be important for you to ever realize IFD capabilities.
    Shan McArthur www.shanmcarthur.net Check out the commercial edition of xRM portals @ www.adxstudio.com
    Friday, April 1, 2011 7:41 PM
    Moderator
  • I'm using a SAN cert - not self-signed. But I'd expect problems with just https://crm/ too, which is why I tried all sorts of FQDNs. I'm stumped. I'm hoping that inspiration will strike over the weekend while I'm thinking about something else!
    Matt Wittemann CRM MVP C5Insight.com
    Friday, April 1, 2011 8:06 PM
  • I have not tried with SAN certs, so you are in uncharted territories.  That url appears to be your internal name.  Try your IFD urls too using the suggestions I mentioned an hour earlier.
    Shan McArthur www.shanmcarthur.net Check out the commercial edition of xRM portals @ www.adxstudio.com
    Friday, April 1, 2011 8:07 PM
    Moderator
  • Yeah, I tried with https://orgname.domain.com and https://orgname.domain.com/orgname as you suggested.
    Matt Wittemann CRM MVP C5Insight.com
    Friday, April 1, 2011 8:18 PM
  • Hi Matt, I was experiencing the same issue as yourself on this however I was perplexed since I had previously got this to work whilst using an internal non-IFD deployment for testing.

    My solution in this instance was to set up the http binding in IIS, disable Claims & IFD, change the CRM properties binding back to http, iisreset then re-run using the string in the following format:

    WebsiteCopy /sourceFile:CustomerPortal.xml /sourceWebsiteName:"Customer Portal" /targetWebsiteName:"Customer Portal" /targetConnectionString:"Url=http://servername/orgname; Domain=domain; Username=username; Password=password;"

    This imported successfully. I changed the binding back to HTTPS, re-ran the claims & IFD wizard (values were retained so just click through) and IISRESET again. CRM seems to be working fine without issue.

    I've had to remove the http binding again from IIS since we use the email router here (cant use both http and https with the email router).

    I've yet to link up the actual portal to CRM yet so hopefully there's no problems connecting to the endpoint from there.

    Not ideal, but a workaround I thought I'd share none the less. Whole process took less than 10 minutes if you need to factor in downtime.

    • Proposed as answer by Jim Glass Jr Tuesday, April 19, 2011 3:58 PM
    Tuesday, April 5, 2011 5:01 PM
  • Thanks, Blmcg. I might give that a try.


    Matt Wittemann CRM MVP C5Insight.com
    Tuesday, April 5, 2011 5:14 PM
  • Download the latest CRM SDK (5.0.3).  We made some changes to better support IFD.  You can use the tool from the SDK.
    Shan McArthur www.shanmcarthur.net Check out the commercial edition of xRM portals @ www.adxstudio.com
    • Proposed as answer by Jim Glass Jr Tuesday, April 19, 2011 5:26 PM
    Tuesday, April 19, 2011 4:08 PM
    Moderator
  •  

    Shan: I am getting the same issue after installing IFD and testing everything out on a previously a working CRM2011 and portal. 

     

    We installed IFD according to the book, debugged it and have it accessible via web and outlook clients under new IFD both inside and outside the firewall.

     

    Our CRM is now ADFS configged for AD inside using https://CRM2011.domain.com/orgname and IFD links are: https://orgname.domain.com, https://auth.domain.com, https://dws.domain.com (instead of dev.domain.com) and using a wild card certificate issued by a trusted provider "*.domain.com"

     

    I am using CRM SDK 5.0.3 and executing on the crm 2011 server

     

    When I run 5.0.3 version crmsvcutil in a folder with all sdk 5.0.3 dlls I get :

     

    C:\Users\szoz\Desktop>cd C:\Program Files\Microsoft Dynamics CRM\Tools\bin5.0.3

     

     

    C:\Program Files\Microsoft Dynamics CRM\Tools\bin5.0.3>crmsvcutil /codeCustomiza

    tion:"Microsoft.Xrm.Client.CodeGeneration.CodeCustomization, Microsoft.Xrm.Clien

    t.CodeGeneration" /url:"https://orgname.domain.com/XRMServices/2011/Organizat

    ion.svc" /out:"xrm.cs" /namespace:Xrm /serviceContextName:XrmServiceContext /ser

    viceContextPrefix:Xrm /u:useraccount/d:domain/p:pw

    CrmSvcUtil : CRM Service Utility [Version 5.0.9688.1046]

    c 2011 Microsoft Corporation.  All rights reserved.

     

     

    Exiting program with exception: The user authentication failed!

    Enable tracing and view the trace files for more information.

     

    C:\Program Files\Microsoft Dynamics CRM\Tools\bin5.0.3>pause

    Press any key to continue . . .

     

    I also get the same error if I try the external domain name or id I append the orgname to the internal url

     

    Any suggestions you have are welcome!

     


    Stephen V Noe, CRM MCT

    Saturday, April 30, 2011 1:14 PM
  • We have found a bug in the source code for CrmSvcUtil as well.  This only affects on-prem, claims-enabled deployments.  This is being triaged and will be fixed and available in a future SDK update.  In the meantime, there is a temporary workaround that you can use with the current SDK.  It is documented here:

    http://community.adxstudio.com/Default.aspx?DN=9a7499fb-4e9a-408c-8096-6d658f9509a2


    Shan McArthur www.shanmcarthur.net Check out the commercial edition of xRM portals @ www.adxstudio.com
    Friday, May 6, 2011 8:40 PM
    Moderator
  • Thanks Shan, I was having to use the workaround I posted prior for CrmSvsUtil too.

    I'll give this a shot and see if it helps since I'm having to schedule a lot of downtime in (however brief, got used to the process now so its usually less than 5 minutes) to regenerate the Xrm.cs as we develop.

    I do find it odd the Claims-Auth is the "standard", recommended, authentication method (Due to IFD) in the deployment guide, yet it seems little testing has went into the SDK under this scenario for on-premise deployments.

    Friday, May 6, 2011 11:34 PM
  • It is easy to spin up non-claims testing environments, but claims testing environments are much more complex to configure.  As such, I don't believe that the testing for complete end-to-end scenarios is as well covered for claims.
    Shan McArthur www.shanmcarthur.net Check out the commercial edition of xRM portals @ www.adxstudio.com
    • Proposed as answer by Jim Glass Jr Tuesday, May 24, 2011 6:30 PM
    • Unproposed as answer by Jim Glass Jr Tuesday, May 24, 2011 6:30 PM
    • Proposed as answer by Jim Glass Jr Tuesday, May 24, 2011 6:30 PM
    Friday, May 6, 2011 11:44 PM
    Moderator