Hello Everyone,
Does anyone encounter often BSOD while provisioning with with APpVolume agent 2.15. Here is what happens in my case. We are using Windows 1809 LTSC, the packaging machines are clones of the Base image stripped down to the minimum. I'm trying to provision Departmental appstacks and consolidate as many common Departmental apps as I can. Sometimes after installing an application I need to reboot the machine while still capturing and when that happens I'm getting BSOD and have to cancel provisioning and start over again. It appears to be happening on many different/random occasions with different application. If I don't reboot at all and simply after being done complete provisioning the machine reboots fine and I can complete the process. If I provision on the same packaging machine with downgraded agent 2.14 I don't see that problem however don't want to go that route either because AppVolumes agent 2.14 doesn't support windows 1809.
Any help would be appreciated,
lI am experiencing the same thing...
What have I tested so far and did not work:
What did work:
This is so strange….
I think it has something to do with the svdriver on the OS and te connection with the av-manager
If someone got and solution, please share!
For know I will use the 2.14.2 agent, that works.
I agree, it looks like agent 2.14.2 works however based on compatibility matrix 2.14.2 does not support WIndows 1809. Last week I worked with support on a different issue with one of the appstacks and was told that I should never do 2 things:
1. Provision with agent older than is installed on the master image
2. That 2.14.2 does not support windows 1809
3. Provision appstacks on different build packaging machine than my master image. For example if you have appstacks provisioned on 1607 build I should not use them with pools using Windows 1809 - although I know it appears to be working but they say that it is not supported
For now we are trying to install apps and not reboot machine in meantime and it appears to be working but I guess I will open a ticket and see what VMware has to say about it
Full rights for the service accounts on all areas
As any one tried full local administrators instead of domain accounts when provisioning. We saw this in older versions which is why we stopped using domain accounts when provisioioning appstacks where ever possible. We are just now trying 2.15 so I can't test this just yet, but wondered if it might help
I'm always provisioning with local administrator account and not using domain joined account.
Not 100% of the Time. JUST when i am giving a demo to our Helpdesk - my Manager and CIO :smileysilly:
I've seen it about 5 times thus far.
We are on 2016 LTSC/B ( 2019 LTSC would not register with KMS )
We are on 2.15 APP VOL - using Writables and UEM.
One of the times we ran into it was Installing Microsoft Dynamics Great Plains.
might sound stupid.. but i think it was because i was forgetting to goto Properties and UNBLOCK.
GP's is like 7 individual installs to run. The ZIP files had not been 'unblocked' prior to unpacking ( diff employee ) and thus created a Ton of EXE's..etc that were not unblocked.
After we unblocked them the BSOD seemed to go away.
in powershell you can run " ls -Recurse | unblock-file " to unblock all files in a subdirectory and anything 'below'.
( probably not the issue your having.. but just throwing it out there ).
thanks ,
We are APpVOlumes 2.15 with writable profile only and using UEM to supplement writable. Even if I start provisioning and don't install anything and simply reboot it happens as well so to me it is not application related.
FYI, for 2019 LTSC we could not get KMS to work until I found an article that with 2019 LTSC only Active Directory activation is supported. Once we uploaded the key in KMS for Active Directory it is activating just fine. I forgot the article url but it works for us since then
Thanks.. yeah saw that as well.. the A/D activation.. however i started reading that people's Windows 7 machines started to NOT register after they brought their KMS up to 2019.
We still have a ton of Win 7 Machines so that would not bode well for us.
sorry getting this a little off topic.
That's fine, we have tons of win 7 as well mixed old Unidesk VDI and physical PCs and did not notice that but I also uploaded Win 7 key to AD activation
I just got off the phone with support and it appears that they knew exactly what to do. Here is the procedure that needs to be done on any packaging machine that faces the issue:
Power on provisioning machine , stop the Agent on the provisioning machine with
Add a registry key to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\svdriver\Parameters
Restart the Agent with
Restart PM ( At this stage you can take a snapshot of the provisioning machine so that it can be used in later as clean machine)
Yesterday I downgraded the environment to 2.14.2...
But with this news I will upgrade it back to 2.15 🙂
Because I need the 1803/1809 support for Windows 10.
Keep you posted if the solution works!
I can confirm that this solution works!
Thanks LukaszDziwisz !
I'm glad it works for you too.
I was hopeful that this would resolve my issues, but sadly I still receive the BSOD when restarting...
What version of Tools, View Agent and UEM (If you use it) do you happen to have installed? Perhaps those have contributed to your success and our failure.
Just realized I placed the key in svservices and not svdriver. Going to add this and test. Hope this is it!
SUCCESS! Thank you so much LukaszDziwisz. It helps to follow the instructions exactly.
Great glad I could help. Also, I was told that the packaging machine should not have View Agent nor UEM agent installed. My packaging machines include only VMtools, AppVol agent, Java, Chrome and Office 2016 for any software needing to build addons/plugins
LukaszDziwisz Just wanted to say thank you for this, was banging my head against the wall looking for an answer and your method worked.
Thanks! I'm deploying 2.15 with 1809 for a customer, and of course all of my test appstacks worked perfect yesterday. Today, during the training session, they failed every single time with a BSOD. Quite embarrassing, especially considering the other 2.15 bug regarding the problem with MSI's and the Windows patch.
Guys, have you tried to update any appstack with this version of appvol agent 2.15 + applied that registry fix ("OptimizationLevel" REG_DWORD 0) ? Since I have applied it all, it looks that appstack is not fully loaded on my capture machine and its really slow to load the machine after restart. I am still investigating what it could cause, just trying to find out if anyone of you experinced teh same. Thanks