Checho's Blog

Talking about Windows Internals, Deployment and Troubleshooting

Artículos recientes

News and Awards

Follow me on Twitter and LinkedIn

@secalderonr

View Sergio Calderon's profile on LinkedIn

Recomendados

Tags

Community

Email Notifications

Archives

November 2011 - Artículos

La aplicación “DLTCAD 2010” que no corría en Windows 7, Process Monitor y su solución.

LogoBlogWithSlogan

Hola a todos,

Realmente me da alegría volver a escribir por aquí después de algunos días, especialmente cuando tengo algo que me haya ayudado a mi aprendizaje y que quiero compartir.

En este caso, como en muchas ocasiones, se trata de un problema reportado con una aplicación llamada DLTCAD 2010 desde los estupendos Foros de Microsoft Answers en Español, me tomé el trabajo entonces de descargar un trial de la aplicación en cuestión y probar yo mismo, afortunádamente, también me dio un error y pude solucionarlo.

A continuación, como siempre divido en: El problema, La causa y su Solución.

El problema

Cuando se instala la aplicación en Windows 7, después de tratar de ejecutarla por primera vez, estaba recibiendo un Crash de la aplicación, es decir, que dejaba de responder sin ni siquiera haber iniciado:

Capture2

dlt2010D.exe dejó de funcionar

Al intentar cerrar la aplicación, inmediátamente recibía un mensaje de error bastante extraño:

Capture

Estaba ocurriendo una Excepción y, según el mensaje, no se podía encontrar el archivo Config.tmp en la ruta de instalación: “C:\Program Files (x86)\DLTCAD2010 DEMO\

Al aceptar el mensaje (OK), la aplicación no terminaba de iniciar. Sin importar cuántas veces la tratar de ejecutar, siempre era el mismo procedimiento, crash y posterior mensaje de error para finalmente cerrar el proceso y no abrir nada.

La causa

Lo primero que intenté hacer fue buscar el archivo Config.tmp pero por supuesto, no apareció por ningún lado, a juzgar por su extensión y nombre además, parecer ser algún tipo de archivo temporal que se ejecuta antes de iniciar la aplicación y que tal vez, pueda contener la configuración o los parámetros iniciales necesarios para que la aplicación arranque correctamente.

*Nota: Claro está, sólo estoy suponiendo porque la verdadera respuesta, la tiene sólo el fabricante implicado en el desarrollo.

En la compatibilidad de aplicaciones con Windows 7, suele ser práctico como primera instancia, intentar con dos alternativas, pestaña de compatibilidad que hará una “Mentira sobre la versión” haciéndole creer a la aplicación que está en una versión anterior de Windows o bien Ejecutarla como administrador elevando los permisos por el cambio en materia de seguridad que sufrió Windows desde XP a Windows 7 ya que todos los usuarios en Vista y 7 trabajan predeterminádamente como usuarios estándar.

Sin embargo, aplicando el modo de compatibilidad con Windows XP Service Pack 3 o inferior, de una vez el ejecutable pasa a pedir elevación de privilegios para que se cambie el token de acceso y sí se esté ejecutando realmente como un administrador (Tal cual se hacía en Windows XP).

Esto fue lo que hice con el ejecutable, fui a las propiedades (clic derecho, propiedades), pestaña de Compatibilidad y seleccioné Ejecutar este programa en modo de compatibilidad para Windows XP (Service Pack 3):

image

A continuación, ejecuté el programa, elevé los privilegios y de sorpresa, la aplicación estaba corriendo perfectamente:

image

Aquí había una gran incógnita, realmente la aplicación sí era compatible con Windows 7, pero pudo haberla hecho funcionar o la mentira sobre versión o la elevación de privilegios.

En un escenario emergente, ésta solución podría bastar, pero no en todas las empresas están dispuestas a dejar que se eleven permisos aunque sea para un proceso porque entonces tendrían que garantizar una cuenta que lo haga, además de que si la aplicación originalmente no pide elevación de privilegios es porque parece estar hecha con el fin de funcionar bajo un token estándar.

Cambié nuevamente el modo de compatibilidad a como estaba presentando el problema, y llamé a la mejor herramienta que me podía ayudar en ese momento, me refiero a Process Monitor de Sysinternals.

El proceso es el mismo de siempre, ejecutarlo, limpiar el primer log que genera, ponerlo a correr nuevamente y ejeacutar la aplicación hasta recibir el mensaje de error.

