How Exchange Leverages Windows PowerShell

From an Exchange perspective, Windows PowerShell provides a way to perform tasks quickly and simply in variety of manners. Prior to Exchange 2007, there was no way for administrators to automate common tasks to meet need to their organization; essentially if exchange engineer didn't code something into product, it couldn’t be done.

Below figure illustrates the central role that Windows PowerShell now plays in the Exchange architecture and how it provides a central place to encapsulate Business Logic that underpins the Exchange Setup program, EMS, EMC and ECP.

       Figure: Windows PowerShell at the heart of Exchange

The options presented by EMC to work with mailboxes, connectors, servers and other objects invariably results in a call to one or more PowerShell cmdlets that actually do the work.

The critical point is that the four major administrative interfaces in Exchange all lead to the same place and execute same Business Logic. Apart from removing redundant and overlapping code, having single place to implement Business Logic allows Exchange Engineer to concentrate on implementing new functionality rather than redeveloping features separately and specifically for EMC, EMS or other setup programs. This approach allows Exchange to deliver more consistent environment and a comprehensive method to automate tasks to deal with mailboxes, connectors, databases and all other components that collectively make up and Exchange Environment.

                                                                       

The RTM release of Exchange 2010 includes 584 cmdlets that are added to EMS to join standard set of Windows PowerShell cmdlets, including cmdlets to work with system registry, file system, variables ( including environment variables) and so on. The number of cmdlets grows again to 619 in Exchange 2010 SP1.

You can determine exact number of cmdlets owned by Exchange with the following command:

Get-ExCommand | Measure-Object | Select Count

You can use below command to generate full list of Exchange cmdlets that your account can access:

Get-ExCommand > C:\ExCommand.Csv

By comparison, Exchange 2007 includes 394 cmdlets, 26 of which have been removed in Exchange 2010. The 216 new cmdlets provided in Exchange 2010 reflects the new functionality in the product, such as introduction of RBAC model, mailbox archives, Database availability group (DAG) along with expansion of existing functionality such as messaging records management.

# Remote PowerShell:

Windows PowerShell has been at the heart of Exchange since Exchange 2007. Exchange 2007 was the first major server product to embrace Windows PowerShell extensively. However lack of remote capability was more serious because it required installation of Windows PowerShell and its snap-ins for exchange on any workstation or server from which you wanted to perform management tasks.

Installing software is an acceptable requirement in environments where all the servers are under your control and within your own network, but it caused problems when you want to manage servers remotely. The Microsoft introduction of Online services where companies will be able to run their exchange environments inside large Microsoft datacenters means that remote management has taken a new importance.

Exchange 2010 includes many new feature designed to ease the transition to online services and remote PowerShell provides the fundamental building blocks for management.

Exchange 2010 extends the concept of remote management to support the remote execution of commands in a secure manner using HTTPS and a Kerberos-based encryption. Here is an interesting thing to know about Exchange 2010 sessions. In Exchange 2010, remote PowerShell is used for all EMS sessions. Which means, even if you are logged on the server and want to user EMS to change property of that server, EMS still creates a remote session to the local server to the work. The same applies to EMC. In effect, remote PowerShell replaces local PowerShell in Exchange 2010 for all server roles except Edge servers.

Removal of local PowerShell and the concentration on the combination of remote PowerShell with and RBAC as the basis for administrative control over Exchange components is a major change in the product.

The logic of replacing local PowerShell with remote model is simple. Just like then change in Exchange 2007 to force all messages to flow through the transport system so that single common place existed to apply features such as transport rules, remote PowerShell forces exchange administration to flow through RBAC so that the PowerShell session will only ever include set of cmdlets to do your job !

The logic of keeping local PowerShell on Edge servers is simple too. These are the isolated from the rest of the organization so they do not have access to remote RBAC roles. Anyone who logs on the Edge server as an administrator operates in the context of management of just that server and has complete control over that server. However, he can not affect any other server or object in the Exchange organization.

The need to support hosting platforms such as Microsoft Business Productivity Online Services (BPOS) was major influence on Exchange’s move to remote PowerShell.

Permissions granted through RBAC are evaluated at the time of session initialization. If you are assigned a new role then you have to create a new session with EMS, ECP or EMC before you can access the cmdlets made available through newly assigned role.

# Advantage of Remote PowerShell:

Microsoft does not make changes to product like Exchange unless they see some clear advantage. There are 3 potential advantages of remote PowerShell.

1 1.Separating client and server processing and using IIS as the mechanism to route the traffic allows communication through a well understood route that can flow across firewalls and so accommodate both Microsoft Online Services and enterprise customers that operate multiple active directory forest.

2 2.The ability for administrators to delegate the tasks to other users on the basis of well defined roles adds to overall system security and prevents inadvertent mistakes that can affect essential data.

   3. Remote capability means you can perform Exchange management tasks from a workstation connected to your network without installing Exchange management tools. Of course you still need to install Windows PowerShell and any prerequisites software such as WinRM, .Net Framework, but these components are more likely to be part of corporate build for administrator’s workstation.

EAS Lock Down - Part 1

     You have an Exchange 2010 environment and users are using activesync devices, now your organization decide to lock down the EAS and allow the access only for those user who have signed some sort of consent form.

Below is the method to achieve this through ECP.

Now the first thing you need to do is edit "Exchange ActiveSync Settings" and you can do it through ecp.
1) Login to the ecp
2) Select "Manage My Organization"
3) Go to "Phone & Voice" Tab.
4) Under "ActiveSync Access" you will have "Edit" option to edit "Exchange ActiveSync Settings".
5) You will then get a pop to edit the settings.
       So you will have three below self explanatory options (but still I'll add some detail to it ) :
              a) "Connection settings
              When a device that isn't managed by a rule or personal exemption connects to Exchange" :
                     Select the option "Quaratine - Let me decide to block or allow later" which will quarantine all the activesync devices

              b)  "Quarantine notification e-mails Select administrators to receive e-mail when a device is quarantined." :
                    Add the administrators details so that email is received by the administrators once device     gets quarantined. Personally I would recommended that you mention the administrators detail here, will explain why it's recommended.


             c) "Enter text to include in e-mails sent to users who have a device in quarantine, blocked, or in the process of being identified" :
                      Here you can enter any custom message that you want to provide in an email which is received by the users' who's ActiveSync device is quarantined or blocked.

             d) Click Save to accept the settings.


Refer below figures for more details :

Figure 1: Managing EAS Settings

Figure 2: Exchange ActiveSync Settings

Once the above setting is applied then all the users who are using activesync on their device will receive the email message saying that their device has been quarantined.

Administrator will also receive an email which would contain the users' activesync device details and direct ecp link for managing users' device.
Administrator then can click on the link given in the email to either block or allow the device from syncing the emails depending on if that user has signed the consent form or not.

     Besides from the email you will also get the list of quarantined devices  under "Quarantined Devices"(6) to manage the users' activesync devices. You can then select the desired user and allow or block the activesync access(6a) accordingly.
If in your organization you have more than 500 users then you will get random 500 activesync devices in the quarantined devices list, so you may or may not get the desired user in the list who has signed the consent form and you want to allow the activesync access for that user.

If you want to allow access only for users' who has signed the consent form and for only particular device (like iOS devices) then you should also check "Device Type" and "Model" while allowing or blocking the activesync access.