Soporte técnico gratuito para instalaciones y compatibilidad de Windows Vista SP1

Microsoft está actualmente ofreciendo soporte técnico gratuito para instalaciones y compatibilidad de Windows Vista SP1. El soporte está disponible en España mediante correo electrónico, o via telefónica hasta el próximo 18 de marzo de 2009.




  • Soporte técnico por Internet: Tiempo de respuesta 1 día laboral


  • Soporte técnico telefónico:



    • 902 197 198


    • 91 270 24 00 (desde Madrid capital)


  • Horario de atención telefónica:



    • Lunes a Jueves de 9:00 a 18:00


    • Viernes de 9:00 a 15:00


    • Del 1/7 al 15/9 y los días 24/12 y 31/12 (excluyendo Sábados y Domingos) de 9:00 a 14:00

También se pueden exponer temas de soporte en los grupos de noticias de Microsoft en donde los MVPs responden a las incidencias.


Más información en: https://support.microsoft.com/oas/default.aspx?ln=es-es&prid=11274&gprid=500921

Windows Vista SP1 (III de III)

La primera y segunda parte de este artículo se puede encontrar en:



Mejoras de seguridad

Sin duda este es una de las áreas de mejora más destacable que incluye Windows Vista Service Pack 1. Aunque se incluyen todos los boletines de seguridad publicados previamente al lanzamiento del Service Pack 1, además, con la actualización del sistema obtendremos los siguientes beneficios.

  • Los desarrolladores de aplicaciones tienen a su disposición un nuevo conjunto de APIs, totalmente soportadas, que permiten que las aplicaciones de seguridad y detección  de código maligno puedan trabajar junto con la protección del Kernel incluida en las versiones de 64 bits de Windows Vista. De esta forma, no es necesario desproteger el sistema o deshabilitar la protección ofrecida por Kernel Patch Protection.

  • Se mejora la seguridad de ejecución de aplicaciones remotas (RemoteApp) publicadas en servidores de terminal (Terminal Server) basados en Windows Server 2008. Windows Vista SP1 diferencia las aplicaciones firmadas digitalmente y advierte al usuario en caso de no poder comprobar la identidad de la aplicación publicada o el servidor remoto.

  • Ahora un nuevo conjunto nuevo de APIs permiten controlar el comportamiento de DEP (Data Execution Protection) mediante programación, lo cual mejora la capacidad de los desarrolladores para realizar pruebas de compatibilidad y garantizar el óptimo funcionamiento de sus aplicaciones en entornos con DEP habilitado.

  • Se mejora la confianza en la información presentada por el Centro de Seguridad de Windows (Windows Security Center), garantizando que solo las aplicaciones autenticadas se pueden comunicar con WSC

  • Se mejora la seguridad de las redes cableadas, habilitando los procesos de inicio de sesión únicos en redes autenticadas.

  • La generación de números criptográficos aleatorios se mejora, al poder utilizar más fuentes de semillas (seed), incluyendo plataformas TPM (Trusted Platform Module). Además se reemplaza el uso general que tenía PRNG (Pseudo-Random Number Generator ) con un nuevo modo específico AES-256 PRNG para las capas de usuario y kernel

  • Se incluye un nuevo soporte para tarjetas inteligentes (Smart Cards) que utilizan autenticación biométrica en vez de PIN

  • Se agrega un nuevo canal seguro de comunicación para leer el PIN de las tarjetas inteligentes.

  • BitLocker Drive Encription permite ahora el cifrado de otros volúmenes que no sean el del sistema.

  • Además Bitlocker Drive Encription ofrece un método de autenticación multi factor, que combina una clave protegida por TPM (Trusted Platform Module) con una clave de inicio almacenada en una llave USB y un número PIN generado por el usuario.

  • Los usuarios no administradores ahora pueden invocar la aplicación de copia de seguridad completa del PC (CompletePC Backup)

  • Se actualiza RDC (Remote Desktop Client) a la versión 6.1 para soportar las nuevas características de terminal Server de Windows Server 2008, incluyendo el control ActiveX para el acceso Web (TS Web Access)

  • Todos los boletines de seguridad que han sido publicados antes del lanzamiento del Service Pack 1, también están incluidos en éste. Para mayor información, la lista completa de boletines de seguridad está disponible en:  http://technet2.microsoft.com/WindowsVista/en/library/20184cb6-7038-4e82-a32c-4bc10ffe56ab1033.mspx?mfr=true 
Soporte de nuevas tecnologías

  • Service Pack 1 añade soporte de nuevos algoritmos de cifrado para IPSec:o   SHA-256, AES-GCM y AES-GMAC para ESP y AHo   ECDSA, SHA-256 y SHA-384 para IKE y AuthIP

  • Se agrega Criptografía de Curva Elíptica (ECC) NIST SP 800-90 a la lista de Generadores de Números Pseudo Aleatorios (PRNG)

  • Se agrega soporte para SSTP (Secure Sockets Tunnel Protocol), lo cual reduce los problemas de establecimiento de túneles  VPN en escenarios con NAT transversal, Proxy Web y Firewalls. SSTP forma parte de las novedades de la plataforma RRAS (Routing and Remote Access Service) de Windows Server 2008

  •  Se soporta completamente el estándar IEEE 802.11n de redes inalámbricas

  • Windows Smartcard Framework cumple con las Directivas de la Unión Europea relativas a las firmas digitales (EU Digital Signature Directive) y los sistemas de identificación digital (National ID / eID)

  • Se Mejora el Firewall de Windows para que cumpla con todos los requisitos y algoritmos de cifrado que forman parte de la iniciativa Suite B de la NSA (National Security Agency) de Estados Unidos. Más información en: http://www.nsa.gov/ia/industry/crypto_suite_b.cfm 
Administración y otras mejoras generales

  • Ahora los usuarios pueden seleccionar los volúmenes lógicos que se quieren defragmentar.

  • Los administradores pueden configurar los clientes NAP para que se reciban las actualizaciones desde Windows Update o Microsoft Update. Anteriormente sólo se permitía el uso de WSUS para este propósito.

  • Se puede configurar el tiempo que un cliente NAP debe recibir y enviar un estado de salud (SoH), lo que permite que el cliente NAP responda a tiempo cuando una conexión tiene un requisito de tiempo máximo de conexión (timeout)

  • Se pueden utilizar registros de DNS para localizar servidores con Autoridades de Registro (HRA), en el caso que no existan HRA configuradas mediante GPO

  • Se permite que equipos clientes con un estado de salud correcto, por ejemplo personal de soporte técnico, se conecten mediante IPSec a clientes con un estado de salud no válido. Esto mejora el soporte de NAP en escenarios en donde se necesitan  resolver problemas e incidencias de clientes con estados de salud no válidos.

  • Los administradores pueden desplegar dispositivos de impresión a través de la web (Web Services for Devices) a equipos remotos basados en Windows Vista o Windows Server 2008 a través de la consola de administración de impresión.

  • Se mejora la impresión en impresoras instaladas localmente desde una sesión de terminal.

  • Se permite que los usuarios eliminen o renombren carpetas redirigidas mientras están trabajando en modo desconectado (offline). Aunque esta funcionalidad está deshabilitada por defecto, puede ser habilitada mediante la modificación de una entrada de registro. Es importante para aquellos usuarios que trabajan durante largos periodos en modo desconectado.

  • Ahora un administrador puede configurar las propiedades de una red como el nombre y desplegarla mediante GPO

  • Se permite que el servicio KMS (Key Management Service) se ejecute en un equipo virtual

  • Se agrega soporte para hotpatching, lo cual reduce significativamente la necesidad de reiniciar el equipo después de aplicar una actualización. Permite que los componentes sigan en uso mientras se están actualizando. Para ello se requieren paquetes de actualización habilitados con tecnología Hotpatched y el proceso de instalación es el mismo que otros paquetes.

  • Se permite la instalación y despliege de versiones de 64 bits de Windows Vista desde sistemas de 32 Bits, lo cual significa que los administradores pueden mantener una única imagen de WinPE (Windows Preinstallation Environment)

  • Se mejora el proceso de despliegue de actualizaciones cuando falla la instalación. Hay situaciones en las que se requiere una actualización antes de instalar otra. En estos casos, el proceso fallido se reintenta una vez completados todos los requisitos previos.

  • Se mejora la estabilidad durante los procesos de instalación de actualizaciones, haciendo el proceso más resistente a errores temporales como violaciones de acceso, interrupción de flujo eléctrico, etc.

  • La instrumentación del sistema se ha actualizado para permitir el envío de datos adicionales a Microsoft mediante CEIP. Con estos datos se han podido identificar numerosas incidencias que ahora se han resuelto en el Service Pack 1.

  • Se mejora el informe de memoria instalada, indicando la memoria física real y no la memoria disponible por el sistema, como ocurría anteriormente. Por lo tanto, aquellos equipos de 32 Bits con 4 GB de memoria RAM instalados, reflejarán los  4 GB físicos en las propiedades del sistema. En cualquier caso, este comportamiento depende de que el BIOS sea compatible, por lo tanto no todos los usuarios observarán este cambio.

  • Se reduce el número de consultas de UAC (User Account Control) desde 4 a 1 cuando se crean o renombran carpetas en una ubicación protegida.

  • Se eliminan dos exploits que afectan a la estabilidad y seguridad del sistema


    • Exploit de BIOS OEM que modifica el sistema de archivos y el BIOS para simular la activación de producto realizado en copias de Windows preinstalados de fábrica.

    • Exploit que resetea el periodo de gracia que se otorga después finalizar la instalación, hasta que se solicita la activación del producto.

Windows Vista SP1 (II de III)

La primera parte de este artículo se puede encontrar en http://geeks.ms/blogs/vista-tecnica/archive/2008/02/23/windows-vista-sp1-i-de-iii.aspx 


Desde el pasado 14 de febrero ya está disponible Windows vista SP1 para todos los suscriptores de MSDN y TechNet Plus, así como los clientes de licenciamiento por volumen.  Para aquellos que ya dispongáis del paquete de actualización, recordad que Microsoft recomienda revisar algunos requisitos antes de instalar Windows Vista SP1:


·         A pesar de que la instalación crea automáticamente un punto de restauración, siempre se recomienda hacer una copia de seguridad de la información importante.


·         Se debe desinstalar cualquier versión previa del SP1 (Beta1, Beta2, RC, etc…)


·         Se debe revisar el espacio disponible que tenemos en el disco del sistema:
















Método de instalación Requisitos de espacio necesario aproximado

Instalación individual (paquete de actualización)

Sistemas x86: 2,500 MB a 5,450 MB
Sistemas x64: 4,100 MB a 7,850 MB
Windows Update Sistemas x86: 1,200 MB
Sistemas x64: 1,500 MB
Instalación integrada

15 GB

 

Para aquellos que instalen Windows Vista SP1 a través de Windows Update, tendrán que instalar algunas actualizaciones antes de proceder a la instalación del SP1:


·         KB935509 (Solo es necesario para equipos con Windows Vista Enterprise o Windows Vista Ultimate)

·         KB938371

·         KB937287


Estas actualizaciones garantizan que Windows vista siga funcionando correctamente después de la actualización. Una vez instaladas, se podrá seleccionar la actualización del Service Pack 1 (KB936330)


Microsoft ha publicado también una actualización que resuelve algunos problemas enviados por algunos clientes con respecto a la actualización KB937287. Para más información http://support.microsoft.com/kb/949358/en-us


Para aquellos administradores que requieran una instalación desatendida en los equipos de su organización, pueden utilizar los siguientes parámetros cuando desplieguen la actualización a sus equipos:

·         windows6.0-kb936330-x86.exe [/quiet] [/nodialog] [/norestart]

·         windows6.0-kb936330-x64.exe [/quiet] [/nodialog] [/norestart]


En esta segunda entrega de la serie dedicada a Service Pack 1, comentaré algunas de las principales características que muchos estábamos esperando. Comenzaré con el área de soporte de Hardware:


·         Se añade soporte para firmware UEFI (Unified Extensible Firmware Interface) de sistemas de 64 Bits. Esto permite que Windows Vista se instale en discos con formato GPT y realizar las operaciones habituales de hibernación, restauración e inicio del sistema desde UEFI. Una de las principales ventajas de UEFI con respecto al antiguo BIOS es que no es específico de una arquitectura concreta, como sí ocurre con BIOS y x86 16 Bits. Por ello UEFI puede evolucionar a lo largo del tiempo adaptándose a nuevas arquitecturas de hardware.


·         Se añade soporte para Direct3D 10.1 y se extiende el soporte de API para nuevo hardware y nuevas características gráficas.


·         Se añade soporte para formato exFAT, que extiende la capacidad de los dispositivos de memoria Flash y almacenamiento extraíble, y también el tamaño de los archivos, por ejemplo imágenes de muy alta resolución.


·         Se añade soporte para identificar con nuevos íconos los formatos de alta definición como HD DVD (ya muerto) y Blu-Ray


·         Agrega al decoder de MPEG2 soporte de protección de contenido en equipos con hardware de sintonización digital de cable, además se mejora la aceleración por hardware cuando estamos reproduciendo un DVD en nuestro PC.


·         Durante el desarrollo del Service Pack 1 se han agregado más de 70.000 nuevos controladores de dispositivos a Windows Update, lo que reduce significativamente los problemas de compatibilidad de hardware que tuvo la versión RTM en los meses posteriores al lanzamiento.


Estabilidad:


·         Gracias a los cambios introducidos en el proceso de recolección de errores (Windows Error Reporting) y la colaboración de los usuarios, ahora el Service pack 1 resuelve importantes problemas de estabilidad.


·         Previene la perdida de datos mientras se desconecta un dispositivo de almacenamiento extraíble formateado con NTFS


·         Mejora las conexiones con IPSec e IPv6, al excluir de IPSec el tráfico de descubrimiento de red


·         Mejora el tiempo de conexión entre redes inalámbricas ad-Hoc (de equipo a equipo)


·         Mejora las comunicaciones P2P de Windows Meeting Space y Asistencia Remota cuando ambos equipos están detrás de un firewall simétrico


·         Ahora la herramienta de copias de seguridad permite incluir carpetas y archivos cifrados con EFS


Rendimiento y consumo


·         Mejora el rendimiento cuando examinamos la red local, consumiendo menos ancho de banda.


·         Elimina el problema de video chipset (VSync interrupt) que evita que el sistema pueda entrar en un estado de ahorro de energía.


·         Reduce el consumo de energía evitando que el disco duro se mantenga girando en situaciones en las que no era necesario.


·         Mejora la velocidad de agregar y extraer archivos comprimidos desde carpetas zip


·         Mejora la velocidad de navegación en carpetas con muchos archivos


·         Mejora el rendimiento de copia de archivos utilizando BITS (Background Intelligent Transfer Service)


·         Mejora el rendimiento cuando se copian archivos localmente en el mismo disco (25% más rápido), cuando se copian archivos desde un equipo remoto que no es Windws Vista a un equipo con Windows Vista SP1 (45% más rápido) y cuando se copian entre equipos con Windows Vista SP1 (50% más rápido)


·         Ajusta la estimación de copia y la barra de progreso mientras se copiar archivos con Windows Explorer


·         Mejora en 50% el tiempo necesario para leer imágenes grandes


·         Resuelve un problema que provocaba que un equipo tardara hasta 5 minutos en iniciar cuando se hacía desde ciertos discos duros habilitados para ReadyDrive


·         Mejora la efectividad de un dispositivo ReadyBoost, reduciendo el tiempo para restaurar desde un estado de hibernación y en espera.


·         Incluye mejoras en SuperFetch que reducen los tiempos de espera


Una nota final para aquellos usuarios que administran entornos de Directorio Activo y específicamente GPOs. Cuando instalamos Windows Vista SP1, se desinstala del equipo la consola GPMC ya que ésta se sustituirá por una nueva versión que estará disponible junto con el lanzamiento de Windows Server 2008. Es importante tener esto en cuenta ya que en caso de que sea necesario administrar GPOs mediante GPMC en Windows Vista, es recomendable mantener un equipo con la versión RTM hasta que Microsoft publique la actualización más adelante en: http://go.microsoft.com/fwlink/?LinkId=108437.

Windows Vista SP1 (I de III)

Ya casi está aquí. El pasado 4 de febrero se anunció oficialmente el lanzamiento RTM de Windows Vista SP1, aunque no lo tendremos disponible vía Windows Update o Download Center hasta mediados de marzo.


Cuando ya llevamos más de un año desde que salió Windows Vista, el Service Pack 1 va a aportar muchas mejoras que los clientes han y usuarios han identificado y demandado durante este tiempo. Especialmente en lo que se refiere a rendimiento, estabilidad, compatibilidad con controladores y seguridad.


Windows Vista SP1 lo podremos instalar, como habitualmente, directamente desde la red, o en modo offline con el paquete de actualización descargado localmente. La diferencia con respecto a otros Service Packs es que el paquete de actualización contendrá los 36 idiomas en que está disponible Windows Vista (por el momento solo están disponibles inglés, francés, japonés, alemán y español), por lo tanto, una única descarga nos sirve para cualquier implantación, dentro de la misma plataforma (x64 o x86). Esta característica, que ya se anunció en su momento, es ideal para el despliegue en grandes empresas, ya que minimizamos el esfuerzo de mantener múltiples paquetes de actualización. Además, se pueden utilizar servicios de gestión de sistemas como SMS 2003, SCE 2007 o SCCM 2007 para desplegar el paquete a los equipos.


Para aquellos usuarios de casa o usuarios finales, es recomendable que realicen la actualización desde Windows Update (instalación express) ya que solamente se descargarán los archivos que sea necesario actualizar.


La diferencia en tamaños puede ser importante, variando desde los 50MB para una actualización online, hasta los 500 MB del paquete de actualización offline.


Una tercera opción para instalar Windows Vista SP1 es para fabricantes OEM y nuevas implantaciones, utilizando imágenes en DVD o ISO para clientes de Licencias por Volumen y Technet ya integradas (slipstreamed). Sin embargo Microsoft no pondrá a disposición de usuarios y clientes estas imágenes hasta mediados de abril, así que tendremos que esperar un poco más.


