Configuring Exchange On-Premises to Use Azure Rights Management

Posted on 7 CommentsPosted in 2010, 2013, 64 bit, aadrm, ADFS, ADFS 2.0, DLP, DNS, exchange, exchange online, https, hybrid, IAmMEC, load balancer, loadbalancer, mcm, mcsm, MVP, Office 365, powershell, rms, sharepoint, warm

This article is the fifth in a series of posts looking at Microsoft’s new Rights Management product set. In an earlier previous post we looked at turning on the feature in Office 365 and in this post we will look at enabling on-premises Exchange Servers to use this cloud based RMS server. This means your cloud users and your on-premises users can shared encrypted content and as it is cloud based, you can send encrypted content to anyone even if you are not using an Office 365 mailbox.

In this series of articles we will look at the following:

The items above will get lit up as the articles are released – so check back or leave a comment to the first post in the series and I will let you know when new content is added.

Exchange Server integrates very nicely with on-premises RMS servers. To integrate Exchange on-premises with Windows Azure Rights Management you need to install a small service online that can connect Exchange on-premises to the cloud RMS service. On-premises file servers (classification) and SharePoint can also use this service to integrate themselves with cloud RMS.

You install this small service on-premises on servers that run Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2. After you install and configure the connector, it acts as a communications interface between the on-premises IRM-enabled servers and the cloud service. The service can be downloaded from

From this download link there are three files to get onto the server you are going to use for the connector.

  • RMSConnectorSetup.exe (the connector server software)
  • GenConnectorConfig.ps1 (this automates the configuration of registry settings on your Exchange and SharePoint servers)
  • RMSConnectorAdminToolSetup_x86.exe (needed if you want to configure the connector from a 32bit client)

Once you have all this software (or that which you need) and you install it then IT and users can easily protect documents and pictures both inside your organization and outside, without having to install additional infrastructure or establish trust relationships with other organizations.

The overview of the structure of the link between on-premises and Windows Azure Rights Management is as follows:


Notice therefore that there are some prerequisites needed. You need to have an Office 365 tenant and turn on Windows Azure Rights Management. Once you have this done you need the following:

  • Get your Office 365 tenant up and running
  • Configure Directory Synchronization between on-premises Active Directory and Windows Azure Active Directory (the Office 365 DirSync tool)
  • It is also recommended (but not required) to enable ADFS for Office 365 to avoid having to login to Windows Azure Rights Management when creating or opening protected content.
  • Install the connector
  • Prepare credentials for configuring the software.
  • Authorising the server for connecting to the service
  • Configuring load balancing to make this a highly available service
  • Configuring Exchange Server on-premises to use the connector

Installing the Connector Service

  1. You need to set up an RMS administrator. This administrator is either the a specific user object in Office 365 or all the members of a security group in Office 365.
    1. To do this start PowerShell and connect to the cloud RMS service by typing Import-Module aadrm and then Connect-AadrmService.
    2. Enter your Office 365 global administrator username and password
    3. Run Add-AadrmRoleBasedAdministrator -EmailAddress <email address> -Role “GlobalAdministrator” or Add-AadrmRoleBasedAdministrator -SecurityGroupDisplayName <group Name> -Role “ConnectorAdministrator”. If the administrator object does not have an email address then you can lookup the ObjectID in Get-MSOLUser and use that instead of the email address.
  2. Create a namespace for the connector on any DNS namespace that you own. This namespace needs to be reachable from your on-premises servers, so it could be your .local etc. AD domain namespace. For example rmsconnector.contoso.local and an IP address of the connector server or load balancer VIP that you will use for the connector.
  3. Run RMSConnectorSetup.exe on the server you wish to have as the service endpoint on premises. If you are going to make a highly available solutions, then this software needs installing on multiple machines and can be installed in parallel. Install a single RMS connector (potentially consisting of multiple servers for high availability) per Windows Azure RMS tenant. Unlike Active Directory RMS, you do not have to install an RMS connector in each forest. Select to install the software on this computer:
  4. Read and accept the licence agreement!
  5. Enter your RMS administrator credentials as configured in the first step.
  6. Click Next to prepare the cloud for the installation of the connector.
  7. Once the cloud is ready, click Install. During the RMS installation process, all prerequisite software is validated and installed, Internet Information Services (IIS) is installed if not already present, and the connector software is installed and configured
  8. If this is the last server that you are installing the connector service on (or the first if you are not building a highly available solution) then select Launch connector administrator console to authorize servers. If you are planning on installing more servers, do them now rather than authorising servers:
  9. To validate the connector quickly, connect to http://<connectoraddress>/_wmcs/certification/servercertification.asmx, replacing <connectoraddress> with the server address or name that has the RMS connector installed. A successful connection displays a ServerCertificationWebService page.
  10. For and Exchange Server organization or SharePoint farm it is recommended to create a security group (one for each) that contains the security objects that Exchange or SharePoint is. This way the servers all get the rights needed for RMS with the minimal of administration interaction. Adding servers individually rather than to the group results in the same outcome, it just requires you to do more work. It is important that you authorize the correct object. For a server to use the connector, the account that runs the on-premises service (for example, Exchange or SharePoint) must be selected for authorization. For example, if the service is running as a configured service account, add the name of that service account to the list. If the service is running as Local System, add the name of the computer object (for example, SERVERNAME$).
    1. For servers that run Exchange: You must specify a security group and you can use the default group (DOMAIN\Exchange Servers) that Exchange automatically creates and maintains of all Exchange servers in the forest.
    2. For SharePoint you can use the SERVERNAME$ object, but the recommendation configuration is to run SharePoint by using a manually configured service account. For the steps for this see
    3. For file servers that use File Classification Infrastructure, the associated services run as the Local System account, so you must authorize the computer account for the file servers (for example, SERVERNAME$) or a group that contains those computer accounts.
  11. Add all the required groups (or servers) to the authorization dialog and then click close. For Exchange Servers, they will get SuperUser rights to RMS (to decrypt content):
  12. If you are using a load balancer, then add all the IP addresses of the connector servers to the load balancer under a new virtual IP and publish it for TCP port 80 (and 443 if you want to configure it to use certificates) and equally distribute the data across all the servers. No affinity is required. Add a health check for the success of a HTTP or HTTPS connection to http://<connectoraddress>/_wmcs/certification/servercertification.asmx so that the load balancer fails over correctly in the event of connector server failure.
  13. To use SSL (HTTPS) to connect to the connector server, on each server that runs the RMS connector, install a server authentication certificate that contains the name that you will use for the connector. For example, if your RMS connector name that you defined in DNS is, deploy a server authentication certificate that contains in the certificate subject as the common name. Or, specify in the certificate alternative name as the DNS value. The certificate does not have to include the name of the server. Then in IIS, bind this certificate to the Default Web Site.
  14. Note that any certificate chains or CRL’s for the certificates in use must be reachable.
  15. If you use proxy servers to reach the internet then see for steps on configuring the connector servers to reach the Windows Azure Rights Management cloud via a proxy server.
  16. Finally you need to configure the Exchange or SharePoint servers on premises to use Windows Azure Active Directory via the newly installed connector.
    • To do this you can either download and run GenConnectorConfig.ps1 on the server you want to configure or use the same tool to generate Group Policy script or a registry key script that can be used to deploy across multiple servers.
    • Just run the tool and at the prompt enter the URL that you have configured in DNS for the connector followed by the parameter to make the local registry settings or the registry files or the GPO import file. Enter either http:// or https:// in front of the URL depending upon whether or not SSL is in use of the connectors IIS website.
    • For example .\GenConnectorConfig.ps1 –ConnectorUri -SetExchange2013 will configure a local Exchange 2013 server
  17. If you have lots of servers to configure then run the script with –CreateRegEditFiles or –CreateGPOScript along with –ConnectorUri. This will make five reg files (for Exchange 2010 or 2013, SharePoint 2010 or 2013 and the File Classification service). For the GPO option it will make one GPO import script.
  18. Note that the connector can only be used by Exchange Server 2010 SP3 RU2 or later or Exchange 2013 CU3 or later. The OS on the server also needs to be include a version of the RMS client that supports RMS Cryptographic Mode 2. This is Windows Server 2008 + KB2627272 or Windows Server 2008 R2 + KB2627273 or Windows Server 2012 or Windows Server 2012 R2.
  19. For Exchange Server you need to manually enable IRM as you would do if you had an on-premises RMS server. This is covered in but in brief you run Set-IRMConfiguration -InternalLicensingEnabled $true. The rest, such as transport rules and OWA and search configuration is covered in the mentioned TechNet article.
  20. Finally you can test if RMS is working with Test-IRMConfiguration –Sender You should get a message at the end of the test saying Pass.
  21. If you have downloaded GenConnectorConfig.ps1 before May 1st 2014 then download it again, as the version before this date writes the registry keys incorrectly and you get errors such as “FAIL: Failed to verify RMS version. IRM features require AD RMS on Windows Server 2008 SP2 with the hotfixes specified in Knowledge Base article 973247” and “Microsoft.Exchange.Security.RightsManagement.RightsManagementException: Failed to get Server Info from —> System.Net.WebException: The request failed with HTTP status 401: Unauthorized.”. If you get these then turn of IRM, delete the “C:\ProgramData\Microsoft\DRM\Server” folder to remove old licences, delete the registry keys and run the latest version of GetConnectorConfig.ps1, refresh the RMS keys with Set-IRMConfiguration –RefreshServerCertificates and reset IIS with IISRESET.

