Argh-- WSS will no longer be a server role for Server 2008

Argh. Well, it's official. I knew, as of the release of the most recent build for 2008 (beta), that WSS 3.0 wasn't there as a server role, but I'd hoped it was something internal-- that it would come back.

Well, no. It seems that Server 2008 will not have SharePoint as a server role like it is for Server 2003 R2. This means that, when Server 2008 is released, WSS 3.0 will require a download and manual install, with all of the prep that would require.

Here's one of many blogs about it:
http://blogs.technet.com/windowsserver/archive/2007/10/29/windows-server-2008-and-windows-sharepoint-services-3-0-update.aspx

and a tiny peek at what you'll have to do to install WSS 3.0 on 2008:
http://blogs.technet.com/wbaer/archive/2007/10/30/installing-windows-sharepoint-services-3-0-on-windows-server-2008.aspx

It worries me for several reason. One is it implies that WSS is going to go through a version change soon, rendering my book somewhat obsolete months after it prints. Also, it implies that my existing implementations will soon require extensive upgrades as well-- so much work it boggles the mind. And it doesn't make me feel as if Microsoft is particularly confident about WSS as a product if they aren't willing to add it as a role to their new server product. What are they doing? Is it possible that there may no longer be a free, server role version of sharepoint in the future? (yes I know the blog seems pretty positive about offering WSS for free, but these are early days, and what exactly do they expect to have happen as part of the "development process"?) Is this a sign that MS regrets having both WSS and MOSS at one time and would like to eliminate WSS as a standalone product?

Man I hope not. However, I felt it necessary to give you the heads up. More on how to install WSS 3.0 on 2008 in detail soon, as well as ongoing information about what to expect when using it on server 2008.

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...

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.

extended web apps, a primer on AAM, and why I don' think they secure the way you think they do...

