Google recently hung a ‘going out of business’ sign on its Message Continuity service for users of Microsoft Exchange. Google will continue to provide the service to its users until their contracts run out, but after that, they’re on their own.

Since the service was launched a little over a year ago, “hundreds” of businesses have subscribed to the offering, which uses Google’s cloud to provide email continuity when a Microsoft Exchange environment is interrupted for any reason.

Hundreds of users, though, can’t compete with the “millions” of businesses that have moved their entire email operation to Google Apps, so Searchzilla has decided to scrap its continuity product for Exchange  and concentrate all its resources on its application suite.

Current users of the continuity product were “encouraged to consider using Google Apps as their primary messaging and collaboration platform” in a company blog written by Vice President of Product Management Dave Girouard.

The brusque departure by Google from the Exchange disaster recovery scene contrasts sharply with how it entered it:

“Google Message Continuity advances our commitment to providing rapidly deployed, cost-effective email management solutions for organizations of all sizes,” Enterprise Product Manager Matthew O’Connor wrote when the continuity product was announced.

Looking back on the announcement, it appears that Google’s “commitment” to the Exchange market was as solid as an adolescent’s commitment to the latest fad.

That’s not to say that Google’s intentions in offering an Exchange product weren’t clear from the start for careful readers of the company’s pronouncements. “Additionally, for organizations interested in eventually moving to Google Apps, Google Message Continuity can provide a smooth bridge to the cloud,” O’Connor slyly observed in his blog item.

O’Connor’s colleague, Rajen Sheth, the group product manager for Google Apps had a similar pitch at the time:

“Google Message Continuity can also help organizations transition to Google Apps down the road,” he wrote. “Since Microsoft Exchange and Gmail are always in sync with one another, there’s no need to migrate email data when eventually deploying Google Apps.”

Little did those who signed on for Google’s continuity solution realize when they did so that if they didn’t “transition” to Google Apps fast enough to suit the Ferret King, they’d be left looking for another business interruption solution within a year’s time.

Google has been criticized in the past for its flighty attitude toward product development. Some detractors maintain that Google often enters markets to be disruptive, not competitive. Like a sea gull boss, it will undercut competitors in a market and when things don’t work, abandon that market, leaving customers who had faith in the Google brand to clean up the mess.

That kind of product management may work with consumers, but it leaves something to be desired in the business world. Google’s competitor in the enterprise market, Microsoft, knows that. While the Redmond crew have suffered a few slings and arrows for sticking with products too long, their commitment to legacy products has been an important, if sometimes overlooked, part of their success in the business market.

Google’s forsaking of Message Continuity brings to mind some remarks by Microsoft Senior Director of Online Services Tom Rizzo in his famous “Google Graveyard Spooks Customers” blog written on Halloween last year:

“Google releases experimental products and tracks adoption to determine whether to continue providing them,” he wrote. “Its products are like spaghetti, Google throws them up against the wall to see if they stick.”

“The burials of de-supported products are more examples of what is convenient for Google and not good for business,” he added.

Google Deserts Exchange Users by Killing Message Continuity

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

As the end of November draws near, anticipation is building that Service Pack 2 for Exchange 2010, which was announced in May, will finally be released. Given Microsoft’s track record with the last two roll-up updates for the software, you really can’t blame Redmond for being extra careful with this service pack.

Although originally expected to make it out the door at the end of October, it appears that the new deadline for the service pack is sometime next week, if Microsoft’s general manager for Exchange, Kevin Allison is to be believed.

At a trade show earlier this month, Allison fudged the issue of the missed deadline by saying that Microsoft had always intended to release SP2 for Exchange sometime in the fourth quarter. Of course, that gives the company all the way to December 31 to let the update into the wild, but he appeared confident that release would come by early December at the latest.

Allison told show attendees that Microsoft considered it critical that SP2 be as bug free as possible, and it was paying particular attention to quality with this release. That sort of begs the question, though, are there updates where the company doesn’t pay particular attention to quality?

Certainly flaws in quality control came to light during the embarrassing releases of two Roll-Up Updates earlier this year, RU3 and RU4. As might be expected, much of Microsoft’s quality control is automated. For example, the code for Exchange is subjected to a suite of well over 100,000 automated tests. In addition to those tests, there’s some manual validation. None of that testing, though, caught the bugs in the two Roll-Ups.

Those muffs could leave a casual observer scratching their heads. In RU3, for example, Blackberry smartphone users found themselves receiving an extra copy of their messages. Even if a flaw like that bypassed the automated tests, you’d think that one of the manual testers with a Blackberry would have discovered the problem. Maybe all the testers were using only handsets running Windows Mobile 7.

The RU4 gaffe was equally puzzling. When users moved or copied a public folder, they found the contents of folder had disappeared. In fact, the contents hadn’t disappeared. It had merely be shipped to the Recoverable Items folder. While it’s well known that Microsoft frowns on the use of public folders, still, not one tester tried to copy or move such a folder during the testing regimen?

Service Pack 2 for Exchange 2010 will have some nice new features. Corporate users without a smartphone will find accessing Outlook via a web easier with OWA Mini. Double logins to OWA will be eliminated for some users with cross-site silent redirections. Hybrid configurations that support local and cloud deployments can be set up. And segmented address books, which can be managed directly from the Exchange Management Console, will be added to the software.

Nevertheless, it remains to be seen what effect past missteps by Microsoft will have on how rapidly SP2 is adopted by the Exchange 2010 community. Despite Redmond’s pledge that it has beefed up its quality assurance on this update, there’s no substitute for testing, testing, and more testing before any organizations fully deploys the update.

Microsoft Exchange 2010 SP2 is Coming Soon

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

Last month, I posted an article titled “What’s a good mailbox size?” where I discussed many of the considerations an architect must take into account when sizing storage for a new email system. In that post, I also set up a survey where I asked readers to answer six short questions about what they think makes a good size for a mailbox, as well as what future plans they might have for system growth. As promised in last month’s post, I am sharing the results of the survey now.

While the total number of respondents was somewhat less than I hoped for, the quality of those responses from survey participants is greatly appreciated. No one skipped any of the first four questions; the last two were “if” type and should have been skipped if not applicable. Thanks to all those who took the time to share their answers. I will share each question and the responses by percentage below.

1. What email system are you running now?

The vast majority of respondents are running Exchange, with a smattering of Notes, but nothing else apparently. While the dominance of Exchange was no surprise, that not a single Groupwise or Sendmail admin responded makes me wonder whether those products are dying out, or if their admins simply are too busy to deal with surveys.

2. What is the standard mailbox size (in MB) for regular users?

Almost half of those responding give standard users mailboxes less than half a gig. Those results shocked me on their own, but wait until you read question four!

3. What is the standard mailbox size (in MB) for special users (IT, executive, HR, or any other group that needs a larger mailbox)?

It looks like half of the admins who responded draw no distinction between regular users and special users. How egalitarian of you. We do see an uptick in the sizes though, with the other half of you giving special users 5 GB or more of storage space.

4. Is your current mailbox size adequate for the majority of users?

Okay, this is the answer that floored me. Over 90% of respondents feel their mailbox sizes are adequate. Considering how many provision regular users with less than half a Gigabyte, that is not at all what I would have expected. If you are one of those folks, please let us know in the comments how you do it. Do you have an aggressive deletion policy, an archiving solution, or do you just prohibit attachments? Inquiring minds want to know.

5. If you are considering a larger mailbox size for regular users, how big would you like that to be?

This is another response that did not come out like I expected. No one is looking for huge mailboxes (>25 Gigabytes) and most look like they would be happy with 10 GB or less. Storage vendors may weep to see this.

6. If you are considering a larger mailbox size for special users, how big would you like that to be?

Now we see an expected distinction, where special users will get much larger mailboxes. The designers of Exchange 2010 are smiling that so many of us share their vision.

So to summarise, the vast majority of regular users’ mailboxes are either in the 512MB range, or in the 1 to 5 GB range. In about half the cases, special users get a bump to 5 GB or larger. Most of us are happy with our mailbox sizes, but if we were going to increase them, it’s only the special users who’d really see a big change, and no one seems to want to go above 25 GB for mail.

Once again I’d like to thank those of you who participated in the survey for your time and the information you shared. I know it will be very useful to me, and I hope that other regular readers of TheEmailAdmin can also benefit from this.

Are there any other issues you’d like to see surveyed and discussed here? Any questions you’d love to see asked in such a large forum? If there are, leave a comment and if I get enough good ones, I will create another survey for the readers so we can see just how everyone else is doing it.

As it Turns Out, a Good Mailbox Size Is…

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

Microsoft’s newly launched Office 365 offers powerful, intuitive controls for businesses looking to deploy a cloud-hosted collaboration and messaging solution.  I was able to get my own trial account activated in just 10 minutes, faster than any hosted Exchange providers that I’m aware of.  In addition, the presence of a free 30-day trial means that businesses and individuals can experiment with – or even deploy – various components of the service without having to part with a single cent.

As I’ve explained in Why Office 365 is good for Exchange Administrators, Office 365 can actually help to bolster the popular of Exchange Server; enhancing the career prospects of experienced Exchange administrators in the long-term.  Moreover, many of the reasons to consider an on-premise deployment of Exchange Server remain just as relevant today.  This includes a greater choice of anti-spam and anti-malware solutions, heightened confidentiality, compliance, as well as increased backup and archival options.

Companies on the fence about deploying Exchange or new businesses lacking the budget for on-premise Exchange Server will definitely want to start off with Office 365.  Depending on individual requirements, businesses can migrate to a full-fledged Exchange Server at a later date.  To assist administrators who may be thinking of starting off their Exchange deployment on Office 365, I shall be exploring the capabilities of the various plans today with a specific focus on Exchange Server.

Office 365 for professionals and small businesses

Positioned towards professionals and small businesses, Plan P is touted as a plan that offers value-for-money.  It is easy to see its attraction when one considers its Exchange capabilities, as well as the presence of SharePoint Online and Office Web Apps.  The downside is lower levels of support: don’t bother calling Microsoft when you encounter any problems.  Moreover, note that Plan P has an upper limit of 50 user licenses, and does not support Active Directory Sync.(Though the Plan P product page says “fewer than 25 users”, it does not stop users from buying up to 50 user licenses).

According to the official FAQ, a company growing beyond 50 users will need to cancel their Plan P and manually switch to a Plan E. You heard it right; there is no automatic migration for businesses that outgrow Plan P.  Finally, do note that Plan P does not officially support what it calls “vanity” domain (yourname@yourdomain.com), but defaults instead to yourname@yourcompanyname.onmicrosoft.com.  There are a couple of workaround strategies fortunately, which I shall outline in my next article. And yes, Plan P includes premium antivirus and anti-spam filtering with Microsoft Forefront Online Protection for Exchange

Despite its shortcomings, its low price of US$6 per user per month makes Plan P a compelling offering indeed.  The Plan P1 trial includes 10 user licenses.  You can read more about Plan P here.

Office 365 for midsize businesses and enterprises

Plan E comes in various configurations that range from E1, E2, E3 to E4.  Priced at US$10, US$16, US$24 and US$27 per user per month, the various offerings under Plan E include the license rights to access on-premise deployment of Exchange Server, SharePoint Server and Lync Server – more about possible deployment scenarios another time.  E1 excludes online document viewing and editing capabilities with Office Web Apps, while E3 and E4 include the desktop edition of Office Professional Plus.  Do note that a trial is only available for Plan E3, which includes 25 user licenses.  You can read more about the various offerings under Plan E here.

Other Online Exchange options

Businesses that require only Exchange Server services will be interested in the “Kiosk Worker Plans” called K1 and K2.  Both plans offer 500MB of mailbox storage and are priced at just US$4 and US$10 respectively.  It is important to note that both plans offer the Outlook Web App as the only interface to standard Exchange services such as email, calendar, contacts and the company directory.  Microsoft Outlook is not supported, although POP access is. The slightly pricier K2 plan comes with the ability to make basic edits to documents with Office Web Apps.

Finally, administrators or individuals interested in Exchange Online-only plans may want to check out the various plans tucked away here.  Exchange Online is offered at just US$5 and US$10 per month and includes access via PC (Microsoft Outlook), Exchange ActiveSync (EAS) and Outlook Web App.  A final Exchange Online Kiosk plan mirrors the K1 plan by doing away with Outlook and EAS support (no contacts and company directory too) for a rock bottom price of just US$2 per user per month.

Have you given Exchange Online in Office 365 a spin yet?  Feel free to share your experiences.

A Closer Look at Exchange in Microsoft’s Office 365

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

As administrators we hear a variety of complaints throughout the week. Some complaints we acknowledge with a minimum of a head nod and an “I’ll get to it as soon as I can” response. Other complaints such as “The system is down” or “I don’t have access to email” capture our attention immediately. But some complaints fall in the middle.

One such complaint is that “…searching on my emails seems slow”. This is an issue that usually means something has broken and will require some time to fix. It also means that if allowed to continue it could also have a greater impact on employee productivity.

Think of the various departments that are dependent on their abilities to search email. For instance, your sales and support departments rely on their abilities to satisfy their customer needs and so they often must search through old emails for keywords such as their competitor’s names or products. Likewise a law firm or office will want to search on emails involving their casework that might relate to their current caseloads.

So searching on email can be considered a key and necessary component to effective business operations. It is a component of business that can be considered critical to have in order to be a successful business. And so as an administrator in an IT organization it must have a high priority.

An example environment where mailbox searches fail could involve Exchange Server 2007 with mailbox servers in a CCR cluster. One server might host the CAS and Hub Transport roles. If users begin to complain about failed searches using Outlook then an administrator can review the Application event logs of the active mailbox server node. They might find events such as the following:

Event Type:    Warning
Event Source:    MSExchange Search Indexer
Event Category:    General
Event ID:    107
Date:        2/11/2009
Time:       10:45:13 AM
User:        N/A
Computer:    CSUSD10
Description:
Exchange Search Indexer has temporarily disabled indexing of the Mailbox
Database E2K7CCR-SG2\E2K7CCR-MBXDB1 (GUID =
b456f687-5445-4d7d-a2c4-15ef0424db14) due to an error
(System.ComponentModel.Win32Exception: Unknown error (0×80043613)
at Microsoft.Exchange.Msfte.CSrchProject.SendBatch(BatchInformation
batchInformation)
at Microsoft.Exchange.Search.NotificationQueue.ProcessingProcedure()).

Event Type:    Warning
Event Source:    MSExchangeIS Mailbox Store
Event Category:    General
Event ID:    1025
Date:        2/11/2009
Time:       10:45:41 AM
User:        N/A
Computer:    CSUSD10
Description:
An error occurred on database “E2K7CCR-SG2\E2K7CCR-MBXDB1″.
Function name or description of problem: Content Indexing received an
unusual and unexpected error code from MSSearch
Error: 0xc0041800

Event Type:    Information
Event Source:    MSFTESQL-Exchange
Event Category:    MSFTESQL Service
Event ID:    4138
Date:        2/11/2009
Time:       10:48:43 AM
User:        N/A
Computer:    CSUSD10
Description:
An index corruption was detected in component ShadowMerge in catalog
ExSearch-b456f687-5445-4d7d-a2c4-15ef0424db14-8976c3aa-307b-4284-b276-9efbe4a4eef3. Stack trace is .Component: MicrosoftIndexer

These events are usually indicative of a problem with the Search Indexing function. Further inspection would probably reveal that the Exchange Search Indexer service keeps trying to enable indexing on the databases but is unable to do so. And the result is the regeneration of the events listed above. Attempts to restarting the Microsoft Exchange
Search Indexer service appear to work at first glance but then the indexing service becomes disabled shortly thereafter.

The resolution to this problem is to rebuild the Full-Text Index Catalog. There are two ways to rebuild the full-text index catalog.

The first method is to rebuild it programmatically via an Exchange Management Shell script. This method involves manually deleting the full-text index catalog directory. An administrator can programmatically rebuild the full-text index catalog by running the ResetSearchIndex.ps1 script provided at <drive>:\Program Files\Microsoft\Exchange Server\Scripts\.

Note that in order to rebuild the full-text index catalog the account an administrator uses must be delegated membership in the local Administrators group. Here are the steps to rebuild the Full-Text Index Catalog using the ResetSearchIndex.ps1 Script.

1. Start the Exchange Management Shell.
2. Remove the index directories that are associated with specified mailbox databases: ResetSearchIndex.ps1 [-force]  <dbname> [<dbname>]
3. Remove the index directories that are associated with all mailbox databases: ResetSearchIndex.ps1 [-force] -all

The second method is to manually rebuild the full-text index catalog. But a manual rebuild involves additional steps. As with the script-based method it should be noted that the account an administrator uses must be delegated membership in the local Administrators group. Here are the steps to manually rebuild the full-text index catalog:

1. Rebuild the full-text index catalog.
2. Stop the Microsoft Exchange Search Service.
3. Delete the old catalog
4. Restart the service.

Rebuilding the full-text index catalog manually forces the server to re-create the full-text index catalog.

Troubleshooting Mailbox Database Indexing

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

The fruits of a partnership announced last year by HP and Microsoft have finally ripened with the announcement of a new series of application appliances aimed at simplifying the deployment of critical business software programs, including Exchange 2010.

The Exchange appliance, the HP E5000 Messaging System, will be available in March starting at $36,000, plus the cost of a software license. It’s designed to meet the design goals of Exchange 2010–including the creation of low-cost large mailboxes that can be scaled quickly to meet growing data demands and are available 24 hours a day, seven days a week–and to reduce the complexity of deploying and optimizing storage for critical business messaging.

With the new appliance, an organization can cash in, with a minimum of pain, on Exchange 2010 benefits, such as boosting user productivity by removing archival functions from the desktop with the elimination of *.pst files, improving performance by adopting new IO patterns that reduce IOPS requirements by 85 percent and decrease storage demands and costs with built-in replication for direct attached storage.

According to HP, in the next 12 months, more than a third of all IT organizations will be upgrading to Exchange 2010 to take advantage of those benefits. When doing so, those enterprises will be facing some hard questions. For example, how should they configure their server? What type of storage should be used? How much network bandwidth will be enough, and should they virtualize or not?

Those questions and others can be easily addressed by the new messaging appliance, HP maintains. It claims the new box can “radically simplify” the delivery of Exchange 2010′s innovations to an organization and because it’s optimized for the software, it can give an outfit everything it needs to streamline deployment, ensure high performance and availability and keep the total cost of ownership for the deployment attractive.

When designing the E5000 system, the HP design team had three goals, according to Dean Steadman, the company’s worldwide product manager focusing on unified storage solutions for Microsoft applications. It wanted the product to be complete, simple and agile.

• Complete. It had to address highly available servers, storage, networking, Windows licensing, support services and Exchange best practices. For example, it addresses high availability by combining HP hardware redundancy with Exchange’s Database Availability Group features. “E5000 customers can sleep at night knowing that their high availability, performance tuning and capacity planning was designed by the industry experts,” Steadman boasted.
• Simple. As much of the system as possible is pre-configured at the factory. Microsoft Windows Server 2008 R2 Enterprise Edition is preloaded on the hardware and all its storage formatted and configured. Those moves alone should save administrators a day’s worth of deployment time, according to Steadman. What’s more, the system contains custom tools to further speed up deployment and quickly integrate the system into an existing Windows infrastructure. In addition, the system plays nicely with management suites like HP SIM and Microsoft System Center.
• Agile. The system is built to accommodate the requirements for a variety of architectures and to adjust to changing business requirements. “We knew that a one size fits all approach wouldn’t work for Exchange,” Steadman said. That’s why the system is designed to work in a single site or standalone deployment, as well as in organizations with multiple data centers or branch offices. To boost the availability of a deployment or address a growing need for mailboxes, up to eight E5000′s can be clustered together. Moreover, adding storage to the hardware is as simple as plugging in an additional disk-shelf.

Steadman acknowledged that HP’s announcement was a little light on hardware specifics. “That’s because the E5000 Messaging System will be available in March and we’re keeping some of the cool geeky details to ourselves for just a bit longer,” he explained.

When HP and Microsoft announced their collaborative agreement a year ago, the companies pledged to jointly spend $250 million to produce appliances that combined technologies from both companies. The goal of the combine was to deliver hardware that was pre-installed and pre-configured to optimize it for maximum performance and smooth deployment.

“Customers are looking to significantly reduce implementation and decision times,” Mark Potter, HP senior vice president and general manager for industry standard servers and software said in a statement. “With our converged application appliances, HP and Microsoft enable customers to shorten the time required to deliver information, which helps to reduce risk and cost.”

New Exchange hardware released by HP-Microsoft

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

More and more companies are learning about virtualization technologies. And there are a lot of companies that have already gone from a dedicated server environment to a virtualized server setup in their data center.

Companies, IT directors, their staff and administrators are all considering the advantages and disadvantages of virtual server technology and whether it is the right choice for their company. There are many reasons to go to a virtual environment. And when going to a virtual environment a frequent question is which of our servers would benefit from being virtualized?

Email servers are great candidates for virtualization. If your organization is small then you are probably already running your email server or servers on small boxes with a certain amount of CPU, memory and disk drives. One of the parameters to look at when considering a virtual server is to ask the question: what is the current CPU utilization of my existing email server?

Typically, most data centers are running their email servers at anywhere from 20 to 25 percent of CPU utilization. If that is the case for your company, and you have other servers also running at 20 to 25 percent, or less, then you are a good candidate for an email server virtualization effort.

And what does it mean to virtualize my server? In short, a server virtualization means that we are consolidating one or more existing servers onto one physical frame or box. Each of the virtual servers gets their own allocation of virtual CPUs, memory, disk storage and I/O adapters. A combination of software and firmware performs the distribution and balancing of those resources among the virtual servers that have been defined on the physical frame or box. Usually a hypervisor is involved as a sort of traffic cop for distributing those resources.

Here are some of the many reasons to help you and your company make the decision to virtualize your email server(s):

1. The very reason why an email administrator would be interested in virtualizing their email server is because of the potential benefit to their resume. An administrator might be scratching their head at this point and be thinking “but, now I have to learn about another new technology again. It’s going to take more time away from my existing work, it’ll be time consuming and I may not even like it.” But that’s exactly why an email administrator should be looking forward to virtualizing their email servers – because most email administrators also perform system administration. And if an administrator is a good technologist already then getting to learn a new technology, such as virtualization, can turn them into a great technologist. Understanding new technologies, such as virtualization, can only add to an administrator’s resume and make them more marketable in the workplace.
2. Given that most companies are running their email servers at anywhere from 20 to 25 percent of CPU utilization and have other servers also running at 20 to 25 percent, or less, they can consolidate those physical servers onto one box running virtual servers instead. Server consolidation can result in 3 to 1 or even a 4 to 1 server reduction ratio in some cases. The result is that they can get a better server utilization of between 60 to 80 percent. This means that the physical server is not wasting resources. CPU, memory, disk drives and adapters are getting a higher percentage of usage and are thus earning their money so to speak. Why pay for resources that are only used for a small percentage of the time?
3. One of the added benefits of using fewer resources, for multiple servers, is that your licensing costs go down. Let’s say that you consolidated 4 email servers, each with 2 CPUs for a total of 8 CPUs, down to one physical box with just two CPUs – a 4 to 1 reduction ratio. That means that rather than paying for 8 CPU licenses in the dedicated server days your company is now paying for only 2 CPU licenses for your virtualized environment. This is something that an IT department can appreciate and see the value of. It also means that for an email administrator they are no longer administering four physical boxes but one physical box. This results in not only a savings of money but also time, time that is valuable to all email administrators and system administrators in general.

In my next blog post I will describe five more reasons why it makes sense to virtualize your email servers.

3 Reasons to Virtualize Your Email Servers – Part 1 of 2

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

Information leaks can be harmful to an organization’s profitable operation. Microsoft Exchange 2010, with its rights management features, can give a company the kind of control over its information to reduce the risk of such leaks occurring.

In an Exchange environment, rights management can be imposed through the Active Directory Rights Management Server. Rights Management was introduced by Microsoft to its Windows Server product in 2003 and later renamed when Windows Server 2008 debuted. The name change reflected improved integration with Active Directory.

Rights Management allows administrators, as well as others, to control access to documents, emails and web pages. It also can be used to limit what can be done to those things. For example, functions such as printing, copying, altering or forwarding can be enabled or disabled for documents or emails. What’s more, administrators can bundle rights in templates that can be applied across a system.

The reason behind rights management is a simple one. Information that should be for internal eyes only should not be exposed to external scrutiny. Rights management aims to plug the leakage of confidential information, either intentionally or unintentionally.

What’s to fear from information leakage? Given the rising interest among regulators in data breaches and the appearance of new laws punishing organizations with lax attitudes toward leakage, a company can face financial penalties for failing to adequately secure the transmission and storage of certain kinds of data, such as customer records. Moreover, because more and more states are requiring companies to report data breaches, the adverse publicity could cost an organization customers and for public companies, market capitalization.

In addition, unauthorized airing of sensitive information can be exploited by competitors to diminish an organization’s competitive advantage in the marketplace. Imagine the impact of information about a planned acquisition or new product being released in the wild prematurely.

Rights management isn’t a bulletproof solution to leakage problems. You can bar a user from forwarding a message that contains sensitive information. Determined users, though, will find a way around rights management. For example, email text can be selected, copied and pasted into an unprotected message and leaked that way, or if copying is prohibited, a would-be leaker can display the message on their computer, whip out a cell phone, take a photo of the screen and forward the message to others that way. In an age when appearance is often a substitute for substance, though, rights management shouldn’t be short changed. With rights management in place, when a leak does occur, an organization can claim that it took all reasonable steps to protect the information within the Exchange infrastructure.

Two traditional ways to control information leaks are TLS, or Transport Layer Security, and email encryption. Both protect the initial access to data, but are less effective in providing constant protection of it.

TLS only protects messages in transit one SMTP host to another. Moreover, it only guarantees protection for the first SMTP “hop.” So you can require TLS protection when you send a message from your SMTP server to another one, but that other server need not use TLS when it moves the message on the next stage of its journey. When the message arrives at its destination, it sits unprotected in an inbox. What’s more, the recipient can do anything with the message–copy, forward or print it.

Email encryption solutions are usually left to the user’s discretion. Ordinarily that’s not the best way to promote consistent or effective email security. Not only are there costs associated with encryption–deployment of a public key infrastructure and maintenance of certificate management and private key protection schemes–but once a message is decrypted, an organization loses all control over what can be done with the message. In addition, encrypted messages can’t be inspected by an organization until they’re decrypted. That prevents your security programs from immediately inspecting messages for malicious content or for violations of messaging policies.

Rights management in Exchange addresses the security deficiencies found in the traditional methods of controlling leaks. It can shut down the ability of someone receiving a rights protected message from forwarding, modifying, printing, faxing, saving, cutting, copying or pasting its content.

What’s more, that level of protection can be extended to attachments. In addition, expiration dates can be imposed on messages and attachments so they can be viewed for a certain amount of time and the snipping tool can be disabled when viewing a rights protected message.

