If you use an older version of Outlook and are missing holidays for 2008 and beyond, its and updated holiday file is available for all versions.

If you use Outlook 2003 (or upgraded to Outlook 2007 from Outlook 2003 and didn't add more holidays) you may have noticed you are "missing" holidays for 2008 and beyond. If you want to believe it’s a conspiracy by Microsoft to force you to upgrade, I have a bridge to sell you, but the truth is that when they release the versions they feel 5 years was far enough out to provide in the holiday file.

You can download the Outlook 2003 Holiday update from http://support.microsoft.com/kb/924423. This is the same file that is included with Outlook 2007.

While users can Add Holidays by double clicking on the Outlook.HOL file to open the Add Holidays dialog, you should replace the original outlook.hol file at C:\Program Files\Microsoft Office\Office11\xxxx (where xxxx is the 4-digit language code for your language) folder so that its available if users decide to add additional holidays later. Otherwise, the Tools, Options, Calendar options, Add Holidays dialog will not contain the updated holiday list.

If you need updated holidays for older versions of Outlook, see Missing Holidays at http://www.outlook-tips.net/howto/missinghol.htm. 

Several people complained about the inability to always open documents attached to an email messages. They were always presented with the Open or Save dialog and the option to "Always ask before opening" was disabled for all file types. Others removed the check so Outlook 2007 never asked but wanted to restore the dialog.

In Outlook 2007, the HKLM\SOFTWARE\Classes\[file type]\EditFlags binary value holds the 'always ask' value. A data value of 00 00 00 00 means Outlook will always ask if you want to open or save the attachment, while 00 00 01 00 opens it without asking.

If the EditFlags value does not exist, create it with 00 00 01 00 data to eliminate the dialog and open the message.

Word 2007 DOCX extension is controlled by this key:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Word.Document.12

Adobe PDF is
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AcroExch.Document

Word's DOC extension is
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Word.Document.8

So what controls whether an attachment opens read only? Attachments opened from the preview pane are always read only while attachments opened from opened messages are editable.

See Restore (or Hide) the Open Save Dialog for more information.

Exchange MVP William Lefkovics wrote in the November 29, 2007 EMO about Exchange Server 2007 Service Pack 1 and many of the changes included in the service pack. You can read that article in the EMO archives at http://www.slipstick.com/emo/2007/up071129.htm.

One of the additional changes for administrators is that service pack 1 has been slipstreamed into the base release. That means that the service pack 1 installer includes the base release and it is not necessary to maintain separate installation media for the service pack and for the RTM release. This is new for Exchange Server and will help to simplify the deployment and update options for Exchange Server.

Note: RTM stands for Release To Manufacturing. The RTM release is the first release of a major version update to a product before any service packs are applied, such as: Exchange 2000 Server, Exchange Server 2003, and Exchange Server 2007.

In the past, when deploying a new Exchange Server, it was necessary to first install the RTM version of Exchange on the server and then install the latest service pack. (And, there were some rare situations where you actually needed to install every service pack in increasing order.)

Now, only the service pack archive itself is needed in order to install an Exchange Server. (Plus a language pack for the non-English versions.) This can result in a significant administrative savings when rolling out a new and/or updated Exchange environment (for example, an organization may choose to update all its Exchange Servers to Windows Server 2008).

When installing Exchange Server 2007 service pack 1, there is a specific order in which the service pack should be installed into the Exchange environment. This order is similar to guidelines that existed for earlier versions of Exchange (update all of your front-end servers first, then update all of your back-end servers, etc.).

Each of your CAS (Client Access Servers) should be updated first, then update all of your Edge Servers, followed by updating all of your Hub Transport Servers, and finally complete the update by installing the service pack on each of your Mailbox Servers.

If you have mailbox servers clustered via CCR (Cluster Continuous Replication), then the update process for each mailbox server cluster is as follows: update the passive node, failover to the passive node, update the former active node, and finally failback to the original active node. In this particular case, you do not do failover using ClusterAdmin, but rather by using the Move-ClusteredMailboxServer PowerShell cmdlet (see http://technet.microsoft.com/en-us/library/bb124710.aspx for more information on using that cmdlet and see http://go.microsoft.com/fwlink/?LinkId=103632 for more information about the CCR update process).

The update process is overall much simpler than it was in past versions of Exchange Server.
Along with the items we’ve already discussed, Service Pack 1 also has speed improvements, reduced memory usage, database performance enhancements, feature parity with OWA in Exchange Server 2003, support for Windows Server 2008, better public folder support, support for importing and exporting mailboxes, plus many other improvements.

It is practically a truism that “service pack 1” is what the original release of a piece of Microsoft software “should have been.” I believe that that has never been more true than it is with Exchange Server 2007 service pack 1. If you have not yet begun to evaluate Exchange Server 2007, now is the time. With service pack 1, there are compelling reasons to begin to investigate and test the upgrade process.

-- Michael B. Smith, MCSE/Exchange MVP

When newly created meetings default to the current date and time, regardless of day or time selected, it usually means the view is corrupt. Open outlook using the /cleanviews switch and all should be well. (Close Outlook and at the Start menu, Run command enter Outlook.exe /cleanviews)

If you have a lot of custom views you don't want to lose, you can try resetting the current view before resetting all views, but if it doesn't fix the problem you'll need to use /cleanviews.

Outlook 2007 has a lot of calendar printing bugs, which I suppose, is why they released a Calendar Printing Assistant. Some were fixed in SP1. Others are just coming to my attention, probably because I don't print calendars.

The newest bug involves printing a series of full month calendars. If you start the series in a month that spans 6 calendar weeks, each monthly calendar contains 6 rows but the names of the months at the top of the print out will be screwy: "Dec", then "Dec - Feb", "Jan - Mar" etc. When you begin printing the calendar in a month that spans 5 weeks every month will span 5 weeks and drop the last couple of days if they extend into the 6th week. At least the months are labeled correctly: Jan, Feb, March; too bad they are short a day or two.

The Calendar Printing Assistant always uses 5 weeks and addresses the problem by "compressing" the days in the 6th week into the blocks of the 5th week. If you prefer to use Outlook's native printing capabilities, you'll need to print the longer months separately.

Older versions of Outlook correctly draw either 5 or 6 rows, as needed.

For links to the Calendar Printing Assistant and other tools that will print the months correctly in 5 or 6 rows, see
Calendar Printing Tools for Outlook
http://www.slipstick.com/addins/calendar_print.asp 

For more information and screen shots, see
Outlook 2007: Month Calendar Printing Bug
http://www.slipstick.com/calendar/6weekcal.htm

Remotely managing Exchange Servers over the years seems to fall into one of two options, with some variations. First, either install the management tools components on your local workstation or second, use terminal services (RDP remote desktop) to access the console. In this overview, I will look at those options and other adaptations.

Installing Management Tools on the Workstation

Back in Exchange 5.5 and 2000, it was easy to install management tools on a Windows 2000 Pro workstation to administer Exchange. Exchange 5.5 had a separate application, admin.exe, that was installed from the CD by selecting the administration components only through the setup interface. Even the Exchange 2000 CD had the Exchange 5.5 administration tools for optional installation. Exchange 2000 also had separate administration components using a Microsoft Management Console (MMC) for each of Active Directory Users and Computers (ADUC) and Exchange System Manager (ESM). Using MMC as the standard interface added flexibility. It was possible to combine administrative interfaces into a single MMC with, for example, ADUC, ESM, Message Tracking, IIS Admin, Certificate Services and Event Viewer.

Well, once administrators had used Exchange administration tools from their desktops, it seems they wanted to continue, but things get a little complicated with different versions of Exchange as well as server and workstation operating systems. In addition, for a coexistence scenario, you needed both Exchange 5.5 and Exchange 2000 administration tools. Let’s start with Windows XP Pro. Installing ESM 2000 was not supported and failed on installation demanding the presence of the Windows 2000 Administration Tools. Trying to install the Windows 2000 Admin Tools on XP returns an error as well. The ‘workaround’ if we can call it that was to ignore the error for the Windows 2000 Admin Tools and proceed. After that, install the Exchange 2000 ESM. It worked. Oh, you wanted to use Outlook on that machine as well? Well, that, too, was not supported:

Microsoft does not recommend installing Exchange Server 5.5 and Outlook 2000 or later on the same computer
http://support.microsoft.com/kb/313889

Microsoft does not support installing Exchange Server components and Outlook on the same computer
http://support.microsoft.com/kb/266418

It can lead to unexpected and challenging issues, such as that outlined in Microsoft KB 329136:

"The information store could not be opened" error message occurs when you try to view client permissions in Exchange Server 2003 or Exchange 2000 Server
http://support.microsoft.com/kb/329136

Next we add Windows 2003 and Exchange Server 2003 into the mix. Windows 2003 had its own Windows 2003 Adminpak.msi. The same limitations applied to Windows 2003 as Windows 2000 when installing ESM on a Windows XP workstation, but it still worked. There was a challenge if you upgraded Windows XP to sp2 after ESM (and therefore IIS Manager) was installed. Reinstalling IIS and then ESM again seemed to work. Or, if you were more meticulous, removing and reapplying the IIS components called ‘Common Files’ and ‘Internet Information Services’ also worked as outlined in Microsoft KB 834121.

What to consider when you install Exchange System Management Tools on Windows XP
http://support.microsoft.com/kb/834121

Ok, so you again want to use Outlook on the same workstation? Now, when you install ESM on XP there are often conflicts with Outlook. These Outlook conflicts with ESM focus on MAPI. Some people have had better luck that others having them operate in tandem on their Windows XP workstation; whereas, others seemed cursed by their attempts. With Outlook 2003 and Outlook 2007, Microsoft provides some format for troubleshooting MAPI conflicts with Outlook in Microsoft KB 813602, but the conflict with ESM remains an issue.

You receive an error message if a file conflicts with the MAPI file on your computer when you start Outlook 2007 or Outlook 2003
http://support.microsoft.com/kb/813602

Finally, Windows Vista enters into the picture. Microsoft clearly states that Exchange Management Tools for Exchange 2000/2003 are not supported on Windows Vista.

You cannot install the Exchange Management Console or the Exchange System Manager on a Windows Vista-based computer
http://support.microsoft.com/kb/931903

This has to be one of the many small issues that deter companies from adopting the newest Windows client. The first block is the Windows 2003 Administration Tools needed by the ESM. Some people have successfully got the Windows 2003 Administrator Tools installed on Windows Vista by manually registering the .dll files with regsrv32. Indeed much of the functionality provided by the tools is then available on Vista. Microsoft has compiled the list of .dlls, a script to register them, and a list of new issues created by this option at their KB 930056:

You experience installation errors and compatibility problems when you install Windows Server 2003 management tools on a Windows Vista-based computer
http://support.microsoft.com/kb/930056

Well, along comes Exchange Server 2007. The MMC console is replaced by an application specific to Exchange 2007. We have returned to a non-extensible format as we had for Exchange 5.x. The Exchange 2007 Management Console (EMC) can be installed separately from the various server roles it controls. Exchange 2007, however, adds a very critical requirement – it is a 64-bit application. With the RTM version of Exchange 2007, installing the EMC on Windows Vista clients is not supported. However, Exchange 2007 Service Pack 1 brings some relief to those who prefer to administer their servers using installed tools on their Vista workstation. The Exchange 2007 sp1 Custom Installation lets you select just the Management Console for installation on Windows Vista where the appropriate prerequisites have been met, such as Windows Powershell 1.0 (MS KB 928439 as shown below), MMC 3.0 and the .Net Framework 2.0. The EMC includes the Exchange Management Shell (EMS) and the compiled Help files. Installing from the same media as your production Exchange 2007 Server means you are working with a 64-bit application that needs a 64-bit operating system. If you are running Windows Vista with the 32-bit client, then you need to download the appropriate 32-bit binaries available on the Microsoft download site:

Microsoft Exchange Server 2007 Management Tools (32-bit)I
http://www.microsoft.com/downloads/details.aspx?FamilyId=6BE38633-7248-4532-929B-76E9C677E802&displaylang=en

Windows PowerShell 1.0 Installation Package for Windows Vista
http://support.microsoft.com/kb/928439

The actual installation of the Exchange 2007 Management tools is not that difficult for either the 32-bit or 64-bit versions as outlined in KB 555841 and Microsoft Technet as referenced:

How to Install the Exchange 2007 Management Tools
http://technet.microsoft.com/en-us/library/bb232090.aspx

Installing Exchange 2007 Management Tools On a 32 Bit Operating System
http://support.microsoft.com/kb/555841

-- William Lefkovics

If installing the ESM (2000/2003) or the EMC (2007) seems to you to be a hassle, well, you are far from alone. Thankfully, Microsoft provides a Remote Desktop feature allowing access to the Exchange Server desktop from the workstation without installing any Exchange components locally. In Windows 2000 this was referred to as Terminal Services - Administration Mode. It is now much more common and included in all business Windows operating systems as Remote Desktop. Other applications can serve the same function, but they introduce their own set of costs, administration and security issues. These remote administration tools include pcAnywhere and Virtual Network Computing (VNC).

The client executable for RDP is mstsc.exe in the %systemroot%\System32 folder. It has a couple of parameters that you can use. You can edit a shortcut to include parameters for the window size, server name, or even log into the console. The /console switch logs the administrator into the actual console. What the administrator sees in his RDP session is exactly what he sees if he logged in directly at the server. For a server name E2K7-MB-02, an administrator might run the following from the run line in the start menu of his workstation:
>mstsc /v:E2K7-MB-02 /console
Run mstsc /? For the list of parameters.

For companies of 75-250 employees, I recommend using an Administration Server or station. This is a secure Windows 2003 R2 server which hosts your management applications. This may include Antivirus management console or Windows Software Update Services (WSUS). I would install the necessary Exchange Management Tools on that server and use RDP to access that using a separate Administrator-level logon. Of course, at your workstation, you are authenticated with the lowest required privileges to perform your tasks. You do not likely need to be authenticated as an Exchange administrator all the time, so using a separate server and username for this makes some secure sense.

RDP has come a long way as well, with various systems able to use Microsoft or third party RDP clients. This includes Windows Mobile, Linux, and MacOSX. I don’t know many who administer Exchange from their Linux box, but at least they could if so compelled.

Windows Vista adds another compelling option for some administrators. Vista can host operating systems as virtual clients. This includes Windows XP sp2 which can be used for the ESM tools for Exchange 2003 administration. As we discussed, ESM, needing IIS6, is not supported on Vista; however, it can run on Windows XP sp2 which can run as a guest using Virtual PC on Vista.

-- William Lefkovics