There are many reasons why an organization would make the move to Exchange Server 2010. Features like email archiving, increased discovery capabilities, greater flexibility and the lure of anywhere access make this email solution a promising one.

However, these features are generally ones that are used to sell management on an upgrade or switch. For administrators, the PowerShell is usually a feature that gets them on board.

The PowerShell feature of Microsoft Exchange is similar to what some email administrators who worked in a UNIX-based environment are accustomed to.

Giving admins the ability to automate repetitive tasks with scripts, called cmdlets, helps save time as many find navigating through GUI menus and submenus looking for the right actions to be wasteful when the same thing can be done by running a few lines of code.

Understanding the basics

PowerShell is installed by default on Exchange 2010. To launch it you will need to be on a workstation, or server, where you have installed the Exchange Management Tools. By clicking on Start | All Programs | Exchange Server 2010, you will be presented with the Exchange Management Shell shortcut. Clicking on this icon will launch the shell for you to get started.

Cmdlets follow a pretty simple syntax. To run a command in PowerShell you simply type in the name of the cmdlet followed by a hyphen and then any parameters. The value of the parameter comes after the parameter name itself and can be wither option or required depending upon which cmdlet you are running. So an example cmdlet would look like this:

Set –Mailbox username –MaxSendSize 5mb -MaxReceive Size 10mb

The result would be to modify the user’s mailbox so that he or she could only send messages under 5mb but would allow them to receive messages up to 10mb. Of course you would need to supply an actual username.

There are times when PowerShell will ask for confirmation before the cmdlet takes the requested action. For example, if you were removing a mailbox the shell will ask you “Are you sure you want to perform this action?” followed by an explanation of what you are about to do.

While you can easily hit the Y key to confirm, or the A key to say Yes to All, you can also turn off the confirmation with the –Confirm:$false parameter.

Parameters also don’t always have to be typed out fully. You can use a shortcut by typing enough characters of the parameter name to differentiate it from any other parameters. An example of this is the –Identity parameter. A valid substitution for this can be –id since this is unique enough to meet the requirement. Since –Identity is one of the most frequently used parameters, this shortcut can be quite helpful.

Wildcards can also be used cmdlets. To use a wildcard the asterisk, “*”, is entered after the characters you select. An example of this can be seen in the following where we set the mailbox sizes for only those that start with the letter “a”:

Set –Mailbox –id a* –MaxSendSize 5mb -MaxReceive Size 10mb

The final tip to getting started in PowerShell deals with the use of single and double quotes in your scripts.

Whenever the values for your parameters require a space, the values need to be enclosed. Most commonly the single quotes would be used for this as in the following example:

Get-Mailbox -OrganizationalUnit 'yourdomain.com/Management Users/Chicago'

This cmdlet will retrieve information for all uses in the specified OU.

Double quotes are used when you expand a variable within a string:

&City=Chicago

Get-Mailbox -OrganizationalUnit “yourdomain.com/Management Users/$City”

Get yourself some help

The help system for any scripting should be your first resource if you run into trouble. When it comes to the PowerShell, help is just a command away.

Get –Help followed by the name of the cmdlet is all you need to type. If you want to get more information about the Get –Mailbox cmdlet then you would enter:

Get –Help Get –Mailbox

To get more specific information, you can use these switches:

• -Detailed – Provides parameter descriptions and examples
• -Examples – Provides multiple examples of how the cmdlet can be used
• -Full – Provides you with the all the help content regarding the cmdlet

So for everything dealing with the Get –Mailbox cmdlet you would type:

Get –Help Get –Mailbox –Full

Again, all of these actions can be completed using the GUI provided with Microsoft Exchange 2010, but having a strong familiarity with the PowerShell not only allows you to get through some tasks a bit quicker, but can be a lifesaver in many circumstances.

PowerShell Basics in Microsoft Exchange 2010

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

With another round of issues facing users of Microsoft’s Exchange Online service the launch of the Business Professional Online Services replacement, Office 365, is starting to face questions by consumers who are starting to think that Microsoft’s cloud based services may not have much of a silver lining.

