Sharepoint Licensing Roundup

In response to lots of questions about how to correctly license Sharepoint, our own Scott Barker helped put together a useful conference call with Microsoft licensing experts.

What follows are my notes on what we heard on that conference call. These notes should not be taken as fact–you should verify their veracity for yourself with Microsoft.

The licensing expert began by explaining the usual way that Microsoft server products are licensed. Generally, you buy a server license, client access licenses (CALs) for each “internal” user, and an External Connector license for each “external” user.

For Microsoft Office Sharepoint Server (MOSS), if you use this traditional approach, it amounts to:

  • Windows Server license
  • MOSS license
  • Windows Server CALs for internal users
  • MOSS CALs for internal users
  • MOSS External Connector for external users
  • SQL Server license
  • SQL CALs for all users (or per processor CAL licensing)

Instead, Microsoft has introduced new specialty licensing for MOSS. The “Sharepoint for Internet” license covers:

  • MOSS license
  • Windows Server CALs for internal users
  • MOSS CALs for internal users
  • MOSS External Connector for external users

In other words, this specialty license is a blanket covering all the licensing, except the SQL licensing and Windows Server CALs.

The licensing expert had a couple clarifications on questions that were asked.

Internal users were defined to be the users we consider employees.

External users were everyone else.

The licensing expert said she would consider our organizational boundaries to include *all* of UW, although I have some serious doubts about whether that was entirely accurate (or relevant), but wasn’t able to follow up in enough detail to get those doubts clarified.

This specialty license does not cover Windows Sharepoint Services (WSS), the version of Sharepoint that comes bundled with Windows Server. WSS licensing follows the Windows server licensing model, so you’d need:

  • Windows Server license
  • Windows Server CALs for internal users
  • External connector (or inpidual CALs for each) for external authenticated access
  • Anonymous access requires *nothing* other than Windows Server CAL

Moving Sharepoint sites

This site is the convergence point of three prior Sharepoint sites.

Those prior sites were:

The convergence of these sites is possible because of a significant milestone for the UW Sharepoint service. That milestone is that there is a suggested cost for that service (which is pending an official announcement).

The process by which these sites converged is technical interesting, and is the topic of this blog post.

Generally speaking, you can export (backup to file) and re-import any Sharepoint site–MOSS or WSS–using special stsadm commands. And in fact, in this instance this is a convergence of two MOSS sites and one WSS site.

One special issue was that the Sharepoint server hosting the old sites was in a different domain. When this is the case, you must either choose to translate security references or drop your security configuration, and recreate it after the import. The translate security functionality has some gotchas. It is a per-user operation which means you’ve got to get a list of all the users. That can easily be done by running the export command once and looking at the log file. Another gotcha is that when you run it to convert say nebula2\user to netid\user it converts *every* instance of nebula2\user in that sharepoint farm to netid\user. This might be very disruptive. A final gotcha is that if the target user you want to convert to has logged in to the source Sharepoint farm, or if they’ve been granted permissions, then the operation can cause destructive behavior or error.

An example of the security translation command is:

stsadm -o migrateuser -oldlogin DOMAIN\user -newlogin DOMAIN\user [-ignoresidhistory]

The combination of these security translation issues left me thinking it was less work to just reconfigure security after the import . Fortunately, the blog site was on it’s own server in the same domain as the UW Sharepoint server, so it didn’t have any of these issues.

An example of the backup/export command I used is:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsadm -o export -url -filename c:\finaltry\ms-collab.cmp -includeusersecurity

An example of the import command I used is:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o import -url -filename c:\temp\ms-collab.cmp -includeusersecurity

The import command will fail if you are not importing to a site with the same site template as the site which you exported from. This is a very important gotcha for when you are trying to converge several Sharepoint sites into one.

And in fact, this site template restriction was a problem for this convergence. The roadmap and wit sites listed above were both from the team site template, whereas the blog site was from the blog template.

To handle this, I decide that the blog site had more content which was harder to manually reproduce via another method, so I went with a blog template, and only imported that site via this method.

For the roadmap site, there were other issues. That site was a subsite of a larger MSCA site collection, and some of the content in the roadmap site had some cross-site lookups to data in that larger MSCA site collection. Those were minimal, and I decided that I could lose those lookups and convert that data to something more static. However, the roadmap site was fortunate in that it was basicallly just two lists. So I exported both lists to a spreadsheet, recreated the custom lists (i.e. recreated columns etc), then copy and pasted the info, massaging the cross-site lookup data slightly.

Finally, there was the wit team site which had a lot of internal documentation. I opted to create a subsite for that, limiting the access to it to internal team members. However, if the goal truly had been to converge, I could have exported all the documents and uploaded them.

So for two of the sites, I used an adhoc approach because it was good enough and was the least cost. However, there are other methods you can use when an adhoc approach isn’t acceptable. has a very detailed comparison of ways to move Sharepoint content around that document some of these other approaches.

Site pages vs. Application pages AND ghosted

There’s so many Sharepoint things I want to blog about, I’m having a hard time writing posts that aren’t long and rambling with multiple topics. You’ll be amused to know that I drafted a post a couple nights ago that I titled:

