Local access to your SharePoint 3.0 site

OK – just a quick poll . . .    Raise your hand if you’ve seen this:

You install Windows SharePoint Services 3.0 (either on a Windows 2003 or 2008 server) and create a new web app & site collection.  While the site works great for all of your local clients, and even works externally – you can’t access the site from the server it is running on.  Specifically – when you try to browse to the site on the local server, you get prompted for credentials 3 times before getting a generic 401 unauthorized error.

I’ll admit I have been seeing this for quite some time, but have always been too busy to track down the cause, especially since the easy workaround is to just access the site from another machine.  Well, I finally did some digging and was able to identify the cause & the solution.  This is actually caused by a failing loopback check – which is the exact same scenario that causes the infamous 2436 Gatherer errors for our companyweb in SBS 2008.  And to keep things consistent – the exact same fix for the 2436 errors will fix our inability to access a WSS 3.0 site on the local server it’s running on.

You can find the specific steps on the SBS support blog:

http://blogs.technet.com/sbs/archive/2009/05/07/event-2436-for-sharepoint-services-3-search.aspx

Just add the URL of your site to the BackConnectionHostNames registry entry, run an iisreset and you’ll be good to go!

Where did it all go?

Ok – so I have a somewhat funny story to share . . .    About a week ago, I received a monitoring alert via Kaseya that free space on the C: drive on my SBS 2008 server was getting low.  I logged in to the server, opened My Computer and it showed that I was using 73 GB of my 80GB C: partition.  So I downloaded TreeSize Free to see what was taking up all of the space.  The problem I ran in to was that TreeSize was showing that I was only using 31.9 GB of space on my C: – no where near the 73 GB that Windows was reporting.  TreeSize did indicate that it couldn’t access the C:\PerfLogs or C:\System Volume Information.  I manually verified the PerfLogs folder was empty, and I did find that I had approx 8GB in ShadowCopies for the C: drive that I didn’t need since all of my critical shares had been moved to a different partition, so I disabled ShadowCopies on the C: drive, but that still left me with a 33GB discrepancy between Windows & TreeSize . . .

At this point, I am going to share two crucial bits of information:  1) This is the first time I’ve dealt with low-drive space on a Windows 2008 box.  2)  I’ve been using TreeSize for years, and by force of habit, I always open My Computer, right-click on the drive I want to scan and launch TreeSize from the context menu.   So can you see where I went wrong?

Yep – I was quietly bitten by UAC in SBS 2008.  By launching TreeSize in my normal fashion, TreeSize was not running with elevated permissions and was unable to access all of the directories on the drive, many of which were several layers deep.  Interestingly enough, TreeSize Free didn’t throw any errors when it encountered a directory it couldn’t access.  Once I launched TreeSize Free from the Start Menu with elevated permissions, it was able to scan the full drive and show me my smoking gun – 27GB of IIS logs for the WSUS Administration site collected over the last 12 months.  So after cleaning up my unnecessary Shadow Copies & purging old IIS logs, I’m back to 41.2 GB (51.5%) free space on my C: drive . . .