Configurar la suscripción de reportes con SQL Server y SSRS

Todo lo que se conecta a SQL Server genera datos que pueden ser presentados en un lindo reporte a través de SQL Server Reporting Services. Puedes trabajar con herramientas intuitivas y orientadas a los usuarios no técnicos, como Report Builder.

En este artículo veremos cómo crear suscripciones a los reportes ya generados.

Las suscripciones son agendas que se crean para despachar, habitualmente, por correo electrónico algún reporte. Por ejemplo, envío de reporte de ventas de la semana anterior todos los días lunes a las 9:00 AM.

A nivel de base de datos, se requiere que el servicio SQL Agent esté corriendo. Este servicio es el encargado de administrar los job. Desde el punto de vista del reporte, es el servicio que se encarga de ejecutar la consulta en la base de datos al momento de generar y enviar el reporte.

Este servicio debe ser inicializado en la herramienta SQL Server Configuration Manager:

001

 

Para el envío de correos se necesita un servidor SMTP y una cuenta de correo para el envío (no es necesario que esta cuenta exista en el servidor). Los parámetros del servidor deben ser configurados en la herramienta Reporting Services Configuration Manager:

002

Sender Address es una dirección ficticia. Es para que muestre un origen válido. SMTP Server es la dirección del servidor SMTP.

En el sitio web de administración de los reportes de SQL Server Reporting Services, buscamos el reporte que se quiere enviar por correo y en el menú contextual, se selecciona la opción de  suscribir.

Primera acción a realizar, es configurar los parámetros de envío de correo y forma. Esto incluye: destinatario, asunto y comentario. También hay que configurar el formato de envío del reporte y agenda (programación). Importante: El portal funciona de forma óptima con Internet Explorer.

003

Luego hay que configurar los parámetros, si es que el reporte los requiere:

004

Una vez que está todo OK, la configuración queda guardada apretando el botón Aceptar.

 

Maximiliano Marín, Consultor Infraestructura, Blue Solutions.

 

Advertisements

Proteger todas las OU a la vez contra eliminación Accidental

Cada administrador de Active Directory debe saber que existe una configuración por defecto desde que apareció RSAT con Windows Vista y que se activa por defecto al momento de crear una nueva Unidad Organizativa. Esta funcionalidad reside en proteger la OU que vayamos a crear contra eliminación accidental, provocando que el técnico que quiera eliminar la OU deba primero desbloquear la limitación para poder eliminar la OU.

El siguiente paso a paso a explicar es un poco delicado, ya que si no se está seguro o si no se tienen los conocimientos suficientes de Active Directory, más algo de línea de comandos, será un poco extraño y posiblemente difícil de entender.

El procedimiento que vamos a seguir es un comando desde una cmd.exe que bloqueará al usuario (todos o everyone) según idioma contra eliminación de objetos he hijos, para así en caso de que un técnico por error vaya a eliminar una OU, ésta estará protegida contra eliminación.

Lo primero de todo, es diferenciar entre el lenguaje del sistema operativo donde vamos a realizar el comando, ya que en el caso que esté en inglés al usuario que le vamos a quitar los privilegios es “everyone” y si está en español es “todos”.

Crear una OU de pruebas sin marcar el pincho “Proteger objeto contra eliminación accidental”.

Desde una línea de comandos y con las herramientas de Active Directory instaladas, ejecutar el siguiente comando:

for /F “tokens=*” %i in (‘dsquery ou “ou=pruebas,dc=dominio,dc=com” -limit 0’) do dsacls %i /D “todos”:”SDDT;;”

Cuando esté realizado, nos vamos a las propiedades de la OU en el ADUC y comprobamos que el pincho “Proteger objeto contra eliminación accidental” vuelve a estar marcado como en la siguiente imagen:

3

El comando que vamos a usar para modificar los permisos de todas las OU’s del directorio activo para proteger contra eliminación accidental es el siguiente:

For /F “tokens=*” %i in (‘dsquery ou –limit 0’) do dsacls %i /D “everyone”:”SDDT;;”

Con este comando realizamos una búsqueda de todas las OU’s de AD (‘dsquery ou –limit 0’) y por cada resultado se le hace un dsacls para que el usuario everyone no pueda eliminar objetos (SD) y tampoco eliminar los hijos de los objetos (DT).

Recordar cambiar el nombre “everyone” por “todos” si el idioma de sistema operativo está en castellano.

Se mostrará por pantalla todos los permisos de todas las OU’s (este proceso es normal, no se asuste). NO CIERRE LA VENTANA.

El proceso tardará más en función de la organización de AD (Si es muy grande puede tardar alguna hora).

Dentro de las buenas prácticas de Microsoft, todas las OU’s del dominio deben estar con esta configuración, para validar la aplicación de este cambio se recomienda ejecutar un BPA (Best Practice Analyzer) para el rol de AD DS.

Nicolás Herrera, Consultor Infraestructura, Blue Solutions.

3 Consejos para la resolución de problemas en SCCM

System Center Configuration Manager es una gran plataforma para la administración de activos presentes en el dominio. Con soporte, que incluye a clientes Linux y Mac.

Ofrece un amplio abanico de posibilidades para mantener control, estandarización de los equipos y seguridad en el momento de la automatización de tareas. Esto se traduce en un sano ecosistema.

¿Qué ocurre cuando deja de existir un sano ecosistema? Lo más probable es que la plataforma no esté operando en óptimas condiciones, por lo que debemos preguntarnos ¿Qué pudo haber fallado?.

La plataforma no es tan elocuente para acusar un problema de funcionamiento, así que les comparto consejos donde buscar, para generar un diagnóstico, antes de comenzar a correr en círculos.

1. Revisar los estados de los sistemas desde la consola de SCCM

Toda actividad de revisión, diagnóstico y reparación debieran partir por aquí. Estos indicadores mostrarán cuál es el componente que está delatando algún problema.

Los indicadores a revisar son:

  • Estado del sitio
  • Estado del componente

Ambos indicadores están dentro del módulo de Supervisión.

M1

En estado de sitio se revisa el estado de cada uno de los roles de la implementación. Por rol me refiero a Puntos de Administración (MP), Servidor de Sitio (Site Server), Punto de Distribución (DP), etc.

M2.png

En estado de componente se encuentra el estado de los elementos ya más técnicos. Se describe en detalle lo que puede entregar el estado de sitio. Siempre es recomendado estar atento a los dos indicadores.

 La forma correcta de acceder a los registros es hacerle click con el botón secundario y luego en mostrar mensajes. En el menú aparecen las opciones. A modo personal, siempre reviso todos y luego dentro de la ventana voy filtrando.

M3.png

M4

M5.png

Revisando los estados ya sabremos algo de lo que está ocurriendo.

2. Comprobación de la comunicación entre cliente y punto de administración.

Entre los clientes y el punto de administración la comunicación es a través de HTTP. Todo el tráfico es web. Los clientes descargan políticas y envían sus inventarios a través de un servicio publicado en IIS.

Una buena manera de comprobar la comunicación es acceder a la URL http://nombre_MP/sms_mp/.sms_aut?mplist desde el navegador del cliente y se debiera tener un resultado muy similar a este:

M6

En el caso que de un código 400 o superior, es porque el problema se encuentra en el servicio.

3. Revisión logs

Aparte de los eventos que la consola nos puede entregar a través de la revisión del estado del sitio y de los componentes, se pueden encontrar registros aún más detallados sobre lo que está ocurriendo.

Para revisar estos logs, debemos navegar hacia la ruta: %ProgramFiles%\Microsoft Configuration Manager\logs.

M7.png

Como recomendación, ordenar los logs por fecha antes de comenzar a revisarlos. Esto ayudará a revisar los logs que se van actualizando de forma más periódica.

A los administradores les recomiendo siempre les recomiendo tener instaladas en su equipo las herramientas para la administración: https://www.microsoft.com/en-us/download/details.aspx?id=50012

Y también el libro gratuito: Troubleshooting Configuration Manager

http://blogs.msdn.com/b/microsoft_press/archive/2013/11/12/free-ebook-microsoft-system-center-troubleshooting-configuration-manager.aspx

Ahora que ya conocen algo más de la plataforma, espero que puedan aplicarlo cuando estén frente a una problemática, o bien, acordarse donde están estos consejos.

Maximiliano Marín, Consultor de Infraestructura, Blue Solutions

¿Cómo podemos actualizar el protocolo de replicación de archivos para AD DS en Windows Server 2012 y 2012 R2?

EL protocolo de replicación en archivos en Active Directory Domain Services es imprescindible para el óptimo funcionamiento de la plataforma, de lo contrario existirían problemas de inconsistencia en la información y bases de datos de AD DS. Microsoft al estar consciente de esto, ha decidido crear un nuevo protocolo de replicación de archivos, 15 veces más rápido y mucho más estable que su versión FRS.

En este artículo usted aprenderá a realizar la actualización del protocolo FRS a DFS-R, para aprovechar todas las bondades que ofrecer Windows Server 2012, y 2012 R2.

Lo primero que debemos saber, es si se está usando FRS o DFS-R. No es fácil detectarlo, ya que la interfaz gráfica usada para administrar o configurar el Dominio no cuenta con la información. Sin embargo, existe una opción para averiguarlo y es a través del Registro (registry), debemos utilizar REGEDIT.EXE y encontrar:

”HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters”

Cuando llegamos aquí, tendremos dos posibilidades, que exista o no una sub carpeta “Syvols\Migrating SysVols”.

Opción 1 Subcarpeta SysVols:

“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\Sysvols\Migrating SysVols”

Esto significa que que se está utilizando DFS-R

1q

Opción 2 No existe subcarpeta SysVols:

Sí la subcarpeta SysVols no existe, significa que se está usando FRS.

2Q

La primera figura, que usa DFS-R, está tomada en un Controlador de Dominio donde se ha creado un Dominio y Bosque nuevos directamente con niveles funcionales Windows 2012 R2.

La segunda figura, corresponde a un Dominio que se ha actualizado desde versiones anteriores.

Entonces, ¿Cómo podemos hacer la migración del servicio de replicación de archivos?

1.- Debemos elevar el nivel funcional de Dominio y Bosque a “Windows Server 2012”.

2.- En uno de los Controladores de Dominio debemos abrir una línea de comandos como administrador y pasar al primer estado. Debemos ejecutar:

DFSRMIG /SetGlobalState 1

Y periódicamente verificar si el proceso fue completado con:

DFSRMIG /GetGlobalState

3g

Una vez alcanzado el nuevo estado (Prepared) podemos seguir con el siguiente:

DFSRMIG /SetGlobalState 2

4g

De forma análoga pasaremos al estado 3.

5q

Y si queremos comprobar, podemos verificar en el registro, que aparece la carpeta mencionada al principio de la nota, y además que el estado es 3 (Eliminated).

6.

El cambio de FRS a DFS–R, en muchos casos permanece oculto para los administradores de Active Directory, que suponen erróneamente su actualización automática cuando se actualiza el Domino. Afectando la calidad y el desaprovechamiento de recursos en nuestros servicios al utilizar un protocolo antiguo.

Nicolas Herrera, Consultor de Infraestructura, Blue Solutions