Of course, as mentioned before, there are ways to circumvent rights management. Third-party screen capture programs, for instance, can still be used to nab an image of a rights protected document. Content can be transcribed into another application, too. Nevertheless, rights management can be a significant barrier to information leakage in an organization.

Plugging Leaks using Rights Management

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

Every end user out there takes for granted that when they push the Send button that there will be no problem. And take for granted that when we go to read our inbox that there will be no trouble to download new messages. But, of course, we all know that sending and receiving email messages can be interrupted at any time. And as administrators we must be able to produce solutions as fast as possible.

If your organization is running Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server, or Microsoft Windows Small Business Server 2003 and your end users try to send or receive email then they might run into one of the following scenarios:

• Exchange server does not accept Simple Mail Transfer Protocol (SMTP) messages from certain Internet domains.
• Exchange server cannot deliver SMTP messages to certain Internet domains.

An administrator can perform a reverse Domain Name System (DNS) lookup and find that the Exchange server that is sending the SMTP message cannot be resolved. They should then perform a network monitor trace and look for any NBT (NetBIOS over TCP/IP) queries before the Exchange server disconnects.

The sender will probably receive a non-delivery report (NDR) that contains the 5.5.0 error code. This code indicates a generic SMTP failure. The NDR will look similar to the following:

> Your message did not reach some or all of the intended recipients.
>
>       Subject:
>       Sent:    9/12/02 3:39 PM
>
> The following recipient(s) could not be reached:
>
> user@destination.com on 9/12/02 3:39 PM
> Your mail system could not find a way to successfully communicate with the destination system. Please notify your administrator. <Server.source.com> #5.5.0

Additionally error code: #5.5.4 “Transaction failed” might also be generated.

Administrators should also check the Windows Event viewer on the Exchange server that is sending the error message. They should look for an error message that contains event 4000 or event 4001. The error message will be similar to the following:

Event Type: Warning
Event Source: MSExchangeTransport
Event ID: 4000
Description: Message delivery to the remote domain ‘ destination.com ‘ failed for the following reason: SMTP protocol error.

This situation can occur if the destination SMTP server performs a reverse DNS lookup and if one of the following conditions is true:

• The IP address does not match the domain name that is used in the return address of the email message.
• A pointer (PTR) record does not exist or is invalid for the source SMTP server’s IP address.

An administrator may find themselves in a situation where email messages which are sent from one domain to another domain are not delivered. Suppose the originator of the email sent has a domain name that is used in the return address of the message such as originator.com. Once the message is sent and the destination SMTP server receives the message it will perform a reverse DNS lookup. If the destination SMTP server finds that the PTR record for the originator.com domain does not exist or is incorrect, it will not deliver the message.

Administrators should be aware that using a dynamic IP address with a network adapter connected to the internet may require a reconfiguration of the Exchange Server settings for proper routing of email messages. This may be necessary for the Exchange Server to route mail from the originator.com domain through an SMTP connector to a smart host.

If an administrator wants reverse DNS lookups to be performed on all connections then they can configure the Exchange server to reject incoming connections by specifying a domain name on the SMTP virtual server. Administrators can perform this operation by right clicking the SMTP virtual server, selecting Properties, then the Access tab and then looking under Connection Control.

Administrators can correct this problem by following the steps outlined below:

1. Confirm that the public DNS records that are hosted on your DNS server are correct. Verify that your DNS server has these settings:                             Ensure that an MX record for your domain points to a valid Host (A) record. The MX record for originator.com points to mail.originator.com. Therefore mail.originator.com is a valid email server.                                                      Ensure that the Host (A) record points to a valid IP Address. In my case, mail.originator.com points to 200.44.51.64.
2. Confirm that there is a valid PTR record for the Public IP address of every SMTP server or Exchange Server system that is sending email.

Troubleshooting Exchange and Unaccepted SMTP Domains

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

Not being able to send or receive email ranks right up there with having your debit card declined at the checkout counter. It is a very frustrating experience for the end user but even more so for the administrators whose responsibility it is to ensure that communications flow as freely as the motor oil in our automobiles.

If a communications problem is consistently happening then an administrator can check the logs and the network to look for errors or other problems. But if email is being sent or received randomly then it can make the diagnostic process that much more difficult.

After clicking on the send/receive button on the top bar an end user can expect to see a picture of two folders on the bottom right of the screen. A status message should also appear which reads “send/receive status xx%”. The send/receive looks like it is making progress but subsequent clicks on the send/receive button may not produce the same results. Users end up recycling their power in an effort to clear out any problems and sometimes this works – for a short while. And that’s when the administrators get called.

One of the easiest things for an administrator to check is to look for multiple open Outlook sessions.

It is very easy for anyone to get distracted while working. And sometimes we can forget to close our applications down. This can result in having more than one session running which can in turn create problems. If an end user has multiple sessions of Outlook running it can cause status messages such as the one previously mentioned to appear and give the impression that there is a problem with either Outlook or Exchange Server.

Simply shutting down the extra sessions of Outlook can clear up the communication problem. Administrators can see how many extra sessions are running by hitting CTRL ALT DEL to bring up the Task Manager to view the applications and processes. Then just shutdown the extra sessions and try the send/receive button again.

But there are other scenarios where simply shutting down extra Outlook sessions will not solve the problem. For instance, there are some problems which can show up when running Outlook 2003 clients and making connections to Exchange Server 2010. Some examples of the problems your company may experience include:

• Email messages remain in the outbox for up to one minute.
• Email messages are not delivered to the inbox for up to one minute.
• Email messages are still in folders for up to one minute even after having already been deleted.
• Email items are not cleared out of source folders for up to one minute after having already been moved to a destination folder.
• Folder updates in general taker longer than normally expected.

The reason why this happens has to do with how Outlook 2003 connects and retrieves email from an Exchange server. It also has to do with how Exchange Server 2010 responds to Outlook clients and notifies them that new email has arrived.

Outlook 2003 expects to be notified by Exchange server via User Datagram Protocol (UDP) notifications. When Outlook makes its initial connection to the Exchange server it registers itself to receive notifications whenever new messages are received. It is expecting to receive those notifications by way of UDP. UDP is known as the connection-less protocol as opposed to the Transmission Control Protocol (TCP) used for connection oriented communications.

The problem arises as a result of how Outlook handles communications when it does not receive UDP communications. Outlook will begin polling the Exchange server for new email messages. It just so happens that the polling occurs, by default, once every minute. This is the reason why changes to the folders seem to be delayed by one minute.

Only Outlook 2003 experiences the long delays due to the polling mechanism instead of the expected UDP communications. Outlook 2007 does not experience these long delays as it uses asynchronous notifications – its default – for its communications with Exchange Server instead of UDP.

Administrators of Outlook 2003 who wish to avoid the long delays can install Update Rollup 1 for Exchange Server 2010. If it is not convenient to install the Update Rollup 1 for Exchange Server 2010 then an administrator can use cached mode for their Outlook 2003 profile. A different architecture is used by the cached mode synchronization process when it updates folders that are in the respective mailboxes.

Troubleshooting Slow Exchange Server Connections

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

Systems with RPC and Outlook Anywhere can turn off some forms of authentication that attract hackers.

As most security folks know, the holidays are a peak time for hacker activity. Not only do the levels of spam and phishing attacks increase, but direct assaults on Exchange servers jump, too. One way to discourage intruders from poking your system for usernames and passwords is to tinker with the authentication settings on your SMTP server.

On most servers, all the authentication settings–Anonymous, Basic and Integrated–for the SMTP receive connector are enabled. The Anonymous Authentication setting allows the server to receive external email. The Basic Authentication setting lets your users send their usernames and passwords without securing them. And Integrated Windows Authentication permits your domain users to use SMTP and verify access to the server using credentials from their Windows accounts.

You can’t disable Anonymous Authentication unless you want to choke off all incoming email, but you may be able shut off the other authentication settings. If a server has RPC over HTTPS and Outlook Anywhere configured on it and you don’t have any users with SMTP/POP3 accounts sending through your Exchange server, there’s no need to enable Basic and Integrated authentication.

Disabling those forms of authentication can be a signficant deterrent to hackers mounting automated atacks on your system. After disabling those settings on some servers that were under sustained attack by net sappers, Alan Hardisty reports that attacks on the boxes had dried up to nothing in two days.

In mounting their sustained attacks on Hardisty’s servers, the Internet miscreants used one of the oldest techniques in the Black Hat book of tricks, the brute force assault. The approach is a very blunt instrument. How else can you describe trying to guess a username and password with thousands of trial and error combinations? Users, though, can make a brute force hacker’s job easier by guarding their email accounts with weak passwords. That problem and others  can be addressed with a preventive program. Here are some elements that should be included in such a program.

