Archivo de la etiqueta: scripting

Azure Service Bus Topics

Otro servicio que ofrece el Service Bus de Azure, junto con las ‘Queues’, ‘Relays’ e ‘Event Hub’ son los ‘Topics’. A diferencia de las queues, donde sólo hay un receptor, en los topics puede haber múltiples. Esto es así debido al sistema que emplea basado en suscripciones, en el cual un topic  puede tener registradas múltiples suscripciones, estando cada una asociada a un receptor. Dicho receptor solo recibirá los mensajes que hayan sido previamente filtrados por la propia suscripción, lo que permite controlar la información que llega a cada receptor atendiendo, por ejemplo, al perfil del mismo.

Instalación

El proceso de instalación o creación es el mismo que el de una Azure Service Bus Queue. Unicamente tener en cuenta que ‘Messaging Tier’ debe estar establecido como mínimo en ‘Standard’, a diferencia de las queues.
La cadena de conexión se recupera de manera análoga.

Funcionamiento

El funcionamiento es muy similar al visto para las ‘queues’, con lo que todo lo comentado para estas se aplican aquí. De esta manera, este servicio es susceptible de ser empleado con diferentes lenguajes (Java, Node.js, .NET, PHP, Ruby o Python). Para los ejemplos se empleará Python.
La gestión de los topics, así como de las suscripciones pueden hacerse asimismo desde el propio portal.

Un código de ejemplo con las operaciones básicas sería el siguiente:

Conclusiones

Como se ha visto, el funcionamiento es muy similar a las colas de Services Bus, con la diferencia fundamental del número de receptores del mensaje. Esta característica, unida a la posibilidad de establecer filtros en cada suscripción, permite un grado de versatilidad con que la anterior estructura de datos no contaba.

Azure Service Bus Queues

Qué es

El Azure Service Bus Queues (ASBQ), al igual que el servicio Azure Queue Storage (se habló de el en este post) hace uso de una estructura de datos basada en cola para el envío de mensajes. A diferencia de este último, el ASBQ no requiere de una Storage Account para su funcionamiento.

Instalación

La instalación es bastante directa y sencilla. Hay que llevarla a cabo desde el portal clásico (ya que desde el portal nuevo, nos redirigirá al primero).

De este modo, en el portal clásico, hay que situarse en “Service Bus” y pinchar en “Create”. Hecho esto, aparecerá una pantalla donde se indicarán los datos del servicio.

Creando ASB 1

Se dará un namespace, el tipo será ‘messaging’, se elegirá el nivel acorde a las necesidades, así como la región (el rendimiento será mejor cuanto más cerca). Una vez creado el servicio, aparecerá en el panel.

ASB creado

Lo último que quedaría por hacer sería anotar la cadena de conexión que posteriormente se empleará en el entorno de desarrollo elegido. Para ello, hay que pinchar en el icono “Connection information”, proporcionando dicha información.

ASB connection info

Funcionamiento

Este servicio puede utilizarse mediante diversos lenguajes (Java, Node.js, .NET, etc), a modo de ejemplo se hará en Python.
La instalación de Python y su correspondiente SDK no presenta complicaciones, habiendo versión para Windows, Linux y MacOS.
Una vez instalado el SDK, ya se está en disposición de crear y eliminar colas, así como introducir mensajes y extraerlos. Cabe señalar que en el propio portal clásico se pueden crear y eliminar colas.

Un código de ejemplo en Python sería el siguiente:

Conclusiones

La modalidad que se ha visto aquí es la más simple (paso de mensajes), pero también presenta otras más elaboradas. Comparándola con la Azure Storage Queue, su utilización es si cabe más sencilla y directa, pero no tan potente y versátil. Todo depende en realidad del uso que se le dé.

Gestión de Azure Storage con Azure CLI

Siguiendo un poco la estela de este otro post, me gustaría hablar del tratamiento que ofrece Azure CLI respecto al almacenamiento o Storage.

Con el conjunto de comandos que Azure CLI destina a este apartado, se podrá llevar a cabo una gestión de los diferentes elementos de almacenamiento, los cuales serían los siguientes:

  • Blobs: datos no estructurados, por ejemplo archivos multimedia.
  • Colas: almacenamiento fiable de mensajes.
  • Tablas: datos NoSQL estructurados.
  • Ficheros: compartición de archivos y datos comunes, basado en el protocolo SMB.

