Issue 1. Module exppw.dll could not be loaded

The first thing that struck me when I went to test OWA was that it wasn't working. I host a few websites on the same server so I was quite shocked to see that none of them were actually functioning. For what it was worth - I had already restarted the server so an IISRESET probably wouldn't have done much good. I decided to check the Application Event Log and saw this:

Source: IIS-W3SVC-WP
Event ID: 2282
Level: Error

Error: The Module DLL 'C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth\exppw.dll' could not be loaded due to a configuration problem. The current configuration only supports loading images built for a x86 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349.

I also noticed the following warning in the System Event Log:

Source: WAS
Event ID: 5139
Level: Warning

Error: A listener channel for protocol 'http' in worker process '5436' serving application pool 'jjclements.co.uk' reported a listener channel failure. The data field contains the error number.

IIS was running, I could successfully Telnet into port 80 on the server. It appeared from the first (Application Event Log) error that IIS was trying to load a new module as part of the SP1 upgrade but couldn't. This was causing IIS to stop loading all of the sites that I had configured within it. I knew that since the release of SP1, Microsoft had released Update Rollup 1 to fix a few of the issues that SP1 brought with it. Out of best practice (and the hope that it may help my problem) I installed Update Rollup 1. Unfortunately it didn't resolve the issue.

Since the error was reporting an issue with IIS loading an x64 compiled module on x86 architecture I decided to investigate which website(s) was attempting to load the module. My reasoning for this was that by default, OWA runs in it's own application pool from a virtual directory located within the Default Website on an IIS installation. Although I had configured other application pools (for the other websites I am hosting) to run with "Enable 32-Bit Applications" set to True, the default setting of False still applied for the MSExchangeOWAAppPool application pool (so it seemed logical to assume that more than one website was probably trying to load the same module):

I used the IIS Manager to locate and then checked the web.config for the OWA virtual directory located:

C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\web.config

Sure enough there was an entry in the web.config for the site to load the exppw module, and because the MSExchangeOWAAppPool was correctly configured with "Enable 32-Bit Applications" set to False this was not the cause of my problem. Since it seemed that IIS was attempting to load the module for other application pools configured to run as 32bit (and I knowingly had other websites configured to run as 32bit) the next logical step was to check the main 'root' configuration file for IIS - applicationHost.config located:

C:\Windows\System32\inetsrv\config\applicationHost.config

The applicationHost.config file is used to store IIS configuration including sites, virtual directories, general settings, logging, caching etc. A quick search through this file revealed the exppw module was also being loaded globally (from within the <globalModules> tag):

<add name="exppw" image="C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth\exppw.dll" />

I decided that I had a couple of options to fix this issue. The first was to stop IIS from loading the module globally by removing the entry from the applicationHost.config. I figured that this probably would have worked since the web.config for the MSExchangeOWAAppPool was loading it anyway. The second option I had was to make sure that the module was only ever loaded for an application pool when it's worker process architecture matched the architecture of the module that was being loaded. I chose the second option as I was concerned that modifying the applicationHost.config to prevent IIS from globally loading the exppw module may have caused issues if any of the other Exchange 2010 application pools were depending on the exppw module being loaded globally instead of from a local web.config.

IIS7 introduced the bitness32 and bitness64 preconditions to make sure that it will only load DLLs with the correct bitness in an application pool worker processes. Where specified, the bitness64 precondition is used by IIS to identify and then load modules only when the worker process is an x64 process - not if the worker process happens to be an x86 process.

I modified the applicationHost.config to reflect the bitness64 precondition for the exppw module:

<add name="exppw" image="C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth\exppw.dll" preCondition="bitness64" />

Without even restarting IIS all of the websites that I host (including the Default Website and OWA application) started functioning again. The exppw module was now only being loaded where an application pool worker process was an x64 process.

Issue 2. Default Website additional bindings

While this didn't actually stop anything from working, the second problem that I happened to stumble across (when investigating Issue 1) was that the default website now had some additional, unconventional bindings:

