Autor: dmatey

Serie «Básicos»

Este sitio Web está dedicado a la arquitectura informática y por lo tanto sus artículos son de nivel medio/alto, pero debido a mi colaboración en foros como la TechNet es común que me encuentre con algunas dudas «básicas».

La serie básicos pretende ayudar a los administradores noveles a solucionar situaciones que aunque sencillas pueden representar un problema para ellos.

Introducción

ISA Server 2004 y 2006 realizan todas las decisiones de que trafico está permitido y que trafico no lo está conforme a las reglas que tengan creadas.

Las reglas tienen un orden, dicho orden puede afectar a cómo reacciona ISA ante el trafico.

Adicionalmente ISA nos proporciona potentes herramientas para saber si las reglas están funcionando bien o no.

El orden de las reglas si afecta el producto

El orden general en el que tenemos que poner las reglas es:

1º las reglas que denieguen el trafico de forma general.

2º Reglas que permitan el trafico de forma general.

3º Reglas que sean para ordenadores específicos (IPs)

4º Reglas para usuarios, urls o contenidos específicos. 

5º Reglas de publicación

6º Otras reglas que permitan tráfico.

Otras buenas prácticas:

http://www.microsoft.com/technet/isa/2004/plan/firewall_policy.mspx

Veamos la siguiente imagen para ver como se modifica el orden de las reglas:

Figura, 1. Orden de las reglas en la consola de ISA.

Como saber que regla debo crear o si una regla funciona bien o no.

Una de las cosas que más me gusta de ISA 2004 y 2006 es la posibilidad de ver en tiempo real el trafico del firewall.

De esta forma podemos averiguar cómo crear una regla que no sabemos qué puertos usa o adonde va o ver por qué no funciona una regla especifica.

Figura, 2. Monitorizando el trafico en tiempo real (1)

Figura, 3. Monitorizando el trafico en tiempo real (2)

Figura, 4. Monitorizando el trafico en tiempo real (3) Editando el filtro.

Figura, 5. Monitorizando el tráfico en tiempo real (4) Filtro ya creado.

Con este filtro veremos en tiempo real todo el tráfico que produzca la maquina 192.168.0.30.

Figura, 6. Monitorizando el trafico en tiempo real (5) Trafico generado por un ping lanzado en la maquina 192.168.0.30 hacia la ip 10.20.20.1

Viendo el resultado de la monitorización podremos averiguar que protocolos y destinos tendremos que poner en una regla para que funcione.

También será fácil ver por qué alguna regla no funciona y solucionarlo.

Serie «Básicos»

Este sitio Web está dedicado a la arquitectura informática y por lo tanto sus artículos son de nivel medio/alto, pero debido a mi colaboración en foros como la TechNet es común que me encuentre con algunas dudas «básicas».

La serie básicos pretende ayudar a los administradores noveles a solucionar situaciones que aunque sencillas pueden representar un problema para ellos.

Introducción

A la hora de decidir cual será el nombre DNS del primer dominio y por lo tanto del bosque que creamos, hay que tomar una elección:

1) Llamar al dominio del directorio activo igual que nuestro dominio externo.

2) Usar un nombre de domino diferente para nuestro directorio activo.

Todas las buenas prácticas apuntan a que es mejor usar la 2ª opción si por ejemplo nuestro dominio externo es Empresa.Com usaremos algo como Empresa.Local para nuestro dominio interno.

En este articulo «básico» analizaremos los problemas más comunes que se encuentra un administrador novel al enfrentarse a cualquiera de las dos decisiones.

Dominio Externo igual que dominio Interno.

En este caso el problema más frecuente es que si por ejemplo se tiene una web publica del tipo http://www.empresa.com/ los usuarios internos de la red no pueden navegar por ella.

La razón es que los puestos tienen configurado como DNS al controlador de dominio que considera la zona empresa.com como local y además se cree completamente autoritativo para ese dominio, por lo cual cuando no sabe resolver algo en esa zona considera que es por que no existe.

Este mismo problema con la web se puede extrapolar a cualquier tipo de servicio como servidores de correo, etc.

Solucionarlo pasa por conseguir que los servidores DNS internos sean capaces de resolver esos recursos públicos.

Conseguir esto es tan sencillo como crear los registros adecuados en la zona DNS empresa.com de nuestros DNS.

Figura, 1. Creando un registro DNS para http://www.empresa.com/ (1)

Figura, 2. Creando un registro DNS para http://www.empresa.com/ (2)

Si usas un servidor Proxy para salir a Internet, tendrás que configurar los navegadores para que soliciten al proxy las direcciones locales y el proxy para que sea capaz de prestar esas páginas web.

Lo segundo depende del tipo de proxy que uses pero lo primero se configura en Internet Explorer.

Figura, 3. Configurando Internet Explorer para que no se salte el proxy en las direcciones locales.

La casilla de no usar proxy para direcciones locales tiene que estar desmarcada.

Domino Interno diferente del dominio Externo.

En este caso, los problemas son:

1)- Al montar exchange este no permite que entren los correos dirigidos al dominio externo Empresa.Com.

2)- Dudas a la hora de publicar servicios o pedir certificados.

Lo primero que tienes que pensar es que este escenario es el mas comun, ademas piensa tambien en la cantidad de proveedores de servicios que prestan servicios de correo electronico a cientos de empresas diferentes o en los grupos de empresas que tienen muchos dominios DNS.

Para conseguir que Exchange acepte el correo electronico del dominio Empresa.Com, lo primero que te tienes que asegurar es que tienes los registros MX creados dentro de la zona publica de tu servidor DNS publico y que apuntan a las IPs publicas en las cuales tengas publicado el puerto 25 de tu servidor exchange.

