alienjoker's Posts

‌Hi again, Do your images have Internet Connectivity and/or do they use a proxy? This does seem to be a deep routed OS related problem as opposed to VMware so you may struggle for an answer here. The last thing I can suggest is to run the Microsoft System Update readiness tool to validate what may or may not be missing from the image in the hope that it fixes any inconsistencies in the build:- https://www.microsoft.com/en-gb/download/details.aspx?id=3132 if i remember correctly, you will need to have started the Windows Update service before running but be sure to disable It again before sealing the image (assuming non-persistent desktops are in use) Best of luck Andrew

Hi Phillip, You're not wrong, I think I have logged a record number of GSS support tickets against both mentioned products but in fairness, VMware have been pretty responsive and turned things around. I've had countless issues in a recent migration that I've been working on and whilst the environment is still subjected to a few "issues", I'm pleased to report that its stabilised since AppVolumes 2.11.1 (yes thats a private .1 release) and 7.0.2. Migrating from VMware view 5 to Horizon View 7 (Part 2) – ACM Computers On paper and in terms of marketing, it looks like a great set of products, but behind the scenes there is still a long way to go. I'm prepared to listen to their story as it does sound convincing but it does come at the cost of many hours of effort and persistence. Cheers Andrew

Hi pchapman, As the blogger behind the article you reference, rest assured, I know VMware are working hard to rectify this basic Enterprise feature at risk of customers moving to a competitor product. As soon as I have visibility of the fix I will be sure to update. Many thanks Andrew

Hi Gary, As per the previous post, it is recommended that you disable tunnelling on the Connection Servers (otherwise you're tunnelling internally too, which will mean if you patch the View Connections, you will sever desktop connectivity). You will then need to change your Firewall rules to permit access from the DMZ Access Point appliance to the LAN Subnet hosting the VDI clients on TCP/UDP 4172. To do this, replace the following rule you have defined: 4172 TCP and UDP to stc-vmconn-01.stc.ricplc.com and UDP 4172 back with 4172 TCP and UDP to VDISubnet/XX (replace /XX with whatever the subnet mask is i.e. /23 or /24) and UDP 4172 back Hope that helps! Cheers Andrew

Hi, I think I have found a solution to the problem. Take a look at my blog article on how it was resolved for a client of mine I'm working for. High CPU TrustedInstaller in a VDI Environment – ACM Computers Let me know if you get any success from the recommendation. Best regards Andrew

Thanks for the update. I have a few considerations in mind regarding what could be causing this and will report back with my findings shortly. In some situations I am able to recreate the problem and in others I am not. The only differing factor is the specific Appstacks that are being mounted, so this may certainly be playing a part.

Hi, We're seeing the exact same problem, components as follows:- AppVolumes 2.11 Horizon View 7.0.2 Agent We have the Trend Deep Security Appliances (host based AV). Our analysis so far has shown that if a user is sent a remote control request (which installs an small agent temporarily), the launch of this application within the user session then triggers the execution of TrustedInstaller.exe and will after about 10 minutes, peg completely out to a single vCPU (at 100%, or 50% in the case of a 2vCPU machine). Have you reviewed the contents of the following folder to determine the action the TrustedInstaller is trying to take? C:\Windows\Logs\CBS\CBS.log 2017-02-08 16:49:39, Info                  CBS    Scavenge: Starts 2017-02-08 16:49:39, Info                  CSI    00000009@2017/2/8:21:49:39.947 CSI Transaction @0x3d0cb0 initialized for deployment engine {d16d444c-56d8-11d5-882d-0080c847b195} with flags 00000002 and client id [10]"TI6.0_0:0/" 2017-02-08 16:49:39, Info                  CBS    Scavenge: Begin CSI Store 2017-02-08 16:49:40, Info                  CSI    0000000a Performing 1 operations; 1 are not lock/unlock and follow:   Scavenge (8): flags: 00000017 In our case, as you can see above, it seems as if what is known as a "Scavenge" takes place, but will run indefinitely. The only way we can then correct a faulting machine is to change the "TrustedInstaller" service to "Disabled" and kill the outstanding executable. We ran the System Update readiness tool from Microsoft to check there were not corrupted files, but the log came back clean so it doesn't look like there are any outstanding updates that the system believes it should be going off to process. To add, Windows Updates etc are all disabled as part of the OSOT tool being run. Does anyone know any more specifically about the Scavenge process and is it potentially linked to the OS believing that AppVolumes and the subsequent mount of a stack has altered the OS file consistency and therefore feels the need to check the files are not tampered with? Many thanks Andrew

Thanks, this is a pretty basic requirement for any Enterprise organisation and I'm surprised it has taken so long for VMware to consider implementing this. Most organisations use some method of folder redirection and therefore omitting something so core and key to application behaviour is a big show stopper for mass adoption of application delivery. I can't imagine having to re-educate users that they must click "File/Open" every time they want to open a file that resides on a network share or for that matter, reconfigure everyones Horizon Client "Sharing" and adding each and every mapped drive. In any case, if the network location is in fact a UNC path, you aren't currently even able to add that as something that will be accessible via the published application as the Add button only offers the presence of fixed drive letters. For the uptake of cloud based application delivery, this is potentially a big show stopper for many who rely on such basic functionality.

No, the image is Windows 7. Good news though - we have upgraded the Horizon agent to version 7.0.2 and the screen flashing has now been resolved despite not yet getting any concrete information as to what changed to fix it. (the SVGA driver did change up from 8.15.1.46 to 8.15.1.48 in the release step).

Hi, Have you considered using native Active Directory to control Logon Hours and apply the group policy to the OU within which the Pools Computer objects are created? You can even force disconnect the users if their connection is active and you want them to immediately disconnect outside of the hours for which the desktops should be accessible. Cheers Andrew

Just to double/triple check, VMs historically only clear down disposable disks under the following events (unless its changed in Horizon 7) Rebalance Refresh Recompose A reset of the VMs won't necessarily clear the issue. If you could try refreshing them as opposed to resetting them, you might have more luck. Thanks Andrew

Hi Rick, Yup, lots of head scratching at VMware as you cannot turn down the VDM logging lower than what its already set at, yet the TP-AutoConnect logs grow exponentially at around 500KB every 10 minutes. I worked it out that over a 7 day Window, that with 1000 users, this will consume circa 500GB of unplanned capacity, not to mention the unwanted IOPs. I have the following SR open: 16260979110 A quick test would be to free up some space (no more than 10mb needed just get a session back up again) on the disposable hidden drive and then see if you can reconnect to a disconnected session. What you'll find is that once the logs grow and the drives fill up again, the PCoIP session will disconnect. As a workaround, I've now dumped using disposable disks, bumped up the size of the Master template to compensate for the relocated Pagefile,sys until VMware come up with a way to disable logging. Not ideal as we're still getting the hit on capacity and IOPs until the desktops are refreshed on logoff. Cheers Andrew

Hey Matthew, In addition to all the above problems, we have now an entirely new list to work through with VMware, one of which being the issue with Zero Clients not getting the correct resolution and/or crazy black screen flashes during client logon. Did you ever get any recommendations or hotfixes to help with your display issues? We've tried changing out our pcoip_server_win32.exe only to find that we're then limited to a single monitor, so had to roll that back. At the moment, we've dropped 3D Rendering (disabled) instead of Software at the pool configuration to avoid one of the issues, but this introduce a problem with Aero now not functioning as Windows 7 cannot detect the non 3D rendered SVGA driver as compatible with its WDDM needs! I've seen Teradici have a number of similar Forum posts relating to display issues on Horizon 7.0.x.but with no solid fix, despite attempts to use various FW versions. Cheers Andrew