También en esas fechas se pondrá a disposición de los usuarios el Serivce Pack 1 para aquellos que tengan habilitadas las descargas automáticas y además se incluirán el resto de idiomas disponibles en Windows Vista. Mientras tanto, el usuario puede descargarse el paquete de actualización desde Download Center o acudir a Windows Update para seleccionar la actualización.


El próximo artículo entraremos en los detalles de los cambios que incluye Windows Vista SP1, principalmente en las siguientes áreas:


·         Soporte de Hardware


·         Estabilidad


·         Rendimiento y consumo de energía


·         Seguridad


·         Soporte de nuevos estándares


·         Administración y otras mejoras generales


Mientras tanto me gustaría destacar que algunas de las mejoras, han sido incorporadas a partir del desarrollo de Windows Server 2008, ya que muchos archivos y componentes son idénticos entre ambos sistemas. Gracias al desarrollo que ha tenido Windows Server 2008 durante algo más de una año después de que Windows Vista saliera al mercado, ciertas características propias de la versión de servidor las veremos también disponibles y actualizadas en este Service Pack 1, por ejemplo:


·         EL subsistema de gestión de recursos compartidos se ha mejorado y optimizado en Windows Server 2008 para soportar miles de conexiones simultáneas. Aunque los sistemas cliente soportan únicamente 10 conexiones simultáneas, las mejoras incorporadas en la pila de recursos compartidos de Windows Server 2008, mejora también el rendimiento en Windows vista SP1.


·         IIS7 se incluyó en Windows Vista RTM con el objetivo de que los desarrolladores pudieran comenzar a probar sus productos en este nuevo entorno, sin embargo aun faltaba mucho desarrollo por realizar. Ahora ya está finalizado y aunque la gran mayoría de usuarios no utilicen IIS7, las mejoras en rendimiento y estabilidad hechas en Windows Server 2008, están también disponibles en Windows Vista SP1.


Hasta el próximo artículo.


 Actualización: La siguiente entrega la podeis encontrar en http://geeks.ms/blogs/vista-tecnica/archive/2008/02/23/windows-vista-sp1-ii-de-iii.aspx

PowerShell (II de V)

Comenzamos esta segunda entrega describiendo la base de la sintaxis en powershell. Lo primero que debemos conocer es que los comandos de PowerShell ahora se denominan cmdlets y comparten una sintaxis común.


 


Todos los cmdlets consisten de un verbo y un nombre, separados por un guión.


Esta estructura permite un aprendizaje más rápido y sobre todo relacionar fácilmente el verbo con lo que se quiere realizar, por ejemplo.


 


Algunos de los verbos admitidos en esta versión 1.0 de powershell son get, set, new, write, start, stop, remove, add, etc..Es relativamente sencillo suponer qué es lo que hace cada uno de los verbos. Si a continuación le agregamos el nombre, completamos el cmdlet, por ejemplo:


 



  • Get-help

  • Get-childitem

  • Get-service

  • Get-process

  • New-item

  • Set-acl

  • Set-alias

  • Set-date

 


Sin embargo muchos de estos cmdlets tienen su alias en versión UNIX y CMD.EXE para aquellos administradores que vengan desde estos entornos, por ejemplo:


 


Get-childitem nos sirve para listar los objetos dentro de una carpeta o disco y podemos utilizar el cmdlet nativo de Powershell o los ya conocidos ls y dir de UNIX y CMD.EXE respectivamente. Además, para no tener que escribir todo el cmdlet, también existe un alias reducido como gci en este caso.


 




Si no conocemos el nombre que debemos utilizar después de un verbo, PowerShell incluye una ayuda para autocompletar los cmdlets utilizando la tecla tabulación. Por ejemplo, si escribimos el verbo set- y queremos saber qué nombres están admitidos, solo vamos circulando por los nombres con TAB.


 



  • Set-acl -> TAB -> set-alias -> TAB -> set-authenticodeSignature -> TAB -> set-content -> TAB -> set-date -> TAB -> set-ExecutionPolicy ->  y así sucesivamente

 


Podemos también comenzar escribiendo las primeras letras del nombre y PowerShell completará los nombres que coincidan con estas primeras letras.


 


Windows PowerShell es una consola orientada a objetos, lo que quiere decir que todos los comandos de entrada y salida son en sí mismos objetos.  PowerShell se basa en el modelo de objetos de.Net.


 


.Net es una representación de objetos unificada que utilizan todos los equipos de desarrollo de Microsoft, por lo tanto desde PowerShell se pueden gestionar todos los componentes de Windows y de las aplicaciones basadas en .Net


 


Por ejemplo, si queremos conocer el día de la semana del 4 de enero de 1643 (nacimiento de Isaac Newton), solo tenemos que escribir lo siguiente:


 



  • (get-date “04/01/1643”).DayOfWeek

 


En este ejemplo, el cmdlet get-date devuelve el objeto .Net DateTime, que tiene una propiedad que calcula el día de la semana. Una aplicación más interesante para los administradores de sistemas es por ejemplo verificar si un archivo es más reciente que otro.


 



  • (get-childitem archivo1.txt).lastwritetime –gt (get-childitem archivo2.txt).lastwritetime

 


Si queremos conocer todos los detalles de cada cmdlet, Get-help nos muestra la ayuda completa. Su so es: get-help cmdlet, por ejemplo: get-help get-childitem.


 


La ayuda en PowerShell está muy cuidada y es muy extensa, de hecho podemos mostrar tres niveles de ayuda:


 



  • get-help get-childitem (Ayuda general y resumida)

  • get-help get-childitem –detailed (ayuda detallada)

  • get-help get-childitem –full (ayuda técnica completa)

 


Si la ayuda es extensa para visualizarla en pantalla, podemos exportar el contenido a un archivo de texto:


 



  • get-help get-childitem –full | out-file C:AyudaPowerShell.txt

 


Aunque si estáis acostumbrados a cmd.exe, podemos escribir lo siguiente para hacer lo mismo:


 



  • get-help dir –full > C:AyudaPowerShell.txt

 


 


Además, parte de la ayuda completa incluye numerosos ejemplos de aplicación de cada cmdlet.


 


Como habéis podido observar, en el anterior ejemplo hemos utilizado el símbolo | Una de las características más importantes de PowerShell es la capacidad de crear pipas (pipes), de tal forma que podemos pasar los resultados de un cmdlet hacia el siguiente. Esta funcionalidad ya la conocen muy bien los administradores que vienen del entorno UNIX ya que es una característica común desde hace mucho tiempo, y que sin embargo en Windows había sido una funcionalidad reducida a algunos comandos muy específicos, como por ejemplo > para exportar los resultados a un archivo de texto.


 


Cada cmdlet en un pipeline recibe un objeto del cmdlet previo, realiza una operación en él y después pasa el resultado al siguiente cmdlet en la pipa.


 



  • Get-childitem –recurse –filter *.exe | format-table name, lenght

 


En el ejemplo anterior, el cmdlet get-childitem recorre todas las carpetas por debajo de la ubicación actual en busca de archivos .exe y el resultado se pasa al cmdlet format-table para dar formato con el nombre y la longitud de los archivos encontrados.


 


Esta es una forma sencilla de hacer búsquedas y formatear la salida en pantalla. Otro ejemplo similar es el siguiente:


 



  • Get-childitem –recurse –path “C:windows” –filter *.dll | where {$_-name –match “system.*dll”}

 


Esta instrucción busca todos los archivos en la carpeta Windows que lleven la palabra system y con extensión dll.


 


Una característica destacable es la capacidad de ejecución en streaming de Powershell, es decir, no necesitamos esperar a que se procesen todos los resultados para verlos en pantalla, sino que a medida que se van encontrando valores coincidentes, se van presentando en pantalla.


 


En la mayoría de las consolas, el streaming se consigue ejecutando procesos separados para cada elemento en la pipa. PowerShell solo utiliza un proceso de ejecución y un único hilo. El streaming se logra particionando los cmdlets en tres cláusulas: inicio de proceso (begin-processing), objeto en proceso (process-object) y fin de proceso (end-processing).


 


Con esto llegamos al final de esta segunda entrega de PowerShell, seguiremos comentando más detalles de los cmdlets y su utilización por parte de los administradores de sistemas en el siguiente post.

Power Shell (I de V)

Powershell es la nueva consola de comandos de Microsoft diseñada tanto para administradores como desarrolladores. Powershell amplia las capacidades y características de cmd, pero además incorpora la posibilidad de escribir y ejecutar scripts de forma nativa y automatizar tareas fácilmente.


 


A lo largo de esta serie de artículos iremos viendo los beneficios que nos aporta PowerShell a los administradores y desarrolladores, además veremos ejemplos de cómo se pueden automatizar tareas administrativas con pocas líneas de comandos, que de otra forma hubiera sido mucho mas costoso realizar.


 


Lo primero que hay que indicar es que PowerShell no viene instalado por defecto en Windows Vista, ni siquiera aparece como componente del sistema. En realidad se instala como una actualización del sistema y está disponible para Windows XP SP2, Windows Server 2003, Windows Vista y Windows Server 2008.


 


