lI am experiencing the same thing...
What have I tested so far and did not work:
- Windows 10 1709 (non-domain)
- Windows 10 1803 (non-domain)
- With SSL and without between agent and av-manager
- VMFS5 and VMFS6 for the template
- Enrolling the appstack template on different volumes/luns/NFS
- Full rights for the service accounts on all areas
- Only using BIOS for the Virtual Machine
- Mounting with ESXi and vCenter
What did work:
- Manual attach the appstack template to a Virtual Machine ( not in provisioning mode )
Reboot without BSOD
Same situation initiated from the av-manager results in BSOD.
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
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 ).
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
2 people found this helpful
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
- net stop svservice
- net stop svdriver
Add a registry key to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\svdriver\Parameters
- "OptimizationLevel" REG_DWORD 0
Restart the Agent with
- net start svdriver
- net start svervice
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'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!