In this post I will highlight some of the benefits, components and other considerations that need to be taken before going for a Hybrid Exchange deployment.

Benefits of a Hybrid Exchange Deployment

Despite the greater complexity, there are a number of tangible reasons why businesses may want to try a hybrid deployment. Services such as Exchange Online Archiving (EOA) can be used with a hybrid deployment, which may appeal to smaller businesses due to its low-barrier access to 99.9% uptime, 24/7 live phone support and ability for users to access their own email archives from their Inbox.

In some cases, organizations can reduce cost by relocating users on inexpensive cloud servers but with important data hosted on-premise. This can be crucial in terms of legal jurisdiction of data for foreign companies not headquartered in the U.S. From a technical perspective, Exchange administrators can also run PowerShell commands that are mirrored to online servers, while a single Outlook Web App URL is used to access both on-premise and cloud-based Exchange deployment.

Do note that while it is possible to set up Exchange for coexistence with another system such as Lotus Notes, the term “hybrid mode” here has specific connotations that pertain specifically to an on-premise Exchange 2010 working with Exchange Online.

Components required for a hybrid deployment

An organization that wants to set up a Hybrid deployment must first configure the cloud-based portion of the Exchange deployment. Furthermore, an Exchange 2010 server with SP1 in the CAS server role is required to be installed on-premise to enable a hybrid deployment. This includes an extension of the Active Directory schema when installing Exchange 2010, as well as the setting up of a DirSync server in order to maintain a synchronized address book between the cloud and on-premise installation.

The Dirsync server will need to be appropriately sized to meet hardware requirements; a 1.6GHz CPU with 4GB memory and 70GB of hard disk space is adequate to support an Active Directory with up to 50,000 objects. Note that a ticket with support will need to be opened for organizations with more than 20,000 Active Directory objects. Also, an Exchange hybrid deployment is not supported for an organization that implements multiple forests for logon or resource segmentation.

Offboarding or decommissioning of on-premise Exchange Server

Aside from the benefits outlined earlier, another use of a hybrid deployment is as an intermediate step to decommissioning an on-premise Exchange so as to switch completely to Exchange Online. In addition, it can also facilitate an organization that started with Exchange Online but decided to move mailboxes back on-premises, in a move called offboarding.

For the former, Microsoft advices that the steps leading to the decommissioning of an on-premise Exchange deployment should be planned carefully with the help of an Office 365 deployment specialist. For moving mailboxes from Exchange Online to an on-premise deployment, you can check out Exchange Hybrid Deployment – Moving Cloud-Based Mailboxes to the On-Premises Organization for more information.

While we have barely scratched the surface of Hybrid Exchange deployment, you should now have a better understanding of what considerations and benefits it involves.

Like this post?

If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free e-book with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!

In this post I shall highlight four important changes in Exchange 2013 that administrators should be aware of when preparing for its arrival.

Exchange Administration Center