Al igual que cuando se introdujo el Azure CLI en el anterior post, la ayuda continua todos los comandos relativos al almacenamiento. Para mostrar dicha ayuda especificando los comandos relativos al almacenamiento, bastaría con escribir:

Azure CLI storage help

Puesto que es bastante extensa, puede ser conveniente refinar más especificando con más detalle el asunto. Así, si por ejemplo se quiere mostrar la ayuda solo referente al elemento blob, entonces:

Hay dos variables importantes que hay que establecer para poder acceder a los elementos: AZURE_STORAGE_ACCOUNT y AZURE_STORAGE_ACCESS_KEY. Esta asignación se puede realizar directamente en un script o en el bash:

La clave de la cuenta (storage access key) se puede descargar desde el portal de Azure. Una vez conectados, para ver las cuentas de almacenamiento de la subscripción seleccionada basta con indicar:

con lo que mostrará todas las cuentas de almacenamiento con que cuenta esa subscripción.

Azure CLI storage account list

Para no ser demasiado exhaustivo, y puesto que la ayuda es autodescriptiva, pondré como ejemplo a los blobs y algunas de sus operaciones.

Los blobs se almacenan en contenedores. La instrucción que crea un contenedor es la siguiente:

Si se quieren ver todos los blobs que hay en un contenedor determinado, la consulta sería la siguiente:

Azure CLI blob list

Por otro lado, para descargar un blob o subirlo, las órdenes respectivas serían la siguientes:

O si se quieren copiar blobs de diferentes cuentas de almacenamiento de forma asíncrona:

y para comprobar el estado de la copia:

Finalmente, para eliminar un blob:

Con respecto a los comandos relativos a los ficheros, tablas y colas, es posible realizar las típicas operaciones sobre estos tipos de elementos (crear, eliminar, mostrar). En la ayuda de Azure CLI se muestra con detalle dichas operaciones, aparte de otras como la gestión de la políticas de acceso de ficheros, tablas y colas, por lo que no es necesario repetirlas.

Y esto es todo por ahora. Espero haber contribuido un poco al conocimiento de esta versátil herramienta.

Administración de servicios de Azure mediante CLI

Hoy voy a a hablar de la interfaz de línea de comandos de Azure, o CLI de Azure. Dicha CLI provee al usuario de una serie de comandos de código abierto basados en shell que permiten crear y administrar recursos de Azure. Esto supone la gestión de servicios y aplicaciones utilizando scripts desde la línea de comandos.

La CLI de Azure está escrita en javascript y necesita de Node.js, tecnología que permite trabajar con javascript desde el lado del servidor, empleando un modelo asíncrono y controlado por eventos.

Cabe destacar que una de las cosas hacen interesante a esta herramienta es su carácter multiplataforma. De esta forma, existen instaladores para cada una de las tres plataformas soportadas:

  • Windows
  • Mac
  • Linux

Otras dos métodos de instalación serían las siguientes:

  • Instalación previa de Node.js y npm, para posteriormente instalar Azure CLI.
  • Ejecución de la CLI de Azure como contenedor de Docker. Consistiría simplemente en ejecutar en un host de Docker ‘docker run -it microsoft/azure-cli’.

Ahondando más en la segunda forma de instalación y tomando como referencia para este post la versión para Linux, (en concreto, Xubuntu 14.04), la misma vendría dada con la instalación de tres paquetes:

Instalados estos tres paquetes, Azure CLI ya estará disponible en el sistema.
Por lo tanto, desde una ventana de consola, escribiendo ‘azure help’ mostrará información de ayuda diversa:

azure help

  • Versión de la herramienta. En este caso, la versión es 0.9.12
  • Comandos disponibles, agrupados según temática. Así, por ejemplo, para ver todos los comandos relacionados con la gestión de máquinas virtuales y las opciones aplicables, habría que indicarlo mediante el siguiente comando:

azure help vm

  • Modo de implementación seleccionado actualmente. Azure cuenta con dos modelos de implementación distintos para crear y gestionar recursos: el Administrador de Recursos (‘Azure Resource Management‘) y el Administrador de Servicios (‘Azure Service Management‘) o módo clásico. Por defecto, está seleccionado el modo clásico. Para cambiar de un modo a otro, se emplea el comando ‘azure config mode <arm|asm>’. Ambos modos son excluyentes entre sí, de manera que los recursos creados en un modo no se pueden administrar desde el otro. Entonces, si se quiere cambiar al modo de Administrador de Recursos, el comando sería:

