domingo, 18 de abril de 2021

Despliegue de Software por GPO a través de VPN

 

Hola, 

Como bien sabéis, quienes habéis leído mi entrada anterior en este blog, el despliegue de software vía GPO se inhabilita cuando las directivas se aplican en modo refresh. Este escenario los encontramos comunmente cuando tenemos equipos fuera de la oficina  que conectan por VPN una vez ya iniciada la sesión de usuario.

Una forma de desplegar aplicaciones vía GPO a pesar de tener equipos por VPN, es la de configurar  una tarea progamada (Scheduled Task) a través también de GPOS. Con ello, podemos lanzar una orden de instalación silenciosa de software.


Programa a instalar

Para la demostración siguiente, he utilizado el programa Visio Viewer.

Download Microsoft Visio 2016 Viewer from Official Microsoft Download Center

Este programa cual ofrece un MSI que rescaté en la ruta:  C:\Program Files (x86)\MSECache\vviewer  tras instalarlo a mano en un equipo y comprobar que la instalación clásica no requiere variables.

Podéis ver todo el registro de instalación de Visio viewer en C:\Users\mhernandez\AppData\Local\Temp\Microsoft Visio Viewer 2016 (0).log y deducir todo esto.

Una vez tenemos un .MSI o .EXE que se deja instalar sin preguntas. o bien un .CMD o .BAT que nos lanza la instalación de un programa que con las variables oportunas comprobamos que se instala sin preguntas, ya tendríamos lo que necesitamos para el laboratorio.

Más información aquí: Command-Line Options - Win32 apps | Microsoft Docs


Creación de GPO

Para la creación de una GPO, iremos a "Computer configuration\Preferences\Control Panel Settings\Scheduled Tasks".

Allí podemos crear Tareas programadas tomando como ejemplo la captura que pongo a continuación.

Observar las capturas relativas a solapa, General, Triggers y Actions.

Teniendo en cuenta que desde Actions, es donde está el kit de la cuestión. Desde allí, en mi caso llamo a un archivo .cmd que tiene una única linea:  "\\servidor\carpeta compartida\viewer.msi".



En Trigger es donde podemos configurar tanto al recurrencia del disparto de la acción, como el día que queremos que caduque la tarea programada.


En Actions es donde llamamos al archivo que disparará la instalación del archivo .msi.



El resultado en un equipo afectado por la GPO es el siguiente:










martes, 13 de abril de 2021

Comportamiento de GPOS a través de VPN

 Hola, 

A raíz de la proliferación de entornos de teletrabajo, muchos administradores de sistemas con Directorio Activo, están encontrando situaciones que no les eran comunes hasta ahora.

La instalación de software o lanzado de scripts de Log-in no está funcionando vía GPO, dado que habitualmente, los equipos iniciados fuera de la Lan, no ven a los controladores de dominio, hasta que iniciamos sesión en Windows e iniciamos la conexión VPN. 

Esto no sería así, si tuviésemos IPSEC, Direct Access o accesos VPN Always on, pero no es algo común de encontrar. 

Habilitación de DirectAccess | Microsoft Docs

Comportamiento

Por definición, y aunque no está popularizado este conocimiento, las gpos se procesan cada 90 minutos con una diferencia aleatoria de 30 minutos. Por lo que podemos decir, que todas las gpos que no se han procesado al estar el equipo conectado a la red en el inicio, finalmente se procesan, si el equipo permanece conectado a la VPN. Esto viene a ser igual, en cuanto a las GPOS con opciones de usuario.

Tenéis información sobre procesamiento Síncrono y Asíncrono y sobre el proceso de refresco aquí:

RefreshPolicy function (userenv.h) - Win32 apps | Microsoft Docs

Initial Processing of Group Policy | Microsoft Docs

Logon Optimization | Microsoft Docs

Actualizar la directiva de grupo | Microsoft Docs

Excepciones

Instalación de software, Scripts de logon y redirección de carpetas.

Lo dicho anteriormente es cierto, aunque es bien cierto también, que no todas las opciones configuradas en las GPOS se aplican cada 90 minutos. "Folder Redirection" por ejemplo, o la aplicación de Scripts de logon e instalación de software vía GPO, en las opciones de GPO por equipo, no se aplicarán nunca si el equipo no alcanza a los controladores de dominio en el arranque del sistema operativo. En cuanto a estas opciones lanzadas por usuario, si no se alcanzan los DCs tras la introducción de las credenciales.

Conectividades lentas

Aun con todo lo comentado, todo equipo conectado por VPN tendrá una conexión considerada lenta si esta ofrece 500kbps. Esta consideración es la que encontramos por defecto, aunque permite ser cambiada.

La política en cuestión, la podéis encontrar en las opciones por equipo: 

    Policies\Adminsitrative Templates\System\Group Policy

    Con nombre: Configure Group Policy slow link detection . Podréis variar la consideración entre 0 y        4.294.967.200 kbps. Si configuráis la cifra 0 desactivaréis la consideración de Slow Link.

La consideración lenta, también puede determinarse por otras situaciones a pesar de tener más de 500kbp, por ejemplo serían estas:

- Slow-link mode:  Determinación de latencia según path. (“Configure slow-link mode” policy on Vista for Offline Files | Microsoft Docs)

