Monday, December 1, 2008

Hmmm, something fishy about importing subsites to be top-level sites

I was working on some vcasts for this site when I stumbled across something I wish I'd put in the book (see I am still working on it, almost a year after printing...). So without further ado, here's the thing:

You see, I have a subsite that I like to use in my conference presentations to demonstrate this and that. It's a contracting site that I've filled with custom lists, fields, columns, content types, dashboards, views, and lots of data. I like to demonstrate how to create nifty site templates with it, how to manipulate data, connect lists, and more.

So it was a natural progression that, when I wanted to demonstrate custom permissions and how to work around applying an .stp file (the single file that a site template gets packed into) to a top-level site, I'd make an export of that contractor site and use it for the demo.

So I exported the contractor subsite (and the two child subsites off of it-- one for a blog and one for a wiki).

I then made a new site collection and imported the export file to it... and found that not only did none of my workflows 'port, but that the default, three-state workflow was deactivated for all sites in the collection.

?!

I knew that workflows and alerts don't port well, but I was surprised that the default workflow for WSS was disabled. That was unexpected.

But here is why it happened in my opinion (with a shout out to James Finley, who patiently listened to me rant and kindly repeated himself over and over, with screenshots, before the issue was resolved):

When a site collection is made, the top-level site gets created and a site template and site collection features are applied (in the case of WSS 3.0, that means the three-state workflow).

In order to import a site, you must already have a site address to import it to (it doesn't create an address for itself). Because it is going to be applying the template and settings it used previously, there is no need to have a template applied to the new site because it's going to be written over. As a matter of fact, usually, importing to a completely clean new site address offers the best results. Generally, having no artifacts left to write over is cleaner and safer. This has always worked for me when moving subsites and what I tell people...

(( in contrast I must admit, I have very successfully imported over an existing site completely with no problems-- much to my dismay. ; ) I have also had a few hiccups when importing to a site with an existing template-- in front of a live audience-- as well.))

When you export and then import a subsite as a subsite to an existing site collection, the site collection features are already active, so they're available for the imported site.

And when you want a subsite to be the top level site of a site collection of its own (ie, working around not being able to apply a .stp template to a new site collection), you would normally use STSADM to do a createsite without a template, then import your exported site to it.

BUT, if you do that you run the risk of having no site collection features.

Why? James and I surmise that applying the template to a top-level site is what activates the site collection features for the entire site collection. No features at the top-level site means no features in any subsites either.

Think about it, you are importing a subsite to a top-level site-- when that subsite wasn't the one that had those features set originally, it depended on the top-level site of the its collection to do that. Therefore, that import file doesn't have the necessary hooks to start features. Without a template pre-applied, when you import, the site collection workflow doesn't activate at that site address when you import. Instead, you have to go to that top-level site's "site collection features" and activate it manually after the import is complete.

The solution (without manually having to activate the feature every time you import)? If you are going to apply a import to a new site collection's top-level site, apply a template to it first if you want the built-in site collection features. At the command line it's really easy. In the GUI it's even easier, you can't create a new site collection without applying a template.

((or, do what I did once, create a fully functioning site there first, then import over it. It made me sad, but the site collection features were active...))

An example of the commands I am referring to:

a simple export of a subsite: STSADM -o export -url http://wss2/contractors -filename file://dc1/backups/contractors.cmp

a simple site collection creation (with the standard team site template applied): STSADM -o createsite -url http://wss2/sites/contractors -owneremail person@sample.org -ownerlogin domain\siteadmin -sitetemplate sts#0

a simple import of the subsite to the new site collection as the top-level site: STSADM -o import -url http://wss2/sites/contractors -filename file://dc1/backups/contractors.cmp

((note that the export, import, and createsite commands have many more parameters than I am using here, this is just the simplest examples possible))

That also brings me to an old but interesting thought-- as to why MS decided to offer their fantastic 20 sites for site collection administrators as templates instead of import files? Why, in the end, did they end up having to split up the way those sample sites (site admin and server admin) were installed-- making them harder to adopt and apply?

There had been some speculation as to why MS did that. Site templates have shortcomings, one of which is the 50 to 500MB content limit. Also, there are things that don't move well, that work better with export/import.