El primer paso que hay que llevar a cabo para poder gestionar los recursos es poder acceder a los mismos. Para ello, se cuenta con tres formas de acceder a una cuenta y sus subscripciones:

  1. Accediendo a una subscripción, utilizando para ello el Directorio Activo (AD) o una Cuenta Microsoft (Microsoft Account).
  2. Mediante un archivo ‘publishsettings‘ de una subscripción descargado del portal de Azure.
  3. Mediante un certificado.

Tomando como ejemplo la segunda forma, habría que descargar el archivo publishsettings con un navegador e importarlo. Para llevar a cabo esto, se ejecutaría lo siguiente:

Con lo que se abriría la página del navegador (si no lo hiciera, basta con seguir el enlace que se indica), se introducirían las credenciales de la cuenta y se descargaría el archivo. A continuación, se importaría con el comando:

Una vez importado, el archivo se puede eliminar. Si hay otros archivos publishsettings que importar, los pasos a seguir son los mismos. Para ver todas las subscripciones que han sido importadas:

donde se mostrarán el nombre de la subscripción, su id, si está o no actualmente seleccionada, y el estado.

Para seleccionar una subscripción determinada y así poder gestionarla:

Y a partir de este momento, ya se pueden administrar los recursos de esa subscripción seleccionada. Por ejemplo, para ver una lista de las máquinas virtuales:

O se quiere crear un regla de firewall para una base de datos:

Por supuesto, todos los comandos de Azure CLI son susceptibles de ser incluidos en un script, con lo cual posibilita la automatización de ciertas tareas que pueden resultar pesadas, sobre todo si no se tiene acceso a Powershell.

Y esto es todo por ahora. Espero que este post haya servido para, por lo menos, dar una rápida visión de esta interesante herramienta.

Comandos útiles en Powershell

Me gustaría hablar en este post de algunos comandos que, ya sea por necesidad o simplemente por curiosidad, uno se va encontrando por el camino. Son los siguientes:

Envío de mensajes de correo con archivos adjuntos (solo para Powershell v5)
Una funcionalidad interesante es la posibilidad de que un script pueda enviar un mensaje de correo electrónico con uno o más archivos adjuntos.
Cabe destacar que este cmdlet solo está disponible para Powershell v5. Los parámetros básicos que hay que indicarle son bastante intuitivos:

 

Creación de un trabajo o job en el planificador de tareas
Si bien esto se puede realizar directamente con el interfaz gráfico del propio planificador de tareas, la posibilidad de creación o eliminación dinámica de un job mediante Powershell puede ser bastante útil, sobre todo en el caso de integrarla en un script.
La ejecución de un job requiere de cuatro elementos principales:
a) El elemento que se va a lanzar, que puede ser un ejecutable, un batch o un script.
b) Los argumentos que empleará dicho elemento, separados por comas.
c) El disparador o ‘trigger’, evento que actúa de detonante en la ejecución del job. Por ejemplo, una hora concreta de un dia determinado.
d) Las opciones adicionales del propio job.

Algo a señalar es que, si hay que eliminar un job existente y éste ha sido creado con el anterior comando, es recomendable hacerlo con este otro:

ya que si bien es posible hacerlo con el interfaz gráfico del planificador de tareas, posteriormente al utilizar comandos Powershell relacionados con esto, por ejemplo Get-ScheduledJob, se puede producir un mensaje de error.

Alerta sonora
Un complemento a una alerta visual (como un mensaje o aviso), puede ser la emisión de algún tipo de sonido. Esto puede ser interesante a la hora de introducir algún tipo de alerta sonora para indicar algún evento relevante, como por ejemplo que se ha encontrado algo o la misma finalización de un script.

En su forma más simple, se puede indicar el código de control correspondiente a la alerta, mediante el siguiente comando:

Esto puede servir para indicar un tipo de evento, pero es bastante limitado. Sin embargo, es posible reproducir sonidos del sistema o incluso archivos con extensión .wav. No hace falta decir que esta última forma es que la que gana en versatilidad al resto

 

Uso de un puerto serie
Aunque de por sí el puerto serie en sí puede estar en desuso, sin embargo nunca ha dejado de utilizarse. Así, por ejemplo, se emplea para comunicarse con microcontroladores diversos. La conexión se puede llevar a cabo mediante una conexión física y empleando, al menos, las tres señales mínimas (TxD, RxD, GND) sin control de flujo, o incluso una conexión inalámbrica empleando Bluetooth. Bluetooth suporta múltiples perfiles, y uno de ellos es el SPP (Serial Profile Port), el cual a efectos prácticos lo hace comportarse como un puerto serie estándar.

 