Lo podéis descargar desde aquí: http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx, en todas sus versiones disponibles hasta el momento.


 



PowerShell 


 


A diferencia de la mayoría de los shells, que aceptan y devuelven texto, Windows PowerShell se ha creado sobre Common Language Runtime de .NET (CLR) y .NET Framework, y acepta y devuelve objetos .NET. Este cambio esencial del entorno proporciona herramientas y métodos completamente nuevos para la administración y configuración de Windows.


 


Ahora con PowerShell vamos a poder hacer cosas como examinar el registro del sistema, navegar por las clases de la instrumentación (WMI) y por supuesto configurar y administrar todo en entorno Windows.


 


Antes de entrar en detalles técnicos me gustaría contaros porqué Microsoft decide desarrollar este nuevo shell.


 


Desde siempre, los administradores de sistemas y clientes han criticado a Microsoft por no proporcionar en sus sistemas  operativos una consola de comandos con la que se pudiera gestionar el 100% de las características del entorno, que fuera sencilla, entendible y sobre todo versátil.


 


Desde los tiempos de Windows NT ya teníamos el intérprete de comandos cmd.exe, junto con command.com de MSDOS, Windows 95 y 98. Si a esto le añadimos las numerosas herramientas que existen para la administración de Windows como son las herramientas de soporte o kit de recursos para cada una de las versiones hasta llegar a Windows Server 2003, los administradores hemos tenido que aprender y familiarizarnos con múltiples entornos de gestión  que en la mayoría de los casos no habían sido diseñadas bajo unos objetivos comunes. Por ello, la sintaxis, funcionalidad y facilidad de uso han sido siempre elementos demasiado heterogéneos.


 


Otro factor que tradicionalmente han provocado las críticas a Microsoft es la automatización de tareas. Con Windows 2000 Server y Windows Server 2003, Microsoft intentó mejorar las capacidades de automatización añadiendo la capa de Scripting o Windows Script Host (WSH). Esta capa de automatización acepta lenguajes como JScript y VBScript, pero se le pueden agregar otros motores como Perl.


 


Entonces, ¿porqué nace Windows PowerShell?. Bien, Microsoft ha estado durante los últimos años estudiando en qué áreas podría ofrecer sustanciales mejoras a sus sistemas, y sin duda una de ellas es la línea de comandos de Windows. Si comparamos la manejabilidad de la línea de comandos de Windows con UNIX, enseguida nos damos cuenta de las limitaciones de la primera.


 


Esto ha sido así porque históricamente Microsoft ha puesto todo su esfuerzo en el desarrollo de la interfaz gráfica, orientada a usuarios estándar. Un usuario medio no se preocupa demasiado por la línea de comandos, sin embargo esta estrategia que comercialmente ha sido muy exitosa, ha dejado fuera del punto de mira a administradores y profesionales de IT que han exigido siempre una mejora en este ámbito.


 


No olvidemos que cada versión de Windows es más compleja que su antecesora e incluye más subsistemas. Para soportar esta complejidad, Microsoft ha desarrollado conjuntos de objetos estructurados, los cuales se integran completamente en el entorno gráfico, pero que son mucho más difíciles de integrar con los entornos de texto tradicionales. Los desarrolladores siempre han tenido a su favor el conjunto de APIs y los SDK que incorporan cada uno de los productos de Microsoft, para poder extender la funcionalidad de la aplicación y personalizarla según las necesidades de la empresa.


 


A medida que Windows Server se incorpora cada vez más a los centros de procesamiento de datos de los negocios, la interfaz gráfica y el hacer clic continuamente dificulta enormemente las labores de los administradores y profesionales.


 


Por todo ello, nace PowerShell, una consola que ofrece un entorno unificado, con comandos y sintaxis homogénea, que permite automatizar tareas con su propio lenguaje de scripting pero que además es compatible con los scripts que ya tenemos implementados en JScript o VBScript.


 


Pero si todo esto no es suficiente, PowerShell se ha diseñado pensando en los administradores y profesionales de mediana y gran empresa en donde conviven plataformas mixtas Windows / UNIX. La curva de aprendizaje es mínima, ya que se pueden seguir utilizando los comandos más habituales UNIX en PowerShell como ls, mkdir, rmdir, mount, ps, cat, etc.


 


Durante esta serie de artículos abordaremos algunas de las más destacadas características de  PowerShell y lo voy a dividir en 5 entregas, de las cuales esta introducción es la primera. Las dos entregas siguientes nos acercaremos a los cmdlets más interesantes para Administradores de Sistemas, mientras que las dos últimas entregas hablaré de scrpts en PowerShell para programar y automatizar tareas.


 


Bien, para terminar con esta breve introducción, os dejo un claro ejemplo de la potencia de PowerShell:


 


Si queremos visualizar los servicios de un equipo en la consola, antes de Powershell tendríamos que haber escrito un script similar a este:


 


strComputer = «.»


Set objWMIService = GetObject(«winmgmts:» _


& «{impersonationLevel=impersonate}!\» & strComputer & «rootcimv2»)


Set colProcessList = objWMIService.ExecQuery(«Select * from Win32_Process»)


For Each objProcess in colProcessList


Wscript.Echo «Process: » & objProcess.Name


Next


 


Ahora con PowerShell


 


Get-process


 


 


get-process

Despliegue masivo de Windows Vista con BDD 2007 (V de V)

Finalmente llegamos a la última entrega de esta serie. Antes de nada aquí tenéis todas las entregas anteriores:


·         “Despliegue masivo de Windows Vista con BDD 2007 (I de V)”


·          “Despliegue masivo de Windows Vista con BDD 2007 (II de V)”


·         “Despliegue masivo de Windows Vista con BDD 2007 (III de V)”


·         “Despliegue masivo de Windows Vista con BDD 2007 (IV de V)”


Recordemos que ya tenemos tanto el “build”, es decir la imagen de despliegue como el Deployment Point o punto de implantación desde donde se transferirán las imágenes de vista que estuvieran disponibles.


El último paso que realizamos en el artículo anterior fue la actualización del punto de implantación. Con esto creamos la estructura de carpetas y copiamos las imágenes .wim que previamente ya habíamos creado en el “build”.



 


Sin embargo aun quedan algunos pasos por realizar ya que en nuestro escenario, el despliegue lo estamos realizando en modo LTI, es decir sin SMS 2003 OSD. Por lo tanto debemos apoyarnos en un último servicio que también incorpora Windows AIK. Me refiero a Windows Deployment Services o WDS.


Ya comente en su momento qué es WDS, recordad que lo podéis encontrar en la carpeta WDS del paquete de instalación de WAIK. WDS nos va a permitir iniciar los equipos utilizando PXE y ejecutar el script de arranque del proceso de instalación (litetouch.vbs) para que se descargue WindowsPE y según la configuración que hayamos realizado, continúe el proceso en modo desatendido o solicitando la intervención del usuario.


La ejecución de los asistentes de WindowsPE en modo desatendido se logra con los parámetros y propiedades que configuramos en los archivos bootstrap.ini y customsettings.ini. Ambos los podemos editar desde las propiedades de la imagen del punto de implantación. Algunas propiedades importantes como DeployRoot, UserDomain, UserID, UserPassword o KeboardLocale evitan que se presenten en pantalla los asistentes mientras se realiza el proceso de instalación y configuración de WindowsPE. Más adelante entrará en acción unattend.xml durante las fases de instalación de la imagen de Windows Vista y su personalización.


Por ejemplo, para realizar un despliegue totalmente desatendido, deberemos editar el archivo customsettings.ini de forma similar a lo siguiente:






[Settings]


Priority=Default


Properties=MyCustomProperty


 


[Default]


OSInstall=Y


ScanStateArgs=/v:5 /o /c


LoadStateArgs=/v:5 /c /lac /lae


 


SkipAppsOnUpgrade=Yes


 


SkipCapture=YES


ComputerBackupLocation=\<NOMBRE_SERVIDOR>Backup$


BackupFile=MyCustomImage.wim


 


SkipAdminPassword=YES


SkipProductKey=YES


SkipDeploymentType=Yes


DeploymentType=NEWCOMPUTER


 


SkipDomainMembership=Yes


JoinDomain=Americas


DomainAdmin=Administrator


DomainAdminDomain=INFORMATICA64


DomainAdminPassword=P@ssw0rd


 


SkipUserData=Yes


UserDataLocation=\<NOMBRE_SERVIDOR>USMTdata


 


SkipBuild=Yes


BuildiD=VIS01


 


SkipComputerName=Yes


ComputerName=%SerialNumber%


 


SkipPackageDisplay=Yes


LanguagePacks1={3af4e3ce-8122-41a2-9cf9-892145521660}


LanguagePacks2={84fc70d4-db4b-40dc-a660-d546a50bf226}


 


SkipLocaleSelection=Yes


UILanguage=en-US


UserLocale=en-CA


KeyboardLocale=0409:00000409


 


SkipTimeZone=Yes


TimeZoneName=China Standard Time


 


SkipApplications=Yes


Applications1={a26c6358-8db9-4615-90ff-d4511dc2feff}


Applications2={7e9d10a0-42ef-4a0a-9ee2-90eb2f4e4b98}


 


SkipBitLocker=Yes


SkipSummary=Yes


Powerusers1=AmericasJoinRis


CaptureGroups=Yes


SLShare=\<NOMBRE_SERVIDOR>Logs


Home_page=http:\www.informatica64.com


 


Es importante conocer cada una de las propiedades, ya que de esta configuración depende que la instalación del sistema operativo sea totalmente automática sin intervención del usuario. Para ello, existe una extensa referencia de cada una de las propiedades en la documentación de BDD 2007 llamada Configuration Reference. Aquí podéis profundizar más acerca de cada uno de los valores configurables y el efecto que produce en el proceso de instalación. Algunos de estos valores se insertan en unattend.xml si estamos desplegando Windows Vista y unattend.txt o sysprep.inf para Windows XP



 


Cuando editamos bootstrap.ini en las propiedades del punto de implantación, en realidad estamos editando la copia que tiene el recurso compartido de implantación o Deployment Share. Por ello debemos actualizar los archivos que hayamos cambiado en el Deployment Point y sobre todo asegurarnos que la imagen de WindowsPE que utilizaremos para el arranque tenga la última versión que hemos creado de boostrap.ini.


Una forma sencilla de realizar esta comprobación es montando la imagen LiteTouchPE_x86.wim que tiene el punto de implantación utilizando la herramienta  imageX.


Bootstrap.ini debe contener al menos la información necesaria para conectarse al punto de implantación y las credenciales que se utilizarán. Este archivo forma parte de la imagen WindowsPE que se debe generar o actualizar en el punto de implantación, por ejemplo:



 


No olvidemos otorgar a la cuenta seleccionada, permisos de lectura al recurso del punto de implantación que en nuestro ejemplo es  Deploy$. Además debemos asegurarnos que usuarios no autorizados no puedan tener acceso a esto u otros puntos de información y despliegue como pueden ser USMT o Logs. En general debemos establecer los permisos adecuados para este recurso y todos aquellos recursos que se vayan a utilizar en el script ZTIConnect.wsf


Una vez hechos todos los cambios oportunos, llega la hora de importar la imagen de inicio del sistema a Windows Deployment Services. Aquellos equipos que no tengan instalado un cliente SMS 2003, es decir, escenarios de nuevos equipos o migraciones de hardware, iniciarán el proceso de despliegue utilizando WDS.


En realidad existen alternativas a WDS, por ejemplo la ejecución manual del script litetouch.vbs desde el propio cliente, sin embargo esto solo es posible si ya existe un sistema operativo instalado en el equipo de destino.


Para importar las imágenes hacemos clic con el botón derecho en el nodo Boot Images  y completamos el asistente.



 


Windows Deployment Services puede responder a las solicitudes de inicio de los equipos que soportan PXE, sin embargo, es probable que queramos especificar que el servidor solo responda si los equipos están identificados ( pre-staged). Esto significa que aunque iniciemos un equipo en modo PXE, no se ejecutará el proceso de instalación de Windows Vista si no se ha identificado el equipo previamente en el Directorio Activo.


Para configurar esta opción, debemos ver las propiedades del servidor WDS. En la etiqueta PXE Response settings seleccionamos Respond only to known client computer. Todos aquellos equipos que no estén ya dados de alta en el Directorio Activo, deberán crearse manualmente para que el servidor PXE responda adecuadamente.



 


Para realizar este procedimiento debemos crear una nueva cuenta de equipo en el Directorio Activo con la opción de equipo administrado habilitada y el GUID / UUID identificado. Este valor GUID / UUID se puede localizar cuando el equipo inicia en modo PXE.



 


Como es lógico, si vamos a realizar una implantación de Windows Vista en decenas o cientos de equipos que no forman parte del dominio o que ni siquiera tienen un sistema operativo instalado, es preferible habilitar WDS para que responda a cualquier solicitud y evitamos el tener que identificad uno a uno cada equipo.


Llegados a este punto, solo nos queda iniciar el o los equipos de destino de nuestra implantación de Windows Vista. Cada escenario de despliegue utiliza un método diferente (Punto de implantación, discos locales, DVD). Los asistentes de Windows Deployment solicitarán cualquier configuración que no se haya configurado explícitamente, ya sea en bootstrap.ini, customsettings.ini o unattend.xml.


Cuando iniciamos el equipo con PXE, WDS se encarga de ejecutar cscript litetouch.vbs e implantar WindowsPE como primer paso de despliegue.


A partir de aquí, solo queda observar el proceso y comprobar que al finalizar obtenemos la imagen instalada según la hemos preparado. Si alguno de los asistentes de Windows Deployment solicita información al usuario, significa que ese valor no lo hemos configurado, por lo tanto deberemos revisar los pasos de edición de los archivos de instalación desatendida e incluir la propiedad solicitada.


Cuando iniciéis el equipo de destino vais a obtener algo similar a esto:









 


 



 


Con esto finalizamos aquí esta serie dedicada a la implantación de Windows Vista utilizando las nuevas herramientas y formatos de imagen que nos proporciona Microsoft para entornos de empresas y organizaciones que busquen automatizar estos procesos.


El poder automatizar todas estas tareas de forma relativamente sencilla y desplegar imágenes desde un punto administrado de forma centralizada a múltiples equipos, permite reducir significativamente los costes de actualización y mantenimiento en la mediana y gran empresa.


Business Desktop Deployment 2007 tiene muchas más características que se pueden explotar y que permiten una flexibilidad total para cualquier organización. Opciones que incluyen la configuración de diferentes tipos de implantación según el sitio físico en donde esté ubicado el equipo cliente o tipo de hardware consultando a la instrumentación del sistema (WMI).


Otro aspecto importante a destacar es que BDD 2007 no solo nos va a servir para el despliegue de Windows Vista, sino también para Windows XP y Office 2007.


En definitiva, para todos aquellos administradores y responsables de tecnología a los que se les exige mantener, implementar y  actualizar los sistemas operativos, el conjunto de herramientas incorporadas en BDD 2007 facilita el cumplimiento de los retos y objetivos siempre presentes en cualquier proyecto de tecnología: hacerlo en el menor tiempo posible y manteniendo los costes controlados en todo momento.  Con BDD 2007 seremos capaces de desplegar un Sistema Operativo en cientos de clientes en cuestión de unas pocas horas.

Despliegue masivo de Windows Vista con BDD 2007 (IV de V)

Llega la hora de preparar en despliegue de la imagen que hemos estado preparando durante las últimas entregas de esta serie de artículos.


Pero, antes de iniciar las tareas de preparación, me gustaría explicar algunos conceptos y opciones de despliegue que BDD 2007 soporta.


Con BDD 2007 podemos realizar básicamente dos tipos de despliegue de sistema operativo: Light Touch (LTI) y Zero Touch (ZTI). Ambos tipos comparten un conjunto de scripts y archivos de configuración comunes.


·         Scripts


·         Archivos de configuración


·         Base de datos de Configuración


·         Variables de entorno


·         Archivos Log


Los scripts proporcionan un modo de automatizar el proceso de implantación y generan archivos log del proceso que han ejecutado para poder realizar un seguimiento o identificación de problemas durante alguna fase del proceso. Para que los scripts se ejecuten correctamente, éstos interpretan los archivos de configuración, los cuales están localizados en la carpeta Control del punto de implantación (Deployment Point) y se crean con los asistentes del Deployment Workbench.


La base de datos de configuración es una extensión lógica de los archivos de configuración. Permite centralizar y almacenar la configuración en una base de datos SQL Server. Durante el proceso de implantación, los scripts consultarán la base de datos según se necesite. Sólo se recomienda esta opción si podemos garantizar que los equipos cliente disponen de una conexión permanente y de alta velocidad al servidor SQL, si no es así, deberemos utilizar los archivos de configuración almacenados localmente en el equipo de despliegue.


La diferencia entre Light Touch (LTI) y Zero Touch (ZTI) consiste más bien en la infraestructura que hay detrás y en la cual nos basamos para realizar el despliegue. Mientras que LTI se realiza con herramientas gratuitas como son BDD 2007, WAIK y WDS, Zero Touch requiere, además de estas herramientas, SMS 2003 SP2 con OSD Feature Pack. La incorporación de SMS en el proceso de preparación y despliegue de sistemas operativos aporta un mayor grado de automatización, sobre todo cuando queremos incluir paquetes de software de terceros junto con una implantación muy personalizada.


En nuestro laboratorio seguiremos los procedimientos de Light Touch, que a pesar del nombre, también se pueden automatizar muchas de las fases y tareas de implantación para que sea un proceso completamente desatendido.


Tanto ZTI como LTI utilizan un archivo denominado bootstrap.ini para especificar propiedades que posteriormente se utilizarán en otro archivo de personalización llamado CustomSettings.ini. Bootstrap.ini  proporciona la información necesaria del punto de distribución, SMS OSD Feature Pack, Windows PE y opciones locales de teclado. En la siguiente tabla vemos algunas de las propiedades que se pueden utilizar en LTI y ZTI:












