It seemed that as well as the normal bindings allowing IIS to listen on ports 80 (http) and 443 (https) for all IP addresses on the server, the SP1 upgrade had added 2 additional bindings. Surprisingly, even though no host headers had been set, the additional bindings were also listening on ports 80 and 443 for the loopback address of 127.0.0.1. For consistency and just incase this caused any issues in the future, I removed the bindings. Seeing as no specific host headers were set for the new additional bindings I concluded that they would have been encompassed by the original 2 bindings anyway. A quick check revealed that none of my other websites had the additional bindings.

Issue 3. Incorrect HomeMTA attribute

Again, while this issue didn't actually appear to stop anything from working, the last problem I noticed was a consistent warning appearing in the Application Event Log. The warning was being generated at frequent intervals for each mailbox that I had configured within Exchange 2010:

Source: MSExchange ADAccess
Event ID: 2937
Level: Warning

Error: Process w3wp.exe () (PID=7276). Object [CN=James,CN=Users,DC=jjclements,DC=co,DC=uk]. Property [HomeMTA] is set to value [jjclements.co.uk/Configuration/Deleted Objects/Microsoft MTA
DEL:75830fde-6ed2-4fe2-b91c-005d7f6b1e6d], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.

A quick search revealed that the HomeMTA user account attribute was now obsolete for Exchange 2010. Yet, for some bizarre reason Exchange 2010 was obviously still checking that the value was valid (and unfortunately logging a warning in the Application Event Log if it wasn't.)

I used ADSI Edit to check the attribute for one my user accounts and confirmed it was set to the Deleted Objects container. Even though I don't have lots of Exchange users, rather than use ADSI Edit to update the HomeMTA attribute manually for each and every mailbox user I wanted to update them collectively. I had read that the Update-Recipient cmdlet could be used to update user account attributes, including HomeMTA. So, from the Exchange Management Shell, I used the Get-Mailbox cmdlet to retrieve all the user accounts with a mailbox in my single Exchange 2010 database and then piped the results into the Update-Recipient cmdlet. The following command successfully updated the HomeMTA attribute for all user accounts that had a mailbox in my Exchange 2010 database and stopped the warning from appearing in the Application Event Log:

get-mailbox -database "<databasename>" | update-recipient

When I checked the Application log in the event viewer I was presented with the error:

Source: Active Server Pages
Event ID: 5
Level: Error

Error: File <url to upload.asp> <line number> Operation not Allowed.

The error indicated that there was an issue with the ASP configuration for the website hosting the application so I had a quick look at the ASP settings in the IIS Manager:

In the settings for ASP I noticed the following option:

Limits Properties --> Maximum Requesting Entity Body Limit

The default value for this property is 200000 bytes which is just under 0.2 megabytes. The file I was trying to upload was just over 3 megabytes so I needed to increase this value. I changed it to 10485760 bytes which is 10 megabytes. Upon retrying to upload the document through the ASP application I was successful. No restart of IIS was necessary.

Download the MySQL installer from HERE

The installer comes in a .zip file so you will need to extract it. Now run the installer (setup.exe) and select the 'Typical' setup type. Click 'Install' to begin the installation process. Once the installer copies files onto your computer you are presented with the option to 'Configure the MySQL Server now'. Make sure this option is checked and click 'Finish' to end the installation and begin configuring MySQL.

You will be presented with an option to choose a 'configuration type' for customizing your MySQL installation. Choose 'Detailed Configuration'.

You will now be asked to choose a 'server type'. Here you are presented with three options. Since I will not be using MySQL a great deal as it will only be used to serve a single website I will choose the 'Developer Machine' option. If you plan on hosting a few websites that require a MySQL database and you expect fairly heavy traffic then I would recommend the 'Server Machine' option. Since my computer's priority is not to serve multiple websites the 'Developer Machine' option is fine for me and this will use less of the computer's memory.

Next you will be asked to pick the 'database usage'. Select 'Non-Transactional Database Only'.

Next you will be asked to gauge the 'number of concurrent connections to the server'. Since I do not expect a high number of users using the database at anyone one time I will select the 'Decision Support (DSS)/OLAP' option. This allows for 20 concurrent connections to the MySQL database.

Now you will be asked to specify networking options for the MySQL database. The defaults are fine.

The following screen requires you to choose a 'default character set'. I chose the default 'Standard Character Set' since this is fine for English Languages.

You are now asked to set any windows options. I used the default option of installing MySQL as a 'Windows Service' and made sure it was set to run MySQL automatically.

The final part of this installation involves setting the security options for MySQL. I cannot stress how important it is to set a complex password on your MySQL database, especially if you computer is not protected by a firewall and is directly connected to the internet. So, make sure the 'Modify Security Settings' check box is enabled and enter a password for the default database admin user called 'root'. Make this password as complex as you can.

Next click 'Execute' to begin configuration of your database.

The wizard will configure the database for you and show blue ticks next to each part of the configuration after a successful setup.

Clicking the 'Finish' button closes the configuration wizard and completes the installation of MySQL. Should any of your requirements change and you need to reconfigure MySQL, there are two ways of modifying your configuration. The first is to manually edit the config file that contains all of the MySQL settings. It can be located at 'C:\Program Files\MySQL\MySQL Server 5.0\my.ini', the second is to browse the start menu on your computer until you find the MySQL sub menu. You can run the configuration wizard by clicking 'MySQL Server Instance Config Wizard' shortcut from within the MySQL sub menu.

I would like to say that I would have preferred to have installed apache on my server. I opted for IIS simply because I use OWA. Whilst both web servers have their pros and cons, I would have preferred apache for its mod_rewrite module. I know there are commercial ISAPI modules available (and a couple of freebies with limitations) but when weighing up the cost of losing webmail IIS was the route I decided upon.

Download the PHP installer from HERE

Now run the installer and install to the recommended directory of C:\Program Files\PHP\

When prompted for the type of Web Server you wish to setup select IIS ISAPI module

On the next screen, from the list of extensions available, select the following to be installed on the local hard drive: GD2, MCrypt, Multi-Byte String, MySQL, and MySQLi. I chose these extensions because I use a MySQL database and phpMyAdmin to manage the database.

N.B. If you find you need additional extensions later on, you can run the installer again and select the extensions to be installed from the list available.

After the setup has finished restart IIS by opening the IIS snap-in, selecting the computer icon (with the name of the computer you have IIS installed on), right clicking, selecting all tasks and choosing restart IIS

When prompted with 'What do you want IIS to do?' select the option to 'Restart Internet Services on computername' and click ok

Now, still within the IIS snap-in, browse the 'Web Sites' folder and right click the 'Default Web Site' to select properties. Select the tab named 'Documents' and add index.php to the list of default content pages. You may want to change the order in which IIS displays index pages, I moved index.php to the top of the list.

Now select the tab named 'Home Directory' and click on the 'configuration' button. Scroll down to .php in the Application Extensions window, click it to select the .php extension and click the 'edit' button. Now change the Executable path from "C:\PROGRA~1\PHP\PHP5IS~1.DLL" to "C:\Program Files\PHP\php5isapi.dll" (with quotes).

N.B. If you create any virtual websites (other than using 'Default Web Site') you will have to perform this step on them as well.

Now I made a couple of changes to the 'php.ini' file. Edit C:\Program Files\PHP\php.ini and change display_errors = Off and log_errors = On to display_errors = On and log_errors = Off. Also change both upload_tmp_dir and session.save_path paths to "C:\WINDOWS\Temp". The default paths for both of these settings is a directory that doesn't exist, hence the need to change it.

Now restart IIS again like you did earlier.

Now in the document root folder for IIS, (for me this was 'C:\Inetpub\wwwroot') create a new file called index.php using notepad or your favourite text editor. In it save the following text:

Now open your browser and browse the local computer by typing http://localhost or http://127.0.0.1 into the web address bar of your browser. you should be presented with a screen similar to the following, displaying the configuration of your PHP setup.

(click to enlarge)

If you see that page then your PHP installation for IIS has been a success!