Y esto es todo por ahora. Espero que alguien pueda sacar provecho de alguno de estos cmdlet para dotar de más funcionalidad a algún script de Powershell.

Powershell basics: Las tuberias

¡Hola a todos!

En ocasiones previas habéis visto en este blog el uso de PowerShell (que también se suele abreviar como PS) para realizar tareas administrativas. Y la verdad es que como herramienta de administración de sistemas Windows es insuperable. Así que… ¿Por qué no hablar sobre algunos de los conceptos más importantes de PowerShell?

La base son los objetos

Ante todo, lo más importante a la hora de trabajar con PowerShell es entender los datos con los que trabaja. A diferencia de otros sistemas de scripting, que nos devuelven datos en forma de texto, en PowerShell lo que se nos devuelve son objetos. Objetos que en la consola tienen una representación textual, pero que pueden manipularse de formas mucho más complejas.

Sin ir más lejos, cuando escribimos el comando “ls” o “dir”, en realidad estamos ejecutando el cmdlet “get-childitem”, el cual nos devuelve una lista de archivos. Ahora bien, como ya hemos dicho, lo que PS nos devuelve son objetos.

ls ls_0

Esto lo podemos comprobar, sin ir más lejos, si deseamos solicitar un elemento concreto de la lista de objetos que ls nos devuelve. Pero aún se puede ir más lejos. PowerShell nos proporciona un cmdlet que nos permite analizar la estructura de un objeto. Este cmdlet se llama “Get-Member”, y nos devuelve información completa sobre métodos y propiedades del objeto que le hemos pasado como parámetro. En este caso, los métodos son funciones que el objeto puede ejecutar, mientras que las propiedades son datos (objetos) que se pueden consultar.

ls_getmember

En este caso, se puede ver cómo PS extrae la información del objeto de tipo “DirectoryInfo”, y muestra diversos métodos que se pueden usar para manipular o extraer más información de dicho objeto. Dependiendo del tipo de objetos con los que estemos trabajando, utilizar el cmdlet get-member va a ser muy útil para inspeccionar los resultados, y obtener no sólo información sobre la estructura del objeto, sino acceder a funciones que permiten al objeto realizar acciones más avanzadas. ¿Cómo se ha conseguido comunicar el cmdlet “ls” con el “get-member”? Pasándole información por una tubería.

Tuberías (Pipeline)

En la mayoría de sistemas de scripting se incluye una funcionalidad conocida como “tubería” y como se puede imaginar, el nombre de esta característica es una metáfora del funcionamiento de la misma. ¿Para qué se usa una tubería? Para conectar un origen de datos a un destino que los consuma. En el caso de PowerShell, una tubería permite hacer un streaming de objetos desde el cmdlet que los está produciendo (como resultado) a otro cmdlet que los va a consumir (para procesar los objetos, transformarlos, ordenarlos, etc).

Entre las características más vitales de las tuberías, destacaría las siguientes:

  • Las tuberías conectan dos cmdlets. Esto no impide que un cmdlet que está recibiendo datos desde una tubería pueda enviar los resultados a través de otra. Es decir, se pueden encadenar tuberías para conectar múltiples cmdlets sin ningún tipo de limitaciones.
  • El streaming de objetos a través de las tuberías se realiza uno a uno. Esto es importantísimo en términos de rendimiento, y en demasiadas ocasiones se suele pasar por alto. Se comenta con mayor detalle en la siguiente sección.

¿Cómo se usan las tuberías?

Para interconectar la salida de un cmdlet con la entrada de otro se usa el carácter especial “|”. Éste carácter indica a PowerShell que debe enviar los objetos de respuesta del cmdlet a la izquierda del mismo hacia el cmdlet a la derecha. Ya se ha visto un ejemplo práctico de funcionamiento de la tubería cuando se presentó el cmdlet “Get-Member”, el cual, como ya se indicó, toma como entrada objetos.

Así pues, un ejemplo de tubería muy sencilla sería “Get-ChildItem | select-Object * | Out-Gridview”. Esta tubería devuelve una ventana (Out-Gridview),8con todos los atributos de los objetos (Select-Object *) devueltos por el cmldet Get-ChildItem.

