Back at the MVP Summit 2012 in Redmond, Microsoft announced to the Exchange MVP community that in Exchange 2013 they are going to pull the Microsoft Exchange Virus Scanning API (VSAPI) from the product. This API is what allows anti-virus products to scan inside the information store for emails. This early news came to me with a big smile on my face!
For years I have been advising customers NOT to install anti-virus products which scan the information store as it causes unnecessary load on the information store and has caused database corruption at some of my customers. Despite my advice, some of my clients go ahead and installed this functionality anyway to meet a "compliance" checkbox which some integrator has flagged in a security audit.
I have always advised customers to perform anti-virus scanning at a transport level (SMTP) and flag emails before they reach the database to improve performance and allow for greater scalability. It is important to note however, Anti-Virus products are always releasing new definitions and it is possible that a virus was allowed in due to the definitions not being able to detect it initially but being able to detect it at a later date. Hence, this still proposes a risk to the business and can be caught using third party Anti-Virus products which use the Microsoft Exchange Virus Scanning API (VSAPI) right? Well yes this is true, however I still do not recommend this. A better solution is to run cached Exchange mode and allow client side Anti-Virus products to scan the users offline cache "OST file" for viruses on a regular basis and offset this load from your already busy mail servers. This approach meets the same objective and does not require use of the Microsoft Exchange Virus Scanning API.
One of my customers who went against my advise and refused to disable Information Store scanning due to compliance requirements on Exchange 2010 now has no option but to remove it. Microsoft Support must have finally had enough of dealing with issues from third party Anti-Virus products causing information store issues just like me!
Have a look at the following screenshot comparing a product GFI MailEssentials 2014 SR2 which has the ability to scan the information store on a Exchange 2010 server compared to an Exchange 2013 server. Under the Email Security menu on the Exchange 2013 server (on the right), you will se the feature gone for good... not just in GFI but all anti-virus products.
A big thankyou to Microsoft for removing this API - this is one less argument I need to have with my customers!
Lastly, I still always recommend companies AppLock with Microsot AppLocker in Enterprise edition of Windows and do away with definition scanning Anti-Virus solutions, they are a thing of the past. This is another argument I'm still having with the security compliance guys stuck in the dark ages, but we will save this for another blog post.
For years I have been advising customers NOT to install anti-virus products which scan the information store as it causes unnecessary load on the information store and has caused database corruption at some of my customers. Despite my advice, some of my clients go ahead and installed this functionality anyway to meet a "compliance" checkbox which some integrator has flagged in a security audit.
I have always advised customers to perform anti-virus scanning at a transport level (SMTP) and flag emails before they reach the database to improve performance and allow for greater scalability. It is important to note however, Anti-Virus products are always releasing new definitions and it is possible that a virus was allowed in due to the definitions not being able to detect it initially but being able to detect it at a later date. Hence, this still proposes a risk to the business and can be caught using third party Anti-Virus products which use the Microsoft Exchange Virus Scanning API (VSAPI) right? Well yes this is true, however I still do not recommend this. A better solution is to run cached Exchange mode and allow client side Anti-Virus products to scan the users offline cache "OST file" for viruses on a regular basis and offset this load from your already busy mail servers. This approach meets the same objective and does not require use of the Microsoft Exchange Virus Scanning API.
One of my customers who went against my advise and refused to disable Information Store scanning due to compliance requirements on Exchange 2010 now has no option but to remove it. Microsoft Support must have finally had enough of dealing with issues from third party Anti-Virus products causing information store issues just like me!
Have a look at the following screenshot comparing a product GFI MailEssentials 2014 SR2 which has the ability to scan the information store on a Exchange 2010 server compared to an Exchange 2013 server. Under the Email Security menu on the Exchange 2013 server (on the right), you will se the feature gone for good... not just in GFI but all anti-virus products.
A big thankyou to Microsoft for removing this API - this is one less argument I need to have with my customers!
Lastly, I still always recommend companies AppLock with Microsot AppLocker in Enterprise edition of Windows and do away with definition scanning Anti-Virus solutions, they are a thing of the past. This is another argument I'm still having with the security compliance guys stuck in the dark ages, but we will save this for another blog post.
This is dummy text. It is not meant to be read. Accordingly, it is difficult to figure out when to end it. But then, this is dummy text. It is not meant to be read. Period.
ConversionConversion EmoticonEmoticon