El siguiente paso es buscar qué puede darnos Process Monitor, de nuevo, como siempre, la recomendación es hacerlo de abajo hacia arriba y utilizando primero palabras que estén relacionadas con el problema, para este caso por supuesto, la primera sería: Config.tmp

Para activar el filtro de búsqueda, basta con ir al menú Edit y seleccionar Find, ejecutarlo desde la barra de comandos de Procmon o bien presionar CTRL + F

image

Para mi fortuna, bastó con los primeros y únicos resultados para encontrar tal vez la clave del problema:

Capture3

Si vamos más a fondo, Windows está utilizando la función CreateFile para tratar de crear el archivo Config.tmp en la ruta: C:\Program Files (x86)\DLTCAD2010 DEMO\, pero como resultado está obteniendo un ACCESS DENIED; esto significa que la ruta existe, que se intenta hacer la operación pero que no se consiguen los permisos necesarios sobre la ubicación en este caso para escribir y que el archivo quede.

Lo interesante está en que en Windows XP, la aplicación funciona perfectamente, y si hago lo mismo con Process Monitor, veré que el trabajo con el archivo Config.tmp se comporta diferente:

CaptureXP1

Como ven, es exactamente la misma operación, pero esta vez con un resultado de SUCCESS, lo que difiere de que tuvo los permisos necesarios para escribir.

Esto es apenas lógico y es donde está la raíz del problema, los permisos NTFS cambian completamente junto con todo el esquema de seguridad como había comentado antes, la aplicación en Windows XP, tiene todos los privilegios para escribir sobre cualquier ruta porque la cuenta predeterminada es de Administrador. En Windows 7 por otro lado, aunque la cuenta esté dentro del grupo de administradores en modo de aprobación, desde que esté el Control de Cuentas de Usuario (UAC) activo, todo lo que se corra se hará bajo el mismo token que el Explorer.exe (Proceso padre), es decir, como si se estuviera corriendo sobre un usuario limitado.

Al yo elevar los permisos en la ejecución dentro de Windows 7, le está diciendo al proceso que cambie de token de usuario estándar a usuario administrador, por lo que los permisos pasarán hacer idénticos a como si se estuviera ejecutando en Windows XP, por eso sigue sin problemas.

La solución

Como el problema estaba en los permisos, es decir, acceso denegado para escribir en la carpeta DLTCAD2010 DEMO, tenía que revisar cómo estaban establecidos de forma predeterminada para el usuario actual, para esto, basta con ir al directorio implicado, hacer clic derecho, Propiedades, ir a la pestaña de Seguridad y hacer clic en el botón Editar:

image

En la edición de Seguridad sobre los permisos NTFS en Vista y en 7, se puede ver cada usuario implicado en los directorios o unidades que hayamos seleccionado, así como cada permiso que tienen sobre los objetos.

En este caso, me situé sobre mi usuario WinGuy del grupo Users (Usuarios) y esto fue lo que me mostró Windows:

Capture4

Como ven, el permiso de Escritura (Write) no estaba seleccionado para Permitir (Allow), lo que quiere decir que mis usuarios estándar, no pueden crear nada en este directorio (DLTCAD2010 DEMO).

Hay una diferencia notable con respecto a los Administradores de la máquina:

image

Todos los permisos están habilitados, incluyendo los de escribir, ¡Aquí la clave de todo!
Esto resolvía el por qué elevando los privilegios que pasa de estar entre los Usuarios a los Administradores, la aplicación estaba funcionando bien.

Para finalizar entonces, sólo tuve que asignar el permiso de escritura sobre mi usuario y aplicar todos los cambios con sólo seleccionar el grupo de Users (Usuarios) y después habilitar Write (Escritura):

Capture5

Por último y para confirmar la teoría, ejecuté la aplicación sin elevar los privilegios (Haciendo doble clic sobre el acceso directo) y .. ¡Aplicación funcionando!

image

Como hemos visto, no todos los problemas son culpa de Windows =)
Espero pueda ser de utilidad, sea por como en mi caso, aprender algo nuevo o bien porque tengan un problema similar con esta aplicación como es el caso que se planteó en los Foros y de donde surgió todo esto.

Saludos,

Checho

Redirección de Perfiles y Carpetas en Windows 7 (Parte IV)

LogoBlogWithSlogan

