Category Archives: Directorio Activo

Buenos días,.

Hoy nos toca píldora de Powershell y Directorio Activo (AD). Hace tiempo me solicitaron modificar la ruta de acceso al perfil de usuarios, concretamente dejar este atributo vacio para todo los usuarios ya que se iba a dejar de utilizar perfiles móviles.

Podemos consultar el valor de este campo si editamos cualquier usuario de AD desde la consola de Usuarios y Equipos, por ejemplo, en la pestaña de «Perfil» o «Profile»

Lo vamos a enfocar en dos partes, la primera encontrar todos los usuarios que tengan  el campo «Profilepath» con contenido. Y el segundo borrar el contenido de dicho campo, todo ello en un mismo cmdlet entubado …..

• Parte 1: Nos lista todos aquellos usuarios en los cuales tenemos establecidos valores en el campo perfil.
  • get-aduser -filter «profilepath -like ‘*'» -Properties profilepath | ft name,profilepath

En este caso, podeis ver tanto el nombre de usuario como la carpeta compartida donde se encuentra ubicado su perfil (he obviado la información que no nos interesa ;-))

Otro ejemplo, si a mi cuenta de AD le pongo que la ruta del perfil sea «aaaaaa», o «bbbbbb», y lo consulto con el cmdlet:

• Parte 2: Nos establece el campo perfil (profilepath) como nulo:
  • Set-Aduser Filtro de usuario –profilepath $null

 Nos quedaría de la siguiente manera:

• get-aduser -filter «profilepath -like ‘*'» -Properties profilepath | Set-Aduser  –profilepath $null

Nada de nada, correcto. Hemos dejado en blanco todas las rutas de perfiles de usuarios.

Espero que os sea útil y os animeis a utilizar Powershell, ese amigo desconocido.

Besos y abrazos,

Buenos dias,

Os dejo con otra píldora formativa de Directorio Activo (AD9. Es relativamente habitual encontrar en nuestros controladores de dominio el siguiente evento de error tipo:

Log Name:      System
Source:        NETLOGON
Date:          04/09/2014 12:50:53
Event ID:      5807
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      ROBDCA.zalo.com
Description:
During the past 4.25 hours there have been 517 connections to this Domain Controller from client machines whose IP addresses don’t map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client’s site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites.  The names and IP addresses of the clients in question have been logged on this computer in the following log file ‘%SystemRoot%\debug\netlogon.log’ and, potentially, in the log file ‘%SystemRoot%\debug\netlogon.bak’ created if the former log becomes full. The log(s) may contain additional unrelated debugging information. To filter out the needed information, please search for lines which contain text ‘NO_CLIENT_SITE:’. The first word after this string is the client name and the second word is the client IP address. The maximum size of the log(s) is controlled by the following registry DWORD value ‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize’; the default is 20000000 bytes.  The current maximum size is 20000000 bytes.  To set a different maximum size, create the above registry value and set the desired maximum size in bytes.

Básicamente, esto quiere decir que hay equipos que tienen asignada una subred que no está dada de alta en Directorio Activo, concretamente en Active Directory Sites and Services (ADS&S). Esto puede dar lugar a problemas a la hora de hacer Logon o conectarse al dominio por parte de dichos equipos. Y ¿cómo lo solucionamoes? pues revisándonos el fichero NETLOGON.log de cada Controlador de Dominio y buscando aquellos errores de NO_CLIENT_SITE, o clientes sin Site definido.

Pues como ha caido en mis manos un post del Blog de Simon Wahlin de cómo utilizar PowerShell (PS) para analizar el fichero NETLOGON.log pues vamos al lio utilizando el siguiente script Get-MissingSubnets.ps1 que lo podemos descargar desde aqui.

SINTAXIS

La sintaxis de Get-MissingSubnets.ps1 es la siguiente:

.\Get-MissingSubnets.ps1 [[-NumLines] <Int32>] [[-DomainControllers] <String[]>] [-IncludeTimestamp] [<CommonParameters>]

Donde podemos seleccionar los siguentes parámetros:

• Get-MissingSubnets.ps1  sin ningún parámetro, nos mostrará el parseo de todas las subredes de todos los Controladores de Dominio.
• Get-MissingSubnets.ps1 -NumLines <int32> donde analizará las últimas líneas que le hayamos especificado. Por defecto son las 100 últimas.
• Get-MissingSubnets.ps1 -DomainControllers <String> donde analizará únicamente el Controlador de Dominio que le indiquemos.
• Get-MissingSubnets.ps1 -IncludeTimestamp <CommonParameters> podemos especificar si el timestamp puede ser leido o o no del fichero netlogon. Si el timestamp está deshabilitado en cada Controlador de Dominio seleccionaremos la opción $false.

EJEMPLO

Os dejo un ejemplo sencillo como real.

Ejecuto el script sin parámetro alguno, asi que va a consultar las 100 últimas líneas del fichero NETLOGON.log en cada Controlador de Dominio (DC), con el siguiente resultado:

Por lo tanto tenemos equipos que acceden desde una subred 10.13.120.0/24 o una subred 10.13.32.0/24 a nuestros DCs y no está definida dicha Subnet, como podemos comprobar:

Añadimos dicha subred a AD Sites & Services y solucionado.

Recordar que para ejecutar este script …. tenemos que tener una Política de Ejecución de Scripts adecuada, como para este ejemplo:

Que tengais una buena semana.

Lecturas recomendadas:

– Blog de Simon Wahlin.

– Blog de Jorge’s Quest For Knowledge!