Sharegate really is just damn simple. However, as with any software, the possibility of running into the odd error message, here and there, remains very real. Therefore, it is important to cover common issues, in order to ensure a seamless migration.
Let’s dig into the matter. Here is the situation: the desired tool was selected, and then it was time to enter the SharePoint site URL and, after clicking on the connect button, an error message is prompted.
At this point, the first reflex is generally to confirm that the address entered is valid, by going to the same SharePoint site URL through a web browser. This way, it is possible to ensure that the site is not temporarily unavailable. Great! The site is accessible from the browser, though it still prompts the same error when the connection process is attempted once again
The second logical step is to try connecting with another client application, to confirm that these can connect. There is no need to search all over the place for a client app – SharePoint Designer is perfect for this job, and it is largely available on machines. The rule of thumb is: If SharePoint Designer also returns an error, then it is important to make sure that Client applications are enabled within the SharePoint Server. You can do so by going to the “Central Administration”. Then, in “Application Management”, click on “Manage Web Applications”, select the SharePoint application, and click on “User Permissions” in the “Security” group on the ribbon. It is important to make sure that the “Use Remote” Interfaces – Use “SOAP”, “Web DAV”, the “Client Object Model”, or “SharePoint Designer” interfaces to access the Web site option and make sure it is checked under the Site group. If it is indeed enabled then further investigation might be needed.
On the other hand, if the connection is successful through SPD, then another little trip to the central administration of the SharePoint Server is highly recommended since the evidences gathered so far points toward an alternate access mappings issue.
Managing SharePoint Connection Issues with Alternate Access Mappings
Alternate access mappings are not as obscure as they may sound. Here is what TechNet has to say about it:
“Alternate access mappings enable a web application that receives a request for an internal URL […] to return pages that contain links to the public URL […]. You can associate a web application by using a collection of mappings between internal and public URLs.Internal refers to the URL of a web request as it is received by SharePoint. Public refers to the URL by which SharePoint will format links that correspond to requests that match one of the internal URLs on that zone, when it returns a response. The public URL is the base URL that SharePoint uses in the pages that it returns.”
In plain English, it means that the alternate access mappings contain information regarding the different URL options to connect to your SharePoint environment. The analogy with name is certainly helpful to grasp the essence of how it works. My name is Jimmy De Santis, yet I respond to many other names such as Jimmy, Jim, Jimbo and even De Santis. However, if someone tries to get my attention by calling me Albert. well, he must be ready to wait for a while because I do not respond to Albert.
The comparison to be made here is to see the Internal URLs as my real name, for instance, Jimmy. Through alternate access mappings configuration, SharePoint gets told to respond correctly when it is addressed with those names.
Now, let’s say there’s someone else at Sharegate that decides that every request addressed to Albert will be forwarded to me. When a client comes and says “Where’s Albert?”; it sends them to me. As long as the client’s request is simple like “How are you?”; the conversation will be fine, but if it gets more complex, the fact that I’m not Albert might bring confusion to the conversation. The replies will most likely not correspond at all with the expected information from the client.
Let’s cover a more concrete example. For instance, a SharePoint 2010 Server has the following Internal URL: http://sharegate. What often happens when a new URL is created for a SharePoint server, is that a DNS entry is added so that requests sent to http://sharepoint.sharegate are redirected to http://sharegate, but no alternate access mappings are created. This redirects all requests that use both URLs to SharePoint, but it really only responds correctly to http://sharegate. It might work well with http://sharepoint.sharegate in your browser (which is a “simple request” like “How are you?), but Sharegate involves a complex communication and hence it will not work properly in this scenario.
The solution is simply to add an alternate access mapping so http://sharepoint.sharegate becomes an internal URL, or a known “nickname” for SharePoint.
A missing URL can easily be added to the alternate access mapping list by going to the SharePoint Server Central administration then clicking on Web Application and selecting configure Alternate Access Mappings.
Once there, clicking on add Internal URL and entering the URL will do the trick.
