INFRASTRUCTURE SUMMARY: VMware Horizon 7.1 with Floating Pool, AppVolumes 2.12.1, UEM, Group Policies
VIRTUAL MACHINE SUMMARY: Windows 10 Enterprise (CBB) v.1607 (64-bit), Office Professional Plus 2016 (64-bit)
PROBLEM DESCRIPTION: This happens to all users of our floating pool. Immediately after launching Outlook (even multiple times within the same session), a "Windows Installer" pops up attempting to perform some updates. After waiting about 30 seconds, the process finishes, leaving us with another pop-up that says to restart for changes to take effect. Since we run a floating pool, upon logout, whatever changes were made to the VM vanish. We tried running an update on the golden image but there are no updates to apply, so we are thinking that the installer is attempting to update the profile on the user's write volume. A VMware KB article warns not to install Outlook components into a user's write volume. If related, we don't know how to prevent this. Maybe suspending these popups is a solution but we don't know how.
WINDOWS INSTALLER MESSAGES: "Preparing to install"; "Please wait while Windows configures Microsoft Office Professional Plus" with a restart request afterwards...sometimes.
I have a similar problem with a similar configuration to GTCyberMike + user Writable volumes.
Office 365 ProPlus has been properly updated on the golden image. On a new clean user, Office reports the proper (latest) build number. Existing users launched from the same VM instant-clone pool report older Office build numbers and prompt the user to Update with a yellow banner.
If the user clicks on Update from within an Office App, I have seen mixed results. The vast majority fail with the "Something Went Wrong" message after the update shuts-down any open Office Applications. Oddly on two workstations, the users didn't get my memo and repeatedly tried Updating, and were ultimately successful, with windows no longer prompting to Update and the proper Build number being reported.
Not that you should have to, but running the various normally disabled Update services on the user workstation, does not seem to change the result.
Anyone thoughts on how to fix the problem, or a solution, would be greatly appreciated. My users find the Office Update Yellow Banner very irritating but at least can work.
Might not be relevant, but we had a single user getting this installer prompts upon launching Excel/Visio 2016 products the day we implemented our recompose of our Master Image from Office 2013 to Office 2016. A reset of his UEM settings for Visio fixed the Visio installer issue. We think some of the Office 2013 UEM settings were interfering. He also had a custom old Macro in Excel that was causing the Excel installer issue.
Anything telling in System/Application Event Viewer?
Also could be an Outlook Add-in doing it, maybe start Outlook in Safe Mode to rule out?
Thanks for the feedback. We tried launching Outlook 2016 (64-bit) in safe-mode and the installer pop-up goes away. This led us to believe that it was an add-in problem, but after disabling all the add-ins, the problem persisted. So there is something else that Safe Mode is doing to correct the problem besides disabling the add-ins.
Give this a try and see if it helps. Outlook might be reconfiguring each time.
reg add HKCU\Software\Microsoft\Office\16.0\Outlook\Options /v NoReReg /t REG_DWORD /d 1
Thanks techguy129. We tried this but it did not solve the problem for us. Since we are running the 64-bit version of Office, we are attempting to try the QWORD option, instead of DWORD registry option.
Mark808 VDINinja311 techguy129VDINinja311
We tried the following troubleshooting and here are the results. The 2 solutions are not ideal for our environment but they may give us insight into the root cause. Also wondering if the applying some additional exclusions to the snapvol.cfg file inside the c:\snapvolumestemp\... directory might help us in this case.
I noticed the identical behavior. Disabling the "Windows Installer Service" over GPO is an acceptable workaround:-)
I've confirmed that the Windows Installer Service is disabled on my non-persistent VM user logins and still the yellow "Updates Available" banner appears on all my Office applications. Oddly the Build number also reports the old version.
This only occurs for those with Writable volumes created prior to updating Office on the master image.
I tried all the things in GTCyberMike's list (other than Safe Mode) and still have the the yellow Update banner in all Office Applications and Office reports a different Build number than is actually loaded on master image.
Deleting and recreating the Writable Volume and rebuilding the user profile (other then the items saved off by UEM) works, but is a pain, and problem will likely reoccur with the next major Build of Office.
Any other suggestion on what can be tried?
Are you using Appsense or other logon scripts during login. we had seen delayed start is fixing the issue. Also, does the prompt goes away after sometime?. If yes this mostly relates to logon race condition. Give it a try and see if this works.
Thanks for the suggestion about researching possible race conditions.
We are not using AppSense, and have no added custom login scripts. We do have UEM redirecting the the usual User folders and Desktop and Favorites, but NOT the Program Menu or the Roaming AppData. I figured those are best left on the Writable Volume. So I don't see the possibility for a race condition there. I'll dig deeper. Perhaps I have a duplication of something in UEM Personalization settings that is causing this problem or it conflicting with something in my snapvol.cfg file. By the general low response to this thread this is not looking like a commonly encountered problem.
Has anyone ever fixed this? We are having the same issue.
Anyone have a resolution for this issue? Outlook 2016 worked for our instant clones but when we moved to a linked clone configuration this problem occurs halting our deployment to our user community. Any suggestions on how to resolve?
Yup, same problem here. tried all the ideas in this thread but no difference. Does anyone from VMWare have a solution to this problem?
I'm not from vmware, but one thing I don't see listed here, make sure you install all components to disk. I opened a ticket back awhile ago, and we solved it making sure every optional component was installed along with office(not including visio and project), and we stopped seeing those errors.