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.

ADFS in 2012R2 – Replacing the Service Communications certificate

I’m not alone in this. Replacing the Service Communications certificate in ADFS under Server 2012R2 is an inconsistent experience to say the least. After a less than ideal run through of updating the cert on some test ADFS servers, I felt that I at least knew the pitfalls and could update the production ADFS servers without too much hassle.  Wrong.

What seems like it should be the obvious method to specify a different Service Communications certificiate, using the ADFS Management MMC, does not work reliably.  For one, you need to manually add permissions for the new cert’s private key.  NT Service\drs and NT Service\adfssrv need read access. The MMC does warn you of that, but that’s something that seems like an obvious oversight.  The installation adds those permissions, so why would the change then be manual?


Onto the problem. I found in both the Test and Prod setups that attempting to change the certificate in the MMC does not work.  The new cert is shown in the MMC, and even if queried with Get-AdfsCertificate, but the clients still see the old certificate. Several restarts of the ADFS service, and reboots of the server did not help.

On the Test server, I was able to use Set-AdfsCertificate, followed by another restart to have it start using the new cert.

Set-AdfsCertificate -CertificateType Service-Communications -Thumbprint <thumbprint>

Made the assumption that this would be the same case for Prod.  It wasn’t. After running through those first steps, the new cert wasn’t in use and no amount of setting it to the new, back to the old, back to new was making a difference.

Finally came upon a number of posts where people mentioned having to manually bind the new cert using netsh.

netsh http delete sslcert hostnameport=<your hostname>:443
netsh http add sslcert hostnameport=<your hostname>:443 certhash=<your cert thumprint> appid={5d89a20c-beab-4389-9447-324788eb944a} certstorename=MY sslctlstorename=AdfsTrustedDevices

same thing for localhost:443, and then <your hostname>:49443, but leave off the sslctlstorename for 49443.

Shoutouts to

Also to Interesting powershell script to check for issues with the cert bindings

Error when adding second 2012R2 AD FS server when using gMSA

Ran into an set of errors when adding a second 2012R2 ADFS server where the service was being run under a Group Managed Service Account.

They were:

  • There were no SPNs set on the following service account ‘DOMAIN\gMSAname$’. Specify the service account used to configured the other FederationServers in the farm, or set the host SPN for the farm on the service account.
  • The user name of password is incorrect
  • Unable to determine the Service SPN.  There were no SPNs set on the following service account ‘DOMAIN\gMSAname$’. Specify the service account user to configure the other Federation Servers in the farm, or set host SPN for the farm on the service account.
  • Unable to retrieve configuration from the primary server. The username or password is incorrect
  • Prerequisites Check Completed
  • One or more prerequisites failed. Please fix these issues and click “Rerun prerequisites check”

I had previously set up ADFS 3.1 with standard service accounts with no issues in the same layout as the new servers so the only immediate difference to me was the gMSA.  The errors as listed appeared incorrect, as I could verify the SPN for the ADFS farm on the gMSA, and more importantly, the first server was working fine.  The error about the password being incorrect seemed erroneous as one of the features of using the gMSA was specifically that it handled passwords automatically.

Finally got a hint to a solution when I came across this post

The issue appears to be related to the location/availability of the 2012R2 Domain Controller, in relation to the new ADFS servers.  In order to deploy gMSAs, at least 1 2012R2 Domain Controller in the domain is necessary.  I had added only 1, so as to satisfy this requirement.  Since I’m deploying ADFS across sites, the result was that I had one ADFS server in a site with a 2012R2 DC, and the other was in a site with only 2008R2 DCs.

It appears that when your initial ADFS server using gMSA is installed, it matters for future servers whether or not they can communicate with a DC of the same version (or higher?) as the original ADFS server does when installing.  When I had done the first ADFS install, it was in the site with the 2012R2 DC, but the second install was in a site where there was no 2012r2 DC.  After reading the above post, I tried some of the steps related to changing the logonserver, but realized in my situation that since the two servers were in different sites, it might not be possible to cause them to use the same DC, without altering the sites anyway.  Instead, I removed the ADFS install on the first server and did the new first install on the server in the 2008R2 site.  Now, the second install in the 2012R2 site runs smoothly and ADFS works great.

Possible bug in Exchange 2013 CU5 Setup.exe /PrepareAD

