I ran into an unusual little problem this afternoon while playing with an unusual environment configuration. I say the environment configuration is unusual because the host that contains my Basic MOSS installation isn’t a domain member; that means no DNS and local security accounts—ick. The problem itself is actually quite common but my solution, given my environment setup, is a little unusual, at least for me.
Before diving in, a bit of background: I’m running an x86 Windows 2008 VM on a x64 Windows Hyper-V host machine. The VM has a normal Windows computer name, MOSS is installed in its basic configuration (SQLExpress, using local accounts), and there’s no domain controller or DNS server in sight. I’ve got a simple web application created on port 30000 running as Network Service and extended into the Internet zone with anonymous access configured. A site collection was created before extending the web app and it’s using the Publishing Portal template. Everything is working fine across both sites within the VM.
The problem arose when I decided to run a quick sanity check and access both sites from another machine on the network. After allowing access to both ports in the Windows Firewall, I was able to browse most of the default page, although with no DNS in place and no hosts file entry, I naturally had to browse to the VM using it's IP address (eg. http://192.168.0.100:30000). I was surprised to get anything back, assuming SharePoint wouldn’t be happy with the IP address-based request. I say I was able to browse most of the page because the empty Press Releases content query web part was coming up with the ol’ favourite:
Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.
We normally get this very error at Tourism because deployment stuffs up file system permissions; to fix that we grant Authenticated Users Read & Execute permissions on the web.config file, the /bin directory, and everything in the /bin directory for the authenticated and anonymous sites. I tried that first and the problem went away for a minute and then came back as I reset IIS and fiddled with the firewall.
Weirdness. I don’t like weirdness.
Remembering my original surprise, I recalled I was accessing the sites using an IP address instead of the computer name and this ended up as the cause of the problem; an error event in the Application event log confirmed this:
Invalid URL: http://192.168.0.100:30000. You may also need to update any alternate access mappings referring to http://MyComputerName:30000.
To get things working, I dropped into Central Admin/Operations/Alternate Access Mappings and added a new internal URL for both zones:
Et voila! Fixed!
Well nearly. This "fix" now prompts me to authenticate twice when browsing the authenticated site off the VM, once for the IP address and again for the host name. From that point my browser's address bar is also telling me I'm accessing the site via the host name. Not sure what magic the AAM setup is doing there but a minor niggle.
And it’s also worth noting you’ll get this web part error for many other reasons—remember, my environment configuration today was unusual!!