Exchange Online is a hosted messaging solution, like Google’s Gmail for businesses, and is based on the same technologies that run the ever popular Exchange server. However as this is a hosted solution, the business does not need to dedicate the same resources towards messaging as they would if they were running their own email servers on-site. Since messages are stored in the cloud, Exchange Online users have “From virtually-anywhere” access to e-mail. Also touted by Microsoft’s website is:

• Improved email security
• Enhanced operations efficiency for a company’s IT staff
• 25-gigabyte mailbox storage size for the standard license

Most importantly, users who have become reliant on Microsoft Outlook and its tools can find the move to hosted email seamless unlike the issues that arise when using Outlook with other hosted email services.

What seems to be the problem?

In early May, most BPOS users experienced loss of service for up to nine hours one day followed by sporadic outages over the next couple of days. Without email services, many businesses found their productivity crippled.

Ironically, email services hosted in Microsoft’s beta offering of Office 365 were not affected by the outages and service here did not have any of the issues that BPOS had. However the timing of these recent problems couldn’t be any worse.

Microsoft’s reputation is still tarnished by the problems associated with Windows Vista and Internet Explorer is often thought of as an inferior product when compared to competitors, so making headlines once again due to service related issues is not the best thing when launching a new product. Even if the product addresses the problems you are infamous for.

Is there light at the end of the tunnel?

Most people understand that there is no such thing as 100 percent uptime when it comes to technology. Ask Gmail users if their service is always up. Things are bound to fail at times. And to Microsoft’s credit they responded to the problems quickly, provided users with a temporary workaround to restore service and they identified the root cause of the issue in a short period of time. Unfortunately most people aren’t in the habit of giving Microsoft much credit for anything.

What we can learn from this

Email administrators understand all too well the importance email service plays in the ability for a business to operate efficiently. When email is down workers grow impatient, management grows frustrated and the email administrator’s popularity rapidly wanes.

In order to handle a disruption in productivity any business that relies on the cloud for essential services, like email, should have a back-up plan. One thing that is promising with Office 365 is that it offers a hybrid approach to email. Using Exchange Server 2010 on site in the hybrid deployment scenario that Microsoft offers can help an organization better deal with outages in their cloud services. Conversely, being able to access email via the cloud keeps things moving when the Exchange server goes down as well.

Microsoft’s Office 365 community website points out that the cross-premise messaging solution (hybrid deployment) offers the following features to help lure potential customers:

• Mail routing between on-premises and cloud-based organizations
• Mail routing with a shared domain namespace (For example, both on-premises and cloud-based organizations use the @contoso.com SMTP domain)
• Unified global address list, also called a “shared address book”
• Free/busy and calendar sharing between on-premises and cloud-based organizations
• Centralized mail flow control; the on-premises organization can control mail flow for both organizations.
• A single Outlook Web App URL for both the on-premises and cloud-based organizations
• Move existing on-premises mailboxes to the cloud-based organization
• Centralized mailbox administration using the on-premises Exchange Management Console (EMC)
• Message tracking, MailTips, and multi-mailbox search between on-premises and cloud-based organizations

Despite recent problems, Office 365’s email solution looks rather promising. One Microsoft is able to do some PR related damage control it looks like they will be able to make a solid run at cloud based email services and give Google Mail something to think about.

Is Microsoft Exchange Online Only Half-Baked?

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Exchange administrators are probably quite familiar with management pressure or subtle ‘suggestions’ to migrate for a cloud-based email service, typically epitomized in the form of Google Apps.  As someone who believes in utilizing the best tool for the job, I am of the opinion that there are businesses and organizations that will certainly benefit from shifting to a cloud-hosted email service.  However, some companies might be opting for Google Apps due to what they hear about its supposed reliability and affordability, but neglecting to perform a factual evaluation.

While some might argue that a comparison of Microsoft Exchange with Google Apps is like trying to compare apples to oranges, there are fundamental similarities in an email service that we can use as a benchmark.

• Reliability

Most readers must have heard of the Gmail Crash that took place on the last weekend of February.  Triggered by an unexpected bug, I suppose it put rest to the idea that cloud-hosted services are infallible.  This incident confirms my personal opinion that a comparison of the system reliability and uptime is only meaningful up to a certain number of 9s, due to an inherent chaos (or Murphy’s Law) that cannot be anticipated.  When seen from this angle, a properly maintained Exchange Server is equivalent to a well-run cloud service, which brings me to the next point.

• Maintenance

A typical on-premise version of Microsoft Exchange requires regular maintenance in the form of software updates and checks to ensure that system readings are within expected parameters.  As you can imagine, smaller businesses could find these tasks a hassle compared to the hands-off nature of a service like Google Apps.  Microsoft is not oblivious to the likelihood of businesses without dedicated administrators ditching Exchange Server however, and now offers the option of Hosted Exchange for businesses that wants the capabilities of Exchange Server without its maintenance overheads.

• Data Backup

Despite the severity of the data corruption bug, Google has pretty much proven that it has a robust off-site backup regime that works.  Of course, this has not stopped a rash of hitherto unknown companies from coming forward to offer various data backup solutions in the wake of the incident, capitalizing on the desires of users and administrators who want more control over their archived data.  This is where Microsoft Exchange wins hands down in terms of management and access to archived email messages.  In contrast, some affected Gmail users were left in the dark for up to four days as Google scrambled to recover and restore from data backups.

• Spam Filtering and Anti-Malware Protection

When it comes to spam filtering, there is no doubt that Gmail incorporates an exceptionally good spam engine.  In addition, users can create their own filters to trash email messages based on custom parameters.  Exchange does offer the ability to install complex server-side filters too; though my personal experience pegs its default spam capabilities as being the weaker of the two.  However, Exchange Server when set up on-premise does offer far greater flexibility when it comes to deploying third party tools, such as using GFI’s MailEssentials for spam filtering and Microsoft’s Forefront Protection 2010 for Exchange Server for a comprehensive security suite.

• Usability

I’ve personally found Google’s Gmail interface to load rather briskly.  In addition, I am generally able to perform better searches via the Gmail search box than in Microsoft Outlook.  Ultimately however, I’ve found that I’m much more productive via Outlook 2010 with its threaded email view and ability to connect simultaneously to multiple Exchange Servers.  Similarly, administrators should also be cognizant that existing users might resist any changes from what they are comfortable with, be it Microsoft Outlook or the Outlook Web App.

• Integration

Some of the business-centric capabilities touted by Google Apps for Business would be BlackBerry and Microsoft Outlook interoperability.  While Google has done an excellent job in creating tools that bridge between its cloud-based systems and end-user software such as Microsoft Outlook, administrators must remember that these tools do not necessarily work perfectly.  Moreover, some of the support is achieved by additional software that must be installed on client-side devices (BlackBerry smartphone support).  I last looked into switching from my Exchange environment to Google Apps late last year, but I was forced to discard the idea after research showed complaints about the presence of software bugs as well as user dissatisfaction on some fronts.

Feel free to chip in below if you have any other comments.

Comparing Microsoft Exchange with Google Apps for Email

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

On 15th April, Microsoft announced the availability of Exchange 2010, the successor to Exchange Server 2007. According to Microsoft:

Exchange 2010 is part of the next wave of Microsoft Office-related products and is the first server in a new generation of Microsoft server technology built from the ground up to work on-premises and as an online service. This release of Exchange 2010 introduces a new integrated e-mail archive and features to help reduce costs and improve the user experience.

What’s new in Exchange 2010? Here’s some details:

• Integrated archiving capabilities
• Cross-browser support and integrated IM capabilities for OWA
• A conversation view which will enable users to collapse messages into groups, streaming and reducing clutter in the inbox
• Voicemail preview
• MailTips which Microsoft say will, “Warn users before they commit an e-mail faux pas such as sending mail to large distribution groups, to recipients who are out of the office or to recipients outside the organization, helping protect against information leaks and reduce unnecessary e-mail messages.”

The MailTips option certainly sounds interesting. I wonder whether it will prove to be more of a help or a hindrance.

You’ll be able to transition (no, an in-place upgrade is not an option) from either Exchange Server 2003 or 2007 but, if you’re running anything earlier, there will be no supported direct upgrade path all – but, no doubt, some third-parties will produce tools that will help make life easy for those wanting to switch from one of the ye olde versions.

You can grab a copy of the beta here. The Exchange 2010 TechNet forum is already open for business and can be accessed here. Be sure to let us know what you think.