Una vez que tengas comprobado esto y que desde internet se puede acceder al puerto 25 de tu servidor Exchange en la IP publica de tus MX, ya puedes configurar Exchange para que acepte los correos del dominio Empresa.com y asigne a los usurios una dirección SMTP del domino Empresa.Local.

Para hacer esto es necesario que crees una politica de recipientes desde la consola de Exchange «system manager»

Figura, 4. Creando una política de recipientes en Exchange (1).

Figura, 5. Creando una política de recipientes en Exchange (2)

Figura, 6. Creando una política de recipientes en Exchange (3)

Figura, 7. Creando una política de recipientes en Exchange (4)

En address pondremos nuestro dominio externo en nuestro caso Empresa.Com precedido de una @.

Es importante marcar la casilla «Esta organización de Exchange es la responsable de todo el correo de esta dirección»

Figura, 8. Creando una política de recipientes en Exchange (5)

La dirección que marquemos como primaria será la que se use para responder los correos.

En la mayoría de los casos recomiendo dejar la dirección smtp de @Empresa.local, pero es opcional.

Después de guardar los cambios y esperar un poco, la RUS que es el servicio encargado de asignar las direcciones de correo según lo indicado en las políticas de recipientes se encargara de asignar una dirección con el domino que hayamos indicado.

Respecto a las dudas relativas a la publicación de servicios en internet, tienes que tener en cuenta.

Siempre que publiques algo lo harás sobre una IP Publica y configuraras el DNS público para que resuelva el nombre que quieras en dicha IP.

Una vez que publiques en tu firewall el recurso que quieras en esa IP, los usuarios externos lo encontraran sin problemas sea cual sea el dominio interno.

Si algún recurso publicado exige validación, hay que validarse indicando el nombre del dominio interno.

A la hora de pedir certificados hay que pedirlos con el nombre del dominio externo.

Si publicas algo en ISA especifica el nombre que tendrá el recurso en internet con el dominio externo.

Si los DNS externos será también tuyos en vez de un proveedor de servicios internet tendrás que crear un split DNS, este articulo te ayudara: http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html

Si tienes que publicar varios sitios web sobre una sola ip publica tendrás que usar encabezamientos para que el IIS sepa a que sitio web quiere ir un usuario según el nombre del sitio.

Esto se puede hacer durante la creación del sitio web:

Figura, 9. Configurando un nuevo sitio web para que pueda funcionar en la misma IP que otros (1).

Figura, 10. Configurando un nuevo sitio web para que pueda funcionar en la misma IP que otros (2).

Figura, 11. Configurando un nuevo sitio web para que pueda funcionar en la misma IP que otros (3).

El resto de la configuración será normal.

Si por el contrario queremos modificar un sitio ya existente, lo haremos modificando las propiedades del sitio:

Figura, 12. Modificando un sitio web para que pueda funcionar en la misma IP que otros (1).

Figura, 13. Modificando un sitio web para que pueda funcionar en la misma IP que otros (2).

Referencias:

Para tener mas información sobre como funciona el DNS dentro de una empresa puedes leer el articulo http://geeks.ms/blogs/dmatey/archive/2007/01/16/basicos-configuraci-n-de-dns.aspx

Para información sobre por que es mejor usar diferentes nombres y una visión mas general del DNS: http://www.microsoft.com/latam/technet/articulos/200110/art03/default.asp

Con este articulo empiezo una nueva serie de artículos denominados Básicos.

Como todos sabéis, este sitio web está dedicado a la arquitectura informática tanto de infraestructuras como de soluciones y por lo tanto suelo tratar temas de nivel medio/alto.

Desde hace un tiempo colaboro en los foros de la TechNet de Microsoft, donde veo que continuamente aparecen preguntas de carácter básico.

Los artículos de esta serie «básicos» están orientados a responder a esas preguntas sencillas que aunque ya están mas que respondidas por la documentación de Microsoft, algunos administradores siguen sin saber aplicar y requieren de una explicación más sencilla.

Introducción:

Cuando Windows 2000 salió al mercado, el directorio activo fue la mayor novedad y la funcionalidad con mayores repercusiones, desde el principio me di cuenta de que el DNS seria uno de los mayores focos de problemas, dado que la mayoría de los administradores de Windows no habían tenido ninguna relación con este servicio que fuera mas lejos que la resolución de nombres en internet.

En este articulo hablaremos de cómo hay que configurar el DNS en una empresa usando Windows 2003.

Primeros pasos:

Cuando hacemos DCPromo se configura automáticamente un servidor DNS en el mismo servidor en el que hemos lanzado el DCPromo, es común que muchos técnicos instalen a mano el servicio de DNS desde quitar y añadir programas del panel de control antes de lanzar el DCPromo.

En ese caso el DCPromo configurara el servicio para funcionar con el directorio activo.

En posteriores controladores de dominio, siempre deberos de ser nosotros los que instalemos el servicio de DNS, antes de lanzar el dcpromo.

Normalmente las empresas tendrán dos necesidades con respecto al DNS interno:

· Que sea capaz de resolver direcciones de internet para que los usuarios puedan navegar y el correo electrónico funcionar correctamente.

· Que permita el buen funcionamiento del directorio activo y resuelva correctamente los nombres y dominios internos.

El error mas común en las pequeñas empresas es poner como DNS de los puestos a un servidor DNS de internet para que pueda navegar.

Cuando se configura un puesto o un servidor de esta manera, no pasa demasiado tiempo antes de que empiecen a aparecer los problemas, GPOs que no se aplican, puestos que tardan en arrancar, recursos de red que desaparecen, etc.

Para que un puesto funcione bien, todos los DNS que use, tienen que ser controladores de dominio.

¿Qué controladores de dominio se deben usar como DNS?, el primario será el controlador de dominio (DC) más cercano que tenga el puesto, el secundario el siguiente aunque este en otra oficina, de esa forma si un DC deja de funcionar el puesto trabajara con normalidad usando otro DNS de otro DC.

¿por que los puestos y los servidores dependen tanto de los DCs para todo lo relacionado con el directorio activo?, en Windows NT, los puestos y servidores encontraban a los PDC y BDC usando broadcast netbios, esto era un problema por muchas razones que no vienen al caso, con el fin de solucionar este problema, Microsoft acertadamente decidió que los DCs y GCs se localizaran a través del DNS.

Cuando un DC arranca su servicio de Netlogon escribe en el DNS una serie de registros que ayudaran a que los puestos lo localicen y sepan que servicios presta, por esta razón estos registros se denominan «locators»

Puedes ver dichos registros entrando en la consola del DNS y luego en la zona de tu dominio:

Figura, 1. Uno de los registros locator de un servidor DC.

Por lo tanto ya conocemos la regla básica del buen funcionamiento del DNS, todas las maquinas tendrán como DNS a los controladores de dominio de su red.

¿Qué DNS tienen que tener configurados los controladores de dominio?, por regla general todo DC se tendrá a sí mismo como DNS primario y al DC más cercano como secundario.

En otros casos se pueden poner como secundarios otros DCs de otros sites, pero esa es una configuración más avanzada que no es el objetivo de este articulo.

Hemos visto que el DCPromo es capaz de configurar nuestro servidor DNS, pero desgraciadamente no realiza el procedimiento completo.

NSlookup es una herramienta de línea de comandos que nos permite interrogar a los servidores DNS, si la ejecutamos se conectara automáticamente al DNS primario que tengamos configurado en la maquina en la que lo corramos.

Figura, 2. Nslookup.

NSlookup nos dice que no puede encontrar el nombre para el servidor con la IP 192.168.0.11, que en nuestro caso es la IP de nuestro DC.

¿Por qué no puedo encontrar el nombre para la IP de mi DC?, cuando DCPromo configura el DNS lo hace para que podamos averiguar que IP tiene un nombre, esto se llama forward resolution, pero para averiguar el nombre que tiene una IP hay que lanzar una reverse resolution.

Para solucionar este problema tendremos que crear una zona de resolución inversa en el servidor de DNS, esta zona de resolución inversa es válida solo para una subred, tendremos que crear una zona por cada subred que tengamos.

En este articulo estamos usando la subred 192.168.0.0 con mascara 255.255.255.0, vamos a crear la zona de resolución inversa para esta red.

Figura, 3. Creando zona de resolución inversa (1)

Figura, 4. Creando zona de resolución inversa (2)

Figura, 5. Creando zona de resolución inversa (3), eligiendo el tipo de zona y si se  almacenara en el AD.

Figura, 6. Creando zona de resolución inversa (4), especificando a que servidores se replicara dentro del Forest.

Figura, 7. Creando zona de resolución inversa (5), indicando la subred de la que se hará cargo la zona.

Figura, 8. Creando zona de resolución inversa (6), especificando si la zona permitirá actualizaciones automáticas de los DHCP y puestos.

Figura, 9. Creando zona de resolución inversa (7), finalizando.

Figura, 10. Creando zona de resolución inversa (8), zona ya creada y con el registro del DC introducido.

¿Cómo se crea un registro PTR?, los PTR son los registros de las zonas de resolución inversa, pulsa sobre la zona con el botón derecho, selecciona «nuevo registro PTR» y rellena el formulario indicando la parte de la IP que no está contenida en la máscara y el nombre completo del servidor al que hará referencia el registro PTR.

Figura, 11. Creación de un registro PTR.

Figura 12. Probando de nuevo con nslookup.

Como podemos ver en la figura 12, el nslookup ya funciona correctamente, gracias a la zona de resolución inversa ya es posible encontrar nombres a partir de IPs, esto tan simple, nos ahorrara múltiples problemas en el futuro.

¿Que pasa con Internet?

Si has configurado todo como te hemos indicado hasta ahora, tu dominio funcionara bien a nivel de DNS, pero tus puestos y servidores no podrán resolver nombres de internet, si tratamos de por ejemplo hacer un ping a http://www.google.com/, no obtendremos respuesta.

Figura , 13. Ping fallido a http://www.google.com/

Para resolver esta situación necesitamos que al menos uno de nuestros DNS sea capaz de resolver direcciones de internet, esto se consigue gracias a los reenviadores o forwarders.

Es importante que comprendamos que los forwarders se configuran para cada servidor DNS, esto significa que :

1) Podemos configurar forwarders en todos nuestros servidores DNS hacia unos controladores de domino concretos que tengan los forwarders hacia internet.

2) Podemos configurar todos nuestros servidores DNS para que tengan como DNS secundarios en las tarjetas de red a los servidores DNS con los forwarders activados (esta solución hace que la resolución sea mas lenta)

3)También podemos configurar forwarders en todos los servidores DNS de nuestra empresa.

La elección es vuestra, aunque a mí me gusta más la opción de configurar forwarders en todos los servidores DNS hacia dos Controladores de dominio concretos que sean los que tengan los forwarders para resolver en internet.

En las empresas pequeñas es común encontrar un solo DC que además sea el único DNS, con lo cual solo hay que configurar un servidor con forwarders.

