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.
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.
Set a REG_SZ named “Flags” with a value of 122 (126 appears to be default).
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 https://lbr.id.lv/#Windows_SMTP_bug_breaks_3DES_and_AES_CBC
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 lbr.id.lv as I’d unwittingly already been through MS Support for this issue before and not realized what side the issue was on.
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 192.168.1.100 192.168.1.10 TLSv1 73 Alert (Level: Fatal, Description: Unknown CA)
The first IP above (192.168.1.100) is the remote client which is triggering the issue. The second IP (192.168.1.10) is the local machine. Then just had to sort out adding the internal CA cert to the client machine. Fixed!
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 http://technet.microsoft.com/en-us/library/gg252636.aspx.
diskpart san 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_SHARED = 0x2 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. http://support.microsoft.com/kb/2849097
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