After migrating a mailbox to Office 365 Exchange Online, if the mailbox previously had full access permissions prior to the migration, then after the mailbox migration is finished the user may receive lots of authentication prompts. This happens by design since cross-forest permissions are not supported. Mailboxes that require full-access and/or send-as permissions should be migrated together in groups to avoid this issue.
But what happens if someone overlooks this requirement and moves a mailbox without moving the shared mailboxes along with it? This is where it gets very interesting. While it is possible to remove the full-access permission from the on-premises mailbox, that change won’t sync or take any effect and doesn’t solve the issue. Likewise, migrating the mailbox to Office 365 with the permissions removed prior to the shared mailbox migration won’t solve the problem (you might expect the original mailbox to see the newly migrated mailbox and that it no longer has full-access, and that would be enough to remove the AutoMapping feature). However, no, that is not how it works. To remove the auto-mapped shared mailbox, you have to migrate the shared mailbox, add the full access permission, then remove it again. That triggers the delegate’s outlook to remove the shared mailbox from the left navigation in Outlook.
During a deployment at a customer site I ran into a problem with SkypeFB Edge replication.
After adding the Edge to the topology, installing the role on the server and proper certificates, replication was failing with Event ID 1046 and Event ID 1047.
The solution was to add the following registry key:
- Open Regedit on the Edge server
- Go to HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL
- Right click and add the DWORD (ClientAuthTrustMode)
- Set the value of the DWORD to 2
- Restart the server
- On the front-end run this command and then wait 2 minutes
Additionally, when working with Microsoft support they also recommended creating these two additional keys:
SendTrustedIssuerList (Value 0) and EnableSessionTicket (Value 2).
There is an interesting troubleshooting article with tracing presented here that could also solve the problem if it was caused by a missing intermediate authority.
And while researching this problem, I came across a very thorough article on this topic that is worth translating into English: http://www.msxfaq.de/signcrypt/win2012tls.htm
Immediately after installing Skype for Business Server 2015 (Standard Edition) the front-end services would not start.
Tom Rimala’s blog article that suggested there is a problem when the internal Certificate Authority uses MD5 as the signature signing method.
Also, the Microsoft Certificate Requirements says “The default digest, or hash signing, algorithm is RSA.” (no mention of MD5).
I changed the CA Authority’s certificate from MD5 to SHA1. Here is the registry key to change on the Root CA signing information (we changed these three values). Note: the guidance was to change this on the Root and Subordinate but in our case the Root was also the issuing CA, so there was no subordinate to change in our case.
The next step is to restart the Root CA services. Then issue a new Root Certificate. Then copy the new root CA cert to the Skype for Business front-end, and finally re-issued the Front End Cert and OATH cert. Then the services should start up.
There was a false negative warning about Event ID 32174 “Server startup is being delayed because fabric pool manager has not finished initial placement of users.” This is clearly a bogus error because a Front-End server doesn’t have additional servers to place users into.
There was a clue about the Certificate problem because the System Event log contained a ton of Schannel events such as 36888, “A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.” And Event ID 36874 “An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.” I am adding these details in the event that a search engine might index these errors to point people to this fix.