Teletrabajo con entornos Windows y coronavirus

Si bien algunas empresas están ya habituadas a permitir a sus empleados realizar trabajo en remoto, con la pandemia del coronavirus muchas otras se han visto forzadas a utilizar recursos limitados para un gran número de trabajadores.

Lo primero de todo, debemos tener en cuenta los servicios nativos cloud, los cuales permiten realizar tareas desde cualquier sitio de forma habitual. Por otro lado, el acceso a recursos locales dentro de la empresa debe asegurarse de diferentes formas:

  • Sistemas de alimentación ininterrumpida deben proveer corriente a los servidores o equipos con disponibilidad, algo básico pero necesario.
  • Seguridad de red activa, abrir un puerto o varios para permitir un servicio (por ejemplo de conexión remota) debe conllevar su monitorización activa en busca de patrones o usos inadeacuados. Firewall dedicados o Azure Bastion por ejemplo.
  • Autenticación de doble factor, donde sea posible y factible, como punto de verificación de identidad de humanos frente a máquinas.
  • Sistemas operativos y antivirus actualizados, no debería llegar una pandemia para tener este punto mínimo cubierto.

Dentro de los entornos corporativos con recursos limitados, se han habilitado ordenadores para su acceso por escritorio remoto, si bien las soluciones RDS/VDI/WVD son muy capaces, para PYMES puede no ser una opción asequible en todos los casos. Por ello debemos tener en cuenta cuando habilitamos el acceso remoto:

  • Separar y securizar redes según los perfiles y requisitos de acceso
  • Establecer directivas de red suficientes
  • Monitorizar y controlar los usuarios permitidos

Si llegados a este punto permitimos el acceso remoto al puesto de trabajo habitual de un trabajador, deberemos tener en cuenta adicionalmente:

Debemos estar seguros lo que supone introducir un ordenador dentro de la red corporativa, así como tener en mente primero a las personas y luego a las máquinas.

 

 


Identificar \Device\Harddisk# en Windows

Algunos de los registros de eventos de Windows utilizan identificadores internos diferentes, para conocer la relación de posible nombres del objeto al que se refieren:

Podemos utilizar la utilidad WinObj de Sysinternals para obtener la relación, desde la carpeta "Device":

O desde la carpeta "GLOBAL??" ordenando por "Symlink" hasta llegar a los dispositivos de disco duro en "\Device\Harddisk..."

Mediante Powershell, donde el DeviceID corresponde con HardDisk#

Get-PhysicalDisk | Select -Prop DeviceId,FriendlyName,SerialNumber

En el registro de Windows dentro la clave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\disk\Enum

Mediante el listado de drivers instalados:

wmic /output:c:\drivers.txt path Win32_PnPSignedDriver

 

Activar escritorio remoto mediante Powershell

Por defecto la conexión por escritorio remoto aparece deshabilitada en los equipos con Windows Pro, en una red de dominio es posible establecer mediante políticas de grupo los permisos necesarios:

- Configuración de Equipo \ Directivas \ Plantillas Administrativas
--- Componentes de Windows \ Servicios de escritorio remoto \ Host de sesión de Escritorio remoto \ Conexiones \ Permitir que los usuarios se conecten de forma remota mediante Servicios de Escritorio Remoto

--- Red \ Conexiones de red \ Firewall de Windows \ Perfil de dominio \ Firewall de Windows: permitir excepciones de Escritorio remoto entrantes

Igualmente podemos echar mano de un Script para powershell escrito por Sitaram Pamarthi en 2013, que mediante WMI nos facilita acciones puntuales:

