Recently I upgraded to Storefront 3.9. Setting the default Website no longer works in that verion:
Disable the setting and enable it again won’t make any difference. That setting configures the web.config file in the root folder of IIS (c:\intetpub\wwwroot\web.config). As a workaround you can configure it in the web.config by yourself. Just add the following config:
<?xml version=”1.0″ encoding=”UTF-8″?>
<httpRedirect enabled=”true” destination=”https://FQDN/Citrix/StoreWeb” childOnly=”true” />
Replace the destination value with your Website of the store and you’re done.
Back in 2014 I posted about these z@ tmp files that are sometimes created by Adobe Acrobat (or Reader) in the temp Folder and cannot be deleted anymore afterwards because they are still in use (see post here).
Adobe finally solved the issue in Adobe Reader 11.0.14, released in January 2016. See the release notes here: http://www.adobe.com/devnet-docs/acrobatetk/tools/ReleaseNotes/11/11.0.14.html
When you migrate to Storefront 3.0, you probably will see that the customized delivery Group Icons are gone. There’s an Powershell command that brings those icons back, just run it on the Storefront Server:
& ‘C:\Program Files\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1’
Disable-DSStoreSubstituteDesktopImage -SiteId 1 -VirtualPath /Citrix/Store
Note that you might have to Change the paths according to your Installation.
…yes, that’s the message I got after clicking on the Windows symbol that appeared in my system tray:
That confirms the statement of a free upgrade, although it’s time limited (I believe 1 year). Today I read that Win 10 would be delayed and will be released for public end of August. Let’s see….
Update 8.6.15: Windows 10 will be available end of July….
In case you need to check if you run in legacy graphics mode, this is how you can do it by command line:
wmic /namespace:\\root\citrix\hdx path citrix_virtualchannel_graphics get /value
Look for Policy_LegacyGraphicsMode=TRUE. If it’s true, legacy graphics mode is enabled.
Yes, Microsoft Ignite (http://ignite.microsoft.com) is finally starting in a few days in Chicago! I’m looking forward to meeting you guys over there! See you soon….
Recently we upgraded from XenApp 7.5 to 7.6 and figured out that the logon experience is worse with 7.6 when starting a published application (i.e. Internet Explorer).
In the meantime, Citrix published a hotfix (ICATS760WX64009) that solves the issue: http://support.citrix.com/article/CTX142036
It’s even a bit faster compared to 7.5.
There is a bug with the App-V 5.0 SP3 Sequencer that has just been release some days ago. When you try to install the MSI of a created App-V package created by the SP3 Sequencer, the installation only works when you run the MSI installation in an elevated cmd (start cmd.exe with “Run as Administrator”). If you deploy your apps with SCCM, you’re usually not affected when you run the installation by the system account.
The following error messages are shown when you install the msi without elevated cmd:
I created an mst that fixes the issue. Do the following steps to apply the fix :
- Download the mst that fixes the issue: http://www.notmyfault.ch/downloads/AppV5_SP3Fix.zip
- Extract the mst file and copy it into the same folder as your msi file
- Run the following command:
msiexec /i YourAppvPackage.msi TRANSFORMS=AppV5_SP3Fix.mst
If you want to run it unattended, add /qb as parameter. Make sure your current directory is the one that contains the msi/mst or just add the full path to your msi and mst. Don’t rename your msi, use the original name that has been created by the sequencer.
You can also permanently apply the transform (mst) to the msi with Orca.
The root cause of the issue is a changed setting in the MSI. The custom actions responsible to publish and remove the App-V package won’t run under the local system account with full privileges (no impersonation)
The mst I created changes that configuration back so that these custom actions run under the local system account with full privileges (no impersonation) as it was prior to SP3. This change is done by changing the above marked type values from 1025 to 3073.
I bought the new GoPro Hero 4 Black edition camera in order to make some recordings during my Australia trip that will take place the whole January 2015. After installing GoPro Studio, I observed a constant high CPU usage (20-50%) caused by WMI Provide Host. That high CPU usage was caused by GoPro Importer. It’s a startup executable that constantly checks if the GoPro cam has been plugged into the computer. After having removed it from the startup list, the issue disappeared.
There is a known issue when you publish an App-V 5.0 SP2 package user-based. The issue will be seen when it’s published to roughly ~250 users. This can be observed in the eventlog:
Part or all packages publish failed.
Please check the error events of ‘Configure/Publish Package’ before this message for the details of the failure.
The issue happens because every user that got the app published has been added to the ACL of the published App-V package below c:\programdata\app-V reaches its limit (~250 entries) and therefore the whole publishing mechanism doesn’t work properly anymore. The reason is the PSAC feature (Package Store Access Control) that is depreciated and won’t exist anymore in App-V 5.0 SP3 that will be released soon. So SP3 will fix the issue. In the meantime, the following workarounds exist:
- Publish the app globally and not user-based
- Delete the cache
- Run a scheduled script that will reset the permissions on the folder
Thanks to Sebastian Gernert who posted about the issue (it’s in German): http://blogs.msdn.com/b/sgern/archive/2014/10/17/10565434.aspx