Archivo

Archivo para viernes, 26 de abril de 2013

Modificar atributos masivamente en objetos de Directorio Activo

viernes, 26 de abril de 2013 Comments off

Hola a todos,

Me han pedido que realice unos cambios en cerca de 3000 objetos usuarios de directorio activo, entre los que están:
1- Cambiar el estado del usuario a Deshabilitado
2- Modificar un atributo del usuario para ocultarlo de la Libreta de direcciones de Exchange.

El punto 1, basicamente, lo solucioné con un Script que consultaba los atributos LastLogonTimeStamp y LastLogon, y manualmente se deshabilitaban aquellos que eran usuarios no genéricos, que tienen nomenclatura similar los usuario normales.

Para saber estos usuarios, desde la consola de administración de Directorio Activo, se ha realizado una búsqueda personalizada en la cual se indica que los atributos LastLogonTimeStamp sea vacío (nunca ha realizado logon en el dominio) o sea anterior a una fecha determinada, en nuestro caso 01/01/2012.

(&((objectCategory=person)(objectClass=user)(|(lastLogonTimestamp<=1325376000)(!lastLogonTimestamp=*))))

Para indicar el valor de TimeStamp, he utilizado la calculadora WEB:

Una vez que he tenido los usuario en Disable, ha tocado ocultar aquellos usuarios que el departamento de RRHH ha indicado por baja en la empresa.

Para poder realizar las acciones sobre el check a marcar:
Atributo HideExchange

Corresponde al atributo del objeto: msExchHideFromAddressLists, que podemos visualizar al abrir el objeto de usuario con la herramienta adsiedit.msc.
Para iniciar las pruebas mediante powershell, probé con visualizar los usuarios que tuviesen el check marcado (true), es decir, que no se ven en la libreta de direcciones o desmarcado (false).

Get-QADUser -Disabled -oa @{‘msExchHideFromAddressLists’=$true}

Para poder modificar tenía 2 formas, una más «elegante que otra», ya que en un Script podía trabajar con Logs de los usuarios modificados.

Sin Logs y a lo loco 😉

Get-QADUser -Disabled | Set-QADUser -oa @{‘msExchHideFromAddressLists’=$true}

Con Logs y más elegante

get-qaduser -searchroot «OU=Disable,DC=domain,DC=local» -IncludedProperties MSExchHideFromAddressLists | where-object {-not $_.MSExchHideFromAddressLists} | set-qaduser -objectAttributes @{MSExchHideFromAddressLists=$true} -Confirm | Tee-Object -FilePath «Ocultos_Exchange.txt»

Pero, como esto hubiese sido muy fácil, este cambio no querían realizarlo de forma masiva sobre toda la OU de DISABLE, e ir haciendo estas modificaciones, previo aviso, otra vez, del departamento de RRHH.

Después de todo esto, y hablando con compañero, me indicaron una herramienta que ha estado toda la vida ahí, y ha sido para mí una gran desconocida 😉

AD MODIFIY: http://admodify.codeplex.com/

Es una herramienta que nos permite, mediante una consulta previa sobre AD, modificar cualquier atributo de manera visual.

Abrimos la herramienta con permisos de modificación en AD, y pulsamos en MODIFY ATTRIBUTES
AD MODIFY

Seleccionamos el dominio sobre el cual queremos actuar y sobre que equipo con el rol de Directorio Activo, queremos actuar.
AD MODIFY

En mi caso, no me hará falta realizar una consulta sobre AD, ya que los elementos a modificar los tengo en el OU de Disable\Users. Navegaré hasta la OU y pulsaremos en ADD TO LIST.

Seleccionamos los objetos que queremos modificar.
AD MODIFY

Y ahora, y de forma visual, podemos modificar el atributo que queremos sin ningún tipo de problema 😉
AD MODIFY

Un Saludo,

Manu

Categories: Herramientas, Microsoft, Server Tags:

Recovery SCCM 2007

viernes, 26 de abril de 2013 Comments off
  • Hola a todos,

He tenido que recuperar un System Center Configuration Manager 2007 R2, con error de hardware e irrecuperable. Se ha tenido que proceder a instalar nuevamente una plataforma de similares característica al servidor origen:

  • Windows Server 2008 R2 Enterprise
  • MS-SQL 2005 Standard x32
  • 2 x vCPU
  • 6Gb vRAM
  • 300Gb vHDD

Para poder recuperar la plataforma de SCCM, lo más similar posible a la que teníamos en producción, es necesario el haber realizado el SiteBackup y tener una copia del FileSystem del servidor.

Una vez instalado el sistema operativo y SQL Server, procederemos a iniciar el restore de SCCM.

Es recomendable el recuperar de la copia de seguridad los directorios:

  • SMSData
  • SMSPKGC$
  • SMSPKGSIG
  • SMSSIG$

Y los directorios, si es posible, de donde guardemos los binarios de los paquetes de instalación de las aplicaciones paquetizadas (por si acaso).

Copiaremos los ficheros de la BBDD de SCCM al directorio de SQL-Server

  • copy [UNIDAD]:\SiteBackup\SMS_Site\SiteDBServer\ *.mdf [UNIDAD]:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\
  • copy [UNIDAD]:\SiteBackup\SMS_Site\SiteDBServer\ *.ldf [UNIDAD]:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\

Y una vez copiado, realizar el attach de la BBDD.
SCCM
Navegamos hasta el directorio «\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Data\» y seleccionamos el fichero que previamente hemos copiado: SMS_Site.mdf
SCCM.

Ahora, tendremos que abrir el desplegable de la BBDD e ir hacia las opciones de seguridad para visualizar los usuarios que existían anteriormente, ya que tendremos que utilizar uno de estos (y que tenga permisos de dbowner), para realizar el posterior proceso de Site Recovery Wizard.

Tendremos que añadir un usuario de la BBDD con permisos de DBOWNER, a la seguridad de SQL-Server.
SCCM

Y posteriormente asegurarnos de que también está en la seguridad de la BBDD
SCCM

Para hacer el SiteRecovery, tendremos que tener en cuenta de que las BBDD de SCCM ya la tenemos en la ubicación correcta, por lo tanto, deberemos de marchar un «check» para que no vuelva a realizar el Attach de la BBDD.
SCCM

Al marcar la opción vemos que no es requerido volver a copiar y presentar la BBDD en SQL-SERVER, por lo tanto, nos indica que la acción es Not Requiered.
SCCM

Si se gerenase algún tipo de error, o quisieramos ver el log de las acciones que se van realizado, deberemos ir a: [UNIDAD]:\Program Files (x86)\Microsoft Configuration Manager\AdminUI\AdminUILog y abrir el fichero: RepairWizard.log.

En la selección de los paquetes, es recomendable el que compruebe la accesibilidad de cada uno de ellos, es un proceso que no tarda demasiado.
SCCM

Reiniciaremos el servidor y abriremos la consola de gestión de SCCM.
Ahora tocará la parte más tediosa, ya que el servidor SCCM deberá de comprobar a todos los agentes que tiene informados, por lo que este proceso, consumirá bastantes recursos del servidor durante bastante tiempo. Así que comprobamos de que en la consola tenemos informados collections que tengamos creadas, advertisements y lo dejaremos para que realice las tareas en Background que hagan falta.