PowerShell, Office 365, sintaxis |El poder de PowerShell | Parte 1/3 .com

Comencemos con un hecho básico sobre mí: no soy programador (y probablemente nunca lo seré). Si pudiera aprender a usar PowerShell, ¡todos podrían hacerlo! Al principio, PowerShell me parece una herramienta “negra” innecesaria y complicada, e hice todo lo posible para evitarla.

El poder de PowerShell | Serie de artículos

La serie de artículos Power of PowerShell, que incluye los tres artículos siguientes:

• El poder de PowerShell | Parte 1/3 (este artículo)
• El poder de PowerShell | Parte 2/3
• El poder de PowerShell | Parte 3/3

Pensé: “¿Por qué debería usar PowerShell, en lugar de la amigable GUI (interfaz gráfica de usuario) de Microsoft?” Con el tiempo, me di cuenta de las importantes ventajas de utilizar PowerShell y, a medida que pasa el tiempo, empiezo a sentirme cómodo con el entorno de PowerShell.

Este artículo trata sobre: conocer los conceptos básicos de PowerShell en el entorno Office 365.

Si siente que quiere comprender mejor el concepto y la lógica de PowerShell y está dispuesto a dedicar más de 2 minutos a leer la información, creo que podría disfrutar de la capacidad de comprender este entorno en lugar de copiar y pegue comandos de PowerShell “misteriosos”.

¿Qué es “PowerShell”?

Hay muchas descripciones "formales" para PowerShell, pero hagámoslo simple: PowerShell, como su nombre lo indica, es un lenguaje "Shell" y Script. La característica principal de PowerShell frente a otros lenguajes de secuencias de comandos es que PowerShell es un lenguaje de secuencias de comandos muy amigable y "similar al humano".

PowerShell nos permite utilizar comandos (cmdlets) muy simples y potentes, y al mismo tiempo PowerShell podría servirnos para escribir scripts muy complicados (esta es la parte más cercana al “Programador”).

En la actualidad, la mayoría de los sistemas operativos y productos de Microsoft se pueden administrar mediante PowerShell, y algunos de los productos, como el servidor Exchange, se basan exclusivamente en PowerShell.

Por ejemplo, la interfaz GUI de Exchange que utilizamos es simplemente una "interfaz amigable". Cada opción que utilizamos en la interfaz GUI se traduce y ejecuta como un comando de PowerShell.

El "poder" de PowerShell

Hay muchas ventajas de usar PowerShell:

• Operaciones masivas: el significado del término "operaciones masivas" es la capacidad de ejecutar un comando de PowerShell para administrar un "grupo de objetos".
  Por ejemplo, necesitamos asignar licencias a todos los usuarios de Office 365 que no tienen licencias. En caso de que nuestra organización incluya 10 empleados, esta tarea se puede implementar muy fácilmente utilizando la Interfaz Web del Portal de Office 365. ¿Pero qué escenario en el que necesitamos asignar la licencia a 1.500 usuarios?
  Por supuesto, podemos hacerlo manualmente, pero será una tarea muy agotadora.
  Al usar PowerShell, podemos usar un comando que busca todos los usuarios que no tienen licencias y asigna la licencia requerida para estos usuarios.
• Exportar información: la interfaz web de Office 365 no incluye la opción de crear informes o exportar información.
  Al usar PowerShell, podemos crear informes y exportar los datos necesarios sobre los diferentes componentes, como una lista de usuarios con licencias asignadas, información sobre Tamaño del buzón, lista de usuarios que incluye información como números de teléfono, departamento y mucho más.
• Sin intervención del usuario: al utilizar PowerShell, podemos ejecutar todas las tareas de administración necesarias para los usuarios de Office 365 en "segundo plano", sin necesidad de involucrar a los usuarios en este proceso.
  Por ejemplo: cuando necesitamos asignar permisos al usuario Buzón de correo o calendario de usuario, no es necesario iniciar sesión en el perfil de usuario de Outlook ni controlar remotamente el escritorio del usuario.
  En su lugar, podemos ejecutar la tarea de administración requerida mediante el uso de comandos de PowerShell.
• Limitación de la interfaz GUI: la interfaz web de Office 365 nos permite realizar muchas tareas administrativas. Algunas de las tareas administrativas solo se pueden realizar mediante PowerShell. Por ejemplo: podemos usar la interfaz web de Office 365 para restablecer la contraseña del usuario y crear una contraseña temporal para el usuario, pero la interfaz basada en web no incluye la opción para : establecer una contraseña predefinida para el usuario o cambiar la política de contraseña de caducidad predeterminada (esta tarea solo se puede implementar mediante PowerShell).
• Automatice las tareas administrativas: muchas veces, necesitamos ejecutar tareas administrativas de forma programada.
  Por ejemplo: cree un informe semanal que incluya información sobre nuevos usuarios, nuevas asignaciones de licencias, etc. mediante el uso de una combinación de scripts de PowerShell y el Administrador de tareas integrado de Windows, podemos automatizar estas tareas administrativas.

PowerShell remoto - Office 365

Cuando utilizamos PowerShell para administrar infraestructuras de Office 365, utilizamos un método que se describe como PowerShell remoto. Para poder ejecutar los comandos requeridos de PowerShell, primero debemos crear una sesión remota que incluya un proceso de autenticación en el Host Remoto (infraestructura de Office 365 y Exchange Online).

Usamos Remote PowerShell para administrar 4 infraestructuras diferentes:

1. Office 365: cuando utilizamos el término "Office 365", el significado es: la parte que sirve como "sobre" para todos los demás servicios de Office 365. Esta parte incluye componentes tales como: objetos de usuario y grupo de seguridad (Windows Azure Active Directory), administración de nombres de dominio, migración de correo, SSO (inicio de sesión único), administración de licencias y más.
2. Exchange Online: esta parte incluye la gestión de los servicios de correo. Por ejemplo: agregar o eliminar una dirección de correo electrónico, establecer el tamaño del buzón, asignar una política al buzón, etc.
3. SharePoint en línea
4. Lync en línea

Cada una de las infraestructuras de Office 365 requiere una "sesión remota dedicada de PowerShell" y, para cada uno de estos entornos, necesitamos usar un conjunto diferente de cmdlets (revisaremos el término cmdlets más adelante) para crear la sesión remota.

PowerShell “Clase de objetos”

PowerShell se trata de: administrar objetos.
En el entorno de Office 365, hay docenas de objetos. Un ejemplo de "objeto" podría ser: usuario, buzón, grupo, dominio, etc.

Clase/tipo de objeto e instancia de objeto

El término "Clase/Tipo de objeto" describe una "entidad" con propiedades específicas. Cuando creamos un "nuevo objeto", como por ejemplo: nuevo Usuario, en realidad estamos creando una instancia de objeto.

La “nueva instancia” (por ejemplo, un nuevo usuario), hereda la estructura de la clase de objeto y (la mayoría de las veces) tiene una identidad única.

Por ejemplo: cuando creamos un nuevo Usuario llamado “John”, el nuevo usuario se considera como “instancia” de la clase de objeto “Usuario”. El nuevo usuario (John) tendrá todos los "campos de propiedades" que fueron heredados de la clase de objeto Usuario.

Nota: La mayoría de las veces, no utilizamos el término "instancia" cuando hablamos de un objeto, sino que simplemente utilizamos el término "objeto". "

Clase de objeto y derivados de objeto

Parte de la "clase de objeto" sirve como "objeto raíz" que tiene derivados.

Por ejemplo, la “Clase de objeto de grupo” tiene los siguientes derivados:

El objeto de grupo podría ser: un grupo de seguridad o un grupo de distribución, y un grupo de distribución podría ser un "grupo de distribución estándar" o un grupo de distribución dinámico.

Cuando creamos un nuevo "Grupo de distribución", la nueva instancia hereda la estructura y las propiedades de la "Clase de objeto de grupo" + una propiedad específica, que son únicas para la clase de objeto "Grupo de distribución", como por ejemplo: Dirección de correo electrónico y aprobación de mensajes. .

Propiedades del objeto

La definición básica de clase de objeto podría ser: una colección o un conjunto predefinido de propiedades.
El concepto de objetos y las propiedades de los objetos se “toman prestados” del mundo real.

Por ejemplo, cada uno de nosotros (un ser humano o una persona) tiene propiedades como: altura, color de ojos, peso, ciudadanía, etc.

Cada una de las clases de Objeto, como el objeto Usuario o el objeto Buzón, tiene un conjunto particular de propiedades que son "relevantes" para la clase de objeto.

Por ejemplo, las propiedades del objeto Usuario podrían ser: detalles generales como: Título, Departamento, Ciudad, Número de teléfono u otras propiedades como: Función de usuario (usuario estándar, Administrador global), licencia (el usuario tiene o no una licencia), Buzón (¿el usuario tiene un Buzón “adjunto” a su cuenta de usuario), etc.?

Nota: Mailbox podría considerarse un "Objeto", pero Mailbox también se considera una "propiedad" de un Usuario porque el objeto Mailbox no tiene una "vida propia". Un objeto Buzón debe estar “adjunto” al objeto Usuario.

Un ejemplo adicional es: Propiedades del buzón.

Las propiedades del objeto Buzón podrían ser el tamaño del buzón, la dirección de correo electrónico que se "adjuntó" al buzón, el archivo personal, etc.

Las "Propiedades del buzón" adicionales podrían ser una política adjunta al buzón.

Por ejemplo: política de retención (una política que se relaciona con la eliminación o el traslado para archivar elementos de correo cuando los elementos de correo alcanzan una "antigüedad" específica).

En caso de que queramos mostrar una lista de las propiedades que “pertenecen” a una clase de objeto específica, podemos usar los cmdlets de PowerShell:

Get-Object Class | Get-Member

Valores de propiedades del objeto

Como se mencionó, podemos describir un objeto como una colección de propiedades. Cuando creamos un nuevo objeto (o si queremos ser más precisos, instancia de objeto), algunas de las propiedades “deben” tener valores (requisito obligatorio).

Por ejemplo: el objeto de usuario de Office 365 debe tener un nombre de alias y un nombre principal de usuario. Otras propiedades como: Contraseña nunca caduca se configuran automáticamente con el valor “Verdadero” y propiedades adicionales como: Título, Departamento, ciudad y más, no tienen un valor predefinido (o podemos decir: “Propiedad vacía”).

Estos “valores”, podrían ser establecidos por el Administrador que gestiona la cuenta del usuario.

Objetos de referencia

La primera parte de cada “frase de PowerShell” o comando de PowerShell comienza con una referencia a una clase de objeto o una instancia de objeto. Repasemos la opción de "Hacer referencia a objetos" demostrando la tarea administrativa básica de la gestión del buzón.

Cuando necesitamos administrar buzones de correo alojados en el servidor de Exchange Online, podemos definir 3 opciones para “referenciar” objeto/s:

1. Referencia a una instancia particular de clases de objetos
   Por ejemplo, queremos obtener información sobre el buzón "John".
2. Clase de objetos de referencia.
   Podemos usar un comando de PowerShell que muestra información sobre - toda la clase de objetos Mailbox
3. Referencia a Subconjunto/Grupo de objetos
   En un entorno Exchange, tenemos un tipo diferente de “Buzones de correo”, como Buzón de usuario, Buzón de recursos, Buzón compartido, Buzón de búsqueda, etc. Muchas veces queremos hacer referencia solo a un “Subconjunto” o un “Subgrupo” de objetos.

Por ejemplo: queremos mostrar solo los Buzones que “pertenecen” al grupo de “Buzones de Usuario”.

Objeto “Identidades”

Cuando queramos hacer referencia a una "instancia" de clase de objeto, necesitaremos especificar la identidad del objeto. Este concepto de: "identidades", es muy similar al "mundo real".

Cada uno de nosotros tiene un par de identidades, como: nombre, nombre completo, "apodo" o número social. De la misma manera, cuando necesitamos administrar instancias específicas de un objeto como "Cuenta de usuario de John", debemos especificar la identidad de esta instancia (John).

Nota: La mayoría de las "identidades" se consideran "únicas", es decir, ningún otro objeto (Usuario) podría tener la misma identidad.

Objeto de usuario "Identidades"

Para fines de demostración, revisemos las opciones para las "Identidades de objetos de usuario". La siguiente lista incluye una descripción de las diferentes identidades de objetos de usuario que podemos usar cuando necesitamos hacer referencia a una instancia específica de la clase de objeto (un usuario específico como "John".

• Nombre para mostrar del usuario: esta identidad se compone del nombre del usuario y del último nombre del usuario. El identificador "Nombre para mostrar" no es un identificador único. El significado es que podemos tener 2 (o más) usuarios con el mismo nombre para mostrar.
  Cuando queremos hacer referencia a un objeto usando el nombre para mostrar del objeto, debemos usar comillas porque el nombre para mostrar incluye un espacio (el espacio entre nombre y apellido). Dado que la identidad del usuario de "Nombre para mostrar" no es única, se recomienda evitar esta opción cuando queremos hacer referencia a un usuario en particular.
• Usuario UPN: (UPN significa nombre principal de usuario). En Office 365, el usuario UPN=nombre de inicio de sesión del usuario. El UPN de usuario es un identificador único (solo un usuario puede tener un UPN específico). El UPN se compone del nombre de alias del usuario y el dominio del inquilino de Office o el nombre del “dominio personalizado” (el nombre de dominio personalizado).
  De forma predeterminada, el UPN del usuario también es la dirección de correo electrónico principal del usuario (este valor predeterminado puede solo se puede cambiar mediante el comando PowerShell).
• Alias de usuario: el nombre de alias de usuario creado de acuerdo con la “Política de nombres de alias” de la organización.
  Por ejemplo, una política de nombres de alias estándar podría ser el nombre del usuario y los primeros caracteres del nombre de usuario de la familia. El nombre de alias del usuario no es un identificador único. Cuando queremos hacer referencia al buzón de un usuario, es más fácil usar el nombre de alias del usuario en lugar de usar el UPN de usuario "largo".
• Dirección de correo electrónico del usuario: la dirección de correo electrónico del usuario es un identificador único. Cuando un usuario de Office 365 tiene un buzón de correo, el usuario debe tener al menos una dirección de correo electrónico que se describa como dirección de correo electrónico principal. Como se mencionó, de forma predeterminada, la dirección de correo electrónico principal del usuario es idéntica a la UPN del usuario.
• GUID (ID de objeto): el ID del objeto es un identificador único. Este identificador no se utiliza con mucha frecuencia. La única vez que tenemos que usar el "ID de objeto" es cuando necesitamos usar una configuración específica relacionada con el grupo de seguridad.

Nota: Hay “identidades” adicionales, como la dirección SIP (la dirección LYNC del usuario) y la dirección ID de Windows Live, pero “omitiremos” estas “identidades” porque no se usan con mucha frecuencia.

Objeto de usuario en el entorno de Office 365

Office 365 podría definirse como un “conjunto de servicios en la nube”.

Cuando se utiliza la administración del portal de Office 365 (la interfaz web), las diferentes infraestructuras parecen "una entidad", pero en la realidad, cada uno de estos servicios (Windows Azure Active Directory, Exchange Online, etc.) se basa en una infraestructura que incluye un bosque dedicado de Active Directory, servidores dedicados, etc.

Por ejemplo: cuando creamos una nueva cuenta de usuario, la cuenta de usuario se crea en Windows Azure Active Directory y luego, una copia de la cuenta de usuario se replica en todos los servicios/infraestructuras adicionales, como Exchange Online, SharePoint online y LYNC. en línea.

Cuando hacemos referencia a objetos como: "Objeto de usuario", necesitamos saber a qué infraestructura queremos hacer referencia.

La sintaxis del comando PowerShell y las "reglas" para hacer referencia a las "identidades" de los objetos son un poco diferentes cuando hacemos referencia a objetos en el entorno de Office 365 (Windows Azure Active Directory) frente a la infraestructura de Exchange Online.

1. Hacer referencia a un objeto de usuario en Office 365 (Azure Active Directory): el nombre del objeto de PowerShell que usamos cuando queremos administrar el objeto de usuario en la infraestructura de Office 365 es: MsolUser
2. Hacer referencia a un objeto de usuario en Exchange Online: el nombre del objeto de usuario de PowerShell que utilizamos cuando queremos administrar el objeto de usuario en la infraestructura de Exchange Online es: "Usuario".

PowerShell y gestión de objetos

En la siguiente sección, "sumergiremos" los comandos de PowerShell y la sintaxis específica de los comandos de PowerShell, pero antes de comenzar, recapitulemos:

Usamos PowerShell para administrar objetos. La “gestión de objetos” podría ser:

• Crear o eliminar objetos: crear una nueva instancia de objeto, como una cuenta de usuario, una cuenta de grupo o eliminar objetos existentes.
• Editar las propiedades del objeto: agregando un nuevo valor a las propiedades del objeto, como el nombre del Departamento, Título, agregar una licencia, agregar o eliminar permisos, etc.
• "Obtener" y mostrar información sobre objetos: cuando necesitamos administrar el objeto, usamos comandos de PowerShell para hacer referencia a una clase de objeto particular, como la clase de objeto Usuario o Buzón. Cuando queremos hacer referencia a una instancia de objeto específica, necesitamos usar el objeto identidad. La información que queremos obtener sobre los objetos podría mostrarse en la pantalla (la consola de PowerShell) o podría exportarse a un archivo con el fin de crear informes o, con el fin de editar los datos que se exportaron.

Cmdlets de PowerShell

La definición formal de cmdlets es:

“En PowerShell, las tareas administrativas se realizan mediante cmdlets (pronunciado command-lets). Los cmdlets son clases .NET especializadas que implementan una operación particular. Los conjuntos de cmdlets se pueden combinar con scripts, ejecutables (que son aplicaciones independientes) o creando instancias de clases .NET normales (u objetos WMI/COM). Estos funcionan accediendo a datos en diferentes almacenes de datos, como el sistema de archivos o el registro, que están disponibles para el tiempo de ejecución de PowerShell a través de los proveedores de Windows PowerShell. "

Ahora, intentemos describir el significado de los cmdlets utilizando una descripción más sencilla: los cmdlets de PowerShell son “pequeños comandos. "

(Creo que este era el significado del sufijo "lets"), que usamos para administrar objetos en el entorno PowerShell. El concepto de "cmdlets" es un carácter único del lenguaje PowerShell frente a otros lenguajes de scripting.

Podemos relacionarnos con los “cmdlets” como una “pequeña aplicación” o “aplicaciones” (como las aplicaciones que usamos en dispositivos móviles). Cada una de las clases de objetos, como la clase de objeto Usuario, tiene un conjunto de cmdlets "dedicados" que nos permiten administrar el objeto de una manera simple y "amigable".

PowerShell y el problema de distinguir entre mayúsculas y minúsculas

El entorno de PowerShell no se considera sensible a mayúsculas y minúsculas. Cuando usamos letras mayúsculas para el nombre de un cmdlet de PowerShell o, para el nombre de la propiedad, esto es solo para fines “estéticos”.

Cmdlets: convención de nomenclatura

El nombre de los cmdlets se construye a partir de dos "partes" separadas por un guión:

• La primera parte del nombre de un cmdlet comienza con un "Verbo", como por ejemplo: Set, Get, etc.
• La segunda parte del nombre de un cmdlet es el nombre de clase/tipo de objeto, como por ejemplo: usuario, buzón, grupo, etc.
• El “Verbo” y el nombre del objeto están “conectados” con el carácter “Guión” (sin espacio entre el nombre del “Verbo” y el “Objeto”)

1. El “Verbo” (El Prefijo)

Los “verbos” más “populares” que utilizamos la mayor parte del tiempo son:

• Nuevo: los cmdlets que comienzan con el prefijo "Nuevo" se utilizan para: crear nuevos objetos. Por ejemplo: crear un nuevo usuario de Office 365.
• Establecer: los cmdlets que comienzan con el prefijo "Establecer" se utilizan para: actualizar las propiedades del objeto. La "Actualización" podría implementarse agregando un nuevo valor al objeto o actualizando la propiedad del objeto existente.
• Agregar: los cmdlets que comienzan con el prefijo "Agregar" se usan para: "agregar" algo "a un objeto. Por ejemplo: agregue un usuario a un grupo de distribución, agregue un alias al buzón, agregue permisos del buzón, etc.
• Eliminar: los cmdlets que comienzan con el prefijo "Eliminar" se utilizan para: eliminar o eliminar objetos o eliminar "algo" de un objeto. Por ejemplo: eliminar (eliminar) cuentas de usuario de Office 365 o eliminar permisos del buzón.
• Obtener: los cmdlets de PowerShell que comienzan con el prefijo "Obtener" se utilizan para: recuperar o "buscar" un objeto. El prefijo "Obtener" es especial porque podemos usar "Obtener cmdlets" para mostrar información sobre objetos o podemos usar "Obtener cmdlets" como la "primera parte" de una oración de PowerShell. Las "siguientes partes" de la oración de PowerShell se basarán en la "entrada" que obtengamos de "Obtener cmdlets".

2. El “sustantivo”

El "Sustantivo" es la segunda parte del nombre del cmdlet. En el mundo de PowerShell, el sustantivo es el nombre de una clase de objeto como: usuario, grupo, buzón, etc.

Objetos y son cmdlets dedicados.

En el lenguaje PowerShell, cada objeto tiene un "conjunto de cmdlets dedicado" que se creó especialmente para administrar este objeto específico.

Por ejemplo: el nombre del objeto que representa un objeto de usuario en Office 365 es: MsolUser

Los cmdlets de PowerShell para Office 365 incluyen un "conjunto de cmdlets" dedicado que utilizamos para administrar objetos de usuario como:

• Get-MsolUser: para mostrar información sobre los usuarios de Office 365
• Remove-MsolUser - para eliminar una cuenta de usuario
• New-MsolUser: para crear una nueva cuenta de usuario de Office 365

El mismo principio se implementa para todos los demás objetos, como: objeto de buzón, objeto de grupo, etc.

Usando los cmdlets Get-Help

En este artículo, revisamos solo una pequeña parte de los cmdlets disponibles de Office 365 y Exchange Online y los ejemplos que utilizamos revelan solo la "superficie" de los parámetros y esa opción para cada uno de los cmdlets.

Al usar los cmdlets: Get-Help, podemos obtener información sobre los cmdlets disponibles que podemos usar y obtener información sobre cmdlets específicos.

Ejemplo 1: mostrar los cmdlets establecidos para la clase de objeto: MsolUser

Para obtener una lista de todos los cmdlets relacionados con el "objeto": MsolUser, podemos usar el siguiente comando:

Get-Help *MsolUser*

Ejemplo 2: mostrar información de ayuda para un cmdlet específico

Si queremos obtener información sobre la forma en que podemos usar un cmdlet específico (parámetros, sintaxis, etc.), podemos usar cmdlets Get-Help con el nombre del cmdlet que nos interesa.

Por ejemplo: para mostrar información de ayuda sobre el cmdlet Get-MsolUser podemos usar el siguiente comando:

Get-Help Get-MsolUser

Jerarquía de objetos y nombres de cmdlets

Otro concepto de PowerShell que me gustaría enfatizar es algo que llamo “Jerarquía de objetos”. El término "Jerarquía" describe la relación "padre e hijo" entre clases de objetos.

Para demostrar el concepto de "Jerarquía de objetos", observemos el objeto Buzón.
El objeto Buzón sirve como "contenedor" para carpetas. Otra forma de describir esta relación es decir que: el objeto Buzón es el "padre" del objeto carpeta (o podemos decir que la carpeta es el "secundario" del objeto Buzón).

El objeto Carpeta es el "Padre" de subcarpetas adicionales como: carpeta "Elementos enviados", carpeta "Calendario", carpeta "Contactos", etc.

Si queremos profundizar más en la jerarquía, una carpeta como "Elementos enviados" podría contener una carpeta adicional y el "nivel más bajo" podría ser "Elementos de correo".

El concepto de "Jerarquía de objetos" se expresa mediante los nombres de los cmdlets y la sintaxis de PowerShell que utilizamos.

Supongamos que necesitamos obtener información sobre los permisos para la carpeta de calendario de un usuario en particular. Los cmdlets que utilizamos para este propósito son:

Get-MailboxFolderPermission

Puede observar que el "nombre del cmdlet" describe la jerarquía o la "relación" que existe entre el objeto de buzón que sirve como "principal" para el objeto "Carpeta" y los "Permisos" que se relacionan con el objeto Carpeta.

La sintaxis del comando de PowerShell que utilizamos para mostrar información de permisos sobre el calendario del usuario es:

Usamos los cmdlets “Get-MailboxFolderPermission” para: obtener información de permisos sobre una carpeta. Luego, especificamos la identidad del usuario (John, por ejemplo) y, por último, especificamos el nombre de la carpeta específica (carpeta de calendario en nuestro ejemplo).

Si queremos obtener más información sobre los cmdlets disponibles que podemos usar para administrar la carpeta, podemos usar el cmdlet Get-Help de la siguiente manera:

Get-Help *Folder*

En la captura de pantalla, podemos ver una lista de todos los cmdlets relacionados con el "Objeto Carpeta".

Como puede ver, podemos administrar "diferentes aspectos" del objeto Carpeta, como permisos de carpeta, estadísticas de carpeta y más.

Otra observación interesante que podemos ver es que tenemos cmdlets “dedicados” para la carpeta del calendario (Get-MailboxCalenderFolder).

Lógicamente, la "carpeta de calendario" debe "tratarse" como cualquier otra carpeta, pero debido a que la carpeta de calendario es una característica importante del buzón de Exchange, tenemos cmdlets "especializados" que utilizamos para obtener información sobre las propiedades del calendario. tales como: PublishDateRange, DetailLevel y más.

Tubería

El concepto de "Pipeling" es una de las "piedras fundacionales" del lenguaje PowerShell. El concepto de canalización es similar a una oración humana que se compone de un par de partes. Cada “Parte” de la oración “Conduce” a la “Siguiente Parte”.

Para simplificar el concepto de Pipeling, veamos las siguientes instrucciones sobre: “Cómo hacer un huevo revuelto”.

• Ve al supermercado y compra un cartón de huevos.
• Rompe los huevos y vierte los huevos en una sartén.
• Revuelve los huevos.
• Cuando la tortilla esté lista, ponla en un plato.

Ahora, veamos nuevamente las instrucciones:

La primera operación fue: ir al supermercado. La tienda de comestibles incluye muchos tipos de artículos (objetos) como pan, azúcar y más. En nuestro escenario, sólo nos interesa un tipo particular de objeto: los huevos. La primera parte de la oración “conduce” a la siguiente parte de la oración.

La siguiente parte incluye instrucciones sobre “qué hacer con los huevos”. Podemos decir que la parte 2 se basa en la “entrada” de la parte 1 porque no podemos “romper los huevos y tirarlos en la sartén” si la primera parte no se completó (Comprar/Obtener los huevos).

La misma lógica se aplica a la tercera parte de la oración (revolver los huevos), porque antes de que podamos revolver los huevos, debemos romperlos y tirarlos en la sartén.

Quizás no sea el ejemplo más brillante, pero así es exactamente como funciona Pipeling en PowerShell. En el entorno de PowerShell, utilizamos "Pipeling" para "construir" una oración de PowerShell. Cada parte de la oración de PowerShell se “separa” de las otras partes mediante el carácter de barra vertical (“|”).

El nombre "Tubería" se seleccionó como metáfora porque una "tubería" sirve como "contenedor" para "líquidos", como agua (datos), que queremos enrutar del punto A al punto B.

Cuando usamos "tubería", el "contenido" de la primera parte de la oración de PowerShell se dirige a través de la "tubería" a la segunda parte de la oración de PowerShell. En la segunda parte, "hacemos algo" con la entrada de la primera parte y podemos continuar "enrutando" la entrada (los datos) a través de una "tubería adicional" a la siguiente parte, y así sucesivamente.

No hay limitación en el "número de partes" en una oración de PowerShell. Podemos usar una oración de PowerShell muy simple que incluya solo una parte (sin tubería), o podemos construir una oración de PowerShell muy complicada que incluya muchas partes.

Un ejemplo de “concepto de canalización” en una “oración de PowerShell” podría ser:

El comando "Obtener"

Los cmdlets de PowerShell que comienzan con el prefijo "Get" son especiales porque podemos usarlos para dos propósitos:

1. Obtener objeto y mostrar información sobre el objeto

De forma predeterminada, cuando utilizamos los cmdlets Obtener como comando "independiente", el comando Obtener obtendrá/obtendrá un objeto y mostrará información sobre un objeto.

Podemos usar la salida (la información sobre el objeto) de los comandos Obtener de dos maneras:

• Mostrar en pantalla: de forma predeterminada, cuando se utiliza el comando Obtener, la información sobre los objetos se muestra en la pantalla (consola PowerShell).

• Exportar información a archivo - la segunda opción que tenemos es: exportar la información a un archivo. Esta información podría servir para dos propósitos:

  • Informes: podemos utilizar la información del comando Obtener para crear informes sobre la infraestructura como por ejemplo: número de usuarios, qué licencias tiene cada uno de los usuarios, información sobre buzones, etc.
  • Reeditar los datos: utilizamos la opción de "reeditar" los datos, utilizando una utilidad adicional (además de PowerShell) para editar o "manipular" los datos.

2. Obtener y canalizar

El segundo uso de los cmdlets Get es utilizarlos como la primera parte de una oración de PowerShell que sirve como "base" para las otras partes de la oración de PowerShell.

En el próximo artículo, comenzaremos con Office 365 PowerShell | Jugando con la salida de visualización en pantalla de Get-mailbox | Parte 2#4.