But, those fantastic 40 templates (even the 20, less fancy site admin templates) were meant to encourage people to extend the use of SharePoint, and especially to purchase and use SharePoint Designer. That meant that Workflows had to 'port intact, for anyone who wanted to use the those sample sites. That means the sites for site admins had to be packaged as templates and not imports, because the workflows won't travel easily any other way.

((of course, an off-shoot of that is if a site is packaged as an .stp file, it can be installed by someone with only site administrator permissions-- hence the categorization. remember, it's not an unexpected or unfortunate shortcoming, if you can consider it a feature...))

And it explains why there are 20 site admin templates that are simple .stp template files, and why 20 are packaged as full solutions (with an additional application template core). Some of the sample sites were just too fancy to package as templates, and had to be offered with separate moving parts instead.

Getting back to the point of this post-- The subject, as to why importing my subsite as a top-level site deactivated the three-state workflow, bothered me. And because of that, I felt it important to let you know that it happened, how it happened, and how to fix it.

It's just one of those little things that might become a big thing at the end of the day on Friday when you thought it would be a piece of cake to move that nifty subsite to a top-level site like your boss asked you to...

.. so you've been warned. As always, check your site features, site collection features, security, versions, and alerts before considering the job done. You know workflows and alerts will be a problem, but check everything, just in case.

11 comments:

Anonymous said...

Hi,

Am still working through your book and have gotten to the backup/restore section. Wanted to ask what strategy to utilize if I wanted to backup a site and then selectively restore a single file from the site? For instance, if a user decided to delete an important file and also somehow removed it from the Recycle Bin but then did not tell me about it until days later. At that point, I can't restore/overwrite the entire site because there would have been changes since the backup but I still need to retrieve that file. Can I restore the backup to a hidden directory and then grab the file(s) that I need? If so, what would be the command to use?

Thanks!

Callahan said...

Yikes HK!! I totally missed your comment!

Thanks for working through my book, feel free to post me here if you have any questions (or using the email addy in the book).

To start with, did you know that WSS has two levels of recycle bin?? That if a user deletes something, and then deletes it from their recycle bin, that the file goes to a second level, the administrative recycle bin, before being truly removed? You might want to check that out. Although you can change the timeout, files don't disappear from recycle bins permanently for about thirty days.

But, what if it's been longer than the thirty days it'd be in the second recycle bin? What if that feature has been disabled for some reason?

I hate to tell you, but there is no way that WSS just restores data to a hidden folder for you to peruse for missing small bits. SharePoint doesn't save it's data like that.

To restore small bits of sites, this is what I do (and it's only what I do, not necessarily MS official):

In addition to regular full farm and differential backups, I also backup the SharePoint databases in SQL, the configuration files in IIS, and the 12 hive.

I then move onto the small stuff. I backup the site collections individually using backup or export (depending on the circumstances). I also backup important subsites, lists, or libraries individually by making templates (this only works if the templates contain less than 500MB, max, and that's with a setproperty tweak).

That's as small as I tend to go with my backups.

To restore them on a moment's notice I either have a spare Virtual Machine (child partition for you hyper V folks) with WSS installed on it, or I create a web application on the server specifically only used for restoring lost data.

Then, in order to get the receptionist's call manual recovered, I just restore the site collection, site, or list/library (depending on the smallest thing I backed up that'd contain her data). I can then simply copy that document to a convenient place, and then email it to her so she can upload it (in case being the owner is a big deal to her).

What I DO NOT do is restore my backup of the site collection, site, whatever *over the top of* a working location. That is, as you obviously know, a bad idea. Restore it elsewhere, a different VM or at least a different web applcation (or even a spare site collection if the item is small enough). Don't put it in the same place as the original.

Some people export each site and then can restore the site under a different name to the same site collection. Although that can be convenient, it can be messy. I prefer to isolate my rescue recoveries to a different address, preferably a VM, web application, or at least a different site collection.

I hope this long winded rant helped HK, and my sincerest, sincerest apologies for the delay.

-callahan

Anonymous said...

Hi CA,

I've been playing around with backing up and restoring WSS. I think the restore to a Virtual Machine is probably going to work best for my situation.

I've noticed that the URL backup method can result in a fairly large file. Is there a way to easily backup each subsite (e.g. https://wss.domain.com/site1, https://wss.domain.com/site2, etc.) to its own file? That way, once we no longer need to use a subsite, I'll burn a copy of that backup file to disc and won't bother backing it up anymore.

Thanks for the response!

Anonymous said...

I am enjoying your book (as I get the time... but I regress...) ;)

I am running things virtually, which helps as far as making snapshots before I make major changes... its good to be able to roll back in a few seconds if need be.

To be honest, I am jumping around the book a bit but I am working my way through it as I can.

I have an Central Admin site up and under it I have http://mysite/ I am planning on putting sites below that (/users /technology, etc). The problem I have right now is that if I add a template on the Cent admin site it's listed there but never has a template offering on anything else.

So on my CA site under _catalogs/wt/forms/allitems.aspx it says ' ITTeamWorkspace (a MS freebie)'

However when I go to start a new site /Technology and pick a template, ONLY the defaults are there.

I have different templates, wsp, stp and loaded the IT Workspace one through the web interface.

What am I doing wrong? Are those not supposed to trickle down? I restarted IIS a few times and the server itself once.

I had another question about email to features. Does each site need an active Exchange box/account to be ready to receive email? I went through the basic setup in the book and can invite users to the site and they get an email, etc but I guess I can't wrap my brain around the incoming portion... the exchange server accepts email to wss@oursite.com but it doesn't really do anything with it. Does WSS actively monitor inboxes and pull the messages?

Sorry for all the questions ;)

Callahan said...

sean C,

Hi there.

I am at a bit of a loss as to where to begin. I guess I'd like to start with "Thank you for buying my book and actually reading it."

Now here is where the loss starts.

Okay, you set up Central Administration. That is good. Without it you can't administer WSS.

But here are a few questions:

Are you running WSS 3.0 or MOSS?

How did you install it? Basic, single server installation? Advanced server farm?

You are aware that Central Administration has its own web application and its own databases, right? That you shouldn't run your content in/on the same content database as Central Administration, right?

You should be using the CA site collection and web application solely for central administration.

If you are going to do anything else with WSS (and of course you are), then you should use a different web application, site collections, etc.

It seems like, at first glance, you accessed Central Administration and started working from there as if it were a viable location to set up all of your company's sites. (please accept my apologies if I am misunderstanding here)

I suggest you don't do that.

But, before we go further I need to know if you're using WSS 3.0, if you know what kind of install you did, and if you are using Central Administration as if it were your top level site.

If you add templates to the Central Administration site, they will be available for that site collection, and not for any other web application or site collection (unless we're talking farm level solutions or features).

However, if you are adding a solution to the farm, then it should be available to other web applications as well-- meaning it's possible that the solution was not applied properly.

So it's very likely that you are adding the templates (especially the stp files) to the wrong site collection (they should be added to the site collection at http://mysite), or you are adding the solutions and deploying them only to Central Administration.

As for email. If SMTP is enabled and set up correctly in IIS on the WSS server, and incoming email is set up correctly, WSS will monitor incoming email in the SMTP drop folder and add it to the correct list or library.

If you have Exchange and WSS on the same physical server, incoming email cannot work, as Exchange is already intercepting port 25 stuff.

The exchange server needs to be able to forward email addressed to the WSS server *to* the WSS server in order for exchange to give email from your users to the WSS server's SMTP drop folder.

WSS itself does not get email per se. When you set up email for WSS, you give it a return address that someone will be monitoring and answering manually.

With incoming email, WSS uses SMTP to check for email in its drop folder and push it to the lists or libraries that have incoming email enabled.

I hope I am understanding you and that this helps a little. The book is particularly useful if you go straight through it. But, since it's so big, I can understand if you have to browse.

Anonymous said...

Hey! thanks for the reply,

I am running in a server farm, yes. Just the one WSS/IIS machine right now though (not MOSS, just WSS).

I have a Central Admin site running. I am using it to create other applications (pools of sites, right?) - of which there are two, ITS and Sharepoint.

ITS is our playground right now, a Blog for users to get some tips about our network, how to add printers, there is a discussion board, etc. That is the root of ITS. I am going to deploy a site /private with seperate user rights for just my team. It was there I was hoping to deploy the ITxxx.wsp template and maybe use it there.

I did go through the index of your book and looked for a different word and am now on page 487, I see that stp's are simpler and wsp files need more work (which is fine).

However, I am still under the assumption that by adding a template to the CentAdmin site it trickles down through everything else, right? I mean that is where major changes in email settings, etc are pushed through all Applications, correct? OR is CentAdmin (in regards to templates) only for CentAdmin/sites/ on downward and not necessarily for seperate applications?

Anonymous said...

The Server Admin Templates are added through the command line options you put in your book. That seems to have worked. Across all Applications/Sites on the server there is now an option when creating a new site to choose 'Application Templates' and from that list you can choose any of the .wsp files added via command line.

Regarding the Site Admin Templates (stp) - I have added them to the CentralAdmin site ok and they do show up under Custom when creating a new Site/Workspace - only on the CentralAdmin site though (which I am not putting content under). I add them and to the other applications/sites running and go to add a new site and that fourth tab, custom is not there, even though I can look in the template gallery on that same site and all are listed. This is referenced on page 486, item 4. I see what is in figure 7.69 but when I go use it, the custom tab is missing...

I restarted IIS and eventually restarted the server to no avail. My last step is to remove all (delete individually, I guess) the stp files and reloading them to one site and see if the show up when creating a sub site.

Thanks for the book and the help so far :)

Anonymous said...

doh... I kept adding the stp files on the same site to the 'list' templates and not site templates... as in my brain is thinking, 'why yes, please list the templates... there is none, so lets load them!'

:)

