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.
http://markswinkels.nl/2012/07/send-as-permissions-with-recipient-management-in-exchange-2010/
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 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.
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
http://tristanwatkins.com/changing-adfs-url-windows-server-2012-r2/
http://www.reinhard-online.nl/2014/10/strange-behavior-ad-fs-windows-server_88.html
Also to http://blogs.technet.com/b/applicationproxyblog/archive/2014/05/28/understanding-and-fixing-proxy-trust-ctl-issues-with-ad-fs-2012-r2-and-web-application-proxy.aspx 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 https://secureidentity.se/mystery-with-adfs-and-gmsa/
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 eActiveDirectorySplitPermissions " was run: "Microsoft.Exchange.Data.Directory.SuitabilityDirectoryException: An Active Directory error 0x51 occurred whe n trying to check the suitability of server 'DC01.Example.com'. 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 ntial) at Microsoft.Exchange.Data.Directory.PooledLdapConnection.BindWithLogging() at Microsoft.Exchange.Data.Directory.PooledLdapConnection.TryBindWithRetry(Int32 maxRetries, ADErrorRecord& errorReco rd) --- 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 onseControl) 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 elineIfFailed)". 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 DC01.example.com 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.
Fixing case in Windows DNS entries
There is almost no legitimate reason to spend time “correcting” the case (uppercase, lowercase, CamelCase) of DNS entries, in fact there aren’t any I can think of at the moment.
That said, maybe you find yourself in a position where a DNS entry in Windows Server does not appear in the way you would prefer. Deleting the entry in the DNS MMC and re-registering the entry they way you’d like it often doesn’t alter the original format. The reason here is the first time a server performs a dynamic registration/update of its DNS name in an AD integrated zone, an object is created in that zone. Deleting that entry manually (or letting it expire) results in the entry being dnsTombstoned and not truly deleted, not yet anyway.
If DNS Scavenging is configured, that object will eventually be removed permanently, if not, the object is essentially immortal. When you re-register the same name, the original object is re-animated (dnsTombstoned = <not set>, or I’ve also seen “FALSE”) causing the original format of the name to come back.
Here’s how to go about “fixing” that.
Each AD object representing a DNS entry is stored in a specific place in AD, based on the replication scope of that particular zone.
Zone replication scope |
Location in Active Directory |
|---|---|
All DNS servers in the Active Directory forest |
Replicates zone data to all DNS servers that are running on domain controllers in the Active Directory forest. Usually, this is the broadest scope of replication.DC=<zone name>,CN=MicrosoftDNS,DC=ForestDnsZones,DC=<domain>,DC=<domain> |
All DNS servers in the Active Directory domain |
Replicates zone data to all DNS servers that are running on domain controllers in the Active Directory domain. This option is the default setting for Active Directory–integrated DNS zone replication in Windows Server 2003 and Windows Server 2008.DC=<zone name>,CN=MicrosoftDNS,DC=DomainDnsZones,DC=<domain>,DC=<domain> |
All domain controllers in the Active Directory domain |
Replicates zone data to all domain controllers in the Active Directory domain.DC=<zone name>,CN=MicrosoftDNS,CN=System,DC=<domain>,DC=<domain> |
The individual entries have objects one level deeper e.g. DC=MYSERVER,DC=mydomain.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=mydomain,DC=com
If you wanted to change that server name to lowercase e.g. “myserver”, the DC=MYSERVER,DC=mydomain.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=mydomain,DC=com object would need to be removed, also potentially replicated to the rest of the relevant servers and then I reloaded the zone just to make sure.
At that point I could re-register with the name in the format I wanted.
Configuring Cisco WebEx Meeting Server to work with ADFS 2.0+
Fantastically useful set of instructions! If only Cisco’s own docs were this good…
Like so many other things I’ve written about, this is another example of where I was unable to find a solid set of instructions online about how to do something and had to assemble a working solution from a number of fragments spread across vendor-provided information, blog posts and cries for help posted in online forum threads. Hopefully this can spare at least a few others from having to go through the same thing.
This procedure has been used to create a system that works on the “first try” so I know that it works. It’s possible that this could be further refined with some additional testing.
This post is targeted to the on-premise version of the Cisco WebEx meeting server, not the hosted (SaaS) version. I believe that most of what is here should be applicable to the hosted version but there are apparently some differences in the configuration…
View original post 1,227 more words
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 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!
ril3y 