Archive | Uncategorized RSS for this section

Recipient Administrators and Public Folder Administrators can’t add Send As permissions by default

Not something we ever noticed before, but after migrating away from 2010 to 2016 and now handling all administration via EAC instead of Public Folder Management MMC mid-level admins found they could edit Send On Behalf for Public Folders and Mailboxes but not Send As.

This post solves the issue for us, adding the permission to Recipient Admins.


Blocking High Contrast Mode Hotkeys

The results of Left Alt + Left Shift + Print Scrn

If you use Group Policy or Registry settings to block the changing of the desktop theme, you might note that this doesn’t seem to block the hotkey combo for setting High Contrast Mode.  HOWEVER, it does block using the key combo to change things back.

Found a registry setting which disabled the hotkey combo, but still allows it to be set manually if allow it.

HKEY_CURRENT_USER\Control Panel\Accessibility\HighContrast
Set a REG_SZ named “Flags” with a value of 122 (126 appears to be default).

I set it via GPP

Once the user logs off and logs in again, the key combo won’t work anymore!

Last night a blog post saved my life! (Or, Hey there’s a really annoying bug in Windows Server 2003 SMTP Service)

All comments aside about how Server 2003 is EOS in about 60 days, some of us still live in a world where those are in use. :-(

In the process of disabling RC4 ciphers on our Exchange servers, we had an IIS 6.0 SMTP service experience begin failing to deliver mail to Exchange.  The IIS server was forwarding mail to Exchange and using TLS.  The immediate presumption was that without RC4 there were no common ciphers with the Exchange server anymore, so we went about installing KB948693 to add AES cipher support to 2003, at least getting to the point where they could share a relatively modern set.  This alone did not fix the issue and looking in Wireshark, there was some odd tailing data when the 2003 was trying to use a cipher other than the RC4 ones which were previously working. This shows up simply as “Ignored Unknown Record” when sniffing the attempted AES use, which by itself isn’t very telling, but appears in stark contrast where the conversation is much cleaner/understood when using RC4.


There’s an amazingly thorough write up of this on

Essentially the problem occurs when using block ciphers as opposed to stream ciphers.  There’s an old update, KB957047, which mentions issues after setting FIPSAlgorithmPolicy =1, which we hadn’t done, but apparently has the same net effect as it forces a switch to 3DES (block cipher). Puzzling that the version of smtpsvc.dll that we had was newer than the one listed in the 957047, so at first glance, would have thought that we wouldn’t need it.  Tried installing it anyway and got warning messages about failed missing dependencies in a package from KB976323, so after re-applying 976323 and then applying 957047, the Ignored Unknown Record disappears from the trace and mail flows normally .  Neither 957047 or 976323 requires a reboot but do restart IIS.  Seems like good practice to re-apply 976323 yet again as well.

So thanks as I’d unwittingly already been through MS Support for this issue before and not realized what side the issue was on.

Clearing up Event 36887 – Schannel The following fatal alert was received: 48


Schannel errors in Event Viewer tend to be really unhelpful.  From MSDN, Error 48 indicates TLS1_ALERT_UNKNOWN_CA  SEC_E_UNTRUSTED_ROOT  0x80090325 so most likely due to a self-signed, or internal CA signed certificate on the host in question.  But it doesn’t indicate which client computer is triggering the error.

However, you can get fairly precise time out of the XML view under the details tab (TimeCreated SystemTime gives the time with lots of decimal places making it way easier to find the offending traffic in a network capture.


To find it in Wireshark, change the Time Display Format to  “Date and Time of Day” in the View Menu (Ctrl+Alt+1) and filter by “ssl”  The timestamps aren’t identical (plus the event log entry isn’t adjusted to the local timezone), but it’s close enough that you shouldn’t have trouble finding it.  The particular traffic I was seeing looked like this.

2014-06-11 12:00:25.774832 TLSv1 73 Alert (Level: Fatal, Description: Unknown CA)

The first IP above ( is the remote client which is triggering the issue.  The second IP ( is the local machine.  Then just had to sort out adding the internal CA cert to the client machine. Fixed!

Why are my LUNs offline because of policy?

Here’s something I’ve been seeing off and on since Exchange 2007.  After a reboot, The LUNs presented off the SAN sometimes appear in Disk Management with the note “The disk is offline because of policy set by an administrator” and you end up needing to manually online each disk.

There are a number of blog posts and such indicating that you need to change the SAN Policy of the server.  The default being “Offline Shared” on Enterprise and Datacenter editions of Windows Server.

The recommendation of these posts being to set the san policy to “Online All” to solve the problem.  This done as prescribed by

san policy=OnlineAll

After a reboot I would find that the problem persisted, the volumes would still show as offline with the same note about policy.  What wasn’t obvious from all those posts was that each disk has its own registry bit indicating that each disk has it’s own setting related to san policy which is apparently set when the disk is discovered. The values are described below.

  VDS_SP_UNKNOWN         = 0x0
  VDS_SP_ONLINE          = 0x1
  VDS_SP_OFFLINE         = 0x3

1,2 and 3 are somewhat obvious, but 0, VDS_SP_UNKOWN seems to indicate that for that disk, the value is undefined so to speak and that it follows the system san policy.

So it appears that in my case, with the default at Offline Shared, disks inherit that setting and regardless of what the system san policy is set to afterward, the disk remembers Offline Shared.

Found another KB article which points out that fact AND includes a quick powershell script to fix it.

You’ve got to dig out the string indicating your vendor from the registry, but that’s easy to find under HKLM:\SYSTEM\CurrentControlSet\Enum\SCSI


The number of people who run Exchange without a DAG is mindboggling.  I’ve run into several business, running Exchange 2010/2013 which don’t use DAGs at all.  Even if there’s only one location, why?