RyanChristopher's Posts

The registry key applies to both composer and instant clones. VMware probably just referenced the same key instead of creating/using a new one for just ICs. If 60 seconds doesn't work you can also try adding debugging in your script to see the overall time and where you might have delays. We had put down %date% %time% markers to be able to track exactly where things were getting stalled or taking a long time to complete. Our current timeout value is 90 seconds. It usually completes before then but wanted to make sure we had a nice buffer in place. echo %date% %time% Begin task... >> c:\temp\logfile.txt echo %date% %time% Begin step1... >> c:\temp\logfile.txt [commands] echo %date% %time% End step1... >> c:\temp\logfile.txt ... echo %date% %time% End task... >> c:\temp\logfile.txt

We have the same command in our script that along with other commands causing Horizon to time out when provisioning new desktops. We found that with 7.11/7.12/7.13 something changed so that during the provisioning steps there is now something taking place that will at times stall/delay the postsync script with new VMs. Should it go over the 20 second default it will report back failed. 7.10 no issues whatsoever. We ended up increasing the timeout limit to 60 seconds. Increase the Timeout Limit for ClonePrep Customization Scripts (vmware.com) You can easily determine this by including a date/time marker in your postsync script (echo %date% %time% >> c:\temp\pslogfile.txt) at the beginning and end of the script.

Will also add in addition to creating the C:\Windows\Temp\VMware folder that we had to extend the timeout as well on 7.13 from the default 20 seconds. For some reason the new post sync process takes longer on 7.13 (might also apply to 7.11/7.12) with the exact same script. Increase the Timeout Limit for ClonePrep Customization Scripts (vmware.com)