outGridview

Consideraciones de rendimiento

A la hora de manipular datos a  escala masiva, siempre va a aparecer la siguiente disyuntiva: Consumo de RAM vs Consumo de Tiempo.

Usualmente, la forma más rápida de procesar datos consiste en almacenar el resultado de la ejecución del cmdlet en un array, y procesarlo. Pero esto significa almacenar toda la información devuelta en memoria. En el caso de, por ejemplo, consultar información de un Directorio Activo con decenas o cientos de miles de objetos, la consulta cargará todos los objetos en memoria. Y esto, en máquinas con recursos limitados, como mínimo va a provocar la ralentización de todos los servicios de la misma. Incluyendo la propia ejecución del script.

Por otro lado, en vez de cachear toda la información en RAM, se puede usar una técnica diferente para procesar esa enorme cantidad de información. Y ya se ha hablado de ella en este artículo. Las tuberías pasan los objetos devueltos  de uno en uno. Esto significa que se pueden procesar las decenas o cientos de miles de objetos individualmente, sin colapsar la memoria del sistema. Como contrapartida, el tiempo de ejecución del script suele aumentar drásticamente, debido al overhead provocado por el movimiento de los objetos entre cmdlets.

En ocasiones, no va a ser posible elegir entre un tipo de optimización u otro. Por ejemplo, si el cmdlet/función que suministra los resultados incluye algún mecanismo de caducidad por el que transcurrido cierto tiempo desde la ejecución del mismo, se considera que los resultados son viejos y por tanto no válidos. Esto puede suceder en funciones de búsqueda o consulta. En este caso, habría que acudir obligatoriamente al mecanismo de cacheado en RAM, ya que los resultados cacheados no van a “caducar” durante la ejecución del script.

 

¡Y esto es todo de momento! Esperamos que con estos consejos sobre el uso de tuberías y cómo afectan al consumo de recursos del sistema podáis escribir scripts más eficaces, siempre adaptándolos a las necesidades de cada momento.

 

Enlaces de Interés:

http://blogs.technet.com/b/heyscriptingguy/archive/2014/06/30/back-to-the-basics-part-1-learning-about-the-powershell-pipeline.aspx

PowerShell Utilities Series: DMCredential o cómo no escribir credenciales en PowerShell

Como administradores de sistemas que somos, si nos encontramos bajo Windows es evidente que PowerShell es una de nuestras más potentes y versátiles herramientas de trabajo. Gracias a sus capacidades de Remoting, con PowerShell podemos conectarnos a otros sistemas para llevar a cabo tareas de mantenimiento y administración en ellos. En mi día a día no es raro tener que entrar varias veces a Office 365, Exchange Online y controladores de dominio desde PowerShell. Sin embargo, esto requiere que nos autentiquemos.

Cualquier administrador de sistemas que use PowerShell estará más que familiarizado con esta línea de comando:

De forma que tendremos que escribir nuestro nombre de usuario y contraseña que se almacenará en la variable $cred, de tipo System.Management.Automation.PSCredential.

En este otro artículo Antonio ya nos contó que podemos automatizar el proceso de inicio de sesión en otra máquina a través de PowerShell, escritura de credenciales incluidas; ya que podemos almacenarlas cifradas en nuestro script. Si somos capaces de hacer esto en un script que conecta con Exchange, ¿no podríamos hacerlo también de forma más genérica y utilizarlo para conectarnos a cualquier sistema? David Moravec, escritor de la PowerShell Magazine llegó a conclusiones similares allá por 2012.

David creó un sencillo módulo que nos permite almacenar las credenciales que necesitemos en un archivo, estando estas perfectamente cifradas de igual forma que las de Antonio. El código del módulo puede verse á continuación:

Básicamente se compone de tres cmdlets:

  • New-DMCredential. Crea un nuevo archivo cifrado que contiene las credenciales que especifiquemos. Por defecto estas se almacenarán en $env:userprofile.
  • Get-DMCrednetial. Lee un archivo que contenga credenciales almacenadas con New-DMCredential y las carga en una variable global. Para que este cmdlet funcione correctamente la máquina sobre la que se ejecuta New-DMCredential y Get-DMCredential debe ser la misma.
  • Show-DMCredential. Muestra la contraseña cifrada contenida en un archivo en texto plano. De igual forma que Get-DMCredential, es necesario que las credenciales hayan sido almacenadas en la misma máquinas desde la que son leídas.