Nombre de la propiedad


LTI


ZTI


DeployRoot


˜


 


SkipBDDWelcome


˜


 


UserDomain


˜


 


UserID


˜


 


UserPassword


˜


 


KeyboardLocale


˜


 


OSDInstallSilent


 


˜


OSDInstallPackage


 


˜


OSDInstallProgram


 


˜


 


Estos archivos se crean desde el Deployment Workbench cuando se crea el punto de implementación (Deployment Point). Después de que estén creados podemos hacer cualquier cambio manualmente en los archivos.


Pero esto no termina aquí. Todas las tareas de implantación se ejecutan siguiendo un guión que también podemos personalizar. A esto le llamamos el secuenciador de tareas. Las fases o tareas se definen en un archivo llamado TS.xml, en el cual se identifica la secuencia correcta de ejecución de todo el proceso de implantación.


Las fases incluidas en TS.xml son:


·         Fase de validación: realiza las verificaciones necesarias para garantizar que la instalación del sistema operativo puede proseguir.


·         Fase de captura de estado de usuario: lee la información de los archivos de configuración, bases de datos y equipo local para determinar cómo se debe ejecutar el proceso de instalación y a captura del perfil de usuario. También identifica el espacio necesario para guardar el perfil completo utilizando USMT, invocando a ScanState.exe.


·         Fase de preinstalación: En esta fase se confirma que toda la información necesaria se ha recogido en los escenarios de actualización y reinstalación de equipos. En los escenarios de nueva instalación y remplazo de equipos, es en esta fase donde se recoge toda la información necesaria para la instalación ya que la captura de estado no se ejecuta.


·         Fase de instalación: En esta fase se instala el sistema operativo en el equipo de destino


·         Fase de post instalación: Se actualiza sysprep.inf, sysprep.xml o unattend.txt con la información recogida en las fases anteriores.


·         Fase de restauración de estado de usuario: En esta fase de hace una llamada a LoadState.exe para restaurar el perfil de usuario que previamente se ha capturado.


Pues bien, en TS.xml se identifican todas estas fases, junto con los pasos necesarios en cada una de ellas y según el escenario de implantación. Además se identifican las tareas necesarias para despliegues con SMS OSD Feature Pack.


Si volvemos a nuestro laboratorio, podemos encontrar el secuenciador de tareas en las propiedades del “Build” o paquete de despliegue que tenemos ya creado. Si seleccionamos la etiqueta Task Sequence observaremos cada una de las fases que hemos comentado.


Lo realmente interesante de todo esto es el grado de personalización que BDD 2007 ofrece, ya que, además de las tareas ya creadas, podemos insertar en cualquiera de las fases, nuestros propios scripts y pasos que sean necesarios para hacer que el sistema operativo final esté  totalmente adaptado y personalizado para nuestra organización.


Por ejemplo, supongamos que queremos incluir una tarea que copie los archivos de instalación de una aplicación de línea de negocio al disco local y que además inicie el proceso de instalación. Supongamos además que todo esto ya lo tenemos creado en un par de archivos llamados copiaLOB.bat e InicarSetup.bat.


Lo único que tendríamos que hacer es determinar el punto de inserción de la nueva tarea, e invocar los archivos .bat en el orden adecuado. Un punto de inserción lógico para este ejemplo sería dentro de la fase de post instalación y probablemente justo antes del reinicio del equipo. Nos situamos en la tarea inmediatamente superior y seleccionamos en el secuenciador de tareas Add > Group. Posteriormente vamos a agregar dos tareas, por lo tanto Add > Task dos veces. Ahora solo completamos los datos necesarios de las tareas y el grupo:


·         Nombre del Grupo: Copia e instalación de LOB


·         Nombre de tarea 1: Copia de archivos, Command Line: C:copiaLOB.bat


·         Nombre de tarea 2: Inicio de instalación, Command Line: C:InicarSetup.bat



Edición de tareas con Task Sequencer 


Fijaros que debemos hacer referencia a la ubicación de los archivos .bat, los cuales deben estar previamente copiados y disponibles en la imagen .wim que acabamos de instalar. Para ello nada mejor que utilizar imageX para abrir, montar y copiar los .bat necesarios para esta tarea.


Todos los cambios se ven reflejados en el archivo TS.xml del build que estemos modificando, en nuestro caso VIS01, localizado en “C:DistributionControlVIS01TS.xml”.



TS.xml 


Una alternativa a los .bat es utilizar scripts en formato .wsf, tal y como los utiliza BDD 2007 para secuenciar sus tareas. Para ello haremos una llamada a “cscript.exe %SCRIPTROOT%NombreDeScript.wsf”.


Una vez que hemos hecho todos los cambios necesarios, personalización de fases y tareas, copia de archivos en la imagen .wim y hemos verificado que el paquete de despliegue está correctamente creado, llega el momento de crear el punto de implantación o Deployment Point.


Para ello nos situamos en el nodo que lleva este nombre y con el botón derecho hacemos clic en New. Veremos el asistente de creación de punto de implantación, y observaremos cuatro opciones disponibles que os comento a continuación:


 Asistente para crear puntos de implantación 


·         Lab or single-server deployment (LAB). Opción predeterminada que crea un punto de distribución (recurso compartido como distribution$). Con esta opción utilizamos el punto de distribución local como punto de implantación (Deployment Point).


·         Separate deployment share (Network). Esta opción crea un Nuevo punto de implantación (Deployment Point) como nuevo recurso compartido de red. Recomendado en escenarios en donde se utilizarán servidores de archivos en red desde los cuales se centralizará la implantación


·         Removable media (Media). Esta opción crea un recurso compartido en donde se crearán imágenes para realizar una implantación basada en CD, DVD, Discos Duros externos o dispositivos  USB. Ideal para escenarios en donde haya equipos desconectados o con limitaciones en la conexión que puedan afectar el proceso de instalación remota.


·         SMS 2003 Operating System Deployment (OSD) Feature Pack (OSD). Si seleccionamos esta opción crearemos un recurso compartido que posteriormente se utilizará en la creación de imágenes para SMS 2003 OSD Feature Pack. Específico para escenarios de implantación ZTI.


Según la opción que hayamos seleccionado, tendremos que dar respuesta a algunas preguntas que nos hará el asistente. Estas preguntas determinan el comportamiento inicial del proceso de instalación del Sistema Operativo y modifican el archivo CustomSettings.ini y Bootstrap.ini



 


En nuestro escenario, utilizaremos la segunda opción, es decir, Separate Deployment Share para que así podamos observar el recurso compartido que se crea y los archivos de configuración que hemos comentado anteriormente. Por lo tanto ejecutamos el asistente y vamos contestando cada una de las preguntas, con los siguientes valores:


·         Deployment Point name: NETWORK


·         Allow users to select additional applications on Upgrade: NO


·         Ask user to set the local Administrator Password: NO


·         Ask user for a product key: NO


·         Server name, Share Name, Path for share: dejamos los valores por defecto


·         Specify user data defaults: Do not save data and settings


Una vez que hemos creado el Deployment Point podemos acceder a sus propiedades haciendo doble clic en el contenedor correspondiente. Desde aquí podemos editar y configurar con un mayor nivel de detalle todas las opciones del punto de implantación.


Propiedades del Punto de Implantación



Otro aspecto a tener en cuenta es que el recurso compartido no se crea realmente hasta que no llevamos a cabo una actualización de archivos, es decir, el punto de implantación no es funcional hasta que todos los archivos necesarios no se hayan copiado al recurso compartido. Para ejecutar esta tarea le haremos clic con el botón derecho al contenedor NETWORK que acabamos de crear y seleccionamos Update.



Actualización de archivos en el punto de implantación 


Bien, hemos llegado al final de este artículo, en la última entrega veremos cómo terminamos de configurar el punto de implantación y ejecutamos la instalación del sistema operativo.


Hasta entonces, saludos a todos.

Despliegue masivo de Windows Vista con BDD 2007 (III de V)

Para preparar el laboratorio podéis leer los  artículos anteriores “Despliegue masivo de Windows Vista con BDD 2007 (I de V)”  y  “Despliegue masivo de Windows Vista con BDD 2007 (II de V)”


En esta tercera entrega de esta serie destinada al despliegue de Windows Vista abordaremos la personalización del «Build» o paquete de despliegue que dejamos creado en el artículo anterior.


Recordemos que el “build” será el producto final que utilizaremos para realizar el despliegue, por lo tanto debe  estar lo más ajustado a las necesidades de la organización como podamos. Desde configuraciones de escritorio, Internet Explorer, Red, Firewall, hasta la instalación de aplicaciones de línea de negocios (LOB), actualizaciones, controladores, etc.


Por lo tanto, estas tareas de personalización las haremos con dos herramientas fundamentalmente: Windows SIM (Windows System Image Manager) e ImageX. Ambas herramientas son componentes de Windows AIK.


Si abrimos las propiedades del “Build” que ya tenemos creado, en la etiqueta settings, observaremos que podemos, desde aquí comenzar a modificar algunos parámetros como el nombre de la organización, contraseña de la cuenta Administrador (creada siempre en Windows Vista pero deshabilitada por defecto), página de inicio de Internet Explorer  y el número de licencia (CD Key) de la edición de Windows Vista que hemos adquirido.