¡Hola a todos!

Finalmente, hemos llegado al final de la serie de artículos denominados: Redirección de Perfiles y Carpetas en Windows 7.

En esta cuarta y última parte veremos cómo reproducir el comportamiento que iniciamos y automatizamos en el artículo anterior utilizando el Archivo de autorespuesta. A diferencia de éste, veremos primero qué es lo que hace realmente el Archivo de autorespuesta y a partir de allí hacer el procedimiento manual de dos formas diferentes.

*Importante: Recomiendo que los que deseen probar los métodos que explicaré en estos artículos lo haga bajo un entorno explícito de pruebas, además de tener respaldo de las claves de registro modificadas e información que pueda verse afectada.

¿Qué hace el archivo de autorespuesta realmente?

Ya en el artículo anterior desplegamos un equipo en el que todos los perfiles nuevos que se crean se van diréctamente para la unidad D:\Users.

Sólo existe una forma de saber de dónde sale este cambio en Windows y es utilizando la mejor de todas las herramientas: Process Monitor de Sysinternals.

Específicamente, la función de Boot Logging que se puede habilitar desde el menú Options, Enable Boot Logging. Para este caso, hice esto y al reiniciar el sistema abrí nuevamente Process Monitor para guardar todo el log; una vez guardado, era tiempo de buscar qué información podría darme.

Como siempre, buscando por palabras que sirvan de patrón, utilice la de “profile” que es “Perfil” en inglés, después de algunos resultados, encontré lo que responde la pregunta inicial:

FF2

*Nota: Recomiendo hacer clic en la imagen para verla en tamaño completo.

Analizando un poco más a fondo el log, al crearse e iniciarse un nuevo usuario (Principalmente al iniciarse que es cuando ocurre todo), primero Windows utiliza la función RegOpenKey para abrir la clave:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Al abrir esta clave, utiliza la función de RegQueryValue para consultar el contenido del valor ProfilesDirectory, que para este caso, las mismas propiedades de la operación lo indican:

image

Como se ve en el valor de “Data”, el contenido es D:\Users, que es la unidad y directorio especificado en el Archivo de autorespuesta y destinado a donde se desea que Windows guarde todos sus nuevos perfiles creados.

En pocas palabras, cuando en el Archivo de autorespuesta indicamos en las propiedades del componente FolderLocation (Ver artículo anterior), Windows en su fase de oobeSystem que es la última establece el contenido del valor ProfilesDirectory a D:\Users, al igual que ProgramData. si desde Process Monitor lanzamos el Registro haciendo clic derecho y Jump To veremos cómo quedó:

image

Obviamente, Windows hace el cambio incluso antes de que se cree el primer usuario, por lo que todos quedan con esta redirección a la nueva unidad.

Ahora, si seguimos analizando la parte de la captura, vemos que luego de hacer esto, Windows cierra el trabajo con esta clave con RegCloseKey e inmediátamente pasa a hacer varias operaciones a nivel de sistema de archivos, entre las que se incluyen, crear la carpeta por usuario en la nueva unidad. Primero trata de abrir el directorio D:\Users\WinGuy2 pero con el resultado NAME NOT FOUND, por lo que todavía no está creado, así que pasa a crearlo utilizando la función CreateFile tal cual lo había buscado, es decir: D:\Users\WinGuy2

Lo está creando en D:\ porque ya previamente leyó dónde tenían que estar los perfiles de usuario almacenados.

Después de esto, viene lo más importante, Windows utiliza la función RegSetValue para crear el valor y su contenido de ProfileImagePath en la clave:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-790306392-3545880310-3045740698-1007

Si nos damos cuenta, después de ProfileList, hay un SID (Identificador único) para un usuario, aunque puede ser difícil detectar a cuál pertenece, sin embargo, al hacer clic derecho e ir a las propiedades, podemos ver algo que nos ayude a identificarlo:

image

En Data, nuevamente está escribiendo D:\Users\WinGuy2, lo que quiere decir que posíblemente este SID corresponda al usuario WinGuy2, entre otras, porque antes de esto recordemos que se creó la carpeta con el mismo nombre en la unidad D:\.

*Nota: Si traducimos “ProfileImagePath” puede ser algo como: Ruta de imagen de perfil, es decir, donde tendrá todo lo relacionado a éste.

