In Forefront Protection for Exchange (now discontinued) for Exchange 2010 it was possible to run the script at http://support.microsoft.com/kb/2292741 to download the signatures and scan engines when the server did not have a direct connection to the download site at forefrontdl.microsoft.com.
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 http://support.microsoft.com/kb/2292741 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 http://forefrontdl.microsoft.com/server/scanengineUpdate/ -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.
Today I visited a client who had noticed that no log files had ever been removed after any backup within Exchange 2010 SP1. It was fortuitous that they had enough log disk space for about eight months of log generations. The disadvantage was that we were four months into this time period, so it was a ticking clock, and that the nightly incremental backups were taking longer and longer.
They were getting the following error in their backup datacentre:
Unable to communicate with the Microsoft Exchange Information Store service to coordinate log truncation for database ‘name’ due to an RPC communication failure. Error 3355379671 Extended Error: 0 and Event ID 2136 for the MSExchangeRepl service in the Application event log.
What the error does not clearly say is that the Microsoft Exchange Replication service (MSExchangeRepl) on the server in the DR site (a passive node in the DAG) needs to communicate via RPC to the Microsoft Exchange Information Store service on the server holding the active node of the database.
In the case of my client, the Exchange team is not the same people as the network team or indeed the firewall team, and these teams are in different countries. In the case of the network for this client, the Replication network for the DAG had been opened to allow RPC traffic, but the MAPI (Client) network had not.
When Exchange in the DR site needed to check which logs it could truncate (a process it performs every 15 minutes), it needs to talk to the Microsoft Exchange Information Store service on the server holding the active copy of the database, and name resolution was returning (as expected) the IP address of the server on the MAPI/Client network. This network blocked RPC between servers and so (as one of the many issues they now attribute to this problem) logs could not be truncated and Event ID 2136 was posted once per database on the passive node in the DR site. The two servers in the primary site could RPC each other, so this log is not repeated in the primary site.
To solve this log growth problem without waiting for a response from the firewall team, we added a record to the hosts file on the passive server to override DNS name resolution, and within 15 minutes 2TB of log files instantly disappeared on all servers. Name resolution was reverted to DNS and the firewall team contacted.
This is a long list of pre-requisites, but for your information they do not work together.
- 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”.
- 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.
- If you have TSWeb installed, then you also have installed the RPC/HTTP proxy component.
- 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!