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:
http://192.168.0.100:30000
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.
192.168.0.100 MyComputerName
And it’s also worth noting you’ll get this web part error for many other reasons—remember, my environment configuration today was unusual!!
Hey, thanks for your post man :D I had a similar issue which wasn't directly related to an IP address; in my case the configuration didn't have a public URL for the alternate access mapping, which made the content query web part display the same error. Your post helped me look in the right direction so I could eventually resolve the issue.
ReplyDeletedirty words? why the name is this? though you are writing good blogs
ReplyDelete@Anonymous: 'SharePoint' was a dirty word around the office when were were implementing westernaustralia.com on MOSS 2007 TR2... our inexperience with the product and a wealth of bugs and issues led to much swearing ;)
ReplyDeletethanks..great hint..worked for me
ReplyDeletebut as an alternate can we resolve it by code access security for that web part?
@Anonymous: No, I don't think so--CAS is a .NET thing whereas this is a networking + SharePoint issue.
ReplyDeleteI'm not sure how similar my issue is to what you dealt with here, but I'll ask my question anyway: I have built a CQWP into several sites on my Site Collection to display a particular item out of a list I have on the main site. It works great, but only as long as I am logged in as a site admin. If I log in as a regular user, I get the "Unable to display..." error. I checked permissions on the list itself, and the regular users have "View" permissions. This is a SP2010 install. What am I missing?
ReplyDelete@CatatonicBug: I'm not developing/administrating much these days but your problem sounds like a permissions problem to me and unrelated to naming/alternate access mappings. You say you've checked permissions--have you tried ramping up permissions for your regular users to see if that helps? Are permissions inheriting?
ReplyDeleteMichael - I think you're right about the permissions issue, but I can't seem to isolate it. Permissions WERE inherited, but for testing purposes, I removed that. The user is able to view the contents of the list directly already. If I give the user "Full Control" permissions on the list, nothing changes. If I add that same regular user to the "'Site Collection' Owners" group (which has Full Control, Limited Access), or the "'Site Collection' Members" group (which has Contribute, Limited Access), the problem goes away for that user. I un-did that, then added that same user to the specific site with the CQWP on it, and gave them "Full Control" of the site, but the problem remains. Shouldn't any user with "View" rights to the site be able to view the contents of the Web Part? Where might I control the permissions for a specific web part?
ReplyDelete@CatatonicBug: You don't normally set permissions on a web part but on a list item, list/library, or site. Just to clarify, are you working within a single site collection and the web part you're working with isn't a custom dev job? If, as you mention, making a user a site collection owner or members group, you're on the right track. Maybe create a new group and fiddle with the permissions until you can isolate the exact permission the users require?
ReplyDelete