A pesar de todo, si deseamos asegurarnos completamente de que este es el SID del usuario, basta con utilizar otra estupenda herramienta de Sysinternals (¡Lo tiene todo!) llamada PsGetSid.

Esta herramienta, como todas las que empiezan por “Ps” de Sysinternals, se hace por línea de comandos y tiene la capacidad de ejecutarse tanto en equipos locales como remotos, y para obtener información del SID tanto de usuario como de máquina.

Como estamos en un equipo local, basta con ejecutar PsGetSid y determinarle el usuario para el que se quiere obtener el SID, por ejemplo, en este caso que quiero confirmar el SID del usuario WinGuy2 bastaría con ejecutar:

PsGetSid WinGuy2

FF3

El resultado era el esperado, el SID correspondiente a WinGuy2 era:

S-1-5-21-790306392-3545880310-3045740698-1007

Exactamente el mismo que Windows estaba estableciendo según el resultado del log de Process Monitor.

Por último, Windows utiliza de nuevo la función de RegCloseKey para cerrar la operación en la subclave correspondiente al usuario.

Ahora que el sistema operativo sabe dónde debe almacenar el contenido del perfil y tiene el directorio creado, empieza a generar todos los archivos necesarios y unicos por perfil un poco más adelante, por ejemplo el de NTUSER.DAT que indica la configuración de HKEY_CURRENT_USER:

image

Hasta aquí, sabemos las claves determinantes que modificó el Archivo de autorespuesta para que Windows después hiciera la redirección del perfil de usuario, con esto podemos “jugar” para lograr finalmente el mismo comportamiento.

Redirección de Perfil de Usuario manualmente

Existen dos posibles formas de cambiar la ubicación del perfil, la primera desde Windows de forma Online y la otra desde la imagen offline, ambas no muy recomendadas ni soportadas, por esto mismo, recomiendo de nuevo hacer las pruebas para los que deseen en un ambiente totalmente controlado, el fin de este artículo es de enseñanza.

Método Online

La recomendación aquí, es hacer el cambio desde un único usuario en el sistema, con el fin de no modificar la ubicación de éste y en cambio sí asegurarse de que la ubicación de todos los demás sea en la nueva partición.

Si tomara como referencia la misma imagen instalada para estos dos artículos, ya todo está en D:\ porque el archivo de autorespuesta hizo el cambio, por lo que tendría que pensar en llevarlo a otra unidad o bien devolverlo todo a C:\

Con fines de ver cómo es el procedimiento, lo que haré será devolverlo a la unidad C:\ todos los nuevos usuarios creados.

Como dije, recomiendo utilizar sólo un usuario actual en el sistema para evitar riesgos, lo más fácil es borrar todos los que hayan y utilizar el Administrador integrado, para esto hacemos clic en Inicio, digitamos CMD, clic derecho y “Ejecutar como administrador”.

En la consola de comandos, ejecutamos:

Net User Administrator /Active:Yes

image

*Nota: Si el sistema está en español, se debe poner el mismo comando pero con la palabra Administrador, es decir: Net User Administrador /Active:Yes

Debe indicar que el comando se completó satisfactóriamente, cerramos sesión, iniciamos con el usuario Administrador integrado y borramos las cuentas que puedan existir desde la ventana de Cuentas de Usuario, para que sólo quede el Administrador y el Usuario invitado que está desactivado:

image

Ahora que está hecho esto, procedemos a modificar la ubicación de los nuevos perfiles de la siguiente forma:

1. Clic en Inicio, digitar Regedit, clic derecho y Ejecutar como administrador.

2. En el Editor de Registro, navegar hasta la clave:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

3. Hacemos doble clic sobre el valor ProfilesDirectory y ahí le indicamos la unidad donde deseamos que queden los nuevos perfiles de usuario, para mi caso por ejemplo, lo moveré a la unidad G:\SoftPack\Users

image

*Nota: Windows es extremadamente inteligente, si el directorio no está, él lo creará Smile

Basta con reiniciar, crear un nuevo usuario, y ver que todo funcione:

image

Como es de extremo riesgo dejar la cuenta de Administrador integrada habilitada, se debe ejecutar el comando de Net User para deshabilitarla otra vez:

Net User Administrator /Active:No

image

De ahora en adelante, a menos de que se modifique otra vez, todos los usuarios que se creen, se irán al nuevo directorio.

