Menu Barra

jueves, 20 de octubre de 2011

Al abrir documentos PDF desde sitio SharePoint 2010 solicita ser guardado.

Problema
En este post se comenta un cierto detalle encontrado una vez creado un sitio en SharePoint 2010, donde al ser creado y por medidas por seguridad especifica que los encabezados no sean añadidos a los documentos almacenados en el sitio, lo que provoca que el documento tiene que ser descargado al PC para poder visualizarlo.


Causa
Esto es provocado por la seguridad por defecto que configura al momento de crear el sitio donde los documentos con extensión html y pdf (extensiones probadas) solicita que sea guardado en el equipo del usuario para ver dicho archivo.

Solución
Por ende para evitar esta opción molesta de descargar el documento y sea visualizado directamente desde el explorador debemos seguir los siguientes pasos.
En nuestra Central Administration nos dirigimos a Manage web applications, seleccionamos nuestro sitio a permitir que añade los encabezados, en la parte superior entramos General Settings y buscamos Browser File Handling y aqui modificamos de Sctict a Permissive.


Finalmente comprobamos y ahora nuestro explorador de internet podrá visualizar los documentos directamente y no tendremos que descargar el archivo para poder verlo.

Este post descárgalo en PDF, Aqui.

Cualquier consulta o sugerencia que tengan, no duden en comentarla.
Atte,
Claudio Pérez Q.


viernes, 14 de octubre de 2011

Error al Instalar Plug-ins VMware Update Manager 4.1 (VUM)

Síntoma
Una vez finalizada la instalación del VUM 4.1 desde el medio (CD-DVD), debemos instalar el Plug-ins para poder administrar estos componentes.

Al iniciar la instalación la instalación del Plug-ins de VUM 4.1, nos arroja el siguiente error:
There was an error connecting to VMware vCenter Update Manager - [Nombre_Servidor_vCenter.domain.com:443].
Database temporarily unavailable or has network problems.


Causa del Error
Este se puede originar si estos tres motivos son cumplidos.
1.     La Base de Datos utilizada para el vCenter no es la versión embebida que trae vCenter o e al aversión de SQL Express.
2.     La configuración de la conexión al servidor de Base de Datos, DSN OBDC del VUM 4.1 (Versión en x86 o 32 bit) se configuro con la Autenticación Integrada

3.     Al finalizar la instalación del VUM 4.1, no ha modificado las credenciales asociadas al servicio de VMware vCenter Update Manager

El motivo del problema se origina al momento de ejecutar el Plug-ins instalado y como el VUM 4.1 se instalo con la cuenta Autenticación Integrada, por ende el DSN OBDC creado intenta conectarse con la Base de Datos con la cuenta de sistema y esta cuenta no tiene los privilegios.

Solución
Debemos cambiar la cuenta asignada por defecto en el servicio, esto debe ser una cuenta de dominio.
Antes de iniciar la labor de cambio de cuenta de usuario, debemos stopear el servicio para luego realizar el cambio. Posterior a esto debemos iniciar el servicio y probamos con activar el nuevamente el Plug-ins del VUM 4.1.
En caso extremo si el Plug-ins no inicia procedemos con el reinicio del servidor y automáticamente deberíamos ver el icono del Update manager y la descarga de actualizaciones (como muestra la imagen).
Este post descárgalo en PDF, aqui

Cualquier consulta o sugerencia que tengan, no duden en comentarla.

Atte,
Claudio Pérez Q.

jueves, 13 de octubre de 2011

5.- Instalación de Reporting Services 2008 (SSRS) sobre SharePoint 2010: Consideraciones

Según las indicaciones y las buenas prácticas de Microsoft dejo una serie de vínculos de interés que hacen referencia para dejar operativa nuestro servidor de reportes en una granja SharePoint, además de comentar lo utilizado en mi implementación.
Vínculos de Interés
·         Arquitectura de componentes

En nuestra implementación se considera lo siguiente:

1. Crear una cuenta de servicio dedicado para la ejecución del servicio de Reporting Services

2. El servidor debe estar registrado en el dominio de la compañía.