De esta forma, crear un nuevo archivo es tan sencillo como:

Este cmdlet nos pedirá que introduzcamos unas credenciales y acto seguido generará un nuevo archivo llamado o365cred que las contiene. Dichas credenciales pueden ser recuperadas así:

Esto creará la variable $global:o365cred y almacenará las credenciales en ella. Fijaos que el nombre del archivo y el de la variable coinciden y que el cmdlet en sí no devuelve nada salvo por el parámetro Alias. Como la variable es global, la tenemos disponible para usar en cualquier ventana o runspace del sistema.

Útil y sencillo de usar ¿verdad? Pero aquí no acaba la cosa. Viendo el bien trabajo que Moravec hizo, se me ocurrió darle una vuelta de tuerca más y hacer que esta variable con credenciales se cargase en memoria cada vez que hacía el simple gesto de abrir una consola de PowerShell, al igual que ya hacía con el módulo de ls a color.

Conseguir esto es una cuestión tan sencilla como agregar el contenido adecuado a nuestro archivo de $profile. A mí me bastó con estas líneas:

De esta forma cuando abra una ventana de PowerShell:

pscred

Mis credenciales se encontrarán automáticamente disponibles en la variable $global:pscred y no tendré que escribirlas. Ni que decir tiene que en este caso nuestro equipo debe bloquearse siempre (Windows + L) siempre que lo dejemos desatendido por razones obvias.

¡Happy Powershelling!

Enlace relacionado: #PSTip Storing of credentials

Conexión remota con PowerShell a Exchange Server 2010/2013

¡Hola a todos!

Hoy hablaremos de PowerShell, conexiones remotas a Exchange, y cómo podemos automatizar estas conexiones para usar en scripts que no requieren intervención por parte del usuario. ¿Suena interesante? Pues sigamos adelante!

Primero veamos cómo podemos conectarnos con PowerShell a un sistema remoto. En este caso, vamos a conectar con un servidor Exchange ficticio llamado “mi.sitio.es”.

Muy fácil, tres líneas de código, introducimos nuestras credenciales en un diálogo pop-up, y tenemos una shell conectada al servidor Exchange, para ejecutar comandos como Get-Mailbox o Get-DistributionGroup. Éste es el procedimiento estándar para conectar con Exchange, y se puede encontrar en miles de artículos por Internet. El problema, es que requiere una sesión interactiva, porque nos pide las credenciales en un diálogo.

Como esto es demasiado fácil, y en ocasiones molesto (especialmente la parte de escribir nuestras credenciales), vamos a escalar la dificultad, y automatizar el proceso para que no haga falta introducir las credenciales en una sesión interactiva. Esto se consigue creando un objeto del tipo PSCredential.

Obviamente, esto nos plantea un dilema práctico. Por muy compleja y segura que sea la password de nuestra cuenta (MiP4ssw0rdEsMuy.Segur0), si la pegamos como texto plano en un script no va a servir de nada. Especialmente si más de una persona tiene acceso al lugar donde el script esté guardado.

Esto se puede solucionar guardando la contraseña en un contenedor especial llamado “SecureString”, que se cifra con nuestras credenciales de Windows. En la práctica, esto significa que, el script quedaría entonces ligado a nuestra cuenta en una máquina en concreto. Si cambiamos de máquina o de usuario, tenemos que generar una nueva representación del SecureString. Útil para maximizar la seguridad del despliegue de un script, aunque es importante tener en cuenta que la seguridad que ofrece no es de nivel militar, pero sí es lo suficientemente buena para el “usuario estándar”.

Ahora bien, ¿cómo podemos generar un SecureString para almacenar nuestra contraseña, de forma segura y fiable? Podemos usar una función como la siguiente:

Nótese que esta función nos va a convertir cualquier cadena que le pasemos a un securestring, ya sea pasando el texto como un parámetro (mala idea), o leyendo el texto con el Read-Host –AsSecureString. Obviamente, podemos usar la función tal cual, “Copipegándola” en la shell, y ya podemos usarla con total normalidad.

El resultado final nos deja con un script de conexión tal como el siguiente:

Estas tres líneas las podemos incluir en un script .ps1 de PowerShell, y a continuación usar todos los cmdlets de Exchange que necesitemos para nuestros propósitos.

 

¡Y eso es todo por el momento! Espero que esta técnica os sea provechosa para aumentar la productividad y, sobre todo, happy scripting!