Callahan said...

LOL sean C. It's nice that the fix was so simple. : P

We've all done stuff like that before.

I am glad it worked out.

Anonymous said...

Yah, it was a silly mistake. ;)

I am on pg 543 now. I added domain users to read only on the blog at the root level, this works. I want them to only add comments. So I go to settings for JUST the comments list on this particular blog but I don't get the permissions you do. I only have the basics - your book shows Add Items, Edit Items, Delete Items, and View Items.
I just have the basics: Full Control - Has full control.
Design - Can view, add, update, delete, approve, and customize.
Contribute - Can view, add, update, and delete.
Read - Can view only.

The breadcrumb (relative to my site name, etc) is the same as yours. The only difference is that you have to be a domain member to see my site, yours is dealing Anon access.

Is there a way to allow just the comments section work like a normal blog? Where people can add but not delete other people's comments, etc? I am doing a Wiki/user to user deal on the same blog but hit the limited permissions wall there as well.

In simplest terms, the permissions are the generic, sweeping ones in my case - where your book is showing permissions based obviously on the list type...

Hope things are good. Thanks for the help.
s

Callahan said...

Hey sean (I am assuming the most recent comment before mine is also from you even though it seems to be anonymous...).


I am on page 543, and the reason the screenshot gives you the options you see there is *specifically because they are for anonymous users*. That difference; between that example applying anonymous access, and the fact that you are not doing so, does make a difference. I think the confusion is you are trying to do something but you are using the steps for a largely different exercise. (I know they seem close, there's a blog there, but what you want is not really what the exercise is really demonstrating)

That figure on page 543 is for setting the permissions for anonymous users on the list. If you are NOT using anonymous access, then you are going to see those settings-- that's standard and that way by design.

The problem is, you are in the site and site collection chapter, which is demonstrating how anonymous access effects a site, while you are actually trying to learn about list permissions or sharepoint permissions overall.

What you might want to do is read the list chapter to learn about applying the item level permissions/edit access, and the permissions chapter to learn about applying permissions, permission levels and groups. This will give you the background you need to do what you need to do.

Item level permissions on a list can limit users allowed to contribute to a list to only being able to edit (or even view) their own items. For more restrictions, you can create a permission level and apply it to the users you specify that can really limit their ability to delete, edit, view, etc. list items.