We are using Instant Clones on 7.12 so Composer is not part of the equation here. Nor are double-quotes part of the issue (the Connection Server UI won't even let you save using single or double quotes). That said, we found that with 7.12 (possibly also 7.11) we have an issue if deleting the C:\Windows\Temp\VMware folder and then pushing out a new image using Guest Customizations. We delete this folder (along with any other files/folders under c:\Windows\Temp) as part of our image cleanup when sealing our gold image. We have been doing this in all previous Horizon versions. Since the folder no longer exists, it appears the VMware Agent is unable to copy scripts to this location and process them. As looking for a workaround, initially we were creating the folder and manually copying the script to this folder after cleanup and then shutting down to take a snapshot. Since then we realized we can just make sure the folder C:\Windows\Temp\VMware exists and then everything works as it did with 7.10. To us this seems like a bug within the Agent since it should have logic to create this folder if it does not exist.

So this is what worked for me as a workaround. Hope this can help anyone else out. I had to create the VMware folder under C:\Windows\Temp and copy our postsync script (postsync.cmd) into this location (C:\Windows\Temp\VMware). Once the script was there the desktop build completed successfully. To add I kept the desktop pool Guest Customization post sync setting pointed to c:\postsync.cmd (although I'm guessing I could have just pointed directly to Windows\Temp\VMware). Seems like a bug to me where it's not moving the script to C:\Windows\Temp\VMware as it has done previously.

Still getting the same error. Instant Clone agent initialization state error (19): Failed to execute postsync script (waited 5 seconds) Here is the exact setting I am using. c:\Windows\System32\cmd.exe c:\postsync.cmd Tried moving the postsync.cmd script to another folder, C:\Scripts - same error Tried using a new empty script test.cmd under both C: and C:\Scripts - same error As an aside, the UI will not allow a double or single quote in the post-synchronization name field (or other fields). Current SR# for reference is 20119373304

I am not using double quotes in the UI under Guest Customization for the desktop pool settings. Post-synchronization script name: c:\postsync.cmd Had no issues with this previously so can assume this is the known bug in 7.11 and 7.12 you referenced. I will try the workaround and post results. For the wrapper script should this be another script calling the postsync script? Or the cmd.exe executable calling the script as you called out in another post? c:\wrapperscript.cmd (which calls c:\postsync.cmd) c:\Windows\System32\cmd.exe c:\postsync.cmd I opened up a SR the other day but the tech has not responded with next steps, information, or workarounds at this point. Do you have a specific bug ID or internal note on this I can reference in my SR? VMware will also want to update documentation for Horizon 7.11 and 7.12 if the log file location has been updated since it still states the following: ClonePrep Script Logs ClonePrep writes messages to a log file. The log file is C:\Windows\Temp\vmware-viewcomposer-ga-new.log.

Thank you for the new log file location and information. We are using a .cmd file for our post sync script and have it set to "c:\postsync.cmd" under Guest Customizations. It has always worked until upgrading to 7.12. I did try placing this in another folder (c:\Scripts\postsync.cmd) and also tried using a blank/empty test.cmd file. This had no effect. Other observations I've found and from the log file. Looks like it's not able to secure the post sync file. In 7.10 the file would be moved from it's original location C:\postsync.cmd to C:\Windows\Temp\VMware\postsync.cmd along with the log file(s). Since the log files have now been moved to ProgramData can we confirm where the postsync.cmd script should be moved to when secured in order to run with Horizon 7.12? It appears our postsync script is not secured by moving to another location. It is still in the original location C:\. Since we're not finding it where it was under 7.10 C:\Windows\Temp\VMware or under C:\ProgramData\VMware and it's still present in the original location I can only assume this would be a possible explanation for issues here. 2020-04-23T12:56:39.155-04:00 WARN  (0BD8-083C) <2108> [vmware-svi-ga] svmga::common::windows::registry::ExistingRegKey::ReadDwordValue(): CloneMachinePasswordChanged Does Not Exist 2020-04-23T12:56:39.155-04:00 WARN  (0BD8-083C) <2108> [vmware-svi-ga] svmga::common::windows::registry::ExistingRegKey::ReadDwordValue(): ChangeCloneMachinePassword Does Not Exist 2020-04-23T12:56:39.155-04:00 WARN  (0BD8-083C) <2108> [vmware-svi-ga] svmga::common::windows::registry::ExistingRegKey::ReadDwordValue(): CloneCustomizationCompleted Does Not Exist 2020-04-23T12:56:39.155-04:00 DEBUG (0BD8-083C) <2108> [vmware-svi-ga] svmga::core::windows::Guest::OkToCompleteCustomization(): No flags set, completing customization 2020-04-23T12:56:39.155-04:00 DEBUG (0BD8-083C) <2108> [vmware-svi-ga] svmga::core::windows::Guest::CompleteCustomization(): Completing Clone Customization... 2020-04-23T12:56:39.155-04:00 WARN  (0BD8-083C) <2108> [vmware-svi-ga] svmga::common::windows::registry::ExistingRegKey::ReadDwordValue(): PostCustScriptSecured Does Not Exist 2020-04-23T12:56:39.155-04:00 DEBUG (0BD8-083C) <2108> [vmware-svi-ga] svmga::core::windows::Guest::RunPostCustomizationScript(): Failed To Execute Post-Customization Script. It Was Not Secured 2020-04-23T12:56:39.155-04:00 DEBUG (0BD8-083C) <2108> [vmware-svi-ga] svmga::core::windows::Guest::SetCustomizationState(): Set guestinfo.clone.CustomizationState to error 2020-04-23T12:56:39.155-04:00 DEBUG (0BD8-083C) <2108> [vmware-svi-ga] svmga::core::util::NotifyViewAgent::MarkCustomizationFailed(): Set NotifyVdmStatusValue to CustomizationFailed(5) 2020-04-23T12:56:39.170-04:00 DEBUG (0BD8-083C) <2108> [vmware-svi-ga] svmga::core::windows::Guest::CustomizeClone(): CompleteCustomization Failed 2020-04-23T12:56:39.170-04:00 DEBUG (0BD8-083C) <2108> [vmware-svi-ga] Support::GetTotalCloneCustomizationTime(): Result: 0 2020-04-23T12:56:39.170-04:00 DEBUG (0BD8-083C) <2108> [vmware-svi-ga] svmga::core::windows::Guest::CustomizeClone(): Total Clone Customization Time: 12781ms 2020-04-23T12:56:39.170-04:00 WARN  (0BD8-083C) <2108> [vmware-svi-ga] svmga::common::windows::registry::ExistingRegKey::ReadDwordValue(): CloneCustomizationCompleted Does Not Exist 2020-04-23T12:56:39.170-04:00 DEBUG (0BD8-083C) <2108> [vmware-svi-ga] svmga::core::windows::Guest::CustomizeVM(): Clone Customization Failed 2020-04-23T12:56:39.733-04:00 ERROR (14F4-14F8) <Main Thread> [wsnm_jms] View Composer agent has failed customization

We also just upgraded to Horizon 7.12 and are having the same issue running a postsync script. We are also not seeing the expected log file. Instant Clone agent initialization state error (19): Failed to execute postsync script (waited 5 seconds) Confirmed the postsync script is (still) on the master image. Guest Customization settings for the desktop pool have not changed. This was working without issue on Horizon 7.10.

@RandyBrown For testing I actually opened up as many apps and browser tabs (both IE/Edge) as possible. Again with 8GB RAM it was hard to get over 50% usage here so perhaps we aren't running into this issue. I can back our image back down to 4GB and test again. We had bumped up RAM for our pilot to rule out some other issues we were having with performance degradation when power users would have all their apps/browsers open. If we test reconnect times with nothing running and just at the desktop we'll see around ~10 seconds, up from our Windows 7 pool with ~5 second reconnect times. Again, this using PCoIP/BLAST. Wanted to also mention we saw improvements when removing Imprivata from our image (or disabling processes/services temporarily) and reconnecting. Not sure it this is because of Imprivata/VMware/Windows10 but we have a case open with Imprivata now to investigate further. Will post any updates here.

Seems we're also having this issue with our Windows 10 VDI pools taking approx. 10 seconds to display the desktop (but have seen upwards to 20 seconds or even longer). Our Windows 7 desktop pools average around 5 seconds. Same Horizon version installed on both (7.9). Both PCoIP and BLAST protocols having the issue (PCoIP does take a tad bit longer however). We are running 8GB RAM in our Win10 pools currently so not sure if RAM is an issue for us. Perhaps it does come into play in some cases. Will also note that this is also observed on an initial connection--although we don't "notice" it as much since we're conditioned to wait for a bit longer here. If we connect/reconnect using RDP it's about 2 seconds.

As an update, changing the settings under the VMware global settings Forcibly Disconnect Users to a high number as recommended in the Teradici release notes for 5.2.x does not work with our zero clients. Still getting disconnected right at the 20 hour (1200 minute) mark after setting this to 10,080 minutes (7 days). Looks like the only workaround may be to modify the ADAM DB per the VMware KB article. But that only applies for connections going through the Connection Servers (and not, for example, a Direct Connect Plugin connection as some have mentioned).

Any further updates on this? Specifically if Teradici will be releasing an updated firmware to support this natively without modifying the ADAM database on the Connection Servers? We are running Horizon 7.0.3 with Tera2 firmware 5.3 and have this issue (without the workarounds 1) ADAM DB 2) Set High Number in VMware global settings applied). Edit: I did see a note on Teradici's support site that with firmware 5.2/5.2.1 this is reported as an issue. The workaround is to set the VMware global settings value Forcibly Disconnect Users to a high number (from never) but not sure if that works as was indicated in a post above.