Propiedades del paquete de despliegue 


En realidad todos estos parámetros, junto con muchos otros, forman parte del un fichero de instalación desatendida que se llama unattend.xml, el cual sustituye a los diferentes formatos que debíamos de gestionar en versiones anteriores cuando diseñábamos despliegues de Windows XP con RIS (sysprep.inf y unattend.txt). Con el botón “Edit Unattend.xml” abrimos la herramienta Windows SIM y podemos editar todos los detalles de respuestas que se pasarán en cada una de las tareas durante el proceso de instalación de la imagen del Sistema Operativo.


Para aquellos acostumbrados a desarrollar aplicaciones con Visual Studio, verán que el entorno es bastante familiar, ya que cada uno de los componentes o paquetes que forman parte del archivo de respuesta unattend.xml, son en realidad objetos con propiedades que podemos editar. Básicamente el entorno de trabajo se divide en cinco áreas:


1.       Distribution Share: Panel de exploración del recurso compartido de distribución, con los elementos y componentes que se han incluido en pasos anteriores como paquetes (actualizaciones de sistema) y controladores “out-of-box”


2.       Imagen Windows: Panel en donde podemos visualizar los paquetes que ya están actualmente incluidos en la imagen WIM, como paquetes de lenguaje, funcionalidades, características y el núcleo del sistema. Estos paquetes se pueden agregar al archivo de respuesta para personalizar la instalación y realizarla sin intervención del usuario


3.       Archivo de respuesta (Answer File): En esta sección veremos los paquetes que ya están incluidos en unattend.xml. Podremos editar sus propiedades, para realizar finalmente el despliegue desatendido que queremos lograr


4.       Propiedades: Cada vez que seleccionemos un paquete del archivo de respuesta o de la imagen de Windows, veremos sus propiedades y las podremos modificar para ajustarlas a los requisitos de la organización.


5.       Mensajes: Al utilizar las herramientas del menú Tools, obtendremos las respuestas de la acción realizada en este panel de mensajes.


Por ejemplo, supongamos que queremos configurar las particiones que tendrá el disco de los equipos en donde instalaremos Windows Vista. Pues bien, para ello debemos agregar al archivo de respuesta unattend.xml el componente necesario y configurar las propiedades. Uno de los aspectos más interesantes de Windows SIM es su nivel de detalle en cada una de las tareas. Para realizar esta configuración seleccionaríamos de la lista de componentes en el panel de imagen Windows, el objeto:


·         x86_Microsoft-Windows-Setup_6.0.6000.16386_neutralDiskConfiguration


Con el botón derecho lo agregamos al archivo de respuesta.



Paquetes en Unattend.xml 


Una vez integrado, podemos crear nuevos discos y nuevas particiones para cada disco. Siempre con el botón derecho, pero esta vez directamente en el archivo de respuesta, seleccionamos:


·         Disk Configuration > Insert new disk.


·         Disk / CreatePartitions > Insert new CreatePartitions


·         Disk / ModifyPartitions > Insert new ModifyPartitions


Cuando ya tenemos el disco creado y las particiones que necesitamos, debemos configurar las propiedades de cada disco y partición, por ejemplo:


·         Disk:  DiskID = 0, WillWipeDisk = true


·         DiskCreatePartitionsCreatePartition: Extend – false, Order = 1, Size = 25000, Type = Primary


·         DiskModifyPartitionsModifyPartition:  Active = true, Extend = false, Format = NTFS, Label = WindowsSystem, Letter = C, Order = 1, PartitionID = 1


Ahora debemos asegurarnos que el sistema se instalará en la partición que se ha creado para tal fin. Para ello abrimos las propiedades del objeto ImageInstallOSImageInstallTo. Este objeto se agrega automáticamente cuando se crea el archivo de respuesta, pero debemos comprobar que DiskID y PartitionID tengan los valores correctos. En nuestro ejemplo DiskID debe tener un valor 0 (Disco 0) y PartitionID un valor 1 (Partición 1).


Otros aspectos que se pueden configurar automáticamente son:


·         x86_Microsoft-Windows-Setup_6.0.6000.16386_neutralUserData


o   Aceptación de EULA


o   Nombre completo


o   Organización


·         x86_Microsoft-Windows-Setup_6.0.6000.16386_neutralUserDataProductKey


o   Licencia de producto (CD Key)


·         x86_Microsoft-Windows-Setup_6.0.6000.16386_neutralDisplay


o   Profundidad de colores


o   Resolución horizontal


o   Resolución vertical


o   Refrescamiento


·         x86_Microsoft-Windows-UnattededJoin_6.0.6000.16386_neutral


o   Dominio o grupo de trabajo al que unir el equipo


o   OU para el equipo


o   Contraseña de equipo


o   Credenciales de cuenta con permisos para agregar equipos al dominio


·         x86_Microsoft-Windows-TCPIP_6.0.6000.16386_neutral


o   Configuración de interfaces de red


o   Configuración IPv4 e IPv6


o   Puertas de enlace


·         x86_Microsoft-Windows-Sidebar_6.0.6000.16386_neutral


o   Gadgets presentados y configuración de Sidebar


Como podéis observar, son muchos los componentes que se pueden configurar de forma desatendida. Por lo tanto, si queréis profundizar en la arquitectura y componentes de Windows SIM, podéis visitar http://technet2.microsoft.com/WindowsVista/en/library/f3b1573b-4915-4532-933a-57ee2bcddf921033.mspx?mfr=true


Una vez finalizada la tarea de personalización de unattend.xml, el siguiente paso es guardar toda la configuración (File > Save Answer File). Por defecto se guarda en C:DistributionControl<Nombre del Build>unattend.xml. Si lo editamos con el Bloc de notas, comprobamos que efectivamente, toda la configuración que hemos ido agregando con Windows SIM está guardada en la estructura XML.


Otra herramienta que podemos utilizar para capturar y modificar imágenes WIM es imageX. El propósito de imageX es completamente diferente del de Windows SIM. Mientras que Windows SIM nos permite editar imágenes WIM y crear, a partir de los componentes incluidos, un archivo de instalación desatendida, imageX la vamos a utilizar en pasos inmediatamente anteriores o posteriores a la creación de unattend.xml.


Utilizaremos imageX para capturar una imagen a partir de un equipo de referencia. En nuestro caso, hemos iniciamos esta serie de artículos con la imagen en DVD de Windows Vista, por lo tanto no hemos tenido la necesidad de capturar una imagen previa. Sin embargo, si podemos tener la necesidad de que, una vez creado todo el entorno de despliegue, queramos modificar la imagen final WIM. Por ejemplo, actualizar unas librerías de unos controladores, o agregar una serie de archivos que utilizarán nuestros usuarios o aplicaciones en la organización.


Para ello, no es necesario volver a repetir todos los pasos y crear nuevas imágenes cada vez que realizamos cambios. Basta con montar la imagen actual e incorporar o actualizar los archivos necesarios. Fijaros que el montaje se realiza a partir de una carpeta previamente creada, y podremos navegar por toda la estructura de carpetas de la imagen .wim como si de un árbol de carpetas locales se tratara.


La herramienta la podéis encontrar en C:Program FilesWindows AIKToolsx86, es realmente sencilla de utilizar. Los modificadores que admite son los siguientes:


·         Append – Agrega un nuevo volumen de imagen a un fichero .wim existente


·         Apply – Aplica un volumen de imagen a la unidad especificada


·         Capture – Captura un volumen de imagen en un nuevo fichero .wim


·         Delete – Elimina una imagen de un fichero .wim con múltiples imágenes


·         Dir – Muestra una lista de archivos y carpetas en un volumen de imagen


·         Export – Transfiere una imagen de un fichero .wim a otro fichero .wim


·         Info – muestra las descripciones XML del fichero .wim


·         Split – Separa un fichero .wim existente en múltiples partes wim de solo lectura


·         Mount – Monta una imagen con acceso de solo lectura en la carpeta especificada


·         MountRW – Monta una imagen con acceso de lectura y escritura en la carpeta especificada


·         Unmount – Desmonta la imagen montada en la carpeta especificada


·         Compress – Establece el nivel de compresión a ninguno, rápido o máximo


·         Commit – Aplica los cambios realizados a una imagen .wim montada


Aquí van algunos ejemplos del uso que podemos darle a imageX


·         Si queremos crear una imagen a partir de un equipo de referencia debemos ejecutar el comando


o   imageX /capture /compress maximun C:  E:ImagenesmiWindowsVista.wim “Imagen de mi Windows Vista”


·         Si queremos aplicar esta imagen a un disco nuevo ejecutaremos


o   imageX /apply E:ImagenesmiWindowsVista.wim 1 D:


·         Opcionalmente se puede crear un fichero de configuración en donde se incluirán las exclusiones que se tendrán en cuenta durante el proceso de captura de la imagen. Dicho fichero debe tener extensión .ini y puede ser algo como esto:



Configuración de imageX /capture 


