Post original en JASoft.org: http://www.jasoft.org/Blog/post/Como-activar-las-busquedas-en-SharePoint-2010.aspx

Si has creado un sitio de SharePoint 2010 y al utilizar el recuadro de búsqueda obtienes cero resultados y un mensaje de error que dice:

«No se puede completar la búsqueda porque este sitio no está asignado a un indexador…»

Entonces es que tienes el servicio de búsquedas de SharePoint detenido.

Para activarlo tienes que abrir la Administración Central de SharePoint e irte al apartado de «Gestión de Aplicaciones», y dentro de éste a «Gestionar los servicios en el servidor»:

Una vez entre en este apartado verás que el servicio está detenido, por lo que debes pulsar sobre el botón de activarlo:

Pulsa para aumentar

En la figura es el segundo desde abajo.

Al Iniciarlo se nos pedirá que configuremos algunas cosas:

Se especifican los usuarios que se utilizarán para ejecutar el servicio y acceder a los contenidos (una descripción detallada de los permisos que necesitas la tienes aquí), se le otorga un nombre (y un servidor SQL Server que lo albergue) a la base de datos de búsquedas y finalmente se decide la frecuencia en la que se efectuará la re-indexación de los contenidos (recuadro rojo).

OJO con este proceso de re-indexado. Debemos poner una frecuencia adecuada a los cambios que se vayan a hacer en los contenidos. Si tenemos un portal con poca gente que no cambia constantemente mejor ponerle una frecuencia mayor que a uno al que accede mucha gente y hay muchos cambios. También depende de la necesidad de hacer búsquedas actualizadas que tengamos. El proceso de re-indexado puede cargar un poco el servidor, así que no conviene abusar del mismo si no es necesario.

¡Espero que te sea útil!

Post original en JASoft.org: http://www.jasoft.org/Blog/post/Como-migrarcambiar-de-dominio-Sharepoint-Foundation-2010.aspx

No soy ningún experto en SharePoint, pero sí que llevo ya unos cuantos años gestionándolo y personalizándolo, desde su primera versión. Dentro de Krasis tenemos varios sistemas montados sobre SharePoint Foundation 2010 (desde el CRM hasta la gestión de tareas, algunas documentaciones, etc…). A medida que pasaban los años he tenido que ir migrando estos portales internos de versión en versión de SharePoint. La verdad es que no se trata de un proceso fácil muchas veces, ya que en mi opinión el instalador y configurador de SharePoint es bastante lioso para mi gusto y da pocas opciones de solucionar cosas que van pasando, que al final debes resolver muchas veces casi mediante prueba y error.

Hace poco hemos tenido que migrar el dominio de Directorio Activo de la empresa a uno nuevo. Esto supuso un nuevo reto pues, al no ser un experto, tuve algunas dificultades que me llevó bastante tiempo resolver. Dado que creo que al final el proceso es sencillo si se siguen los pasos correctamente he creído interesante explicar aquí en forma de paso a paso para ayudar a otros (y a mi mismo en el futuro, jeje). Seguro que los expertos en SharePoint encuentran algún atajo u otra cosa que a mi se me escapa, pero este sistema me ha funcionado sin problemas para hacer una migración «a pelo» de las BBDD y usuarios al cambiar de servidor y dominio.

1.- Hacer backup de la BBDD

Lo primero es asegurarte de que tienes una copia de seguridad de la base de datos de contenido de tu portal o portales, en el dominio anterior. Esto es fácil.

Puedes ver qué BBDD está usando cada uno de tus sitios yendo a la administración central de SharePoint y viendo el apartado «Gestión de la aplicación·Bases de datos»Gestionar bases de datos de contenido» (en mi instalación es en inglés):

Pulsa para aumentar

Ahí te indicará qué BBDD tienes y podrás ir al administrador de SQL Server y hacer copias de seguridad.

Incluso, como vas a hacer la migración y no debería seguir usando el actual SharePoint para no modificar la BBDD, mi recomendación sería detener el producto, des-adjuntar las BBDD y directamente utilizar los archivos .mdf y .ldf en el nuevo servidor.

2.- Instalar SharePoint 2010 y SQL Server en el nuevo servidor

Pues eso. En este caso tampoco hay demasiado misterio. Simplemente se instala de la manera habitual. Yo lo instalo eligiendo que forme parte de una grande de servidores, pues me da más control posteriormente sobre cómo indicarle contra qué servidor de datos trabajar y con qué credenciales, etc…

Es mejor instalar SQL Server antes y durante la configuración de SharePoint apuntarlo ya a la nueva instalación.

Lo instalamos todo y lo ponemos en marcha.

3.- Configurar una aplicación Web

Desde el mismo menú que antes, pero esta vez en el apartado de aplicaciones Web, gestionamos las aplicaciones Web existentes:

Pulsa para aumentar

Al acceder a la gestión de aplicaciones veremos que ya está definida una aplicación que es la propia configuración central del producto, y nosotros podemos añadir una nueva aplicación usando el botón correspondiente en la barra de herramientas de la parte superior:

Lo que nos abre un diálogo bastante largo (hay que hacer mucho scroll) que debemos rellenar para definir todos los aspectos del sitio Web. La parte correspondiente a la BBDD está bastante abajo:

Pulsa para aumentar

Debemos fijarnos bien en dos parámetros de este diálogo:

1. El nombre del grupo de aplicaciones (o application pool) de IIS que gobernará el comportamiento de este sitio Web. Dale un nombre apropiado o fíjate bien en el nombre que le da por defecto, ya que luego, a lo mejor, tendremos que hacer un pequeño ajuste sobre el mismo.
2. El nombre de la BBDD. Ahora no es importante, porque la vamos a borrar, pero precisamente por eso hay que anotarlo no vaya a ser que borremos la base de datos que no es.

Ya hemos creado la aplicación, que luego usaremos para acceder a nuestros diferentes portales.

4.- Borrar la BBDD recién creada

Ahora volvemos a la gestión de BBDD que vimos en el punto 1, sólo que en el servidor nuevo. Al entrar veremos que está la BBDD recién creada e el paso anterior.

Pulsa encima de la misma para entrar en sus propiedades. Lo primero es ponerla Off-Line para cerrar todas las conexiones que hubiera abiertas hacia ella (quizá creadas por ti mismo al probar la recién creada aplicación Web):

Pulsa para aumentar

Ponemos en esta lista «Offline» y guardamos.

Una vez que esté en modo Off-line podemos entrar de nuevo y borrarla, para lo cual sólo hay que marcar la opción correspondiente en sus propiedades, hacia la parte de abajo:

Nos avisa de que al borrarla quedará inutilizado el sitio Web asociado. No pasa nada, enseguida lo arreglamos, así que acepta y borra la base de datos de contenido.

5.- Incorporar la BBDD anterior

Ahora debemos incorporar la base de datos anterior, la que queremos migrar.

Para ello vamos a SQL Server y restauramos la BBDD desde la copia de seguridad o simplemente la adjuntamos al servidor si hemos copiado los archivos .mdf y .ldf:

6.- Relacionar la BBDD con la aplicación Web

Una vez incorporada la BBDD a SQL Server con el nombre apropiado, vamos de nuevo a la administración central de SharePoint y gestionamos las BBDD (figura de punto 1). Una vez allí pulsamos el enlace de «añadir nueva base de datos de contenido»:

Pulsa para aumentar

Debemos indicar el nombre de la BBDD que acabamos de restaurar, y asegurarnos de que en la lista superior («Web Application») está seleccionada la aplicación Web adecuada que creamos en el paso 3.

Al hacerlo lo que estamos consiguiendo es que la aplicación sea gestionada a través de la base de datos que teníamos guardada. Veremos que si ahora accedemos estarán todos los anteriores contenidos, y que funcionarán los sub-sitios que hubiera definidos bajo éste.

7.- Migrar los usuarios

Aunque todo parece funcionar, lo cierto es que todavía tenemos un paso importante que realizar y es migrar los usuarios. Aunque en el nuevo dominio hayamos replicado los nombres de usuario existentes en el anterior, en realidad son usuarios diferentes y tienen nombres diferentes, ya que en el primer dominio serían de tipo «DOMINIO1Usuario» y ahora serán «DOMINIO2Usuario», así que debemos hacer que las referencias a usuarios anteriores que existieran en la BBDD pasen a referenciar a los nuevos usuarios.

Para ello la única forma que yo conozco es usando la utilidad de línea de comandos STSADM.EXE propia de SharePoint y pensada para gestionar multitud de aspectos del producto.

Este ejecutable se encuentra en la ruta: C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14BIN y hay que ejecutarlo como administrador.

La línea de comandos necesaria para migrar a un usuario es la siguiente:

STSADM.EXE -o migrateuser -oldlogin DOMINIO1usuario -newlogin DOMINIO2usuario

Si queremos migrar un grupo de usuarios completo (se conceden permisos a grupos) sería similar:

STSADM.EXE -o migrategroup -oldlogin DOMINIO1grupo_usuarios -newlogin DOMINIO2grupo_usuarios

OJO: esto no migra a los usuarios del grupo individualmente, sino que migra los permisos y referencias del grupo en sí, y hay que migrar a los usuarios igualmente uno a uno.

Lamentablemente no conozco ninguna forma de automatizar este proceso para que coja automáticamente todos los usuarios y los migre, sino que hay que ir uno a uno migrando usuarios y grupos. En mi caso como éramos pocos usuarios fue un proceso rápido pero no quiero ni imaginarme el tener que hacerlo en un dominio grande :-O

8.- No se encuentran los usuarios

Con lo anterior debería ser suficiente. Sin embargo puede que tengamos un problema adicional del que nos daremos cuenta un poco más tarde.

Cuando vamos a añadir un nuevo usuario a los permisos del portal o incluso cuando algún elemento a uno de los portales dispone de un campo que sea una persona, introducimos su nombre y, tanto al pulsar el botón de verificar como el de buscar, no nos encuentra el usuario del dominio:

Pulsa para aumentar

Da igual como lo escribamos: no aparece ningún usuario. ¿A qué es debido?

El problema es que si no hemos elegido adecuadamente al usuario que se suplanta en el grupo de aplicaciones de IIS asociado con el sitio Web, éste no podrá interrogar al directorio activo para encontrar a los usuarios. De ahí que haya hecho hincapié en el paso 3 en que te fijases en el nombre del grupo de aplicaciones asociado al sitio Web:

Fíjate que en ese apartado de la configuración aparece (debajo del nombre, que está recuadrado) el usuario que quieres usar para suplantar en el grupo de aplicaciones. Por defecto te permite seleccionar ciertos usuarios predefinidos, como por ejemplo el «Servicio de red» o el «Usuario de sistema local», que es muy típico asociar a estos grupos.

La pega es que esos usuarios puede que no tengan permisos de acceso a la red (por ejemplo el «Local System») o que no tengan permisos para interrogar al directorio activo.

Para solucionar el problema es necesario asociar a este grupo de aplicaciones un usuario que tenga los permisos suficientes para ello (en principio cualquier usuario del dominio debería tenerlos). Por lo tanto lo recomendable es crear un nuevo usuario del dominio específico para ejecutar SharePoint. Una vez creado se puede asociar directamente en las propiedades de IIS si queremos:

Ç
Pulsa para aumentar

Utilizamos el diálogo para asignar el usuario apropiado y ya podremos buscar sin problemas a los usuarios del directorio activo para asignarlos a campos de listas de SharePoint.

En resumen

La migración entre dominios de SharePoint no es que sea excesivamente complicada pero si no sabes de antemano como hacerla puedes invertir muchas horas de prueba y error hasta dar con los pasos correctos.

Insisto en que no soy un experto en despliegue de SharePoint por lo que seguramente se me ha escapado algún detalle que nos ahorre un paso o que facilite el proceso, pero estos pasos me han servidor bien a mi y espero que puedan ahorrarte mucho tiempo y quebraderos de cabeza a la hora de migrar tus portales.

¡Espero que te sea útil!

Post original en JASoft.org: http://www.jasoft.org/Blog/post/Cuanto-cuesta-un-PDF-o-por-que-no-pueden-venderse-a-5-euros.aspx

Hace cosa de un par de de semanas, coincidiendo con el día del libro, en Krasis Press lanzamos todo nuestro catálogo de libros técnicos en formato electrónico.

Lo cierto es que es algo que nos demandaba mucha gente, sobre todo en Latino-América por aquello de reducir los costes de envío allí, que son muy elevados en papel (aunque ofrecemos la posibilidad de comprarlos todos en librerías on-line como Amazon en donde esos costes de envío se reducen mucho).

La cuestión es que han tenido una acogida muy buena y la gente se va animando bastante a comprarlos. Sin embargo hemos recibido algunas críticas relativas a los precios de los mismos en formato PDF que, la verdad, no se entienden. Por eso me gustaría comentarlo aquí, a ver qué opiniones recojo…

Lo máximo que estoy dispuesto a pagar por un PDF son 5 euros

Esta es una de las cifras que hemos oído: 5 euros, 10 euros, 15 euros, ha habido de todo un poco. En cualquier caso siempre cantidades bajas.

Por ejemplo, nuestro libro sobre Entity Framework 4.0, de casi 400 páginas, único en el mercado en castellano y escrito por un «crack» como es Unai Zorrilla cuesta en papel 40 €. Esto incluye los gastos de envío por mensajero a cualquier parte de la península, lo cual no está nada mal. Sobre esto, de momento nadie se ha «quejado».

Ahora bien, la versión en PDF de este mismo libro, indexada para hacer búsquedas, en color, con enlaces «clickables», con posibilidad de imprimirse, copiar y pegar, etc… y sin protección DRM para que puedas usarla en cualquiera de tus equipos o tablets, etc… sin problemas, cuesta 28€.

Esto sin embargo a algunos (por suerte no a la mayoría) les parece una locura: «¡28 € por un libro en PDF! ¡Es carísimo! Lo máximo que pagaría son 5 euros».

Es decir, en papel sí que se pueden pagar 40€ por el  libro en papel, pero en PDF no se pueden pagar más de 5€ porque como no está el coste de imprimirlo y enviarlo ¿no? ¿Es ese el razonamiento?

Vale, a ver… 40-5 = 35€, quítale los gastos de envío por mensajero…

¿Quién se cree que la impresión de un libro de 400 páginas cuesta 27 o 28€? Imagino que nadie.

Por lo tanto, lo que estás pagando cuando te compras un libro (da igual su formato) no es la impresión como muchos se piensan, sino que son varias cosas, entre otras:

• El esfuerzo (brutal) que tiene que hacer el autor para crear el libro y transmitirte a ti sus conocimientos. Un autor generalmente le dedica cientos de horas a escribir el libro. Normalmente estas horas se las quita al sueño, a la familia, al propio trabajo. Merece ganar algo por todo este esfuerzo ¿verdad? Y te aseguro que además, por muchos libros que venda, el precio/hora que le saldría sería absolutamente ridículo.
• El trabajo de revisión: los libros se revisan, tanto técnicamente como gramática y ortográficamente. Algunos dan más trabajo que otros, ya que hay autores que aunque saben mucho de lo suyo les cuesta transmitirlo de forma apropiada por lo que a veces hay otras muchas decenas de horas empleadas por otra gente en hacer que el libro tenga su forma final.
• El trabajo de edición/maquetación: el libro tiene que tener un formato agradable y fácil de leer, las figuras deben estar bien colocadas, los listados adecuadamente formateados y sangrados… Todo este trabajo lo hace un maquetista que cobra su buen dinero, cuanto más gordo el libro más caro este trabajo. Y en el caso de libros técnicos más.
• El trabajo de diseño: ¿A qué molan mucho las cubiertas de nuestros libros? Pues te gusten o no, llegar a tenerlas supone un trabajo de diseño, compra de derechos de imágenes, etc… que tiene también un coste más o menos elevado dependiendo del libro.
• Marketing, ventas, facturación…: hay un montón de gastos relacionados con la puesta en marcha del libro. Hay que gastar dinero en marketing, en registrar el libro en redes de distribución internacionales para que se pueda comprar desde fuera, en emitir facturas y mantener los sistemas de venta, almacenaje, atención telefónica… Además de que todo el equipo de personas que trabajamos en Krasis para hacer los libros y los cursos tenemos que tener ordenadores, licencias, y estar trabajando bajo un techo. Todo esto cuesta dinero aún antes de vender un solo libro.

Bien, como verás, hasta aquí todavía no hemos metido ni un solo coste ni esfuerzo que tenga que ver con el hecho de disponer de una copia del libro en cualquier formato, es decir, que tenga nada que ver la impresión del mismo o la descarga en PDF o cualquier otro formato.

Es decir, antes de vender ni siquiera un solo libro hay varios miles de euros invertidos en tenerlo disponible para que alguien lo compre.

Teniendo en cuenta todo lo expuesto y que además los libros técnicos de programación se venden muy poco (del orden de unos pocos cientos, un best seller sería el que logra vender 1.000 ejemplares) porque el público interesado es reducido, que toda la inversión anterior dura pocos meses porque enseguida Microsoft saca nuevas versiones de las tecnologías y enseguida se vuelven obsoletos, que muchos son los únicos que se publican en castellano precisamente por estos mismos motivos… ¿Todavía hay alguien que piense que un libro electrónico debe costar como mucho 5 o 10 euros?

Si es así, perdonadme, pero me temo que no nos va a quedar más remedio a todos que aprender inglés, porque en este mercado en español, con esta filosofía pocos libros más se van a sacar en los próximos años si sigue la tendencia.

Ahora es cuando alguno saldrá con que, si el precio fuese ese venderíamos muchos más: ¡Falso!. Lo hemos comprobado con diversos experimentos. Podrían aumentar un poco las ventas, pero no lo suficiente (ni de lejos) para compensar la bajada de precio. El público objetivo de estos libros es muy reducido. Al contrario que en el caso de los discos, no se trata de que bajando el precio se vendan más porque haya un número casi ilimitado de compradores, así que aquí ese razonamiento no funciona. Además, en contraste con los músicos, a los gurús de la programación no se les paga tampoco por dar «conciertos» (o sea, las conferencias), así que ese argumento no me vale tampoco.

Ahí lo dejo para la reflexión 😉