[cmdletbinding()]
param(
	[parameter(ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
	[string[]]$ComputerName = $env:computername,
	[ValidateScript({Test-Path $_})]
	[string]$OutFolder = "c:\"
)

begin {
$SuccessComps = Join-Path $OutFolder "Successcomps.txt"
$FailedComps = Join-Path $OutFolder "FailedComps.txt"
}

process {
	foreach($Computer in $ComputerName) {

		try {
			$RDP = Get-WmiObject -Class Win32_TerminalServiceSetting `
								-Namespace root\CIMV2\TerminalServices `
								-Computer $Computer `
								-Authentication 6 `
								-ErrorAction Stop
								
		} catch {
			Write-Host "$Computer : WMIQueryFailed"
			"$Computer : WMIQueryFailed" | Out-File -FilePath $FailedComps -Append
			continue
		}
		
		if($RDP.AllowTSConnections -eq 1) {
			Write-Host "$Computer : RDP Already Enabled"
			"$Computer : RDP Already Enabled" | Out-File -FilePath $SuccessComps -Append
			continue
		} else {
			try {
				$result = $RDP.SetAllowTsConnections(1,1)
				if($result.ReturnValue -eq 0) {
					Write-Host "$Computer : Enabled RDP Successfully"
					"$Computer : RDP Enabled Successfully" | Out-File -FilePath $SuccessComps -Append
				} else {
					Write-Host "$Computer : Failed to enabled RDP"
					"$Computer : Failed to enable RDP" | Out-File -FilePath $FailedComps -Append

				}
			
			} catch {
				Write-Host "$computer : Failed to enabled RDP"
				"$Computer : Failed to enable RDP" | Out-File -FilePath $FailedComps -Append
			}
		}
	}

}

end {}

Su utilización para un equipo concreto:

.\Enable-RDPAccess.ps1 -ComputerName <computer name>

 Si obtenemos errores al ejectuarlo, debemos comprobar que tenemos acceso mediante WMI o activarlo mediante GPO:

- Configuración del equipo \ Directivas \ Configuración de Windows \ Configuración de seguridad \ Firewall de Windows con seguridad avanzada \ Reglas de Entrada

Error durante la migración a Windows 10: No se pudo actualizar la partición reservada del sistema

Microsoft ha simplificado, cada vez más, las actualizaciones y migraciones a Windows 10 desde el año 2015, pero en ocasiones es necesario acciones específicas. En este caso el error que nos aparece al utilizar la herramienta de actualización es el siguiente: "No se pudo actualizar la partición reservada del sistema"

En equipos antiguos la partición reservada para el sistema es de escasos 100 MB y los requisitos habituales para Windows 10 en un equipo nuevo crean particiones de 500 MB. Existe una solución temporal que nos permite liberar espacio de la partición original, sin tener que mover particiones completas, se trata de liberar espacio eliminando los recursos de idiomas que no se utilizan. Necesitaremos 15 MB libres.

Debemos seguir el procedimiento muy bien descrito en el artículo de Microsoft, según el tipo de partición MBR o GPT que tengamos en nuestro sistema, lograremos acceder y eliminar algunos recursos no críticos de la partición. Si debemos ejecutar en el procedimiento los comandos del tipo "takeown" en las instrucciones se especifica:

takeown /d y /r /f .

Donde debemos tener cuidado de incorporar el espacio y el punto después de la 'f' además si nuestros sistema operativo se encuentra en español debemos cambiar la 'y' de YES por la 's' de SI

takeown /d s /r /f .

Siguiendo el procedimiento, pasaremos a tener entorno al 50% más espacio libre que nos permitirá continuar la instalación.

 

NOTA: Para otros errores puedes utilizar la aplicacion SetupDiag.exe para analizar los registros de instalación.

Forzar desinstalación de Office

Algunas versiones de Office pueden no ser sencillas de eliminar por completo, sin dejar rastro ni ficheros; otras veces teniendo instaladas varias versiones de la suite ofimática en el mismo ordenador acaba siendo una pesadilla.

El proceso en las nuevas versiónes Office 365, Click-to-run... se ha simplificado considerablemente mediante la utilidad "Microsoft Office Fix", pero con las versiones previas: Office 2013, Office 2010, Office 2007... el proceso manual es largo.

Existen aplicaciones de terceros y otras no tan fiables, pero la propia Microsoft tiene automatizada la desinstalación según versiones y Sistema operativo: