Exchange Server 2010 Portable Command Guide: Advanced Techniques
- Working with Pipelines
- Running Programs
- Creating and Running Scripts
- Registry Modifications with PowerShell
- Understanding Quotes
This chapter provides information and commands concerning the following topics:
- Working with pipelines
- Running programs
- Creating and running scripts
- Registry modifications with PowerShell
- Understanding quotes
Working with Pipelines
When you pipeline, you take the output of one cmdlet and use it in a subsequent cmdlet to perform another operation. This simple act ensures that you can string together very simple cmdlets into complex operations. Some of the reasons you may wish to pipeline include the following:
- You need to pass data from the output of one cmdlet to a subsequent cmdlet.
- You need to perform multiple actions on one or more Exchange objects without having to do so individually.
- You need to pass data output between dissimilar nouns.
- You need the system to report errors or warnings.
You can use pipelining to pass data from the output of one cmdlet to a subsequent cmdlet in order to perform another operation. This operation might work like what's shown in the following table.
Get-User
-OrganizationalUnit OUName
| Enable-Mailbox
-Database "DatabaseName"
PS C:\UsersAdministrator>Get-User
-OrganizationalUnit
Assemblers |
Enable-Mailbox
-Database "AssemblyDB"
|
After acquiring a new assembly plant in Philadelphia, you need to create mailboxes in the AssemblyDB database for all users in the Assemblers OU, which is a child of the Philadelphia OU. This pipelined cmdlet retrieves a list of all users in the Assemblers OU and passes the resultset to the Enable-Mailbox cmdlet, which creates the mailboxes for those users. In Figure 3-1, you can see that there are two users in the Assemblers OU in Active Directory Users and Computers. However, in Figure 3-2, there are no mailboxes present for these users. Figure 3-3 demonstrates the cmdlet used for creating mailboxes for existing users using a Get-User cmdlet piped to an Enable-Mailbox cmdlet. Finally, in Figure 3-4, you can see that the mailboxes have been created. |
Figure 3-1 Users in the Assemblers OU in Active Directory Users and Computers
Figure 3-2 No mailboxes present in the Exchange Management Console for the Assemblers OU users
Figure 3-3 Mailboxes for users in the Assemblers OU created with the Enable-Mailbox cmdlet
Figure 3-4 Mailboxes now present in the Exchange Management Console for the Assemblers OU users
You can also use pipelining to combine several actions. In that way, you can use one cmdlet to gather the mailboxes for all managers, VPs, and anyone in the Assembly department in your organization who has an Exchange mailbox and then a second cmdlet to set multiple quota values on those distinct groups of mailboxes. Performing multiple actions on Exchange objects might work like what's shown in the following table.
Get-User -Filter {((Title -like
Title1Name) -or (Title -like Title2Name)
-or (Department -eq DepartmentName
))
-and (RecipientTypeDetails -eqRecipientType
)} | Set-Mailbox
-IssueWarningQuota size1
-ProhibitSendQuota size2
-ProhibitSendReceiveQuota size3
-UseDatabaseQuotaDefaults $boolean value
PS C:\Users\Administrator>Get-User
-Filter {((Title -like "*Manager*") -or
(Title -like "*VP*") -or (Department -eq
"Assembly")) -and (RecipientTypeDetails
-eq "UserMailbox")} |
Set-Mailbox -IssueWarningQuota
900MB -ProhibitSendQuota 1GB
-ProhibitSendReceiveQuota unlimited
-UseDatabaseQuotaDefaults $false
|
You have very distinct groups of users who need unique quotas applied to their mailboxes. You cannot use a quota at the database level because these users are spread across multiple databases. All managers, VPs, and users in the Assembly department need these quotas applied to their mailboxes regardless of the server or database where their mailbox is located. You can combine the collecting of the distinct groups of users with the application of the unique quotas on the mailboxes with a piped cmdlet, as shown. |
You can pipe data between dissimilar nouns. You might find that you want to use the data from one cmdlet within another cmdlet, but the object types do not match. This can happen if one cmdlet references one noun (such as by importing information from a .csv file with an Import-CSV cmdlet, where "CSV" is the noun) and you then want to use that imported data to create a new user account as well as an Exchange mailbox, which you can do with the New-Mailbox cmdlet, where "Mailbox" is the noun. Finally, you might wish to add title and department attributes to the user account (not the mailbox), which references the "User" noun. Passing data output between dissimilar nouns might work like what's shown in the following table.
Import-CSV "C:\filename.csv" |
ForEach-Object -Begin {
$Pass =
ConvertTo-SecureString password
-asPlainText -force} -Process
{New-Mailbox -Name $_.Name
-UserPrincipalName
"$($_.UserName)@
DomainName"
-OrganizationalUnit "OUName" -Database
"DatabaseName" -Password $Pass
-ResetPasswordOnNextLogon $true |
Set-User
-Title $_.Title -Department
$_.Department}
PS C:\Users\Administrator>Import-CSV
"C:\FileFromHR.csv" |
ForEach-Object -Begin {$Pass =
ConvertTo-SecureString "Pa$$w0rd"
-asPlainText -force} -Process
{New-Mailbox -Name $_.Name
-UserPrincipalName "$($_.UserName)
@DomainName"
-OrganizationalUnit "OUName" -Database
"DatabaseName"
-Password $Pass
-ResetPasswordOnNextLogon $true |
Set-User
-Title $_.Title -Department
$_.Department}
|
You need to import several users from a .csv file given to you by the HR department. The noun initially used is "CSV". You then wish to create the user and the mailbox at the same time, but that requires setting a password for each user. You create a password and save it as a secure string, which the Active Directory will accept. You use a variable ($Pass) to store the secure string password. This involves the New-Mailbox cmdlet, which utilizes the "Mailbox" noun. Finally, you want to add values to title and department, which are properties of the user, so you need to reference the "User" noun to do that. |
You can also report errors or warnings though pipelining, which might work like what's shown in the following table.
$Name = "Custom Text"
PS C:\Users Administrator>
$Warn
= "This is an example
of a custom warning
that you might create that could provide
an onscreen warning
when some condition
exists."
$Name | Write-Warning
PS C:\Users Administrator>
$Warn |
Write-Warning
|
This illustrates how you could pipe a string to the Write-Warning cmdlet. You could save the string in a variable, as shown in the first pair of cmdlets, and then pipe the string to Write-Warning, as shown in the second pair of cmdlets. |