VNX: CAVA error VC: 3: 32: Server 'x.x.x.x' retourneerde fout 'FAIL' bij het controleren van het bestand

Terwijl de viruscontrole wordt uitgevoerd, verschijnt er in de logboeken een foutmelding die aangeeft dat de VC-service deze niet heeft gecontroleerd:

2016-03-29 11:38:44: VC: 3: 32: Server 'x.x.x.x' retourneerde fout 'FAIL' bij het controleren van bestand '\root_vdm_id\mount_path\bestandsnaam.ext'

Het 'FAIL'-bericht treedt op wanneer een scanaanvraag wordt geopend (de VC-service op de datamover stuurt een aanvraag naar de CAVA-servers) en wanneer de CAVA-server deze probeert te openen, wordt het bestand niet gevonden.  Dit betekent dat het bestand is verwijderd voordat het kon worden gescand.  Er zijn enkele scenario's waarin dit kan gebeuren:

• Een manier waarop dit gebeurt, is als het bestand een cookie, tijdelijk bestand of vergrendelingsbestand was.  Microsoft Office maakt bijvoorbeeld tijdelijke bestanden met de indeling ~$<original_filename.xxxx>.  Deze bestanden verdwijnen normaal gesproken wanneer het bestand wordt opgeslagen of gesloten, en als dit snel gebeurt, kan het bestand verdwijnen voordat het de kans krijgt om te worden gescand, wat leidt tot het FAIL-bericht in het logboek van de dataverplaatser.  De bestandsnamen die scans mislukken, identificeren dit meestal als de oorzaak van het probleem.
• Een andere manier waarop dit kan gebeuren, is als het bestand een speciale 'dispositie' heeft.  In SMB en SMB2 kan de gebruiker bij het openen van een bestand een dispositie 'delete on close' instellen.  Als het bestand waarnaar wordt verwezen voor scannen wordt geopend door een andere gebruiker met deze dispositie, wordt het bestand verwijderd voordat het kan worden gescand, wat leidt tot het bericht FAIL in de logboeken van de dataverplaatser.  Deze optie is te zien in pakkettraceringen door te kijken naar SMB 'Create'- of 'SetInfo'-aanroepen, maar wordt ingesteld door de gebruiker die het verwijderen uitvoert, en waarschijnlijk niet door de CAVA-servers.  Dit kan de zaken moeilijk maken omdat normaal verkeer moet worden gecontroleerd (niet alleen de AV-server) om te bepalen wie de vlag instelt.

De beste oplossing is om te stoppen met het verwijderen van het bestand (de externe gebruikers die het bestand verwijderen).  Dit kan betekenen dat het gebruik van tijdelijke bestanden op kantoor moet worden uitgeschakeld of dat andere tijdelijke bestanden of cookies moeten worden opgeslagen in een lokale map in plaats van in een gedeelde.  Als dit niet mogelijk is, wijzig dan viruschecker.conf om dit soort bestanden uit te sluiten van controle door de regel 'excl' te wijzigen om ~$* uit te sluiten.* (voor Office-bestanden), *.tmp of een andere extensie die deze fouten kan veroorzaken.

viruschecker.conf:
CIFSserver=<CIFS server op data mover>
addr=<geconfigureerde CAVA servers>
excl=~$*.*:*.accdb:*.laccdb:*.ldb:*.mdb:*.pst:*.tmp:????????
masks=*.*
shutdown=viruschecking

aanvullende bronnen:
https://support.microsoft.com/en-us/kb/211632 (Beschrijving van hoe Word tijdelijke bestanden maakt)
https://wiki.wireshark.org/SMB2/SMB2_FILE_DISPOSITION_INFO functie (SMB2_FILE_DISPOSITION_INFO lost op 'verwijderen bij sluiten')