En nuestro laboratorio, vamos a ver cómo podemos montar y modificar la imagen a partir de la cual estamos realizando todo el proceso de despliegue. Recordemos que la imagen .wim que estamos utilizando proviene del DVD de Windows Vista, por lo tanto si queremos agregar algún archivo o carpeta a dicha imagen, debemos montarla en modo lectura y escritura, hacer los cambios necesarios y posteriormente aplicar los cambios.


La imagen está en C:DistributionOperating SystemsWindows Vistasourcesinstall.wim


Para montarla vamos a crear una carpeta que será nuestro punto de montaje, por ejemplo C:ImagenVista. Para montar la imagen debemos saber qué imagen montar, recordemos que en un único fichero .wim podemos almacenar múltiples imágenes. En nuestro laboratorio tenemos en install.wim todas las ediciones de Windows Vista, por lo que si queremos saber en qué orden están guardadas, podemos hacerlo con:


·         imagex /info «C:distributionoperating systemswindows vistasourcesinstall.wim»


Observaremos que la información proporcionada está en formato XML. Debemos localizar la etiqueta <IMAGE_INDEX> Y <NAME> para saber el índice de la imagen que buscamos.



imageX /info 


Según nuestro fichero .wim, la edición Ultimate está en la posición 4, por lo tanto montaremos esta imagen:


·         imagex /mountRW «C:distributionoperating systemsWindows Vistasourcesinstall.wim» 4 C:ImagenVista



imageX /MountRW 


Ahora podemos ver el contenido de la imagen en C:ImagenVista y navegar por la estructura de directorios. Podremos crear carpetas, agregar ficheros o modificar contenido. Por ejemplo, si queremos agregar o actualizar los controladores disponibles en nuestra imagen para la posterior instalación de dispositivos, entonces basta con agregarlos a WindowsSystem32DriverStore.


Una vez realizados los cambios debemos aplicarlos con la siguiente instrucción:


·         imageX /unmount /commit C:ImagenVista



imageX /unmount /commit 


Bien, hemos visto cómo podemos crear, editar y aplicar imágenes .wim con las herramientas Windows SIM e ImageX. En la siguiente entrega de esta serie comenzaremos las tareas de preparación del despliegue y las pruebas con un cliente que sin tener un Sistema Operativo instalado, deberemos iniciar ya sea con un CD de arranque de Windows PE o mediante PXE.

Despliegue masivo de Windows Vista con BDD 2007 (II de V)

Para preparar el laboratorio podéis leer el artículo anterior “Despliegue masivo de Windows Vista con BDD 2007 (I de V)”


Una vez instalados todos los componentes y servicios necesarios ya estamos listos para comenzar la preparación de imágenes de Windows Vista y su posterior despliegue en los dos equipos que tenemos (un Windows XP que actualizaremos y un equipo sin OS).


En este laboratorio vamos a utilizar un CD de Windows Vista como imagen de referencia, pero también se puede utilizar un equipo previamente instalado como equipo de referencia.


Lo primero que debemos hacer es iniciar “Deployment Workbench”. Esta aplicación nos va a permitir preparar todo lo necesario para el despliegue. Como observaréis se divide en cuatro nodos: “Information Center, Distribution Share, Builds y Deploy”.


·         El “Information Center” es un centro de documentación y enlaces a recursos Web que podemos utilizar para revisar los procedimientos y tareas de todo el proyecto de despliegue.


Microsoft divide el proyecto en varias claramente identificadas. Estas fases incluyen desde una primera comprobación de compatibilidad de nuestra infraestructura con Windows Vista (hardware y software), hasta la preparación de imágenes, configuración de la instalación de aplicaciones, migración de perfiles de usuario y el propio despliegue en los equipos de destino.


Es una guía muy completa que esta a vuestra disposición y que haciendo clic en cada uno de los íconos podemos acceder a los documentos de procedimientos de cada una de las fases.


 Fases del proyecto de despliegue con BDD 2007


·         El segundo nodo es el recurso compartido de distribución. Es aquí donde tendremos de importar las imágenes WIM de referencia y prepararemos las aplicaciones, actualizaciones de sistema y conjunto de controladores de dispositivos necesarios para nuestros equipos de destino.


·         En el nodo “Builds” veremos nuestras  “construcciones” de imágenes ya preparadas, es decir, una vez copiado y configurado todo el software necesario que se incluirá en Windows Vista durante el proceso de instalación y pasos post-instalación. Para poder crear un “Build” debemos tener al menos un Sistema Operativo configurado en el nodo de distribución.


·         Por último tenemos el nodo “Deploy” en donde crearemos los puntos de despliegue e identificaremos los equipos de destino, ya sea por nombre de máquina, dirección MAC, rol, ubicación y marca y modelo. Todo esto con la ayuda de una base de datos que debemos crear y configurar. Con respecto a los puntos de despliegue, BDD 2007 admite la creación de 4 tipos de despliegue.


a.      Mediante un recurso compartido en el mismo equipo


b.      Mediante un recurso compartido en otro equipo en la red,  por ejemplo un servidor de archivos,


c.       Mediante un medio extraíble, por ejemplo un DVD


d.      Mediante SMS 2003 con OSD


Bien pues una vez conocido esto, ahora llega el momento de importa la imagen WIM desde nuestro DVD de Windows Vista hacia el Distribution Share. Para ello, agregamos un nuevo OS con el asistente. En este laboratorio seleccionamos la primera opción ya que estamos trabajando con el DVD. No es necesario seleccionar la imagen .wim, solo la raíz del DVD, BDD detectará todas las imágenes que contiene el fichero .wim


Copia de archivos de instalación de Windows Vista


Una vez copiados todos los archivos de instalación, tendremos todas las ediciones de Windows Vista disponibles para ver sus propiedades y configurar la que vayamos a instalar en los equipos de destino


El siguiente paso es agregar a nuestra imagen las aplicaciones que se instalarán junto con el sistema operativo. Después veremos que gracias a un secuenciador de tareas podremos configurar el momento en que queremos que se produzca la instalación de las aplicaciones que aquí agregamos.


En este paso podemos agregar desde una pequeña utilidad que nuestros clientes requieren, hasta un sistema completo como Office 2007. Tenemos dos opciones en el asistente: aplicaciones que contienen archivos de origen, es decir, instaladores, archivos de configuración, archivos .cab, ficheros de texto, documentos, etc. Y como segunda opción podemos agregar aplicaciones que no tienen ficheros de origen o que están alojadas en un servidor de archivos.


Asistente para agregar aplicaciones


En la siguiente pantalla del asistente tenemos que indicar el nombre de la aplicación y la plataforma en que puede ejecutarse (x86, x64, IA64 o todas)


Por último seleccionamos la carpeta en donde residen los archivos de instalación de la aplicación y posteriormente los detalles de la instalación, es decir, los parámetros que se le van a pasar al programa de instalación para hacer un proceso automático y desatendido (estos datos varían según la aplicación). Si es un instalador basado en Windows Installer, algunos de los parámetros que podemos utilizar son los siguientes:


·         /q – quiet


·          /n Sin UI


·          /norestart – Sin reinicio


·         /passive – modo desatendido solo con barra de progreso


·         /log – crea un registro de instalación (se debe especificar la ubicación)


De todas formas, si tenéis cualquier duda, estos valores los podéis consultar ejecutando en una consola de comandos el instalador, por ejemplo “miaplicacion.msi /?”


Una vez que tenemos todas nuestras aplicaciones agregadas al recurso de distribución, a continuación haremos lo mismo con las actualizaciones que sean necesarias. Para ello debemos seleccionar con el asistente para nuevo paquete, la carpeta en donde se encuentran los ficheros .cab que contienen la actualización.


Por último, si necesitamos agregar controladores que se instalarán junto con el sistema operativo, lo podemos hacer con el asistente para nuevo controlador. En esta ocasión se buscarán los ficheros .inf  en la carpeta que indiquemos.


Bien, una vez que hemos terminado de agregar componentes a nuestra imagen ya podemos crear el “Build”. El Build se utiliza internamente durante el proceso de despliegue, realmente lo que se hace es unificar todo el contenido que hemos ido agregando en los pasos anteriores.


Necesitaremos identificar el “Build” con un número único, especificar un nombre y agregar algún comentario en el asistente de creación.



Posteriormente seleccionamos la edición de Vista que vamos a desplegar, en este caso seleccionaremos Vista Ultimate.


El asistente nos seguirá pidiendo datos como la clave de producto, nombre de la organización, página de inicio de Internet Explorer y la contraseña de la cuenta Administrador.


Selección de la imágen de Windows Vista


Todos estos datos van a formar parte del archivo de instalación desatendida, el cual podremos configurar y ampliar en un paso posterior utilizando la herramienta Windows SIM (Windows System Image Manager)


Hemos llegado al final de esta segunda parte. En la tercera parte abordaremos la personalización del “Build” que acabamos de crear. Podremos agregar componentes de Windows Vista a la instalación, configurar cada unos de los pasos y utilizar el secuenciador de tareas para incluir nuestros propios scripts de configuración y personalización del entorno.


Hasta entonces, saludos a todos.