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

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.

Interesting URL trick-- How to Get a SharePoint Server on the Farm to Use Its own Local Central Admin Site

So I am in the end run for editing the book and I, of course, ran into something that has absolutely nothing to do with what I am doing...

...Bill Baer has a great little blog article about changing the URL address of a Sharepoint server's default Central Administration site.

I've always hated how, by default, even if you enable Central Administration on a second (or third, or fourth) sharepoint server in the farm, that server never actually points to its own Central Admin site's address.

Now I've always thought that I needed to add it in the Alternate Access Mapping, but according to Bill Baer, it's a registry thing. That each server has a hardcoded URL that it uses for its access Central Administration site. According to the blog entry, you need to change the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS. Locate CentralAdministrationURL and edit the value to reflect the desired location.

Check out the blog entry at: http://blogs.technet.com/wbaer/archive/2007/08/30/sharepoint-3-0-central-administration-url-on-multiple-web-front-end-servers.aspx