Antivirus exclusion list for servers

Based on all of the resources linked on Microsoft Technet article, this is a complete list of AV exceptions that should be in place on servers running AD, DHCP, Hyper-V, SQL and Exchange. There are more exceptions listed in the article but these were the ones that applied to my server configurations at the time.

*.mdf
*.ldf
*.ndf
*.bak
*.trn
*.trc
*.sqlaudit
*.sql
%ProgramFiles%\Microsoft SQL Server\MSSQL.X\OLAP\Backup\*.*
%ProgramFiles%\Microsoft SQL Server\MSSQL.X\OLAP\Log\*.*
%ProgramFiles%\Microsoft SQL Server\MSSQL10_50.BACKUPEXEC\MSSQL\Binn\SQLServr.exe
%ProgramFiles%\Microsoft SQL Server\MSSQL10_50.BACKUPEXEC\Reporting Services\ReportServer\Bin\ReportingServicesService.exe
%ProgramFiles%\Microsoft SQL Server\MSSQL10_50.BACKUPEXEC\OLAP\Bin\MSMDSrv.exe
%windir%\SoftwareDistribution\Datastore\*.*
%windir%\SoftwareDistribution\Datastore\Logs\*.*
Edb*.jrs
Edb.chk
Tmp.edb
*.edb
*.sdb
*.log
*.chk
*.jrs
%allusersprofile%\NTUser.pol
%SystemRoot%\GroupPolicy\Machine\Registry.pol
%SystemRoot%\GroupPolicy\User\Registry.pol
%windir%\Ntds\*.*
%windir%\Ntfrs\*.*
%systemroot%\Sysvol\Staging areas\*.*
%systemroot%\Sysvol\Domain\*.*
%systemdrive%\System Volume Information\DFSR\*.*
%systemroot%\System32\DHCP\*.*
%systemroot%\System32\Dns\*.*
%allusersprofile%\Microsoft\Windows\Hyper-V\*.*
C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks\*.*
%systemroot%\System32\vmms.exe
%systemroot%\System32\vmwp.exe
%ExchangeInstallPath%\*.*
%SystemRoot%\System32\Inetsrv\*.*
%Winnt%\Cluster\*.*
%Windir%\Cluster\*.*
%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files\*.*
%SystemRoot%\System32\Inetsrv\*.*
C:\Inetpub\logs\logfiles\w3svc\*.*
Cdb.exe
Microsoft.Exchange.Search.Exsearch.exe
Cidaemon.exe
Microsoft.Exchange.Servicehost.exe
Clussvc.exe
MSExchangeADTopologyService.exe
Dsamain.exe
MSExchangeFDS.exe
Microsoft.Exchange.EdgeCredentialSvc.exe

SSL security and Microsoft Exchange

This year the SSL Certificate Authorities announced that they would no longer be allowing SSL certificates to be issued for private IP and internal domain names. In my company this meant that when our SSL certificate recently expired we could no longer renew it for the internal exchange server name (exchange.domain.local). This was all well and good for OWA and our external staff who used our external domain address in their email clients, but it caused Outlook to have a major hissy fit and complain that the SSL certificate wasn’t valid and kept popping up an annoying warning message.

So off I went to hunt down a solution to the problem. There were two main suggestions that permeated throughout the internet:

1. Map the internal server name to the matching external name by setting up new DNS zones on the domain controller.
2. Changing the Exchange server to user external DNS names.

Option number 1 didn’t work properly for me. It was probably a configuration fault on my part as others have reported success with that approach. However, it is kind of cumbersome as you have to create a new DNS zone for each external address (you’ll need at least two – server.domain.com and autodiscover.domain.com).

Option 2 however was far more successful. Using a guide provided online by Digicert I discovered that using the Exchange Management Shell on the server, there are three Exchange entries that you need to change with the following commands:

• Set-ClientAccessServer -Identity HostName -AutodiscoverServiceInternalUri https://mail.yourdomain.com/autodiscover/autodiscover.xml
• Set-WebServicesVirtualDirectory -Identity "HostName\EWS (Default Web Site)" -InternalUrl https://mail.yourdomain.com/ews/exchange.asmx
• Set-OABVirtualDirectory -Identity "HostName\oab (Default Web Site)" -InternalUrl https://mail.yourdomain.com/oab

Once you have run these commands in Exchange Management Shell on the server, you need to then open IIS Manager, expand Application Pools, right click on MSExchangeAutodiscoverAppPool and then choose the Recycle option.

Once you’ve done this Outlook will no longer complain about invalid SSL certificates.

Remote Desktop goes black after login

When trying to login remotely to a server today I discovered that on every attempt, when I was redirected from a successful login to the desktop, the screen would go black and be unresponsive. The server was running fine and the login worked fine from the console. After a bit of searching I discovered a thread on the Microsoft Technet forums discussing this very issue.

The solution to this problem was very simple but completely unexpected. By pressing CTRL + ALT + END I could trigger the Windows security screen (much like CTRL + ATL + DEL does on a local computer). Pressing cancel on this box then restored my desktop on the server.

Others have reported online having to take an extra step of disconnecting their RDP session and then reconnecting again in order to fully restore the desktop. Many thanks to Rob Kraft on the Technet forums for this deliciously simple solution.