¿Que dns de internet uso para los reenviadores?, la costumbre es usar los DNS de tu proveedor de internet, otra solución es ver que servidores DNS son mas rápidos y usarlos como reenviadores, ya que esta velocidad puede mejorar el rendimiento de tus consultas en internet.

Puedes ver la lista de DNS de los ISP en http://www.adslzone.net/dns.html o http://www.34t.com/box-docs.asp?doc=886

¿Cómo funcionan los reenviadores?, para contestar a esta pregunta veamos el siguiente diagrama.

Diagrama, 1. Funcionamiento de los reenviadores

Vemos en el diagrama que si un puesto pide resolver una dirección como por ejemplo http://www.google.com/, pasara lo siguiente:

1- El puesto se lo pide al servidor DNS que tenga configurado como primario en la tarjeta de red, ya hemos aprendido que este servidor tiene que ser un DC del dominio en el que este el puesto.

2-El servidor ve que no tiene ninguna zona google.com y por lo tanto usa el reenviador que tenemos configurado para solicitar al servidor DNS que hayamos indicado que le resuelva el registro http://www.google.com/.

3-El servidor DNS de internet resuelve http://www.google.com/ y responde a la solicitud de nuestro DC.

4-El DC cachea la respuesta para poderla responder directamente si algún puesto se la hace de nuevo.

5-El DC responde al puesto con la dirección de http://www.google.com/.

Estupendo, eso es lo que quiero!!!!! ¿Cómo configuro el reenviador?

Es muy sencillo, antes que nada te tienes que asegurar de que tu controlador de dominio sabe llegar a internet y que tu router y tu firewall le están dejando usar el puerto 53 de salida para que pueda acceder al los servidores DNS en internet.

Puedes ver si todo esto se cumple, es tan fácil como usar nslookup para probarlo.

En nuestro caso vamos a probar con un DNS de telefónica (80.58.0.33)

Figura, 14. Probando si el DC puede usar un DNS de internet con NSlookup.

Para conectarnos con un servidor DNS tenemos que usar el comando server dentro de nslookup indicando la ip del servidor.

Después podemos escribir directamente el nombre que queremos resolver.

Si esto no funciona, significa que alguna de las siguientes cosas está fallando:

1) El servidor no sabe cómo llegar a internet, tienes que indicar a tu servidor que use como puerta de enlace predeterminada al dispositivo de tu red que de acceso a internet como por ejemplo un router o un firewall.

2) Tu firewall no está dejando que el servidor salga por el puerto 53 de TCP y de UDP, tienes que configurar una regla en tu firewall que deje salir al DC por el puerto 53 de TCP y UDP.

Para configurar el reenviador o forwarder sigue estos pasos:

Figura, 15. Configurando el reenviador (1)

Figura, 16. Configurando el reenviador (2)

Puedes meter tantos servidores DNS como quieras, también puedes configurar reenviadores para dominios específicos, esta solución se emplea por ejemplo cuando se crean relaciones de confianza o hay varios forest dentro de la misma empresa.

Ahora que ya tenemos configurados los forwarders, nuestro DC ya podrá resolver nombres de internet.

Figura, 17. Probando el forwarder con NSlookup.

Una cosa muy interesante de la que hemos hablado es la cache, la cache permite que los servidores DNS guarden las resoluciones que ya se han hecho y en caso de que se le pida de nuevo a un servidor DNS una consulta que tenga en la cache, el servidor la devolverá directamente de la cache, esto acelera el acceso a internet y es muy interesante para los proxys y los servidores de correo.

Puedes ver la cache haciendo lo siguiente.

Figura, 18. Viendo la cache (1)

Figura, 19. Viendo la cache (2)

¿Entonces como funcionara el DNS si tengo varias oficinas?, si tienes varias oficinas, se pueden dar los siguientes casos:

1) La oficina es pequeña y no cuenta con un DC propio, por lo tanto los puestos tendrás configurados como DNS los DCs de la central y funcionaran como has visto hasta ahora.

2) La oficina tiene bastantes usuarios y cuenta un DC propio, en ese caso, el DC de la delegación se tendrá así mismo como DNS primario y como secundario al de la central, que cuenta con el forwarder, el funcionamiento sería el siguiente:

Diagrama, 2. Resolución en un escenario con DC en delegación.

1- El puesto se lo pide al servidor DNS que tenga configurado como primario en la tarjeta de red, ya hemos aprendido que este servidor tiene que ser un DC del dominio en el que este el puesto, en este caso además es el DC que esta en su delegación.

2-El servidor ve que no tiene ninguna zona google.com y por lo tanto usa el DNS que tiene como secundario para realizar la solicitud al DC en la central, también se puede configurar un forwarder en este servidor para que use al de la central.

3-El servidor DNS de de la central usa su forwarder para hacer la solicitud

4- El DNS de internet resuelve http://www.google.com/ y responde a la solicitud de nuestro DC en la central.

5- El DNS de la central cachea la resolución.

6- El DNS de la central responde al DNS de la delegación con los datos de la resolución.

7-El DC cachea la respuesta para poderla responder directamente si algún puesto se la hace de nuevo.

8-El DC responde al puesto con la dirección de http://www.google.com/.

Tengo aun alguna cosa más que contar sobre las pruebas de softgrid:

La primera es que aunque ejecutamos la aplicación que habíamos virtualizado (PowerPoint Viewer), tal y como habíamos dicho, solo se tendría que haber bajado al cache local, la parte que hemos usado del mismo.

Si vemos la consola cliente, veremos lo siguiente.

De momento solo hemos bajado el 55% de la aplicación, si entramos en las propiedades de ese paquete, podemos cargarlo completo pulsando sobre load.