So I am working on the edits for the web application chapter and I am at the end, where Alternate Access Mapping was introduced by, ironically, first extending a web app (not exactly what I would have done, but that's what happens when you give the chapter to another author). It's after that extension though, that everything comes together, the creation of the blogging web app earlier in the chapter, the anonymous access, the self-service site creation, the host header intro. And it is then that I really realized something that had been bothering me.

Alternate Access Mapping is purely a way to teach sharepoint what URLs to respond to, and what content to point them at when they come calling-- with a dash of misdirection if the URL it sends back isn't the one sent by the user initially. But it is also tied up with extending web applications in a way that almost makes me feel insulted.

Before we get to that, here's a pretty beefy primer on the Alternate Access Mapping concept so you understand where I am coming from here (and where I might be going wrong if you want to skool me):

You can have web applications that hold site collections that contain a structure of sites and subsites consisting of pages containing lists, libraries, and web parts (most of which point back at the lists and libraries). All of the site collections get their data for those pages from the content database(s) used by the web application. The site collections get their web addresses from appending their path to the web application's address, like http://sharesrv/sitecol1/.

And if that web application's contents are successful, a lot of your users will want to use it, and may want to use it from several different places-- like the office, home, and at branch offices. So to give those users access to those site collections, you have to somehow get Sharepoint to accept more than one URL for the same web application.

Therefore you can use Alternate Access Mapping and just associate some URLs to the same web application, meaning you can have http://sharesrv for the internal office users, and http://sharesrv.mycompany.com for the external users. As long as DNS is set up correctly, then both URLs will go to the same web application.

So why would you ever want to extend a web application? I really had to wrestle with this concept (no, not to understand the concept, but to understand why). An extended web application is where you create a second IIS Web Site that uses the same application pool as an existing web application. This means the extended web application uses exactly the same content as the first web application.

According to Microsoft and people who repeat what they say, you want to extend a web app' because that second web app' can use different security and a different URL. And if you give that extended web app's URL to users that need to be constrained by that extended web app's security, they will use that URL and be constrained. And what is really pushed is the fact that Alternate Access Mapping is a thinly veiled way of managing the URLs of your various extended web applications.

Sharepoint handles URLs as internal and public (external). Internal URLs are what sharepoint gets from the user, accepts them, and sends back the appropriate data. Public URLs are what sharepoint uses to show the user it's links and usually the internal and public URLs are the same.

That makes sense to me, if you want a different URL for a web app to be accepted by sharepoint, you use a public URL (which made its own internal matching URL for resolution purposes only) and point it at the correct web app. Then the user (if DNS is set up correctly) uses either URL and still gets to the web app. Case closed.

All web applications have one real internal URL and five public URLs they can use. Yes, five. Why five you ask? I ask that too. This where MS muddies the waters. Instead of having a nice clear concept of using alternate URLs for web apps, they decided that, in addition to doing alternate URLs, sharepoint will also use the public URLs as the only way to create and manage URLs for those extended web applications.

Remember those? Extended web applications are IIS Web Sites that point to the same content for, apparently the sake of having a different URL than the original web application and for the sake of being able to explicitly set things like authentication and SSL on the extended web app that is different than the original web app.

You can only have four extended web applications per existing web application by the simple expedient of having only four fields available (default is taken by the internal address of original web app itself). These public URL fields are called zones, and you select from the available ones for a web app being extended when you are filling in the settings for the new extension (so to speak). When you fill in a zone address, which is a public URL, it also creates a matching internal URL so that sharepoint uses that address coming and going, you could say.

Say you wanted to have more than one URL go to the same web application, and you decide not to just type one in one of the public URL fields, but instead you decide to create an extended web application for it instead.

So, you use the URL you want for the extended web app, and assign it a public URL zone. Back in Alternate Access Mapping that public URL will be taken. Everywhere else in the administrative interface for sharepoint, that extended web app will be referred to by its zone name. So if you want to change its security settings or whatever, remember that you need to remember its zone. You won't be seeing it by it's URL anywhere. Furthermore, it's not considered "real", so if you want to make any general web app changes (like enable the metaweblog api), you can only do that for the "real" existing web app it was extended from.

Anyway, you have an alternate URL to access the original web application's contents. You can apply security to that extended web app so the users who use its URL to get to the content will have to comply with its security requirements, like SSL or Kerberos (eek).

So now you're with me: how using extended web apps ties up and limits Alternate Access Mappings to these arbitrary four public zones. Muddying the clear waters of alternate addressing with forcing the alternate access for an existing web application to a few public URLs with a strong insistence that those should be extended, extra IIS Web Sites pointed at the same data.

And also I have a concern about this whole alternate web apps with different URLs thing implying that it will somehow secure sharepoint sites by simplygiving the different groups of users the URL you want them to use.

And, of course, that'll work, right? They'll just be happy using that one URL. They won't confer with their buddies and find out that james uses a different URL than they do, one that lets him see things on sharepoint pages without logging in, right? And, even if they did, they'd never be tempted, nay driven, to use that URL instead, would they?

I find the idea of security through expecting users to freely comply to be bad practice. Unless you have only one internal URL for the office, and one URL for outside of the firewall, I don't see how the users are not going to figure out how to cheat. Hell, internal users can use the external address if they want to, so even with two URLs, half of the users can be exposed to data they possibly shouldn't, or security settings you weren't expecting.

And that's why I am bothered by zones, extended web applications, and alternate access mapping. Because they strongly imply that admins must create more IIS web sites to use for public URLs, which they seem to think will corral those users and get them to access the site collections using only the URL they suggest. And then, to allow only four public URLs per web app, adds insult to injury...

...Frankly, what I have come up with, and this seems to be true of most things sharepoint is that there is no why to a feature that is there, or how it works, or how its set. The point to sharepoint is not that it was meant to do something in particular. Often we find a use for it that has nothing to do with what we were told it was meant to do, we use it because of what it does. The point to sharepoint is not that the option, feature, or setting is there, specifically, for a single use or reason. The point to sharepoint is that the option is there if you have a reason for it. If you want it, extended web apps are there for you. If you want, you can use the public zones for URLs you type in that are not part of the extended web apps. You can use SSL, Kerberos, or Anonymous Access on either or both the original web app or the extended one. And, finally, you can try to tell only those users who need to have a certain kind of access to use a certain URL. It's up to you.

This is how I am feeling during the last few hours of editing chapter 8, if you're wondering.