var context = Xrm.Page.context; var serverUrl = context.getServerUrl();
However there are a few issues with the context that this returns. For example, if I open up a contact form that has some fetch logic on the CRM server, then form opens up and renders cleanly. However opening the same contact form remotely will result in an error such as the one shown below:
The reason for this is quite simple:
When running CRM from the server, the URL does not need to include the domain name. For example: http://crm/org1. However when running from a client machine you need to specify (in certain scenarios) the full domain in order for CRM to open e.g. http://crm.acme.com/org1.
The problem with the context.getServerUrl() command is that in both of the above cases it will return http://crm/org1 (without the acme.com) which is going to be valid when running from the server but not when running from a remote client.
Although I have not confirmed I believe there will be similar issues if you're running CRM over https i.e. it will cause browser security warning popups to be issued as the command will try and execute over the http context rather than https.
The solution that we found (thanks to this post) was instead to use the following syntax in favor of the more standard formula listed above:
var context = Xrm.Page.context; var serverUrl = document.location.protocol + "//" + document.location.host + "/" + context.getOrgUniqueName();
The result is that when running CRM using the http://crm/org1 URL, serverUrl will return http://crm/org1. And when running CRM using the more fully qualified http://crm.acme.com/org1, serverUrl will correspondingly return http://crm.acme.com/org1. Which of course is what you should expect.
And this small tweak results in the experience being the same no matter which machine CRM is accessed from.