VMware Horizon Community
morrisosu
Contributor
Contributor
Jump to solution

Random "View Composer agent initialization state error"

We are using 4.0.1 build-233023 with linked clones with persistent desktops and we are getting "View Composer agent initialization state error (6): Unknown failure (waited 0 seconds)" errors that occur randomly after provisioning. I have read several articles that indicate restarting the VM will correct this, while this is very annoying it does work.

However, we are receiving this error on VMs after provisioning and after users have already logged into the VM. So if the VM goes to an error state, users get an error stating the desktop is unavailable! A reboot/reset of the user’s VM will correct this, but this is not feasible.

Has anyone found a permanent solution to this?

Thanks so much!

Reply
0 Kudos
1 Solution

Accepted Solutions
BrandonJackson
Enthusiast
Enthusiast
Jump to solution

Food for thought: I removed all the excess junk variables out of the "Run" key and changed my reboot script to wait 30 seconds to run. This time, the desktop refresh had 0 errors (usually i see 1 or 2 with the initial push). One time isn't a trend, but i wanted to throw that out there. The other thing we have changed is decreased the concurrent provisioning for the vCenter server to "1" (just in case this error is due to View Composer getting too busy). I will update if things don't work out in the long run with the above fixes. Thanks!

Brandon

View solution in original post

Reply
0 Kudos
9 Replies
WilliamReid
Enthusiast
Enthusiast
Jump to solution

Try creating a post-sychronization script and add it to the quickprep settings to reboot the VM after being provisioned.

Reply
0 Kudos
morrisosu
Contributor
Contributor
Jump to solution

Well I tried that, following this advice: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101165...

However, this did not appear to help and what gets me is that the error is occurring after a "Ready" state and after a user has already claimed the persistent VM.

Reply
0 Kudos
mholgate
Enthusiast
Enthusiast
Jump to solution

I just started receiving this error after rebuilding my parent VM.I also applied the KB article fix above.

I am noticing an issues when finalizing my parent VM build:

After I re-install the View Agent, during the final restart the parent VM will hang at "Running shutdown scripts" for about 10 to 15 minutes. If I wait it out it does eventually restart. This is also when I started receiving the error on those desktops in th View Manager.

I have checked the event viewer on the parent VM and there is nothing of any consequence..

This one has me puzzled.

Mike... VM, Virtually!!

Mike... VM, Virtually!!
Reply
0 Kudos
mholgate
Enthusiast
Enthusiast
Jump to solution

Well, after realizing that the only real change I made was moving from ThinApp to Microsoft AppV, I started doing some web research and found that there is a problem with the AppV client service and the View agent. I applied this workaround from this website and it solved my issue:

Mike... VM, Virtually!!

Mike... VM, Virtually!!
Reply
0 Kudos
BrandonJackson
Enthusiast
Enthusiast
Jump to solution

We have clients with View 4.0 and View 4.0.1 that have this problem, and they don't have Microsoft App-V installed on the base image. The provisioning process does add an extra reboot with a post-sync script. The only thing the "userinit" key runs is userinit.exe and wssm.exe, so nothing extra there that should cause this. I have not found any other things to try to resolve this.

I am going to clean up the "Run" keys in the registry to see if it is something there that is tripping this up and will report back to this thread if I find out anything.

Brandon

Reply
0 Kudos
BrandonJackson
Enthusiast
Enthusiast
Jump to solution

Food for thought: I removed all the excess junk variables out of the "Run" key and changed my reboot script to wait 30 seconds to run. This time, the desktop refresh had 0 errors (usually i see 1 or 2 with the initial push). One time isn't a trend, but i wanted to throw that out there. The other thing we have changed is decreased the concurrent provisioning for the vCenter server to "1" (just in case this error is due to View Composer getting too busy). I will update if things don't work out in the long run with the above fixes. Thanks!

Brandon

Reply
0 Kudos
morrisosu
Contributor
Contributor
Jump to solution

Good info! I'll give those ideas a try! Where do I set "concurrent provisioning for the vCenter server"?

Reply
0 Kudos
mholgate
Enthusiast
Enthusiast
Jump to solution

Within View Manger, click Configuration, select the vCenter Server and click the Edit link above it. At the bottom of the window that opens choose Advanced. You will see your concurrent settings for vCenter there.

Mike... VM, Virtually!!

Mike... VM, Virtually!!
Reply
0 Kudos
morrisosu
Contributor
Contributor
Jump to solution

Awesome! Many thanks!

Reply
0 Kudos