Exchange Server 2007 Availability and Autodiscover Service

The availability service only works with client computers that are members of the domain, or else it can’t get the location of the autodiscovery stuff without Active Directory. The alternative to looking it up in AD is to create a website on an Exchange Server 2007 box called Note the requirement for https and not just http. It won’t work unless you have an SSL cert set up properly.

So create a new website with its own IP address (a necessity for a SSL site), called
Create a new Autodiscover web service in it with this:
new-autodiscovervirtualdirectory -BasicAuthentication $true -DigestAuthentication $false -ExternalUrl -InternalUrl -Path "C:\Program Files\Microsoft\Exchange Server\ClientAccess\Autodiscover" -WebSiteName autodiscover -WindowsAuthentication $true
That command takes quite a few seconds to run.

You can then compare the output of the original with the new one
Get-AutodiscoveryVirtualDirectory -Identity “EXCH” | fl

You might as well tick the “require secure channel (SSL)” box in the website properties / Directory Security / Secure Communications / Edit dialog, as Outlook will only use it over https anyway.

Once the SSL cert is in place, you can switch the new site ‘on’ with
Set-AutodiscoverVirtualDirectory -Identity “EXCHANGE3\Autodiscover (autodiscover)” -BasicAuthentication $true -DigestAuthentication $false -WindowsAuthentication $true -ExternalUrl -InternalUrl
The format of the -Identity parameter is server-name\url-section (web-site-name).

It may then be worth re-testing the autodiscover functionality in Outlook 2007, from a PC that is not a member of the domain. Outlook logging goes into the %TEMP% directory (Start / Run... / %TEMP%). To enable it in Outlook 2007, go to Tools / Options / Other / Advanced / Enable logging (troubleshooting). The logs go into a file with a strange name (but I think it ends in .log) and a directory name something like olkas with up-to-the-minute log information files in it. You can search by modification date under %TEMP% if all else fails. Ctrl-click on the Outlook 2007 icon in the alerts toolbar (right end of task bar) and choose “Test Email configuration”. That should let you try everything out. Plus do it for real by creating a New Meeting Request and add hg or hcd or wh or hos to it and show the Schedule Assistant as that will attempt to get the Free/Busy information for them from the Exchange 2007 server.

This does indeed all now work. Free+Busy from Outlook 2007 clients that are not members of the domain works just fine, as does auto-configuration of new users in Outlook (any version).

Exchange Server 2007 “Service Unavailable” on /public

This appears to be caused by the Public Folders database not mounting correctly, despite the Exchange System Manager saying it has. This is usually due to replications being missing from some of the system public folders. Dismount and them re-mount your public folder database, then go in to Event Viewer and look at the application log. This will probably show you errors, the detail of which tells you the replication(s) that is(are) missing. Fix those, leave them to replicate, then try dismounting and remounting your public folder database again. You should get a clean mount in the Event Viewer.

Once it works, should produce a login box, and not just a “Service Unavailable” error.

Exchange Server 2007 “Service Unavailable” on OWA

This is apparently caused by installing important security patches, noticeably anything to do with .Net. It installs the 32-bit version of .Net 2.0 Service Pack 1, where Exchange Server 2007 requires the 64-bit version and will only work with the 64-bit version.

In the Event Viewer it generates an error 2268 or 2274.
The event text includes “ISAPI Filter ‘C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\\aspnet_filter.dll’”.

Fortunately, this one is easy to fix. Look up and follow the instructions give in the “ASP.NET 2.0, 64-bit version” section.

To run the 64-bit version of ASP.NET 2.0, follow these steps:
1. Click Start, click Run, type cmd, and then click OK.
2. Type the following command to disable the 32-bit mode:
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 0
3. Type the following command to install the version of ASP.NET 2.0 and to install the script maps at the IIS root and under:
%SYSTEMROOT%\Microsoft.NET\Framework64\v2.0.50727\aspnet_regiis.exe -i
4. Make sure that the status of ASP.NET version 2.0.50727 is set to Allowed in the Web service extension list in Internet Information Services Manager.
Note The build version of ASP.NET 2.0 may differ depending on what the currently released build version is. These steps are for build version 2.0.50727.