“((‘Customizing vs. Developing,’ OR ‘Site pages vs. Application pages’) AND ‘What does ghosted mean?’) OR (‘How does Sharepoint render any given page?)'”

I know it’s silly to have boolean logic in a title but I couldn’t resist.

But that post suffered from this rambling syndrome (which I’m already prone to), so it won’t see the light of day. Instead, I’m going to try to break it down into smaller consumable bits.

So … let’s talk about the difference between site pages and application pages.

Site pages are pages which live in the Sharepoint database.

Application pages are pages which live on the server’s file system. Application pages usually also execute code, but not always.

In past posts, I’ve mentioned the fact that most everything in Sharepoint is stored in a sql database, not in the file system. Sharepoint adds to this illusion, by using URLs that make the end user *think* there is a file system behind all the pages they access.

On a well-used Sharepoint server, the majority of pages are site pages. However, on a freshly installed Sharepoint server, most of the pages are application pages. You might have noticed that every Sharepoint site has a handful directories which are identical. They are virtual directories, and each points at the same directory. And in fact, these underlying directories are real–holding actual files on the file system of the Sharepoint server. The actual files in these “real” directories (served via virtual directories on every site) happen to be the .aspx pages that are called 90% of the time any user is interacting with Sharepoint. These files are actually code, grabbing content elements from the Sharepoint database, and rendering a page with that content. For example, if you go to any document library, you’ll get the ‘AllItems.aspx’ page.

That’s the same exact page almost every list in Sharepoint calls to display what’s in the list.

Why would Sharepoint do this? Well, it turns out that this is one of the reasons why Sharepoint can scale to support ungodly numbers of sites. A majority of page requests are hitting the same hundred pages which are cached in memory, with a bit of content elements getting filled in from the (fast) sql database.

Sharepoint Designer is one tool that can be used to create and edit Sharepoint pages. In fact, it’s the primary tool that most people will use. *Every* file that Sharepoint Designer creates or modifies becomes a site page. In other words, Sharepoint Designer can’t be used to create or edit a physical file on the Sharepoint server. And as a side note, there is no offline mode for Sharepoint Designer–it only edits live Sharepoint sites (which has some implications you might want to plan around). If you edit a page which happens to have a physical presence, then unbeknownst to you, behind the scenes a copy of that file is stored in the Sharepoint database specific to your Sharepoint site, and the link from your site to that page which usually sends users to the physical file, now sends them to the file in the Sharepoint database. As an example, if you edit the default.master (which you should never do), you aren’t editing the default.master in the file system. Instead, you’ve created a special custom version of the default.master stored in the Sharepoint db which is linked to from your site. In other words, Sharepoint changes the link from the physical file to the virtual file in the database (and makes a complete copy of your edited version to put in the database).

There are ways to create application pages (i.e. pages on the physical file system), but I’ll refrain from going into that now. I’ll also refrain from delving into master pages.

I will mention that an application page (i.e. it has a physical presence) that has been customized so that it becomes a site page is called “ghosted”. This term is an unfortunate one, because it doesn’t have any obvious meaning. Microsoft is apparently trying to kill off the ghosted/unghosted terminology, replacing it with customized/uncustomized (which are so much more obvious in meaning), but they’ve shot themselves in the foot within the Sharepoint framework (the code which Sharepoint developers rely upon) by hardcoding that terminology there which will likely perpetrate the unfortunate terminology.

Sharepoint Development

So this week I’ve been at a Sharepoint Developer class. This is the second in a series offered by Netdesk, i3602. Many of my prior Sharepoint posts came out of the first class I took about a year ago.

This class is excellent. The instructor, Michael Cierkowski, wrote the course materials himself based on the MS Press book, Inside Windows Sharepoint Services 3.0,

You’ll see quite a bit of interesting code samples downloadable on that website, and if you buy the book, you get the explanations, and conceptual underpinnings. The labs in the class are quite good, based on the idea that the instructor expects you to apply what you’ve learned earlier in the class. In other words, as you go along, you get fewer “step by step” instructions, and more higher level instructions, e.g. “do X–like you did in the last lab but with this slight twist”. It’s harder, but it makes you learn the material much more solidly than most classes.

I’m still getting my head straight about just what I’m learning, and what kinds of things I might blog about out of this class (and I’m only half thru the class too), but right now I envision these posts:

  • ‘Customizing vs. Developing’
  • ‘Site pages vs. Application pages’
  • ‘What does ghosted mean?’
  • ‘What is a feature? What is a solution?’
  • ‘When should I use an application page vs. a webpart vs. a feature?’
  • ‘Customized master page vs. themes vs. custom CSS file’
  • ‘The challenges of developing on Sharepoint’
  • ‘Why should I care about Sharepoint development? (or how to save yourself time and do cool things)
  • ‘Webparts’
  • ‘More on data sources–when to use the Sharepoint DB vs. when to keep the data external’

Of course, some of the material behind these envisioned posts may not materialize enough to justify a post, so we’ll see. And my work time is not exactly without lots of large demands, so it may take awhile to get these out the door, but I figured just the post titles would be interesting.