viernes, 24 de julio de 2015

Evento en el MUG - AD DS de Cero hasta la Nube

Junto con Javier Schamber vamos a realizar un evento en el MUG de Buenos Aires en donde mostraremos Active Directory Domain Services desde cero hasta mostrar como instalar Domain Controles en Azure.

Además vamos a contar con la paticipación especial uno de los IT Pros más reconocido en el país, Rodrigo De Los Santos.
 
Para inscribirse, pueden visitar el sitio del MUG.

viernes, 10 de julio de 2015

No todo lo que un mailbox necesita es Set-Mailbox

En un entorno Exchange, cuando queremos ver la propiedades de un mailbox, utilizamos el cmdlet Get-Mailbox, y para configurarlo utilizamos Set-Mailbox.
 
Recientemente me consultaron cómo se podrían deshabilitar los protocolos de conexión Imap4 y Pop3 para todos usuarios. La primera opción fue crear una GPO en la cual los servicios relacionados con ambos protocolos se deshabilitaran (Figura 1).

Figura 1

Luego me consultaron por la posibilidad de deshabilitar múltiples usuarios de forma centralizada. La dificultad consiste en que Set-Mailbox no permite habilitar o deshabilitar protocolos de conexión. Esto se debe a que las configuraciones de conexión de acceso de un mailbox se ven y se modifican respectivamente con los cmdlets Get-CASMailbox y Set-CASMailbox.
 
Una vez que sepamos qué cmdlets utilizar, simplemente debemos crear una sentencia que sirva a nuestro propósito.

Get-CASMailbox * | Set-CASMailbox -ImapEnabled $False -PopEnabled $False

Con el cmdlet previo, deshabilitamos Imap y Pop para todos los usuarios, y si reemplazamos el "*" por el filtro que queremos, podemos realizar la misma acción en un sub-set de usuarios.

martes, 30 de junio de 2015

¿Cómo puedo ser "NT Authority"?

Existen algunos momentos en los cuales no basta con ser administrador del equipo. No importa si es por un error al asignar un permiso, un programa que falló, una mala desinstalación, o un equipo que no sabemos por qué manos pasó... La realidad es que aunque creemos que los administradores somos los que tenemos más autoridad sobre el equipo, algunas veces nos encontramos con un "Acceso Negado".
 
Quien verdaderamente tiene todos los permisos sobre las claves de registro, archivos, directorios, etc es la cuenta System (nt authority\system).
 
Esta cuenta existe en todos los equipos Windows, pero no podemos utilizarla  si no tenemos la posibilidad de ingresar el password de la cuenta.

Si utilizamos PSExec (La herramienta de Sysinternals) podemos acceder como System.
 
Figura 1
 
Al ejecutar "PSExec.exe -s \\NombreDelEquipo cmd", accedemos remotamente a una consola de comandos en el equipo remoto, tal como lo muestra la Figura 1. Aquí podemos ver que nos conectamos remotamente a otro equipo con un CMD con permisos de System.
 
Si queremos utilizarlo en el equipo local, debemos ejecutar "PSExec -s -i -d cmd".
 
En cualquiera de los dos casos, debemos ejecutarlo desde una consola con permisos de Administrador (Figura 2).
 
Figura 2
 
 
 

miércoles, 6 de mayo de 2015

Boot a VHD / VHDX con UEFI

Recientemente intentamos virtualizar unas desktop para pasarlas a una infraestructura de VDI. Para aprovechar que el SO era Windows 8.1, creamos los equipos virtuales en Hyper-V como equipos de Generación 2.
 
Esta nueva generación de máquinas virtuales realiza el inicio por UEFI, por lo que nos encontramos con algunos problema a la hora del inicio de los equipos.
 
Primero, el desktop que antes iniciaba por BIOS ahora no iniciaba por UEFI, adicionalmente no podíamos utilizar Bcdedit para manejar las opciones de inicio (Figura 1).

Figura 1

Inicialmente utilizamos Diskpart para formatear la partición de System con sistema de archivo FAT y activarla.

Por último, debimos utilizar Bcdboot, incluido en el directorio System32 de la instalación de Windows y lo ejecutamos con algunos parámetros (Figura 2).

Figura 2
bcdboot.exe :\Windows /s  /f All


Indicamos el disco donde está Windows , el disco de inicio, y especificamos que el SO puede iniciar con BIOS y UEFI "/f ALL".

Siguiendo esos pasos el disco que antes era físico e iniciaba por BIOS, ahora pudo iniciar por UEFI como parte de un equipo virtual.

martes, 25 de noviembre de 2014

Remove-MoveRequest falla con AccessDeniedException en Exchange Server

Durante una transición de Exchange Server de 2010 a Exchange Server 2013 nos encontramos con un problema cuando se intentó mover el "Archive" de un usuario a otra MailboxDatabase.
 
En un principio, obtuvimos un error que indicaba que ya existía un MoveRequest anterior, por lo que lo verificamos y lo intentamos eliminar (Figura 1).


Figura 1

El error de AccessDeniedException nos hizo dudar, debido a que la cuenta con la que realizabamos la operación era miembro del grupo de RBAC "Organization Management". Finalmente encontramos que la cuenta en algún momento de la transición había sido movida a Exchange Server 2013 y luego vuelto a Exchange Server 2010.
 
Para resolver nuestro problema ejecutamos el cmdlet "Remove-MoveRequest" en Exchange Server 2013 (Figura 2).


Figura 2


Con eso pudimos volver a la EMS de Exchange Server 2010 y realizar el "New-MoveRequest" (Figura 3).

Figura 3
 
 



lunes, 27 de octubre de 2014

Modificar TTL para un solo registro en la zona DNS

Una de las opciones de configuración en una zona DNS es el tiempo de vida de los registros (TTL o Time To Live), el valor ingresado en el registro SOA es válido para todos los registros de la zona (Figura 1).

Figura 1
 
Sin embargo, en algún caso, puede ser necesario querer variar el TTL para un registro en particular. En las propiedades del registro no se ve la posibilidad de cambiarlo (Figura 2).
 
Figura 2
 
Para poder cambiar el TTL de un solo registro primero hay que activar las opciones avanzadas en la consola de DNS (Figura 3) y luego, al abrir las propiedades del registro, tenemos presente esa opción (Figura 4).
Figura 3

Figura 4

Podemos especificar cualquier valor, que será válido solo para ese registro. Si utilizamos nslookup en modo de debug (Figura 5), podemos ver que cuando hacemos una consulta por el registro (A) que modificamos, el TTL del registro es diferente al de la zona (Figura 6).
 
 
Figura 5

Figura 6

miércoles, 23 de abril de 2014

Borrar cuenta de equipo que es un contenedor

Cuando quisimos borrar un equipo desde el Active Directory Users And Computers (ADUC) nos hemos encontrado con un mensaje que informaba que el objeto era un contenedor, y dentro de éste había otros objetos (Figura 1), similar a cuando borramos una OU.
 
 
Object contains other objects. Are you sure you want to delefe object and all of the objects it contains
Figura 1

Si queremos saber qué objetos hay dentro de este objeto, debemos seleccionar View y luego Users, Contacts, Groups and Computers as containers dentro del ADUC (Figura 2).

Figura 2
 
 
Luego de activar esta opción, podemos ver en el ADUC que la cuenta de equipo contaba con algún ServiceConnectionPoint (Figura 3), debido a que era un Exchange Server 2010.  
 
Figura 3

Una vez que comprobamos que efectivamente no es necesario conservar esa información, podemos borrar la cuenta sin problemas.