En las instalaciones de MOSS 2007 de tipo WebFarm o incluso en las instalaciones en un único servidor pero donde se especifica que el servidor de SQL Server es uno específico, SQL Server versión Standard o Enterprise (No instalación básica con SQL Express, etc.), resulta que parece que la instalación/configuración de las colecciones de sitios personales no la hace MOSS-2007 bien, o por lo menos, no la hace por defecto.

Da el error:

"No se puede crear el sitio personal porque no se ha creado la ruta de acceso administrada "personal" para este sitio. Póngase en contacto con el administrador del sitio para obtener más información."

o también el error (lo pongo en inglés, porque es donde lo he reproducido):

"Your personal site cannot be created because Self-Service Site Creation is not enabled. Contact your site administrator for more information".

Lo que hay que hacer para solucionar el problema es:

1.- Habilitar la 'Administración de Sitios sin intervención del Administrador' para la 'Aplicación Web' SharePoint-MySite-puerto (en inglés se le llama Virtual-Server). Esto se realiza lógicamente desde la Administración Central de MOSS-2007. ¡¡Asegurarse que se ha seleccionado en la combo la 'Aplicación Web' SharePoint-MySite-puerto, no la 'Aplicación Web' raiz u otra aplicación-web...!!

2.- Verificar/Añadir en 'Definir rutas de acceso administradas' el path 'personal' como 'Inclusión de comodines'.

Con esto, debería de arreglarse el problema y poder crearse ya los sitios personales.  :-)

Autenticación en WCF con token de seguridad ASP.NET Membership
Aunque en la configuración por defecto de los bindings de WCF se utiliza autenticación Windows/AD, otra opción para muchos escenarios es que la aplicación cliente WCF se identifique contra el servicio WCF con una pareja de usuario-password que deba autenticarse contra un repositorio Membership.
Con .NET 2.0 y ASP.NET 2.0 apareció como novedad una nueva tecnología de autenticación llamada Membership (no confundir  con el antiguo Membership de Microsoft Site Server 3.0 allá por 1999 ;-), que era una implementación Microsoft de directorio LDAP… no tiene nada que ver…).
El Membership de ASP.NET 2.0 no consiste en un único y específico repositorio de usuarios para realizar autenticación. No, se trata más bien de una capa intermedia para realizar autenticaciones contra cualquier ‘proveedor Membership’ que dispongamos nosotros ‘por debajo’.  Podemos desarrollar de forma muy sencilla un proveedor ‘custom’ de Membership que autentique contra cualquier fuente de datos de repositorio de usuarios. Se puede hacer uso del proveedor ejemplo SqlMembership o bien desarrollar un proveedor contra el esquema y SGBD propio que queramos, o incluso contra otro repositorio que no sea un SGBD sino un directorio LDAP, etc. Lo interesante de Membership es que nos proporciona un interfaz estándar de autenticación (tanto programático por APIs como con Web-Controls visuales), siempre basado en tokens ‘usuario-password’, pero contra cualquier repositorio que configuremos.
En definitiva, por la razón que sea (aplicación existente basada en Membership, no disponibilidad de Directorio Activo, etc.), podemos disponer de un repositorio de usuarios expuesto a autenticación mediante Membership y utilizarlo para ¡¡basar la autenticación de nuestros servicios WCF en Membership!!.
Para integrar Membership en un servicio WCF, el usuario debe de alguna forma proporcionar las credenciales que requiere Membership (siempre usuario y password). Para transferir esos datos al servicio WCF, debemos por lo tanto hacer uso de un binding que soporte credenciales de tipo usuario/password, como wsHttpbinding y especificar explícitamente que el tipo de credenciales es UserName. En el servicio, la seguridad de WCF autenticará al usuario basándose en dicha pareja de datos (usuario/password) contra el proveedor Membership que hayamos configurado. Posteriormente, incluso podríamos hacer uso de autorización de acceso a recursos (componentes de negocio, etc.) basada en Roles-Providers de ASP.NET (Roles con usuarios Membership)…

Configuración de Servicio WCF para soportar autenticación Membership

Una vez tenemos configurado el proveedor Membership en el .config (no lo pongo porque es algo específico de Membership de ASP.NET 2.0, no exclusivo de WCF), tenemos que configurar una sección de tipo ‘Behavior de WCF’.

En esta sección definimos un behavior de servicio (comportamiento de servicio) donde especificamos que la autenticación se basará en credenciales de tipo usuario-password y en concreto en un proveedor Membership  determinado (en este caso ‘SqlMembershipProvider’).
Además de eso, también se requiere un certificado servidor X.509 exclusivamente para el servidor. Este certificado tiene un uso similar al que se le da en las comunicaciones seguras SSL, es decir, sirve para identificar al servidor y también sirve como raíz origen de las claves seguras necesitadas para realizar encriptación (cifrado) de la comunicación, que será automático en caso de utilizar el binding wsHttpBinding, como es el caso del ejemplo.
Una vez tenemos definido dicho ‘Service-Behavior’ (que podemos utilizar con cualquier definición de servicio), lógicamente tenemos que tener el XML de definición de nuestro servicio que queremos ‘enlazar’ con este behavior. Como por ejemplo, la definición de servicio siguiente (en este caso hago hosting en una aplicación de consola y basado en protocolo HTTP en el puerto 8000, todo gracias a Http.sys):

 El enlace del servicio con Membership está precisamente al principio donde especificamos el  Behavior llamado ‘behaviorConfiguration="MiSvcMembershipSecBehavior"’.
Además también es necesario especificar de forma explícita que el tipo de credenciales cliente a ser autenticadas por mi servicio son del tipo ‘UserName’ (puesto que Membership es un sub-tipo de autenticación basada en credenciales usuario-password).
Con esto ya tendríamos configurado nuestro servicio para utilizar seguridad Membership. Solamente nos faltarían un par de cosas, como configurar nuestra aplicación cliente con unos bindings que también soporten Membership (estos pueden ser generados automáticamente por la utilidad  svcutil.exe o por el propio Visual Studio cuando hacemos un ‘Add Service Reference…’ que realmente está utilizando svcutil.exe).
Por último, tenemos que instanciar la clase proxy de nuestro servicio desde la aplicación cliente y proporcionarle, lógicamente, las credenciales usuario/password, como hacemos en el código C# siguiente:

¡Pues con esto ya estaría todo!. Autenticar contra Membership en servicios WCF es muy útil por ejemplo para escenarios en Internet. :-)