*Nota: Adicionalmente se puede mover el directorio de ProgramData, el de Public y el de Default, pero nuevamente, que sea desde un único usuario que no se afecte para que los demás no tengan problemas.

Método Offline

Este método consiste básicamente en montar la imagen Offline (Install.wim) antes de instalarse y modificar el Hive correspondiente a HKEY_LOCAL_MACHINE, hacer el cambio a los nuevos directorios (En la misma clave que el método Online), desmontar la imagen guardando los cambios y desplegarla.

No entraré en detalle, porque tengo un artículo totalmente dedicado a esto, lo único que varía es la clave que se va a modificar, pueden verlo desde aquí:

http://geeks.ms/blogs/checho/archive/2011/10/11/sysinternals-y-windows-deployment-mejor-juntos-establecer-pol-237-ticas-y-cambios-en-el-registro-a-una-imagen-offline-de-windows-7.aspx

*Importante: Los cambios mal hechos en el Hive de HKLM pueden ocasionar corrupción completa en la imagen de Windows, así como los que se hacen en el Registro de Windows, por eso no es un procedimiento soportado.

Adicional a esto, pueden tener problemas de perfiles temporales, en caso de que sea así, es porque se hace referencia a ubicaciones de perfiles que no existen o bien que no se encuentran los archivos necesarios por perfil como el NTUSER.DAT, pueden revisar este artículo en caso de tener el problema.

Con esto llegamos al final, espero haber cubierto todo o la gran mayoría de los métodos existentes para direccionar tanto los perfiles como las carpetas de usuario.

Ojalá les sea de utilidad tanto como para mí lo fue aprenderlo.

PD. No olviden seguirme en Twitter: http://twitter.com/#!/Checho_L

Saludos,

Checho

Redirección de Perfiles y Carpetas en Windows 7 (Parte III)

LogoBlogWithSlogan

Ya estamos finalizando la serie de artículos sobre la Redirección de Carpetas y Perfiles en Windows 7; en las anteriores entregas, vimos cómo Windows controla y administra la redirección de sus carpetas por medio de Políticas de Grupo, además de cómo era el comportamiento cuando hacíamos la configuración manualmente.

A pesar de esto, como nos hemos dado cuenta, hasta ahora sólo hemos tocado lo que concierne a la redirección de las carpetas de usuario (Documentos, Imágenes, Música, etc), el perfil hasta ahora sigue en su ubicación predeterminada al instalar Windows, es decir, en %SystemDrive%\Users, que normalmente es C:\Users

En este post veremos el procedimiento que corresponde a la redirección de Perfiles, que básicamente, es que no se vayan sólo las carpetas sino todos los archivos que requiere cada perfil para otra partición o ubicación definida.

El procedimiento soportado consiste en utilizar un Archivo de autorespuesta, a comparación con las anteriores maneras, se configura el redireccionamiento desde la instalación de Windows y no cuando éste ya está online (Instalado).

¿Qué necesitamos?

- Los archivos de instalación de Windows 7, tengamos en cuenta que vamos a preparar una imagen, necesitamos entonces copiarlos todos a una carpeta local, para este artículo, estarán en C:\7

- En el Equipo técnico donde está la carpeta con los archivos de instalación, necesitamos tener instalado el Kit de Instalación Automatizada para Windows 7 (WAIK). Si aún no lo tienen, pueden descargarlo desde Aquí.

- Un equipo virtual o físico donde probar el despliegue del sistema operativo.

Configurando Archivo de autorespuesta

Ya hemos visto desde hace tiempo y en varios artículos que el Archivo de autorespuesta es básicamente, un XML de texto plano que le indica a Windows qué debe hacer conforme va transcurriendo la instalación, es decir, le dice qué particionamiento debe tener, idioma, usuarios, y configuraciones adicionales.

Esto da la estupenda oportunidad de pensar en un despliegue totalmente desatendido (Sin interacción de usuario) tanto en Windows como en Server y configurable desde varios gestores (MDT, WDS, SCCM, etc).

Como dije, el Archivo de autorespuesta entrega una grandísima cantidad de configuraciones y personalizaciones que se pueden asegurar en la imagen que quedará finalmente implementada, esto lo hace utilizando el Administrador de imágenes de Windows (SIM) incluido en el WAIK y, básicamente utiliza unos componentes que alojan todas las configuraciones y que se adhieren en diferentes fases que tiene el Archivo de autorespuesta y que a la vez, representan las fases de instalación de Windows.

Lo que haremos será utilizar el subcomponente de FolderLocation, ubicado en el componente de Windows-Shell-Setup para redirigir el perfil a la partición D:\ o a cualquier otra.

¡Empecemos!

Para ejecutar el Administrador de Imágenes de Windows (SIM), hacemos clic en Inicio, Todos los programas, Microsoft Windows AIK; clic derecho en Windows System Image Manager y seleccionar “Ejecutar como Administrador”.

SIM se divide en tres grandes páneles, el primero de Izquierda a derecha donde se encuentra divido en dos llamados Distribution Share que es donde se ubican los recursos adicionales como paquetes a distribuir con la imagen y el que nos interesa aquí que es Windows Image, en éste debemos seleccionar sea la Imagen de instalación (install.wim) o su respectivo archivo de catálogo (install_Windows 7 <Edicion>.clg) para que se presenten los catálogos.

Hacemos clic derecho sobre Select a Windows Image or catalog file y escogemos Select Windows Image…

image

Debemos ir hasta la carpeta donde ubicamos los archivos de instalación de Windows 7 (En mi caso, en C:\7), ubicar la carpeta Sources y seleccionar el archivo de imagen o catálogo, el más rápido y que sirve sin problemas es el archivo de Catálogo, en mi caso, como es Windows 7 Enterprise, tiene el nombre de install_Windows 7 ENTERPRISE.clg:

image

Cuando se abre el archivo de catálogo, en el SIM debajo de Windows Image ahora se verá la imagen seleccionada y las carpetas de Components y Packages:

image

El segundo pánel está compuesto por el de Answer File, aquí irá el Archivo de autorespuesta y todos los componentes adicionados a éste.

Debemos hacer clic derecho sobre Create or open an Answer file y seleccionar New Answer file…

image

El resultado será el Archivo de autorespuesta con todos los nodos disponibles para agregar componentes:

image

Hasta aquí sólo agregamos el archivo de catálogo con los componentes y creamos el archivo de Autorespuesta, lo que sigue ahora será enfocarnos en agregar el componente de FolderLocation que hará la redirección de perfiles para que la imagen al instalarse se vayan directo a D:\

A pesar de que el componente principal es FolderLocation para lo que queremos, debemos hacer una configuración adicional y se basa en las particiones del disco, debemos asignarlas desde el Archivo de autorespuesta para que la redirección funcione, si no se hace, no funcionará así se haya especificado el FolderLocation.

La aparente razón es porque Windows no utiliza el nombre para las particiones sino hasta el final cuando las asigna, por tanto, la configuración no se establece al no encontrar la partición a la que se redireccionó ya aplicada (Ver captura de “Sobre asignación de particiones” en la última parte)

El primer paso entonces es ir al panel inferior izquierdo, debajo de Windows Image, expandir el nodo de Components y buscar el de Microsoft-Windows-Setup_6.1.7600.16385_neutral, expandir el subcomponente DiskConfiguration, Disk, CreatePartition, clic derecho y seleccionar Add settings to Pass 1 windowsPE

image

Debajo de CreatePartition, está ModifyPartition, debemos agregarla de la misma forma también a windowsPE.

Hacemos esto tres veces para cada una, es decir, tres para CreatePartition y tres para ModifyPartition.

En el Archivo de autorespuesta, debajo de windowsPE, se deben ver todos los componentes agregados y aún sin configurar (Color azul claro):

image

La razón de la que son tres particiones es porque la primera será la Oculta de 200 MB que Windows utiliza para los archivos de BitLocker y de arranque, la segunda será la de instalación del sistema operativo, normalmente C:\, y la tercera será la destinada a la redirección de perfiles, normalmente y para este artículo, la particón D:\

Esta es la configuración que debe tener todo el componente de DiskConfiguration:

DiskConfiguration

WillShowUI: OnError
Disk DiskID: 0
WillWipeDisk: True
CreatePartition Order: 1
Size: 200
Type: Primary
CreatePartition Order: 2
Size: <TamañoEnMB>
Type: Primary
CreatePartition Extend: True
Order: 3
Type: Primary
ModifyPartition Active: True
Format: NTFS
Label: System
Order: 1
PartitionID: 1
ModifyPartition Format: NTFS
Label: Windows
Order: 2
PartitionID: 2
ModifyPartition Format: NTFS
Label: Perfiles
Order: 3
PartitionID: 3


