One of my client’s users came to me with an unusual situation — he could reach the SharePoint pages that host the SmartForms application, but none of the SmartForms would appear. Instead, this MacBook user saw messages that read, “The webpage at {URL} might be temporarily down or it may have moved permanently to a new web address.”

The user works in a remote office, and uses the application infrequently, as needed.

What gives?

On applications like these, where the SmartForms are surfaced through SharePoint, the browser is forced to identify the addresses for the SharePoint server and for the K2 server.

I considered a few different things in my troubleshooting: user and group permissions were the usual suspects; but because I was told his office was an acquisition, and that their machines are not standard corporate issue, I also considered the possibility the office was using a HOSTS file with an old address, or the machine might be running some security software that is blocking JavaScript or sees the two different URLs as a cross-site scripting threat (a complete WAG).

In the end, the fix was far simpler: I asked the user to type the SmartForm URL directly into the browser’s address bar.

I did this to test the notion of a bad HOSTS file, actually hoping the browser would return an error. I was surprised when he replied that he could see the content, and even more surprised a moment later when he asked me what I did to fix the problem!

I guess I can take credit for the action, but not the intention — what I did to fix it was ask him to navigate directly to the SmartForm. How that fixed the problem is it forced the browser to resolve the address for the SmartForm, and to download the server’s (relatively) new certificate.

When the user then tried the SharePoint site again, the K2 content appeared as it should — because the server address had been freshly cached and the new certificate added to the store. #Network+CE