La historia de las salas de conferencias saturadas

Este artículo se publicó por primera vez en pr itk y ha sido visto allí unas 10.000 veces.

Tiempo de lectura: 18 minutos

Última actualización antes de 1 año a través de Patrick Ruppelt

Este artículo se refiere básicamente a la constelación en la que los usuarios con su cliente Outlook (Outlook 2010, Outlook 2007, Outlook 2003) acceden a un Exchange Server 2007 (o en partes también a otras versiones de Exchange).

Exchange ofrece la posibilidad de definir recursos. Toda una serie de recursos ya están predefinidos, al igual que los recursos de sala, es decir, las salas. Es estupendo que el usuario simplemente introduzca una nueva cita en su agenda, invite a los participantes y seleccione una sala correspondiente como recurso. Si la sala está ocupada, el usuario puede verlo en la línea de tiempo que viene con un Office Outlook actualizado. Exactamente como uno está acostumbrado de otros usuarios.

Ahora bien, se dice que en realidad ocurre que al mismo tiempo dos equipos están delante de la misma sala de reuniones y ambos afirman que la cita ha sido introducida y confirmada en sus calendarios. ¿No puede ser? ¿Uno de ellos miente? ¡No! Sí que se puede. De hecho, Exchange puede dar a dos equipos la impresión de que ambos han reservado una sala y que, en realidad, está introducida en los calendarios de ambos como reservada. Emocionante, ¿verdad?

Para llegar al fondo de la causa, tienes que profundizar un poco más en el asunto. El asunto no es tan trivial como parece a primera vista. La gestión de los recursos -si se me permite decirlo como no técnico- sigue en realidad una lógica bastante estricta. Por un lado, es técnica en el sentido de que los parámetros individuales son booleanos. Por otra parte, la intención que persigue el administrador al establecer los parámetros también sigue reglas booleanas.

Mi hilo de pensamiento es un poco confuso, lo ilustraré con algunos extractos de un -sí, casi panfleto- de Murat Gunyar. Ha escrito un magnífico artículo en el Blog del Equipo de Intercambio Artículo que me parece extremadamente instructivo, informativo y absurdamente divertido en algunos puntos. Aunque lo absurdo se debe más al hecho de que la tecnología sólo es tan buena como se desarrolla para serlo. Cito:

Nota: Cuando se vuelve a ejecutar el cmdlet Set-MailboxCalendarSettings para modificar cualquier configuración, se eliminan los permisos del delegado original. El delegado sigue apareciendo al ejecutar el cmdlet 'Get-MailboxCalendarSettings'. Sin embargo, si miras los permisos del calendario de recursos, se han eliminado los permisos del delegado.

Esto significa tanto como lo siguiente: Estableces nuevos parámetros en el Powershell, por ejemplo, porque quieres cambiar una pequeña cosa. Pero esto no funciona tan fácilmente, porque Set-MailboxCalendarSetting simplemente sobrescribe todos los ajustes anteriores con el nuevo. No se trata de una "adición", sino de una "sustitución". Puede que ésta sea una de las sutilezas que todo administrador de Exchange conoce. Bueno, si no eres administrador no tienes por qué saberlo, pero aun así me parece interesante para todos aquellos que lean este artículo simplemente por interés o curiosidad. Volviendo al tema. Así que hay una "sustitución". Bien. ¿Y después? El comando se ejecuta tal y como estaba previsto, los antiguos permisos, por ejemplo, ya no existen.

¿Qué tiene esto que ver con una agenda sobrecargada? Bueno, está el comando Get-MailboxCalendarSettingsque -me pregunto por qué- muestra la configuración. Por desgracia, este comando vuelve a mostrar no muestra los ajustes modificados. Para verlos, tienes que mirar los permisos en el calendario del recurso. Y ahora seamos sinceros: ¿Qué administrador hace eso...?

Vale, hay que reconocer que esto no tiene mucho que ver con los calendarios sobrecargados, pero nos estamos acercando un poco. Porque: ahora hemos llegado a un punto bastante central del servidor Exchange y podemos empezar a buscar posibles causas.