En la zona del reloj podemos ver el icono del softgrid (esto se puede configurar en la consola cliente), este icono nos permite también recargar las aplicaciones a mano, ver los mensajes del cliente y trabajar off-line, si tenemos el paquete completamente descargado, es posible trabajar off-line.

La eterna pregunta será, ¿y la red, cuanto carga la red?, así que os responderé de la única forma que se, con datos.

Bien, el paquete tenia 8Mb, al hacer una carga completa en la red se han movido 9.5Mb, llegando a estar el interfaz del servidor al 40%, durante un instante.

Está claro que la primera vez que una aplicación corra o cuando sea necesario descargar partes de la aplicación a la cache local, la aplicación no irá tan rápido como si estuviera en local, pero creo que es un mal menor dadas las ventajas de la solución.

También creo que lo que si hay que tener en cuenta es el dimensionamiento del networking y de los interfaces de red del servidor.

Respecto a las actualizaciones del software virtualizado, estas se hacen desde el secuenciador, abriendo el paquete para actualización.

Con una licencia especial, es posible usar SoftGrid en los servidores de Terminal, de esta forma se puede desplegar las aplicaciones a los servidores de la granja de terminales y aprovechar otras ventajas tales como el control de licencias o los informes.

Y con esto, oficialmente y salvo preguntas que gustosamente responderé en los foros de la technet, termino mi exposición de SoftGrid.

El cliente es el software que permite que el puesto se conecte con el servidor, vea las aplicaciones que están asignadas al usuario que ha arrancado el equipo, creo los iconos y se encarga del streaming de la aplicación con el servidor.

La consola cliente nos permite ver información sobre las aplicaciones asignadas al usuario, la cache de aplicaciones y otras funcionalidades, si queremos instalar la consola en un servidor o en un puesto que no quiera el cliente

El cliente se puede desplegar usando las GPO, ya que es un MSI.

Se puede establecer el tamaño máximo que podrá ocupar el cache de aplicaciones virtualizadas.

Hay que indicar que servidor (se puede usar NLB) hay que usar para conectarse.

Una vez que hemos instalado el cliente ya tendremos dos servicios corriendo (como local system).

La consola la instalaremos en el servidor, para ello seleccionaremos instalar el servidor y utilidades y luego en “custom setup” seleccionamos solo la consola cliente

Al arrancar el XP con el usuario Prueba, que pertenece al grupo al cual le asignamos la aplicación en el softgrid, tendríamos que tener ya el menú del PowerPoint y el icono en el escritorio.

¿y si no?

Bueno los problemas más frecuentes son:

El directorio en el que dejas los proyectos tiene que ser un share y el grupo de usuarios a los que asignas las aplicaciones tiene que tener acceso a ese share.

Dentro de la aplicación la ruta a los ficheros tiene que hacer mención a ese share.

Lo mismo pasa en el tab de “file associations”

Lo mejor es que os aseguréis que en la consola del servidor en la raíz si os meteis en la opción de “system options” veais que se menciona el share en el que habeis dejado el osd.

Bien si seguís teniendo problemas, dentro del PC en el que tenéis el cliente, hay un log, está en:

“C:archivos de programassoftcricitysoftgridsoftgrid for Windows desktopssftlog.txt”

En ese mismo directorio teneis una consola que se llama sftCMC.msc que os permite realizar operaciones con el cliente, tales como recargar las aplicaciones, cachearlas completas, etc.

Si en algun momento queries borrar este archivo de log, tendreis que parar los dos servicios antes.

Los logs del event viewer no es que digan mucho, asi que fijaros en este log, en el “policy provider” tambien podeis añadir un log en fichero, aunque por defecto lo déjà todo en BD.

Si todo va mal, lo mejor es importar otra vez la aplicación.

Alguna vez me ha pasado que empiezan a salir errores como el siguiente en el event viewer del servidor, sin embargo las últimas veces he creado el share sobre C:Program FilesSoftricitySoftGrid Servercontent y hay me ha ido bien siempre (aseguraros que dejais los archivos resultantes de la secuenciación en ese directorio).

Bien, llega el momento que esperáis, ejecutar la aplicación 😀

Cuando lancéis la aplicación fijaos en el lado derecho inferior de la pantalla, veréis una barra de progreso con la carga del streaming de la aplicación, como veis la aplicación se ejecuta con normalidad.

Si vamos al task manager, todo parece normal.

Sin embargo si buscamos la aplicación por ejemplo en el sistema de ficheros, no la encontraremos.

Como has podido leer en la parte 1, 2 y 3 de este articulo, hemos instalado el servidor de Softgrid y hemos virtualizado la aplicación “Power Point Viewer”, el paso siguiente es importar esa aplicación virtual dentro del servidor SoftGrid y después asignársela al grupo de usuarios que queramos que la use.

El paso siguiente que veremos en la parte 5 será instalar el software cliente de softgrid en un PC con XP y ejecutar el “PowerPoint Viewer”.

Importando la aplicación.

Desde la consola del servidor.

Seleccionamos el nodo “applications” después botón derecho y “Import Applications”

Seleccionaremos el proyecto que hicimos antes.

Marcamos el grupo de servidores, como veis aquí también se puede seleccionar el grupo de licencias que queremos.

En esta pantalla configuramos como queremos que se publique la aplicación en los puestos.

Las asociaciones.

Luego seleccionamos que grupo de usuarios va a tener acceso a esta aplicación en mi caso he creado un grupo especial, con esta nomenclatura podre buscar estos grupos programáticamente y localizarlos con facilidad.

