SEMblog

Scott Schnoll is reporting on his blog (http://blogs.technet.com/scottschnoll/archive/2007/01/24/exchange-2007-32-bit-management-tools-available-for-download.aspx) that Microsoft have released 32 bit management tools for Exchange 2007. This allows you to manage Exchange remotely in the same way that you could by installing Exchange 2003/2000 system tools on to other machines.

However the download is almost 700mb!

Apparently it includes the help file, the best practises tool, the help file etc.

Download the tools from here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=6be38633-7248-4532-929b-76e9c677e802&DisplayLang=en

What the download does not include is the additional tools that you need to install first…

MMC 3.0
Net Framework 2.0 (plus an update)
Powershell

So you will need to download those.
Use the links I posted on my blog a little while ago (http://blog.sembee.co.uk/archive/2007/01/15/32.aspx).
If you installing the Exchange tools on Windows XP, make sure that you get the XP versions of the additional components, as the Windows 2003 versions do not install on XP.

You also need to install the core components of IIS. For Windows XP this is just 1mb, which is installed through Add/Remove Programs, Windows Components. Go in to IIS and choose "Common Files".

The installation defaults to Typical, which includes some server roles, which is very odd. You will need to change to custom installation and then select just the management tools.

Once installed, there is no change in the functionality - it is the same as the tools on the server itself.

http://blogs.technet.com/scottschnoll/archive/2007/01/24/exchange-2007-32-bit-management-tools-available-for-download.aspx

For the second year in a row, I have been named Expert of the year at Experts Exchange.
This is the third year I have one of the three prizes. I was Rookie of the year in 2005, Expert of the Year and Most Questions Answered last year and Expert of the Year again this year.

http://www.experts-exchange.com/expertAwards2007.jsp

I have also just crossed the 13 million points barrier.

If you haven't used Experts Exchange before, then you are missing out.
Despite how the site has been setup, it is free to join. If you answer questions, and earn 10,000 points (which can be earned by answering as few as 5 questions worth 500 points (there is a multiplier involved)) in a month, then 3,000 points every month thereafter, you will have full access to the site without having to pay anything.

30th May 2008
There is a new post elsewhere on this blog that I believe makes this post redudant. As SAN/UC certificates have come down in price it makes more sense to use those rather than the method I have outlined below. Furthermore this process does not work on Windows 2008 and Microsoft do not support Outlook Anywhere outside of the default web site.
To see the updated blog posting click here: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx 

I will leave this post here for reference, but I suggest that you deploy a SAN/UC certificate using the guide I have written above.

1st October 2007
I am aware that at least one SSL vendor is sending some customers to this blog posting when asked about deploying their certificates with Exchange 2007. If you have been sent here by a vendor, then you should ask them why they are sending you to a blog rather than assisting you with resolving the problem.

Remember that this is one solution to the problem, and it is not a solution that Microsoft recommend. I have found that it works, but that does not mean it is the ONLY solution.

As of the time of writing this section (1st October 2007) it is still the way that I deploy Exchange 2007 and have found that it works. I constantly review my techniques and will change the article if I believe there is a better way.

If you care about network security, you will want to use SSL certificates with your Exchange deployment. SSL certificates could be used with OWA, Outlook Anywhere, ActiveSync and the Autodiscover Service.
However as you will quickly find, SSL Certificates for use with Exchange 2007 is a mess.

When Exchange 2007 is initially installed, the installation wizard creates a self generated SSL certificate for the default web site. While this is fine for initial use, you will quickly want to replace it with a commercial certificate to avoid certificate warnings when users browse to the OWA site and to avoid complications deploying Windows Mobile handhelds.

(I have discussed the reasons to use a commercial SSL certificate on my blog last year: http://blog.sembee.co.uk/archive/2006/03/05/Self-Generated-versus-Commercial-SSL-Certificates.aspx).

With Exchange 2003 it was quite simple to deploy a commercial certificate, simply request and deploy a certificate with your chosen external name. If you wanted the same name to work inside, then you would also configure split DNS (http://www.amset.info/netadmin/split-dns.asp).

If you remove the default certificate with Exchange 2007, it will initially appear to work. If your clients are on Outlook 2003, then most things will work correctly.

However when you introduce Outlook 2007, the complications start.

Outlook 2007 is the first client to support the new web based method of Address Book distribution. Previous versions of Outlook used system folders, part of the public folder structure. Microsoft have made no secret of their desire to kill off public folders and the change in address book distribution is a key step towards that goal.

If you replace the SSL certificate with a certificate that does not match the server's real name, then Outlook 2007 generates a certificate warning when it connects to your server on the LAN. It is expecting the SSL certificate to be on the server's real name.
However best practise for certificates is to use a generic name. You may also be in a position where the server's real name ends in .local.

Therefore you need a certificate that supports the additional name.

On a side issue - you will note that Outlook does not generate a warning message on your self generated certificate, which will not be trusted by the client. It has been confirmed that Outlook does not check the trust status when connecting to Exchange on the internal network.

Then you get the complication of the autodiscover service, which is new for Outlook 2007. That connects to autodiscover.domain.com (where domain.com is the domain name in your email address). Therefore your SSL certificate on host.domain.com will not be accepted because it doesn't match the address being accessed.

If you are fortunate enough to be using the same domain name for your AD domain, as your primary email domain, which is also accessible from outside (domain.com), then you might be thinking at this point to purchase a wildcard certificate - so that *.domain.com would work.
That would be fine, but if you want to support Windows Mobile devices, then you will need to think again, as Windows Mobile does not support wildcard SSL certificates.

Therefore what is the solution?

You could look to purchase an SSL certificate that supports the additional names. However none of the cheap SSL certificate providers (RapidSSL and GoDaddy) issue certificates that allow you to have the additional names. The only certificate that I have found that does is one of the US$600 certificates from Geotrust. Having to pay $600 for a certificate just to secure OWA seems very expensive and is not something that many sites will accept.

Therefore the resolution to this problem I have found is to use multiple web sites.

This isn't as hard as it may sound and I will give you the brief steps here. (More comprehensive instructions will appear on the amset.info web site at some point in the future).

1. Setup Outlook Anywhere as required. This is important as it is the one feature that cannot have its virtual directory recreated using the Exchange Management Shell.
   
2. Add an additional internal IP addresses to your Exchange server's network card. For example, if 192.168.1.1 was the default address for the server, you would add 192.168.1.2 as an additional address. It does not have to be the next address, just as long as it is on the same subnet (192.168.1.x)
   You need additional IP addresses as you cannot use host headers with SSL.
   
3. Adjust the configuration of IIS so that the default IP address is bound to the default web site. This is a change from the "All unassigned" setting.
   
4. Create a new web site in IIS Manager. In this example I will call it External. Set it to use the additional IP address, using the default ports. When asked for the path, use the same as the default (C:\Inetpub\wwwroot). When asked for permissions, select Read and Run Scripts only.
   
5. Open the Exchange Management Shell and run the following commands:
   If you are supporting Exchange 2007 Mailboxes ONLY:
   
   New-OWAVirtualDirectory -OwaVersion:Exchange2007 -Name "owa" -WebSite "External"
   
   If you are also supporting Exchange 2003 mailboxes, then you need to run these additional commands:
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exchange" -WebSite "External" -VirtualDirectoryType:Mailboxes
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Public" -WebSite "External" -VirtualDirectoryType:PublicFolders
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exadmin" -WebSite "External" -VirtualDirectoryType:Exadmin
   
   New-OwaVirtualDirectory -OwaVersion:"Exchange2003or2000" -Name "Exchweb" -WebSite "External" -VirtualDirectoryType:Exchweb
   
   For ActiveSync, run the following command:
   
   New-ActiveSyncVirtualDirectory -WebSiteName "External"
   
   When you refresh the configuration in Exchange Management Console, you should see two sets of virtual directories under Server Configuration, Client Access, Outlook Web Access and Exchange ActiveSync.
   
6. To add Outlook Anywhere to the web site, open up IIS Manager. In the default web site, find the /rpc virtual directory. Right click on it and choose All Tasks, Save Configuration to a File… and save the configuration.
   Then on the new web site that you have just created, right click on the root and choose New, Virtual Directory (from file)…
   When prompted select the file that you exported from the default web site.
   
   Important note - any configuration changes to Outlook Anywhere do not appear to be reflected in this exported file, so it is important that any configuration is done before the export/import. If you make any changes to the Outlook Anywhere configuration then the export/import will need to be repeated. Delete the imported virtual directory and replace it with a freshly exported configuration file.
   
7. Once you have created the virtual directories, you can then put an SSL certificate on to the new web site and then point external traffic to that address.
   Internal traffic can also be pointed to the new web site.
   Leave the self generated certificate on the default web site, as Outlook 2007 will continue to connect to it.

Autodiscover Service

For Autodiscover, you actually have two options.

1. Repeat the above process, with a new dedicated web site for autodiscover.
   The command for a new Autodiscover virtual directory is
   
   New-AutodiscoverVirtualDirectory -Websitename Autodiscover -BasicAuthentication:$true -WindowsAuthentication:$true
   
   That web site can then get its own SSL certificate.
   This could be useful if you use two different domains, one for email and one for external facing web services. Autodiscover uses the same domain as your email.
   However if you have multiple domains for email, you will need to use the redirect method.
   
2. Add to the external web site and configure a redirect.

To add the Autodiscover virtual directory to the External web site created in above:

New-AutodiscoverVirtualDirectory -Websitename External -BasicAuthentication:$true -WindowsAuthentication:$true

The redirection configuration is very important to ensure that it works correctly. The redirection method requires port 80 (http) traffic to come in. For internal traffic that is fine, but for external traffic you may want to look at a way of configuring the redirection using a public web site.

At the time of writing, this is Microsoft's article on redirection. It is covered under the section Hosted Environments and the Autodiscover Service, but would also be useful if you have more than one domain, or you use a different domain for email than you do for external facing web services.

http://www.microsoft.com/technet/prodtechnol/exchange/e2k7help/4172728f-bb70-4579-9d5d-fccdd4afcd80.mspx?mfr=true

Conclusion

Your control over the web services of Exchange 2007 provides you with many more options for using SSL than Exchange 2003. Unlike Exchange 2003, with the exception of Outlook Anywhere, these options are provided as part of the product, allowing you to use them with the confidence that they should work as expected and can be managed with other features of Exchange.

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.