Algo que posiblemente hayan notado trabajando con Exchange, es que ni siquiera el administrador que instaló el primer servidor de la organización tiene permisos suficientes para abrir el buzón de otro usuario. Este permiso no viene asociado a ningún grupo en particular.
Al intentar abrir el buzón de otro usuario utilizando Outlook u OWA nos encontramos con los siguientes errores:
Outlook
“No se puede expandir la carpeta. No se puede abrir el conjunto de carpetas. La operación cliente ha fallado”
Si están intentando abrir una carpeta en lugar del buzón entero, el error es muy similar salvo que indica el nombre de la carpeta en cuestión.
Ejemplo abriendo la bandeja de entrada:
“No se puede mostrar la carpeta. No se encuentra la carpeta Bandeja de entrada.”
OWA
“El buzón de correo parece no estar disponible. Intente volver a obtener acceso al mismo en 10 segundos. Si el error persiste, póngase en contacto con el departamento de soporte técnico”
En general cuando asignamos este permiso lo hacemos a nivel de buzón, base de datos o la organización en su totalidad. Mediante scripting y tareas agendadas sería posible utilizar otro tipo de filtros, por ejemplo membresía de grupos, atributo de departamento, custom attributes, etc. En este artículo vamos a hacer foco en los escenarios más comunes.
Permisos de acceso sobre un buzón específico
Si bien esta tarea puntual la podemos realizar desde la EMC (Exchange Management Console) en Exchange 2010 o EAC (Exchange Admin Center) en Exchange 2013, vamos a utilizar el EMS (Exchange Management Shell) que aplica a ambos:
Add-MailboxPermission –identity buzon –User admin –AccessRights FullAccess
Donde “buzon” es el buzón al cual quiero acceder y “admin” es el usuario al que le quiero delegar el permiso de acceso total.
Cabe destacar que esto habilita a abrirle el buzón, etc pero no a enviar como (send as) el usuario.
Permisos de acceso a nivel de base de datos u organización
Viendo el comando utilizado en el primer ejemplo podríamos asumir que para aplicar esto a todos los buzones de la organización ejecutaríamos lo siguiente:
Get-Mailbox | Add-MailboxPermission –User admin –AccessRights FullAccess
Si bien esto asignaría los permisos requeridos, no aplicaría en el caso de nuevos buzones, es decir que habría que asignar los permisos correspondientes cada vez que creemos uno nuevo.
El modo más simple y escalable sería utilizando un comando diferente: Add-Adpermission y ejecutarlo a nivel de base de datos:
Get-MailboxDatabase | Add-AdPermission –User admin –AccessRights ExtendedRight –ExtendedRights “receive-as”
Esto aplica a todas las bases de datos que existen en la organización al momento de la ejecución del comando, si posteriormente creo una nueva base debo ejecutarlo nuevamente (de cualquier modo esto es mucho menos frecuente que la creación de un nuevo buzón).
En caso de querer ejecutar el comando sobre una base individual lo puedo hacer especificando el nombre de la base de datos
“Get-MailboxDatabase nombreDB | Add-AdPermission –User admin –AccessRights ExtendedRight –ExtendedRights receive-as”
A tener en cuenta que los cambios no se ven reflejados de forma inmediata, es decir que si ejecutan el comando e inmediatamente prueban, probablemente no funcione. Primero debe replicar Active Directory y expirar el cache del Information Store. Como alternativa para no esperar por el Information Store pueden bajar y subir el servicio, la desventaja es que desmontaría todas las bases desconectando a los usuarios en el proceso.
En definitiva, antes de ejecutar los comandos saber que hay que tener paciencia 
.
Por último les dejo algunos links con más información sobre los comandos utilizados:
Related Articles:
- Como delegar la administracion de grupos en Exchange 2010/2013 – Parte 2
- Como delegar la administracion de grupos en Exchange 2010/2013
- Evento 1053: Insuff_Access_Rights – Access is denied
- Grupos en Exchange 2013 – No tiene permisos suficientes para realizar esta operacion
Puzzle Bobble
Karate Blazers
Puzzle De Bloques
Magical Cat Adventure