3. En mi caso los el servidor ya están integrado con la granja sps2010 en base a los requerimientos necesarios de SharePoint 2010 (rol, Features, prerrequisitos e incluso dentro de los prerrequisitos se instala el Add-In que permite integrar SSRS con SharePoint)

4. Como mencione los Add-In de SharePoint deben estar instalados EN TODOS LOS SERVIDORES que conforman la granja a excepción de los servidores Back End o Base de Datos. Debo mencionar que las versiones es muy importante, si un solo servidor de la granja cuenta con una versión distinta a las demás el servicio de Reporting Services no se verá reflejado en la administración Central de SharePoint aunque hemos configurado correctamente Reporting Services.

5. Dentro de las consideraciones, al inicio de este post dejo una serie de vínculos para realizar este procedimiento en base a las buenas prácticas, por eso que este post ha sido realizado en base a las buenas prácticas que sugiere Microsoft en cuanto a la arquitectura, hardware y software necesario para la implementación.

6.- También por seguridad debemos considerar una cuenta de servicio dedicada para la instalación de Reporting Services, donde debemos iniciar sesión con esta cuenta e instalar y configurar los servicios con dicha cuenta. Esta cuenta debe ser creada en el Controlador de dominio de la compañía con las siguientes características mostradas en la imagen.

Ya con esto podemos continuar el siguiente post de:
1.- Introducción
2.- Escenario a instalar
3.- Requisitos mí­nimos (Hardware y Software)
4.- Requisitos previos para SSRS
5.-
Consideraciones

6.- Proceso de instalación
7.- Test de la implementación
8.- Problemas a considerar
 
Este post descárgalo en PDF, aquí

Cualquier consulta o sugerencia que tengan, no duden en comentarla.
Atte,
Claudio Pérez Q.

4.- Instalación de Reporting Services 2008 (SSRS) sobre SharePoint 2010: Requisitos previos para SSRS

Con el capitulo anterior ya tenemos claro  los Requisitos mínimos de Hardware y Software, por ende ahora debemos considerar los Requerimientos previos para instalar SSRS. Para eso debemos tener en cuenta que el servidor de reportes debe estar dentro de la granja SharePoint 2010 (en este caso), cumpliendo la función de servidor dedicado para los reportes o en caso de no tener los recursos necesarios podemos instalar Reporting Services en uno de los servidores Front End de Share]Point como indica Microsoft.
Seguidamente dejo aquí la URL de Microsoft y más debajo los requisitos para la instalación de nuestro  SharePoint 2010 versión Enterprise

Requisitos de hardware: servidores web, servidores de aplicaciones e instalaciones de un solo servidor



Requisitos mínimos 




Ya con esto podemos continuar el siguiente post de:

1.- Introducción
2.- Escenario a instalar
3.- Requisitos mí­nimos (Hardware y Software)
4.- Requisitos previos para SSRS
5.-
Consideraciones

6.- Proceso de instalación
7.- Test de la implementación
8.- Problemas a considerar


Este post descárgalo en PDF, aquí

Cualquier consulta o sugerencia que tengan, no duden en comentarla.
Atte,
Claudio Pérez Q.

martes, 4 de octubre de 2011

3.- Instalación de Reporting Services 2008 (SSRS) sobre SharePoint 2010: Requisitos mínimos (Hardware y Software)

Siguiendo con la serie de Integración de SSRS 2008 con SPS2010, también debemos considerar los requerimientos mínimos para un buen funcionamiento. En base a las recomendaciones de Microsoft utilizaremos la versión de SQL Server 2008 R2 Enterprise (64-bit) x64, para nuestra integración.
A continuación dejo cuadro que específica los requerimientos para nuestra versión, en caso para otras versiones dejo aquí la URL de Microsoft.
Procesador, Memoria y Versión de Sistema Operativo.

Hardware y Software necesario


Una vez que ya tenemos claro los requerimientos de SQL Server Reporting Services 2008 (SSRS), podremos continuar con el siguiente post donde explicare los Requisitos previos para la instalación de SSRS.
Continuando con el siguiente post de:
1.- Introducción
2.- Escenario a instalar
3.- Requisitos mí­nimos (Hardware y Software)
4.- Requisitos previos para SSRS