New-Mailbox -database "Storage Group 1Mailbox Database 1" -Name ConfRoom1 -OrganizationalUnit "Conference Rooms" -DisplayName "ConfRoom1" -UserPrincipalName ConfRoom1@contoso.com -Room

Este sería un ejemplo sencillo directamente del Microsoft TechNet sobre el tema "cómo creo un buzón de habitación". Pero, ¿cuándo me siento en casa de un cliente, se produce el fenómeno del overbooking y puedo sentarme cómodamente y crear yo mismo los buzones? Podría haberlo hecho ayer en casa de mi cliente -donde se produjo exactamente este problema- una vez con más de 3.000 usuarios y no sé cuántas salas de conferencias. Diviértete.

Así que el siguiente intento: comprobemos cómo están configuradas las salas. En realidad, ayuda a averiguar qué salas están afectadas. Pero, por regla general, el usuario que ha comunicado el error no puede decírtelo. Ni ellos mismos lo saben, porque se ocupan de muchas otras cosas cada día, ¿por qué iban a preocuparse de la informática? Solución: ejecuta grep sobre todos los recursos incluyendo todas las banderas relevantes, mételo todo en un archivo Excel y luego evalúa. ¿Evaluar? Cómo, esa es la cuestión.

Fase 1: Qué buzones son en realidad salas. Las salas no siempre se llaman así. Primero hay que completar la lista para que la investigación tenga algún sentido. Todo lo que es un -habitación no puede estar tan equivocado. Al fin y al cabo, hay muchos caminos que llevan a Roma. También hay buzones de equipo, y un confi, en principio, también puede considerarse como tal. También puedes realizar salas mediante buzones compartidos, o crear tus propios usuarios para ellos y abusar de ellos como buzones de grupo con calendarios. Pero lo más importante es que el gigante de Redmond suele tener algo en mente cuando ofrece asistentes y funciones especiales que pueden hacer exactamente lo que quieres.

Fase 2: Ahora tenemos habitaciones. Su comportamiento depende de los parámetros que se hayan establecido. Microsoft tiene una lista bastante extensa de ellos en la sección TechNet pero eso es probablemente ir demasiado lejos para un blog que se autodenomina social techblog desde un punto de vista económico. Así que aquí está mi resumen, que básicamente presenta el principio de cómo y por qué los espacios se comportan de forma independiente. Este debe ser el quid de la cuestión en alguna parte.

Parámetro importante número 1: AutomatizarProcesamiento

Este parámetro regula cómo

• Ninguno: Tanto la reserva de recursos como el llamado asistente de calendario, que introduce automáticamente nuevas reuniones en el calendario, están desactivados en este recurso. Esto significa que ambos no hacen nada, todas las solicitudes permanecen en el buzón del recurso hasta el último día.
• Actualización automática: El valor por defecto acepta condicionalmente todas las solicitudes y luego espera a que el delegado confirme la cita. El organizador de la reunión recibe la información del delegado.
• AutoAceptación: Y aquí es donde la cosa se pone realmente emocionante. La reserva del recurso tiene lugar a nivel de buzón de sala. Las solicitudes entrantes se procesan en función de las políticas almacenadas (directrices). En este modo -y sólo en este modo- el organizador de la reunión recibe realmente la confirmación de la propia sala.

Hasta aquí, esto suena plausible y lógico, al menos una vez que has pensado cuál sería la mejor forma de poner en práctica algo así tú mismo. Pero, ¿cómo debería funcionar una AutoAceptación para que realmente produzca resultados aceptables en la práctica? Hay otro parámetro que no es del todo inocente en el lado negativo de la sobreventa de habitaciones.

Número 2: Políticas de reserva de recursos

También en este caso sólo proporciono un resumen muy breve; por favor, no me apedreéis por no proporcionar 100% información técnica correcta. Las políticas definen un estado "EnPolítica", es decir, permitido, y un estado "FueraDePolítica", es decir, no permitido. Permitido o no puede definirse por franjas horarias (reuniones sólo dentro del horario laboral), overbooking (sí/no y sí, oha, también puedes definir que se permita el overbooking. Pero eso sería realmente trivial como causa de overbooking), duración (es decir, cuánto dura la reunión; por ejemplo, todas las reuniones de más de 2 horas requieren permiso del supervisor), etc.

Y para que la historia sea realmente confusa -no, en realidad, sólo para que sea factible-, en este punto se hace otra distinción:

• BookInPolicy: Esta lista de usuarios (grupos, AD, ...) pueden introducir reuniones InPolicy y éstas también se aceptan automáticamente.
• RequestInPolicy: Similar a BookInPolicy, pero es necesaria la aprobación del delegado para confirmar la reserva.
• RequestOutOfPolicy: Aquí vuelve a ser un poco diferente con el esquema, a estos usuarios se les permite solicitar cualquier chorrada y si el delegado la aprueba, entonces también vale. Supongo que Microsoft introdujo esta opción para los comités de empresa, consejos de administración y directivos. O para los adictos al trabajo que, naturalmente, siguen sentándose en la sala de reuniones los domingos.

Ahora hemos avanzado tanto que tiene sentido examinar de nuevo cómo puede producirse el overbooking. Murat ha elaborado una conclusión en su entrada del blog en forma de tabla de posibilidades sensatas. Te recomiendo que leas también este artículo, porque es realmente bueno.

El hecho es: ¿qué tiene sentido?

• Reserva automática: AutoAccept > AllBookIn True > AllRequestIn False. Delegado: ninguno
• Aprobación manual: AutoAceptar > AllBookIn False > AllRequestIn True. Delegado: debe definirse
• Aprobación manual: AutoUpdate > AllBookIn True > AllRequestIn False. Delegado: ninguno

No es tan fácil llegar a este punto, porque la pregunta también se ha planteado a menudo en TechNet. Llegados a este punto, ¡la tecnología se detiene y se impone la lógica!

Si ahora evalúas cientos de salas de conferencias, siempre encontrarás algunas que quizá no procedan del Exchange Server actual, sino que fueron tomadas de uno de 2003. Aquí, los recursos también parecían distintos. ¿O de un Exchange aún más antiguo? O alguien creó las cuentas, o simplemente se parametrizaron de forma diferente.

He aquí un ejemplo para mostrar lo que ocurre cuando se ignora la lógica, y que, al final, puede provocar cosas tan emocionantes como una doble reserva por un sistema técnico. Lo interesante es que sólo tienes que mirarlo desde este lado y considerar lo que realmente es "más probable que ocurra". Hay toda una serie de constelaciones que pueden hacer que algo vaya mal. debe.

Toma el caso 1: AutoAceptación > AllBookIn True > AllRequestIn False. Delegado: ninguno

Pongamos AllBookIn en Falso. ¿Qué ocurre? Alguien quiere programar una cita. Independientemente de la lista BookIn en la que esté, no hay ningún delegado que pueda aprobar nada. Tampoco puede registrarse regularmente, y menos como RequestIn. Lo que ocurre en la práctica: El mejor caso de reserva incorrecta: un mensaje de error diciendo que los derechos no son suficientes para reservar esta cita.

Caso 2: Tomemos un caso realmente malo - Aprobación manual: AutoAceptación > AllBookIn Falso > AllRequestIn Verdadero. Delegado: debería estar definido, pero no lo está

Y ahora llega el caso en el que realmente se combinan tantas coincidencias que es a la vez emocionante ver el resultado e increíblemente difícil identificar directamente la causa en la práctica. Lo que ocurre es lo siguiente

• El empleado 1 introduce una cita. Por tanto, AllBookIn false sólo hace que AutoAccept confirme la cita provisionalmente. El organizador recibe un correo electrónico en su buzón indicando que la cita se ha confirmado provisionalmente. La cita queda registrada en el calendario del empleado. En los detalles de la cita, también puedes ver tu propio tiempo y el de los participantes como reservados. La sala de reuniones también se muestra en el calendario. Duda: La visualización de Outlook en este punto parece ser incoherente, o tiene que ver con tu propia configuración de visualización. El hecho es que el usuario no ve que la propia sala sigue configurada como "sujeta a cambios".
• El empleado 2 introduce una cita. Ahora podría copiar el texto del empleado 2. El caso es que aquí todo parece perfecto, pero no lo es. De hecho, tengo que admitir que mi título puede ser un poco engañoso, porque Exchange no reservó dos citas al mismo tiempo. Pero para los usuarios, todo parece realmente correcto, para ambos equipos. Lo probamos durante varias horas y pudimos reproducirlo en todas las constelaciones imaginables.

¿Qué ocurre ahora? Porque esto no es ni mucho menos el final del camino de lo dudoso. Ambos empleados vuelven al trabajo y no piensan nada malo.

Todo el to Empleados invitados a ambas citas suponer de todos modos que la fecha ya encajará, después de todo hay Un organizadorque se ocupará de ello.

La fecha está firmemente reservada en todos los calendarios. Para ver siquiera -si se buscara explícitamente- que algo no encaja, ya habría que como organizador mira los detalles de la cita y arrastra la línea de tiempo en un monitor que tenga al menos 22″ de ancho, para que puedas ver que la sala aún no ha sido aprobada en una zona sombreada muy pequeña. Los empleados ven - Número de dudosidad X - la habitación como se reservó. Es decir, como reservada en firme. Supongo que los participantes ven este estado (y por tanto suponen que todo encaja perfectamente) porque no ven el estado de su propia sala, sino sólo que la sala ha sido reservada en principio. Pero sólo por el equipo que llegó primero. En otras palabras, los participantes invitados de la reunión 2 definitivamente no han recibido una cancelación y pueden ver la fecha, los participantes y la sala en todos sus calendarios. Los participantes invitados de la reunión 1 ven exactamente lo mismo, pero es de suponer que ellos mismos ven realmente el estado reservado de la sala.

Hasta aquí todo bien. Todo esto es un poco extraño, pero con los parámetros almacenados correctamente este estado no duraría demasiado. Aquí es donde entra en juego un delegado. Recibe el conflicto en su buzón, porque como delegado trabaja como representante de la sala y tiene que tomar una decisión.

Ah, sí, una inserción interesante: aunque así sea y él envíe una cancelación, el organizador de la cita debe seguir actuando. ¡Esto no cambia nada en absoluto en las entradas del calendario de todos los participantes! En otras palabras: otra supuesta doble reserva. Dudoso.

Volviendo al tema actual. El delegado no entra, el correo para la decisión está atascado en la cola de la sala y no hay escalado. Así que no pasa nada.

¿Qué se prevé en tal caso? Nada. Porque es una concepción errónea del conjunto de normas aplicadas por el Admistrador desde un punto de vista lógico. Un proceso así no debería ocurrir nunca. Y eso significa en lenguaje llano: ambos organizadores recibieron un compromiso provisional. Nunca se produjo una cancelación. Y todo parece correcto en todos los calendarios. Ergo: Ambos equipos estarán en el mismo lugar al mismo tiempo y ambos tienen la misma razón. Dudoso.

Y todavía no hemos llegado al final: aún me quedan curiosidades por descubrir. La mayoría de los clientes no sólo utilizan Exchange desde ayer, sino que también han utilizado versiones anteriores. Era habitual que los departamentos tuvieran uno o varios empleados que se ocupaban de los calendarios de las salas de conferencias. Normalmente se abrían simplemente como un buzón de correo adicional, e incluso entonces ya no se producía este overbooking. Lo que ocurre es que no está diseñado así. Por supuesto, funciona, pero sólo mientras el calendario esté abierto en algún sitio, como "propietario", por así decirlo. Si el empleado se va, se acabó. Un caso así nunca se documenta, al menos no en 15 años... ¿Y entonces? Entonces tienes una sala de conferencias desierta que aparentemente ha funcionado durante años (aunque estaba mal configurada) y luego "de repente" ya no cumple su función y permite la sobreventa.

No es dudoso: La culpa, como siempre, es del ser humano.