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.

Continue reading Troubleshooting Mailbox Database Indexing

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.

Continue reading New Exchange hardware released by HP-Microsoft

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.

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

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.

Continue reading Plugging Leaks using Rights Management

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.

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.

Continue reading Troubleshooting Slow Exchange Server Connections

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.

Continue reading How to fight hacker attacks on Exchange servers

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.

Continue reading Microsoft Jetstress guide useful for smooth Exchange transitions

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. Continue reading Microsoft defends Exchange migration policy

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.

Continue reading Should you dump antivirus software on your Exchange server?