We've successfully deployed the Imprivata Agent to our virtual desktops as a layer using Unidesk (www.unidesk.com). We actually have both the type1 and type2 agents in separate layers, along with the Imprivata Epic Connector in another separate layer (so in all 3 separate layers). It allows us to layer just one time and then apply to desktop pools as we see fit. For example, for FastUserSwitching workflow we can deploy the type2 agent to our ExamRoom desktop pool, but for other desktop pools deploy the type1 agent. We can also easily add the Imprivata Epic Connector to desktop pools with Hyperspace in them. I'd definitely check out this solution, especially the forthcoming 4.x version with VMware support, if you are constantly updating your Gold/Master images and/or trying to have all of your applications individually layered. As an added benefit, OS updates are quite painless now (no more Patch Tuesday nightmares). Here's a really good write up for what Unidesk can do vs. AppVolumes: Comparing Unidesk and VMware App Volumes This isn't to say that AppVolumes isn't a good choice if you're licensed for it and are using it for specific use cases--we've just found that Unidesk works better since it provides both in-guest/at logon (Elastic Layering) and out-of-band/pre-boot layers. Pretty much we can throw any apps/drivers/stacks at Unidesk and it will work.

I'm not sure what you mean by workarounds. Most of the Already Used issues we had before have been resolved using the GPOs to only allow the user to logoff of the VM from the Start Menu. I will say, though, that I still run across this issue from time to time, just not as often. I'm not sure if there's still another reason why this issue shows up but at least it's not as noticeable as before. It would be nice for VMware to add an option that would determine desktops in the Already Used state and automatically perform tasks on it (e.g., refresh, recompose, delete, etc.). Perhaps in a future release.

Thank you for your explanation as to why this was happening. We too were having issues along the same lines as you. If I can make a quick suggestion that might work better in some cases, rather than writing/using a PowerCLI script and scheduling the refresh of these VMs. For our non-persistent automated linked-clone desktop pool, we simply applied a GPO that disables the ability to shutdown the VM by the user. I noticed that you already have a GPO to make the default option on the Start Menu "Logoff", so why not take this a step further and also enable Remove and prevent access to the Shut Down, Restart, Sleep, and Hibernate commands from the Start Menu as well? That way the user won't even have the ability to shutdown the VM in the desktop pool in the first place. It may not work for everyone, and depends heavilty on how you have GPOs setup in your AD environment, but might be another option.

@BMC2: Not sure if you were able to resolve this or not, but to run powershell via Task Scheduler you need to include the switch -ImportSystemModules in the Add arguments (optional) field. The command would look something like: "PowerShell" -ImportSystemModules "c:\PSScripts\test.ps1" There might be another way, but that's what we did to resolve the issue you described. If you look at the shortcut to your PowerShell console it should have both -ImportSystemModules and -NoExit as arguments, so that's why the modules are available in the console. Hope that helps.