PowerShell
Common Area Phone en Skype for Business online (CAP Online)
Common Area Phone en Skype for Business online (CAP Online)
En el siguiente articulo explicaremos como registrar un teléfono de área común en Skype online de Office 365.
Los teléfonos de área común son una característica que se puede configurar en Skype for Business on-prem, esta caracteristica se usa para configurar teléfonos en salas de reuniones o en espacios comunes, la particularidad de estos telefonos es que no están asociados a ningún usuarios en particular, ademas no requiere de una licencia de usuario.
La configuración y administración de estos teléfonos (CAP) en Skype for Buisness on-prem no es precisamente algo sencillo, requiere crear objetos en AD (Active Directory) ademas de activar las opciones de registro por extensión y PIN. Casi toda la configuracion y administracion se hace mediante Powershell con lo cual requiere que el administrador tenga buenos conocimientos de scripting.
En el caso de Skype for Business online no existía esta característica hasta mas o menos Marzo del 2018, ahora se pueden crear teléfonos de área común (CAP) en Skype for business online y emparejarlo a un teléfono físico que colocaremos en zonas comunes de nuestra empresa.
De momento no se puede usar todos los teléfonos que soporta registro en Office 365 para registrarlos como área común, de momento la opción de CAP online algunas gamas de telefonos Audiocodes y Polycom.
En este caso utilizaremos un teléfono Audiocodes 440HD con firmware version UC_3.0.4.1264
A continuación pasaremos a explicar los pasos requeridos para registrar teléfonos de área común.
Configuración de CAP Online en Office 365
Lo primero que necesitaremos sera un usuario en Office 365, en nuestro caso el usuario se llama “pruebaskype” y tiene la siguiente configuración de licencias
- Licencia Office 365 Enterprise E3
- Sistema telefónico
Dentro de la licencia E3 tiene todas las opciones de servicio activas.
Este usuario también esta activo en Skype for Business online y se le ha asociado un numero de la RTC Local, ya que en el despliegue contamos con un Cloud Connector Edition.
Activar el servicio CAP online en Office 365
Una vez tenemos el usuario creado, vamos a activar en Office 365 el servicio de CAP online.
Desde la pagina de administración de Office 365, vamos al menú facturación, Comprar servicios. Y una vez en la pagina de “Comprar Servicios” iremos a Otros Planes
Ahora, buscaremos “teléfono de área común” e iniciaremos la prueba gratuita o podemos comprar directamente la licencia de 6,70 € por usuario al mes
Asignar la licencia CAP al usuario en Office 365
Una vez comprada la licencia de teléfonos de área común, iremos al panel de administración de Office 365, buscaremos el usuarios “pruebaskype” y editaremos la licencia de producto.
Y activamos “teléfono de área común”
Configuración del Teléfono AudioCodes 440HD
A continuación explicaremos como configurar el telefono Audiocodes 440HD
- Con el teléfono conectado a la red, entramos en el “menú” pulsando la tecla menú
- Ayudándonos con las teclas de “cursor” bajaremos hasta la opción “Administration“
- Ponemos la clave de administración, la de por defecto es “1234“
- Una vez entramos en el menú de administración vamos a “Common Area Phone“
- Una vez dentro, seleccionamos “Enabled” y guardamos
- El teléfono se reseteará
- Una vez arranque el teléfono, pulsaremos en “Sign in“
- Seleccionaremos la opción “CAP Provisioning“
- Seguidamente nos aparecerá la URL de aprovisionamiento y el “Paring Code“
Configuración del emparejamiento
Ahora iremos a la pagina “http://aka.ms/skypecap” y nos logaremos con el usuario Administrador de Office 365. Una vez en la pagina buscamos el usuario con licencia CAP Online y podremos el código de emparejamiento.
Una vez hemos añadido el código de aprovisionamiento que obtuvimos en el teléfono deberemos ver que el teléfono se registra de forma automática.
Y en la url de aprovisionamiento veremos que el teléfono esta registrado
De esta manera ya tenemos el teléfono registrado y listo para usar como telefono de área común de Skype for business online
Powershell Commands to Test Lync and Skype for Business Services
Este articulo en Español aquí
After a few weeks without writing today I have been encouraged again, I have many “articles” in my mind, but I am more involved in some new project. This time I bring some PowerShell commands that you can launch tests of installed services in a Skype for Business implementation.
Usually when we do a Unified Communications installation there is a moment during the project where we will do a “battery” of tests to check the services of Skype for Business. This complicates sometimes, because we will need at least 2 or 3 Skype clients with different user accounts to do the “typical” IM tests, calls, conferences, etc … Apart from The complication to have the “clients” Skype simultaneously, we will need the help of another coworker to be able to do the tests.
Well, with these commands that I will specify below, we will be able to do a basic tests of the Skype services that will give us the “health” result of the platform.
To perform the tests we will need two accounts registered in Skype for Business, I always advise to have a couple of “Test” accounts, which we can have to do tests, etc. This is something we will ask in the Initial Requirements to begin the installation To our client or the Active Directory administrators. In this case the accounts that I am going to use are.
Login: MRLYNC\SkypeTest1
Sip: SkypeTest1@mrlync.com
Password: *********Login: MRLYNC\SkypeTest2
Sip: SkypeTest1@mrlync.com
Password: *********
Once we have the data of our “Test” accounts, we will enable them in our Skype for Business.
Declare the variables
The first thing we will do is declare your variables with the data we want to use for the tests:
$login1 = “SkypeTest1@mrlync.com”
$sip1 = “SkypeTest1@mrlync.com”
$password1 = “*****” | ConvertTo-SecureString -AsPlainText -Force
$cred1 = New-Object System.Management.Automation.PsCredential($login1, $password1)
$login2 = “SkypeTest2@mrlync.com”
$sip2 = “SkypeTest2@mrlync.com”
$password2 = “******” | ConvertTo-SecureString -AsPlainText -Force
$cred2 = New-Object System.Management.Automation.PsCredential($login2, $password2)
$targetfqdn = “skypepool.mrlync.com”
$authtype = “ClientCertificate”
#$authtype = “Negotiate”
Surely you have noticed that the field “login” we declare it as the field “Sip”, with Skype for Business I worked in this way the commands, but if we are going to run the tests in a platform of Lync 2013, surely we will need to put The login field: “MRLYNC \ SkypeTest1”
Front End Services
Once we have collected the data in the variables, we use the following commands to test the services of our Pool or Standard Front End Server.
#Regitration
Write-Host “Registration“
Test-CsRegistration -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Address Book Service
Write-Host “Address Book Service“
Test-CsAddressBookService -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Lis Configuration
Write-Host “Lis Configuration“
Test-CsLisConfiguration -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Presence
Write-Host “Presence“
Test-CsPresence -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SubscriberSipAddress “sip:$sip1” -SubscriberCredential $cred1 -PublisherSipAddress “sip:$sip2” -PublisherCredential $cred2
#Lync Web App
Write-Host “Skype Web App“
Test-CsUcwaConference -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -OrganizerSipAddress “sip:$sip1” -OrganizerCredential $cred1 -ParticipantSipAddress “sip:$sip2” -ParticipantCredential $cred2 -verbose
#Skype IM
Write-Host “Skype IM“
Test-CsIm -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$login1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$login2” -ReceiverCredential $cred2
Test-CsGroupIM -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
Test-CsMcxP2PIM -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
#VoIP
Write-Host “VoIP”
Test-CsP2PAv -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
All of these commands can be added in a TxT file format * .ps1 and launched directly as a script from PowerShell, so we can use it to test the Skype deployments that we will configure
Comandos Powershell para probar los servicios de Lync/Skype for Business
This article in English here
Tras unas semanas sin escribir hoy me he animado de nuevo, tengo muchos “artículos” en la recamara, pero la verdad que últimamente ando mas liado en algún proyecto nuevo. En esta ocasión traigo algunos comandos PowerShell con los que se pueden lanzar pruebas de los servicios instalados en una implementación de Skype for Business.
Normalmente cuando hacemos una instalación de Comunicaciones Unificadas hay un momento durante el proyecto donde haremos una “batería” de pruebas donde comprobar los servicios de Skype for Business. Esto se complica a veces, ¿por que?, pues principalmente se complica porque necesitaremos al menos 2 o 3 clientes Skype con diferentes cuentas de usuario para hacer las “típicas” pruebas de IM, llamadas, conferencias, etc… A parte de la complicación para tener los “clientes” Skype simultáneamente, necesitaremos la ayuda de otro compañero para poder hacer las pruebas.
Pues bien, con estos comandos que paso a especificar a continuación, podremos hacer una pruebas básicas de los servicios de Skype que nos dará el resultado de “salud” de la plataforma que estamos montando.
Para realizar las pruebas necesitaremos dos cuentas dadas de alta en Skype for Business, yo siempre aconsejo tener un par de cuentas “Test”, que podremos tener para hacer pruebas, etc.. Esto es algo que pediremos en los Requisitos iniciales para comenzar la instalación a nuestro cliente o los administradores del Directorio Activo. En este caso las cuentas que voy a utilizar son
Login: MRLYNC\SkypeTest1
Sip: SkypeTest1@mrlync.com
Password: *********Login: MRLYNC\SkypeTest2
Sip: SkypeTest1@mrlync.com
Password: *********
Una vez tengamos los datos de nuestras cuentas “Test”, las habilitaremos en nuestro Skype for Business.
Declaramos las variables
Lo primero que haremos será declarar nuestras variables con los datos que queremos usar para las pruebas:
$login1 = “SkypeTest1@mrlync.com”
$sip1 = “SkypeTest1@mrlync.com”
$password1 = “*****” | ConvertTo-SecureString -AsPlainText -Force
$cred1 = New-Object System.Management.Automation.PsCredential($login1, $password1)
$login2 = “SkypeTest2@mrlync.com”
$sip2 = “SkypeTest2@mrlync.com”
$password2 = “******” | ConvertTo-SecureString -AsPlainText -Force
$cred2 = New-Object System.Management.Automation.PsCredential($login2, $password2)
$targetfqdn = “skypepool.mrlync.com”
$authtype = “ClientCertificate”
#$authtype = “Negotiate”
Seguramente os habréis fijado en que el campo “login” lo declaramos igual que el campo “Sip“, con Skype for Business me funcionaron de esta manera los comandos, pero si vamos a ejecutar las pruebas en una plataforma de Lync 2013, seguramente necesitaremos poner el campo login: “MRLYNC\SkypeTest1“
Servicios del Front End Server
Una vez hemos recogido los datos en las variable, usaremos los siguientes comandos para probar los servicios de nuestro Pool o Servidor Front End Estándar.
#Regitration
Write-Host “Registration“
Test-CsRegistration -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Address Book Service
Write-Host “Address Book Service“
Test-CsAddressBookService -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Lis Configuration
Write-Host “Lis Configuration“
Test-CsLisConfiguration -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -UserSipAddress $sip1 -UserCredential:$cred1
#Presence
Write-Host “Presence“
Test-CsPresence -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SubscriberSipAddress “sip:$sip1” -SubscriberCredential $cred1 -PublisherSipAddress “sip:$sip2” -PublisherCredential $cred2
#Lync Web App
Write-Host “Skype Web App“
Test-CsUcwaConference -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -OrganizerSipAddress “sip:$sip1” -OrganizerCredential $cred1 -ParticipantSipAddress “sip:$sip2” -ParticipantCredential $cred2 -verbose
#Skype IM
Write-Host “Skype IM“
Test-CsIm -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$login1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$login2” -ReceiverCredential $cred2
Test-CsGroupIM -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
Test-CsMcxP2PIM -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
#VoIP
Write-Host “VoIP”
Test-CsP2PAv -authentication $authtype -TargetFqdn $targetfqdn -RegistrarPort 5061 -SenderSipAddress “sip:$sip1” -SenderCredential $cred1 -ReceiverSipAddress “sip:$sip2” -ReceiverCredential $cred2
Todos Estos comandos los podemos añadir en un fichero TxT con formato *.ps1 y lanzarlo directamente como un Script desde PowerShell, así lo podremos usar para probar las implantaciones de Skype que vayamos a configurar
Error “Cannot open database “xds” en Lync 2013
Buenas a todos,
Por fin consigo un rato para escribir, iré poniendo todos los post atrasados (lo prometo..), de los problemas y casos curiosos que me he ido encontrando en mis ultimas instalaciones de Microsoft Lync Server 2013 y Skype for Business. A parte continuo en mis ratos libres probando la instalación de Cloud Connector que me resulta un producto de lo mas interesante, al menos para las pequeñas y medianas empresas que han decidido irse a la nube de Microsoft y que quieren migrar sus viejas centralitas a un entorno de comunicaciones unificadas sin tener que desembolsar mucho dinero en una infraestructura de servidores.
Bueno ya tendré mas tiempo de hablar del Cloud Connector, pero en este articulo quiero hablaros de un problema que me he encontrado recientemente en un cliente.
Concretamente necesitábamos conectarnos para realizar una auditoria de la infraestructura que tenia en Lync 2013 y con información obtenida hacerle una propuesta de migración a Skype for Business con integración de Voz y servicios externos a través de un EDGE, pues bien, lo primero en estos casos es o pedirle el fichero de la topología o conectarte con un usuario que te faciliten con los permisos RBAC adecuados para descargarla tu mismo.
En este caso el cliente nos proporcionó un usuario con pertenecía a los siguientes grupos y permisos:
Pero a la hora de conectarme al FrontEnd y descargar la topología, primero recibía este mensajes “Topology Builder could not copy to the topology from the Central Management Store. Cannot read Topology. Verify that the topology data is accessible“
Después volví a forzar la descarga y recibí la siguiente ventana de error:
El texto del error completo decía lo siguiente:
DbConnectionOptions userOptions) at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions) at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection) at System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection) at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) atSystem.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions) at System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry) at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry) at System.Data.SqlClient.SqlConnection.Open() at Microsoft.Rtc.Common.Data.DBCore.PerformSprocContextExecution(SprocContext sprocContext) — End of inner exception stack trace — at Microsoft.Rtc.Management.Store.Sql.XdsSqlConnection.ReadDocItems(ICollection`1 key) at Microsoft.Rtc.Management.ScopeFramework.AnchoredXmlReader.Read(ICollection`1 key) at Microsoft.Rtc.Management.WritableConfig.AnchoredXmlSchemaCache.get_Item(ScopeClass scopeClass) at Microsoft.Rtc.Management.Xds.ManagementConnection.GetAnchoredXmlWrapperFromReader(SchemaId schemaId) at Microsoft.Rtc.Management.Xds.ManagementConnection.ReadTopologyXml(TypedXml& typedXml, AnchoredXml& anchoredXml) at Microsoft.Rtc.Management.Xds.ManagementConnection.ReadTopology(TypedXml& topologyXml, Topology& topology) at Microsoft.Rtc.Management.Xds.XdsCmdlet.<ReadTopology>b__5() at Microsoft.Rtc.Management.Internal.Utilities.DeImpersonator.<>c__DisplayClass1.<Run>b__0() at Microsoft.Rtc.Management.Internal.Utilities.DeImpersonator.Run[T](Boolean dropImpersonation, Func`1 func) atMicrosoft.Rtc.Management.Xds.XdsCmdlet.ReadTopology() — End of inner exception stack trace — at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input, Hashtable errorResults, Boolean enumerate) at System.Management.Automation.Runspaces.LocalPipeline.InvokeHelper() at System.Management.Automation.Runspaces.LocalPipeline.InvokeThreadProc()
Failed
Finished
Tras revisar con el cliente los permisos del usuario, etc…, probé a lanzar el comando Get-CsAdminRole desde la Shell de Lync para ver que estaban bien aplicados los permisos, y recibí lo siguiente “Cannot open database xds requested by the login. The login failed“.
Con este error si pude indagar mas por la red, finalmente para solucionarlo simplemente de la manera mas fácil, arrancar el Topology Builder como Administrador
De esta forma pude descargar de forma correcta la topología, también para ejecutar comandos con el PowerShell utilizando la misma formula.
Seguramente que este post no sea de lo mas atractivo pero os lo cuento porque he visto en algún otro blog que con el mismo error que aconsejaban desinstalar todos los componentes de Lync como “Administrative Tools, Core Components, etc ..” y borrar la carpeta “RTCLOCAL” cosa que un entorno en producción es impensable y si de esta manera al menos podemos ir administrando la plataforma sin tener que provocar tanto trastorno al cliente. A mi de esta manera me sirvió y pude trabajar con normalidad.
Saludos
Problema con la distribucion de usuarios en los “Routing Groups” de Lync 2013
Hoy quiero escribir este artículo acerca de un problema que me encontré hace un año aproximadamente en una migración de un entorno de Lync 2010 a Lync 2013, en concreto el problema se produjo al mover los usuarios desde un entorno al otro.
Tras montar toda la infraestructura de Lync 2013, movimos algunos usuarios de prueba al nuevo pool, después de unos días sin experimentar ningún problema y ver que todo estaba correcto, se decidió mover el resto de usuarios de la infraestructura, unos 5.000 usuarios.
Ese mismo día dejamos programado el Script que migraría todos los usuarios, el Script lanzaba el siguiente comando.
Get-CsUser -Filter {RegistrarPool -eq “lyncpool2010.mrlync.com”} | Move-CsUser -Target “lyncpool2013.mrlync.com”
¿Cuál fue nuestra sorpresa? Al día siguiente mientras los usuarios arrancaban los clientes Lync de sus ordenadores empezamos a notar lentitud en el comportamiento de los mismos, muchos de ellos se quedaban con las funciones limitadas, o no veían presencia, etc… Tras ver los problemas que estaban ocurriendo se decidió volver a mover los usuarios a la versión 2010 y todo volvió a la normalidad.
Parecía claro que a los servidores no le sentaba bien la carga de usuarios, con lo cual procedimos a ir migrando usuarios en grupos de 50 en 50, en el momento que pasamos los 1500 usuarios volvimos a notar los problemas de rendimiento.
Nuestro primer pensamiento fue pensar que era un problema de rendimiento debido arquitectura, esta era la arquitectura que teníamos:
Teníamos un pool de FrontEnds con redundancia geográfica dividido en dos Sites separados físicamente en dos CPD, sabíamos que con 4 FrontEnds teníamos más que suficiente para aguantar la carga de los 5000 usuarios, por ello nos centramos en que el problema pudiera ser la conexión de red entre los dos CPD, pero los tiempos y la calidad de red parecía correcta, por otro lado pensamos en que el fallo podría estar en la conexión de los FrontEnd con el BackEnd y que por alguna razón teníamos un cuello de botella, pero al igual que el caso anterior todo parecía correcto.
Tras las pruebas y descartar que el problema pudiera ser causa del rendimiento de los servidores comenzamos a revisar la configuración y el comportamiento de los servidores de Lync 2013 y sus Routing Groups.
Tras el movimiento de usuarios vimos que todos se metían en el mismo Routing Group cuando la manera correcta seria que se distribuyeran entre varios. Para comprobar los Routing Groups, hicimos consultas a la BBDD RTC Local de los FrontEnd, o el atributo msRTCSIP-UserRoutingGroupID.
Pero casualmente en una de las pruebas que lanzamos fue usando la consola de Administración de Lync y la sorpresa fue ver que los usuarios si se distribuían bien. Tras este comportamiento decidimos probar con la consola de Powershell Remoto contra uno de los servidores y lanzamos el movimiento de usuarios en grupos de 50 en 50, ¿Cuál fue el resultado? Todos los usuarios se movieron de forma correcta y se acabaron los problemas de rendimientos.
En conclusión, el problema era que los primeros script de movimiento de usuarios los hacíamos con el “Lync Server Management Shell” en el propio servidor de Lync.
Y tras utilizar un script que abría una consola de PowerShell remoto en Lync todos los usuarios se distribuían correctamente. ¿Por qué cuando lanzábamos el mismo comando PowerShell desde la consola de PowerShell del servidor no se distribuían bien los usuarios? No he conseguido encontrar la explicación coherente, pero estaba claro que ejecutar el movimiento de usuarios desde el propio PowerShell de Lync nos daba problemas
Desde este problema todas las instalaciones o migraciones de Lync que realizo, el PowerShell remoto se ha convertido en un elemento obligatorio para la administración, aunque sea en un único Servidor Standard Edition.
Para entender más acerca de cómo funcionan los routing groups, os recomiendo la siguiente página:
http://masteringlync.com/2013/10/29/understanding-how-windows-fabric-works/
Con respecto al script de conexión de powershell remoto, encontrareis muchas maneras de hacerlo en internet, cualquiera de ellas os servirá, la que yo utilizo es la siguiente:
En un fichero TXT copiamos el siguiente código
$Cred = Get-Credential “mrlync\lyncadmin”
$Session = New-PSSession -ConnectionURI “https://lyncserver01.mrlync.com/OcsPowershell”-Credential $cred
Import-PSSession $sesión
Este fichero lo renombramos a *.ps1 y lo ejecutamos desde el PowerShell, con este formato nos pedirá clave de “lyncadmin” cada vez que lo ejecutemos. En algunos entornos puede haber mucho movimiento en lo que a las bajas y altas de la compañía respecta, de esta manera podemos dejar un script de PowerShell remoto para que gestione las altas en Lync teniendo la contraseña de administrador en otro fichero encriptado para que se ejecute de forma automática, esta gestión de las altas de usuario en Lync las abordaré en otro artículo en el que explicare como crear un proceso automático de altas en el que incluso se asignen las políticas según el perfil de usuario.
