|
Una opción interesante a la hora de configurar los roles de una granja sería la de duplicar el rol de administración central, si alguna vez se da el caso de que la maquina donde se aloja la administración central se quede offline o tenga algún problema de hardware, lo que nos dejaría sin administración central, seguro que alguien lo va a agradecer.
Duplicando el rol de administración central hacemos más robusta nuestra topología sin carga alguna a nivel de proceso, y en el hipotético caso de que la máquina original tenga problemas podremos seguir contando con la aplicación web de la administración central.
Me parece una opción bastante interesante sobre todos en granjas con un alto número de máquinas o donde la alta disponibilidad es fundamental, como sería el caso de los portales basados en SharePoint.
Configurarla es bastante sencillo, basta con ejecutar el wizard de configuración de SharePoint (Products and Tecnhnologies Configuration Wizard).
Una vez se está ejecutando el asistente, hay que seleccionar “Advanced Settings” y “Use this machine to the web Site” en la pantalla donde pregunta acerca de si se quiere añadir el rol de administración central:
 
Una vez se ejecuta el wizard del “Producs and Technologies” nuestra máquina ya contará con dicho rol:
Por defecto una vez instalamos la administración central en el segundo servidor tendremos un AAM(Alternate Access Mapping) como el que sigue:
Para que la aplicación web de la administración central reconozca la nueva url como propia y no nos re direccione a la url original hay que añadir la nueva url pública para la zona de Intranet (u otra zona sin uso).
Por lo tanto el AAM para la administración central será como el que sigue:
Por último, el enlace a la administración central de la maquina MOSSWEB02 seguirá abriendo la administración central original (hospedada en mossweb01), para modificar esto será necesario modificar el registro del sistema, en la ruta “HKLM\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS” es necesario modificar el valor de la cadena CentralAdministrationUrl para que apunte a la nueva url de acceso “http://mossweb02:8080”
Enlaces relacionados:
· http://harbar.net/articles/spca.aspx |
|
Al desplegar una solución, en algunas ocasiones puede ser que se quede intentando desplegarla (“deploying”) indefinidamente
Esto puede comprobarse en el almacén de soluciones de la Administración Central: 
Que una solución se quede en este estado, implica que no tenemos mucha información acerca de que está ocurriendo, en el detalle de la solución simplemente veremos que esta en fase de despliegue y poco más.
Cuando se despliega una solución, la administración central crea diferentes trabajos temporizados (“timer jobs”) encargados de desplegar dicha solución en cada una de las máquinas de la granja.
En la sección de operaciones de la administración central, hay un enlace al estado de los trabajos del temporizador:
Ahí es donde podremos verificar el comportamiento de cada uno de estos “jobs” para nuestra solución en particular, en mi caso entre los muchos “jobs” los referidos a la implementación de la solución anterior serían estos:
Donde puede comprobarse que el “job” encargado de desplegar la solución en la máquina MOSSINDEX02 no se ha completado.
Para forzar la ejecución de este job, bastará con ejecutar en la maquina MOSSINDEX02 el siguiente comando, que forzará la ejecución de los trabajos del temporizador pendientes en la máquina MOSSINDEX02:
stsadm –o execadmsvcjobs
Una vez se ejecuta este comando el “job” encargado del despliegue también se ejecutará, y en el almacén de soluciones de la Administración Central se modificará el estado “deploying” a “deployed” si todo ha ido bien.
Si algo ha fallado en el despliegue en el mismo error para la solución del almacén de soluciones se indicará información detallada a la que se debe el error del despliegue. |
| En SharePoint 2007, el WebPart de búsqueda avanzada por defecto solo permite filtrar las propiedades por “es igual a” y “no es igual a”, pero puede extenderse para que permita los criterios “contiene” y “no contiene”:
Para esto en el XML de propiedades del WebPart de búsqueda avanzada hay que incluir la opción “AllowOpContains”:
|
| En algunos casos las indexaciones de MOSS fallan, el índice se corrompe y el SSP que queda indexando indefinidamente, al intentar detener la indexación se queda “stopping”, como puede verse en la imagen (la indexación llevaba 76 horas)
En el visor de eventos de la máquina de indexación, habrá un error del tipo:
ID:4127
Content index on AnchorProject could not be initialized. Error The content index is corrupt. 
Esto indica que el índice está corrupto, y no puede reiniciarse automáticamente, para esto será necesario reiniciar el servicio de búsqueda de MOSS en la máquina de indexación:
Una vez el servicio de búsqueda se ha reiniciado (en la consola del IIS yo siempre hago un “stop” y luego “start” en vez de un “restart”, escéptico que es uno), será necesario reiniciar el contenido rastreado(reset all crawled content):
Y volver a realizar un rastreo completo(fullcrawl):
Ahora el rastreo funciona correctamente y ya no se producen errores en el visor de eventos:
|
| Por defecto en los sitios anónimos de SharePoint todos los usuarios tienen acceso a todo el contenido del sitio, esto incluye entre otras cosas las páginas de formulario (allitems.aspx) de las librerías y las bibliotecas de documentos, que en algunos casos no deben ser visibles para estos usuarios.
Evidentemente en un sitio de acceso anónimo, la cuenta de acceso al contenido que se usa para rastrear una colección de sitios de SharePoint tendrá acceso a dichas páginas, por lo tanto estas también serán mostradas como resultados de búsqueda.
En algunos casos, sobre todo para portales expuestos a internet esto puede ser un problema. Para solucionar esta casuística, por defecto SharePoint incluye la característica ViewFormsPagesLockDown, también conocida como LockDownFeature.
Básicamente bloquea el acceso de usuarios anónimos a las páginas de formulario.
Para activarla simplemente basta con ejecutar el siguiente comando stsadm:
stsadm –o activatefeature –url <siteurl> -name viewformpageslockdown
Si anteriormente a la activación de esta feature esta activado el acceso anónimo deberá ser deshabilitado y vuelto a habilitar.
Más información:
|
|
Por defecto SharePoint tiene un time-out de 6 minutos (360 segundos), tiempo más que de sobra para casi cualquier acción, no obstante puede ser que sea necesario realizar tareas síncronas de mayor duración, en estos casos será necesario modificar el límite de time-out de SharePoint.
En el ejemplo con el que voy a ilustrar este artículo una cierta página, alojada en el directorio virtual layouts, que permite realizar una carga síncrona de datos bastante pesada, que dura más de 6 minutos, por lo que genera el error: “Request timed out”:
SharePoint usa un web.config específico para establecer los time-out de las páginas almacenadas en el directorio virtual de layouts, dependiendo de la ruta de instalación se encuentra en:
Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS
Ahí se puede observar que el time-out “exceptionTimeOut” tiene por defecto un valor de 360 (segundos), por lo tanto para incrementar dicho tiempo solo será necesario modificar este valor y reciclar el pool (o hacer un iisreset)
En este caso voy a modificarlo para que sea de 3600 segundos (60 minutos)
Enlaces relacionados:
· http://geekswithblogs.net/DennisBottjer/archive/2009/04/13/increase-sharepoint-execution-timeout.aspx |
| Últimamente he pasado un rato creando archivos ejecutables (.bat) con los que normalmente mediante comandos stsadm creo parte de la estructura de SharePoint (sitios, páginas,…) esto resulta muy ágil y funcional a la hora de crear la estructura de SharePoint de los diferentes entornos.
A la hora de crear estos archivos batch, el principal problema es que la codificación ASCI de Windows no se corresponde con la de batch, coinciden casi todos los caracteres excepto las vocales acentuadas, es decir si en un fichero, digamos ejecutable.bat incluimos:
Al ejecutarlo mostrará esto:
Por lo tanto para la salida sea la correcta debería ser:
Y al ejecutarlo mostrará esto:
Por lo tanto parece claro que en este tipo de casos es necesario contar con una correspondencia entre el símbolo Windows que debe insertarse en estos ficheros y su valor en batch:
WIN |
BATCH |
WIN |
BATCH |
á |
|
Á |
µ |
é |
‚ |
É |
|
í |
¡ |
Í |
Ö |
ó |
¢ |
Ó |
à |
ú |
£ |
Ú |
é |
Sé que parece que para la á no hay valor batch asociado, pero se trata de un tipo de espacio en blanco distinto al habitual….
Otra forma de conseguir el valor Windows asociado, seria desde la consola de Windows ejecutar lo siguiente:
Con lo que tendremos un fichero con los valores batch para cada una de estos caracteres problemáticos:
|
|
Con motivo de la cercanía de la SharePoint Conference donde se presentará SharePoint 2010, que se celebrará este 19 de Octubre, el grupo de producto de Microsoft ha publicado un artículo bastante extenso y muy interesante acerca de la evolución que ha llevado a SharePoint a ser el producto que es hoy en día.
· SharePoint History
Este artículo es el primero de una serie destinada a introducir lo que será SharePoint 2010, y en los dos próximos artículos abordarán el proceso de ingeniería seguido para desarrollar SharePoint 2010 así como las mejoras presentes en la nueva versión. |
|
SPD (SharePoint Designer) es una herramienta muy útil cuando necesitamos realizar modificaciones en la visualización de una página, de una manera sencilla podemos editarla añadiendo campos arrastrándolos directamente sobre ella.
El problema es que al hacer esto, con columnas de sitio y campos de un tipo de contenido, además de los campos aparece una etiqueta bastante molesta.
Una de las propiedades de este control es “DisableInputFieldLabel” que en buena lógica debería desactivar la etiqueta, pero no parece funcionar….
La única forma que he encontrado para deshabilitarla ha sido modificando los estilos de visualización, de manera que se oculte la etiqueta:
<style type=""text/css"">
.ms-formfieldlabelcontainer {
display: none;
}
.ms-formfieldvaluecontainer {
border: 0px;
border-style:hidden;
}
</style> |
Incluyendo los estilos anteriores en la propia página, se oculta la etiqueta, y este sería el resultado:
|
|
|
|
|
|
|
|
Welcome to SharePoint Blogs. Use this space to provide a brief message about this blog or blog authors. To edit this content, select "Edit Page" from the "Site Actions" menu.
|
|
|
|
|