Windows 7 / Getting Started

---

Administrative Tools

Exchange Server 2010 provides administrators with three primary administrative tools: The first two, the Exchange Management Shell and the Exchange Management Console, were both introduced with Exchange Server 2007. The third, the Exchange Control Panel, is new to Exchange Server 2010 and provides some exciting possibilities.

The Exchange Management Shell is a command-line interface, allowing administrators to run single commands or complex scripts to simplify redundant tasks. The Exchange Management Shell can be utilized to configure every aspect of an Exchange Server environment.

The Exchange Management Console has a graphical user interface (GUI). Nearly as powerful as the Shell, the Console can be used to configure most of the aspects of an Exchange Server environment.

New to Exchange Server 2010 is the Exchange Control Panel, which enables personnel to administer some aspects of the Exchange Server environment through a web interface. Unlike the Management Console or the Management Shell, which are designed and intended to be used only by Exchange Server administrators, the Exchange Control Panel is designed to also enable end users to self-manage certain aspects of their accounts.

Exchange Management Shell

The Exchange Management Shell (EMS) is the engine that powers all Exchange Administrative tools. A powerful management tool in its own right; the EMS is also utilized by both the Exchange Management Console and the Exchange Control Panel to process actions initiated in their interfaces.

Introduced in Exchange Server 2007, the Exchange Management Shell is a command-line management interface. Administrators had been screaming for years for a command-line tool that was powerful enough to enable scripted changes of Exchange Server objects, and the Exchange Management Shell was well received.

Tasks that had to be done manually within the confines of the GUI management application in pre-2007 versions could now be scripted, allowing administrators increased flexibility for repetitive tasks. The Exchange Management Shell looks similar to the DOS command prompt (cmd.exe), in that it opens a window with a black background and a text interface. However, you notice immediately that certain commands and errors are highlighted in yellow or red text rather than the traditional monochromatic command prompt.

With the Exchange Management Shell, administrators can manage every aspect of Exchange Server including the creation and management of new email accounts, the configuration of Simple Mail Transfer Protocol (SMTP) connectors and transport agents, or properties of database stores. In fact, every task that can be accomplished with the Exchange Management Console can be accomplished from the command line in the EMS, but the opposite is not true.

NOTE: When the EMS was first released, there were many commands that had to be performed in the shell because many configuration options were not available in the EMC. As much as administrators enjoyed the new capabilities of the command-line interface, they did not like being told "you have to use it all the time." Over time, more and more functionality was added back into the Exchange Management Console.

With the EMS, administrators have a powerful yet flexible scripting platform that is much easier to take advantage of than using Microsoft Visual Basic scripts-previously the only way to script changes in the Exchange Server environment. As described by Microsoft, "What once took hundreds of lines in Visual Basic scripts can now be accomplished easily with as little as one line of code."

The EMS uses an object model that is based on the Microsoft .NET platform. This enables the shell commands to apply the output from one command to subsequent commands when they are run.

Whereas Exchange Server 2007 used PowerShell v1, Exchange Server 2010 is built on PowerShell v2, which has several enhancements that distinguish it from the previous version.

Exchange Server 2010 also utilizes Windows Remote Management (WinRM) 2.0. Whether an administrator is connecting to a local server or one halfway around the world, EMS always connects to the desired Exchange Server 2010 server via a remote connection utilizing an Internet Information Server (IIS) virtual directory. This holds true even when administrators are running the PowerShell command against the server they are currently logged on to. Due to this capability, the ability to perform PowerShell-based Exchange Server management does not require Exchange Server binaries to be installed on the requesting client, so 32-bit clients that have PowerShell v2 with WinRM 2.0 installed can be used for remote PowerShell administration.

The supported client OS platforms include the x86 and x64 versions of Windows Vista, Windows Server 2008, Windows Server 2008 R2, Windows 7, Windows Server 2003, Windows Server 2003 R2, and Windows XP.

Exchange Management Shell Basic Concepts

The Exchange Management Shell has a number of command functions, support options, and customization features. The following is a list of some of the basic concepts administrators should be aware of:

• Objects-The collection of properties that represents each of the pieces that make up an Exchange Server environment. An object can refer to a user mailbox, a server, a connector, or one of many other configurable items.
• Cmdlets-A cmdlet, pronounced "command-let," is a specialized .NET class that performs a particular operation. Cmdlets are the smallest unit of functionality in the EMS. Similar in appearance to the built-in commands in other shells (such as the DIR or CD commands in a Microsoft command prompt), cmdlets can be run individually or combined in scripts. There are hundreds of cmdlets provided for Exchange Server-specific management tasks.
• Parameters-Parameters are elements that provide information to the cmdlet. Parameters can either identify an object or its attributes to act upon or can control how the cmdlet performs its task.
• Restricted PSSession-By implementing the RBAC control model, the EMS can restrict available cmdlets and parameters to only those that the user has access to run. For example, if the user does not have the access to create new mailboxes, the New-Mailbox cmdlet will not be presented to them.
• Identity-Identity is a special parameter that can be used with most cmdlets to give access to the unique identifiers that refer to a particular object. By using the identity parameter, administrators can specify the particular object they want to retrieve, modify, or delete. To reduce unnecessary keystrokes, the identity parameter was created as a positional parameter. When running a cmdlet, the first argument is assumed to be the identity parameter, so running the command get-mailbox -identity "linkin" will produce the same results as get-mailbox "linkin".
• Pipelining-Before the EMS, one of the biggest shortcomings of scripting in the Exchange Server environment was the lack of ability to take the output of one command and utilize it directly as the input for other commands. Within the EMS, pipelining allows exactly that. Administrators have the ability to string cmdlets together, using one cmdlet to gather data, passing the results to a second cmdlet that filters the data to a smaller subset, and then supplying the result to a third cmdlet to act on.
• Object-oriented data handling-Because the resulting output from any cmdlet in the Exchange Management Shell is an object, all output can be acted upon and processed by other commands with little to no changes. Commands that are intended to work together on particular feature sets accept the output from other commands in the same feature set.
• Access cmd.exe commands-All the commands available in the Windows command prompt (cmd.exe) are also available to the EMS. Administrators can not only run these commands, but also can take the output from those commands and perform actions based on that output.
• Trusted scripts-Administrators have long been concerned that the ability to run scripts in an organization (especially when logged in with administrative credentials) could have disastrous results. To prevent this from happening, the Exchange Management Shell requires that all scripts be digitally signed before they are allowed to run. This feature is intended to prevent malicious users from inserting a dangerous or harmful script in the EMS. Before a script can be run, the administrator must specifically "trust" it, helping to protect the entire organization.
• Profile customization-The EMS provides a powerful, easy-to-use interface with the default installation, but administrators might want to customize the appearance of the interface, create shortcuts for commonly used commands, or specify specific commands to automatically run when the EMS starts. All these items can be configured using a customized Exchange Management Shell profile.
• Tip-Although perhaps not as impressive as the preceding features, a welcome feature of the EMS is the display of a Tip of the Day each time the Exchange Management Shell is opened. The Tip of the Day offers advice on how to perform specific tasks within the shell, listing commands and proper syntax for their use.