Enrique Blanco

Exporting Scopes, Crawled and Managed Properties between SSPs

Enrique Blanco — Fri, 03 Jul 2009 22:50:00 GMT

Imagine this, you are a happy developer that is creating a wonderful enterprise search webpart for MOSS, you have created lots and lots of scopes and managed properties in your machine and now you have to install your app in the test, QA and production server and your team also need the app in their machines, you need to recreate the scopes and properties in the machines… This can be a real hell.

If you are in this situation SharePoint Shared Services Search Provider Property Creation is your tool.

Simply export and import, and all the machines will be alike :), really really time saving!

Troubleshooting MOSS Explorer View

Enrique Blanco — Sun, 21 Jun 2009 10:40:15 GMT

Just a minutes ago I came across this whitepaper: Understanding and Troubleshooting the SharePoint Explorer View

Explorer view is one of the features that causes more user complains, the main point about it is that needs the Web Client service running on the client machine and it is not always running, so it might cause trouble.

I’ve seen also problems with IE8 not displaying it, in my VM setup (Windows 2003), I managed to get it running by:

Making sure WebDav is enabled in IIS.
Making sure WebClient service is running in the client machine. Please make sure you run windows update on the clients, this service has suffered from some important vulnerabilities.
Upgrading WSS and MOSS to Service Pack 2.

Hope it helps.

[MOSS] How to force variations propagation programmatically

Enrique Blanco — Sun, 10 May 2009 19:17:20 GMT

In a previous post I talked a bit about variations and since it has been the most viewed post of the blog so far :D I wanted to talk a little more about it.

I’ve seen many searches as “force moss variations”, so I did this post to give a c# code to force moss variation propagation. The solution with the code and the test webpart can be downloaded here, you can use it freely, but I’d love if you let me know :).

We have a simple publishing portal, with three hierarchies “initial”, “secondary” and “third”, we have already created the hierarchies.

So we need to know how to propagate the hierarchies, so we go to the main page of our root hierarchy:

We see there is a menu item which makes what we want, so we’ll use .NET reflector to know which methods does it invoke…

Fist of all we have to identify where the Update Variations option is located, so we’ll open Microsoft.SharePoint.Publishing.dll using .net reflector.

Once opened, we’ll search Variations, and we will find UpdateVariationsAction as the first result, we are lucky ;)

We double click it to show the disassembly, and locate the UpdatePageVariationsLro class with its “Start”, “DoWork” and “UpdatePageVariations” methods (promising!):

When you look a the variations object model you’ll find there is no public method to propagate the changes because everything is internal, so it is a bit difficult to make and we will need to make use of reflection…

So I will create a class DeploymentWrapperHelper which will encapsulate the logic needed to interact with the variations:

We will create this global variables:

In the constructor of the class we will get the type for the deployment wrapper and the actual object to be used with reflection:

So once we have the foundation, we use this function to force the variation propagation, after a few attempts the easiest way to achieve the propagation is calling the Start method:

You can see that we create a list of VariationCreateUpdateError objects (I’ve taken the Create Generic Type Dynamically function from this post by Marcin Celej.), then the running operation job, then we configure the job.

Then we check if we the target variation pages are created, we need them to be created or the code will fail. I tried to create them by using the CreateVariations method of the Publishing Page class, but it failed with a file not found error and created inconsistencies in the variation propagation, so… the target pages must be created prior to run the code.

And the last part is to start the job, it will propagate the changes to the pages. I could make this work from a webpart, not from an external exe, I suppose it uses internally some kind of context object.

The code needed to get the variation settings is this:

So far, we have forced the variation propagation to all the variations, but how can we force the update for just one variation label? Here is the code:

You’ll notice that ugly “try-catch” block, it seems that the problem arises when the systems tries to update the status of the job, the variations get propagated ok and the variation systems continue to work, but the exception is thrown.

The main problem with both utilities is that we need to have the page created before running the code, but it might be useful for certain things since you don’t need to publish the page to update the variations, you can do it with the Update Variations, button, but this code can make the job when updating lots of pages.

First contact with IE8 web slices

