SEMblog

A common question I am being asked is whether to deploy Exchange 2007 right now (January 2007) in a live production environment. The answer I am giving to everyone is the same - no.

That is not because I do not have faith in the product, or the quality of the product.
I am also not part of the "Wait until Service Pack 1" group who apply that to all of Microsoft's products.

The simple fact is that you are looking to replace a product that is effectively six years old (I consider Exchange 2003 to be a point release of Exchange 2000 - they are very similar), with one that is only a few weeks old. It needs time to bed in.

If the deployment of Exchange 2007 goes through without a hitch, then you are fine.
If you are having your spam and AV either taken care of by a third party service outside of your network, or you are going to use Microsoft Forefront, then you are also fine.

However if you have problems then you will be stuck. In the last 24 hours I have heard of two people who have taken E2007 issues to Microsoft Support who have failed to resolve them. They then come to newsgroups to get assistance and found none, because the knowledge just isn't there.

Exchange 2003 is very mature and there is an awful lot of assistance available for it in the form of newsgroups, forums and independent consultants. Most problems are well known, covered either in the Microsoft knowledgebase, blogs, forums, newsgroups or web sites.

For Exchange 2007, there are no books, very little documentation. Even the documentation from Microsoft cannot be relied upon at the moment. The help documentation is riddled with errors. I have sent a number of feedback items for errors in the help documentation.
(I suspect that soon I will be recommending that after installing your Exchange server, the first thing you should download is a new version of the help or at least ignore the help file that is supplied with it and rely on the one on Microsoft's web site.)

Then you get issues with third party support. Very little is confirmed to be working with Exchange 2007 (and don't take the sales droid word for it - they will say it is compatible with Exchange 4.0 if it will get them a sale).

The questions I ask of those who ask me about deploying Exchange 2007 now, is do you want to be the guinea pig for application support, be the one of the first to discover what does and does not work, and when you find things do not work, are unable to phone up an IT support company and get assistance?

What about administration? Your IT person gets up to speed on Exchange 2007 setup and admin, goes away for the weekend and breaks their leg. Getting someone to stand in for them at this time will be very difficult.

Therefore what I am suggesting to clients at the moment who need to purchase Exchange is buy the Exchange 2007 licenses then request an Exchange 2003 media kit. Use downgrade rights for the next six to nine months. Get used to Exchange, get it working how you want - as it is well known what is and is not possible with Exchange 2003.

In six to nine months time it will be much easier to transition to Exchange 2007. The product will be more established with many techniques which are taken for granted with Exchange 2003 are known and tested with Exchange 2007.

Third party tools and applications will have been tested, possibly updated with new versions. Those that don't work will be known and there could be workarounds or alternative products available to you.

What you should be doing at this time is building a lab. A separate domain, possibly using VMWARE or Virtual PC/Server. Get hold of the evaluation editions of Exchange 2007 and install it so that you can start to see how it works. As your existing vendors bring out applications that are compatible with Exchange 2007, test them in the lab.
When it comes to the transition to Exchange 2007 for production use, you will be very familiar with it and confident about using it.

Of course the only problem with waiting is that there is no in-place upgrade available for Exchange 2007. While new hardware should be 64 bit (with a 64 bit Windows 2003 license) if you are using Exchange 2003 you will need to have 32 bit Windows installed.
Therefore when it comes to the upgrade you will need to carry out a swing migration using another machine as a temporary step.

However for the potential disruption that you may have to email while Exchange 2007 settles down, that slight inconvenience of having to use a temporary machine for a couple of days later in the year may be worth it.

With the release to manufacturing of Exchange 2007 and the availability of the evaluation editions, I am now spending more time with Exchange 2007 than previously.
As such there will probably be a spate of blog postings on the topic over the next couple of weeks.
Exchange 2007 Setup Observations
I have decided to spend this week working with, and blogging on Exchange 2007.

To get things started, I thought I would start with some observations I made during the setup process.

Pre-Installation.

This version needs a lot of things to be installed before you start.

I was using Windows 2003 SP1 (NOT R2) as that was the only media I had access to at the time.

First thing is make sure that the machine has been fully patched before you even start. Otherwise the setup procedure fails by asking for updates to be applied.
I got caught on a .net framework update.

To get the Installation to start, I had to install:

.net Framework 2.0

http://www.microsoft.com/downloads/details.aspx?FamilyID=0856eacb-4362-4b0d-8edd-aab15c5e04f5&DisplayLang=en

And an update: http://support.microsoft.com/default.aspx?kbid=926776

MMC 3.0 for Windows 2003 (as this was not R2)

http://support.microsoft.com/default.aspx?kbid=907265

PowerShell 1.0

http://support.microsoft.com/default.aspx?kbid=926139

If you are installing an Edge server (workgroup machine if going in the DMZ) then you need additional installations:

ADAM - Active Directory Application Mode

http://support.microsoft.com/?kbid=902838 which leads to this location:

http://www.microsoft.com/downloads/details.aspx?familyid=9688f8b9-1034-4ef6-a3e5-2a2a57b5c8e4&displaylang=en

The application components required are on the auto play menu, but unlike Exchange 2003 you don't get the list of IIS Components required.

Therefore you have to install some of the IIS components - but they are not the same as the components required for Exchange 2000/2003. I selected the default options for IIS by selecting Web Services and the RPC over HTTP Proxy.

You do not need to install SMTP, NNTP or POP3, as Exchange 2007 has its own versions of those

Finally, make sure that the domain is at least native Windows 2000. I got caught on this as I built a new domain and by default new domains and forests are mixed. I simply switched the forest to Windows 2003.

Application Installation

After getting through all of that lot, the installation itself is pretty straight forward.

For your first installation, choose typical. That will get you started with everything that you need.

The only thing to watch for is the second question it asks, about whether you have any older versions of Outlook on the network. At this time, most people would probably say Yes. However if you are reading this article in a couple of years, you might actually consider saying no. If you say no, then you don't get Public Folders.

Post Installation

When you first start the Exchange console, and each time you start it with an evaluation edition, you will get a prompt about licensing and turning the evaluation edition in to a real version.

As you probably know, Exchange 2007 is 64 bit only.
So while they have provided a 32 bit evaluation, what Microsoft have done is ensure that there is no way to turn that evaluation copy in to a live copy. The licensing wizard has been removed.
If you have built a lab system on 32 bit hardware or 32 bit virtual machines, then you will have to rebuild it at frequent intervals.

Once you are in to the console, a list of post installation tasks comes up. This is worth stepping through, as it provides you with a good introduction to the console and the new Exchange Management shell. You will be working in both. No need to worry about getting things wrong, as the commands are all there for you, but oddly enough you cannot copy and paste them. You have to type them out yourself which I found a little odd.

Public and System Folder Replication

If you are coming across from Exchange 2003 and are still supporting Outlook 2003 or older clients, then you will have to replicate public and system folders. The management console in Exchange 2007 has no management of Public Folders at all, so everything has to be done from ESM on Exchange 2003. The folders to replicate are the same as Exchange 2003.

User Creation

With everything in place, you are now ready to setup users, groups etc. Unlike Exchange 2003, this needs to be done from the Exchange Management Console. You cannot use Active Directory Users and Computers. You use EMC for email tasks, and ADUC for account tasks that are not email related (password reset, login script settings etc). That will take a little getting used to.

Still to Come...

That will do for now... later in the week I am planning to have a post on setting up a single Exchange 2007 server, how to get round an annoying SSL certificate prompt when using Exchange 2007, Outlook 2007 and a commercial certificate, greylisting with Exchange 2007 and a few other bits.

On my technical site amset.info I have an article on how to detect the operating system in a login script.
The method that I use is to dump the results of ver out to a text file, then find the version number in those results.
Here is a code snippet based on what is on that page, for detecting Windows XP. (http://www.amset.info/loginscripts/os-id.asp)

 ver >"%userprofile%"\ver.txt
 
 Rem now find the operating system and act accordingly
 
 findstr 5.2 "%userprofile%"\ver.txt
 if errorlevel 1 goto XP
 
 :notxp
 echo not XP
 
 goto end
 
 :xp
 echo XP
 
 goto end
 
 :end
 echo end

When Vista was released, I decided to update the page to include Vista as an example.
I therefore added the following line:

 findstr 6.0 "%userprofile%"\ver.txt
 if errorlevel 1 goto Vista

However this was based on theory, and wasn't something that I had time to test before I uploaded the new page.

Needing to use it for a client who has a couple of Vista machines and part of the login script wasn't required for Vista, I tried using my own code to skip that section.
If failed to work correctly and I couldn't understand why it wouldn't skip the section I wanted, but worked for older versions of Windows.

The answer I found was in the results of the ver:

XP: Microsoft Windows XP [Version 5.1.2600]
Vista: Microsoft Windows [Version 6.0.6000]

It appears that findstr command ignores the "." in the string. So it was looking for 60 and was finding it in the XP ver results.

The solution is to change the string to search for to 6000 which results in a positive detection.

Update March 2008: With the release of Vista Sp1 the detection fails because Microsoft changed the version string, again. The updated commands required are here: http://blog.sembee.co.uk/archive/2008/03/17/74.aspx

Despite Exchange 200x being around for over seven years, the question of hardware configuration is still frequently asked and discussed on forums and message boards around the internet.

Exchange is a high transactional database, which means it is constantly writing to its hard disks. Therefore, when you are considering what hardware to purchase for Exchange, you need to remember that you get the best performance from Exchange by prioritising its storage needs.

From a processing power point of view, you can large numbers of users on low end hardware. A single processor with a 1 gb of RAM will support 100s of users on a dedicated machine.

If you have one eye on a possible Exchange 2007 deployment later on, then get the smallest number of RAM modules that you can afford, so that you can put more RAM in place later. Although remember that you cannot in place upgrade to Exchange 2007, so you will need another machine to do a swing migration.

Also remember that Exchange 2007 is 64 bit only, but Exchange 2003 doesn't install on to 64 bit. Therefore you could purchase a machine with a Windows 2003 64 bit license, but you would need a 32 bit media kit to install Windows for use with Exchange 2003.

The rules with hardware selection on Exchange 2007 will change anyway, as it is 64 bit and can make better use of more processing power and memory. Despite these advances in the use of the processor and memory, the storage configuration outlined here will still be valid with Exchange 2007.

Array Selection

At a minimum, even with a small number of users, you should be looking to use at least two arrays.

- A mirrored array of two disks for the OS, application files and logs.
- A RAID 5 array of at least three disks for the database.

If you have a machine that can take six disks, then another disk as a hot spare can ensure that the server is able to run at optimum levels most of the time.

Remember that hard disks will fail, it is just a matter of when.

Partitioning the Disks

Partition wise, the mirrored array would be split. Usually 20gb and then the rest. So if you have 72gb of space you would have a 52gb second partition.
The transaction logs would then go in to a folder on this partition.

The files go in to a folder on the partition rather writing to the root of the partition for a number of reasons.
- it makes it easy to keep track of what they are
- it ensures that the server keeps running - Windows doesn't like lots of files in its root.
- it allows you to put something else on to this partition. I often share it with the message tracking logs.

Why partition the drive?
Partitioning isn't done for performance reasons, but for data protection.
If something happens, for example a mail loop or some kind of attack, the transaction logs will grow very quickly, using all the space that is available.
By having a restriction on the drive, there will be a point where no more logs can be written. At that point Exchange will dismount the stores.
However, the machine will still be running, giving you access to troubleshoot the problem.
If the logs had been on the same partition as the OS, then you may have a crashed server as well to deal with. Windows doesn't like having no free hard disk space.

The other array for the database would be a single partition.

More Disks Means No Partitions

If you have the budget, then go for something that can take at least eight disks.

2x mirrored OS
2x mirrored transaction logs
3x RAID 5 database
Hot spare.

If you are on Enterprise edition, then you can further increase the performance by having multiple arrays - with each array housing a separate storage group or mailbox store. The bottleneck at that point would then be the drives housing the transaction logs. At that point you could even go as far as having two arrays for each storage group - one for the database and one for its logs. It all depends on what your budget is like.

What about disk space?

The disk space required for the OS and transaction logs isn't really an issue. The smallest drives you easily purchase now are 72gb, which will be fine for a combined OS/Logs array or for separate arrays for the OS and logs.

The database array provides much more scope and very much depends on which version of Exchange you are installing.

If you are installing Enterprise edition, which is theoretically unlimited in storage space, then you need to make a guess at how much space you will need. If you already have Exchange, look at your current store size, double it and add at least 30%. If you have the users mailbox sizes restricted, then your life is a little easier as you can ask HR for a predicated population growth. However you are still taking an educated guess.

If you are installing Standard edition of Exchange 2003, then things are much easier, as there is a hard limit.
Standard edition of Exchange 2003 with Service Pack 2 can support up to 75gb in the mailbox store and the public folder store. This gives you a maximum use of 150gb.
Allowing for the use of the recovery storage group, recovering a store at the maximum size you would need another 75gb.
While Public Folders cannot use the RSG you should probably allow enough space for them to be recovered as well, meaning a total capacity of around 300gb.
Therefore 3x 146gb drives would be enough (giving you about 250gb of space) or if available, three 300gb drives.

RAID Card

Don't forget to purchase a good fast RAID card. If you have decided to make the investment in the storage, then ensure that the RAID card is up to the job. Don't put a small 64mb RAID card in and hope it will support your large database and high transactions. At least a 128mb RAID card and if your budget will take it, go for something even faster. You should aim to get the data to the disks as quickly as possible.

Conclusion

When faced with a choice between RAM/Processor and storage, storage wins every time. That is where the most can be gained from the investment on an Exchange server.

There are so many reasons why you shouldn't use a POP3 connector on an Exchange server that it is difficult to know where to start.
I don't simply mean the POP3 Connector supplied with Small Business Server, but any third party POP3 Connector. They all have the same issues.

With the correct choice of services and configuration, there is almost no reason why a POP3 connector should be used as part of the deployment of Exchange.

POP3 is a client to server protocol. Designed for pulling email from the server for storage in the client. Exchange is not a POP3 client. All that the POP3 connector does is pull the email down, then place it in to the SMTP queue for delivery to the end users.

With the SBS POP3 Connector, that is done at 15 minute intervals.

I have outlined the most common arguments for using the POP3 connector below and why they don't make a very good case.
Then I have outlined the major benefits of using SMTP delivery.

I may well update this article in the future, so if you are using the RSS feed and it comes up again, then that is why.

Common Arguments for using the POP3 Connector.

I don't have a static IP address.

Not having a static IP address is not a hurdle for hosting your own email.
Simply use one of the dynamic DNS services to map a dynamic DNS to your MX record host, or just use the dynamic DNS address host in your MX records.
You will need to put a tool on to the server to keep the dynamic DNS address active, but there are lots around.
http://www.amset.info/exchange/dynamicip.asp

My ISP blocks port 25.

If you are running Exchange on a "residential" connection, or the ISP wants you to upgrade to a business class connection that costs many times the normal amount for basically the same service, then you may find that port 25 is blocked.
For outbound email you can use an SMTP Connector.
For inbound email, simply subscribe to one of the mail hop services. These services provide you with hosts that you put in to your MX records and will receive email for you. They then forward the email to you on an alternative port that is not being blocked.
Furthermore, in the event of a failure of your server or internet connection, these services will queue the email for you, which also deals with the "protection" reason (see below).

It provides "protection" in case the server goes down.

One of the most common reasons that people want to use the POP3 connector is because of the protection that is provides for them in case the server goes down.
This is often the reason given by people who don't understand the way that email and SMTP delivery works on the internet.

You should have complete control over your email at all times.
In fact, you should have control over all aspects of your internet service.

What happens if your ISP goes bust? It happens. Not as often as it once did, but it does happen.
If you are using a dedicated web hosting company, then they are more likely to go bust than regular ISPs, because the hosting market is so competitive. (I can rent a dedicated server for UK£45 a month - on that I could get 100 web sites very easily).

You have an disagreement over a bill with your ISP. They cut off access to your email until you pay the bill - holding you to ransom. 

You should have the email delivered to your server at all times, using SMTP. That is what Exchange is designed to do.

However, many people will see that the Exchange server is a single point of failure for email delivery. Unless you pay out for additional services and applications, that will be a factor for most companies.
You also have the internet connection - that is often a single point of failure as well.

SMTP email has some protection built in. Most servers are configured to attempt to deliver email for 48 hours before giving up. If email is that critical to your business, then you will not wait 48 hours before getting some kind of email service. Where hardware is available, I can have a server back running in around four to six hours. It may not have the old information available to the users, but what most companies want is new email, the old content can wait a bit longer.

If hardware isn't available, then you can use an alternative email service, collect the email with POP3 and then import it back in to Outlook. That can be fixed up in around 30 minutes, with just clients to configure.

If you are in a larger site with multiple servers, then it probably doesn't apply as you will be able to make internal arrangements.

My mention of POP3 in the previous paragraphs doesn't mean using the ISPs POP3 service, or supports the use of the POP3 connector.

How can you protect yourself?

The biggest problem with making alternative arrangements is the DNS propagation time. It takes 48 hours for DNS changes to fully propagate round the Internet. Therefore if you were to rely on replacement DNS changes, you would loose email.

The trick that I like to use is to use a second MX record and a dynamic DNS service provider.
The dynamic DNS entry is pointed at your existing IP address - so you have two MX records pointing at the same location:

MX value: 10 mail.domain.com
MX value: 50 companyname.dyndns.org

mail.domain.com Type: A Value: 123.123.123.123
companyname.dyndns.org Type A: Value 123.123.123.123

Note that two hosts have been used, not a alias to the original host.
While this does break the official best practises for MX records in having two records pointing at the same host (which will be flagged if you use dnsreport.com for example), in operation it has no effect.

In the event of a failure, the original lowest value MX record is no longer responding. The sending servers will try the higher value MX record - which at the point of failure also isn't responding.

Simply change the IP ADDRESS on the dynamic DNS record to point to your alternative server or internet connection. No other changes are required, and email will begin to flow very shortly afterwards.
You haven't got to wait for DNS changes to propagate, because they are already there. The dynamic DNS services have setup their service so that host changes are reflected around the internet very quickly.

Once the original server has been fixed, change the entry back again and email to the alternative server or IP address will very quickly dry up.

Why not use a Backup MX Service?

You may have seen advertised backup MX services. This is where another server is configured in your MX records to accept email for your domain - using similar values to my example above.

The reason not to use backup MX services is quite simple.
In most cases it is only spammers who will use the second (higher value) MX record to send email. The theory being that the backup record is not so heavily protected against spam.

One of the most effective ways to deal with bandwidth use by spam and virus carrying messages is to simply refuse delivery for users who are unknown on your server. http://www.amset.info/exchange/filter-unknown.asp
This feature works by rejecting the message at the SMTP stage, before the message has been delivered. In a small site it is very effective.

If you are using a backup MX server, then you will probably be unable to use that feature, because the backup server has already accepted the message. Attempting to refuse delivery of the message will cause the messages to queue on the ISPs server as they are trying to bounce the message back to the "sender". In most cases the sender of the spam is spoofed and doesn't exist.

My ISP / Web Host doesn't provide an SMTP feed.
That excuse is one that is regularly heard. You don't need an SMTP feed to host your own email. That excuse often comes from the ISP / host, who just want control over everything. They recognise that you could be using your own email server, and want to ensure that you have a level of reliance on their service. They may even be charging you on a per mailbox basis, and don't want to see their revenue stream removed.

To have email delivered to your email server, all you need to do is get your MX records configured to point at your server instead of theirs. If they will not change the MX records, then transfer the domain to a domain name registrar where you have complete control. You can continue to use the ISP/host for hosting the web site (despite what they may say).

I have users who need to collect email from outside by POP3.
If you have any kind of permanent connection to the Internet, then they should be collecting email from the Exchange server. Configuring a domain and Exchange server to share a domain with another email server is problematic and an administrative overhead you could probably do without. It can be done, and is documented on the MS KB but I wouldn't advise it.

If you are on Windows 2003/Exchange 2003 or SBS 2003 then remote users should be configured to use RPC over HTTPS. This gives the user the Exchange feature set, without requiring a VPN. It just needs an Internet connection.

I don't have a permanent internet connection.
Of the main reasons for using a POP3 connector, this one is probably the only reason for using it for some sites. It is probably the ONLY reason I would deploy the POP3 connector, and that would be only after all other alternatives have been investigated an found not to be available.
However you still don't have to use the POP3 connector.
Use an ISP that supports ETRN collection. This is effectively "SMTP on Demand". The Exchange server connects to the Internet and then sends the ETRN server a command to say that it is ready to receive email, and the ETRN server then delivers it. You get most of the benefits of the SMTP type delivery, but without the hassles of POP3 collection.

The CEO wants to import his personal email in to his Exchange mailbox.
This reason has started to become more frequent with the increasing amount of space available in web mail services. There is no technical reason why this is a bad idea. Depending on the relationship you have with the staff member who requests it, you may not have any other choice.

However the best counter-argument for this reason is the loss of privacy. It is personal email. Once it has been imported in to Exchange, it becomes business content. It will be backed up and could be read by anyone else once the staff member has left the company.

Does that email have a place going through company systems?

I am also very suspicious of someone using personal email for business purposes. Why would they want to mix personal and business email up. The main reason is so that they can remain in touch once the business email is no longer available. Or perhaps they don't trust business email or are hiding something.

Benefits of SMTP Email Delivery

If you are currently on a POP3 connector, then why should you switch to SMTP delivery?

It is How Exchange is designed to work.
Exchange was built around the SMTP protocol, and is designed to work with SMTP.

Almost Instant Email Delivery
Most POP3 connectors will only collect email at most every minute, and the SBS POP3 Connector at 15 minute intervals.

As a consultant, one of the easiest ways for me to look good is to ditch the POP3 connector and switch the client to SMTP. The users see an immediate benefit as email is delivered shortly after it is sent - not when the server decides to collect it.

Add and Remove Users easily
You can simply add and remove users, email accounts, distribution lists to the server without having to worry about the configuration of the POP3 account. If you have named mailboxes with the ISP, then you don't need to configure those either.
If you are using a "Catch All" type mailbox, then you have bigger problems which can be solved by using SMTP delivery

The most effective anti spam measures are based on SMTP delivery
If you want to effectively deal with spam, then you need to block it at the point of delivery. With a POP3 connector you cannot do that, as it has already been "delivered" - to your ISPs server. If you attempt to block the message after that point your ISP will probably make you stop and insist that you download all the email that is waiting for you.

If you are using a "catch all" email account, which POP3 connectors, do, you will be bringing down spam messages with your legitimate email. As the sender of the spam messages is more often than not spoofed, your server will be unable to bounce the message and the messages will either queue or have to be dropped. This is a waste of bandwidth.

The two most effective methods of dealing with the major of spam messages are filtering unknown users (http://www.amset.info/exchange/filter-unknown.asp) and grey listing (http://blog.sembee.co.uk/archive/2006/09/18/27.aspx) .
Both of those require the email to be delivered directly so that the messages can be blocked.
Those measures are also effective against many of the email virus threats.

Remote Sites Know the Message Has Been Delivered
When you have your email delivered directly, remote sites can check their logs to see that the message has been correctly delivered to your server.