IT tutorials
 
Applications Server
 

Exchange Server 2013 : The Exchange Management Shell - How Exchange uses Windows PowerShell

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

From an Exchange perspective, Windows PowerShell provides a way to perform tasks quickly and simply in a variety of manners, from one-off interventions to process one or more Exchange objects to complex scripts to perform tasks such as mailbox provisioning. Most administrators cut their teeth on PowerShell by using the Exchange Management Shell (EMS) to do simple things, such as using Get-Mailbox to report on a mailbox’s properties and Set-Mailbox or Set-CASMailbox to set a property, before moving on to the more esoteric commands to manipulate connectors or control the ability of devices to connect through ActiveSync and so on. The saying is that almost anything is possible with Windows PowerShell, and this is certainly true when you dedicate enough energy and time to mastering the language, not to mention the time necessary to scan the Internet for useful examples of scripts that can be adapted to meet your needs.

Prior to Exchange Server 2007, business logic was scattered in components throughout the product. The management console did things—even simple things like setting a property on a server—by using different code and logic than in the setup program, and the application programming interfaces (APIs) included in the product usually provided a third way to approach a problem. The result was a total lack of consistency, duplication of code, and a tremendous opportunity to create bugs in multiple places. In addition, administrators could not automate common tasks to meet the needs of their organization; essentially, if an Exchange engineer didn’t code something into the product, it couldn’t be done.

Figure 1 illustrates the central role Windows PowerShell now plays in the Exchange architecture and shows how it provides a central place to encapsulate business logic that underpins the Exchange setup program, the Exchange Administration Center (EAC), the mailbox options that users can update through Outlook Web App, and the Exchange Management Shell (EMS).

A graphic showing how Exchange is built on top of PowerShell. All of the business logic in Exchange is encapsulated in a set of PowerShell cmdlets that are then used to build the Exchange Administration Center (EAC), the management shell (EMS), and the setup program.

Figure 1. Windows PowerShell at the heart of Exchange

The way Exchange uses Windows PowerShell to implement business functionality is probably the most extensive of any Microsoft application. As explored throughout this book, the options presented by EAC to work with mailboxes, connectors, servers, and other objects invariably result in a call to one or more PowerShell cmdlets that actually do the work. The functionality presented to administrators, specialist users (those who perform a subset of administrative tasks such as maintaining user details), and normal users is all based on PowerShell.

The exact scope and range of the functionality presented to any individual user is determined by the permissions granted to him through role-based access control (RBAC). RBAC is designed to function across a range of environments, from a single-server organization to an organization composed of a mixture of on-premises and hosted servers. The need to accommodate such a wide range of environments is also why Microsoft has moved from local PowerShell (by which all commands are executed on a local server) to remote PowerShell (by which commands are redirected through Internet Information Services [IIS] for execution on a target server). The details of just how remote PowerShell and RBAC work together in EMS are covered shortly.

Simplifying the implementation of new functionality

The administrative interfaces in Exchange all lead to the same place and execute the same business logic. Apart from removing redundant and overlapping code, having a single place to implement business logic enables the Exchange engineers to concentrate on implementing new functionality rather than re-implementing features specifically for use by EAC, EMS, or the setup program. The approach enables Exchange to deliver a more consistent administrative environment and a comprehensive method to automate tasks to deal with mailboxes, databases, connectors, and all the other components that collectively make up an Exchange organization.

At the time of writing, Exchange 2013 RTM CU2 includes 965 cmdlets that are added to the standard set of Windows PowerShell cmdlets, including cmdlets to work with the system registry, file system, variables (including environmental variables), and so on that are available in an EMS session. Depending on the RBAC role groups of which your account is a member, the number of cmdlets available to you might vary.

Collectively, the set of EMS cmdlets manages the objects and the properties of the objects that form Exchange. Objects include mailboxes, servers, transport rules, connectors, and so on. You can determine the exact number of cmdlets Exchange owns by using the following command (this command doesn’t work with Exchange Online):

Get-ExCommand | Measure-Object | Select Count

Inside Out Finding the cmdlets available to you

An EMS session allows you access only to the cmdlets and parameters that are defined in the roles included in the role groups of which your account is a member. Accounts that are highly permissioned, such as those belonging to the Organization Management role group, can use many more cmdlets than those that belong to a less-permissioned role group, such as Help Desk or Recipient Management. You can use this command to generate a full list of all the Exchange 2013 cmdlets your account can access:

Get-ExCommand > C:\Temp\ExCommands.txt

By comparison, Exchange 2007 includes 394 cmdlets, Exchange 2010, 584; and the RTM version of Exchange 2013, 958. The hundreds of new cmdlets included in Exchange 2013 and subsequently augmented through cumulative updates reflect the new functionality in the product such as the introduction of site mailboxes and data loss protection policies, along with the expansion of existing functionality such as the changes to compliance.

PowerShell use and syntax are fundamental skills for Exchange administrators to master. In fact, many Exchange administrators prefer EMS to EAC because of the additional flexibility that EMS provides. This chapter lays out the basics of Windows PowerShell and sets the stage for the examples of PowerShell found in other chapters. To begin, review how the Exchange management tools actually connect to PowerShell.

 
Others
 
- 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
- Sharepoint 2013 : Building an Application with Access Services (part 4) - Adding, Removing, and Editing Tables
- Sharepoint 2013 : Building an Application with Access Services (part 3) - Creating the Basic Application
- Sharepoint 2013 : Building an Application with Access Services (part 2) - Configuring SQL Server 2012, Configuring the Windows Development Environment Firewall
- Sharepoint 2013 : Building an Application with Access Services (part 1) - Configuring an On-premise Development Environment
 
 
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