Enrique Blanco — Sat, 25 Apr 2009 17:10:00 GMT

IE8 introduced a new element called webslices, it is a microformat that allows the visitor of a page to subscribe to a certain portion of the page. It’s different to an rss since there are no posts or xml involved, only “one time” html, but it shares the concept of “subscription”.

The way to implement that is the same as all the microformats, by using specifically named classes in the html elements of an standard page.

The most basic webslice html looks like this:

<div class="hslice" id="1">
            <p class="entry-title">
                This is the title of the webslice</p>
            <div class="entry-content">
                This is the content of the webslice </div>

</div>

And when rendered, IE applies a “smart tag like” format when you hoover it, and a green icon appears:

If you click over the green icons you can add the slice, so a new item appears in your favorites bar:

In the window that opens you can see two icons: and arrow and the refresh.

The arrow opens the page the slice came from, but be aware: not from the server, but from the request IE took the slice the last time it was refreshed, so you’ll get an old version. I tried it by putting a <%=DateTime.Now.ToString()%> in the slice code.

IE simply requests the page and uses the slice’s html portion inside the “entry-content” div and the headers. The styles inherited from parent elements of the hslice div are not applied and the tags you place outside the entry content are used, but not displayed in the popup, so it is a good place to put the content expiration, references and refreshing tags.

The refresh sign makes a request to the server and gets the results.

Referencing another page

If you want to have only a “pointer” to the slide in your page and reference another page which shows the actual slide content, you can use this tag, this is very useful:

AutoRefresh

You can make the slide autorefresh automatically so your visitors have always fresh info.

You can add an span or div with class “ttl” and content equal to the number of minutes to refresh:

Or to visually hide this you can use this alternative approach:

The refresh tag does not work as I expected because the minimum refresh time is 15 minutes, it has some sense (imagine having 20 slides refreshing once a minute), but it would be cool if you could override this setting when you add the webslide.

Expiration

You can set an expiration time for an specific webslide, for example if its an alert, an auction. What you must do is to include something like this:

<abbr class="endtime" title="2009-04-25T13:09:00+01:00">Expires on 4/25/2009</abbr>

When the item is about to expire, you get notified: the name of the slice gets bold and italic and when you expand the slice there is a warning icon on the bottom of the window:

When the slide expires, IE will mark the slide as expired (in gray) when that time is reached, and an error sign appears on the bottom of the window.:

Misc

It seems that the slices are rendered using quirks mode, not IE8 standards mode. I haven’t confirmed it yet :(

It seems that you cannot execute scripts inside the window unless you specify the “entry-content” class: That is, when you show only a portion of the page, javascript does not work.

You can use NTLM authentication with it, so you can add them to your enterprise apps if you need so. It can be very useful in an intranet-extranet environment, Doron Goldberg has already created a control adapter for MOSS so you can subscribe to any web part in your intranet. Off-topic: Also check the IE search providers for MOSS, they are cool.

A very good article on the topic is Subscribing to Content with Web Slices

There is a Firefox plug-in called WebChunks that implements webslices. I’ve not tried it, but exists.

How we did our last MOSS upgrade. Tips and Experiences.

Enrique Blanco — Sun, 19 Apr 2009 02:01:27 GMT

Last year we upgraded a big customer's intranet, it was a long project and during most of the time there were 4 to 6 people working on it. I'll stay away from most topics covered in Upgrading to Office SharePoint Server 2007 because they are treated there and I couldn't say anything new. What I want to tell you is how we organized the team, some steps we took to perform the migration and some ideas we had to improve the result and the team work.

It's mainly focused on our migration project, but many things can be applied to any kind of project.

I'll omit many client-specific actions (a very big document modification process), so the result can be applied to any migration process. I also won't enter into design customizations, webpart development and such things.

It's very important to understand that you really should "quickstart" the migration process even if the migration at first is far from perfect. The sooner you have something to play with, the sooner you'll find faults and you can start producing productive things.

If you have any doubt, I’ll love to help you with it, just use the comments :). Remember you can also subscribe to the comments thread.

Scenario