Recently ran into an issue when attempting to run Setup.exe /PrepareAD for Exchange 2013 Cu5.  As with all new Exchange updates, the expectation is that there will be schema updates included.

Upon running the Setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD command I get this error.

Performing Microsoft Exchange Server Prerequisite Check

Prerequisite Analysis COMPLETED

Configuring Microsoft Exchange Server

Organization Preparation FAILED
The following error was generated when "$error.Clear();
initialize-ExchangeUniversalGroups -DomainController $RoleDomainController -ActiveDirectorySplitPermissions $Rol

" was run: "Microsoft.Exchange.Data.Directory.SuitabilityDirectoryException: An Active Directory error 0x51 occurred whe
n trying to check the suitability of server ''. Error: 'Active directory response: The LDAP server
is unavailable.' ---> System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
at System.DirectoryServices.Protocols.LdapConnection.Connect()
at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCrede
at Microsoft.Exchange.Data.Directory.PooledLdapConnection.BindWithLogging()
at Microsoft.Exchange.Data.Directory.PooledLdapConnection.TryBindWithRetry(Int32 maxRetries, ADErrorRecord& errorReco
--- End of inner exception stack trace ---
at Microsoft.Exchange.Data.Directory.TopologyDiscovery.SuitabilityVerifier.CheckIsServerSuitable(String fqdn, Boolean
isGlobalCatalog, NetworkCredential credentials, String& writableNC)
at Microsoft.Exchange.Data.Directory.ConnectionPoolManager.GetConnection(ConnectionType connectionType, String partit
ionFqdn, ADObjectId domain, String serverName, Int32 port, NetworkCredential credential)
at Microsoft.Exchange.Data.Directory.ConnectionPoolManager.GetConnection(ConnectionType connectionType, String partit
ionFqdn, NetworkCredential networkCredential, String serverName, Int32 port)
at Microsoft.Exchange.Data.Directory.ADDataSession.GetConnection(String preferredServer, Boolean isWriteOperation, St
ring optionalBaseDN, ADObjectId& rootId, ADScope scope)
at Microsoft.Exchange.Data.Directory.ADDataSession.GetReadConnection(String preferredServer, String optionalBaseDN, A
DObjectId& rootId, ADRawEntry scopeDeteriminingObject, DualSearchMode dualSearchMode)
at Microsoft.Exchange.Data.Directory.ADGenericReader.GetNextResultCollection(Type controlType, DirectoryControl& resp
at Microsoft.Exchange.Data.Directory.ADPagedReader`1.GetNextResultCollection()
at Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.GetNextPage()
at Microsoft.Exchange.Data.Directory.ADGenericPagedReader`1.<GetEnumerator>d__0.MoveNext()
at Microsoft.Exchange.Data.Directory.Recipient.ADRecipientObjectSession.<FindByAccountName>d__2`1.MoveNext()
at Microsoft.Exchange.Data.Directory.Recipient.ADRecipientObjectSession.FindByAccountName[T](String domainName, Strin
g accountName)
at Microsoft.Exchange.Management.Tasks.InitializeExchangeUniversalGroups.InternalProcessRecord()
at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePip

The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup.log located in the
<SystemDrive>:\ExchangeSetupLogs folder.

I looked at a network capture while attempting to run it again and saw something odd. Right at the time of the failure in the ExchangeSetup.log there’s an attempt to contact a non-GC Domain Controller on port 3268.  Which obviously fails.

The problem appears to occur during the execution of the command:
initialize-ExchangeUniversalGroups -DomainController $RoleDomainController -ActiveDirectorySplitPermissions $RoleActiveDirectorySplitPermissions

Looking in the log file it identifies a Preferred GC (DC02) and Preferred DC (DC01 which is the Schema Master). They are used successfully it seems earlier in earlier portions of the update.  But when initialize-ExchangeUniversalGroups runs, for some reason it doesn’t use the identified GC, doesn’t even try before attempting a connection to the non-GC.

In trying to fix this, I moved the Schema Master role from DC01 to DC02 (the GC).  The next time /PrepareAD worked fine.  Presumably making the Schema Master a GC would have also worked.  Strange problem though as I’ve done the rest of the schema updates involved in the previous 2013 CUs without any problem.