Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
A few months ago I successfully configured the Dynamics 365 App for Outlook. It worked correctly in all environments until yesterday.
Application Versions:CRM: 220.127.116.11 (on-prem)AD FS: 3.0 (Server 2012 R2)Outlook 2016 (16.0.4843.1000)Exchange is on-prem as well.
Beginning yesterday, when users try to access Dynamics 365 within the Outlook client, they are prompted for credentials, via the AD FS form prompt, however the window does not dismiss after a successful credential challenge. The "We're reviewing you Dynamics 365 information..." spinner continues to spin in the reading pane, but will ultimately time out with the message:
But if you find out anything, I'd love to hear about it. We currently have almost a thousand unhappy users that can't track anymore because of this issue.
No definitive explanation yet, if anything just more conflicting details.
I disabled automatic updates removed and reinstalled Office 2016 on my PC. The App for Outlook worked perfectly on the fresh Outlook install, version 16.0.4266.1001. Curiously, I didn't even receive the AD FS authentication challenge.
I rebooted once or twice and the old version of Outlook continued to function correctly.
I enabled updates, and installed all available updates, expecting the App to break again.
However the app did not break. It is still running successfully on my PC, at version 16.0.4849.1000, which is higher than the version I started with when the error was occurring.
Complicating things further, our team members access Outlook via Citrix VDAs. Those delivery servers do not take updates on Patch Tuesday and do not show any updates on or around 7/9/2019, when the issue started.
One of the blogs I ran into briefly mentioned a similar issue after a publish occurred, which was resolved by clearing the cache in IE. I did publish one entity before the issue reports began, but it only changed the default sort order of a View. Is it possible that you published something just prior to the issue occurring as well?
Is there a cache in Outlook for the App that could have been knocked out of sync after a publish, and was cleared on my PC during the un/reinstall?
I appreciate the update. I will try your strategy of reinstalling Outlook to see if that works for me.
From my side of things I've established the following...
1. The outlook app works for anyone on Windows 10 or higher in my company
1. The outlook app does not work for anyone on Windows 7
2. The outlook app works in OWA on Chrome in any OS
3. The outlook app does not work in OWA on IE on Windows 7
4. If you switch to InPrivate mode, the outlook app will work on IE in OWA
I've opened up a github issue with the Office Dev team hoping they will take a look at it.
My PC is Windows 10, and did experience the issue.
The VDAs are Windows Server 2008 R2 SP1, so the same user experience as Windows 7.
The Outlook App in OWA does work on IE in the 2008 R2 environment.
That is beyond concerning that OWA works for you InPrivate. That screams that a cached response is being used rather than actually making the call to generate a new response. Fiddler broke my access to the AD FS credential prompt when I had the error in the Outlook dialog, and I can't access Developer Tools in the Office Dialog to debug what's going on in the JS on my end.
I'd love to step through that InlineData() method, line 32: System.Net.WebRequest request = System.Net.WebRequest.Create(uri);
If that is returning cached data, might it be passing an invalid auth token into Office.context.ui.messageParent()?
While I was looking through your fiddler traces the managed services team finished uninstalling and reinstalling Outlook on the VDA. That appears to have resolved the issue there as well. I am beside myself on this.
Same problem for us, it began on 10 Jul 2019 :
Products version :
We checked all CRM, ADFS configuration all seems Ok.
No updates was installed.
No ideas, any help will be usefull.
we have the exact same issue for one of our customers.
Seems like uninstalling this update solved this: KB4464534
Still investigating the issue, but could be related to this security patch.
Thank you! That was tremendously helpful.
This morning my issue returned on my development PC, previously I "resolved" the issue by uninstalling and reinstalling Office 2016, overkill.
I was able to get myself back into a working state by removing KB4464534.
What this does not explain is why the rest of my company experienced the issue, we do not believe that this update, or any other, was installed in our Citrix delivery environment.
I do not want to flag this as answered just yet, but I will do so after more testing.
We are also facing the same issue.
All userclients does not have this patch, and somehow they are still facing this same issue.
Could you link me the blog you mentioned earlier - regarding publishing could couse this kind of issues?
I think this was it. I've cleared my IE cache more times than I can remember with no luck though.
You are saying clearing the App cache fixed it for your company? How is the process for that different than clearing the browser cache?
No, uninstalling Office fixed my company, which isn't really a solution.
I had alluded to the linked discussion in a previous post, it did not actually help me.
Anything new Frank?
Did you manage to solve this?
Testing over the weekend shows that removing KB4464534 will resolve the issue on Windows 10 for me.
My core set of users are still okay now as well after uninstalling and reinstalling Outlook once. I cannot explain why they were impacted in the first place, and I am still concerned that the issue is going to come back for them. I know everyone in this thread has mentioned impacted PCs being that did not take updates, and I'm having a hard time letting this go because of that.
Also interesting, if you authenticate successfully, then install KB4464534, you will stay authenticated for some time, probably defined by the TokenLifetime on the ADFSRelyingPartyTrust. After the token times out and you are prompted to login again, the authentication will fail.
So, we have the exact same problem since last week and have a ticket open with Microsoft Support but that's taking some time. Today i stumbled against your topic and tried removing KB4464534 on an affected computer. After rebooting i double checked if the KB4464534 was removed and it was. After opening Outlook an trying to track an e-mail it still throws the white screen.
Any suggestions (beside reinstalling outlook 2016)? People who are experiencing this problem are using Chrome and webmail for now as workaround.
Is it showing you the white screen before or after the credential challenge? One thing I have noticed is that KB4464534 will reinstall itself on a reboot, probably depending on your Windows Update settings. Can you try pausing Windows Update, reboot, make sure KB4464534 is still gone?
I am working on permanently hiding that KB on my PC this morning. I have been back and forth a few times now between working / not working based on pausing Windows Update and removing that KB.
I am very glad to hear that you have a ticket open with Microsoft though, please be sure to let us know what their solution is.
The affected file was fixed in CDN. The file is cached locally for 24 hours, so users would need to clear out their local IE cache in order to get the fix immediately, otherwise, it may take up to 24 hours to surface in the client without such manual action. As fix was done on Friday 7/19/2019, so you should not see this issue anymore.
Business Applications communities