My Top Five Lackluster Band Names

My personal list of the top 5 band names that show really no attempt to come up with anything clever or original. My criteria? None really. But these names have always annoyed me. I guess it doesn’t take much.

5. The Cars: Do I need to say more? I love these guys as much as the next person, but this is all they could come up with? Good luck getting Alexa to figure it out.  Be prepared to hear Gary Numan.

4. Mr. Mister: Why oh why?  I know they chose that name as a joke, but it felt so stupid to even say it.

3. Train: Right up there with “The Cars”.

2. Yes: No.

And the most lackluster…

1. J. Giles Band: Naming after a founding member is not unusual or bad in of itself, but usually it’s the artist most closely associated with the group. You know, that person that stands out or clearly represents them to the world. No, not this one. How many people even know which one is Mr. Giles? Even worse, one of the members is named “Magic Dick”.

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:



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

Hopefully it shows green:



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



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]


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!


You are unable to choose the OU in EAC when creating a new Mailbox or Groups…

If you have more than 500 Organization Units in your AD forest, you…you will, run into this issue in the Exchange 2013 EAC when creating a new mailbox or group and want to create the object in a different OU other than the default “Users” container.

Upon accessing the OU Dialog box:



You will see this lovely message:


Unfortunately, this is a known issue. There is no fix yet.

I would recommend you simply create the mailboxes and groups in Powershell if you want to specify the OU.

The work-around for EAC:

  •  Edit the web.config file on the MAILBOX server under

     \\Program Files \ Microsoft \ Exchange Server \ V15 \ ClientAccess \ ecp \

    add the following under the appsettings section of the file.

    <add key=”GetListDefaultResultSize” value=”<number more than OUs in your forest” />

Recycle ECP app pool.

Note that you will need to do this after each Cumulative Update.


P.S. If you do not know how many OUs your forest has:

Get-OrganizationalUnit -ResultSize unlimited | Measure-Object

Bogus Public Folder Mailbox Quota Alerts in Exchange 2013

All is not quiet on the Exchange 2013 front if you are running Public Folders. Once you migrate from legacy PFs, ( I assume you aren’t crazy enough to start using Public Folders in a greenfield 2013 org), you may start seeing over Managed Availability Alerts such as:

Log Name:      Microsoft-Exchange-ManagedAvailability/Monitoring
Source:        Microsoft-Exchange-ManagedAvailability
Date:          1/26/2016 8:30:31 AM
Event ID:      4
Task Category: Monitoring
Level:         Error
User:          SYSTEM
The public folder mailbox PFMBX01 is approaching its storage limit. Consider splitting the mailbox using Split-PublicFolderMailbox.ps1. This warning will not be sent again for at least twenty four hours. 
At this point, you may be tempted to move folders from this mailbox to another.

However, before you do that, check the actual quota usage either in EAC:



Or powershell:

Get-MailboxStatistics <PFMBX> |FL totalitemSize

TotalItemSize : 14.2 GB (15,248,828,208 bytes)

So what’s going here? Why are alerts firing when the mailbox quota warning has not been reached? Quite simply, it’s a bug.

The MA service doesn’t or can’t differentiate between individual folders that are nearing their quota and the actual Public Folder Mailbox. For the admin, this can create a lot of confusion. If an individual folder is nearing quota, the folder contacts will get alerted and that is typically sufficient. If the mailbox itself is nearing it’s quota warning level, the admin will obviously want to take action soon.

Hopefully this will be fixed in Exchange 2013 with a future CU.

For 2016, I will update this blog when I have time to test.

If you are concerned about missing actual PF mailbox over quota events, I suggest creating a scheduled PowerShell task that checks the mailbox sizes and fires off an email alert if the quota is approached.




Reminder: Leave those Default Receive Connectors Alone!

I have been preaching this on the forums for many years, but it’s worth a reminder. There is generally no reason to muck with the default receive connectors.

And yes, I am aware of the advice from the 2010 days:

Note that in 2013/16, anonymous is already enabled on the “Default Frontend” connector to boot!

Messing with them is a sure way to stop mail flow between servers and who knows what else.

If you need to customize or have the very common requirement to enable support for inbound TLS with a common FQDN across servers, create a new receive connector on each server. You’ll be glad you did.


“Public folder ‘\MyPublicFolder’ isn’t mail-enabled”

Continuing the 2013/2016 Public Folder theme… If you see this error in power shell:

Public folder ‘\MyPublicFolder isn’t mail-enabled.
    + CategoryInfo          : NotSpecified: (:) [Get-MailPublicFolder], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : [Server=Exchange01,RequestId=73da9220-fa76-4b50-923d-f1d45b2e4470,TimeStamp=1/11/2016 11
   :50:40 AM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 9A83BDC,Microsoft.Exchange.Management.MapiTa
    + PSComputerName        :

yet it shows it mail-enabled in EAC, consider that if you are in a multi-domain, it may not show as mail-enabled unless you set the scope to the entire forest (Set-ADServerSettings -ViewEntireForest $true)

Oh, and while I am thinking of it, in a multi-domain forest, the AD objects for legacy mail-enabled PFs were created in the MESO folder of the same domain as the folder creator. In 2013/16 PFs, the AD objects are created in the root domain MESO folder from what I have seen… Just something to keep in mind if you try to find them!


Anchors Aweigh!

My friend Andrew (what a cool name), has written an article about the latest change in Exchange 2013, starting with CU11 ( and Exchange 2016 CU1). I have to admit I am not a fan of anchoring for Powershell connections, but will withhold final judgment until after I get a chance to play around more with CU11. See: