Todas las publicaciones, artículos y otros contenidos de este blog se proporciona "TAL CUAL", sin garantías, y no otorga ningún derecho. Cualquier ejemplo esta bajo los términos especificados por Microsoft
A finales de Octubre se ha hecho público el último paquete de actualizaciones para SharePoint. Hay varias actualizaciones disponibles y la instalación de las mismas depende del entorno específico que se pretende actualizar. Dado que no siempre es inmediato saber qué parches hay que instalar, voy a dar una breve explicación de los mismos:
"Global" / "Language Specific"
Entorno nativo en inglés: se necesita únicamente el GlobalEntorno nativo en castellano (u otro idioma): hay que aplicar el Global + el de lenguaje específico
MOSS / WSS
Para entornos que únicamente usen WSS, sólo se necesita aplicar los parches de WSS. Para los entornos de MOSS, hay que aplicar primero el de WSS y luego el de MOSS.
Infrastructure Update / August CU / October CU
Todas estas actualizaciones son posteriores al Service Pack 1. Es necesario tener el SP1 instalado.Son acumulativas, lo que significa que incluyen cada una a las anteriores. No hace falta aplicar todas las actualizaciones, únicamente la de nivel superior que se quiere llegar a tener.
El orden que hay que seguir es:
- WSS Global y WSS Language Specific- MOSS Global y MOSS Language Specific
Por ejemplo, si quisieramos actualizar a nivel del October CU un entorno nativo en Castellano que se encuentre a nivel del Infrastructure Update, no habría que instalar las actualizaciones de Agosto puesto que se encuentran incluídas ya en el paquete de Octubre. Por otro lado, sí que habría que aplicar las actualizaciones "Language Specific" de Español, puesto que el sistema está instalado en un idioma nativo distinto del inglés. Por lo tanto, habría que instalar: - WSS Global October CU- WSS October CU Language Specific (Español) - * (aun no disponible - en este caso se aplicaría el de Agosto, que es la actualización más reciente para este caso)- MOSS Global October CU- MOSS October CU Language Specific (Español)
Por ejemplo, si quisieramos actualizar a nivel del October CU un entorno nativo en Castellano que se encuentre a nivel del Infrastructure Update, no habría que instalar las actualizaciones de Agosto puesto que se encuentran incluídas ya en el paquete de Octubre. Por otro lado, sí que habría que aplicar las actualizaciones "Language Specific" de Español, puesto que el sistema está instalado en un idioma nativo distinto del inglés.
Por lo tanto, habría que instalar:
- WSS Global October CU- WSS October CU Language Specific (Español) - * (aun no disponible - en este caso se aplicaría el de Agosto, que es la actualización más reciente para este caso)- MOSS Global October CU- MOSS October CU Language Specific (Español)
El listado completo de dichas actualizaciones puede encontrarse en los siguientes enlaces:
Para cualquier otra actualización, compruebe el sitio de descargas oficiales de Microsoft, así como el blog oficial del grupo de SharePoint.
Hola MOSSer@s,
soy Sergio Holgado y tras unas largas "vacaciones" de 8 meses aproximadamente, he vuelto a formar parte de este gran equipo de soporte de SharePoint. Pensaréis que vaya vacaciones más largas he tenido este año, pero realmente no ha sido así. Mi primera etapa empezó en septiembre del año pasado y estuve trabajando en el grupo de soporte de SharePoint durante 4 meses como externo de Microsoft. Tras finalizar en enero seguí trabajando en mi anterior empresa con muchas herramientas Microsoft, tanto sharePoint como algunas otras similares y relacionadas. Y al pasar estos 8 meses he vuelto al grupo de soporte formando parte de Microsoft.
En esta segunda etapa todo ha empezado como la seda, familiarizado con todo el ambiente y el trabajo y con muchas ganas de ayudar a nuestros clientes y aprender de toda la gente de nuestro alrededor. Este es mi primer post y sirve de presentación. En un próximo post os hablaré de la herramienta SQL Profiler que nos sirve para analizar las operaciones que MOSS realiza sobre nuestro servidor de SQL Server. Es una herramienta muy potente y nos puede ayudar mucho a saber que está pasando entre MOSS y SQL Server en un momento determinado, pero esto vendrá en los próximos días.
Un saludo,
Sergio
Hola a tod@s, mi nombre es Juan Manuel Castro (Juancho para los amigos :-) ) y también formo parte de este equipo de soporte. Estas 2 últimas semanas han sido muy especiales para mi ya que en la primera tuve la oportunidad de asistir a un excelente curso de depuración para SharePoint y esta segunda he estado en el TechEd para IT Pro que se celebró en Barcelona donde además de aprender un montón de cosas nuevas he podido conocer a uno de los grandes ídolos de quienes nos dedicamos al soporte, Mark Russinovich. Para quienes no le conozcan el fue quien diseño herramientas tan importantes como Process Explorer, Process Monitor o TCPView entre muchas otras además de los libros como Windows Internals.
Durante una de sus Charlas Mark contó como resolvió unos cuantos casos utilizando principalmente las herramientas desarrolladas por el e internet. De las herramientas utilizadas en esos casos me gustaría destacar una de ellas llamada Process Monitor la cual nos sirve para, como dice su nombre, monitorizar la activdad de un proceso, en especial los accesos a disco duro y al registro que hace el mismo. (Esta herramienta es la unión del antiguo FileMon y RegMon los cuales nos siguen siendo de utilidad en sistemas operativos antiguos que no están soportados por Process Monitor)
Lo primero que tenemos que saber es cuándo puede sernos útil utilizar Process Monitor, estas situaciones son por ejemplo al obtener mensajes del tipo acceso denegado, archivo no encontrado o más en general cuando sospechemos que el problema puede estar en la estructura de archivos o el registro de windows.,
Una vez iniciado process monitor aparecerá una ventana como la siguiente en la que empiezan a quedar registrados gran cantidad de eventos.
En general nos interesará detener la captura de eventos ya que los habilitaremos (Ctrl+E o click en la lupa) solo mientras reproducimos el problema.
Me parece que la mejor forma de demostrar la potencia y utilidad de esta herramiente es mediante un ejemplo, por ejemplo, supongamos que tenemos una página web que cuando la accedemos obtenemos un mensaje de error que dice: "Ha ocurrido un error accediendo al archivo", dicho mensaje no nos dice que archivo es el que se ha intentado acceder y por tanto no podemos solucionar el error. En este ejemplo utilizaremos Process Monitor para intentar averiguar dicho archivo.
Para ello hemos creado un pequeño código para producir este error el cual reproducimos a continuación. Tened en cuenta que normalmente no disponemos de acceso al código fuente y el hecho de ver el archivo que se ha intentado acceder en el código no es una alternativa posible.
public partial class pgDefault : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { try { Response.WriteFile("C:\\FicheroInexistente.txt"); } catch { Response.Write("Ha ocurrido un error accediendo al archivo"); } } }
Una vez iniciado Process Monitor reproducimos el problema y cuando obtenemos el mensaje de error detenemos la captura (Ctrl+E).Dada la gran cantidad de eventos que hemos registrado hemos de empezar a aplicar filtros para centrarnos en el que nos ocupa, para ello primero filtraremos por el identificador de proceso (PID) del proceso que procesó la página web. En Internet Information Server 6 (IIS) y posteriores dicho proceso es el w3wp.exe.
NOTA: En caso que tengamos más de un web activo alojado en la misma máquina podemos utilizar IISAPP para obtener el PID del w3wp.exe que nos interesa.
En nuestro caso el PID es 6408, haremos click en el menú Filter opción Filter… (o Ctrl+L)
Una vez hecho esto pulsamos Add y luego OK
Al ir aplicando filtros reduciremos la lista de eventos hasta llegar a los que realmente nos afectan, en este ejemplo vemos que hemos podido identificar el archivo al que no podíamos acceder C:\FicheroInexistente.txt
Tan solo nos queda ver porque ese fichero no está en su sitio para solucionar el problema.
Adicionalmente comentar que podemos guardar los registros de eventos para que sean analizados posteriormente o en otra máquina,
Espero que os haya sido de utilidad este post y para aquellos que no conozcan las utilidades de sysinternals es mas que recomendable que le echeis un vistazo ya que nos ayudan a solucionar más de un problema.
Juancho
Quiero hablaros de registros, si realmente me gusta hablar de registros.....
Nos otros trabajamos cada día con varios clientes en un gran variedad de entornos. Ni un entorno es igual, y en cada entorno MOSS está utilizado en manera distinta. Puede ser el intranet de una empresa, un portal para un instituto donde publican información en el internet, portales enormes, pequeños y todo lo que puede existir por la mitad.
Muchas veces los problemas de nuestros clientes muestran la misma variedad, un problema en una lista, en un despliegue de contenidos o problemas con permisos en un sub sitio de una colección de sitios. A nos otros la tarea de entender el entorno, su valor, el problema y su repercusiones. Para entender el entorno y su valor tenemos la ayuda de nuestros clientes, para entender la repercusión de un problema también, pero para entender el problema y su causa tenemos registros. Tenemos la suerte que los registros de SharePoint son muy elaborados y bastante elegantes, encima tenemos otros registros que nos pueden ayudar, intento hablar un poco de ellos en esta entrada.
1. Los registros de SharePoint.
Los registros de SharePoint son proporcionado por el Unified Logging Service, por esto nos otros les llamamos ULS logs. En la administración Central de SharePoint ya en la pestaña de Operaciones tenemos un enlace a su configuración.
En este en lace podemos decidir:
· Cuantos registros guardamos; por defecto el valor de esta opción es 96
· Cuantos registros generamos; por defecto el calor de esta opción es un registro cada media hora.
De hecho por defecto guardamos una historia de registros por 2 días.
· Donde guardamos estos registros, por defecto asumimos que la carpeta C:\Archivos de Programa\Archivos Comunes\Microsoft Shared\web server extensión\12\LOGS es una ubicación lógica, pero bueno se puede cambiar a una ubicación diferente.
· Nivel de registración; por defecto registramos de todas las categorías los eventos que son errores y mas graves en el visor de sucesos, y registramos los eventos de nivel medio al registro de trazas (los registros de SharePoint que acabamos de guardar en una ubicación que nos viene bien).
Los que ya han trabajado con nos otros igual han notado que tenemos el costumbre de pediros de cambiar el nivel de registración a detallado.
Cuando miramos en la carpeta designada para guardar los registros veremos 3 tipos de registros.
1) Registros con el formato: PSCDiagnostics-fechahora.log; estos registros son registros que son creado cuando ejecutamos el Asistente de Configuración de tecnologías y productos SharePoint. Lo ejecutamos después de instalar el producto y cualquier actualización.
2) Registros con el formato: nombredelservidor-fecha-hora.log: estos registros son los registros que proporciona el Unified Logging Service.
3) Un fichero upgrade.log: en este fichero podemos ver la información detallado sobre el proceso de la instalación de una actualización, o la actualización de una base de datos que hemos adjuntado a una aplicación web.
Como podéis ver por parte de SharePoint creamos bastante registros que nos ayudan entender muchos problemas y sus causas, pero no siempre es suficiente. Por esto motivo miramos a otros registros también.
Truco nuestro: Suele ocurrir como decía que pedimos que cambiáis el nivel de registración a detallado. Para volver al estado por defecto sin entrar en administración central, pinchar en operaciones, pinchar en registro diagnostico, seleccionar todas las categorías, seleccionar el nivel del registración en el visor de sucesos etc. etc. etc. etc. y finalmente pinchar en Guardar.
Abre una línea de comandos, navega a la carpeta bin de C:\Archivos de Programa\Archivos Comunes\Microsoft Shared\web server extensión\12 y ejecuta:
Stsadm –o setlogginglevel -default
2. El visor de sucesos
Otra fuente de registros que nos gusta mirar, no solo salen aquí los errores de SharePoint, también salen eventos sobre información, avisos y errores de productos que necesitamos para que SharePoint funciona correctamente como COM, .NET, la propia sistema operativa y depende a la instalación también del servidor de SQL.
3. Los registros de IIS
Por el momento son los últimos registros de cuales quiero hablar. Como SharePoint muestra sus contenidos por sitios gestionados en IIS, los registros de IIS también son una fuente de información importante para nos otros para entender el problema y su causa.
Truco nuestro: Cuando hay solo un sitio web es bastante fácil encontrar su registro, además si es el sitio web predeterminado se guarda (por defecto) en c:\Windows\System32\Logfiles\W3SVC\1.
La verdad es que hace años que he visto un servidor con solo un sitio web, entonces para ver el registro de un sitio web que no es el sitio web predeterminado:
En la administración de IIS pincha en el nodo “sitios web”, en la parte de la ventana a la derecha te salen todos los sitios web y su identificador. Este número nos sirve para identificar la carpeta donde guardamos nuestros registros. He adjuntado un imagen de la administracion de IIS para que tenéis una idea.
Como veis tengo cariño a los registros aunque he intentado ser breve, me he dejado llevar un poquito. Si has llegado al final y has leído todo creo que s posible que también eres aficionado/a de los registros, si has llegado sin leer todo no te preocupes; lo importante es que había información que te ha servido J
Niels
Llevo trabajando en soporte más de diez años y muchas veces me han preguntado qué es esto de dar soporte. Para mi soporte es básicamente ayudar. Si eres de esas personas que te gusta ayudar a los demas a resolver sus problemas y si tus amigos te llaman a horas intempestivas preguntándote por qué no se conectan a Internet o que portátil se tienen que comprar quizás nos entiendas.
La semana pasada saqué esta foto del escritorio de uno de mis ingenieros.
Resumen bastante bien el espíritu de soporte. Es una mezcla entre tecnología, clientes (hablamos mucho con ellos, sobre todo por teléfono), resolución de problemas (por el cubo de Rubik) y situaciones críticas (una Coca-Cola suele ayudar). Pero hay algo que falta en la foto. Es el sentimiento de compañerismo necesario para que todo esto funcione.
Cuando contratamos a alguien buscamos sobre todo que tenga ese sentimiento, que quiera ayudar. El resto se puede aprender.
Y trabajar en soporte en Microsoft no es sencillo. Somos los último del circo, los que recogemos los problemas y los que solemos hacer el trabajo sucio. Pero también es cierto que si te gusta es bastante difícil dejarlo.
Hace 7 años mi jefe llamo a mi compañero y yo, y decía: “Chicos, echad un vistazo a este SharePoint Team Services, viene gratis con Office 2000 y puede ser interesante para nuestros proyectos internos.”
Así empezó mi historia con SharePoint, hace 7 años en Holanda. En aquella época lo mirábamos, hicimos unos sitios con el producto pero ya había en la empresa un producto para gestión de documentos, un producto que estratégicamente tenía que ser nuestro plataforma para gestión de conocimiento. Este SharePoint nos ofreció una solución rápida para gestionar documentos relacionados con pequeños proyectos internos, más fácil de usar y gestionar que la solución que ya había y tenia mejor aspecto, pero bueno solo sirvió para sitios piratas.
Dejo a SharePoint en unos meses y volví a pasar los días con mis queridos amigos Exchange, IIS y ISA. Pero el tiempo pasaba y mis amigos aun que seguían encantarme, no podían prevenir que me aburrí. Ni el hecho que mi empresa se fusiono con otra empresa podía prevenir que me aburrí.
Fui a buscarme un nuevo amigo y creía que me lo encontró en un producto para gestionar activos empresariales, desde oficinas hasta a bolígrafos se podía gestionar con este producto.
Me gusto y me dedico a Visual Basic script y consultas de SQL para que pudiera personalizar el producto e implementar soluciones elegantes. Solo nos quedábamos juntos medio año, perdimos el contracto gordo y no había más alternativas para mi jefe que mandarme de nuevo a pasar los días con mis amigos Exchange, IIS e ISA. Lo entendí y lo intente pero después de otro medio año de aburrimiento me marcho a otra empresa, otros jefes y un entorno diferente.
Como cambio mi mundo. Trabajé de nuevo con mis amigos Exchange, IIS e ISA, pero también con Virtual Server, SQL y un tal SharePoint Portal Server el gran hermano de Windows SharePoint Services que era la versión nueva de SharePoint Team Services. Ya no me aburrí. Los días eran llenos de jugar con mis viejos y nuevos amigos, juntos hicimos plataformas impresionantes mayormente para el sector de educación. Cada uno de ellos me revelaban secretos obscuros que no sabía yo antes y les prometí nunca decirlo a nadie.
Mi mejor amigo era Virtual Server, hasta los fines de semana pasábamos juntos y me hice reír un montón. Hasta que un día empezábamos con el programa Beta de Office SharePoint Server, ¡wau! ¡Como se ha mejorada mi viejo amigo! Le presento a mi nuevo amigo Virtual Server, pero en realidad Virtual Server se quedo un poco pálido al lado de este nuevo SharePoint. Llego un día y empresa decidía a dejar de usar completamente a Virtual Server, decían que había un producto mejor. Defendió a mi amigo lo mejor que podía pero no me escucharon. Mayormente dejé a Virtual Server en los clientes y en la empresa, mientras tanto me consoló con este nuevo SharePoint tan bonito y elegante.
Y SharePoint me lo agradeció y me daba una oportunidad de irme a trabajar en España en la empresa donde nací él. Una oportunidad de compartir más secretos y pasar más tiempos juntos a él y juntos a amigos suyos. Sin dudarlo me fui a por esta oportunidad ya hace casi 2 años y estoy muy feliz cada día con pasar los días con SharePoint y sus amigos.
Esto es, hasta el día de hoy, mi historia con SharePoint. Yo soy Niels Immink y actualmente trabajo en el equipo de soporte de SharePoint en España.
Cuando me entrevistaron para trabajar de ingeniero de soporte de SharePoint en Microsoft me preguntaron que estrategia seguiría para resolver un problema técnico. Sin pensarlo dos veces respondí "Buscaría en Google".
Como podréis comprender quizá esta respuesta no fuese la mejor para entrar en Microsoft. Nunca me olvidaré de las caras de Julián, Javi y Pedro. Fue uno de esos momentos en los que uno se da inmediatamente cuenta que tendría que haber pensado esta respuesta un poco más antes de responder.
Desde entonces ha llovido mucho y ha habido mucho cachondeo por esta respuesta. Cuando uno entra a trabajar en una empresa como Microsoft se da cuenta que todo el conocimiento que uno cree poseer no es NADA comparado con el de todos estos "frikis" que trabajan aquí. Desde que entré no he parado de <ala-ballmer> APRENDER, APRENDER, APRENDER! </ala-ballmer>. El conocimiento y los recursos que hay aquí dentro parecen infinitos pero hay un momento en la vida del ingeniero que descubre “LA FUERZA” (aka “El sentido de la vida, el universo y todo lo demás”, “El numero 42”, “El Secreto”,...). Esa fuerza de la que el Maestro Yoda nos hablaba...
"toda aquella energía que es creada por todas las cosas, incluso entre una roca, la tierra y los seres vivos"
Y como controlar esta fuerza infinita os preguntareis... pues bien... os lo voy a revelar... Se llama...
WinDBG es un depurador multipropósito que viene incluido en las “Debugging Tools for Windows”. Es quizá también uno de los productos más feos de Microsoft y algunos directamente lo asocian con el lado oscuro. Su padre, Darth Vader (aka NTSD), reside en todos los Windows y siempre ha estado oculto en su ventana oscura de consola listo para destripar cualquier proceso. En los próximos post veremos paso a paso como utilizar esta espada laser jedi con la que podréis enfrentaros a cualquier reto técnico que se os ponga por delante.Por ahora os dejo mis dos blogs favoritos de depuración:
If broken it is, fix it you shouldPensabais que la princesa Leia era solo producto de la imaginación y la fantasia? He aquí una revelación: La hermana de Luke existe y vive en Suecia bajo el nombre de Tess. Nada mas entrar en su blog podreís sentir su fuerza. Sin miedo... que no os tiemble el pulso... pinchad...http://blogs.msdn.com/tess/default.aspx ASP.NET DebuggingA Tom no le posiciono muy bien dentro de la familia de los Jedi pero desde luego tiene la fuerza para depurar ASP.NET como pocos saben hacerlo. Un auténtico impresindible para los aprendices de Jedi.http://blogs.msdn.com/tom/
...dos libros fundamentales para iniciarse en el dominio de la Fuerza
...y mis enlces deliciosos de: Depuración: http://delicious.com/sachaa/debuggingSharepoint: http://delicious.com/sachaa/sharepointy todo lo demas...:http://delicious.com/sachaa/ ...que la fuerza os acompañe!
Sacha
Hace unos siete años más o menos yo era el responsable de soporte del grupo de mensajería y Office en Microsoft en España (nosotros llamamos a este grupo Business Applications). Por aquel entonces me acababan de “hacer jefe” y me estaba resistiendo a dejar de ser un técnico. Así que me fui a un curso en Londres sobre un nuevo producto que estábamos lanzando y del que nadie había oído hablar ni se sabía qué hacía. El producto parecía novedoso. Era SharePoint Portal Server 2001.
Volví transformado. Era algo sustancialmente diferente a lo que teníamos y proporcionaba a Office un campo enorme en el que crecer. Colaboración. Wow. Así que le dije a uno de mis ingenieros de soporte de Exchange: “Oye Javi, este producto mola. Creo que tendrá éxito. ¿Por qué no empiezas a dar soporte?”
Javi me miró con cara sorprendida pero se fio de mi instinto (siempre te estaré agradecido, amigo). El grupo creció, pronto fueron dos, luego tres. Yo dejé el grupo para hacer otras cosas pero volví el año pasado con ellos. Ahora somos cinco, pronto seremos siete.
Este grupo de cinco me propuso hace poco comenzar un blog. “¿Otro?, dije yo”. Bueno, podría ser el blog del grupo. Nos podría ayudar a crear comunidad de soporte, entre nosotros y los clientes. Nos lo podemos pasar bien. “Vale” dije, no muy convencido.
Así que me comprometí a arrancarlo con un post. Nuestra idea es que sea un blog con carga personal. Al fin y al cabo nosotros somos personas. Sí, claro, trabajamos en Microsoft, pero soportamos el producto con todas sus miserias (las menos) y sus grandezas (las más). Y si hay algo que nos une es la pasión por lo que hace.
Mi nombre es Julian Isla. Soy el responsable del grupo de soporte de Office System en España. Éste es el blog del grupo de soporte de SharePoint. Yo os contaré cómo son mis ingenieros, o al menos como los veo desde mi esquinita. Solo os puedo decir una cosa. Son estupendos ¡ya lo veréis!
¡Bienvenidos!
Bienvenidos al blog del Equipo de Soporte de SharePoint en España.
Hemos puesto en marcha esta idea con el propósito de acercarnos más a vosotros: queremos haceros llegar tanto información general del producto como comentar algunas "Best Practices" o mencionar soluciones a casos comunes que nos encontramos en soporte.
Nos gustaría también escuchar vuestras sugerencias y comentarios, por lo que cualquier feedback será bienvenido.
Intentaremos actualizar el blog tan a menudo como sea posible :-) Si quisierais sugerir algun tema, no dudéis en comentarlo en algun post o enviarnos un correo.
Sacha, Niels, Juancho, Ioana y Sergio