The most dramatic difference in Exchange 2013 is the Exchange Management Console, which will be replaced by the Exchange Administration Center (EAC). The EAC replaces the Exchange Control Panel (ECP) too, and is accessed from the same URL (http://<serverFQDN>/ecp). EAC is much more powerful in that it’s now optimized for on-premises, online, or hybrid Exchange deployments, and allows Exchange to administer it from multiple platforms.

Browsers supported by EMC include Internet Explorer, Firefox, Safari and Chrome; you can see a detailed list of the supported combinations of browsers and operating systems here. Going for a fully web-based interface means that administrators can now deploy their Exchange Server in a secure datacenter that is physically hard to access and still perform their work as if it is down the hall in the server room.

Change in Architecture

Probably the most notable change in Exchange Server 2013 will be the reduction of server roles to just two: Client Access server and Mailbox server. The Mailbox role includes Unified Messaging, while the Client Access role handles authentication and proxy/redirection. This change reduces complexity for administrators, and is a reflection of the optimizations being enacted in the core Exchange engine. It is understood that an Edge Server role will not be available when Exchange 2013 is released, but will be released post-RTM with Exchange Server 2013 SP1.

There are many other changes under the hood too, which include a much reduced IOPS load (up to 50%), as well as optimization for multiple databases per volume in order to increase aggregate disk utilization. Moreover, available RAM is harnessed to improve search query performance and reduce IOPS, all of which translate to larger mailboxes at lower costs.

PowerShell cmdlets

Based on PowerShell version 3.0, PowerShell in Exchange Server 2013 adds more than a hundred new cmdlets. A number of cmdlets have been dropped in Exchange 2013, though they mostly have to do with a major change in how public folders are now handled (See below). One of the advantages offered by PowerShell 3.0 is its simplification that makes it easier to use even as it allows for more comprehensive management of servers.

Note that as PowerShell cmdlets are executed on Mailbox servers only, organizations would have to have an Exchange 2013 Mailbox server available to manage the environment. Regardless, it is evident that not only is PowerShell here to stay, but is set to play an even greater role in Exchange. 

Change in Public folders

Exchange 2013 completely changes how public folders operate, and now stores them in mailbox databases. This means that public folders can now take advantage of Database Availability Groups (DAG) for replication and high availability.

Another effect is that mailbox quotas do apply to them too, and a public folder that has grown too large will need to be moved to another mailbox. As a result, administrators will do well to more carefully plan their public folder deployment in Exchange Server 2013.

There are a great many other changes made to Exchange 2013, which is best experienced by checking out the preview version yourself. Download it here.

Like this post?

If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free e-book with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!

Exchange Server has multiple roles, namely the Edge Transport, Client Access, Hub Transport, Mailbox server and Unified Messaging roles. For a large enterprise, the presence of these server roles makes it possible to design deployment scenarios for greater redundancy and load-balancing that can span offices or even geographical regions.

Organizations that do not require the Edge Transport and the Unified Messaging role will find themselves questioning whether they should deploy the Client Access, Hub Transport Server and Mailbox server roles on the same machine. I address these below:

Multi-role server for simplicity

To be clear, a multi-role Exchange deployment involves collocating the Client Access, Hub Transport and Mailbox roles into the same physical server. The key advantage of taking this route has to do with the simplified initial configuration as well as the ease of subsequent administration. While it can be argued that deploying the Client Access and Hub Transport role into separate servers allows for greater scalability down the road, excessive processor overhead is a sheer waste of computing capability and RAM.

Another argument in favor of a multi-role server has to do with how simplicity helps keep things manageable, while the inherent complexity of deploying the various roles on separate physical servers increases risk. This may range from something as mundane as a LAN cable coming loose or improperly maintained documentation causing a new Exchange administrator to misconfigure a crucial IP address.

Debunking scalability

Instead of working with suppositions that a multiple-server Exchange deployment allows for greater future expansion, Microsoft has provided the free Exchange 2010 Mailbox Role Requirements Calculator to help administrators work out the RAM and processor utilization for a given set of hardware and various variables such as number of users and size of mailboxes.

Exchange administrators can use this tool to validate a new server, as well as to compare the merits of an Exchange deployment using multiple servers versus a single multi-role server.  Remember to factor the cost savings of using fewer servers (over a multi-server deployment) into consideration.

Do you need high availability

As Exchange 2007 does not support Client Access or Hub Transport roles on clustered server, there is no way to have a high availability deployment unless the roles are segregated into separate physical servers. The use of a multi-role server may not be suitable in such a scenario. The introduction of Database Availability Groups (DAG) in Exchange 2010 removed that limitation though, and as such eliminates an argument against multi-role servers.

Hardware recommendations

Microsoft does offer a recommended configuration for combining a Client Access and Hub Transport role into a single server. According to Microsoft, a minimum of two processor cores are required, with up to a recommended maximum of 12 processor cores. Minimum RAM should be 4GB, with a recommended maximum of 2GB per core.

Multi-role Exchange deployment should be adequate for the majority of businesses out there. As such, it makes sense to start with the assumption of a multi-role server for the simplest possible solution, and move on to more complex deployments only when there is a need to.

Like this post?

If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free ebook with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!

Below are some tips to quickly get up to speed on certain important aspects of using PowerShell with an Exchange Server deployment.

Connecting to Exchange Online using PowerShell

As its name suggests, Exchange Online is the cloud-based version of Exchange Server. The growing acceptance of cloud services is resulting in businesses that eschew buy their own physical servers, or who may opt for a hybrid deployment involving both Exchange Online and an on-premise Exchange Server. Fortunately, it is possible to connect to Exchange Online using PowerShell too; here’s how:

To initiate an Exchange Online session, first type in the following command in a PowerShell session. You will be prompted for your admin credentials:

$LiveCred = Get-Credential

Once done, create a new remote PowerShell session with the following command:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $LiveCred -Authentication Basic –AllowRedirection

Next, import the cmdlets to your local PowerShell session:

Import-PsSession $Session

You can now execute various cmdlets; you can use the command below to view information about cloud-based mailboxes:

Get-Mailbox

When done, be sure to disconnect from the server-side session with the following:

Remove-PSSession $Session

For additional information about the cmdlets that are available in Exchange Online, you can check out this reference here.

Creating PowerShell Scripts

While the PowerShell command line offers extraordinary flexibility in performing all manner of tasks, its real power lies in the ability to create custom scripts for performing various regular management tasks. This also promotes code reuse, which has the added effect of reducing errors resulting from typos or outright mistakes.

To be clear, a PowerShell script is essentially a text file with a .PS1 extension, which allows it to be edited using the PowerShell Integrated Scripting Environment (ISE) or any common text editor such as Windows Notepad or NotePad++. Variables, conditional logic (if, else) and loops (do while, while, do until, for, for each) are other important aspects of PowerShell that Exchange administrators working with scripts will need to be familiar with.

To write scripts for managing Exchange Online or other remote Exchange Servers, it may be necessary to first store the login credentials so that the housekeeping scripts may be launched at predetermined times outside office hours. Rather than having the passwords in plaintext within the script, a much safer alternative would be to write an encrypted version of it to a local file. This can be done with the following command:

Read-Host -AsSecureString | ConvertFrom-SecureString | Out-File C:\Users\someone\MyPassword.txt

Within your PowerShell script, the encrypted password credential can be accessed using the following snippet:

$Password = type C:\users\someone\MyPassword.txt | ConvertTo-SecureString

$Userid = someone@organization.onmicrosoft.com

$Cred = New-Object System.Management.Automation.PSCredential ($Userid, $Password)

It is important to note that although this method is more secure than having the plain text password written in the script itself, a few risks remain. Anyone who manages to get access to the script can alter it to perform unauthorized actions which can compromise the security of your Exchange Servers. Furthermore, if someone with malicious intent gets access to the system and is able to run his/her own scripts he/she can still retrieve the password from the SecureString itself. That said, it is a good middle ground between convenience and security for most.

Finally, organizations with more than one Exchange admin in place may also want to create a common repository to store useful scripts that can be shared internally. Depending on the storage environment, this repository of scripts and functions – mentioned below, can also be added to the system path for easy access.

Piping the output of Cmdlets, Functions

Not everything requires the hassle of writing a script though. For simpler tasks, it may make more sense to pipe the output of a cmdlet to another for the desired output. While this may require more command line and PowerShell knowledge than the average Exchange administrator may possess, chaining various cmdlets into a single command is an enormously powerful way of performing complex Exchange tasks.

Building on the idea of code reuse mooted above in “Creating PowerShell Scripts”, would be the idea of packaging them into functions. As opposed to the single purpose usage of a script, a function can be called and its output reused or even piped to another cmdlet as necessary. Used correctly, piping the output of one cmdlet to another can be used to quickly perform tedious configuration changes. The following configures all mailboxes with a quota of 3GB with a warning set at 2.8GB (source):

Get-Mailbox | Set-Mailbox -IssueWarningQuota 2.8GB -ProhibitSendQuota 3GB

This may also be further filtered by selecting only those accounts where the “Office” attribute matches that of the “Main Office.” The result would look something like this:

Get-Mailbox | Where-Object {$_.Office -eq “Main Office”} | Set-Mailbox -IssueWarningQuota 2.8GB -ProhibitSendQuota 3GB

Though we have really only scratched the surface with the tips outlined above, PowerShell is capable of greatly simplifying the work for Exchange admins. With its increasing role in the Windows Server operating system and the latest improvements in PowerShell 3.0, its role in the management of Exchange environments will only become more important.

Like this post?

If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free ebook with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!

Configuring Edge Transport Server

The Edge Transport server role was really created to serve as an additional layer to assess and filter incoming messages before allowing them into Exchange proper. In this regard, various policies and rules are used to identify and eliminate spam and other undesirable messages. Do note that it is not installed by default; a deployment done without one is still considered a fully operational Exchange Server messaging environment.

An Edge Transport server works on new incoming messages in the following order:

1. IP Block and Allow Lists are first checked for a match (blacklisting and whitelisting respectively).
2. Next, IP Block List Providers and IP Allow List Providers are checked.
3. The Sender Filtering Agent checks the Blocked Senders list for a match.
4. A Sender Policy Framework (SPF) lookup is conducted.
5. The Blocked Recipients list is checked for a match; this also filters out nonexistent recipients.
6. Content Filtering Agent looks into the content of messages and filters them according to the company’s policy.
7. Mail attachments are then analyzed by the Attachment Filter Agent.
8. Finally, if everything checks out, the message is delivered into Exchange inboxes. Depending on the exact configuration, rejected messages could get an error message, be deleted without further notice, sent to the spam quarantine mailbox, or placed in a user’s Junk E-mail folder.

One downside is that the accurate way to determine the impact or effectiveness of various rules would be to deploy an Edge Transport server in a “live” environment. As such, it makes sense to start with laxer filter configuration so as not to unwittingly delete legitimate emails – slowly tightening it over time.

Third Party Solutions

Administrators who prefer a more autonomous set of spam and malware filtering capabilities than those offered by an Edge Transport server have a number of anti-spam solutions to choose from:

Cloud-based provider: A popular option, anti-spam cloud providers work by redirecting incoming email messages at the DNS MX level, with only legitimate mails being channeled back. This has the advantage of ensuring that no processing and bandwidth overhead enters your network. The downside is that regulatory rules or sensitivity of certain data may preclude this approach.

Spam appliance: The spam appliance is attractive as it prevents CPU cycles from being wasted to process spam. Deployment is also generally straightforward, with little or no need for maintenance. However, spam appliances may be expensive, and prone to hardware obsolesce.

Server deployed: This is usually the preferred option for businesses with on-premise Exchange deployments, and tends to saddle the middle ground between a cloud-based provider and spam appliance in terms of cost. Be prepared for a higher maintenance and administrative overheads here however.

Endpoint protection: Many antimalware suites feature endpoint spam protection. Personally, I least prefer this option due to the general lack of central manageability in such software.

There are many options that can be brought to bear against spam and malware. Indeed, a mix-and-match approach would work too, though it will obviously result in a higher cost. Ultimately, the ideal solution would depend on the company’s infrastructure, its overall budget, as well as the amount of spam that an organization is receiving.

Like this post?

If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free ebook with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!

Built-in Exchange Connectors

Exchange Server 2003 and the earlier versions of Exchange, come with embedded connectors that can be used for Exchange to work with other email systems. For example, the GroupWise Connector or Lotus Notes Connector can be used to connect to the respective systems to facilitate directory updates as well as email messages. However, it is important to note that Exchange 2010 no longer comes with these connectors. As such, the use of the built-in connectors in Exchange 2003 may only be good as an interim measure for businesses that may still be on this old version of Exchange Server.

Forefront Identity Manager

Forefront Identity Manager (FIM) is a product from Microsoft that helps to manage identity information from a variety of heterogeneous directory and non-directory identity stores, presenting it as a single local view that makes for ease of management. The key capabilities of FIM include the management of users, credentials, access and policy. Management agents (MA) within FIM are used to communicate with a specific type of directory that includes the importing or exporting of data.

In short, it is an extremely powerful tool that can be used to synchronize user between Exchange Server 2010, Active Directory and other support third-party directories such as Novell eDirectory, LDAP and UNIX directories. Oracle and SAP are also supported, as with the ability for users to reset their own passwords via a web management interface.

Though FIM greatly simplifies the task of integrating a heterogeneous network, a good understanding of the various environments is necessary in order to deploy the pertinent MA. As such, expect to devote a significant amount of time to properly study, plan and deploy FIM.

Windows Server 2008 Services for UNIX

In situation where an existing UNIX implementation needs to be integrated with an Exchange Server 2010 forest, Windows 2008 Services for UNIX can be leveraged upon to provide the needed interoperability between the UNIX and Windows environment. Earlier versions of this suite of tools were released as Services for UNIX, with the latest separately released version being 3.5; the tools were subsequently incorporated within Windows Server 2008.

Specifically tested versions of UNIX that will work with Windows Server 2008 include Sun Solaris 7.x to 10, Red Hat Linux 8.0 and later, Hewlett-Packard HP-UX 11i, IBM AIX 5L 5.2, and the Apple Mac OS X. As with FIM, a successful implementation of Services for UNIX requires proper understanding of identity management concepts in UNIX and adequate time for planning.

The above tips simply represent a snapshot of the options available to Exchange administrators. Depending on organizational needs, other solutions, such as the writing of custom scripts using ActivePerl or the Windows Scripting Host to reduce overheads and tweak account parameters, may be viable options too.

Like this post?

If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free ebook with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!

Server Roles

Thankfully, Exchange Server 2010 makes it intuitive to scale Exchange deployments with its various clearly defined server roles. A small business can probably install the different server roles (Except Edge Transport Server) onto a physical server, and expand by deploying heavily loaded roles into the new physical server in tandem with the growth of the company.

• Client Access Server (CAS) – Hosts client access via protocols such as POP3, IMAP4, ActiveSync, Outlook Web Access and Outlook Anywhere.
• Edge Transport Server – Typically deployed at the network perimeter or DMZ, this facilitates content filtering before forwarding them onto the Hub Transport Server.
• Hub Transport Server – Works as an internal mail delivery system.
• Mailbox Server – Acts as a backend store house to host mailboxes and public folders.
• Unified Messaging Server – Links up a Private Branch PBX system to Exchange 2010 for voice messaging and fax capabilities.

Clearly, an understanding of the various Server Roles and how they can be expanded is crucial to being able to scale Exchange Server 2010 to support a larger number of clients.

Third-Party Applications

An important but often overlooked consideration is the presence of third-party monitoring applications. For example, internal network appliances may need to relay mail off Exchange Server’s SMTP engine to send out important email alerts to administrators, and CRM (Customer Relationship Management) portals or other internal applications may also generate a hefty load on this front.

Apart from relaying email messages through the SMTP engine, Microsoft has designed Exchange to support hooks for third-party software such as antimalware scanners, backup software, fax software and other phone/PBX features. As this will also have an impact on the system performance, knowing from beforehand how these third-party applications interact with Exchange pays off.

Database Availability Groups

Database Availability Groups (DAGs), is a feature in Exchange 2010 that allows for multiple databases to be spread across multiple servers. While the use of DAGs is primarily geared towards high availability and site resilience, its strengths do address the primary pain points when scaling an Exchange deployment.

Specifically, because DAG allows for multiple databases that tend to be smaller in size, restoration of an individual database from offline storage can complete in a smaller time window compared to a larger database. In addition, risk is mitigated by distributing mailboxes across multiple databases; failure of a single database will only inconvenience users contained within that specific database, instead of all users in an organization.

Configure Your Disk for Performance

A common problem that can severely reduce the efficiency and speed of your Exchange Server would be poor disk performance as server workload increases. One easy way of mitigating this, so that an existing deployment can be scaled without having to rebuild it, would be to separate the Exchange Server database and log files into separate hard drive volumes.

Because log files predominantly consist of write operations, in the same way that the majority of mailbox database accesses are read operations, a relatively clean separation can be achieved by simply storing Exchange and server log files in a separate physically volume from the Exchange databases.

Obviously, other methods exist with which to boost disk performance. Switching to Solid State Drive (SSD) will bring about a tremendous improvement in read and write speeds, but at a much higher per megabyte cost.

There are many considerations that play a part in stretching the scalability of an Exchange Server deployment, and we hope that the above tips will help you plan better, as well as to squeeze some more life out of existing deployments.

Like this post?

If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free ebook with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!

The average IT admin needs to be concerned about a wide range of security threats, such as the prospect of a security breach and denial of service (DOS) attacks. In this post we shall look at five steps admins need to take to protect their Exchange Server deployments from security attacks.

1. Be persistent about security updates

Ensuring that important patches and security updates are applied in a timely fashion is a must when it comes to protecting an Exchange Server from security breaches.  On the downside, if done manually, the installation of a security update can be a time-consuming affair for larger deployments due to the need to take systems offline. David Kelleher touches on this in his post where he suggests the best practices for running server patch management.

On the other hand, the judicious use of virtualization can minimize downtime by allowing administrators to easily test new updates before an actual rollout.  And assuming that mailbox databases are stored on a SAN, the option exists to perform a rollback should catastrophic problems surface at a later stage. Of course, other benefits such as higher scalability and rapid disaster recovery apply.  Indeed, virtualization vendor VMware has put together some nice pages on using Exchange Server with virtualization.

2. Maintain separation using firewall

The creation of server roles in Exchange Server has served to greatly alleviate the challenges of protecting a general purpose email server against external attacks.  Regardless, it would be foolhardy not to place an Edge Transport Server behind properly configured firewalls, preferably within a DMZ.

The concept is simple: to reduce the attack profile by allowing only essential services to be exposed to the Internet.  This is the same philosophy that Microsoft applied to its upcoming Windows Server 8 operating system where the software vendor removed the GUI from the basic base Server Core installation so as to reduce security risks to an absolute minimum.

And while we’re on the topic of narrowing the attack profile of an Exchange Server, it makes sense to tweak things on the network front such as the disabling of HTTP (allowing only HTTPS), as well as ensuring that default digital certificates are not used on Internet-facing server roles.

3. Protecting against DoS attacks

The hard truth is that there is really no easy way to defend against DOS attacks without huge investments to acquire the requisite expertise and to bolster one’s underlying infrastructure capabilities. For most companies faced with a determined and competent attacker, the only viable solution would be to seek the assistance of a DDoS mitigation vendor.

Fortunately, there are a number of tricks that an administrator can employ to foil the occasional troublemakers.  On an Exchange 2010 Transport Server, for example, the Set-TransportServer cmdlet can be used to modify the default control message processing rates, SMTP connection rates and SMTP session time-out values. Moreover, the Set-ReceiveConnector cmdlet can be used to configure inactivity timeouts, maximum number of connections and allowable SMTP protocol connection errors.

Finally, the Set-POPSettings and Set-IMAPSettings cmdlets can be used to configure parameters related to POP and IMAP.  The last two are particularly useful for organizations that don’t implement VPN security but allow users to download their emails from external networks. Ram Mohan’s post on how to defend against DDoS attacks touches on generic techniques further.

4. Have external parties conduct penetration tests

The simplest way to know what hackers are thinking would be to hire someone who can reason in the same way and then task them with finding ways to break into your system.  It is an acceptable practice these days to hire penetration testing engineers, also known as ‘white hats’, to find weak spots in a company’s IT setup.

5. Protecting against zero-day vulnerabilities

By definition, zero-day vulnerabilities are not detectable with current antimalware defenses. It is therefore unfortunate that an increasing number of attacks have been shown to utilize novel exploits.  One possible way of defending against zero-day vulnerabilities would be to install antimalware defenses known as whitelisting software. While nothing is absolute, the use of whitelisting software should offer a level of additional protection against the execution of ‘helper’ software such as RAT (Remote Administration Tool) commonly installed to facilitate hackers’ entry into a compromised server.

Following these five steps may not guarantee ultimate protection, but it will definitely mean you are making the best out of the technologies and methods available to protect your Exchange Server.

Like this post?

If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free ebook with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!

Let’s go through three tricks of using Exchange Server with PowerShell that you might have not been aware of:

1. Windows PowerShell Command Log

Windows PowerShell Command Log can be configured to log every Shell command that runs within EMC. This may be useful for novice admins in order to keep a log of the commands that they have performed. Even expert users operating within mission critical environments may want to enable it so as to facilitate the tracking of mistakes.

The log can be started by clicking on “View…” and selecting “View Windows PowerShell Command Log…” in EMC. Under the “Action” menu, click on “Start Command Logging” to enable logging. The PowerShell Command Log stays resident when logging commands and continues to do so until EMC is closed. It resumes logging when EMC is restarted. Anderson Patricio gives explains this further in his post on using Exchange 2010 Windows PowerShell Command Log.

2. Reviewing the Event Log

Events that pertain to Exchange can often be logged into the Windows Event Log. On a busy server that is used for many tasks however, it may be a hassle to filter out those related to Exchange on a regular basis. One simple and powerful way to leverage PowerShell would be to make use of the Get-Eventlog to export a CSV file of events that pertains to Exchange to regularly check for potential problems that may arise. Saving into CSV allows it to be easily imported and viewed by Microsoft Excel.

Get-Eventlog Application | while {$_.Source –ilike “Exchange*”} | Export-CSV [Path to output file]

3. Parsing Setup Logs for easy Review

Installing Exchange 2010 creates a folder named “C:\ExchangeSetupLogs” which contains numerous log files generated by the installation process. While a normal text editor will suffice to view the generated text files, Microsoft has provided the GetSetupLogs.ps1 script to process the log files. It will highlight warning and critical errors in different color so that an Exchange Administrator can quickly review it for installation errors. To use it, simply run: .\Get-SetupLog.ps1 from the Scripts folder.

Best Practices

Although this post was on using Exchange Server with Powershell, I would like to conclude with some of the best practices related to EMS that may be of help:

• Make use of PowerShell scripting to automate repetitive tasks to save time and reduce mistakes.
• Work on creating a cmdlet and script library that can be reused.
• Develop a naming scheme that makes it easy to identify and intuitively understand the function of cmdlets in your library.
• You can make use of EMS to create reports to identify email users with large mailboxes and user distribution reports, for example.
• Create scripts to perform server administration tasks; use EMS to perform basic administrative tasks such as in the creation, moving and modification of mailboxes.

Like this post?

If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free ebook with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!

1.      Identify the problem

The first step would of course be to identify the problem.  Identification of the issue is important as not only does it allow an estimated timeframe to be worked out and the allocation of sufficient resources, but knowing the problem can also influence whether a full server backup is required.

Below is a short list of some of the categories of problems that may crop up.

• Mailbox content deleted by mistake
• Data is lost, restoration from backup required
• Data is fine, but server just doesn’t boot
• Data is corrupted: Some or all mailboxes inaccessible
• Exchange Server is fine; problem lies somewhere else
• Mail is not flowing between sites
• Mail is not flowing to or from the Internet.

The restoration on mailbox content is actually the easiest to recover from.  This is because data is actually retained in Exchange for 30 days (default), and can be retrieved using the “Recover Deleted Items” tool.  You can read more about the process for items that were deleted normally as well as for “hard deleted” items.

The other issues can be broadly divided into those that require a restoration from data backups, hardware and other issues not directly related to Exchange or Exchange-centric problems.  In a nutshell, administrators may want to establish if the failed Exchange Server is related to data, external factors or Exchange-related problems – or a combination of them.

2.      Perform a full backup of server

Before the initiation of any attempts at recovery, it is imperative that a full backup first be performed on the affected server.  An experienced administrator will know that the race to solve the problem might sometimes cause more harm as a direct results of mistakes made.  Moreover, the installation of patches or updates that causes inadvertent problem may also not be easy (or even impossible) to reverse.

The rational for a full server backup is simple: it serves as a restore point where harmful changes or misconfigurations can be overcome by rolling backwards to the original point.  The exception would be external problems such as those related to the network or misconfiguration of DNS, for example.

3.      Initiate recovery

Only after the creation of a backup should the recovery of a failed Exchange Server be initiated.  Below is a short list of common problems.

Boot failure: Assuming that the boot failure is not caused by a malware attack, initiate the Recovery Console by hitting the F8 key as the boot loader is being loaded.  Problems related to errant system services or problematic applications in the startup queue may be resolved here.

Disk failure: Where RAID is used, a recovery here may be as easy as replacing a failed disk in the array and waiting for it to rebuild.  However, the situation is akin as recovering from a complete server failure should there be no data redundancy, or should multiple disk failure occur.

Complete server failure: The first step to do here would be to file a support ticket with your server vendor.  Depending on support package, a replacement may be delivered in as little as four hours or on the next business day.  The decision at this stage would be to decide on rebuilding a new machine or restoring the server image from a backup.

Database corruption: The steps for partial or complete database corruption may vary, as with the tools that can be used.  On this, I recommend reading Understanding Backup, Restore and Disaster Recovery from TechNet for additional background on the technology and methodologies behind data recovering for Exchange 2010 here and using Recovery Storage Group to restore Exchange mailbox data from earlier versions of Exchange here.

Configuration problem: While easy to resolve in the hands of an experienced Exchange administrator, it can also result in larger problems being caused by consecutive or multiple configuration mistakes.  Making a proper backup before proceeding is highly recommended here.

4.      Preparing for easy recovery

Finally, it makes sense to prepare adequately for disaster before they actually hit.  One way to do so would be to configure your Exchange with redundancy or failover in mind.  An alternative for businesses that cannot afford failover hardware is to ensure the presence of sufficient storage space to facilitate the creation of server backups mentioned earlier.

Another way to be prepared would be to ensure that the Exchange Server environment is properly documented.  Some of the information that should be documented includes the server name, version of Windows, version of Exchange Server, database names, location and size of databases.  On this front, Microsoft has a utility called ExchDump that can assist administrators in creating a baseline snapshot of an Exchange environment.  The utility can be downloaded here.

Like this post?

If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free ebook with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!