Como podeis ver si os dais una vuelta por la consola, la aplicación se ha introducido automáticamente en todas las partes de la consola donde debería de estar y podemos ver diferente información sobre ella.

 Ya queda poco para poder ejecutar la aplicación.

Supongo que habrás leído la parte 1 y parte 2 de esta serie de artículos y por lo tanto ya sabes lo que es el secuenciador aparato usado por el alto evolucionador para alterar el código genético de los humanos mezclándolos con bestias en los comics de marvel.

En esta parte instalaremos el secuenciador y vitualizaremos una aplicación y posteriormente dominaremos el mundo (óigase una risa maligna de fondo).

Ya tenemos instalado el secuenciador, el paso siguente será secuenciar una aplicación.

El proceso de secuenciación es en realidad sencillo de realizar, pero debió de ser muy complicado de inventar.

Otros programas dedicados a realizar ficheros de instalación, ya usaban el mismo sistema que softgrid hace mucho tiempo.

El sistema muy resumido es el siguiente,

1-inicias el proceso

2-El secuenciador se pone a monitorizar todo el sistema analizando que está pasando en el

3-Instalas el programa que quieras virtualizar con absoluta normalidad.

4-El secuenciador ha aprendido y guardado todo lo necesario para virtualizar el programa

5-Tienes la aplicación virtualizada.

Por lo tanto la aplicación virtualizada es el resultado de la resta del sistema después de la instalación y el sistema antes de la instalación y la suma de todas las dependencias del programa instalado.

Os recomiendo que useis una maquina limpia para realizar la secuenciación, yo uso una maquina virtual en la que no guardo los cambios, de esta forma me aseguro de que el proceso es lo mas limpio posible.

Empecemos:

Creamos un nuevo paquete.

Como es la primera vez, es mejor que le deis al “yes”

Como no se que virtualizar, voy a virtualizar el visor del powerpoint que es pequeño.

En el paso siguiente hay que seleccionar que sistemas operativos podrán usar este programa.

Bien, como decíamos al principio lo siguiente que pasara es que el secuenciador tiene que aprenderse la aplicación que queremos virtualizar, para ello tenemos que pulsar el botón “begin monitoring”

Ahora intalamos el visor del powerpoint con normalidad. 

Luego paramos la monitorización del secuenciador.

Luego hay que seleccionar donde queremos dejar el fichero, nosotros seleccionaremos la carpeta content donde tenemos el share. 

En la siguiente pantalla se pueden añadir ficheros a mano al sistema de ficheros virtual de la aplicación, el añade algunos por defecto.

Softgrid ya ha aprendido que extensiones tiene que usar la aplicación live writer y también sabe ya que iconos y que menus tiene que poner en el menú inicio, ¿no es alucinante?

 En el paso siguiente, haremos un lunch de la aplicación, esto hara que el paquete se optimice para el streaming.

Se arrancara el powerpoint viewer, lo cerramos y continuamos.

La aplicación esta virtualizada.

Si urgamos un poco, veremos cómo ha capturado dentro de la imagen todas las dependencias, como por ejemplo el framework.

El Registro

Los ficheros.

El Powerpoint viewer no usa servicios, si no los hubiera capturado también.

El paso siguiente es salvar el paquete, dentro del menú “file” pulsamos en “save as”

Fantástico el paso siguiente será importar la aplicación en el servidor softgrid.

Pero antes de dejaros con la miel en los labios, ¿no os preguntáis cuanto ocupara la aplicación virtualizada?.

El instalador del PowerPoint Viewer ocupa unos 2Mb, el fichero SFT que es el que contiene la aplicación virtual ocupa 8Mb.

Pero gracias a esos 8 Mb, podremos correr la aplicación incluso en PCs que no cumplan con los requisitos de software, no penséis que es una escala, lo que pasa es que el PowerPoint Viewer no tiene muchas dependencias.

En la Parte 1 vimos que era SoftGrid y como se instalaba la parte servidor, ahora veremos la consola del servidor, no leas esto si no has leído la parte 1.

La consola se conecta al servidor de softgrid usando http o https, os recomiendo este último por razones obvias, aunque para poder usarlo tendréis que instalar el consabido certificado en el servidor web.

He probado que la conexión usa el famoso fichero UDL del que hablamos en la parte 1 así que cuidado con él.

Bien, veamos ahora que nos ofrece la consola del servidor SoftGrid.

Lo primero es que es muy importante que nos aseguremos que si pulsamos dentro de la raiz con el boton derecho y luego seleccionamos «options» nos tiene que aparecer referenciado el share que mencione en la parte 1, si esto no es asi, tendreis un monton de problemas mas adelante.

En el nodo “Applications”, iremos viendo las aplicaciones a medida que las secuenciemos, cuando secuenciemos nuestra primera aplicación volveremos a este menú para dar más detalles.

En el nodo de “File Type Assosiations” es donde podemos vincular las extensiones de ficheros a aplicaciones virtuales que hayamos secuenciado.

Al pulsar con el botón derecho y seleccionar nueva asociación accedemos a un wizard:

Como veis es muy sencillo; extensión, aplicación e icono, aunque en realidad como veremos mas adelante, el secuanciador rellenara esto por nosotros.

Después llegamos al nodo de “Packages” aquí es donde se irán colocando las diferentes versiones de las aplicaciones, de tal forma que a medida que las vallamos actualizando iremos contando con diferentes paquetes.

Los paquetes tienen una importancia muy alta dentro de softgrid, un paquete puede tener una o varias aplicaciones, esto vale por ejemplo para poder dar permisos a un usuario para que ejecute todas las aplicaciones contenidas en un paquete, por ejemplo el paquete del office podría tener el Word, Excel, etc.