The Public Beta of Exchange 2010 is Available

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

The benefits associated with archiving Microsoft Exchange email and associated data, creates many cost effective solutions. Archiving facilitates government regulatory or civil litigation searches for ediscovery requests. It also allows for more complete archive journaling, and provides storage benefits for both mailbox growth and the various storage devices that can be utilized.

Although lowering storage reduction costs is a common denominator for email archiving, compliance requirements are moving more companies to implementing archiving strategies. Depending on the motivation factors, cost savings on storage are subject to interpretation by different people.  For some people, compressing email could reduce licensing, as well as storage hardware costs.  For others it may mean creating a mailbox for end users, which has virtually unlimited space.

The majority of Microsoft Exchange Server archiving solutions have some form of compression that reduces the size of overall archived emails.  For an Exchange email administrator, an unlimited space mailbox really just means eliminating the user responsibility of being concerned about having to archive their email. This allows mailboxes to grow as long as there is more than adequate disk space real estate available to allow seamless expansion.  The limitations of unlimited mailboxes are usually determined by the archiving options provided by the archiving solution. According to the Ferris Research blog, Microsoft recommends against using stubbing techniques.  Microsoft further recommends using 3rd party email archiving solutions that allow configurations to move email messages completely out of the mailbox without leaving stubbing foot prints  inside the mailbox.

6 different stubbing techniques are provided below only for informational purposes, but are not best practices recommended by Microsoft.

1. Substitute body and attachment with a plain text Stub
2. Substitute body attachment with HTML Stub
3. Maintain plain text body only with deleted attachment
4. Maintain HTML message body only, with deleted attachment
5. Maintain HTML body and image with deleted attachment
6. Message attachment residing in the archives

Will your current archiving procedures or planned archiving solution meet all future email storage requirements?

Archive Stubbing Techniques Not Recommended

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

“The more the better,” is a common mantra when it comes RAM but, in the case of Exchange Server 2007, that’s certainly not the case (OK, so it isn’t really the case in relation to other operating systems either, but that’s for another story).

With Exchange Server, Microsoft recommend no more than 32 GB of RAM. That’s because a) more than 32 GB will not substantially improve performance (and so you’d be wasting your money) and b) it may actually negatively impact performance. Here’s why (from Microsoft):

Cold state is defined as the state of the Mailbox server immediately following a server reboot or store.exe process restart. The Database Cache, which is used to cache database read/write operations, is small in size (or “cold”) during this period so it has a significantly diminished ability to reduce read I/O operations. As the Mailbox server processes messages, the Database Cache Size grows which increases the effectiveness of the cache and subsequently reduces the I/O footprint of the server. The larger the physical memory size of the server the longer it takes the Database Cache size to reach its optimal size. If the storage is designed/sized for a server with a large amount of physical RAM (>32GB), and the I/O profile of the users assumes an optimal Database cache state (large/warm cache); then the client experience may be compromised due to insufficient disk performance during these “cold state” periods.

So, does this mean that you need to put exactly 32 GB of memory into your Exchange Server in order to derive the best performance from it? Nope, it most certainly does not. Adding up to 32 GB wouldn’t degrade performance, but it wouldn’t necessarily improve performance either – and so you’d be wasting your money.  The optimal amount of RAM that you’ll want to put into your Exchange Server will depend on its role, but here’s how you’d work it out for a mailbox server. The first thing to do is to grab a copy of the Microsoft Exchange Server Profile Analyzer and work out whether you have “light” users, “average” users or “heavy” users (no, that doesn’t mean that you need to weigh Big Bertha in accounts, it simply means you need to work out how many messages she – and the other users – send and receive on average). Armed with that information, you can then work out how much memory you need as follows:

2 GB + 2 MB per user (light users) = Total memory needed
2 GB + 3 MB per user (light users) = Total memory needed
2 GB + 5 MB per user (light users) = Total memory needed

So, for example, if you were to have 1000 light users, you’d want 4 GB of RAM (2 GB + (1000 x 2 MB). Additional memory would be needed if you need to create more than 8 Storage Groups (which is the maximum that 4 GB will support).  

For more detailed information, see Microsoft’s Exchange 2007 Processor and Memory Recommendations.

How Much Memory is Too Much?

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators