Archivos de la categoría: Sin categoría

Capturando Windows 10 Pro para fábrica de Windows

Me he encontrado con este escenario ya dos veces. Clientes que cuentan con MECM o SCCM necesitan montar una fábrica de Windows para la distribución de imágenes corporativas de Windows 10 sin mucha intervención y disminuyendo el tiempo de espera de usuarios y bajando la carga al equipo de soporte.

Esta operación requiere de preparación de imagen y de una posterior captura. Para que sea una imagen única se ejecuta un proceso que se llama sysprep, que destruye los identificadores de usurio y máquina y permitiendo que se genere uno nuevo por cada distribución.

Todo fantástico. En Winodws 7 funcionaba a la primera y de maravillas. En Windows 10, no.

Con Windows 10 llevaron las Universal Apps. Básicamente son aplicaciones que tienen la interfaz moderna de Windows 10. Microsoft incluye muchas de terceros y propias para mejorar la experiencia del usuario. El problema está en que estas aplicaciones no son compatibles con el proceso de sysprep y hace que fallen. La solución está en eliminarlas a mano y continuar con el proceso.

¿Cómo se identifican?

No existe un listado definido de aplicaciones, porque cambian con cada build de Windows, pero son identificables cuando arroja el error.

El log se encuentra en %windir%\system32\sysprep\panther\setupact.log y %windir%\system32\sysprep\panther\setuperr.log y podrás ver algo como:

SYSPRP Package SpotifyAB.SpotifyMusic_1.148.625.0_x86__zpdnekdrzrea0 was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.

El problema está en la aplicación Spotify. Para quitarla hay que abrir una sesión de Powershell como administrador y teclear:

Get-AppxPackage *spotify* | Remove-AppxPackage

Santo remedio. Hacer lo mismo con todas que arrojen error.

Feliz 2021.

Reflexiones sobre SQL Server

Para los que no lo conocen, SQL Server es el gestor de bases de datos relacionales de Microsoft. Tiene parecidos con todos los otros motores de otras marcas, gratuitos o pagados, pero tiene chichecitos propios que lo hacen atractivo. Es un producto al cual le tengo bastante cariño y he seguido sus avances a pesar que ya no trabajo directamente con él.

No obstante, últimamente por temas laborales me ha tocado interactuar bastante con él en distintos clientes y, en consecuencia, escenarios.

En este artículo pretendo compartir algunas experiencias relevante recogidas en el trabajo con clientes.

Always On

Esta es una tecnología de alta disponibilidad y recuperación de desastres, que aparece por primera vez en la versión 2012 y que ha ido evolucionando mejorando la cantidad de nodos síncronos permitidos, entre otras cosas. Viene junto a la edición Enterprise, pero hay uno en la edición Standard, pero que no tiene todas las capacidades que la incluida en Enterprise, por lo tanto, si se dispone de los medios, presupuesto, hardware y licencias, hay que usarla.

Las máquinas virtuales son geniales. La idea de optimizar el espacio, optimizar recursos y licenciamiento hace que hoy todo el mundo tenga máquinas virtuales para la mayoría de los escenarios. SQL Server puede correr perfectamente en máquinas virtuales. Eso si, se recomienda que los archivos de datos, log y tempdb queden en discos distintos y en ejes de discos distintos. Me refiero a que los discos duros de las máquinas virtuales son archivos que el hipervisor los interpreta como disco y se los presenta a la máquina virtual como un disco duro.

Volviendo al tema, Always On puede correr sobre máquinas virtuales, pero para conservar la esencia recomiendo lo siguiente:

  • Los nodos de Always On deben estar en host físico distinto. En lo posible en distintos rack, con alimentación eléctrica independiente y conectado a otro switch, en modalidad de multi subnet. El motivo es simple: si se cae el host físico completo, está el otro host que almacena los otros nodos. Si se cae el rack completo, está el otro.
  • Se puede hacer una extensión de Always On hacia un ambiente IaaS en Azure. Esto implica la instalación de un controlador de dominio en la nube. No sirve Azure Active Directory. Instalar el nodo de SQL Server y usar un load balancer. Además de configurar una VPN S2S y configurar reglas de firewall y network security group, según corresponda. Importante que las redes se deben ver, tanto en la nube como la red local. El load balancer debe estar configurado con el puerto de la instancia de SQL Server en Azure, debe ser local y tener una dirección ip local. El listener local se debe configurar con la red y la dirección ip del load balancer. Es él quien hará la “magia” al momento de hacer failover. Para más información sobre el listener leer: https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-group-listener-overview?view=sql-server-ver15
  • Las versiones deben ser iguales y con el mismo nivel de parchado.
  • La autenticación integrada Windows la encuentro más segura si se está en un dominio. Sino, usar la de SQL Server.
  • NUNCA usar el usuario sa. Es como usar la cuenta administrator de un dominio o un root en Linux. Las razones son más que obvias.
  • Las aplicaciones pueden correr perfectamente en un sistema Linux. Lo importante es que el servidor debe tener configurado el DNS Suffix y debe estar apuntando al servidor DNS del dominio de Active Directory.
  • NUNCA configurar el listener en la tabla de hosts del servidor Linux o Windows. Para eso está el DNS.

SQL Server en dominio

Es muy común que SQL Server se instale en un dominio para aprovechar las características de administración, seguridad e integración con otras plataformas de monitoreo como System Center Operations Manager.

En el caso que este sea el escenario, recomiendo lo siguiente:

  • Iniciar la instalación con una cuenta de dominio que tenga privilegios de administrador local sobre el servidor. Una cuenta de administrador de dominio no es necesaria.
  • Idealmente no cambiar el nombre del servidor. En caso de hacerlo, configurar el SQL Server para que adopte el nuevo cambio.
  • Siempre usar una cuenta de servicio que esté en el dominio. Esto es para la seguridad del dominio y no tener problemas con los SPN. En caso de llegar a tener algún problema con estos usar la herramienta Microsoft Kerberos Configuration Manager for SQL Server Esta herramienta no nos hará perder el tiempo y generará los scripts necesarios, o en caso de tener permisos de administración sobre el dominio, hará los cambios. Un SQL Server con un SPN mal configurado provocará que las aplicaciones no puedan hacer uso del servicio a pesar que esté arriba.

Dos puntos importantes que no cabían arriba son:

  • Documentación al día: modelos, topologías, inventarios, etc.
  • Actualizaciones al día.

Eso. No sé que más les puedo decir. Cuiden sus motores de base de datos.

Chau!

Certificado autofirmado en IIS

Hola terrícolas.

En la entrega de hoy les vengo a explicar cómo generar un certificado autofirmado para IIS. Esto es válido desde IIS 7.0 hacia arriba. La verdad es que un certificado autofirmado no provee ninguna seguridad para nuestro sitio ni para nuestros visitantes. Lo importante es contar con un certificado de una entidad certificadora local, si el sitio es para consumo local o una entidad externa, como GoDaddy o GlobalSign si nuestro sitio será consumido desde internet.

Para comenzar con la instalación es imperante que el rol de IIS se encuentre instalado. Abrir la consola de administración e ir a Server certificates .

Luego ir a Create Self-Sign Certificate

Completar con la información del certificado

El certificado ya se encuentra creado. Ahora hay que asignarlo a un sitio web. Seleccionaremos el Default web site y nos iremos a bindings.

Solo queda asignar el certificado al sitio. Agregar el binding para el puerto 443 y asignar certificado.

Para probar abrir la URL en un navegador. El resultado esperado es que el sitio de un mensaje de error de seguridad.