Los paquetes tienen un atributo que es la versión, cada vez que actualicemos una aplicación para por ejemplo introducir un service pack o hotfix estaremos generando un nuevo fichero “sft” con cada fichero “sft” estamos generando un nuevo paquete.

El nodo de “Application Licenses” es muy interesante, nos permite controlar el uso de los programas que hayamos virtualizado de forma que podamos asegurarnos de que mantenemos su uso dentro de la legalidad impuesta por las licencias adquiridas.

Se nos permite agrupar las licencias en grupos y podemos tener tres tipos diferentes de licencias.

· Ilimiatadas, para aquellos programas que no necesitemos adquirir licencias individuales o que no requieran licencias.

· Concurrentes, para aquellos programas cuya licencia este limitada a un número de usuarios usando el programa a la vez, el propio softgrid evitara que alguien arranque la aplicación si se ha superado el número de licencias concurrentes.

· Nominales, las licencias nominales se conceden directamente a un usuario del directorio activo concreto y se puede indicar si la licencia está habilitada o no y la Key de la licencia, la licencia puede tener fecha de expiración.

 Se me ocurre que la integración con el inventario de software de las empresas, podría ser muy provechosa.

Como veremos la final de este articulo, SoftGrid nos proporciona una serie de informes que nos ayudaran a entender cómo se usan las licencias.

En el nodo de “Server Groups” podemos crear agrupamientos de los servidores de SoftGrid que tengamos, a los grupos se les puede asignar un “Provider Policy”, dicho provider especifica el nivel de logging y de seguridad del grupo de servidores.

 También se especifica en el grupo de servidores, que aplicaciones son las que sirven los servidores contenidos en el.

Desde la consola no se provee de ninguna agrupación real del servicio que prestan los servidores, simplemente es una forma de poder administrar algunas de sus configuraciones de una forma agrupada.

Para poder unir realmente los servidores de softgrid que formen un grupo tendremos que usar NLB o balanceadores de carga hardware.

Cada servidor cuenta además con algunas otras configuraciones individuales.

RSTP es el protocolo por el cual se hace el streaming de las aplicaciones, podemos ver también cómo es posible usar certificados para encriptar estos puertos.

Otra cosa que me parece muy interesante es que podemos limitar con bastante precisión los recursos que usara el servidor de softgrid lo cual lo hace inicialmente candidato a consolidarse con otros servidores si fuera necesario.

El siguiente nodo es el de los “Provider Policies”, como ya he comentado antes, estas políticas nos permiten establecer parámetros de configuración comunes a los servidores donde se apliquen y por lo tanto a las aplicaciones que estos presten.

Cuando creamos un nuevo provider, en la primera pantalla podremos especificar el nivel de registro de los errores que queremos tener y un parámetro muy importante, cada cuanto queremos que los escritorios refresquen las aplicaciones que tienen disponibles, por defecto los puestos solo buscaran la lista de estas aplicaciones cuando arrancan, pero podemos configurar que lo hagan cada cierto tiempo.

Después tendremos que asignar los usuarios que estarán asociados a esta política.

Por último hay que seleccionar el tipo de validación que usaremos, desde integrada hasta anónimo, esto puede afectar a la información contenida en los informes, pero puede ayudarnos en escenarios en los que los usuarios no estén en un dominio.

También podemos indicar como queremos actuar con las licencias, si solo queremos auditarlas o forzar su cumplimiento.

En “Account Authorities” vemos el acceso al directorio activo del SoftGrid, aquí será donde cambiaríamos la cuenta de acceso al AD.

En el nodo “SoftGrid Administrators” es donde podremos indicar quien puede administrar el SoftGrid.

El ultimo nodo es el “Reports” desde donde podremos sacar los siguientes informes de las aplicaciones.

En la siguiente parte usaremos el secuenciador para virtualizar una aplicación.

Introducción a softgrid.

Cuando alguien me pregunta que es lo que más me fascina de la tecnología de Microsoft que esta por venir, tengo que decir que de entre toda la vorágine de tecnologías apasionantes, las dos que me parecen más revolucionarias son Hypervisor de longhorn y Softgrid.

Hypervisor como ya sabéis es la tecnología de particionamiento que funcionara con Longhorn y que permitirá particionar el hardware obteniendo maquinas virtuales de 32 o 64 bits y hasta 8 procesadores, acceso directo al hardware y un rendimiento prácticamente semejante al de una maquina real.

Softgrid sin embargo es una tecnología de virtualización de aplicaciones y diréis ¿qué significa esto?, y yo os diré, esto es la caña, esto es como House en una guardería, como si Alonso tuviera cuello, como si Chema el Maligno se cortara el pelo y llevara traje, como si yo fuera sociable, como si mi amigo Alf dejara de usar la camiseta de Atari, esto es lo más grande a la informática de escritorio desde que el mismísimo Bill Gates decidiera comprar su primera patente.

Entonces porque Softgrid es tan, tan la leche; Imaginaros un mundo en el que en los PCs solo está cargado el sistema operativo y cualquier usuario que arranca un pc sea el que sea dentro del dominio dispone automáticamente de sus aplicaciones listas para correr usando los recursos locales de la maquina que está usando, imaginar que no hay conflictos entre aplicaciones, que todas las licencias se controlan centralizadamente, que uses el ordenador que uses, las personalizaciones que hagas en los programas que uses estarán disponibles para ti, imaginar que podéis actualizar todas las versiones de un software de forma centralizada e instantánea, imaginar que los programas solo ocuparan en disco el espacio requerido por la parte del programa que uséis.

