Microsoft Dynamics CRM URLs


CRM 4.0 introduced many changes to the way URLs need to be constructed.


In MSCRM 3.0 and earlier, you could simply access a page by using a URL such as ht.tp://<crmserver:port>/default.aspx


The introduction of multi-tenancy and CRM Online/IFD deployments required changes to the URL formats. Both CRM online and IFD deployments require URLs of the form ht.tps://orgname.mycrmhost.com – This was mainly done for reasons related to securing cookie domains, but also helps provide organization specific URLs.


Things are a little bit different for on-premise CRM installations.



a)      we need a way to indicate which organization the user is trying to access – The format used here is: /orgname/page.aspx">/orgname/page.aspx">ht.tp://<crmserver:port>/orgname/page.aspx


b)     We actually don’t create virtual directories for every organization. MSCRM implements a virtual path provider that parses the URL to figure out which organization you are accessing and help in performing the correct authentication (verifying that the user is a member of that organization etc).


c)     For on-premise deployments, if a user just types in a URL without an organization name (such as ht.tp://crmserver), MSCRM would try to service the request for the user’s default organization.


One of the common questions is around accessing custom pages and the correct URL format for that.


Rich Dickinson on the CRM PM team compiled an excellent list of when the custom page should be accessed using an org specific URL and the table below is based on that compilation.






























URL to access what object?


Format for On-Premise Deployments


Format for IFD deployments


Format for CRM Online


aspx page or webservice under ISV folder using MSCRM’s vdir


Prepend org name to the page – http:<crmserver>/orgname/isv/page.aspx


Do not prepend org name to the page. URLs are of the format:


ht.tp://orgname.myhost.com/isv/page.aspx


N/A


aspx page or webservice not under MSCRM’s vdir (on a separate vdir or server for example)


Do not prepend.


Do not prepend


Do not prepend org name.


ISV Menu/Iframe to a URL addressable CRM form


Prepend org name


Do not prepend orgname


Do not prepend orgname


Access crmservice.asmx


Use DiscoveryService


Use DiscoveryService


Use DiscoveryService


 


You will notice that you will have to prepend the orgname to the URL if your page is under the ISV folder in MSCRM’s vdir (for on-premise deployments). This is because the MSCRM virtual path provider will process the request to your page and it will assume the request is for the default organization for that user if an orgname is not specified and can result in “The organization id of the user being verified does not match the organization id of the execution context passed to VerifyUser” error.


Michael Höhne has a more detailed blog explaining the authentication issue at: http://www.stunnware.com/crm2/topic.aspx?id=js28


Important note: We will soon be documenting an API (prependOrgName) that can be used in client side scripts to adjust a given URL automatically. We’ll have a blog announcing this in the CRM team blog as soon as the documentation is ready (next round of SDK documentation update will be around end of august).


The CRM SDK documentation also has walkthroughs on how to use discovery service to get the URL to access MSCRM webservices -- http://msdn.microsoft.com/en-us/library/bb955359.aspx


Jagan Peri

Comments (11)

  1. Kamaldeep says:

    Can we forward the org links to subdomains or different domains?

  2. Kamaldeep,

    If you forwarded the org link to a different domain, CRM would need to be installed on that domain, so you would probably need another installation of CRM.

    You can set up host headers on your orgname URL to give your users an easir to remember URL to access CRM than having to type in the organization name.

  3. Ahmad says:

    What if we are planning to have folders directly under CRMWeb folder instead of CRMWeb/ISV folder. How do we access custom pages and web services under such a folder, both in on-premise and IFD?

    Thanks.

  4. Kosher says:

    What if our domain name is the same as our org name?  The problem is that the domain controller uses the ORGNAME and then the internet facing domain is domainname.com so we end up with the DC, ORGNAME.domainname.com.  The problem is that ORGNAME is also used for the CRM name, which causes a conflict in naming.

    I would like to just have users go to crm.somedomain.com on the internet facing side to access CRM.  It seems IFD wants to put it at ORGNAME.domainname.com, which is the when the conflict happens.  If I specify the IFD root domain to be ORGNAME.domainname.com then it puts the CRM in ORGNAME.ORGNAME.domainname.com, which is not really what I want users typing to access CRM.

    Please let me know of a way to use crm.somedomain.com

    Thanks!

  5. Anoniem says:

    Hi Kosher

    For a customer I already have succesfully set up an IFD: orgname.crm.domainname.com

    crm.domainname.com was the root domain.

    And used a shorter one for redirecting to this orgname.crm.domainname.com.

  6. Hi, I recently started owning the Internet Facing Deployment (IFD) feature set within the CRM team and

  7. Hi, I recently started owning the Internet Facing Deployment (IFD) feature set within the CRM team and

  8. Prateek says:

    Hi,

    Does prependOrgName automatically determine if the URL is for IFD or On-Premise and adjust accordingly? i.e. add orgname if on premise or does not add orgname if IFD?

    thanks,

    prateek

  9. gkellett says:

    This has been stumping me for hours!!  Having to put the organisation name in from of my custom web page url solved my issue.  Thanks for your help.

  10. Bob R. says:

    Hello, we rebuilt our development CRM application server and changed the URL name; however, the CRM Discovery Service still returns the old name.  I cannot find where to update that value on the server.  

    Any ideas?  Thanks in advance for your help!

    Bob

Skip to main content