IT tutorials
Applications Server

Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 4) - Identities, Piping

12/1/2013 8:19:55 PM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

6. Identities

You might have noticed the –Identity parameter in some of the cmdlets you have explored so far. In many cases, a call to an Exchange cmdlet results in a set of objects being returned (for example, all the mailboxes on a server). In these instances, you might need to identify a specific object within the chosen set with which to work. (Think of a pointer to an item in an array.) For example, if you issue the Get-ExchangeServer cmdlet, you retrieve a list of all the Exchange servers in the organization. If you want to work with one server, you have to tell EMS which server you want to select by passing its identity. For example, to work with just the server named ExServer1:

Get-ExchangeServer –Identity 'ExServer1'

Apart from its obvious use to identify the object with which you want to work, –Identity has a special meaning within PowerShell because it is a positional parameter. You can specify the parameter’s value without specifying the parameter’s name, so the example previously used is just as valid if you use:

Get-ExchangeServer 'ExServer1'

Inside Out Best practice to include the –Identity parameter

Although you might find it faster to omit the –Identity parameter when you’re working interactively with EMS, it is best practice always to include the –Identity parameter when you write code for reusable scripts because this ensures that there is no possibility that another administrator or programmer will mistake the value passed for the identity for anything else.

If you want, you can retrieve a list of objects and store them in a variable and retrieve the values as you wish. The variable holds the objects as an array. For example, to populate a variable with a set of mailboxes hosted by a server:

$Mbx= Get-Mailbox –Server 'ExServer1'

To retrieve the different objects in the array, pass the number of the object with which you want to work, starting from zero. For example, to fetch the first mailbox in the array:


You can be more specific and ask for one of the object’s properties. For example, to get the identity of the first mailbox in the array:

IsDeleted           : False
Rdn : CN=Eoin P. Redmond
Parent : Mailboxes
Depth : 3
DistinguishedName : CN=Eoin P. Redmond,OU=Exchange Mailboxes,DC=contoso,DC=com
IsRelativeDn : False
DomainId :
ObjectGuid : 0bcd15b3-c418-43be-b678-2658614f732b
Name : Eoin P. Redmond

You might be surprised by the amount of information returned here for the mailbox’s identity (it’s all defined in the schema), but it contains all the ways you can navigate to this object through its relative distinguished name (shown here as the rdn property), distinguished name, globally unique identifier (GUID), and name. Normally, you’ll just use the name of a mailbox to find it, but you can use the other methods, and Exchange will find the mailbox. There is no requirement to parse out a specific piece of the identity you want to use or to trim values; PowerShell does it all for you. For example, you can use an identity to discover the groups to which a user belongs. Here’s the code:

$U = (Get-User –Identity TRedmond).Identity; Get-Group | Where-Object {$_.Members –eq $U}

The Get-User cmdlet loads the user’s identity into a variable, and then the Get-Group and the Where-Object cmdlets scan all groups to discover any that include the user in their membership. Scanning the membership list of groups to discover string matches is never going to be as quick (and will get slower as the number of groups in the forest grows) because a string compare will never get close to the backward pointers that consoles such as Active Directory Users and Computers or EMC use to display group membership in terms of speed of access, so don’t be surprised. Scanning for group membership in this way takes some time to complete.

If you don’t like user-friendly forms such as email addresses or mailbox names, Exchange also allows you to use GUIDs as identifiers. Because they are obscure and long, GUIDs are difficult to type, but you can still use them. One slightly complicating factor is that you must know which GUID to use where. You might want the GUID that points to a user’s mailbox, the GUID pointing to her Active Directory account, or even the one pointing to her archive mailbox. For example, this command displays all GUIDs registered for a mailbox:

Get-Mailbox –Identity 'Tony Redmond' | Format-List *Guid*
ExchangeGuid        : c2c4a3b5-c1a6-5a17-971d-8549123a78d0
ArchiveGuid : 00000000-0000-0000-0000-000000000000
DisabledArchiveGuid : 00000000-0000-0000-0000-000000000000
Guid : 288617d1-4592-4211-bb20-26ab755458c8

The ExchangeGuid property points to the user’s mailbox. This is a tremendously important property because the GUID pointing to a mailbox can be guaranteed to be unique across an Exchange organization, which is why the Store uses this value to locate a user’s mailbox. It’s also why Outlook users see the ExchangeGuid of their mailbox instead of the server name when viewing the server name property shown when viewing the server settings of an Exchange 2013 mailbox (Figure 3).

A screen shot showing how Outlook displays the GUID that identifies an Exchange 2013 mailbox when it configures a profile to access the mailbox.

Figure 3. How Outlook displays the ExchangeGuid

It is confusing, but if you run Get-MailboxStatistics to retrieve summary details of the contents of a mailbox, EMS returns a MailboxGuid property. This is the same value as the ExchangeGuid when reported by Get-Mailbox. Why Microsoft felt that two names were required for the same GUID is beyond me.

The Guid property identifies the user’s Active Directory account and thus provides the essential link between a mailbox and an account. In this case, the ArchiveGuid is shown as all zeros, so no archive mailbox is associated with this mailbox. The DisabledArchiveGuid value is also all zeros. This GUID is used only when a user has been assigned an archive mailbox that was subsequently disabled for some reason. Exchange maintains the GUID so the archive can be reconnected to the mailbox up to the point at which it is permanently removed from a database after the expiry of the deleted mailboxes’ retention period.

Now that you know what the GUIDs are, you could use them to reference a mailbox. For example:

$GUID = (Get-Mailbox –Identity 'Tony Redmond').Guid
Get-User | Where {$_.Guid –eq $GUID} | Format-Table Name

The great thing about identities is that you sometimes don’t need to use them. This situation occurs when you pipe information from one cmdlet for processing by another because the shell understands that it needs to operate on the current object that has been fetched through the pipe. For example, this command pipes a list of mailbox identities passed in strings to the Set-Mailbox cmdlet:

"TRedmond", "JSmith", "JDoe" | Set-Mailbox –Office "Dublin"

7. Piping

You’ll pipe output from one cmdlet to another frequently as you work with Exchange data. The important thing to remember is that PowerShell outputs fully formed objects that can be manipulated when fed as input to other cmdlets through the pipeline. This wouldn’t be possible if PowerShell output text strings. For example, assume that you want to change the value of the Office property for a set of users who have moved to a new building. It would be tedious if you had to fetch the identity of each user individually, determine each identity, and then pass the value to make the change to each user’s properties. A simple pipe works because PowerShell knows that it can use the stream of data from one command to identify the objects it has to process with another. Here’s how you might update the Office property for a complete set of users without any mention of an identity. You’ll see that the two cmdlets that do the work are separated by the pipe character, “|”. This is the character that tells PowerShell to pipe the output from the first cmdlet to become the input to the second.

Get-User –Filter {Office –eq 'Building A'} | Set-User –Office "Building B"

Too many objects

By default, EMS returns up to 1,000 objects in response to cmdlets. (The value in Exchange 2007 is 5,000.) Therefore, if you run a cmdlet such as Get-Mailbox, Exchange will return up to 1,000 mailboxes if they are available. If you work in a small Exchange organization that supports fewer than 1,000 mailboxes, you don’t need to worry too much about the number of objects you have to deal with because PowerShell will likely return relatively few objects, and things usually progress quickly. However, it’s a different situation in large organizations, in which you have to pay attention to the filters you specify to retrieve data or override the default limit for returned objects by specifying the ResultSize parameter for cmdlets. For example, to let EMS return as many mailboxes as it can find, you could use a command like this:

Get-Mailbox –ResultSize Unlimited

This command will work, but it will be very slow because EMS has to read every mailbox in the organization. Think about how long this might take to execute in an organization that supports more than 300,000 mailboxes. In these situations it’s always better to specify a filter to restrict the number of objects EMS looks for and returns.

- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 3) - Using common and user-defined variables, Using PowerShell ISE with Exchange
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 2) - Handling information EMS returns , Selective output
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 1) - Command editing
- Exchange Server 2013 : The Exchange Management Shell - Using remote Windows PowerShell - Connecting to remote PowerShell
- Exchange Server 2013 : The Exchange Management Shell - How Exchange uses Windows PowerShell
- Active Directory Planning and Installation : Installing Active Directory - Promoting a Domain Controller
- Active Directory Planning and Installation : Understanding Domain and Forest Functionality
- Active Directory Planning and Installation : Verifying Network Connectivity - Tools and Techniques for Testing Network Configuration
- Active Directory Planning and Installation : Verifying the Filesystem - Setting Up the NTFS Partition
- Sharepoint 2013 : Building an Application with Access Services (part 6) - Adding a Macro, Reporting and External Data
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Technology FAQ
- IIS Web site works in all browsers except Safari on Mac
- notification
- alternative current in to a pc
- parse url in JavaScript
- Dual WAN on a Fortigate 60
- Should Sys Admins (Domain Admins) also have user accounts?
- DR solution for data warehouse
- C# Creating Plugins
- SCCM 2007 collection by OU not showing all pc's
- Email account got spoofed?
programming4us programming4us