The scenario was a SharePoint 2003 installation with:

About 30GB of data (which were doubled to 70Gb due to a recategorization process some months before migrating). Over 3000 webs most of them with a single default.aspx, and a customized document library.
The default area definitions were modified.
About 20 site collections (the intranet, 10 personal sites, and some team sites).
Some pages were modified using SPD.
Over 16000 profiles, 8000 users a day.

Other things (not covered here):

We have to integrate data the data from >2000 webs into a single document library using folders, keeping permissions, version history and all. About 60Gb. We called this "consolidation".
We had to "normalize" the 70Gb data, stepping from the typical lookup columns to a custom column types, and change some of the metadata that wasn't properly categorized.
Some the data (20Gb or so) had to be exported, normalized and imported in another moss farm (the public portal).
We had to make a complete graphical redesign of the intranet, branding and so.
Develop a ton of webparts, both existing and new.

As we had new hardware we chose a content database migration.

Create MOSS Software Baseline

The first thing is to create a simple document (an excel for example) in which you specify all of your servers and the typical developer machine and register all the moss related software installed on everyone.

All machines should have the same patch level, updates and so. It is very important as a bug can appear on one machine while not on the other and then it will be a mess!

The initial baseline could be MOSS + SP1 + Infrastructure Update, if you need an specific hotfix, install the proper accumulative update in all machines and annotate it in the baseline.

It is also a good idea to keep all downloaded updates in network share, and if you have both 32 and 64bit machines download them all.

Install the "DDS" (Dirty Development Server)

That's how I call it :). It is a server, distinct from the "regular development" server,

I want it to perform the test migrations without bothering the team members: In our project in the DDSes (1Gb RAM moss + 1.5Gb RAM SQL2005) the migration process took between 9 and 12 hours so, by doing the migration in a different server, nobody was affected.

The third day (literally) of the project we performed the first test migration (of course the results were mostly useless) but it gave us some initial data to play with. So start doing migrations (even unsuccessful) ASAP.

Know your data and customizations

It is crucial to know what customizations have been performed so you should:

Of course execute prescan.exe. It will give you some info about errors in the DB, customizations made, and unghosted pages.
Prescan does not detect when you have customized the default are definitions. So if you only look at prescan results your migration can lead to unusable data. The trick to detect those customizations is to have a clean SPS2003 installation (with the same patch level as the real production server) and compare the 60 hive with the production one using Beyond Compare or a folder compare tool. Using this you will get all the changes to the definition xmls, the additional images, and everything they could have installed.

Create a reduced Data Set

Once you know what customizations have been applied, you might need to create a reduced set of data to "debug" your migration:

We had some custom area definitions, so we need to customize the XML files located in %12%\Config\Upgrade so MOSS upgrade can create equivalent webs in MOSS and your data get migrated properly. This files contains mappings between files in SPS2003 and MOSS2007, the features required on each site type and things so.

As the only known way to "debug" that XML is to do the migration itself it is a good idea to have an small subset of the data in the server to do quick migrations and quickly fix that XML.

You can:

Install the customizations on a clean SPS2003, and create test areas, and list, inserting a few data.
Take the development environment of the current intranet and delete things until you have a decent but not excessive amount of data.

The idea is to have at least a small amount of data of every list template and site template, so the migration could be performed in your laptop in about and hour or less.

Create target Content-Types

If there are list customizations, you have to create the features for the Content-Types matching those list data. Be sure that not only the name of the fields are the same, but also the internal name of them, because it can lead to some problems.

Remember that the content types must match only the columns referenced in the site definitions, not the columns added though the user interface, those columns are migrated automatically.

That features are the ones that need to be referenced on the %12%\Config\Upgrade XML files.

Every developer works in his own environment

Working on a central server is a thing some people do but I can only see problems. Every developer should have the environment on his PC. As simple as that.

They can have all the data or the reduced data set, but they need to develop on their machines.

The size of the data is not such a problem when using today computers, I had attached a 100Gb database on my laptop and survived. Believe me. What is more, you should have a decent amount of data locally to test with, we had a problem we didn't discover early because the developer only had 50 docs or so in the library and accessing the items collection was not a problem, when we tested that code with 10.000 docs the problem arose...

The development server should be used to integrate everything.

Distribute the Content-Types to Developers

Once you have at least the initial content-types, your developers can start working with them in the webparts, search and things so.

So provide them with the new versions as they become available, but it is important that they (even more if they are not very experienced) start to work with the content-types ASAP.

Refine Migration Process by Iterating

Using the data of the reduced set, and the XML, all you have to do is migrate, check, fix and migrate again. Don't be fooled by the fact that you can open, see or add a new version of the item. A very good test is trying to move the item from one folder to another and then from one library to another, if it moves it is likely to be OK.

If it does not move, you can create a new item and compare the metadata with a migrated one using SharePoint Designer: The migrated will contain the metadata (field names, internal names, guids) from the migration, but the new one will contain the metadata from the Content-Types. If they don't match, modify the Content-Types to match the columns in SPS2003.

This process took us a very long time, but since we had a near real Content-Types by the first weeks everybody could work based on them.

Automatize as much as you can!

Make batch files, stsadm commands, and everything you need to avoid repetitive tasks.

We had a batch that performed the migration, exported, imported, normalized data... It made 85% of the migration itself. Repeatable and not error prone.

You can create scripts that install solutions, activate features, move webs, create webs, upload docs,... Gary Lapointe stsadm commands are a must.

The goal can be that a developer can delete his working web app and create a new one with all the features in less that (let's say..) 20 minutes. It should not be painful or take a lot of time, recreating the working environment in our case was something quite usual.

We also did a lot of stsadm commands to make the migration work easier:

Re-ghost pages in a branch of webs.
Configure the layouts of the pages of a branch of webs.
Configure the themes used by a branch of webs.
Delete an specific webpart in a branch of webs.
Export a page webparts and configuration and import in another page (great for designing and configuring a page in the development environment and moving it to production environment).
Modify the web.config in all servers of the farm by using the SPWebConfigModification class.
Many more

Since we needed to do a lot of web structure modifications, we made an utility in where you altered the web tree of the site and generated a batch file that performed the site creation, moving, renaming and deleting. So you could do it in your dev environment once, and test it many times in the test migrations.

Of course it is absolutely recommended that you use solutions for the deployment, they get propagated “automagically” to the servers in the farm, so the maintenance gets greatly enhanced.

One tip for multiple frontend farms, install the features by hand, not by a bat (or use a bat with pause statements), the reason is this: when you deploy a solution, the command exits before the solution has been deployed to all the servers in the farm and when if you activate them right away they might not be actually deployed so you might get an error.

There are some utilities in Codeplex to export and import the search settings, managed properties and such configuration things, you should take a look at them: you invest 30 additional minutes now and you save 2 hours and a headache in the real deployment :)

Migrating Profiles

We did not migrate the profiles, we simply re-imported them. Since there was nothing special and all the profile data came from the AD, there was more work in migrating the profiles than in importing them again.

The only "special" thing we did was to change the LDAP query to import only the active profiles instead of importing all the accounts from the AD. There were literally thousands of inactive accounts that shouldn't be imported.

The original query was:

(&(objectCategory=Person)(objectClass=User))

And our query:

(&(objectCategory=person)(objectClass=user)( !(userAccountControl:1.2.840.113556.1.4.803:=2)))

Advance as much work as you can

Since we did not migrate the profiles we installed the farm some days before, we created the webapps, set up the SSP, imported the profiles and QuickLinks, installed the features, did a test migration, create the managed properties, search scopes, etc and run some performance test on it. The older intranet was still being used.

It was a fully functional test migration, after that we deleted the content db using the central administration and re-migrated the real database. All the ssp config, profile importation, quicklinks and so was in place before the migration took place.

That test migration was very useful to get timings of how long would it take to complete the real migration (they were the same) and helped us to synchronize with the team that was migrating the public-facing portal that needed some data from us.

Identify the URL changes due to the migration

It was very specific to us, but helped in the alert migration and user links migration. The main point is that in MOSS all the bucket webs disappear and the site URLs get changed, so a site like "/C11/Product" can become "/Portfolio/Solutions/Product". The bucket webs were that estrange "C-Something" webs that ruined your URLs :)

Now they are gone, so most of your webs will change the URLs. We wanted to have a matching database to identify SPS2003 sites URL with MOSS2007 URLs.

We did an small utility that parsed the "Upgrade.log" file that the migration process generate and stored the site id (does not change during the migration process), old URL and new URL in a database table.

This “correspondences” table was used when migrating the alerts and the personal links of the users.

Migrating Alerts

We did a custom stsadm command to recreate the alerts, it read the alert data from the Service database in 2003 and created them again in the new places using the data from the correspondences table.

The tables in the 2003 Services db were sub_SubscriptionDetails, sub_UserSubscription, sub_SubscriptionChannels, we read the data from them and create the alerts using the SPWeb.Alerts collection.

To identify the user we matched the emails of the alerts with the emails we got from the user profiles of the SPSite.

One of the points that lead to this approach was the data consolidation we needed to do, but also we weren’t able to attach the servs db as we saw in some blogs, so we got a solution using this approach.

Migrating QuickLinks

When migrating QuickLinks we used a similar approach as in the alerts, we read the data from the QuickLinks table in SPS2003 Profiles DB , and inserted it in MOSS using the QuickLinks collection of the UserProfile object.

This was very straightforward. The groping of the links keeps just like it was on 2003.

Migrating the Personal Sites

We migrated the few personal sites just like they were, as the number of sites was pretty low we kept them that way in the same web app as the intranet.

If the number were bigger I think we should have moved them to another webapp in another db. The procedure would have been migrating them first and then moving the site collections using stsadm commands.

A very first look at Mono, mixed feelings

Enrique Blanco — Sun, 12 Apr 2009 13:44:12 GMT

During those past holidays I've been taking a very very quick look at Mono. It's an open source clone of the .net Framework which can run on windows, Linux, MacOs, etc, it is sponsored by Novell.

Claims partial support for ASP.NET, ADO.NET, Windows.Forms and is binary compatible, also claims full support for C# 3.0, that is: in ideal conditions you can take the exe or dll from visual studio and run it over Linux. I've tried that with a "hello world", and it works :).

It is not only multiple OS capable, but also runs on ARM, s930, PowerPC. I've not tried that.

They provide a migration analysis tool which inspects your program to look for possible incompatibilities when running it over Mono.

The fastest way to start looking at it is downloading a linux vm with all installed selecting the VMWare download in http://www.go-mono.com/mono-downloads/download.html

Mono has created a control toolkit that mimics Windows.Forms so you can use just the same controls in windows, linux, MacOs. They have also implemented Gtk# which means that you can use gnome libraries in Windows, Linux and MacOs.

There is also an integrated development environment called MonoDevelop which is quite pulished, supports plug-ins for nunit, subversion... You cannot visually edit asp.net pages (sincerely I do not know if it's good or bad, think VS editor is a bit crappy) or windows forms apps (if you use Gtk# instead of Windows.Forms you can). You can open visual studio 2005 projects with it, and work with them.

My feelings about it...

I think that this is a tremendous effort to provide a reliable, really multiplatform framework implementation, and MS should sponsor, support and learn from such an initiative, creating synergies and enhancing both Mono and .NET. It makes me sad reading that if you have used reflector to look at .NET code you cannot contribute to mono.

I want to test it properly before giving my opinion about technical issues and controls usability.

The problem when selling this solution to a customer is that such a big effort looks a bit "unfocused": there are plenty of things not fully implemented and some other that are being created anew while the others are not fully finished...

It's not clear if they have focused more on the client side or on the server side, and that is a problem, you could say "on both of them" but I'll have to see it to believe it. There are few widely known applications (except maybe Paint.Net, but its not fully ported it seems) that make you feel confident about it.

So... what do I want to do? I'm trying to port some of my applications to Mono, and get real feedback about it.

I hope someday I could propose one of my customers to use Mono for their multiplatform apps.

Where does the value come from?

Enrique Blanco — Wed, 08 Apr 2009 11:44:13 GMT

It’s simple, but sometimes leads to frustration, the value comes from the user.

You can give the user the best technically possible, user friendly, powerful application, but it is him/her which gives the value to it. You must “sell” the application to the user, convince him to use it.

Many times the question is "are you building the application that the user needs?” but sometimes you build the application you want to build or the application you think your user needs.

A user given an application which does not give any value added over the old solution, simply wont use the new, I’ve seen (literally) hundreds of thousands Euros spent in projects that simply don’t do what the user wanted the way the user wanted. And that project never was used.

So, talk with your users, try first to get their real requisites, needs and hopes and then, only when you got it, give them a brilliant technical solution, which sometimes will be a lot different of what you initially thought they would need.

Make a prototype show it to them, let them play. Show them the advance of the project, do anything you need to satisfy them, because if your users are not happy your work will be in vain.

Inspired by this post.

Are you X or Y?

Enrique Blanco — Mon, 06 Apr 2009 20:47:04 GMT

One key factor in the success of a project is the motivation of the teams member, I think there is a common misconception in the heart of many “hardcore-techie” about the “goodness” of the team members, we cannot pretend everyone is as motivated as us, everyone will love their job just like we do or even that everyone will give their best at it.

There is a theory by Douglas McGregor called “XY” which relates to management styles (X for authoritarian and Y for participative). It distinguishes the management styles based on the image of the employees from the manager’s point of view:

Theory X: Employees are inherently lazy and will avoid work if they can: Low-motivated, dislike work, avoid taking responsibilities, little ambition, no initiative. This management style often produces micro-managing, mistrust, and constant pressure.

Theory Y: Employees, under the proper conditions, may be self-motivated, and exercise self-control: They enjoy working, and love doing it well, and eventually they like to take more responsibilities, they are motivated. This management style leads to comfortable, communicative working environment and IMHO way better results.

Of course X and Y are extremes and most people don’t fall exactly in one of those categories, the basic model is very rigid, and has been critiqued for it.

But… if we take it as an starting point for self-reflection:

How do you think your manager sees you? Why?
and from the bottom of your heart… are you X or Y?

PD: I bet that if you’re reading this you mostly fall on the Y side ;)

Evaluating a professional CMS solution

Enrique Blanco — Sat, 04 Apr 2009 13:38:38 GMT

I’ve been thinking about some alternatives to MOSS when the customer can’t afford the license cost, or simply it is overkill due to the necessities, so I’ve made this list of questions to evaluate a CMS solution aimed at a professional environment (In no particular order):

Scalability

Will the solution escalate to support your expected user base? And your content base?

You must evaluate the size of your expected user base an the document corpus size, and make sure the products supports such figures. You must evaluate the storage mechanism and check that it supports such a size.

Are there any similar sized portals based on that solution available?

I will not try to be the first breaking barriers, if you are obliged to, try to make a test before using such a load.

Is the solution load-balancing friendly, uses lots of session objects and so?

They will usually be, but you might need to configure affinity in the load-balancing, or things so. Remember that you may or not need load balancing.

Caching mechanisms

Does the product provide a caching mechanism?

The pages are usually cached, can it be switched on or off for specific pages? Where are the cached files stored? Does it provide some kind of blob cache mechanism?

Does it work alright when there is some kind of security trimming?

If different elements of a page are shown to different kind of users, does the cache properly handle that?

Search capabilities

Does the product provide good search capabilities?

Not only a simple search box, but a more complex query page, a way to create custom searches, make contents searchable or not.

Can it search in the files hosted?

If it can store files can it search in the contents of the files? is the architecture open to support more kind of files, like the ifilter architecture.

Can you add custom attributes to the pages, files and search for them?

If you need to create categories of file, distinguish between file types, document types, languages, you might need to add custom attributes to the files and pages.

Supports search over a little portion of the data stored?

Can you create search scopes to search only on a portion of the pages? Are the scopes easy integrated in the search page.

Active directory/LDAP integration

Does the solution integrate with your corporative LDAP for editors and non-anonymous users?

Will your editor users log into the application by using their domain accounts, or will log into the cms using another set of user and passwords managed by the product.

Does it provide a way to extend the membership “stuff” used? Membership providers, etc?

Suppose you need to implement a new membership system (imagine an internal/external deployment with users both inside and outside the organization), is it easy/possible to implement? Does it use a standard membership provider?

Integration with another applications & Development

Can it be integrated with another applications? Search engines, external web services, translation services,…

Does it provide out-of-the-box mechanisms to integrate it with standard (or de-facto standard) external applications:

http://www.opensearch.org/Home
LDAP
http://akismet.com/
Translation (google, live)

Does it provide a documented API to extend it? Any webservice provider?

If you need to programmatically add features to the product… Can you access the product’s object model? Is it extensible? Has a plug-in architecture?

Is there a good support? Is the source code available? Is there a proper developer base?

This is a must. You need support, documentation, a good developer base. think of your daily work, you get more information from blogs than from the official sources, don’t you? So look for blogs, forums, etc.

Can you extend the administration interface?

You might need not only extending the visual public-facing side but also extending the administration interface to, for example, provide an alternate html editor, or integrating some of the customizations you are going to made.

File Storage capabilities

Does it provide a good file storage mechanism? Libraries, folders or so?

Can you create folders or libraries or the product provides a single location for file storage? Is there a maximum number of files, can you create folders?

Can the folders be security trimmed? Need to be an admin to upload a file?

Can you select which users can access a file or folder? Can you select which users can upload a file or only the admins?

Content deployment between servers

Can you implement an edition farm and a publication farm?

In some/many big customers the typical deployment is a private-facing farm in which the editors edit the content and another, public-facing farm which is used by the visitors. If this layout is necessary… can you implement that?

Can you transfer the contents between servers or environments?

For a layout like the described before, or for transferring the contents, can the product suit your needs? What method does it use to transfer contents? Does it bypass the firewalls between the internal network an the dmz?

Capable of creating accessible sites

Is it easy to implement an accessible site? Have you seen one?

Many institutions require AA level accessibility for their public-facing websites, the product must be able to provide JavaScript-free, clean html at least in anonymous mode.

Does it provide standard master pages or templates?

The learning curve an the design integration process gets better if you can create standard master pages or templates that are easier to create and integrate by designers and developers. If I can avoid products with custom script languages and so on, the better.

Solution deployments between environments

Does the product provide a way to install or deploy solutions? Can you package and upgrade your customizations?

Once you have created your code, customizations, master pages, images, etc… Can you easily package them and deploy on other server? Can you upgrade them once installed?

Does it seem to have been designed for operation in the typical development, QA and production environments?

Many solutions are only thought to be installed on the production server, so implementing it over the three stages is not their natural operation mode.

Installation

Is the installation suitable for your hosting environment?

There are products with near zero installation (database + pages), and other rely on windows services, etc. Be sure you can install it on the target machines before you select one solution.

Multilanguage

Can you easily create Multilanguage sites?

Does it support multilingual sites? Are they easy to implement without programming? Is the editing interface multilingual or only the contents?

Can you tweak the Multilanguage capabilities?

In my MOSS experience variations have been always a problem, replication, drafts, etc. It would be cool if the product you’re choosing lets you configure things such as automatic replication, draft creation, translation webservices and so.

It seems it's real SPD 2007 for free and PerformancePoint 2007 server included in MOSS license.

Enrique Blanco — Thu, 02 Apr 2009 23:18:04 GMT

As seen in LadyLicensing's Product Licensing Changes to SharePoint Designer, PerformancePoint Server and Forms Server – April 2009, it seems that:

Office SharePoint Designer will be available free of charge
PerformancePoint 2007 Server license will be included with any Office SharePoint Server 2007 license
Forms server available in a MOSS standard license?

PD: Today I've seen millions of posts regarding this, but I will take the following reflection of one:

This is great news, but it might not be as good as it my seem if you're supporting some of the people who might use SPD now, so check and recheck your disaster recovery plan you may need it soon!! hehehe :D