VMware Horizon Community
LukaszDziwisz
Hot Shot
Hot Shot

BSOD when provisioning with AppVolumes agent 2.15

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,

25 Replies
Jketels
Contributor
Contributor

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.

Reply
0 Kudos
LukaszDziwisz
Hot Shot
Hot Shot

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

Reply
0 Kudos
sjesse
Leadership
Leadership

  • 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

Reply
0 Kudos
LukaszDziwisz
Hot Shot
Hot Shot

I'm always provisioning with local administrator account and not using domain joined account.

Reply
0 Kudos
Douglas42Adams
Enthusiast
Enthusiast

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 ,

Reply
0 Kudos
LukaszDziwisz
Hot Shot
Hot Shot

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

Reply
0 Kudos
Douglas42Adams
Enthusiast
Enthusiast

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.

Reply
0 Kudos
LukaszDziwisz
Hot Shot
Hot Shot

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

Reply
0 Kudos
LukaszDziwisz
Hot Shot
Hot Shot

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)

Jketels
Contributor
Contributor

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!

Reply
0 Kudos
Jketels
Contributor
Contributor

I can confirm that this solution works!
Thanks LukaszDziwisz​ !

Reply
0 Kudos
LukaszDziwisz
Hot Shot
Hot Shot

I'm glad it works for you too.

Reply
0 Kudos
babagunoosh
Contributor
Contributor

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.

Reply
0 Kudos
babagunoosh
Contributor
Contributor

Just realized I placed the key in svservices and not svdriver. Going to add this and test. Hope this is it!

Reply
0 Kudos
babagunoosh
Contributor
Contributor

SUCCESS! Thank you so much LukaszDziwisz. It helps to follow the instructions exactly.

Reply
0 Kudos
LukaszDziwisz
Hot Shot
Hot Shot

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

Reply
0 Kudos
Anobix67
Enthusiast
Enthusiast

LukaszDziwisz Just wanted to say thank you for this, was banging my head against the wall looking for an answer and your method worked.

Reply
0 Kudos
pchapman
Hot Shot
Hot Shot

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.

Reply
0 Kudos
Skocza
Enthusiast
Enthusiast

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

Reply
0 Kudos