skip to Main Content

Getting started with Office 365 PowerShell | Basic introduction | Part 1#4

Let’s start with a basic fact about myself: I am not a programmer (and I probably will never be). If I could learn how to use PowerShell, everyone can do it! In the beginning, PowerShell looks to me like an unnecessary “Black” and complicated tool, and I did my best to avoid it.

The Power of PowerShell | Article Series

The Power of PowerShell article series, including the following three articles:

I thought: “Why should I use PowerShell, instead of the friendly Microsoft GUI (graphical user interface)? Over time, I became aware of the significant advantages of using PowerShell and, as the time goes by, I start to feel comfortable with the PowerShell environment.

This article is about: getting to know the basic of PowerShell in the Office 365 environment.

If you feel that you want to understand better the concept and the logic of the PowerShell and, you’re willing to allocate more than 2 minutes for reading the information, I believe that you could enjoy the ability to understand this environment instead of copy and paste “mysterious” PowerShell commands.

What is “PowerShell”?

There are many “Formal” descriptions for PowerShell, but let’s make it simple: PowerShell, as the name implies, is a “Shell” and Script languish. The main character of PowerShell versus other script languages is that the PowerShell is very friendly and “Human-like” script languages.

PowerShell enables us to use very simple and powerful commands (cmdlets), and at the same time, PowerShell could serve for writing very complicated scripts (this is the part that is closest to the “Programmer’s”).

At the current time, most of the Microsoft OS and products can be managed by using PowerShell, and some of the products like Exchange server, are purely based on PowerShell.

For example, the Exchange GUI interface that we use is just a “friendly interface”. Every option that we utilized in the GUI interface is translated and executed as a PowerShell command.

The “Power” of PowerShell

There are many advantages of using PowerShell:

  • Bulk operations – the meaning of the term “Bulk operations” is the ability to execute a PowerShell command for managing a “group of objects”.
    For example, we need to assign licenses to all Office 365 users who don’t have licenses. In case that our organization includes 10 employees, this task can be implemented very easily by using the Office 365 Portal Web Interface. But what a scenario in which we need to assign the license to 1, 500 users?
    Of course, we can do it manually, but this will be a very exhausting task.
    By using the PowerShell, we can use a command that finds all the users who don’t have licenses, and assign the required license for these users.
  • Export information – Office 365 Web interface does not include the option for creating reports or exporting information.
    By using PowerShell, we can create reports and export required data about the different components such as a list of users with assigned licenses, information about Mailbox’s size, user list that includes information such as phone numbers, department and much more.
  • No user intervention – using PowerShell, we can execute all the required administration tasks for Office 365 users on the “background,” without the need for involving the users in this process.
    For example: when we need to assign permissions to user Mailbox or user calendar, there is no need to login to the outlook user profile, or remote control the user Desktop.
    Instead, we can execute the required management task by using PowerShell commands.
  • GUI interface limitation – Office 365 Web Interface, enables us to perform many administrative tasks. Some of the administrative tasks could be carried out only by using PowerShell.For example: we can use the Office 365 Web interface for reset user password and create a temporary password for the user, but the Web-based interface does not include the option for: setting a predefined password for the user, or change the default expiration password policy (this task, can be implemented only by using PowerShell).
  • Automate administrative tasks – many times, we need to run administrative tasks on a scheduled basis.
    For example: create a weekly report that includes information about new users, new license assignments, etc. by using a combination of PowerShell scripts and the built-in Windows Task Manager, we can automate these administrative tasks.

Remote PowerShell – Office 365

When using PowerShell for – managing Office 365 infrastructures, we use a method that describes as Remote PowerShell. To be able to execute the required PowerShell commands, we first need to create a remote session that includes an authentication process to the Remote Host (Office 365 and Exchange Online infrastructure).

We use Remote PowerShell for managing 4 different infrastructures:

  1. Office 365 – When we use the term “Office 365”, the meaning is: the part that serves as an “envelope” to all other Office 365 Services. This part includes components such as: User and Security Group objects (Windows Azure Active Directory), Domain names management, mail migration, SSO (Single sign on), license management and more.
  2. Exchange Online – This part includes the management of Mail services. For example: add or remove Email address, Set Mailbox size, assign policy to the Mailbox etc.
  3. SharePoint Online
  4. Lync Online

Each of the Office 365 infrastructure requires a “dedicated remote PowerShell session”, and for each of these environments, we need to use a different set of cmdlets (we will review the term cmdlets later on) for creating the Remote session.

Remote PowerShell Office

PowerShell “Objects Class”

PowerShell is all about: managing objects.
In the Office 365 environment, there are dozens of objects. An Example for “object” could be: User, Mailbox, Group, Domain etc.

PowerShell Object class

Object Class/Type and object instance

The term “Object Class/Type”, describe an “entity” with specific properties. When we create a “new object” such as: new User, we are actually creating an object instance.

The ”new instance” (for example, a new user), inherit the structure of the object class and (most of the time) have a unique identity.

For example: when we create a new User named “John”, the new user considered as “instance” of the object class “User”. The new user (John) will have all the “properties fields” that were inherited from the User object class.

Object class and object instance

Note: Most of the time, we don’t use the term “instance” when we talk about an object, but instead, we just use the term “object.”

Object class and object Derivatives

Some of the “Object Class” serves as a “Root object” that has Derivatives.

For example – the “Group Object Class” has the following Derivatives:

Group Object could be: a security group or distribution group, and distribution group, could be “standard distribution group” or a Dynamic distribution group.

When we create a new “Distribution Group,” the new instance inherits the structure and the properties of the “Group object class” + a specific property, that are unique for the “Distribution Group” object class such as: Email address and message approval.

Object Class and Object Class Derivatives

Object Properties

The basic definition for object class could be: a collection or a predefined set of properties.
The concept of objects and object’s properties is “borrowed” from the Real World.

For example – each of us (Human being or a person) has properties such as – height, eye color, weight, citizenship, etc.

Each of the Object classes such as User object or Mailbox object have a particular set of properties that are “relevant” to the object class.

For example, User object properties could be: general details such as – Title, Department, City, Phone Number, or other properties such as: User Role (standard user, Global Administrator), license (does the user have or don’t have a license), Mailbox (does the user have Mailbox “attached” to his user account) and so on.

User object Properties

Note: Mailbox could consider as an “Object”, but, Mailbox is also considered as a “property” of a User because the Mailbox object doesn’t have a “Life of its own.” A Mailbox object should be “attached” to User object.

An additional example is – Mailbox properties.

The properties of the Mailbox object could be a Mailbox size, the email address that “attached” to the Mailbox, personal Archive, etc.

Additional “Mailbox properties” could be a policy that attached to the Mailbox.

For example: Retention policy (a policy that relates to deleting or moving to archive mail items when mail items reach a specific “age”).

Mailbox object Properties

In case that we want to display a list of the properties that “belong” to a specific object class, we can use the PowerShell cmdlets:

Get-Object Class | Get-Member

Object properties values

As mentioned, we can describe an object as a – collection of properties. When we create a new object (or if we want to be more accurate – Object instance), some of the properties “Must” have values (mandatory requirement).

For example: Office 365 user object must have Alias Name and User Principal Name. Other properties such as: Password Never Expires are set automatically with the value “True” and additional properties such as: Title, Department, city and more, don’t have a predefined value (or we can say: “Empty property”).

This “values”, could be set by the Administrator that manages the user’s account.

Object Structure

Referencing Objects

The first part for every “PowerShell sentence” or PowerShell command starts with a reference to an object class or an object instance. Let’s review the option for “Referencing Objects “by demonstrating the basic administrative task of Mailbox management.

When we need to manage Mailboxes that hosted on the Exchange Online server, we can define 3 options for “referencing” object/s:

  1. Reference to a particular instance of object classes
    For example – we want to get information about “John” Mailbox.
  2. Reference objects class.
    We can use a PowerShell command that displays information about – all the Mailbox object class
  3. Reference Subset/Group of objects
    In an Exchange environment, we have a different type of “Mailboxes” such as User Mailbox, Resource Mailbox, Shared Mailbox, Search Mailbox etc. Many times we want to reference only a “Subset” or a “Sub Group” of objects.

For example: we want to display only Mailboxes that “belong” to the group of “User Mailboxes”.

Reference object options

Object “Identities”

When we want to reference an “instance” of object class, we will need to specify the object identity. This concept of: “identities”, is very similar to the “Real world”.

Each one of us has a couple of identities such as – First name, Full name, “Nickname” or Social Number. In the same way, when we need to manage specific instances of an object such as “John User Account”, we need to specify the identity of this instance (John).

Note: Most of the “identities” are considered as “Unique”, meaning – no other object (User) could have the same identity.

User Object “Identities”

For the demonstration purpose, let’s review the options for the “User Object Identities”. The following list includes a description of the different User Object Identities that we can use when we need to reference a specific instance of the object class (a specific user such as “John”.

  • User Display name – this identity is composed of the user first name and the last user name. The “Display name” Identifier is not a unique Identifier. The meaning is that we can have 2 (or more) users with the same display name.
    When we want to reference an object by using the object display name, we should use quotation marks because the display name includes a space (the space between first name and last name). Since the user’s identity of “Display name“ is not unique, it’s recommended to avoid this option when we want to reference a particular user.
  • User UPN – (UPN stand for- User Principal Name). In Office 365, the user UPN = User Login name. User UPN is a unique Identifier (only one user can have a specific UPN). The UPN has composed of the user Alias name and, the Office tenant domain or, the “custom domain” name (the vanity domain name).
    By default, the user UPN is also the user primary Email address (this default can be changed only by using PowerShell command).
  • User Alias – the user Alias name created according to the organization “Alias name Policy”.
    For example, a standard Alias name policy could be the user first name and the first characters of the family user name. The user Alias name is not a unique Identifier. When we want to reference a user Mailbox, it’s easier to use the user Alias name instead of using the “Long” user UPN.
  • User Email Address – User Email Address is a unique identifier. When Office 365 user have Mailbox, the user, need to have at least one email address that describes as a Primary email address. As mentioned, by default the user’s primary email address is identical to the user UPN.
  • GUID (Object ID) – the object ID is a unique Identifier. This Identifier is not used very often. The only time that we have to use the “object ID”, is when we need to use a specific configuration that relates to the Security group.
User object “Identities”

Note: There are additional “identities” such as the SIP address (the user LYNC address) and windows live ID address but, we will “skip” these “identities” because they are not used very often.

User object in the Office 365 environment

Office 365 could be defined as a “suite of cloud services”.

When using the Office 365 portal administration (the Web interface), the different infrastructure looks like “one entity”, but in the reality, each of these services (Windows Azure Active Directory, Exchange Online, etc.), is based on a separated infrastructure that includes a dedicated Active Directory forest, dedicated servers and so on.

For example: when we create a new user account, the user account is created in the Windows Azure Active Directory and then, a copy of the user account is replicated to all of the additional service/infrastructures such as Exchange Online, SharePoint online and LYNC online.

User object in the office 365 environment

When we reference object such as: “User object” we need to know which infrastructure we want to reference.

The PowerShell command syntax and “rules” for referencing object “identities”, is a little different when we reference object in the Office 365 environment (the Windows Azure Active Directory) versus the Exchange Online infrastructure.

  1. Referencing a User object in Office 365 (Azure Active Directory) – The PowerShell object name whom we use, when we want to manage the user object in the Office 365 infrastructure is: MsolUser
  2. Referencing a User object in Exchange Online – The PowerShell user object name whom we use, when we want to manage the user object in the Exchange Online infrastructure is: “User
User object in the office 365 environment and PowerShell cmdlets

PowerShell and Object Management

In the next section, we will “dive” into PowerShell commands and the specific PowerShell command syntax but before we start, let’s recap:

We use PowerShell for managing objects. “Object management” could be:

  • Create or deleted objects – creating a new object instance such as a Users account, Group Account or deleting existing objects
  • Editing object properties – by adding a new value to object properties such as a name of the Department, Title, add a license, add or remove permissions, etc.
  • “Fetch” and display information about objects – when we need to manage the object, we use PowerShell commands for referencing a particular object class such as User or Mailbox object class.When we want to reference specific object instance, we need to use the object identity.The information that we want to get about objects could displayed on the screen (the PowerShell console) or, could be exported to file for the purpose of creating reports or, for the purpose of editing the data that exported.

PowerShell cmdlets

The formal definition for cmdlets is:

“In PowerShell, administrative tasks are performed by cmdlets (pronounced command-lets). Cmdlets are specialized.NET classes implementing a particular operation. Sets of cmdlets may be combined with scripts, executables (which are standalone applications), or by instantiating regular.NET classes (or WMI/COM Objects). These works by accessing data in different data stores, like the filesystem or registry, which are made available to the PowerShell runtime via Windows PowerShell providers.”

Now, let’s try to describe the meaning of cmdlets by using the more friendly description: PowerShell cmdlets are “Little commands.”

(I think that this was the meaning of the suffix “lets”), that we use for managing objects in PowerShell environment. The concept of “cmdlets” is a unique character of the PowerShell languish versus another scripting languishes.

We can relate to “cmdlets” as a “small application” or “apps” (like apps that we use on mobile devices). Each of the object classes, such as a User object class, has a “dedicated” set of cmdlets that enable us to manage the object in a simple and a “friendly” way.

PowerShell and the issue of Case sensitive

The PowerShell environment not considered as Case Sensitive. When we use capital letters for a PowerShell cmdlets name or, of the Property name, this is only for “Aesthetic” purposes.

Cmdlets – Naming convention

Cmdlets name is built from two “parts” separated by a Hyphen:

  • The first part of a cmdlets name start with a “Verb” such as: Set, Get etc.
  • The second part of a cmdlets name is the Object Class/Type name such as: User, Mailbox, Group etc.
  • The “Verb” and the object name are “connected” with the “Hyphen” Character (no space between the “Verb” and the “Object” name)
cmdlets – Naming convention

1. The “Verb” (The Prefix)

The most “popular” “verbs” that we use most of the time are:

  • New – cmdlets beginning with the “New” prefix are used for: creating new objects. For example: create new Office 365 user.
  • Set – cmdlets beginning with the “Set” prefix are used for: update object properties. The “Update” could be implemented by – add a new value to the object, or update existing object property.
  • Add – cmdlets beginning with the “Add” prefix are used for: “add “something” to an object. For Example: add user to a distribution group, add Alias to Mailbox, add Mailbox permissions etc.
  • Remove – cmdlets beginning with the “Remove” prefix are used for: remove or delete objects or, removing “something” from an object. For example – remove (delete) Office 365 user accounts or, remove Mailbox permissions.
  • Get – PowerShell Cmdlets that start with the “Get” prefix are used for: retrieve or “fetch” an object. The “Get” prefix is special because we can use “Get cmdlets” for display information about objects or, we can use the “Get cmdlets”, as the “first part” of a PowerShell sentence. The “next parts” of the PowerShell sentence will be based on the “input” that we get from the “Get cmdlets”.
cmdlets – Naming convention The “Verb” (Prefix)

2. The “Noun”

The “Noun” is the second part of the cmdlets name. In the PowerShell world, the Noun is the name of an object class such as: User, Group, Mailbox etc.

Objects and they’re dedicated cmdlets

In the PowerShell languish, each object has a “dedicated set of cmdlets” that was created especially for managing this specific object.

For example: the object name who represents a user object in Office 365 is: MsolUser

The PowerShell cmdlets for Office 365 includes a dedicated “cmdlets set” that we use for managing User object such as:

  • Get-MsolUser – for displaying information about Office 365 users
  • Remove-MsolUser – for deleting a user account
  • New-MsolUser – for creating a new Office 365 user account

The same principle is implemented for all other objects such as: Mailbox object, Group Object and so on.

Object “dedicated” cmdlets

Using the Get-Help cmdlets

In this article, we review just a small part of the available Office 365 and Exchange Online cmdlets and, the examples that we use reveal just the “surface” of the parameters and that option for each of the cmdlets.

By using the cmdlets: Get-Help, we can get information about the available cmdlets that we can use and, get information about a specific cmdlets.

Example 1 – Display the cmdlets set for the object class: MsolUser

To get a list of all the Cmdlets that relate to the “object”: MsolUser, we can use the following command:

Get-Help *MsolUser*
Get-Help MsolUser

Example 2 – Display Help information for a specific cmdlet

If we want to get information about the way that we can use a specific cmdlet (Parameters, syntax etc.), we can use Get-Help cmdlets with the name of the cmdlet that we are interested in.

For example: for displaying help information about the Get-MsolUser cmdlet we can use the following command:

Get-Help Get-MsolUser
Get-Help Get-MsolUser

Object Hierarchy and cmdlets names

An another PowerShell concept that I would like to emphasize is something that I call “Object Hierarchy.” The term “Hierarchy”, describes “parent and child” relationship between object classes.

To demonstrate the “Object Hierarchy” concept, let’s observe the Mailbox object.
The Mailbox object serves as a “container” for folders. Another way of describing this relationship is to say that: the Mailbox object is the “parent” of the folder object (or we can say that the folder is the “child” of the Mailbox object).

The Folder object is the “Parent” of additional sub-folders such as: “Sent Items” folder, “Calendar” folder, “Contacts” folder and so on.

If we want to get “deeper” in the Hierarchy, a folder such as “Sent Items” could contain additional folder and, the “lowest level” could be “Mail Items”.

Object Hierarchy and cmdlets names

The concept of the “Object Hierarchy” is expressed by the cmdlets names, and by the PowerShell syntax that we use.

Suppose that we need to get information about the permissions for the calendar folder of a particular user. The cmdlets that we use for this purpose is:


You can notice that the “cmdlet name” describe the hierarchy or the “relationship” that exists between the mailbox object that serves as a “Parent” to the “Folder” object, and the “Permissions” that relate to the Folder object.

The PowerShell command syntax that we use for displaying permission information about user calendar is:

Object Hierarchy and cmdlets names syntax

We use the “Get-MailboxFolderPermission” cmdlets for: getting permissions information about a folder. Then, we specify the user identity (John for example) and last, we specify the specific folder name (calendar folder in our example).

If we want to get more information about the available cmdlets that we can use for managing folder, object we can use the Get-Help cmdlet in the following way:

Get-Help *Folder*

In the screenshot, we can see a list of all the cmdlets that relate to the “Folder Object”.

As you can see, we can manage “different aspects” of the Folder object such as a Folder Permissions, Folder Statistics and more.

Another interesting observation that we can see is that we have a “dedicated” cmdlets for the calendar folder (Get-MailboxCalenderFolder).

Logically, the “calendar folder” should be “treated” like any other folder, but because the calendar folder is an important feature of the Exchange Mailbox, we have a “specialized” cmdlets that we use for getting information about the property of the calendar such as: PublishDateRange, DetailLevel and more.

Get-Help Folder


The concept of “Pipeling” is one of the “Foundation stones” of PowerShell languish. Pipeling concept is similar to a Human sentence that is composed from couple of parts. Each “Part” in the sentence “Lead” to the “Next Part”.

To simplify to the concept of Pipeling, let’s look at the following instructions on: “How to make a Scrambled egg”.

  • Go to the grocery store and buy a carton of eggs.
  • Break the eggs and spill the eggs to frying pan.
  • Scramble the eggs.
  • When the omelet is ready, put the omelet on a plate.
PowerShell and how to make a Scrambled eggs

Now, let’s look again at the instructions:

The first operation was: go to the grocery store. The grocery store includes many types of items (objects) such as bread, sugar and more. In our scenario, we are interested only in a particular kind of object: eggs. The first part of the sentence “leads” to the next part of the sentence.

The next part includes instruction about “what to do with the eggs”. We can say that part 2 based on the “input” of part1 because we cannot “Break the eggs and spill the eggs to frying pan” if the first part was not completed (Buying/Getting the eggs).

The same logic applies to the third part of the sentence (scramble the eggs), because before we can scramble the eggs, we need to break the eggs and spill the eggs to frying pan.

Maybe it’s not the most brilliant example, but this is that exact way that Pipeling works in PowerShell. In the PowerShell environment, we use the “Pipeling” for “building” a PowerShell sentence. Each part of the PowerShell sentence is “separated” from the other parts by using the pipe (“|”) character.

The name “Pipe” was selected as a metaphor because a “pipe” serves as a “container” for “Liquid” such as water (Data) that we want to route from point A to point B.

When we use “pipe”, the “content” of the first part of the PowerShell sentence, is routed through the “Pipe” to the second part of the PowerShell sentence. In the second part, we “do something” with the input from the first part, and we can continue to “route” the input (the data) through “additional Pipe” to the next part, and so on.

There is no limitation on the “number of parts” in a PowerShell sentence. We can use very simple PowerShell sentence that includes only one part (without a pipe), or we can build a very complicated PowerShell sentence that includes many parts.

An example for- “Pipe concept” in a “PowerShell sentence” could be:


The “Get” command

PowerShell cmdlets starting with the “Get” prefix are special because, we can use them for two purposes:

1. Get object and display information about the object

By default, when we use Get cmdlets as a “stand alone” command, the Get command will Get/Fetch an object + display information about an object.

We can use the output (the information about the object) from the Get commands in two ways:

  • Display on screen – By default, when using the Get command, the information about objects is displayed on the screen (PowerShell console).
  • Export information to file – the second option that we have is: export the information to a file. This information could serve for two purposes:
    • Reports – we can use the information from the Get command for creating reports about the infrastructure such as: the number of users, what licenses each of the users have, information about mailboxes and so on.
    • Re-edit the data
      we use the option of “re-edit” data, by using additional utility (beside of PowerShell) to edit or “manipulate” data.

2. Get and pipeline

The second use for the Get cmdlets is by using the get cmdlets as the first part of a PowerShell sentence that serve as a “foundation” for the other parts of the PowerShell sentence.

The “Get” command

In the next article, we will Get started with Office 365 PowerShell | Playing with the Get-mailbox on screen display output | Part 2#4.

The o365info Team

The o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *