SharePoint site down, repeat, site down....

Well, more issues concerning Microsoft releasing hotfixes that completely ruin otherwise perfectly fine installations of sharepoint.

And again I say, do not ever install Microsoft Updates for your production servers without first checking to see if you need the update and can survive the consequences (backup, backup, backup, don't forget to backup before you apply it).

So a great many people have had either Central Administration become unaccessible, or all of their sharepoint sites.

There are blogs that have suggestions, one is vlad's http://www.vladville.com/fixing-sharepoint-30-with-kb932091, and one is a "near official" Microsofty's blog entry-- http://blogs.technet.com:80/wbaer/archive/2007/10/15/kb934525-troubleshooting.aspx. Check these out and see if they help.

And if you are wondering why I am not suggesting fixes step by step-- well I usually don't do step by steps if I don't need them. And, I didn't install the hotfix on any of my servers because they didn't need it. So I have not had any problems.... Mind you, if I had needed it, that would be a different story...

Yikes, Oct. 9 WSS 3 .0 update

So there was a big rollup hotfix released for WSS 3.0. And maybe you're thinking you should just install it because, well, it's got to be good.

Before you do, consider this:

• It cannot be uninstalled.
• The hotfix will, somehow, be wiped should a service pack be installed, along with the fixes it applied.
• It has problems with host headered site collections, search, and on SBS, restarting the sites themselves properly.

Don't believe me? Read it yourself (and more) at http://support.microsoft.com/kb/934525/.

Before you install a hotfix/update/service pack always check the known issues to see if it is worth the risk, or if it breaks more than it fixes. Now you know.

If you installed the hotfix that updated WSS so that it stopped secretly sending information to Microsoft about your server without your permission, then it is possible that, after installing the Oct. 9 hotfix, your sharepoint site will completely cease to function. It will look like a database problem, but no database fix will seem to work. If that's the case, you need to uninstall the 932091 update, then reinstall it. See this blog entry http://www.vladville.com:80/fixing-sharepoint-30-with-kb932091 from some guy named Vlad for more details.

Just something conceptual... anonymous access

I am now editing the end of chapter answers and I am doing chapter 8. One of the questions (mind you I did not write these, this is one of the chapters I didn't do) is about enabling anonymous access.

But it got me to thinking- the solution just glibly says that to enable anoymous access on a list or library you first enable AA on the web application, then you enable list and library AA at the site collection level, and then enable it at the particular list or library you want to allow AA.

Okay. That works.

But then, messing around, I forgot which web app/zone I enabled anonymous on. So I had a web app at http://sp2:8080/, and an extended web app at http://blogs.dem0share.com/; both pointing at the same content.

I enabled anonymous on blogs.dem0share.com, just to go through the steps in the answer to make sure they were correct. I then browsed to the site, assuming I'd have to log in before enabling AA at the top-level site of the site collection-- and wasn't prompted to log in.

?!

So I checked the permissions page's anonymous access settings and Entire Site was already enabled.

What's this?! I just enabled AA at the web application. I haven't set it yet... wait a minute, maybe I enabled AA on one of the other zones for the web app.

And sure enough, I had.

So here's the simple concept-- Site collections only have one anonymous access setting. Regardless of how many web application zones are used to funnel users to the sites, if one of the web apps allows anonymous, and the site allows AA at the entire site level, then you cannot enable AA on a different URL (zone) accessing the same site collection and expect to be allowed to have different site collection settings. When you enable AA for a URL, it simply unmasks the anonymous access settings for the site collection already being enforced. If AA is not enabled at a URL, then that option is not available for the users when they access the content.

But what we are taught is-- pick a URL, allow anonymous, then enable the specific kind of anonymous you want at the site collection level. Therefore, the next logical step would be, each URL that accesses the same site collection should be able to set different site collection access- which is wrong.

I guess, when you look at it like this, it's silly to even question. But I was still taken aback to find the site collection pre-set for anonymous when I innocently enabled it at the extended web app level. So I thought I'd just reinforce the concept-- don't enable anonymous on a URL without first checking to see if there are any other zones accessing the content that are already AA enabled. And if so, see what their content is set to allow.

Why do imported sites need to worry about versions?

I wrote faithfully about the STSADM Import operation in the book-- that it has a parameter about preserving file versions.

But why? Why is it there?? The import has to be done, by definition, into a blank, empty site. There is no -overwrite parameter, so what versions is it actually going to mess up? Is it going to go back to the original and pull the newer versions in? What is that about?

I am going to mess with this further when I have time. Meanwhile, if any of you out there have an answer, please let me know....

More Microsoft Crazy Making

I've caught a summer cold and am a little slow on my rants and announcements, but I just had to mention this (on the coattails of my rant last week).

I was editing chapter 10. I was going to be done early (yay me) when I was checking the next to last setting on the Application Management page-- the HTML Viewer.

I had written the section, having used the viewer configuration in the past, expecting to really challenge it when I had more time in author review.

Well, this is all the review I was going to get. So I fired up an XP workstation VM and added it to my little Sharepoint VM network to use it to host the HTML Viewer service and Office, so I could set up Sharepoint to point at it.

Then when I had the VM up, I went online to download the HTML Viewer from Microsoft, as you do... and it's not there.

It's not anywhere. Its page has been removed from Microsoft Downloads, all the mirror sites don't have it. Google cache doesn't have it, no one has it.

Troubled, I started searching. HTML Viewer is still supported on the WSS v2 site-- although it points to the dead link for the executable (htmlview.exe). But if you go to the WSS 3 site, or MOSS's for that matter, it is absolutely not mentioned. ANYWHERE.

I then went to the WSS 3.0 Technical Library on Technet's site. It is not mentioned anywhere. It's as is MS doesn't want to admit it ever existed... but the setting page is still right, smack dab on the freaking Application Management page!!

If they didn't want us to use it, if they were going to sneakily just take the necessary component to configure it away, why did they leave the page to configure it still in the interface?!!

Argghh.

So I left the info in the book, changed it to say it was for pre-existing configurations of HTML Viewer, and wrote a sidebar flatly stating that I think the feature has been deprecated, that possibly it is waiting for the Office 2007 HTML Viewer (dare we hope?), and otherwise it was really not meant to be used.

Okay, maybe that was bitter, but by that time I'd lost hours, it was after 2am and I was suffering from a brand new cold.

So now you know.

Argh, Microsoft drives me crazy-- Or how there is no global blocked file type list

Okay, here's my rant of the day--- how the heck does total misinformation about the way sharepoint works actually make it to the darned Sharepoint interface?!

---Oh no wait-- is it because, despite the fact that I am using WSS only, this interface mistake is correct if you have added MOSS? Would they do that? If so then they need to strip non-WSS data out of the WSS interface----

So I am editing chapter 9 now. I am about halfway through, but you know me, I've got to challenge everything, even when I am in a desperate hurry.

So I got to a bit about the Blocked File Types. This chapter is supposed to be a quick reference, part way through the book, of the settings for Operations in Central Administration. Most of the real meat is in other chapters of the book (although, with the ones I didn't write, I can't be sure), but I want to be accurate, even if I am just blurbing.

So, on Blocked File Types page I notice some text at the top of the page itself. Something written there like a quick tip or suggestion about using the setting --- and it is wrong.

This is WSS 3.0, not an earlier version. It says: NOTE: To allow a file type that is currently blocked you must delete it from both the global and Web application lists.

THERE IS NO GLOBAL LIST ANYMORE, at least not for WSS 3.0. That statement, right at the top of the page, is outdated, misleading, confusing, and wrong. I can understand when a blogger, writer, or speaker gets it wrong. They don't work at MS, they are working on second hand information. But when the Sharepoint team itself, within MS, takes it for granted, without testing, that unblocking blocked file types is a two step process, when then I just despair.

It makes my job so hard when I can't even trust Microsoft to get it right. And what's worse is it makes people who are hardworking and dependable in the industry say things that are wrong because they picked the data up from the darned interface itself.

(here's an example http://www.sharepointblogs.com/ssa/archive/2007/05/09/unblocking-blocked-files.aspx)

And if someone disagrees, they do sort of vaguely, or maybe I'm the only one who has truly noticed: http://www.sharepointblogs.com/mattg/archive/2007/03/13/blocked-file-types.aspx. This guy mentions (sort of, there's no "more..." to the article) that the setting should not be on the Operations page in Central Administration because it is set by web application and then almost mentions that it would be understandable if there were a global list....

Try it yourself. In WSS 3.0, go to the blocked file types page (Central Administration/Operations/Blocked File Types) and read the note for yourself. Then remove a blocked file type from a web application on the page (select the correct web application from he drop down, then delete an extension from the list). Click OK and go to a library in that web application. Upload the now unblocked file type and see that it works. No error page, nothing. No two step process, no going to search on the server to find the global.asax page or whatever to try to remove the file type globally.

this is the third such mistake I have found in the interface itself. It's so sloppy...

Sigh. Okay, rant off. back to work.

SQL 2005 collation matters to WSS

So I am reinstalling SQL 2005 on one of my images so I can have my TE edit chapter 15. It's been about eight months since I've had to install and configure SQL and I completely forgot the collation requirements for Sharepoint.

I've got them now, and since I'm here I am going to record them for safekeeping.

WSS needs the collation to be Latin1-general, case insensitive (don't check it), AS, KS, WS.

Keep it in mind. ; )

Oh, and by the way, you need the workstation component to get the system manager, and don't forget to open remote connections with the surface area configuration manager....