En el componente de InstallTo, si es que se especifica una instalación desatendida, se le debe indicar que sea en la segunda partición, es decir en DiskID 0, PartitionID 2:

image

Después de indicadas estas configuraciones para el particionamiento, se debe abrir el componente de Microsoft-Windows-Shell-Setup, clic derecho en FolderLocation y seleccionar Add setting to Pass 7 oobeSystem

image

En el Archivo de autorespuesta, se selecciona y en la tercera columna de propiedades se le debe indicar una partición y carpeta preferida si se desea a FolderLocation y ProgramData, en mi caso, todo para D:\Users  y D:\ProgramData respectivamente.

*Nota: Ambas carpetas se recomiendan enviarlas a la misma ubicación.

Capture

*Nota: Recomiendo siempre poner una carpeta a crear, preferiblemente de igual nombre que la que maneja Windows (Users ó Usuarios y ProgramData), si sólo se pone la unidad, pueden dañar el servicio de perfiles y obtener este error al intentar ingresar por primera vez:

ErrorPro

Esto es todo, adicionalmente se puede configurar el Archivo de autorespuesta para que la instalación sea totalmente desatendida.

Una vez terminado, se debe ir al menú File, Save as y guardar el archivo en la carpeta Raiz de los archivos de instalación de Windows con el nombre Autounattend.xml, en mi caso en C:\7

image

Si desean, pueden descargar el Archivo que utilicé para este artículo que redirige a D:\ y está totalmente desatendido, exceptuando el nombre del equipo y el de usuario, además de que copia el perfil de usuario predeterminado teniendo en cuenta que se puede trabajar con una imagen maestra capturada. Todo para que lo tengan como referencia:

Construyendo Imagen…

Ya todo está listo, nos queda crear la imagen .ISO de nuestra instalación, para eso vamos a Inicio, Todos los programas, Microsoft Windows AIK, clic derecho sobre Deployment Tools Command Prompt y seleccionamos “Ejecutar como administrador”

El comando para construir la imagen es:

oscdimg –b<Directorio7>\Boot\Etfsboot.com –u2 –h <Directorio7> <Ubicacion>\Name.iso 

Donde <Directorio7> es la carpeta que contiene los archivos de instalación de Windows, <Ubicacion> es el directirio donde deseamos guardar la imagen ISO y “Name.iso” es como deseamos llamar la imagen con la extensión .ISO.

En mi caso, sería:

oscdimg –bC:\7\Boot\Etfsboot.com –u2 –h C:\7 C:\Win7FD.ISO

image

Sobre asignación de particiones

Como había mencionado en el principio del artículo, estamos particionando desde el Autorespuesta es porque así se haga el particionamiento dinámico en Windows, nos estamos asegurando de que el XML le diga al sistema operativo que la segunda partición es la que tendrá los Perfiles, si no lo hacemos, tal vez habría que jugar con el cómo Windows administra las letras de particiones:

FDD

En la captura anterior por ejemplo, mientras se hace la expansión de archivos en la instalación de Windows, la primera letra asignada es la C:\, pero no es a Windows, sino a la partición oculta de 200 MB mientras se hace la instalación, la letra que es Windows es la D:\ y la que tiene Perfiles es finalmente la F:\, por lo que si no particionáramos desde el Autorespuesta habría que saber en este caso esto e indicarle a FolderLocation que guarde en F:\, probáblemente al terminar la instalación que Windows pasa a ser C:\ porque la partición oculta se queda sin unidad y Perfiles pasa a ser D:\, tendría ahí los perfiles de usuario entonces.

*Nota: Estaré probando esta teoría pronto, pero veo innecesario teniendo el Autorespuesta de complicarnos en este artículo buscando cuál es cuál.

El último paso es finalmente instalar grabando la ISO en alguna unidad DVD/USB o bien montándolo en un equipo virtual y una vez terminado, verificar que efectivamente en la partición D:\ (O en la que se haya escogido) esté la carpeta de Users con el respectivo perfil creado:

image

Como ven, quedó la carpeta Users en la unidad D:\ tal y como debería de ser.

En el próximo post estaremos terminando esta serie de artículos explicando cómo realizar este mismo proceso manual, aunque no soportado.

PD. No olviden seguirme en Twitter: http://twitter.com/#!/Checho_L Smile

Saludos,

Checho