Si todo esto fuera real, ¿no sería la leche?, ¿no sería mejor que los percebes con pan :-D?, bien pues todo esto es softgrid.

La base de softgrid es un programa llamado secuenciador, el secuenciador es usado para virtualizar una aplicación, como resultado de esa virtualización obtendremos una serie de ficheros que representan la aplicación ya virtualizada.

Una vez que se tiene la aplicación virtualizada se introduce dentro del Servidor de Softgrid, donde asignaremos las aplicaciones a usuarios o grupos de usuarios del Directorio Activo.

Los usuarios que tengan esas aplicaciones asignadas y que usen una maquina que tenga instalado el cliente de softgrid verán los iconos de los programas y los tendrán en el menú de programas, adema los archivos con las extensiones adecuadas estarán correctamente asociados a dichas aplicaciones.

Cuando un usuario ejecute uno de estos programas, el cliente de softgrid bajara la parte del programa necesaria para que corra la aplicación, esto suele ser aproximadamente un 8-10% de la aplicación, la aplicación correrá en local, podremos ver el proceso en el task manager con el nombre que tendría si lo corriéramos normalmente, la única diferencia es que en realidad no tenemos la aplicación instalada, las carpetas de la aplicación no están , las ramas del registro no están, no hay rastro de la aplicación, cuando la cerremos será como si no hubiéramos tenido nunca nada.

Esto es así por que el secuenciador virtualiza las partes del registro necesarias para la aplicación, también virtualiza las carpetas y todas las dependencias desde el framework hasta objetos com, etc.

El administrador puede decidir si las aplicaciones se bajan completas o a medida que las uses, también puede definir que se queden en el cache local del cliente softgrid y en ese caso por cuánto tiempo quieren que se queden.

Es posible unir softgrid a SMS y repartir los paquetes (aplicaciones virtualizadas) por los medios habituales en SMS.

Softgrid es una tecnología que pertenecía a una empresa que compro Microsoft y la versión actual es la 4.x.

No me extraña que lo compraran, la tecnología no hace mella (salvo en algun tema de seguridad), es como programada por Microsoft, las consolas están bien, todo bien integrado usa SQL Server para guardar las configuraciones, toda la administración se basa en Web Services.

A nivel de red, todo corre muy comprimido, es impresionante ver que funciona aceptablemente hasta por satélite y qué decir de UMTS.

Si por ejemplo un usuario tiene problemas con una aplicación, el administrador puede reiniciar esa aplicación al estado inicial de la virtualización, con lo cual problema solucionado.

Microsoft inicialmente distribuirá softgrid a los clientes a través de un paquete llamado DOPSA del que ya he hablado muchas veces en este blog, este paquete ya está disponible para los clientes con Software Assurance.

Por ultimo decir que por desgracia la versión que ha incluido Microsoft en el Dopsa Pack no es la ultima versión de softgrid.

Bueno, con esto termino la cháchara 😀 y llego a la parte en la que me mancho las manos y os muestro las pantallas del softgrid.

Instalando el servidor de softgrid.

Windows 2003 SP1, SQL Server 2005 SP1, mmc 3.0 (http://www.microsoft.com/downloads/details.aspx?familyid=4C84F80B-908D-4B5D-8AA8-27B962566D9F&displaylang=en), IIS Instalado

Ejecutamos el setup:

Instalamos el servidor y las utilidades

Instalamos el servidor y las utilidades

La consola cliente solo hay que instalarla si queremos gestionar los clientes remotamente desde este servidor.

El servidor en el que lo estoy instalando se llama sps2007 que esta heredado de una demo de Sharepoint 😀

No se para que sale un combo si solo se puede seleccionar SQL Server 😉

Yo he creado una cuenta de SQL especial para el softgrid, llamada SvcSoftGrid, pero no me gusta que no se pueda usar seguridad integrada.

El Servicio necesita otra cuenta para acceder a la base de datos, he creado otra cuenta llamada SvcSoftGridDataAccess, si usais SQL 2005 aseguraros de que la password que ponéis cumple con la política de seguridad.

Softgrid necesita una cuenta para poder acceder al directorio activo, creo una cuenta en la unidad organizativa “Services” llamada SvcSoftGridDirectoryAccess, al estar en esa OU se le aplicaran las políticas y scripts adecudos para mantener segura una cuenta de este tipo, pero eso sale del alcance de este articulo.

Creo un grupo en el directorio activo llamado GrpSoftGridAdmin donde estarán los usuarios que tengan que administrar el softgrid, tengo montado el AD de tal forma que el sistema está configurado para que todos los grupos que terminan en admin son monitorizados, si los miembros cambian, se lanza una alerta tanto al sistema forense como al MOM y por correo al oficial de seguridad, pero esto se sale de esta articulo :-D.

Hay que crear otro grupo que será el de usuarios que formaran parte del softgrid y de esta forma se les podrán asignar aplicaciones, luego podremos añadir más grupos, etc. En mi caso lo llamo GrpSoftGridUsers.

Esto es una demo, pero en producción os recomendaría que usarais un disco aparte alejado de la paginación.

Este directorio hay que convertirlo en un share ya que es desde aqui desde donde los clientes se bajaran las aplicaciones y otros contenidos.

Ok, ya esta, ya tenemos instalado el servidor.

Curioseemos.

Lo primero que vemos es una BD llamada softgrid con unas vistas muy curiosas

Jeje, esto es extensible :-D.

Luego tenemos un directorio virtual en el default website, que es donde el sofgrid ha montado sus cositas y ups un udl :-D, chungo en el UDL ha metido a capon la password :-¿???

2 puntos menos.

Bueno mañana seguimos con otro capítulo.