Plug n Lay (down)

    Estos días ando algo liado intentando configurar WDS para que despliegue imágenes Windows y Linux, así que no tengo demasiado tiempo para escribir. En todo caso, tampoco quiero dejar la semana en blanco, así que voy a publicar un pequeño post relámpago de un script que me pidieron el otro día.     Desde uno de nuestros departamentos nos pidieron crear unos cuantos cientos de direcciones de correo con las que poder testear una aplicación. Las cuentas deben de ser lo suficientemente “reales” para poder comprobar que los correos de repuesta se reciben correctamente y probar carga. Bajo esas condiciones, se decidió utilizar un buzón compartido de Exchange online, de un dominio nuevo creado para este tipo de test. Mi trabajo consiste en crear un script que se conecte a Exchange online y permita a un usuario con los permisos necesarios, añadir el numero de cuentas que necesite con el formato que necesite al buzón compartido que elija. Y aquí está el resultad...

   Y seguimos a vueltas con la implementación de AD connect que estoy realizando ahora. Curiosamente, esta debería ser la mas sencilla de las tres que he tenido que llevo en total, ya que al ser una startup, Office365 ha sido su primer y único proveedor de correo y lo único que querían, era sincronizar las contraseñas. Fácil, ¿no? Pues no.    Durante las pruebas iniciales, comencé sincronizando a los usuarios de mi departamento, así como una serie de grupos de la nueva estructura/nomenclatura que estoy implantando en el AD local. Una vez solucionado el único fallo que había tenido en la implantación (podéis saber más aquí ), había considerado cerrada ya la parte de configuración y me disponía a migrar el resto de departamentos. En ese momento, mi jefe me llamo y me explico que estaba había accedido al portal de Exchange online para echarle un vistazo a algunas configuraciones de los grupos y no podía hacer algunas operaciones. En concreto, estaba intentando modifi...

La verdad es que últimamente no paro. Después de añadir los logs de servicios de directorio a mi script de chequeo de eventos, he visto que tenía unos warnings indicándome que no había hecho backup recientemente de algunas (o todas) de las particiones del directorio. El mensaje es el siguiente: Así que he comprobado en nuestra aplicación de backup (Veeam backup) y he visto que si se hace backup de los DCs. Al final el problema consiste en que, pese a que se hace backup, este se realiza a nivel de máquina virtual, y por lo tanto no es consistente. Podéis encontrar una explicación mas completa en este post de Veeam: LINK La solución simplemente consiste en realizar un backup nuevo con las VM que necesitan que el backup sea consistente (no solo los DCs, también maquinas con otras bases de datos). Para ello el backup debe hacer uso del servicio de snapshots VSS de Windows, y esto se configura en este paso del asistente del job de backup de Veeam: Una vez configurada esta nueva ta...

Ayer termine de instalar y configurar Azure AD connect. Para los que no lo sepáis, Azure AD connect es el programa que se utiliza para sincronizar objetos de tu directorio activo local con el directorio activo de azure. Podéis acceder a la estupenda documentación de Microsoft aquí. El caso es que después de terminar la configuración, estuve repasando que las primeras sincronizaciones fueran correctas cuando vi que aparecía una tarea con errores en Azure AD sync service. El fallo era el siguiente: Como podéis ver, esta tarea de export, que ya os voy diciendo que era una sincronización de contraseñas, falla por un problema de permisos. La verdad es que era un poco confuso, ya que había seguido la documentación de Microsoft para la implementación al pie de la letra y cumplido todos los prerrequisitos. ¿Se me escapaba algo? Al final, la respuesta era bastante sencilla. Este directorio activo no lo desplegué yo, así que hay algunas cosillas “heredadas”. Una de ellas es que una Unidad Organi...

   Esta semana estoy preparando nuestro dominio para conectarlo con Office365. Uno de los pre-requisitos que se deben cumplir para poder hacerlo, consiste en que tu Dominio local debe ser enrutable en internet ( link ). Desgraciadamente, el dominio de mi actual empresa es un dominio .local, así que no cumplimos este prerrequisito. Afortunadamente, existe una forma sencilla de sortear este problema, evitando tener que renombrar tu dominio, un proceso que es bastante complejo (ya tuve que hacerlo una vez hace años, y no me apetece repetirlo). Lo que hay que hacer es básicamente añadir un segundo sufijo de dominio a nuestro directorio. Para ello, haremos los siguiente:    Abrimos el complemento de administración de  Dominios y confianzas y pulsamos con el botón derecho en dominios y confianzas y luego en propiedades:    En la ventana que se nos abre, escribiremos un sufijo alternativo para nuestro dominio (obviamente, que sea enrutable) y después pulsa...

Rápido y fácil. El siguiente código te permitirá lanzar un ping a todos tus servidores de dominio: Get-ADComputer -Filter 'OperatingSystem -like "Windows Server*"' | foreach-object {Test-Connection -computername $_.dnshostname -Count 1} | ft -autosize -wrap Y como nos ha sobrado algo de tiempo, podríamos gastarlo en www.lolcats.com Todo un clásico. Cheers!

   Recientemente he tenido que hacer limpieza de restos debido a la baja de un compañero administrador. Unos días después, mi script de chequeo de logs todavía me cantaba errores que podían estar relacionados con el uso de su cuenta de administrador. Lo mas probable es que hubiera sesiones remotas abiertas con su usuario (ya deshabilitado), desperdigadas por los servidores de la compañía. Para buscarlas, hay varias formas de hacerlo. A continuación, os muestro dos de ellas.    THE OLD WAY, usar los comandos quser y logout    Primero necesitamos ver que usuarios están logados en el servidor remoto y con que id de sesión para después, poder hacerles logof remotamente. Para ello, usaremos el comando quser de la siguiente forma: Quser /server:servername     Este comando devuelve la lista de usuarios logados en un equipo remoto, indicando el nombre, el id de la sesión, el estado y los tiempos de logon y de inactividad. Una vez que teng...

    Hoy me había propuesto hacer un pequeño inventario para uso personal con la lista de servidores Windows que tenemos en AD, así como los roles de servidor que cada uno de ellos tiene instalado. No he conseguido encontrar en internet la forma de filtrar la salida del comando get-windowsfeature para que solo muestre roles, así que os lo pongo aquí para que veáis como se hace (en realidad es muy fácil).    Para hacerlo, he usado el siguiente script de Powershell: #Lista servidores y SO desde Directorio Activo $servers = Get-ADComputer -Filter 'OperatingSystem -like "*Server*"' -Property name,OperatingSystem #Para cada servidor listado del comando anterior, muestra la lista de Roles instalados foreach($server in $servers) {      Write-host -BackgroundColor Blue -nonewline $server.name "----" $server.OperatingSystem      Get-WindowsFeature -ComputerName $server.name | Where {$_.FeatureType -like 'Role' -and $_.installed -eq $...