Mcafee/TIE: Definition 424 solves c:\Windows\assembly false/Positive detection


The problem with the c:\Windows\assembly\Nativeimages seemed to be solved by update 424. These are Framework

Files Executables which are compiled in real time first usage. We have only seen that as example on Exchange CAS Servers before.

They time the first user logs onto OWA after an MSP Patch has that delay once. We had up to 6'000 Files per W7 client before that patch new

During March 2016 Patchday.



Rule 139 - Identify trusted DOT Net assemblies




This rule detects files that have CLR code (DOT Net) and have been installed into the global

Assembly cache folders. The files are present on multiple machines within the enterprise,

Indicating they are not just-in-time compiled assemblies.


Default State: Mandatory


Changes in this release

Changed how age and prevalence are handled in DOT Net validation algorithm 



Also there is a heavy update for Ransomware detection.

Rule 240 - Identify suspicious files with characteristics that have been predominantly seen in





Identify suspicious files with characteristics that have been predominantly seen in

ransomware, are in uncommonly used locations and less than 7 days old


Default State: Evaluate

Post Patchday: Bitlocker Patch KB 3133977 W7, (ONLY FIPS MODE) + VM KB3137061

A few few intermin/post May 2016 Patches in WSUS from Microsoft

  • Bitlocker Patch W7/2008R2 WSUS, Post Intermin Patchday March 2016 (ONLY FIPS MODE)
  • VM SCSI Disk Patch from Microsoft

This article describes an issue in which BitLocker can't encrypt the drive and the service crashes in Windows 7 Service Pack 1 (SP1) or Windows Server 2008 R2 SP1. An update is available to fix this issue. Before you install this update, see the Prerequisites section.



This issue occurs after you install A FIPS-compliant recovery password cannot be saved to AD DS for BitLocker in Windows 7 or Windows Server 2008 R2 (2990184) and have the Federal Information Processing Standard (FIPS) mode enabled.

This article describes an issue in which Windows Azure virtual machines (VMs) don't recover from a network outage and data corruption occurs in Windows 8.1, Windows RT 8.1, Windows Server 2012 R2, Windows Server 2012, Windows 7 Service Pack 1 (SP1), or Windows Server 2008 R2 SP1. Before you install this update, see the Prerequisites section.


This issue occurs because the SCSI synchronize cache command fails, and the command result isn't checked when VMs handle the FLUSH request.

Note VMs disks should check the result of the synchronize cache command.



Mcafee Endpoint 10 / VSE 10 Preview points


Some points for upcoming Mcafee VSE 10. You can run TIE/GTI integration today with VSE8.8 and Framework 5.X.

Check out some related links:


Exchange Netvault/Netapp: Failed backup leftover Snapshots

  • Dell Netvault Backup Agent
  • SME for Exchange 6.1
  • Netapp Snapdrive

You have LEFTOVER SYMBOL Link on all drives or OLD NVBUShadowcopy Directory on LUNS you handle with Netvault Backup.

Solution 1a)

Stuck left over drives from failed backup in Netapp Plugin:

Solution 1b)

In cmd.exe


List shadows all

Search for corresponding leftover folder like "E:\NvbuShadowCopy_2052"

Get the SHADOW COPY ID of the stuck one

* Shadow copy ID = {e08f4105-1d42-4d53-afdd-838247c03529}

<No Alias>

- Shadow copy set: {e9f98574-49b1-4df1-bcb9-67d5c485764a}

<No Alias>

- Original count of shadow copies = 4

- Original volume name: \\?\Volume{b304d909-0cc1-11e4-b5ec-00505

68121c3}\ [E:\]

- Creation time: 30.11.2015 12:34:36

- Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeS


- Originating machine:

- Service machine:

- Exposed locally as: E:\NvbuShadowCopy_2052\

- Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5}

- Attributes: No_Auto_Release Persistent Differential


Delete it:

Delete shadows id {e08f4105-1d42-4d53-afdd-838247c03529}

Exchange 2010, 2008R2, Event 106 MSExchange Common

Problem: Exchange 2010, 2008R2, Event 106 MSExchange Common

Solution: Reload the correct performance counter file in Powershell

Event 106, MSExchange Common

Performance counter updating error. Counter name is Base for Average Number of Mailboxes Processed per Request, category name is MSExchange Availability Service. Optional code: 1. Exception: The exception thrown is : System.InvalidOperationException: The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly.

at System.Diagnostics.PerformanceCounter.Initialize()

at System.Diagnostics.PerformanceCounter.IncrementBy(Int64 value)

at Microsoft.Exchange.Diagnostics.ExPerformanceCounter.IncrementBy(Int64 incrementValue)

Last worker process info : System.UnauthorizedAccessException: Access to the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14\Transport' is denied.

at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)

at Microsoft.Win32.RegistryKey.CreateSubKey(String subkey, RegistryKeyPermissionCheck permissionCheck, RegistrySecurity registrySecurity)

at Microsoft.Exchange.Diagnostics.ExPerformanceCounter.GetLastWorkerProcessInfo()

Processes running while Performance counter failed to update:

2164 MSExchangeMailSubmission


Get the "D:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf" path

Open Exchange Powershell:

Add-pssnapin Microsoft.Exchange.Management.PowerShell.Setup

D:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\RpcClientAccessPerformanceCounters.ini



[PS] C:\ >Add-pssnapin Microsoft.Exchange.Management.PowerShell.Setup

[PS] C:\ >New-perfcounters -definitionfilename "D:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\RpcClientAccessPerformanceCounters.xml"

[PS] C:\ >


Event 1000, Source LOADPERF > OK

Performance counters for the MSExchange RpcClientAccess (MSExchange RpcClientAccess) service were loaded successfully. The Record Data in the data section contains the new index values assigned to this service.


If this does not fix try following (Correct the paths again)

Add-pssnapin Microsoft.Exchange.Management.PowerShell.Setup

new-perfcounters –definitionfilename "C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\AdminAuditPerfCounters.xml"
new-perfcounters –definitionfilename "C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\ResourceHealthPerformanceCounters.xml"
new-perfcounters –definitionfilename "C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\ThrottlingPerformanceCounters.xml"
new-perfcounters –definitionfilename "C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\MiddleTierStoragePerformanceCounters.xml"
new-perfcounters –definitionfilename "C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\IsMemberOfResolverPerfCounters.xml"
new-perfcounters –definitionfilename "C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\ADRecipientCachePerformanceCounters.xml"
new-perfcounters –definitionfilename "C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\RpcClientAccessPerformanceCounters.xml"
new-perfcounters –definitionfilename "C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\ExchangeTopologyPerformanceCounters.xml"
new-perfcounters –definitionfilename "C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\ExSearchPerformanceCounters.xml"
new-perfcounters –definitionfilename "C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\ExSearchCatalogPerformanceCounters.xml"


Your worst case scenario in terms of risk would be at the end if all does not solve it you have to re-index the Exchange Databases.

In would wait with that UNTIL you check all the Permissions/Counters and if they are registered correct!

Here is the official Linkl for the RE-INDEX (Last options if it currently fails all of the time)