5.- Consideraciones
6.- Proceso de instalación
7.- Test de la implementación
8.- Problemas a considerar

Este post descárgalo en PDF, aquí
Cualquier consulta que tengan, no duden en comentarla.

Atte,
Claudio Pérez Q.

Lentitud al reiniciar Servidor ESX/ESXi en Cluster y con maquinas virtuales con RDM siendo nodo pasivo demora al iniciar

Tras un acontecimiento en mi lugar de trabajo donde tuvimos que reiniciar un servidor ESX 4.1 con maquinas virtuales en clúster y con discos mapeados (RDM) me percate que el proceso de inicio de servicios del servidor demoraba demasiado, por ende dejo documentado esta incidencia donde el problema se origina directamente con el S.O. ESX.
El proceso que dejo se debe realizar a todos los servidores del clúster VMware para evitar problemas a futuro en caso que queramos crear más maquinas con las mismas condiciones, además de aplicar para las siguientes versiones:
  • ESX/ESXi 4.0
  • ESX/ESXi 4.1
  • ESX/ESXi 5.0
Síntomas
En un sistema ESX/ESXi con VM en Cluster MSCS, donde uno de los nodos del Cluster se encuentra en pasivo (independiente cual sea), tras el reinicio del servidor físico este demora alrededor de 10 a 30 minutos en encender.
Al bootear el servidor ESX/ESXi nos muestra una el siguiente mensaje:
Loading module multiextent
Posterior a esto comienza el inicio de los servicios asociados a nuestro Cluster VMware, el servicio que demora en levantar es el Storage-drivers … donde aquí comienza la reivindicación y la detección de los dispositivos SCSI, por ende posterior al booteo el servicio Starting Path Claiming and SCSI Device Discovery tratara e iniciara el servicio en un plazo aproximado de 30 minutos (como muestra imagen), dependiendo del número de maquinas virtuales que tengamos con RDM

Solución
A continuación dejo la solución extraída de los KB de VMware y su URL, donde nos brindan mayor detalle de la solución para cada plataforma y los vinculo correspondientes para descargar las actualizaciones para solucionar este inconveniente.
ESXi 5.0
ESXi 5.0 uses a different technique to determine if Raw Device Mapped (RDM)  LUNs are used for MSCS cluster devices, by introducing a configuration flag to mark each device as "perennially reserved" that is participating in a MSCS cluster. During a boot of an ESXi system the storage mid-layer attempts to discover all devices presented to an ESXi system during device claiming phase. However, MSCS LUNs that have a permanent SCSI reservation cause the boot process to elongate as the ESX cannot interrogate the LUN due to the persistent SCSI reservation placed on a device by an active MSCS Node hosted on another ESXi host.
Configuring the device to be perennially reserved is local to each ESXi system, and must be performed on every ESXi 5.0 system that has visibility to each device participating in a MSCS cluster. This improves the boot time for all ESXi hosts that have visibility to the device(s).
 There is no support to apply this setting using vSphere host profiles. As such, ESXi 5.0 systems deployed using vSphere Auto Deploy cannot take advantage of this feature. The advanced option Scsi.CRTimeoutDuringBoot is no longer valid on ESXi 5.0.
Note: advanced option Scsi.CRTimeoutDuringBoot is no longer valid on ESXi 5.0.


Upgrading to ESXi 5.0
- Prior to upgrading, unpresent all MSCS RDMs from the host
1.     Determine RDM LUNs that are part of a MSCS cluster.
2.     From the vSphere Client select a virtual machine that has a mapping to the MSCS cluster RDM devices.
3.     Edit your Virtual Machine settings and navigate to your Mapped RAW LUNs.
4.     Select Manage Paths to display the device properties of the Mapped RAW LUN and the device identifier (that is, the naa ID).
5.     Take note of the naa ID, which is a globally unique identifier for your shared device.
6.     Unpresent all MSCS RDMs devices from the hosts. 
- Upgrade the hosts to ESXi 5.0. See Methods of upgrading to ESXi 5.0 (2004501)
- Following reboot, use the esxcli command mark the device as "perennially reserved". (This will work even if the LUNs are not currently presented to the host).  

                      esxcli storage core device setconfig -d <naa.id> --perennially-reserved=true
-       Re-present the MSCS RDM devices to the hosts and rescan.
-       Rebooting hosts should not now have issues with MSCS devices.

Upgraded ESXi 5.0
To mark the MSCS LUNs as permanently reserved on an already upgraded ESXi 5.0 host, simply run the same esxcli command as above and all subsequent rescans/boots will be at normal speed.

1.     Determine the RDM LUNs that are part of a MSCS cluster.
2.     From the vSphere Client select a virtual machine that has a mapping to the MSCS cluster RDM devices.
3.     Edit your Virtual Machine settings and navigate to your Mapped RAW LUNs.
4.     Select Manage Paths to display the device properties of the Mapped RAW LUN and the device identifier (that is, the naa ID).
5.     Take note of the naa ID, which is a globally unique identifier for your shared device.
6.     Using the esxcli mark the device as "perennially reserved" with the command:
 esxcli storage core device setconfig -d <naa.id> --perennially-reserved=true 
7.     To verify if the device is perennially reserved, run the command:  

8.     Repeat the procedure for each Mapped RAW LUN that is participating in the MSCS cluster.  
Note: The configuration is permanently stored with the ESXi host and persists across reboots.
          To remove the perennially reserved flag, run the command:

      esxcli storage core device setconfig -d <naa.id> --perennially-reserved=false
  
PowerCLI 5.0
To mark the MSCS LUNs as permanently reserved through PowerCLI, esxcli functionality is available directly through the PowerCLI. The only thing you have to do is to retrieve an EsxCli instance and then invoke any of its methods. 
For additional information see VMware vSphere PowerCLI Blog.
Connect-VIServer -Server xxx.xxx.xxx.xxx  -User xxxxx -Pass xxxxx

-Set the EsxCli instance
$myesxcli= get-esxcli -VMHost ESXhost
- List the Devices.
$myesxcli.storage.core.device.list()   
- Determine the PowerCLI parameters.
$myesxcli.storage.core.device.setconfig
 TypeNameOfValue     : VMware.VimAutomation.ViCore.Util10Ps.EsxCliExtensionMethod
OverloadDefinitions : {void setconfig(boolean detached, string device, boolean perenniallyreserved)}
MemberType          : CodeMethod
Value               : void setconfig(boolean detached, string device, boolean perenniallyreserved)
Name                : setconfig
IsInstance          : True

- List details by device naa id.
$myesxcli.storage.core.device.list("naa.50060160c46036df50060160c46036df")
AttachedFilters        :
DevfsPath              : /vmfs/devices/disks/naa.50060160c46036df50060160c46036df
Device                 : naa.50060160c46036df50060160c46036df

IsPerenniallyReserved  : false IsPseudo               : true


- Set the device as "perennially reserved" with the command:
$myesxcli.storage.core.device.setconfig($false, "naa.50060160c46036df50060160c46036df", $true)
- Verify the parameter updates.
$myesxcli.storage.core.device.list("naa.50060160c46036df50060160c46036df")
AttachedFilters        :
DevfsPath              : /vmfs/devices/disks/naa.50060160c46036df50060160c46036df
Device                 : naa.50060160c46036df50060160c46036df

IsPerenniallyReserved  : true IsPseudo               : true 

- To remove the perennially reserved flag, run the command:
$myesxcli.storage.core.device.setconfig($false, "naa.50060160c46036df50060160c46036df", $false)

ESX/ESXi 4.x
 This issue is resolved by the VMware ESX/ESXi 4.1 patch released 2011-07-28:
To workaround this issue, modify an advanced configuration option on affected ESX/ESXi hosts to speed up the boot process. For more information on changing advanced configuration options, see Configuring advanced options for ESX/ESXi (1038578).
  • For ESX/ESXi 4.0: Change the advanced option Scsi.UWConflictRetries to 80.
  • For ESX/ESXi 4.1: Change the advanced option Scsi.CRTimeoutDuringBoot to 1.
Este post decargalo en PDF, aqui


Cualquier consulta que tengan, no duden en comentarla.
Atte,
Claudio Pérez Q.