Windows Server

Sincronización horaria en Directorio Activo

fernando

En la instalación por defecto de Windows Server la sincronización horaria se realiza contra el reloj del propio servidor; para utilizar una origen externo NTP, en este caso utilizaremos el pool para España, de debemos ejecutar en el servidor principal:

net stop w32time
w32tm /config /syncfromflags:manual /manualpeerlist:"0.es.pool.ntp.org,1.es.pool.ntp.org,2.es.pool.ntp.org,3.es.pool.ntp.org"
w32tm /config /reliable:yes
net start w32time

w32tm /query /status

Para los equipos pertenecientes al dominio la sincronización se realiza contra la arquitectura de Directorio Activo mediante NT5DS es posible modificar mediante política de grupo (GPO):

Podemos restaurar los valores por defecto del servidor horario si vemos que no se aplican correctamente algunos cambios y forzar la sincronización:

net stop w32time
w32tm /unregister
w32tm /register
net start w32time
w32tm /resync /force

Para forzar a un equipo cliente a sincronizar contra el servidor del directorio ativo:

w32tm /config /syncfromflags:DOMHIER /update
w32tm /resync /nowait
net stop w32time && net start w32time

Auditoria de servidores en entorno híbridos

fernando

Si disponemos de equipos on-premise y en Azure, podemos unificar la gestión de registros en una única herramientas. Aunque ha variado de nombres, actualmente se engloba dentro de «Área de trabajo de Log Analytics» que podremos crear desde el panel de control de Azure.

Desde el nuevo recurso en «Configuración avanzada» podemos descargar el agente para Windows o Linux:

Leer más →

Administración Remota mediante Política de Grupo

fernando

Para permitir la administración remota a equipos dentro del dominio podemos definir una Política de Grupo:

Configuración del Equipo – Directivas – Plantillas administrativas – Componentes de Windows – Administración remota de Windows (WinRM) – Servicio WinRM

 

Configuración del equipo – Directivas – Plantillas administrativas – Red – Conexiones de red – Firewall de Windows – Perfil de dominio

Habilitamos «Firewall de Windows: Permitir excepción de administración remota entrante» e indicamos la IP desde la que se puede gestionar o asterisco «*» para cualquiera

Por último añadimos una regla en el firewall: Configuración del equipo – Configuración de Windows – Configuración de seguridad – Firewall de Windows con Seguridad Avanzada – Reglas de entrada

Añadimos una nueva predefinida: «Administración remota de windows»

Configuración de equipo – Preferencias – Configuración del Panel de control – Servicios

Nos aseguramos que «WinRM» se inicie con el sistema:

Directorio activo hybrido en Azure

fernando

Ambos nombres son equivalentes, describen un atributo que no cambia durante la vida de un objecto. Se trata de identificar de forma única en un entorno local y en Azure AD.

Por defecto se calcula codificando en Base 64 la propiedad objectGUID del servidor local, por ejemplo:

$Usuario = Get-ADuser nombreDeUsuario -Properties * -server localhost
$ImmutableID = [system.convert]::ToBase64String(([GUID]($Usuario.ObjectGUID)).tobytearray())

Realmente no debería cambiarse, pero en ocasiones nos encontramos en la necesidad de hacerlo, bien por una migración de directorio, eliminación de usuarios, replicación con errores… Si en lugar de utilizar el objectGUID utilizariamos un atributo personalizado no tendríamos este problema pero conllevaría la gestión y administración del mismo, si dentro de la empresa cada uno tiene un identificador único personal podría utilizarse para calcular el sourceAnchor.

Esta propiedad se establece durante la instalación inicial, solo si se desinstala correctamente se puede volver a establecer con un valor personalizado, desde la versión 1.1.524.0 se facilita el atributo ms-DS-ConsistencyGuidcomo atributo de los usuarios a utilizar como sourceAnchor.

Podemos visualizar la propiedad actual desde PowerShell:

Import-Module AzureAD
$O365Cred = Get-Credential
$O365Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
Import-PSSession $O365Session
Connect-AzureAD -Credential $O365Cred
Get-AzureADUser -ObjectId [email protected] | Select objectID, UserPrincipalName, ImmutableID

Si bien, en la documentación aparece, la posibilidad de establecer el valor en nulo para desvincular las cuentas creadas localmente de la nube mediante powershell:

Set-AzureADUser -ObjectId [email protected] -ImmutableID $null

No genera ningún resultado ni modificación del objeto, por lo menos a fecha de hoy.

Como alternativa, podemos crear un usuario temporal en nuestro directorio, sincronizar e intercambiar sourceAnchor, asignando otro incorrecto al usuario a eliminar posteriormente.

 

 

Modern Backup Storage, DPM, NTFS y ReFS

fernando

A partir de System Center Data Protection Manager (DPM) 2016 se introdujo este nuevo sistema de «almacenamiento moderno de copias de seguridad» en su traducción literal, con el objetivo de simplificar, optimizar y gestionar de forma más rápida copias de seguridad locales consumiendo menos espacio.

En la práctica y de manera sencilla, se utiliza un volumen formateado en ReFS y ficheros/discos VHDX que se provisionan para la copia. La combinación de ambas permite sacar mayor rendimiento en el sistema de ficheros:

  • Clonación de bloques (Block cloning) permite transformar la copia de ficheros en copia de metadatos, es decir, si tenemos un Fichero A dividido en nuestro disco en 100 partes y lo copiamos en un Fichero B, este último hará referencia a las 100 partes iguales de su origen, enlaza el contenido. Si se produce una modificación de una parte del fichero, en ese momento se realiza una copia de la parte afectada (se desenlaza de A y se enlaza el nuevo bloque a B)
  • VDL disperso (Sparse Valid Data Length) agiliza la escritura de ceros en ficheros grandes, permite eliminar ficheros, y crear archivos de tamaño fijo VHDX de manera rápida.
  • Paridad acelerada por reflejos (Mirror accelerated Parity) se realiza la escritura de entrada espejada para después calcular la paridad y almacenarse en su ubicación final.

En el momento de «Agregar almacenamiento en disco» se formatea automáticamente el contenido de la unidad en ReFS.

Si bien este sistema de ficheros no sustituye todavía a NTFS, permite grandes ventajas en entornos de almacenamiento y virtualización.

Ahora bien, en el momento que intentamos localmente «Agregar DPM Externo» de Azure nos encontramos:

Error 100070: El destino de recuperación seleccionado para recuperar una o más archivos no es válido.
Acción recomendad: Asegúrese de que el destino de recuperación se encuentra en un volumen NTFS montado localmente

Durante la configuración no se advierte ni comprueba. En el momento de intentar agregarlo si ¿Por qué este requisito? ¿No se puede restaurar ficheros desde Azure sobre un destino ReFS?

 

Referencia de errores: Codigo de error de Data Protection Manager
Versión: Azure Backup Server v3 13.0.415.0