Let’s start with a basic fact about myself: I am not a programmer (and probably I 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:
The thought that I had was: “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:
- 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.
- 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.
- SharePoint Online
- 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.
You can read more information about how to create the remote PowerShell for each of the environments by using the following articles:
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.
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 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.
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.
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”).
General Note: 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:
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.
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:
- Reference to a particular instance of object classes
For example – we want to get information about “John” Mailbox.
- Reference objects class.
We can use a PowerShell command that displays information about – all the Mailbox object class
- 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”.
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).
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 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.
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.
- 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
- 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”
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:
The formal definition for cmdlets in Wikipedia 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 built from two “parts” separated by a Hyphen.
1. The “Verb” (The Prefix)
The most “popular” “verbs” that we use most of the time are:
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 principal is implemented for all other objects such as: Mailbox object, Group Object and so on.
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:
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:
Object Hierarchy and cmdlets names
An anther 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”.
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:
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:
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.
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.
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:
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:
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.
It is important for us to know your opinion on this article