Then you should find that OWA (Outlook Web Access) and Entourage 2008 support start working again.

Entourage 2008 and Exchange Server 2007

Out of the box, even with an Exchange 2007 server installation including support for Exchange 2003 and earlier (ie. a “legacy” install), Entourage 2008 simply does not connect to the Exchange 2007 Server. That’s pretty poor in my view, they are both the latest versions of Microsoft’s own products, and it just does not work. Pretty crap Sad

Hopefully this note will help you get them working together properly.

Start up an Exchange 2007 Management Shell from the Exchange 2007 Programs menu, and the IIS manager from “Administrative Tools”.

Delete the Exchange subweb from IIS on the Exchange 2007 server.
This only deletes it from IIS, it doesn’t take it out of the Exchange 2007 Active Directory data.
So when you try to create it with New-OwaVirtualDirectory, it will give an error saying it already exists.

So do this:
remove-owavirtualdirectory -Identity "exchange3\Exchange (default web site)"
remove-owavirtualdirectory -Identity "exchange3\Public (default web site)"
exactly as given, except for the “exchange3” which should be replaced with the name of your Exchange 2007 server. This is assuming your Exchange 2007 server is called “exchange3”, so edit it appropriately.

New-OwaVirtualDirectory -name Exchange -OWAVersion Exchange2003or2000 -VirtualDirectoryType mailboxes
New-OwaVirtualDirectory -name Exchange -OWAVersion Exchange2003or2000 -VirtualDirectoryType PublicFolders
Also read

In the Account properties “Edit Account” dialog box, set this
Account ID:
Leave the Domain blank and the Password blank.
Ok this dialog, then quit and restart Entourage 2008.

If that Account ID setting doesn’t work, try this instead:
Account ID: ECS2000\jkf-private
where “ECS2000” is your Active Directory domain name, and “jkf-private” is your username. Again, leave the “Domain” and “Password” blank, it will prompt you for the password. Never type in anything into the “Domain” box, always leave that blank.

I still cannot get Public Folders working from Entourage 2008. Sorry.

Let me know if this helps or not.

MAPI/CDO with Exchange Server 2007

In all previous versions of Exchange prior to 2007, Microsoft shipped the MAPI client library and CDO library as part of Exchange.
In Exchange Server 2007, they have stopped doing this. If you need the libraries, you need to download them from here:

Applying Exchange Server 2007 Service Pack 1

Due to us having a scheduled lack of internet connection, we chose this as a good time to patch the management’s Exchange 2007 server.

Be warned: to get this service pack to apply, you must first install .Net 2.0 service pack 1 which they chose not to bundle with the enormous Exchange service pack 1. Why not? Who knows! Sad The service pack doesn’t fit on a CD anyway, so why not just include a copy of .Net 2 SP1 with it? Finding the service pack on their website is not trivial either, as it’s very badly titled and so most of the obvious search terms don’t help you. Go to and search their downloads for “.Net 2 SP1”. This will find you the x86 version, and there is a link to the x64 version near the bottom of the page, as well as the ia64 Itanic release if you need that instead. It’s currently at:

Install that and then reboot. The server needs to be able to see the Active Directory schema master as well, so I hope your internal network is working (our’s wasn’t due to our campus network managers’ incompetence at their stunning inability to hire a generator to keep a few routers up and running).

After this, install the Exchange SP1. It installed perfectly on our server, and the whole process took about 20 or 30 minutes and did
not require a reboot afterwards.

The only damage it appears to have done is set the “https required” flag on the default website in IIS. I have this switched off and do an auto-redirect from
http://exchange...../ to https://exchange...../owa, which saves our users a lot of typing and saves us a lot of “I can’t get at the webmail” complaints.