- #DELL UNABLE TO ACTIVATE OFFICE 2016 INSTALL#
- #DELL UNABLE TO ACTIVATE OFFICE 2016 PATCH#
- #DELL UNABLE TO ACTIVATE OFFICE 2016 WINDOWS 10#
- #DELL UNABLE TO ACTIVATE OFFICE 2016 WINDOWS#
The process cannot access the file because it is being used by another process. 1 / 18 / 2018 12 : 25 : 09 PM - Wait for Service 'sppsvc' to get to State Stopped 1 / 18 / 2018 12 : 25 : 16 PM - Service 'sppsvc' State Stopped Thu 01 / 18 / 2018 - 12 : 25 : 16.33 - Copy the files from the layer into the 2.0 directory
#DELL UNABLE TO ACTIVATE OFFICE 2016 WINDOWS#
Microsoft ( R ) Windows Script Host Version 5.812 Copyright ( C ) Microsoft Corporation. Thu 01 / 18 / 2018 - 12 : 24 : 24.74 - Wait for SPPSVC to Stop to allow the updates
#DELL UNABLE TO ACTIVATE OFFICE 2016 WINDOWS 10#
Thu 01 / 18 / 2018 - 12 : 24 : 22.05 - Found Windows 10 will try to copy FromLayer \data. It appears as though I am, in fact, logging in before activation occurs : There's nothing in our scripts that should be doing that, so I'd be very interested in knowing who actually is shutting down your machine. Since you're redirecting your event logs, and I assume they're persistent, go check the System event log to see what process sent the Shutdown message. Also, our builds are always cumulative, so 4.7 definitely includes that fix.
#DELL UNABLE TO ACTIVATE OFFICE 2016 PATCH#
The patch you found me talking about is definitely not what you're seeing. Still, if you can induce this when booted in Private mode (or if you publish straight to the Hypervisor outside of PVS), check those files. Of course, since you say your machine always shuts down when this happens, it might not be possible to capture those files. For instance, if the activation always succeeds, but your user logged in before it started, that would suggest a delay would be useful. Compare that with when your user logged in to see if waiting longer would solve this. It will show you both when it ran and whether it succeeded. What Rob is suggesting is, when you see this, go check C:\Windows\Setup\Scripts\ActivateOffice_log.txt and see when (and whether) our script ran versus when your user logged in.
I found a post in another thread from gunthera that says the following: The ELM console did throw warnings about things possibly not working with this layer assigned elastically, but I have been able to use the apps in this layer just fine most of the time.
#DELL UNABLE TO ACTIVATE OFFICE 2016 INSTALL#
This layer was the only App Layer where I had to actually join the domain to install the application, and then remove it from the domain before Finalizing the layer. Throughout my testing, I did not see this issue once until I started working on that final Micromedex/Toxicall elastically-assigned layer. Office 2016 (standard apps minus OneDrive and OneNote KMS)Ĭore Apps (Adobe Reader, Cisco WebEx Meeting, and a few other apps)Īdmin Tools (RSAT, Notepad++, Firefox 57, and a few other apps) VCache (D: volume with pagefile and Event Logs moved onto it) The layered image consists of the following: Before I even get a chance to verify that both Office and Windows appear to be activated, the VDI begins shutting down, and I'm booted out. For the life of me I can't recall the exact message, so I'm going to try and grab the exact verbiage tomorrow, hopefully. Randomly - not all of the time, and I cannot reproduce it at-will - I will login to the VDI desktop, and a few seconds after the desktop loads will be presented with an Office 2016 message about needing to finish configuration/installation. I have Office 2016 installed in its own App Layer, following the recipe to the letter, using KMS activation. I've got a completely random issue that I'm hoping somebody else has come across before.
0 kommentar(er)
