Exchange Null Path Statement

Travelling to see different customers from one side of Canada to the other is always interesting.  This post is written whilst in Vancouver and is from a reported customer issue waaaaay out East.

The Exchange admins pointed out that they were consistently running into an issue when they applied an Exchange Cumulative Update (CU) to a server.  The 3rd party file system anti-virus client then started to run rampant and spawn multiple processes consuming all of the resources on the Exchange server.

Being the clever cookies that they are, the Exchange admins were able to determine what was causing the issue.  What they noted was that the Exchange CU install was adding a Null path statement in as an system environment variable.  We can easily see this in a couple of ways.

Opening up system properties, and clicking on Environment Variables shows the below.  Note the highlighted section and the space between the semi colons.

System Properties Showing Null Environment Variable

This is also visible using the cmd prompt.  Again note the space at the start of the path statement.

Cmd Prompt Showing Null Environment Variable

The above screen shots were taken from an Exchange 2013 CU20 server which was installed on Windows Server 2012 R2.

I also checked my additional Exchange 2010, 2013 and 2016 servers and only noted this issue on Exchange 2013 and 2016 servers.  Exchange 2010 installed onto Windows 2012 did not have a null path statement.  The below is from that Exchange 2010 system – note there is no null path statement and Exchange is installed into the V14 folder.

Exhcange 2010 - No Null Path Statement


To address the issue the customer was manually remediating the path variable by removing the null entry and restarting the server.  This must be checked and verified after each server install or CU update.

The issue is also meant to be corrected in an updated version of the anti-virus client, which is currently being evaluated and rolled out in their enterprise.




Comments (8)

  1. Brenkster says:

    I checked this on my servers and all of them had this. This is one example:
    H:\>set path
    Path=; ;C:\Program Files\avs\bin;C:\Program Files\avs\bin32; ; ;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;
    C:\windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files
    \Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files\Microsoft\Exc
    hange Server\V15\bin;C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Native\

    I’m not experiencing performance issues, what do you advise? Keep it running or remove the null entries?

    1. DukeTeft says:

      I just checked this on our servers as well and noticed it was creating the Null path statement. We are running EX13 on server 2012R2 and are not experiencing performance issues, but are curious as to if we should still proceed with correcting or leave it running as is?

  2. This only came up due to the issues observed in the 3rd party product.

    I’m checking to see if we are tracking this internally.


  3. Hello, I checked our server and we have it too:
    Exchange 2013, server 2012 R2
    ; ;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;D:\Exchange _Server_2013_V15\bin;D:\Exchange _Server_2013_V15\Bin\Search\Ceres\Native\

    No third party software installed. No anti-virus software ever installed on server. Should we remove it ? Thanks

  4. TheGhost82 says:

    So an issue in the CU is causing a problem in a 3rd party product and (according to the last line in the article) because of that the 3rd party product needs to be corrected?? I don’t get it!? I would say the issue needs to be corrected in Exchange?

    1. That’s not what is there – the section is entitled workaround.


Skip to main content