Recently we encountered an issue where a client was using Exchange Online authenticating using ADFS/SSO.
Issue: Outlook would not connect to Exchange Online after changing the user’s password in Active Directory.
- We ran Outlook in Online mode, this remedied the issue but was not something the client wanted to do for the organization.
- Clearing the local credential cache from Windows also resolved the issue. However, this is not a fix so much as a workaround.
Interestingly enough, after stumping Microsoft support for a few hours, we decided on a whim to enable Modern Authentication for Exchange Online withing the Office365 tenant.
The commands are as follows:
Step 1. $Credentials = Get-Credential
Enter in the account with administrator priveledges to the tenant.
Step 2. $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Credentials -Authentication Basic -AllowRedirection
Step 3. Import-PSSession $Session
Step 4. Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true
Note: You can check to see if it is already enabled or verify the command worked by entering the following:
Get-OrganizationConfig | Select Name, OAuth*
I have seen in some cases that after enabling the correct telephony policy that users still do not have the “Video” button within the menu of the Lync client’s IM window. This is usually caused by a GPO of some sort not allowing the proper registry values to be updated. As always, I implore you to attempt restarting the Lync client before making the following change to see if the issue resolves itself and proceed at your own risk as we will be modifying the registry.
- From the registry navigate to HKCU\Software\Microsoft\Communicator
- Double click the OCTelephonyMode DWORD.
- Change the Hexadecimal value to 1.
- Restart Lync
In most cases you will see the the value was set to 5, which is IM and Presense Only.
I hope this helps.
It would seem Microsoft fixed the blunder that was MS13-061 that changed settings for the search infrastructure, placing the content index for all databases into a failed state. They have assured us that they “tested” this release.
They have released the updates here:
Per Exchange team blog…
Questions & Answers
Q: What was changed in these patches?
A: The registry settings for the search infrastructure outlined in KB 2879739 are preserved during patch installation.
Q: Was this patch tested in your on-premises environment prior to release?
A: Yes, we tested this in our Exchange Dogfood environment prior to release and validated that the search settings were retained upon installation.
Q: What happens if I uninstall the security update (or any other interim update I receive from Microsoft for Exchange 2013)?
A: You will need to follow the steps identified in KB 2879739, otherwise your search infrastructure will be broken.
Q: Wait, I thought you fixed that issue; why do I have to follow KB 2879739 if I uninstall?
A: This has to do with the way the search infrastructure is installed during the Cumulative Update. Unfortunately, this issue cannot be corrected via a patch file; we have to address it in a cumulative update. We are planning to address this in CU3.
Q: If I uninstall a patch and then install a new patch, do I still have to follow the steps in KB 2879739?
Q: Will I need to follow KB 2879739 every time I install a patch?
A: No; the installation of a new patch without uninstalling the previous patch will not introduce this behavior.