• Require complex passwords from your users. The passwords should contain both upper and lower case letters, numbers and special characters. Such passwords can foil “dictionary” attacks where words from a dictionary are thrown at a password challenge until the right one is found.
• Require a minimum length for passwords. Longer passwords are better than shorter ones but none should be shorter than eight characters.
• Force passwords to be changed regularly. Security experts will argue on what “regularly” means but somewhere in the 30 to 60 day range should sufice.
• Lock out an account after a set number of abortive password attempts. That number should be low–three to five failed attempts. Once an account is locked down make sure it stays that way for a sufficient amount of time to discourage attackers from renewing their efforts. The hiatus doesn’t have to be too long–15 minutes or so.
• Configure your firewall so that only the protocols that you need are enabled. All other protocols should be disabled.
• Check the settings for your firewall on a regular basis to make sure that only the ports that you need are open. Unneeded ports should be closed down.
• Make sure your firewall logs collect login information from your entire system. That information can be invaluable in identifying IP addresses from which suspicious activity may be originating, especially multiple login attempts.
• Archive firewall logs that are full and keep them in a safe place.
• Set up alerts for your system’s Security Log so you’ll be notified when multiple invalid login attempts occur. This will allow you to quickly react to a possible cyber attack and the quicker you react, the less time intruders will have to compromise your system and steal usernames and passwords.
• Disable any account on your system named Administrator. This is the first account penetrators will look for when probing your system. Items in the Administrator account should be moved to another account created by you, Server Admin, for instance, and the administrator account disabled.
• Inventory your user accounts on a periodic basis. Disable or delete accounts that appear to be dormant. Dead wood accounts are meaty targets for system intruders.
• Locate all your server user accounts in Active Directory, preferably in a single OU, or organizational unit. That will allow you to more easily keep tabs of the accounts on your system and make it less likely for a compromised account to avert  your notice because it’s buried in some obscure location that you rarely, if ever, eyeball.

How to fight hacker attacks on Exchange servers

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

You’re ready to deploy Exchange, but you’re not quite sure if you have the storage chops to accommodate the change. Wouldn’t it be nice if you could simulate the installation and uncover any hassles that might be waiting for you when you start the process for real? Such a nicety exists. It’s called Jetstress, and Microsoft recently released  a guide on using it with any version of Exchange you plan to implement.

The 49-page document prepared by Senior Consultant Neil Johnson explains how Jetstress works, how to plan and perform tests with the software and how to automate the process. Although the guide discusses determining if a storage setup can meet the demands of an Exchange installation, it doesn’t offer guidance on storage design for the software. If you’re interested in that aspect of the preparation process you might want to consult another Microsoft offering: Mailbox Server Storage Design.

During the design phase of an Exchange deployment, theoretical targets are set for handling expected input-output loads for the software’s databases. Without Jetstress, those targets would be untested until Exchange was installed. Jetstress can be used to test those targets without such an installation. That’s important because it lets you see how your installed storage and server infrastructure will behave during an actual deployment of Exchange. Actual behavior, as predicted by Jetstress, can be very different from theoretical predictions cooked up during the design phase, especially when your storage infrastructure is shared or your storage design is complex.

Here are some Jetstress benefits cited in the guide.

• Validation that a physical deployment is capable of meeting specific performance requirements.
• Validation that a storage design can meet specific performance requirements.
• Identification of weak storage components before Exchange deployment.
• Proof of storage and I/O stability.

Something you need to take into account when using Jetstress–and which is stressed multiple times in the guide–is that the program needs to be run with the same version of the Extensible Storage Engine (ESE) files that will be used in your Exchange infrastructure when the software is actually installed.

A successful Jetstress test will validate all hardware and software components in the I/O stack from the operating system to physical disk drives. It will ensure that the components are working at a level that  meets the predicted performance needed for Exchange to operate successfully. You should keep in mind, however, that, like any test, Jetstress results are only as good as the data you give it, namely the user profile analysis and workload predictions formulated during the design phase of the project.

The Jetstress guide is organized into eight sections. After two introductory parts, it begins with a discussion of Jetstress internals then moves to when and where to run the program and how to install and configure it. It wraps up with advice on output files produced by the program and reading its report data.

Although you may be inclined to use Jetstress only during the build stage of an Exchange deployment, it can be useful during the design stage too, to take the guesswork out of that process. It can be used to give you some real numbers on the maximum storage I/O capacity of your system. Those numbers can then be used to create your bill of materials for the deployment more precisely, which can save you money on it and reduce risks associated with it.

Using Jetstress during the design phase, though, doesn’t preclude using it during the build phase. In fact, it’s still a good idea to perform the test again at that time. It’s common to test a single server and its storage solution at build time. That approach can miss problems such as someone installing only a partial part of the build on a server or an untested device driver lurking on a machine or existing faulty hardware. A Jetstress run can catch those problems, as well as identify failing components on the system.

“[I]t is much less stressful to identify a weak batch of disks during a Jetstress test than on a Monday morning after a large user migration!” the guide reminds administrators.

It also reminds administrators not to run the program on production servers with Exchange installed on them. That can lead to problems with Exchange performance counters.

The guide is chock full of useful information for using Jetstress and is worth a peek if you want to use the program to make an Exchange transition as smooth as possible.

Microsoft Jetstress guide useful for smooth Exchange transitions

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

Clarke: Defends forced migration.

More than a few administrators have been annoyed by Microsoft’s decision to omit an in-place upgrade when moving to recent versions of Exchange. Exchange General Manager Perry Clarke recently defended the policy in his Ask Perry blog.

Contrary to the opinion of some critics of the practice, in-place upgrades weren’t ignored because the Exchange team is full of lazy programmers, he joked.

As any Windows user knows, Microsoft designs its software for the latest hardware on the market. Sure, you can run it on legacy iron, but it will be a problematic proposition that will eventually force you to buy new hardware in frustration. That logic appears to be behind the forced migration policy for Exchange.

 ”In major releases we tend to make substantial changes to our architecture to take advantage of exponential changes occurring on the hardware front,” Perry wrote on his blog. “Doing this in a backwards compatible way often leads to substantial compromises that leads to a more expensive and less reliable TCO [Total Cost of Ownership].”

The new software can produce significant cost savings for organizations, but only if it’s run on new hardware, he maintained.

“Certainly to fully take advantage of the changes in the release requires rethinking the hardware design,” he wrote. “Over the past couple of releases, doing this properly will reduce costs so substantially that continuing to run the old hardware would be un-economic even through it is fully depreciated.”

In defending forced migration, Perry makes it sound like Microsoft is doing IT managers a favor by coercing them to buy new hardware to accommodate an Exchange upgrade.

“Given the rapidly improving hardware and the fact that the most expensive component (storage) wears out [r]egular hardware refreshes in the order of every 3-4 years are needed,” he wrote. “Doing both a major-version in-place upgrade followed by a migration to new hardware is a model that combines the worst of both approaches.”

“The migration model is well suited to most organizations because it allows you to move your least sensitive mailboxes first, your most sensitive mailboxes ( execs? application mailboxes?) last and have a great coexistence story,” he argued.

In a video accompanying Perry’s blog, he added that changes in the way recent iterations of Exchange treat storage has made it difficult to do in-place upgrades. The first time Microsoft faced that problem was when it went from Exchange 2003 to Exchange 2007. At that time, it was decided to make the software 64-bit only. That essentially shut the door on in-place upgrades.

“That was a tough decison at the time,” he said. “Marketing was really concerned that it would be a big blocker. But when we looked at the hard data, our customers largely were doing migrations.”

“Well more than 80 percent of the people upgrading from 2003 had done a migration approach, and almost all of the rest, had done an in-place upgrade followed by hardware migration,” he added.

To salve the sting of migration to Exchange 2010, Microsoft has incorporated features into the program to minimize disruption to the daily operations of an organization. In previous versions of Exchange, migrations had to take place after normal business hours, Clarke explained. With Exchange 2007, which supported larger mailboxes, it became more and more difficult to restrict migrations to that “after hours” window.

“The single biggest thing that we did to improve this was to enable online moves between versions,” he said. “So between 2007 and 2010 your mailbox moves can actually occur during your migration period 24-by-7 and users will see absolutely no impact,” he contended.

Clarke’s defense of forced migration attracted more than a few gadflies to his blog.

“Excuse me,” commented “Thomas,” “but did you ever hear about virtualization? You know, you can add RAM and processor power dynamically there. No need to move to a new machine.”

Another irrate commenter, ‘Ferdy’, complained, “It is ridiculous that a software vendor gets to decide that their clients need to replace their hardware, no matter how large your technical changes are.”

“Yeah I’m sorry, but that sounds a lot like a desperate defense of the indefensible,” wrote ‘Mark’ of Clarke’s remarks. “We administrators are perfectly capable of analyzing our hardware and it’s capabilities ourselves.  We don’t need Exchange Developers deciding for us whether or not we need to upgrade our hardware with every single major release.”

Microsoft defends Exchange migration policy

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

It has been a best practice for some time in security circles that a network needs antivirus software installed on all its elements to properly protect it from the slings and arrows hurled at it by cyber miscreants. With slavish dedication, administrators have loaded antivirus programs on their organization’s desktops, servers and perimeter defenses.

The logic behind those deployments seems unassailable. The odds against network defenders are long. To be successful, those defenders must foil every attack on their systems, which can number in the thousands. The attackers, on the other hand, only need to unleash one of their pernicious payloads to claim victory. In view of those odds, it only makes sense to put as many barriers as possible between the Black Hats and success.

