coreyberla's Posts

VMWare just release this statement   Notice: On December 14, 2021 the Apache Software Foundation notified the community that their initial guidance for CVE-2021-44228 workarounds was not sufficient... See more...
VMWare just release this statement   Notice: On December 14, 2021 the Apache Software Foundation notified the community that their initial guidance for CVE-2021-44228 workarounds was not sufficient. We believe the instructions in this article to be an effective mitigation for CVE-2021-44228, but in the best interest of our customers we must assume this workaround may not adequately address all attack vectors. We expect to fully address both CVE-2021-44228 and CVE-2021-45046 by updating log4j to version 2.16 in forthcoming releases of vCenter Server, as outlined by our software support policies. VMSA-2021-0028 will be updated when these releases are available. In the interim, we will be updating this Knowledge Base article with revised guidance to remove all JndiLookup classes per Apache Software Foundation guidance. Please subscribe to this article to be informed when updates are published.
Does anyone know the status of App Volumes? I'm assuming that VMWare is indicating it's not impacted because it's not listed as a Horizon fix, but I did notice log4j components on the App Volumes Man... See more...
Does anyone know the status of App Volumes? I'm assuming that VMWare is indicating it's not impacted because it's not listed as a Horizon fix, but I did notice log4j components on the App Volumes Manager. Can anyone confirm?
Hi all, I'm trying to use group policy to log off disconnected users rather than creating a bunch of separate pools. Terminal Services Group Policy Settings for Sessions When I use the ab... See more...
Hi all, I'm trying to use group policy to log off disconnected users rather than creating a bunch of separate pools. Terminal Services Group Policy Settings for Sessions When I use the above group policy setting on a test VM, RDP to the VM, and run tsdiscon, I get the expected behavior.  When I attempt the same thing on a VM through PCOIP (whether I run tsdiscon or simply disconnect the session), I don't get the expected behavior.  I noticed that when I run "query session" on the VM through PCOIP, it says I'm connected to the console, and in the documentation for the above group policy setting, it says that it doesn't logoff console sessions.  Am I misunderstanding what the above group policy settings are supposed to be used for, or am I getting connected to console when I'm not supposed to. I'm running Horizon View 5.3 with Windows 7 and Active Directory 2003.  Thanks in Advance.
Windows 7 and 8 are also offered in 32 bit versions.
In your package.INI for the entry point, commandline are you using the argument --no-sandbox after chrome.exe. I believe you need that for thinapp to work.
Correct: Certain operating systems and applications are not supported by ThinApp.  16‐bit or non x86 platforms such as Windows CE  64‐bit applications running on 32‐bit Windows operating s... See more...
Correct: Certain operating systems and applications are not supported by ThinApp.  16‐bit or non x86 platforms such as Windows CE  64‐bit applications running on 32‐bit Windows operating systems  16‐bit applications running on 64‐bit Windows operating systems
FYI my virus scanner is configured to not scan the thinapp share on both the client and server.  It is also configured not to scan the sandbox on the client.  I'm using vShield.
I have Microsoft Office 2010 installed natively on my image.  I then have a "dummy" thinapp that launches Office (in order to use applinks to programs like adobe acrobat).  The issue that I've se... See more...
I have Microsoft Office 2010 installed natively on my image.  I then have a "dummy" thinapp that launches Office (in order to use applinks to programs like adobe acrobat).  The issue that I've seen is that launching apps through thinapp takes a fair amount of time longer than natively. Word - Native: 0.4 seconds, Thinapp 1.5 seconds Outlook - Native 1.3 seconds, Thinapp 3.8 seconds I've read that Thinapp should have very little overhead. Tweaks I've made to Package.ini AutoStartServices=0 Tried both merged and writecopy Tried Fast and None for compression Removed applink for testing purposes I tried streaming the thinapp from local storage and network with no change in performance.  The sandbox is on local storage and I've verified that appdata isn't redirected.  I also attended to put Full isolation on the %appdata% and %local appdata% folders. Thanks in advance for any ideas. Corey
How do most people deal with this, seems like a really disruptive issue.
Hi, Recently I've noticed in the morning that many of my thinapps crash / have crashed (APPCRASH stackhash).  I believe this is caused from my backups which take a VM and VSS snapshots stunnin... See more...
Hi, Recently I've noticed in the morning that many of my thinapps crash / have crashed (APPCRASH stackhash).  I believe this is caused from my backups which take a VM and VSS snapshots stunning the machine for too long thus breaking the connections from the thinapps.  Currently my thinapps are hosted on a single windows file share (non-redudant).  I've read that VMware recommends placing thinapps in a DFS namespace that has multiple targets.  My preliminary testing of that setup had little success.  I would launch the thinapp from the DFS link and then kill whichever server it connects to causing the thinapp to fail.  I'm guessing this is the case because DFS merely points the client in one direction, then when the server fails it is up to the client to reconnect to the next location.  I've read up on Failover Clusters in 2008R2 and it seems that there may be similar issues.  I was interested in transparents failover in server 2012 with SMB 3.0, but it requires Windows 8 clients (and I'm using Windows 7).  Any suggestions would be greatly appreciated. Corey