- Tiempo de espera: Control Slow Network Connection 120 milisegundos (GPS: Control slow network connection timeout for user profiles (gpsearch.azurewebsites.net)

- PingBufferSize: Algoritmo por cierto que ha varia en Windows Server 2019 y versiones superiores a Windows 10 1809. (https://docs.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/manage-profile-service-slow-link-detection#how-slow-link-detection-works-in-current-operating-systems)

La consideración de conexión lenta según PingBufferSize, ha variado según versión de Windows:

  • Windows Server 2019 and Windows 10 1809: KB 4601383, February 16, 2021-KB4601383 (OS Build 17763.1790) Preview
  • Windows 10 1909: KB 4601380, February 16, 2021—KB4601380 (OS Build 18363.1411) Preview
  • Windows 10 20H1/20H2: KB 4601382, February 24, 2021—KB4601382 (OS Builds 19041.844 and 19042.844) Preview

También, podéis cambiar el comportamiento de conexión lenta a través de las siguientes opciones en GPO:

A modo de diagnóstico. El evento que veréis cuando no podremos por ejemplo aplicar un Roaming profile es el siguiente:

Log Name: Application

Source: Microsoft-Windows-User Profiles Service

Event ID:1543

Y por ejemplo, el aviso que un usuario verán en perfiles móviles dirá lo siguiente: 

Your roaming profile isn't synchronized with the server because a slow network connection is detected. You've been signed in with a local profile.

Más información la podéis encontrar aquí: https://docs.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/manage-profile-service-slow-link-detection#settings-that-control-slow-link-detection

Slow Link Mode - Archivos Offline

Event ID=1004

Description:  Path \server\share$ transitioned to slow link with latency = 81 and bandwidth = 258888 

“Configure slow-link mode” policy on Vista for Offline Files | Microsoft Docs


Las opciones de las directivas de grupo no aplicará en conexiones Slow Link son las siguientes:


COMPONENTE


FORZADO (Push)


Deployed Printer Connections

No

Disk Quotas

No

Folder Redirection

No

Scripts

No

Software Installation

No

domingo, 11 de abril de 2021

Script - Configurar Azure VM como DC durante su creación

 Hola, 

El Script que os quiero compartir no es gran cosa, pero andaba cansado de crear DCs a mano para entornos de pruebas en Azure. Así que hace un tiempo creé un Script que lo hace y hoy, tras utilizarlo por enésima vez, os lo comparto.

#Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled false

Add-WindowsFeature RSAT-ADDS-Tools

Install-WindowsFeature -name AD-Domain-Services

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

$pasw="TuContraseña"

$spasw = $pasw | ConvertTo-SecureString -AsPlainText -Force

Install-ADDSForest -DomainName dominio.local -SafeModeAdministratorPassword $spasw -Confirm:$false -Force -InstallDns:$true -DomainNetbiosName dominio -NoRebootOnCompletion

Start-Sleep -s 10

Restart-computer

Veréis que he comentado la línea donde podrías deshabilitar el Firewall de Windows, yo finalmente no lo hago, pero up to you. También tendréis que adaptarlo y poner vuestra contraseña.

La primera vez, para poder lanzarlo durante la creación de una VM, tenéis que subirlo a un contenedor y en opciones avanzadas, elegir crear un "Custom Script Extension", eligiendo el script subido o subirlo durante el wizard que aparecerá.






miércoles, 3 de febrero de 2021

Asignar licencia de M365 por pertenencia a grupo en Azure AD

Hola, 

A continuación os detallo los pasos para asignar licencias de forma automática por pertenencia a grupos de Azure AD o AD sincronizados.

Licencias M365 Apps por device

El funcionamiento de asignación de licencias O365 apps por dispositivo, es el mismo que se describe a continuación, pero deberemos incluir equipos en el grupo correspondiente, en vez de usuarios. Tras eso, ya podremos desplegar Office 365 apps (anteriormente proplus) y este software será activado por dispositivo.

Para la poder inlcuir equipos en grupo de auto asignación de licencias, deberías habilitar la sincronización de dispositivos en Ad-Connect.


Licencias M365 por Usuario

Necesitas contar con licencia P1 o E5 pero con tener una se habilita la opción...

1. Ir a la opción "Licenses" en Azure AD.


2. Dentro de la opción elegida, hacer click "All groups" y luego en el tipo de licencias que queréis asociar al grupo.




3. Tras esto has de elegir "Users and Groups" y en el menú de la derecha elegir el grupo que queréis asociar.


4. Después de elegir el grupo, tenéis que hacer click en "Assignment options" y elegir las opciones de la licencia que queréis aplicar.



Con esto ya estaría. Una licencia se asignará a cada usuario perteneciente al grupo.

Debéis tener en cuenta que toda licencia asignada a un usuario mediante grupo, no podrá ser retirada de un usuario directamente, para eliminar la licencia asignada habrá que retirar al usuario del grupo.

Saludos.



lunes, 1 de febrero de 2021

Habilitar Self Service Password en inicio de sesión

 

Hola, 

A continuación os dejo los pasos necesarios para habilitar la opción de recuperación de contraseña en el inicio de sesión.






Requisitos

Opción 1 - Escenario de AD híbrido 

- Azure AD P1 en el usuario

- Password Write Back habilitado en la sincronización de AD Connect.


Opción 2 - Escenario con equipos ligados solamente a Azure AD

- Solamente es necesario ligar el equipo a Azure AD.


Requisitos generales:

- Contar con los equipos ligados a Azure AD.

- Internet y en el caso de Proxy, contar con acceso a las direcciones passwordreset.microsoftonline.com y ajax.aspnetcdn.com

-Contar con versión Windows 10 1803 o superior

-Qué los usuarios hayan ofrecido información de contacto, como por ejemplo teléfono y/o dirección de correo secundaria.


Los pasos para configurar la activación


Sin Intune (Endpoint Device Manager)

Promulgar en tus equipos la clave de registro siguiente: 

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount

"AllowPasswordReset"=dword:00000001


Con Intune (Endpoind Device Manager)

Crear una política aplicada a usuario o equipos con la siguiente configuración: 

OMA-URI  - ./Vendor/MSFT/Policy/Config/Authentication/AllowAadPasswordReset

Tipo de datos : Entero

Valor: 1