SSL 3.0 enabled after an Exchange update – Fixed in 2013 CU13

If you have been vigilant, you disabled SSL 3.0 a long time ago on your servers. You may be surprised to find it enabled again after you apply an Exchange Update.

NOTE: This appears to be fixed in CU13 for Exchange 2013. You should still verify after applying any CU however!

From the CU13 setup log:

 

New-Item -path $keyPathRoot”\SSL 3.0″ -ItemType key -Name “Server” -Force;
}
Set-ItemProperty -path $keyPath -name “Enabled” -value 0x0 -Type DWORD -Force;

 

 

 

Now, back to the original issue:

A little history: SSL 3.0 has some well-documented security issues and with a reg tweak and reboot, it’s no longer advertised. You can easily test this with my favorite “sanity-check” site:

https://www.digicert.com/help/

Capture4

 

Enter the server name and click “Check for common vulnerabilities”.

Hopefully it shows green:

Capture5

Great!

Until you apply an Exchange update. So on goes 2013 CU12 for example, and like all good admins you check the certificate one more time against  https://www.digicert.com/help/

Capture2

Doh!

Well, luckily it’s easy enough to fix of course. Reapply that registry setting and reboot.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
“Enabled”=dword:00000000

Capture5

Whew. So, what’s going on here? Well, take a look at the ExchangeSetup.log file under the ExchangeSetupLogs directory at the root of the system drive:

 

04/26/2016 17:27:46.0177] [1] Executing:
$keyPathRoot = “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols”;
$keyPath = $keyPathRoot + “\SSL 2.0\Server”;
if (!(Test-Path $keyPath))
{
New-Item -path $keyPathRoot”\SSL 2.0″ -ItemType key -Name “Server” -Force;
}
Set-ItemProperty -path $keyPath -name “Enabled” -value 0x0 -Type DWORD -Force;

$keyPath = $keyPathRoot + “\SSL 3.0\Server”;
if (!(Test-Path $keyPath))
{
New-Item -path $keyPathRoot”\SSL 3.0″ -ItemType key -Name “Server” -Force;
}
Set-ItemProperty -path $keyPath -name “Enabled” -value 0x1 -Type DWORD -Force;

As you can see, Exchange Setup happily sets that key and enables SSL 3.0.

Just something to put on your post upgrade checklist!

 

Error when accessing a resource mailbox: “The value ” is already present in the collection”

When accessing a resource mailbox in Exchange 2013 EAC, you may encounter an error that you prevents you from viewing or editing the room mailbox properties:

Capture

 

Powershell is no good either!

 

Get-CalendarProcessing <Room>
WARNING: An unexpected error has occurred and a Watson dump is being generated: The value ” is already present in the
collection.
The value ” is already present in the collection.
    + CategoryInfo          : NotSpecified: (:) [Get-CalendarProcessing], InvalidOperationException
    + FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.Exchange.Management.StoreTasks.GetCalendarProcessing

 

Cause: Typically this is because there is a disabled mailbox listed in the RequestInPolicy or BookInPolicy attributes for the room.

Solution: Run the following in Exchange Powershell to clear the values. Example:  Set-CalendarProcessing <Room> -BookInPolicy $null  

Once done, you should be able to access the room via Powershell or EAC and re-add any required requesters to the room policy. Alternatively, if you have Exchange 2010 still around, you can simply remove the disabled mailbox via the 2010 EMC.