Of course, that logic only makes sense if the antivirus products do what they’re supposed to do without becoming a potion that’s worse than the disease it was designed to cure. Historically, that’s been the case with many antivirus programs installed on Exchange. For example, when an antivirus program scans Exchange’s information store files it can create all sorts of annoying problems. It may cause the Information Store service to abruptly quit. It may corrupt the information store database. All of a sudden, the service may stop responding at startup. Worse yet, mailbox data may be lost. Over the years, Microsoft has made improvements in its APIs to allow antivirus programs to play better with Exchange, but problems continue to persist.

Those annoyances may induce some administrators to scrap antivirus software on Exchange altogether and beef up the perimeter defenses of their networks so attackers are turned away at the gateways to the system. The problem is if an attacker gets behind the perimeter defenses, the administrator will feel what Priam felt during the sack of Troy. That kind of compromise need not involve penetration of the perimeter defenses. Malware may be introduced into a network by one of its users through an infected laptop, thumb drive or other device that interacts with the network behind a firewall. That’s why internal as well as perimeter defenses are needed, security purists will argue. Besides, they will add, a properly configured antivirus program will work perfectly fine with Exchange.

As simple as “properly configured” sounds in theory, in fact it can be problematic. To keep up with the increased sophistication of the Internet underworld, antivirus makers have had to make their products more and more complex. While those products may be loosely grouped under the antivirus umbrella, most of them do far more than combat viruses. They’ve become full blown software suites designed to protect organizations from not only malware but spam, phishing attacks and even integrating with other security and management tools on a network. Although that complexity makes the software more capable in thwarting system assaults mounted from the Net’s dark side, it has also made things more difficult for system administrators who have plenty to worry about without the additional bother of a security suite mucking up network operations.

“My position is that anti-malware protection is mandatory at the perimeter and on the desktop, desirable on Hub Transport servers, and optional on the Mailbox server,” Paul Robichaux wrote recently for WindowsIT Pro. “This combination gives the best mix of protection, ease of administration, and stability.”

Robichaux’s remarks spurred some interesting comments from his readers, who seem to come down on the side of protecting Exchange with antivirus software. For example, several pointed out that file-level antivirus protection is needed to guard against malware attacks on Windows itself.

“That’s a good point,” Robichaux acknowledged, “one which I failed to consider in my original column.”

“It is very important to ensure that none of your servers, Exchange included, are compromised by fast-spreading malware,” he added. “Those of you who worked in the IT industry around the time of the Blaster, Nimda, or SQL Slammer worms know exactly what I’m talking about.”

Another argument for antivirus software on Exchange advanced by readers is the threat of Zero Day attacks. That kind of attack could slip through perimeter defenses and make it onto an Exchange server before it’s discovered. Antivirus software on the server will allow the malware to be disabled once the Zero Day attack is exposed.

Antivirus software on Exchange servers is a nettlesome issue and one that needs additional scrutiny.

“What I’d really like to see is a comprehensive study, or even an attempt at one, that shows the difference in catch rate for different combinations of antivirus protection at different tiers,” Robichaux wrote. “It might not be practical to gather that data, especially given that no one vendor is likely to come off as the conqueror in such a study. However, I would like to see some hard data one way or another.”

Should you dump antivirus software on your Exchange server?

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

One of the most unwanted problems which database administrators have to deal with is the corruption of their databases. When a database crashes or gets corrupted then that’s the time that everyone involved in their IT operation really appreciates the value of their backups. And since email is used by everyone within a company then when an email database gets corrupted everyone from the front office to the back office is affected.

Sometimes a corrupted Exchange database can be the result of a hardware disk failure. Disk failures are infrequent but when they do happen they can damage the database. Administrators can try to restore the database using the most recent backup copies. The restore might begin and even proceed for a while but if the database copy itself is corrupted then the restore will be unsuccessful.

It’s possible that the information store will continue to run. And the mailbox store may even be mounted but even using earlier backup copies with transaction logs to roll forward the changes might not help. This is why it is so important to routinely check the system logs for notices of faults or other error conditions.

If the database is corrupt but still running then a reboot could turn what is currently an unfortunate situation into a real disaster if the database doesn’t come back up.

Some of the possible error conditions to look for include:

Event type: Error
Event source: ESE
Event category: Logging/Recovery
Event ID: 474
Date: date
Time: time
User: N/A
Computer: computername
Description: Information Store (1532) Storage Group 1: The database page read from the file “C:\Program Files\Exchsrvr\MDBDATA\Storage Group 1\MDB2.edb” at offset 12611584 (0x0000000000c07000) for 4096 (0×00001000) bytes failed verification due to a page checksum mismatch. The expected checksum was 8700524288068713684 (0x78be78be1dfe7cd4) and the actual checksum was 564489450306895060 (0x07d5782a0cff7cd4). The read operation will fail with error -1018 (0xfffffc06). If this condition persists then please restore the database from a previous backup. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.

Note that an unrecoverable (or multiple-bit) error is still reported as event 474 in Exchange 2003 Service Pack 1.

Event type: Error
Event source: ESE
Event category: Logging/Recovery
Event ID: 475
Date: date
Time: time
User: N/A
Computer: computername
Event type: Error
Description<process name> (<process id>)
The database page read from the file “C:\Exchsrvr\mdbdata\priv1.edb” at offset 5570543616 (0x000000014c07c000) for 4096 (0×00001000) bytes failed verification due to a page number mismatch. The expected page number was 1359995 (0x0014c07b) and the actual page number was 1546806883 (0x5c326663). The read operation will fail with error -1018 (0xfffffc06). If this condition persists then please restore the database from a previous backup. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.

In the case of Event ID 475, this error event indicates that a database page read failed verification due to a page number mismatch. This means that a database page referenced is corrupted. The specific database page is located within the Exchange store file (such as priv1.edb). In addition, a -1018 error will most often be listed in the description section for event ID 475.

Possible symptoms include:

• A -1018 checksum error is returned and online backups fail.
• A -1018 checksum mismatch error is listed in the online defragmentation error message.

The cause of the errors can range from driver or firmware issues to hardware problems. These problems can damage at the page level of the database and produce error event 475.

Administrators can resolve this error by performing one or more of the following actions:

• Run system diagnostic tests to determine the source of the error messages. It may not be possible to determine the source of the errors if the conditions are sporadic or happen occasionally.
• Move the data to a different set of storage disks.
• Update the firmware to the latest vendor release level.
• The database can be repaired by using the eseutil /p command, running eseutil /d, and then running isinteg -fix.
• New hardware is always a solution although usually the most costly.
• Defragment the database. Verify that you have free disk space that is at least one-hundred ten percent of your database size.

Note that the repair process can take as long as an hour or more per gigabyte.

Troubleshooting a Corrupt Exchange Database

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

Microsoft’s reboot of its efforts in the mobile market with Windows Phone 7 has been greeted with kudos from some quarters, but its integration with Exchange Server leaves something to be desired, at least in the view of one Redmond watcher.

“While I’ve been an enthusiastic supporter of Windows Phone 7 since, well, Microsoft announced the new smart phone platform back in February, it’s time for a reality check,” writes Paul Thurrott at the SuperSite for Windows blog.

“Yes,” he continued, “Windows Phone 7 offers excellent competition to the current industry favorites, Apple iPhone and Google Android. And yes, I do think it will establish itself as one of the key mobile platforms going forward. But Windows Phone 7 is not an acceptable enterprise smart phone solution, at least not in its initial release.”

That’s a bit surprising, since Windows-based mobile phones have a reputation for being extememly enterprise friendly, sometimes at the cost of providing a satisfying user experience. With WP7, Microsoft appears to have gone in the opposite direction. It’s finally got the user experience thing down pat, but at the expense of its enterprise prowess.

“We’re still extremely impressed by the software’s touch responsiveness and speed,” observed Joshua Topolsky comparing, at Engadget, the final version of the platform to earlier editions. “In fact, this is probably the most accurate and nuanced touch response this side of iOS4.”

“It’s kind of stunning how much work Microsoft has done on the user experience since we first saw this interface–everything now comes off as a tight, cohesive whole. We haven’t seen any substantial interface lag while using the device, and the short transitions between applications or pages are well suited to the overall experience,” he continued.

“Overall, though, day to day use inside of this UI has been solid,” he added. “Microsoft actually created a fairly intuitive, tightly woven operating system. We did see some occasional lagginess and freezes, and we had some troubling issues with third-party app performance…but for a first generation, brand new OS, the folks in Redmond have done a pretty impressive job.”

While Thurrott raps WP7′s Exchange integration, he does praise some enterprise aspects of the platform. For example, WP7 supports multiple Exchange Server accounts, including accounts based on non-Microsoft systems that support Exchange ActiveSync or EAS. He also raved about the platform’s email client, which he called “an email triaging wonder.”

He also noted that WP7 has a “decent” Office Mobile client, although it isn’t as robust as Office Mobile 2010 for Windows Mobile, and a “terrific” SharePoint Workspace client with seamless over-the-air access to multiple SharePoint servers and the documents on them.

The problem with WP7, as Thurrott sees it, is that with it, Microsoft has conceded that if it wants to be player in the mobile market, it has to cater to consumers, not IT departments.

“This is the way the world’s going, of course,” he wrote, “and though I’ve expressed my fears over the so-called consumerization of IT before, allow me to reiterate a key theme: Businesses think they are saving money by letting workers use their own phones with work-related data and resources, but the resulting lowering of the guard may ultimately come back to haunt them.”

It’s hard to blame Microsoft for facing the realities of the mobile market. The plain truth is that individuals buy cell phones, not corporations. By Microsoft’s own calculations, 82 percent of Windows mobile phones are bought by users, with only 11 percent bought by employers. That user figure is probably even higher for the leaders in the market, the iPhone and Google’s Android handsets.

Thurrott acknowledges that WP7 has few security features to protect Exchange Server from mobile users. For example, an administrator can impose a policy requirement on WP7 phones so users must protect their phone with a PIN before they can access the server. Applications in the phone are sandboxed from each other to prevent the spread of electronic infections. In addition, the phones can’t be configured as portable hard drives and used for wholesale theft of data.

However, the platform doesn’t support a full set of Exchange policies, as Windows Mobile did. Although the phones will work with Exchange Server 2003, 2007 and 2010, it only works with Sharepoint 2010 and only within the corporate firewall.

What’s more, the phone is tightly integrated with Microsoft’s Zune ecosystem. That means the only way to get apps in the thing is through Windows Phone Marketplace, which is similar to Apple’s App Store. That will be a real pain for organizations who want to run custom apps on the phone.

“Put simply,” Thurrott wrote, “Windows Phone 7 is a wonderful platform for end users. But for the enterprise that wants to really manage what happens on the devices they deploy to end users, the initial shipping version is going to fall a bit short.”

WinPho 7 Exchange security questioned

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

Seven Deadliest Microsoft Attacks is part of a series of “attack” books published by Syngress, a book maker specializing in security titles. This compact volume in the series (192 pages, $24.95) provides system defenders with a solid reference to the most common ways Black Hats compromise Microsoft software, including Exchange server.

The book, authored by Rob Kraus, Brian Barber, Mike Borkin and Naomi Alpern, begins with a discussion of password attacks on Windows, moves to besieging Active Directory to escalate privileges, goes to stored procedure attacks on SQL servers, then focuses on mail service attacks on Exchange Server. From there it touches on assaulting Microsoft Office with poisoned macro and ActiveX controls, ravaging Internet Information Services with web service attacks and mounting multi-tier assaults on SharePoint.

The chapter on Exchange server attacks will be very enlightening to email administrators. In it, the authors discourse on how mail service attacks work, the dangers associated with the attacks, the future of the attacks and how to defend against them. Some of the attacks talked about in the chapter include:

• Directory Harvest Attacks - By targeting Active Directory, miscreants collect e-mail addresses from the repository and send spam and other kinds of spoiled messages to them.
• Cache Poisoning - That occurs when corrupt information is planted in the Domain Name Services (DNS) cache in order to redirect messages to an outlaw server.
• Denial of Service - DoS attacks are aimed at incapacitating a system by flooding it with more traffic than it’s designed to handle. Such an assault on a mail server could mean an organization would be without one of its mission critical resources for a substantial amount of time.
• Buffer Overruns - They’re similar to DoS attacks but seek to go beyond merely interrupting service on a targeted system. By inundating a buffer, a cyber bounder can get malicious code to be executed by the system, which can raise all kinds of havoc in a system.
• Spoofing - It’s used by net cads to hide their tracks and disguise the origin of an email message. Phishers use the tactic all the time to give their malevolent payloads legitimate airs–make them appear to be coming from a bank, for instance, or an Internet store  front.
• NDR Attacks - They’re used to turn a legitimate email server into a spam server. It works like this: a spammer floods an email server with messages. The addresses of the recipients of the messages don’t exist. When that’s the case, an email server will attach the message to one of its own in which it explains the message is undeliverable, and ships it to the return address in the spammer’s message. That return address, though, isn’t where the message originated. It’s the address of someone the spammer has targeted for his or her junk. So the legitimate server acts as a relay for the spam and helps anonymize the spammer.

In the chapter, the authors also discuss a variety of defense strategies that administrators can deploy to foil digital blackguards.

One recommendation they suggest is to make sure there is some SMTP presence in your organization’s perimeter defenses. It should be maintained separately from the mail servers that are housing user data and performing internal routing.

Mail traffic should not be allowed to flow from the Internet directly into your internal network, and your internal Exchange servers should not be transmitting data to the Internet. In order to reduce exposure whenever possible, Exchange servers should be placed on the internal network. There’s an exception to that though.

Both Exchange 2007 and 2010 support the configuration of Edge servers. Those servers deployed into a screened subnet on your perimeter network can be used as smart hosts for forwarding email from the Exchange servers on the internal network to the Internet.

“Utilizing Exchange Edge servers allows for minimal surface exposure to the Internet,” the authors explained, “and since Edge servers are designed to be Internet facing, they are an SMTP deployment which is secured by default.”

“As the messaging administrator, you must remain aware of potential messaging system attacks,” the authors noted. “By understanding the characteristics of attacks that may be executed against your system, you are better prepared to identify them and respond to them in a defensive manner.”

“One of the factors that helps to make your job easier is that Exchange Server has evolved over time to be installed defensively straight out of the box,” they added. “Since by default you are more protected than ever before, attackers have had to become increasingly more creative in their attack approaches.”

Seven deadliest Microsoft attacks targeted by book

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

Microsoft introduced its first analyzer tool for Exchange in 2004. Called by the catchy title Microsoft Exchange Server Best Practices Analyzer, the software proved to be so successful that similar software was rolled out for troubleshooting other aspects of Exchange.

Best Practices Analyzer emerged after Microsoft observed certain patterns when addressing critical situations with its support services. Critical situations require urgent assistance to solve a problem that’s disrupting service to an organization’s members and its important business operations. What Microsoft found was that not only were the number of critical situations growing, but that 60 percent of them were caused by configuration errors, not bugs in Exchange. Moreover, new critical situations arising in some shops were the same ones that had emerged in other organizations just a few months earlier.

Microsoft began by creating a utility to gather key information throughout an Exchange environment. When a customer faced a critical situation, they were told to run the utility and Microsoft would sift through the data to ferret out the root cause of a problem.

Collecting data was only the first step. Next, an engine was developed that could analyze the data and expose it to a set of rules. The rules established thresholds. If a key data item was outside the acceptable range in a threshold, the rule would “fire” and a red flag would be raised for support folks.

With the basic model in hand, Microsoft began refining it. Performance was improved from taking 24 hours to collect and analyze information to two hours. The rules set was beefed up.

Once in action, however, it didn’t take Microsoft long to figure out that Exchange didn’t operate in a vacuum. Email problems can originate in the underlying infrastructure of a system, as well as in the applications running on top of Exchange. So Microsoft expanded its analyzer’s rules to take into account what’s running under Exchange and invited vendors running software on top of Exchange to submit rules for their programs that could be added to the tool.

The latest version of Best Practices Analyzer, version 2.8, was released in June 2007. True to its roots, the program collects data from repositories such as Active Directory, registry, metabase and performance monitor and applies best practice rules to the lot. A report is generated that an administrator can use to improve an Exchange environment’s performance, scalability and uptime. The program shouldn’t be used to scan Exchange 2007 or 2010, however, since the software is installed  automatically when those versions of Exchange are set up.

In addition to Best Practices, Microsoft also makes software for troubleshooting Exchange. Aptly named Exchange Troubleshooting Assistant, the software executes a set of troubleshooting steps to expose the fundamental causes of problems with performance, mail flow and database mounting issues. Like the Best Practices software, Troubleshooting Assistant collects key data for its purposes–configuration data, performance counters, event logs and tracing information from Exchange and other sources–and determines what data is needed to treat the symptoms of the problems it finds.

Another valuable analyzer offered by Microsoft is its web-based Exchange Remote Connectivity Analyzer. As its name suggests, it’s designed to help administrators solve connectivity problems. Client logons and mail flows scenarios are simulated by the tool. If a test fails, advice is offered for troubleshooting many of the errors discovered by the service.

Four tests are available from the main Connectivity Analyzer page.

There’s an Exchange ActiveSync test. It simulates the steps a mobile device takes to connect to an Exchange server using ActiveSync, or ActiveSync device uses to obtain settings from the Autodiscover service.

There’s a Web Services connectivity test. It walks through basic Exchange Web services tasks to confirm they’re working. It’s handy for troubleshooting external access from Web Services clients, such as Entourage EWS, Microsoft’s email client for Apple’s Mac computers. Entourage will be replaced in the new version of Office for the Mac expected to be released in the fall. The web Services test also verifies a service account’s ability to access a specific mailbox, create and trash items in it and access it via Exchange Impersonation.

There’s an Office connectivity test that examines the steps Outlook uses to connect via Outlook Anywhere or Outlook 2007 uses to obtain settings from the Autodiscover service.

