IT tutorials
 
Applications Server
 

Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 3) - Using common and user-defined variables, Using PowerShell ISE with Exchange

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

4. Using common and user-defined variables

PowerShell includes a number of variables you will use a lot. $True and $False are variables you can pass to shell commands and scripts to check for true and false conditions. Usually, $True is equivalent to setting a check box for an option in EMC, and $False is equivalent to clearing a check box. If you prefer numeric values, you can replace $True and $False with 1 (one) and 0 (zero), respectively. Other global variables you commonly meet as you work with PowerShell include $Null (no value), $home, which returns the user’s home folder, and $pwd, which returns the current working folder. Important Exchange variables include the following:

  • $ExBin. Points to the directory in which Exchange binaries and other important files are kept. On an Exchange 2013 server, this variable normally resolves to disk: \Program Files\Microsoft\Exchange Server\V15\bin.

  • $ExScripts. Points to the directory in which important Exchange .ps1 scripts are kept. On an Exchange 2013 server, this variable resolves to disk: \Program Files\Microsoft\Exchange Server\V15\Scripts.

  • $ExInstall. Points to the root directory for Exchange. On an Exchange 2013 server, this variable resolves to disk: \Program Files\Microsoft\Exchange Server\V15.

You can use these variables to access files in these directories. For example, to see a list of scripts Exchange provides, type Dir $ExScripts.

Checking that a value is $True or $False is a common occurrence. For positive conditions, you can shorten the check by just passing the property against which to check, and PowerShell will assume that you want to check whether it is true. For example, assume that you want to find out which mailboxes are enabled to use Outlook Web App. You can use this command and, as you can see, there is no mention of $True, but it works:

Get-CASMailbox | Where-Object {$_.OWAEnabled} | Select Name

Note the use of $_ in the last command. $_ is a very important variable because it points to the current object in the pipeline. Scripting languages on other platforms such as UNIX and Linux also support pipelines, which compose complex commands by allowing the output of one command to be passed as the input to another. The | operator indicates that a pipeline is in place. Data are passed as fully formed objects rather than as a text stream. This enables PowerShell to operate on the full structure of data that are pipelined, including the attributes and types that define the objects piped from one cmdlet to another.

For example, if you create a filter to look for people in a certain department because you want to update the name of the department, you might do this:

Get-User | Where-Object {$_.Department –eq 'Legal'} | Set-User –Department 'Law'

The Department property is prefixed with $_ to indicate that you want to check this property for every object the call to Get-User passes through the pipeline. You actually use $_. as the prefix because it includes the “.” operator to specify that you want to access a property. If you just passed $_ the comparison would not work because PowerShell would compare “Legal” against the complete object.

User-defined variables can be integer, decimal, or string—you decide by passing a value to the variable you want to use. For example:

$Tony = 'Tony Redmond'
$Figure = 15.16

This creates a string variable, and the second variable holds a decimal value. Variables are case-insensitive and case-preserving. Using the preceding example, you can refer to $Tony as $TONY or $tony or even $ToNY, and PowerShell will refer to the same variable. Variables are local unless you declare them to be global by prefixing them with Global, as in:

$Global:Tony = 'Tony Redmond'

When a variable is global, you can reference it interactively and in scripts you can call from anywhere.

A word of caution about PowerShell and quotation marks

Be careful how you use quotation marks in PowerShell because although it might appear that double and single quotation marks are interchangeable, there is a subtle difference that might catch you out. Single quotation marks represent a literal string, one that PowerShell will use exactly as you provide it. Double quotation marks mean that PowerShell should examine the string and resolve any variable it finds inside through a process called variable expansion. Consider this example:

$n = Date
$n1 = 'Right now, it is $n'
Right now it is $n
$n2 = "Right now, it is $n"
$n2
Right now, it is Tue Jan 16 17:59:54 2013

Can you see the difference a little quotation mark makes? Best practice is to use single quotation marks whenever you are sure that you want a string variable to stay exactly as you have typed it and to use double quotation marks elsewhere. Be careful about using editors that insert smart quotation marks because PowerShell cannot deal with them; it is best to use a simple text editor whenever you create or edit a script. You cannot mix and match the different types of quotation marks to enclose a variable because PowerShell will refuse to accept the command. You will not do any great harm if you use double quotation marks instead of single quotation marks, but it is best to use single quotation marks as the default.

Tip

Do not include hyphens when you name variables because PowerShell interprets the hyphens as parameters. In other words, $ServerName is a good name for a variable, but $Server-Name is not.

Like any good scripting language, PowerShell supports conditional checking with IF and ELSEIF that you will mostly use in scripts. It’s easy to generate code that goes through a certain number of iterations with constructs such as 1..100 | ForEach-Object <command…>.

5. Using PowerShell ISE with Exchange

If you don’t like the bare-bones nature of EMS, you might prefer to use ISE, the PowerShell Integrated Scripting Environment. ISE is installed on Windows 2008 R2 SP1 and Windows 2012 servers to provide a GUI for PowerShell that allows users to write, test, and debug scripts. PowerShell ISE is also installed by default on Windows 7 and Windows 8 workstations.

ISE supports multiline editing, tab completion, syntax coloring (or highlighting of different parts of commands), context-sensitive help, and keyboard shortcuts. Because of its debug features, ISE is a good way to write complex scripts for use with Exchange 2013.

When you start ISE, it has no knowledge of Exchange or how to create the kind of remote session with an Exchange server in the way EMS does when it starts. Some work is therefore necessary to integrate ISE with Exchange. The easiest way to do this is to insert some code in the PowerShell profile so that ISE learns enough about Exchange when it initializes to access Exchange when you need it to.

The code you need to use with ISE is very similar to the code you met earlier when discussing the basics of creating a remote PowerShell session. Start ISE and type Notepad $Profile to edit your PowerShell profile, and then insert the following code (amending the reference to contoso.com to reflect your own environment):

$PSISE.CurrentPowerShellTab.AddOnsMenu.SubMenus.Add(
"Connect to Exchange", {
$user = Get-Credential
$Server = Read-Host "Connect to what Exchange server "
$connectpoint = $Server + ".contoso.com/PowerShell/"
$ExSession= New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri
$connectpoint -Credential $user
Import-PSSession $ExSession
},
"Control+Alt+1"
)

The code defines a new menu choice called Connect to Exchange that appears on the ISE Add-ins menu. The option can also be invoked with the Control/Alt/1 key combination. In either case, when invoked, the code prompts for user credentials and the server to which to connect and then initiates a new remote PowerShell session with the selected Exchange server. After the connection is established, you can work as with EMS except that extra information and facilities are available to you, such as a context-sensitive list of cmdlets that appears when you start typing a cmdlet name (Figure 2).

A screen shot of the PowerShell ISE being used to write code for Exchange 2013. Several commands that have been executed are visible, including Get-Mailbox and Get-User, and the current input is Get-Mailbox, to which ISE responds with a list of all the matching commands starting with Get-MailboxSearch.

Figure 2. Working with Exchange 2013 through the PowerShell ISE

 
Others
 
- 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
- Sharepoint 2013 : Building an Application with Access Services (part 5) - Modifying Application Views, Creating a Query
 
 
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
 
Facebook
 
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