Cerrar
InicioMicrosoft TEAMSMicrosoft Teams, conceptos y tecnología (Parte XXIV) – Solución Problemas Operador Automático

Microsoft Teams, conceptos y tecnología (Parte XXIV) – Solución Problemas Operador Automático

Siguiendo con el proceso de migración de usuarios a Teams (Microsoft Teams, conceptos y tecnología (Parte XXIV)) y las dificultades que nos podemos encontrar (Microsoft Teams, conceptos y tecnología (Parte XXIV) – Solución Problemas Migración Usuario), os voy a comentar el siguiente problema que había tenido en la migración del sistema de telefonía On-Premises (Cisco Systems) a Cloud-PBX.

El proceso de portabilidad sin problema, todo ha ido a la perfección, pero siguiendo con el problema de los atributos de los usuarios que parecían que eran usuarios ubicados en un SkypefB On-Premises, claro .. ha surgido un problema con los Operadores Automáticos. Cuando uno se crea un operador automático, el sistema finalmente crea un contacto en el Directorio Activo para luego desde los clientes de Lync/SkypefB puedan encontrarlo y llamar si fuese necesario. Como mi entorno están sincronizado con AzureAd Connect con Office 365 y, entiendo que algo habría pasado por el problema de los usuarios que tenían un valor incorrecto el atributo HostingProvider … pues al configurar el Operador Automático no iba a ser menos, como vemos nos indica que nos falta la entrada en el Directorio Activo.

Si editamos el Operador Automático y lo guardamos veremos la advertencia con mayor nivel de detalle, aquí os dejo un artículo que había publicado en su momento y donde explico esto pero claro, cuando era un entorno híbrido que no es el caso ahora, pero por lo menos os servirá par aclarar el “problema”: Migrar SkypefB On-Premises a SkypefB On-Line CloudPBX

Pues siguiendo el mismo procedimiento que había seguido con el problema del atributo HostingProvider de los usuarios, he abierto el caso con el soporte de MSFT y  … más de los mismo:

  1. Revisión de atributos locales
  2. Crear el operador automático en On-Premises de forma manual en mi Directorio Activo On-Premises:

$OU = “ou=,dc=,dc=”
$displayname = “Nombre”
$lineuri = “tel:+349XXXXXXXX”
$guid = [guid]::NewGuid()
$sipaddress = “sip:oaa_8974acdc2fd642bd9a613bdd31b9b5c7@XXXXX”
$name = “{” + $guid.Guid + “}”
$objurn = “urn:trustedonlineplatformapplication:ce933385-9390-45d1-9512-c8d228074e07”
$deploc = “sipfed.online.lync.com”
$cn = “CN=” + $name
$dn = $cn + “,” + $ou
$upn = $sipaddress.replace(“sip:”,””)
New-ADObject -type User -Path $ou -Name $name -DisplayName $displayname
Set-ADObject -Identity $dn -Add @{“msRTCSIP-ApplicationOptions”=256;”msRTCSIP-ArchivingEnabled”=0;”msRTCSIP-DeploymentLocator”=$deploc;”msRTCSIP-OptionFlags”=384;”msRTCSIP-OwnerUrn”=$objurn;”msRTCSIP-PrimaryUserAddress”=$sipaddress;”msRTCSIP-UserEnabled”=$TRUE;”UserPrincipalName”=$upn;”msRTCSIP-Line”=$lineuri}

Claramente … esto ha dado error porque yo no tenía (ni tengo) esos atributos en el Directorio Activo:

Y bueno .. como en la otra ocasión cuando se cansaron de hacer pruebas .. pues me llaman y me dicen que pruebe a editar el Operador Automático y compruebe que ahora al guardar ya no da problemas, pues … vamos a ello:

Parece que pinta bien ..

Listo!! Ya no tenemos problemas, básicamente y aunque no me lo hayan dicho, ellos han creado el objeto en el Directorio Activo donde yo sincronizo el mío vía AzureAD Connect:

Como podemos apreciar, 0 errores!!

Comentaros también que esto no impide el buen funcionamiento del operador, simplemente que no lo podamos encontrar en las búsquedas desde el cliente de Skype y poco más. Pero claro, entrar a editar el Operador Automático y ver siempre ese error … me supera.

Espero que si os ocurre algo parecido esto os sirva de ayuda y ganar tiempo con el personal de soporte!!!

Microsoft Teams, con
Reglas de QoS aplica
NO HAY COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This