Now you can encrypt messages on-premises using your AADRM licence and so not require RMS Server deployed locally.

Updating Exchange 2013 Anti-Malware Agent From A Non-Internet Connected Server

Posted on Leave a commentPosted in 2013, 64 bit, antivirus, exchange, Exchange Online Protection, IAmMEC, malware, mcm, mcsm, powershell, x64

In Forefront Protection for Exchange (now discontinued) for Exchange 2010 it was possible to run the script at to download the signatures and scan engines when the server did not have a direct connection to the download site at

To achieve the same with Exchange 2013 and the built-in anti-malware transport agent you can repurpose the 2010 script to download the engine updates to a folder on a machine with internet access and then use a script from Exchange Server 2013 to download from a share on the first machine that you downloaded the files to, and that the Exchange Servers can reach.

So start by downloading the script at and saving it as Update-Engines.ps1.

Create a folder called C:\Engines (for example) and share it with Authenticated Users / Read access and full control to the account that will run Update-Engines.ps1

Run Update-Engines.ps1 with the following

Update-Engines.ps1 -EngineDirPath C:\engines -UpdatePathUrl  -Engines “Microsoft” -Platforms amd64

The above cmdlet/script downloads just the 64 bit Microsoft engine as that is all you need and places them in the local folder (which is the shared folder you created) on that machine. You can schedule this script using standard published techniques for scheduling PowerShell.

On your Exchange Server that has no internet connectivity, start Exchange Management Shell and run the following:

Set-MalwareFilteringServer ServerName –PrimaryUpdatePath \\dlserver\enginesShare

Then start a PowerShell window that is running as an administrator – you can use Exchange Management Shell, but it too needs to be started as an administrator to do this last step. In this shell run the following:





Then compare the first results from Get-EngineUpdateInformation with the second results. If you have waited 30 or so seconds, the second set of results should be updated to the current time for the LastChecked value. UpdateVersion and UpdateStatus might also have changed. If your Exchange Server has internet connectivity it will already have updated automatically every hour and so not need this script running.

Enabling Exchange 2013 to Filter OneNote and Publisher Files

Posted on 1 CommentPosted in 2013, 64 bit, exchange, IFilter, owa, transport

Exchange Server 2013 includes the Search Foundation product to index and search most of the file types that needed IFilters installed for in previous versions including PDF files, so the Adobe IFilter is no longer needed. That said, it does not filter OneNote and Microsoft Publisher files.

To filter these files so that you can search them as part of your mailbox search, include them in discovery and compliance searches and to write transport rules that can act on the contents of these files you need to install the Microsoft Office Filter Pack 2010 and Service Pack 1 for Microsoft Office Filter Pack 2010 (KB 2460041) 64-bit Edition and then, once installed, set a few registry keys. The following script does the registry key steps for you, and needs running on all your Exchange 2013 Mailbox Servers. See for steps to install the PDF filter on Exchange 2010 if you need to do that. This script is based on the work in that post and the original scripts from Microsoft to configure the IFilters in Exchange 2010 RTM.

Script for Install-IFilters.ps1

Download the Install-IFilters.ps1 here (which is a zip containing some test files as well – see below for testing steps. The PowerShell script is also shown below:

   1: # Script to enable indexing of OneNote and Microsoft Publisher filtering in Exchange 2013

   2: # Written by Brian Reid, C7 Solutions Ltd. 14:27 21/11/2012

   3: # Based on a script by Mark Smith from Capex Global that installed PDF filtering for Exch2010

   4: # Note PDF filtering is included in Exchange 2013 and not needed as an extra install


   6: # The Microsoft Office 2010 Filter Pack needs installing before running this script:

   7: # The Microsoft Office 2010 Filter Pack SP1 (x64) needs installing before running this script:

   8: # This script has not been tested with the Microsoft Office Filter Pack 2013 release as it was not available at time of writing


  10: # This script will restart the Transport service and Microsoft Filtering Management Service. Mail-flow might be affected

  11: # by the first of these restarts. Existing items in the store will not be indexed


  13: $iFilterDirName = "C:\Program Files\Common Files\Microsoft Shared\Filters\"


  15: $KeyParent = "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\HubTransportRole"

  16: $CLSIDKey = "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\HubTransportRole\CLSID"

  17: $FiltersKey = "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\HubTransportRole\filters"


  19: # Filter DLL Locations

  20: $ONEFilterLocation = $iFilterDirName + "\ONIFilter.dll"

  21: $PUBFilterLocation = $iFilterDirName + "\PUBFILT.dll"


  23: # Filter GUIDs

  24: $ONEGuid    ="{B8D12492-CE0F-40AD-83EA-099A03D493F1}"

  25: $PUBGuid    ="{A7FD8AC9-7ABF-46FC-B70B-6A5E5EC9859A}"



  28: # Create CLSID and filters root registry keys if they do not exist

  29: Write-Host -foregroundcolor Green "Creating parent registry keys"


  31: New-Item -Path $KeyParent -Name CLSID -ErrorAction SilentlyContinue | Out-Null

  32: New-Item -Path $KeyParent -Name filters -ErrorAction SilentlyContinue | Out-Null



  35: # Create CLSIDs

  36: Write-Host -foregroundcolor Green "Creating CLSIDs..."


  38: New-Item -Path $CLSIDKey -Name $ONEGuid -Value $ONEFilterLocation -Type String | Out-Null

  39: New-Item -Path $CLSIDKey -Name $PUBGuid -Value $PUBFilterLocation -Type String | Out-Null


  41: # Set Threading model

  42: Write-Host -foregroundcolor Green "Setting threading model..."


  44: New-ItemProperty -Path "$CLSIDKey\$ONEGuid" -Name "ThreadingModel" -Value "Both" -Type String | Out-Null

  45: New-ItemProperty -Path "$CLSIDKey\$PUBGuid" -Name "ThreadingModel" -Value "Both" -Type String | Out-Null


  47: # Set Flags

  48: Write-Host -foregroundcolor Green "Setting Flags..."

  49: New-ItemProperty -Path "$CLSIDKey\$ONEGuid" -Name "Flags" -Value "1" -Type Dword | Out-Null

  50: New-ItemProperty -Path "$CLSIDKey\$PUBGuid" -Name "Flags" -Value "1" -Type Dword | Out-Null


  52: # Create Filter Entries

  53: Write-Host -foregroundcolor Green "Creating Filter Entries..."


  55: New-Item -Path $FiltersKey -Name ".one" -Value $ONEGuid -Type String | Out-Null

  56: New-Item -Path $FiltersKey -Name ".pub" -Value $PUBGuid -Type String | Out-Null


  58: # Setting permissions

  59: Write-Host -foregroundcolor Green "Granting NETWORK SERVICE read access to $KeyParent and child keys "

  60: $acl = Get-Acl $KeyParent

  61: $rule = New-Object System.Security.AccessControl.RegistryAccessRule ("NETWORK SERVICE","ReadKey","Allow")

  62: $acl.SetAccessRule($rule)

  63: $acl | Set-Acl -Path $KeyParent


  65: # Restarting required services

  66: Write-Host -foregroundcolor Green "Stopping Microsoft Exchange Transport service (this takes a few minutes)"

  67: Stop-Service "Microsoft Exchange Transport" | Out-Null

  68: Write-Host -foregroundcolor Green "Stopping Microsoft Filtering Management Service"

  69: Stop-Service "Microsoft Filtering Management Service" | Out-Null

  70: Write-Host -foregroundcolor Green "Starting Microsoft Exchange Transport service (this takes a few minutes)"

  71: Start-Service "Microsoft Exchange Transport" | Out-Null

  72: Write-Host -foregroundcolor Green "Starting Microsoft Filtering Management Service"

  73: Start-Service "Microsoft Filtering Management Service" | Out-Null

Testing Attachment Filtering

The download above contains the script and some test files for different document types. To test just create a transport rule where:

    • The sender is your mailbox.
  • Any attachment’s content includes “Testing IFilters”. (the files in the download include these words)


  • Generate an incident report and send it to your mailbox. Incident Reports are advanced transport rule actions.


If you create this rule before you run the script then you will get incident reports for the TXT file, DOCX file and the PDF file (note, you did not need to install the Adobe IFilter to get this functionality). But sending the ONE file and the PUB file before running the above script, even though you have the Microsoft Filter Pack installed, will not generate an incident report.

Once you have run the script, email yourself the ONE and PUB files and both should generate an incident report. From now on trasnport rules will process OneNote and Microsoft Publisher documents correctly, including any that match any Data Loss Prevention rules that you have enabled.

Access Is Denied Message After Sysprep–How To Fix

Posted on 1 CommentPosted in 2003, 2007, 2008, 2008 R2, 2012, 64 bit, backup, bios, hyper-v, password, recovery, sysprep, windows, windows 2003, windows 2008, windows 7, windows server, workstation, x64, x86

If before you use Sysprep to prepare a Windows machine for imaging you set the administrators password “User cannot change password” then sysprep will not clear this setting, but will set the “User must change password at next logon” setting. Normally these two settings are mutually exclusive, but in the scenario for sysprep it seems they can both end up being set.

This means you get prompted to reset you password at first logon after sysprep completes and then find you have “Access Denied” as the response. There is seemingly no way around this Catch-22.

That is unless you use the Offline NT Password and Registry Editor. This tool allows password resets when booting the server from a CD or USB key (so physical access to the server is required). As the download for this is an iso file, it can also be used in virtual environments by configuring your virtual machine to boot from the iso you have downloaded.

To allow you to logon to your machine following the above issue, all you need to in the Offline NT Password tool is to blank out the administrators password and unlock the account. These are options 1 and 4 during the password reset stage. Full instructions with screenshots follow:

  1. Boot the server with the issue with the Offline NT Password and Registry Editor iso file:
  2. Choose the correct boot option (or just press Enter for the defaults):
  3. For Vista and earlier select the default of Option 1. For Windows 7 and Windows 2008 and later select Option 2 (to boot into the second partition on the disk). You might need to select a different option if you have more partitions. You need to select the partition that Windows is installed on.
  4. If the disk is marked as Read-Only ensure that the server went through a clean boot and was not shutdown incorrectly. Once the messages indicate a writable partition
  5. Select the presented folder (by pressing Enter again). You can typically just press Enter through most of these stages. You will be asked what you want to do – we want to reset passwords:
  6. Select Option 1 to Edit user data and passwords:
  7. Press Enter to choose the Administrator account:
  8. Type 1 to Clear (blank) user password. You should get back the message “Password cleared!”:
  9. Press Enter again to reselect the Administrator account, and this time select Option 4 to unlock the account (even though this program tells you the account is already unlocked):
  10. Once you see “Unlocked!” you can quit from this program. The process to quit requires you to save your changes. Note that the default setting is not to save changes, so you cannot now use Enter to select the default option.
  11. Enter ! to quit from the password reset program:
  12. Enter q to quit from the script and to ask about saving changes:
  13. Enter y to write back the files that have been changed:
  14. You should have been told “***** EDIT COMPLETE *****”. Press Enter to finish the program scripts:
  15. At this final screen you can remove the CD or unmount the iso image from your virtual machine and press CTRL+ALT+DEL to restart the server. The server should now boot into Windows and auto-logon as it has a blank password.
  16. Change the password and optionally untick the “User cannot change password” setting.

How to Speed Up Hub Transport Server Selection

Posted on Leave a commentPosted in 2010, 64 bit, exchange

Install Exchange 2010 SP1!

Installing the service pack fixes the round-robin selection process for remote hub transport servers in other sites (see Hub Transport Load Balancing) so that only the IP addresses of operational servers are used.

Exchange 2010 runs on Windows 2008 (or 2008 R2) and this operating system supports IPv4 and IPv6. In fact it will provide an IPv6 address even if you don’t have an IPv6 router or infrastructure. But if a remote hub registers an IPv6 address in DNS then you might attempt to use the IPv6 address before any IPv4 address and fail to connect. Exchange 2010 SP1 will now remove the IPv6 address from the round-robin hub selection list, and so speed up transport in Exchange.

Publishing ADFS Through ISA or TMG Server

Posted on 2 CommentsPosted in 2010, 2013, 64 bit, active directory, ADFS, ADFS 2.0, certificates, exchange, exchange online, https, isa, mcm, microsoft, Office 365, pki, tmg

To enable single sign-on in Office 365 and a variety of other applications you need to provide a federated authentication system. Microsoft’s free server software for this is currently Active Directory Federation Server 2.0 (ADFS), which is downloaded from Microsoft’s website.

ADFS is installed on a server within your organisation, and a trust (utilising trusted digital certificates) is set up with your partners. If you want to authenticate to the partner system from within your environment it is usual that your application connects to your AFDS server (as part of a bigger process that is better described here: But if you are outside of your organisation, or the connection to ADFS is made by the partner rather than the application (and in Office 365 both of these take place) then you either need to install ADFS Proxy or publish the ADFS server through a firewall.

This subject of the blog is how to do this via ISA Server or TMG Server. In addition to configuring a standard HTTPS publishing rule you need to disable Link Translation and high-bit filtering on the HTTP filter to get it to work.

Here are the full steps to set up AFDS inside your organisation and have it published via ISA Server – TMG Server is to all intents and purposes the same, the UI just looks slightly different:

  1. New Web Site Publishing Rule. Provide a name.
  2. Select the Action (allow).
  3. Choose either a single website or load balancer or use ISA’s load balancing feature depending on the number of ADFS servers in your farm.
  4. Use SSL to connect:
  5. Enter the Internal site name (which must be on the SSL certificate on the ADFS server and must be the same as the externally published name as well). Also enter the IP address of the server or configure the HOSTS files on the firewall to resolve this name as you do not want to loop back to the externally resolved name:
  6. Enter /adfs/* as the path.
  7. Enter the ADFS published endpoint as the Public name (which will be subject or SAN on the certificate and will be the same certificate on the ADFS server and the ISA Server):
  8. Select or create a suitable web listener. The properties of this will include listening on the external IP address that your ADFS namespace resolves to, over SSL only, using the certificate on your ADFS server (exported with private key and installed on ISA Server), no authentication.
  9. Allow the client to authenticate directly with the endpoint server:
  10. All Users and then click Finish.
  11. Before you save your changes though, you need to make the following two changes
  12. Right-click the rule and select Configure HTTP:
  13. Uncheck Block high bit characters and click OK.
  14. Double-click the rule to bring up its properties and change to the Link Translation tab. Uncheck Apply link translation to this rule:
  15. Click OK and save your changes.

ADFS should now work through ISA or TMG assuming you have configured ADFS and your partner organisations correctly!

To test your ADFS service connect to your ADFS published endpoint from outside of TMG and visit https://fqdn-for-adfs/adfs/ls/idpinitiatedsignon.aspx to get a login screen

Windows 2008, IIS 7.0, 64 bit Server, Terminal Services Web Application and Access Databases

Posted on Leave a commentPosted in 2008, 64 bit, access, iis, oledb, proxy, sql express, windows, x64

This is a long list of pre-requisites, but for your information they do not work together.

  1. If you have a web site that uses Access as its data storage and you migrate that site to an x64 Windows machine then access to the Access MDB file ceases with the following error: “‘Microsoft.Jet.OLEDB.4.0’ provider is not registered on the local machine”.
  2. On IIS 6.0 you need to set the entire web server to 32 bit mode, but on Windows 2008/IIS 7.0 you can set each application pool to 32 or 64 bit. This is a property found under Advanced Settings for the application pool. To gain access to Access MDB files the application pool needs to run in 32 bit mode.
  3. If you have TSWeb installed, then you also have installed the RPC/HTTP proxy component.
  4. If you have the RPC/HTTP proxy component installed any 32 bit application pool will fail upon starting – Error 5139 for Microsoft-Windows-WAS.

So to use Access databases in a legacy web application migrated to Windows 2008, 64 bit, with TSWeb also installed either uninstall TSWeb (and RPC/HTTP proxy), or use a different server, or rewrite the web application to use SQL Express. Supposedly this will be fixed in the first service pack for Windows 2008.

There – it only took 6 hours to work that one out!