There’s also Internet Email tests that check the steps an Internet email server uses to send inbound SMTP email to the tester’s domain or reviews an outbound IP address for certain requirements.

No one likes troubleshooting problems, but with Microsoft’s analytic tools, some of those snares can be solved with a minimum of fuss.

Use Microsoft’s analyzing tools to keep Exchange humming

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

The most common question I have received as a result of this post on mail server misconfigurations is “how do I change my SMTP banner?” This article will tell you how to do so on several common mail server platforms. But first, let’s discuss why you want to.

Bad guys frequently use banner grabbing techniques as a part of the initial recon. It is a fairly innocuous activity that takes advantage of expected behaviours. To determine the type and version of mail server you are using, a bad guy need only connect to it on port 25, just like any other system would that is trying to send an email to one of your clients. IPS/IDS systems won’t alert on this, since to them it looks just like any other mail server trying to send mail, and unless you review every single log item, you probably won’t notice a connection that doesn’t actually send an email.

If, however, your SMTP does not reveal its version, all the bad guy knows is that he connected to your mail server. He is going to have to work a lot harder to identify your server, and that may be enough to trip an IDS/IPS alarm. Or, he may simply move on to easier pickings. Either way, make him work for it…don’t just give up all the information in your banner. Intrigued? Read on to learn how to change the SMTP banner on several popular mail server platforms.

Most systems default banners display the information required by the RFCs, but then go a step further and reveal the type and version of SMTP daemon they run. With that information, all the bad guy has to do is focus on exploits known to affect that version, and hope that you are not up to date on your patches.

RFC 2821 requires all server responses to start with 220 when the service is ready to receive mail. Specifically, the recommended format is this;

220 <domain> Service ready

So when we customise our banner, we want to make sure that if our SMTPd does not prepend the response with 220 for us, we include that in our text string.

Sendmail

Sendmail will prepend the 220 automagically for us, so we just need to define our text string. We can use some variables, or just free form text.

1. Edit sendmail.cf
2. Change the line

SmtpGreetingMessage=$j Sendmail $v/$Z; $b

to

SmtpGreetingMessage= yourtextgoeshere

You can use the following variables
$j = fully qualified hostname
$v = sendmail version
$Z = configuration file version
$b = current date and time

3. Restart sendmail for the new banner to take effect.

IIS SMTP service

If you are using the Windows SMTP service that comes as a part of IIS, and is used in Exchange 2003 (and earlier) here is what you do. We will need to include the 220 response code at the beginning of the banner.

1. Open a cmd prompt.
2. Change to the Adminscripts directory. The default location is C:\Inetpub\Adminscripts
3. Enter the following cmd, where ‘vsi number’ is the number of the SMTP virtual server, and ‘your text’ is what you want the banner to display. Don’t forget to start the string with 220

   cscript adsutil.vbs set smtpsvc/vsi number/connectresponse “Your Text” [enter]

4. Restart the SMTP service.

Exchange 2007-2010 SMTP service

Of course, you should have expected that to do this, we will use PowerShell. Again, we must remember to start the response with the 220.

1. Open the Exchange Management Shell as an administrator.
2. Enter this command, where ‘your text’ is the response you want. Both the “From the Internet” and the “220 your text” must be enclosed in quotes

Set-ReceiveConnector "From the Internet" -Banner "220 your text" [enter]

This will take effect immediately, without requiring you to restart the service.

MailEnable

MailEnable makes it pretty easy, giving you a GUI method to set this, and automagically prepending the 220 code.

1. Launch the ME MMC
2. Go to SMTP connector->Properties->Security Tab.
3. Check the box to Use Alternate Welcome Message.
4. Enter your message in the box.
5. Restart the SMTP service for this to take effect.

Postfix

We will need to edit the file /etc/postfix/main.cf. Do this as root or a sudo user. Postfix will prepend the 220 code.

1. Open /etc/postfix/main.cf with your favourite text editor, or in vi.
2. Find the parameter smtpd_banner. By default, it’s set as:

smtpd_banner = $myhostname ESMTP $mail_name

3. Edit this value as desired.
4. Save the file, and restart Postfix.

Lotus Domino

According to lotus.com, directly editing the NOTES.INI file is unsafe, so we’ll use their instructions for this. Domino will prepend the 220 code.

1. From the Domino Administrator, open the Domino Directory and click the Configuration tab.
2. To modify NOTES.INI settings on the server, click the NOTES.INI Settings tab. This tab lists a number of current settings in the server’s NOTES.INI file.
3. To add or change a setting, click Set/Modify Parameters to display all settings that you can set in the Configuration Settings document. Select the variable SMTPGREETING.
4. Set the string to whatever you want. You can use %s as a variable for the system date/time.
5. Save and close the document.

With that, your mail server will continue to greet other MTAs with the required 220, may give an auditor a laugh, but will not give the bad guys any extra information. Remember, security is all about layers, and this is a fairly simple layer to set up.

How to change your SMTP banner for fun and profit

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

Are your users on Microsoft Outlook and Exchange server  complaining about lethargic performance? Here are some things to troubleshoot when you want to quell the griping.

1. Antiquated Software. Are you still on Exchange 2003? That old 32-bit warhorse will have a tough time meeting the email demands of a modern organization. New 64-bit versions of Exchange–2007 and 2010–support more memory and bigger buffers, as well as other speed enhancements. As a result, they can be from five to 10 times more efficient than 2003 in handling mail. While upgrading to a new version of Exchange isn’t an immediate solution to your problems, it’s something to advocate as a long term solution.
2. Mailbox Limits. Both Exchange 2003 and 2007 have 2GB limits on mailbox sizes. However, Outlook users can  exceed those limits. The rub is, the greater that 2GB limit is exceeded, the bigger the hit the user will see in performance. One way to address that problem is to deploy an archiving solution. It will automatically archive a user’s emails when his or her mailbox approaches or exceeds the 2GB limit.
3. Overstuffed Folders. Too many messages stored in a single folder will impair Outlook’s performance. Microsoft recommends that between 3500 to 5000 messages should be placed in a single folder. An archiving solution can address this folder problem, too, as well as creating more top-level folders or sub-folders in folders with high growth rates such as Inbox, Sent and Calendar.
4. Anti-Virus Software. Local anti-virus software can make Outlook work harder than necessary. Each time a message is opened, its body and any attachments to it are scanned by the anti-virus software. That can result in delays of as much as 20 seconds. An alternative to local virus scans is to scan messages in transit at the Exchange Hub Transport servers. With malware scans performed at the servers, you can disable scanning at the client end of things and boost performance for your users.
   
5. Flakey Indexing. Indexing was introduced into Outlook in 2007. It’s a great feature because it quickens the time it takes to find anything in the program. If the index  is corrupted, however, the function can cripple Outlook. How do you know if the index is corrupt? If Outlook never seems to finish indexing messages, that’s definitely a sign that something is wrong with the feature. The best thing to do then is to delete the index and re-index all your messages. Yes, that’s going to slow things down in Outlook for a while, but faster performance will be the reward at the end of the process.
6. Too Many Rules. Users create rules in Outlook to manipulate messages in the program. Messages from the boss, for instance, might be shipped to an Ignore Until Harassed folder. The amount of space allocated to each folder for rules is 32KB, which will accommodate 40 to 50 rules. As a folder approaches the space ceiling, Outlook starts to slow down. The solution to this problem is simple: use fewer rules in your folders.
7. The Myth of New Hardware. A brand new desktop will run faster than a four-year-old clunker, but you should be careful that new hardware isn’t masking old problems. A user with an old machine and 80,000 messages in his or her inbox may see a performance boost with a new machine, but that doesn’t remove the fact that there were too many messages in the inbox in the first place. What’s more, while the user with the new computer may be whistling along at his or her desk, those 80,000 messages are still taxing Exchange’s performance and in turn, hurting other users on the system.
8. Shared Folders Headache. Outlook 2007 and 2010 turn on by default shared folder caching. That can create performance problems, especially for Outlook’s calendar module. You see, with shared folder caching on, when you open another person’s calendar, the entire calendar is sent to your calendar. What’s more,  when you’re online, Outlook syncs your calendar with all the calendars you’re linked to on your system. That can really slow things down. It can take up to 20 seconds before your calendar is displayed. The simple solution to that problem is to turn off shared folder caching.
9. Wacky MAPI. Most of the devices in Outlook/Exchange environments use MAPI to communicate. That can create bottlenecks for both clients and servers. On a client, for example, you may have Outlook, Microsoft CRM, integrated voice mail and an email archiving application all trying to send and receive information on a single network adapter. On the server side, you have numerous requests being sent  to your server from numerous devices deployed by numerous users. One way to address those problems is to scale your Outlook/Exchange environment on the basis of the number of devices on the network, not the number of users. In addition, efforts should be made to control the number of MAPI devices in use on the system.
10. Disappearing DNS. Although it’s not a common problem, sometimes a user is sent to a phantom server by a corrupt DNS. When Outlook can’t find the phantom server, it has to search for another. That results in delays that users see as slow performance. Running Exchange’s “Best Practice Analyzer” will most often identify those kinds of DNS problems.

10 reasons why Outlook is running sooooo slowly

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