[Weird OneDrive upgrade issues (multiple builds showing in C:\Program Files (x86))]

As usual, thanks again, Rob. I have no idea how the hell it happened, but in my current Platform layer, the entire C:\Program Files (x86)\Microsoft OneDrive folder was, in fact, in there. I had other issues with some OS layers recently, and wound up deleting 3 of those versions (one being the version used to create that Platform layer), and then recreating them. I just checked my latest Platform layer, and the OneDrive stuff is not present, thankfully.

[Weird OneDrive upgrade issues (multiple builds showing in C:\Program Files (x86))]

1 hour ago, Rob Zylowski1709158051 said:

Hey Nick,

For a file, folder or registry to get pulled into any layer when packaging it has to be opened for write.  So to get the files/folder in your platform layer something had to update them.  To know fi that is the case use something like filezilla to grab the platform layer out of your appliance and mount it on a non app layering machine and look in it to see what folders and files you have.

Ah, I forgot about grabbing the layers out of the appliance to look at it. What's the easiest way to match a file to a layer once I can into the appliance's storage?

[Weird OneDrive upgrade issues (multiple builds showing in C:\Program Files (x86))]

Has anyone had issues with upgrading OneDrive in the OS layer, where you find multiple versions of it located in C:\Program Files (x86) in your compiled image? For example, let's say I do this:

 

1. OS Layer 1.0: Install OneDrive 21.119.x
2. Platform Layer 1.0: Build as normal; no changes to OneDrive
3. Compile image v1.0 with OS Layer 1.0
4. OS Layer 1.1: Install OneDrive 21.150.x
5. Compile image v2.0 with OS Layer 1.1

 

Booting into the image, I will see folders for both versions of OneDrive. In Apps and Features, it shows 21.119.x as being installed, and that is the build of OneDrive.exe that is running. All of the OneDrive tasks, etc. that control automatic updates are disabled in the image, so I have no idea why this is happening. The only thing I can think of is that when you build your Platform layer, it timestamps a few files in the OneDrive folder, which is what I noticed. And perhaps that is preventing the upgraded version in the OS layer from working properly? I'm certainly not going to update my Platform layer after a OneDrive update, because that's absurd.

[Teams Presence addin not working in Oulook]

Yep - Microsoft gonna Microsoft.

[File association is not always working]

In that case, SetUserFTA is your best bet. You can assign the action to only those who need it, and it is very consistent.

[Teams Presence addin not working in Oulook]

3 hours ago, Daniel Dunn1709158952 said:

When I looked into the registry and compared, I think a lot of the entries were over written by the Zoom Outlook plugin.

 

I haven’t tried uninstalling the Zoom plug-in and having another go as I got round it 

 

do you have the Zoom Outlook plugin installed?

I do not, know. One of the guys on my team actually told me that MS said there was a bug where if you did not have Skype installed, Outlook presence did not work in Teams mode on the back end. So I redid my O365 layer and included Skype. Even though it's not running at all, presence now works in Outlook. So, another wondering solution thanks to MS.

[Best practice guide for end users]

Things we have in ours that you may want to consider:

• Install/configure/uninstall Citrix Workspace App for Windows and Mac
• Supported OS and browser
• Microphone/webcam preferences (including info on how to set this in both the VDA and Teams, if applicable)

[Teams Presence addin not working in Oulook]

On 5/10/2021 at 6:54 AM, Daniel Dunn1709158952 said:

I dont know if anyone can advise just on this point and what it is suggesting, but what I have found is:

 

If I copy all of the registry items from HKEY_CLASSES_ROOT on a working machine and import it to a non working machine.

 

Presence on the non working machine works again.

 

 

Any chance you've found a better resolution? I'm dealing with the same issue now, and have come up short. Replacing HKCR with a working device hasn't worked for me.

[File association is not always working]

It has gotten better, but I've noticed inconsistency with WEM's FTA functions, as well. That said, you can also check out SetUserFTA to get the job done. That's what a lot of us use, and it's rock solid reliable, and able to be set via a WEM action.

 

Alternately, you can update the OEMDefaultAssociations.xml file in your image to have .pdf files set to use Acrobat.

[implement onedrive for business and remove onedrive.]

I know this is an old post, but figured it's worth mentioning what I do on my own W10 VDAs (1909 and 20H2, on 1912 LTSR CU2, non-persistent PVS):

 

1. Download the latest OneDrive installer from Microsoft's site
2. In my OS Layer, I install OneDrive and disable the associated task that is created. I do this in PowerShell:

   1. $var_Install_Exec = "OneDriveSetup.exe"
      $var_Install_Arg = "/allusers"
      
      $proc = Start-Process -FilePath $var_Install_Exec -ArgumentList $var_Install_Arg -WorkingDirectory $PSScriptRoot -PassThru
      Do { Start-Sleep 5 } While (Get-Process | Where ProcessName -eq OneDriveSetup.exe)
      Start-Sleep 10
      schtasks /change /tn "OneDrive Per-Machine Standalone Update Task" /disable | Out-Null

       

3. In my Platform Layer, I disable OneDrive scheduled tasks and registry entries via Citrix Optimizer:

   1. Disable the OneDrive Standalone Update Task
      Get-ScheduledTask -TaskName 'OneDrive*Update*' | Disable-ScheduledTask
      
      Remove OneDrive Setup - Local Service
      Action: Delete Value
      Key: HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Run
      Name: OneDriveSetup
      
      Remove OneDrive Setup - Network Service
      Action: Delete Value
      Key: HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Run
      Name: OneDriveSetup
      
      Removes OneDrive System.IsPinnedToNameSpaceTree x86
      Key: HKCU\Software\Classes\CLSID\{018D5C66-4533-4307-9B53-224DE2ED1FE6}
      Name: System.IsPinnedToNameSpaceTree
      Value: 0
      Type: Dword
      
      Removes OneDrive System.IsPinnedToNameSpaceTree x64
      Key: HKCU\Software\Classes\Wow6432Node\CLSID\{018D5C66-4533-4307-9B53-224DE2ED1FE6}
      Name: System.IsPinnedToNameSpaceTree
      Value: 0
      Type: Dword
      
      Disable Microsoft OneDrive startup run
      Key: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run
      Name: OneDrive
      Value: 3,0,0,0,100,161,2,239,76,62,209,1
      Type: Binary
      
      Remove OneDrive Setup - HKU 1
      Action: Delete Value
      Key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
      Name: OneDriveSetup
      
      Remove OneDrive Setup - HKU 2
      Action: Delete Value
      Key: HKCU\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run
      Name: OneDriveSetup
      
      Remove OneDrive Setup - HKU 3
      Action: Delete Value
      Key: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
      Name: OneDrive

4. In Citrix WEM, I create an application for OneDrive and set it to automatically start when the user logs in. The command line for this is C:\Program Files (x86)\Microsoft OneDrive\OneDrive.exe /background
   1. I do this so that I can control how OneDrive is launched One of the registry keys listed above will be able to accomplish the same, but I prefer this method
5. The only OneDrive location that appears in File Explorer is our OneDrive for Business app - the normal OneDrive app does not appear for the users

[How to upgrade a multiple infrastructure servers configuration?]

Are you using NetScaler for load balancing? If so, this is my process (similar to above). It's worth noting that as of WEM 1912, you no longer have to remove the DB from SQL AlwaysOn AG (hooray!).

 

1. Backup the current WEM DB
2. Disable broker #1 in the Service Group in NetScaler
3. Upgrade the Infrastructure Services agent on broker #1
4. Launch the WEM Infrastructure Service Configuration utility, validate the settings, and save the configuration
5. Upgrade the WEM DB using the WEM Database Management Utility
6. Upgrade the WEM console on broker #1
7. Launch the WEM console and validate success
8. Enable broker #1 and disable broker #1 in the Service Group in NetScaler
9. Upgrade the Infrastructure Services agent on broker #2
10. Launch the WEM Infrastructure Service Configuration utility, validate the settings, and save the configuration
11. Upgrade the WEM console on broker #2
12. Launch the WEM console and validate success
13. Enable broker #2 in the Service Group in NetScaler
14. Upgrade the WEM agents
15. Crack open your beverage of choice

[Feature Request: Add layer descriptions to the GUI when creating an image]

Always appreciated, Rob!

[Feature Request: Add layer descriptions to the GUI when creating an image]

I do agree that this can probably be mitigated by changing the version to actually include a description, but I think that's probably not normal for most. Here's an example of my OS layer. Using 5.3 - Updating the C:\Service folder as the version, etc. would work, but still feels unnatural.

[Feature Request: Add layer descriptions to the GUI when creating an image]

This one still drives me nuts, and it seems like such an easy thing to implement. When building or modifying an image, it would be immensely helpful if the GUI could also include the description of the layer version so that I don't have to go back and reach them all for the OS and App layers. Here's an example of the screen I'm referring to:

 

 

["This version of Citrix Workspace does not support selected encryption" after launching an app after a CWA upgrade (2006.1 to 2009.6)]

In case anyone else ever comes across this, HDX RTME 2.9 LTSR is definitely the issue in our environment. Here's how we reproduce it:

 

1. Install CWA 2006.1
2. Install HDX RTME 2.9 LTSR
3. Attempt to install any newer CWA client

This is when the errors appear. Even uninstalling HDX RTME doesn't help, which led us to the HKLM\SOFTWARE\WOW6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ICA 3.0\VirtualDriverEx registry value. The HDX RTME installer is not removing HDX RealTime Media Engine,SOCKSProxyPlugin,UDPGatewayPlugin from the above registry key. Even with HDX RTME installed, those 3 entries cause the issues. I can reproduce this on fresh builds with their first CWA install, and old devices.

 

TL;DR: Uninstalling HDX RTME and deleting that VirtualDriverEx registry value resolved the issue for us.

[Migrating from Office 2016 (KMS) to Office 365 (SCA)]

Deleting the key file in AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\Microsoft\Crypto\TokenBindingKeys\Keys worked. Just need to automate this with the help of WEM and then I can proceed to test. I'd still like to hear from others who have gone through this migration to see if I'm going to run into more issues.

[Migrating from Office 2016 (KMS) to Office 365 (SCA)]

32 minutes ago, Rob Zylowski1709158051 said:

Nick, it sounds like you have the office 2016 license pulled into your FSLgix layer which has a higher priority than app layering.  Not sure what has to be removed or reactivated. to make that work. 

I've narrowed it down to the AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy folder. If I delete that, logoff, and log back on, O365 activates just fine. I can't possibly be the first person to want to move users from Office 2016 and KMS to O365 using the same profile, right? Do you guys recommend just starting fresh in this scenario?

[Migrating from Office 2016 (KMS) to Office 365 (SCA)]

We are finally just around the corner from completing our O365 migration, and with that I need to replace Office 2016 (x86) in my XenDesktop image (1912 LTSR, W10 1909) with O365 (x64) and Shared Computer Activation enabled. I installed O365 in a new App layer, run the optimizer to process O365 licensing, and then finalized the layer. If I login with a brand new profile, activation works fine, and I'm off and running. However, if I login with my current Citrix profile - we're using FSLogix, both Profile and ODFC containers (only the OST in the ODFC container) - the license files never appear in %localappdata%\Microsoft\Office\16.0\Licensing, and I am prompted to sign in to Office.

 

This was working flawlessly long ago when I was first testing out, but that was many changes ago. If I delete the contents of %localappdata% and log back on, even though everything else is hosed up, O365 activation actually works, so there has to be a file or folder somewhere that I need to target to make this work smoothly. Having the users recreate their profiles isn't going to be an option here.

 

Any chance somebody else has come across this very issue moving from Office 2016 to 365? Furthermore, is there a good reason why I shouldn't just have everyone start fresh with a clean profile once we make that switch? I don't know if I could even sell that option to management.

["This version of Citrix Workspace does not support selected encryption" after launching an app after a CWA upgrade (2006.1 to 2009.6)]

We're seeing a number of devices throwing this error and crashing after launching any published app, after upgrading CWA 2006.1 to 2009.6. It's worth noting that we also have HDX RTME 2.9 LTSR installed, and I think that may be part of the issue based on the error in the event log:

 

Faulting application name: WFICA32.EXE, version: 20.9.6.21, time stamp: 0x5f747f33
Faulting module name: SOCKSProxyPlugin.dll, version: 2.9.0.2330, time stamp: 0x5e51765f
Exception code: 0xc0000005
Fault offset: 0x000422bc
Faulting process id: 0x1620
Faulting application start time: 0x01d6bf787fd53c05
Faulting application path: C:\PROGRA~2\Citrix\ICACLI~1\WFICA32.EXE
Faulting module path: C:\PROGRA~2\Citrix\ICACLI~1\SOCKSProxyPlugin.dll
Report Id: 2c3943d9-9a42-4564-8c35-785f3d18658a
Faulting package full name:

Anyone ever come across this before? This is literally our first upgrade attempt after moving from Receiver 4.9 LTSR to CWA 2006.1. https://support.citrix.com/article/CTX133536 doesn't appear to help our situation.

[NIC missing after Platform layer version]

My environment:

XenServer 7.1 CU2 (all hotfixes applied)

App Layering 2009

In my latest OS layer version, I upgraded Windows 10 from 1909 to 20H2. I then created a brand new Platform layer (v1.0) based on this OS layer and installed PVS 1912 CU2, VDA 1912 CU2, CWA 2009.6, HDX RTOP 2.9, WEM 2006, FSLogix 2.9.7621.30127, Topaz SigPlus, and some USB drivers. Everything looked good, so I finalized the layer. I then created a new version of that Platform layer (v1.1) so that I could run Citrix Optimizer, as I like to separate my optimizations from the base installs. When the packaging VM booted up, the NIC was completely missing (see NoNic.jpg screenshot).

 

 

No amount of reboots resolved it. I went ahead and uninstalled the XenServer PV Network Device, rebooted, let Windows reinstall the device, and then rebooted again. When the VM came back online, the NIC was restored, and all seemed well. I'd almost accept this, except that when I tried to update an App layer using that same OS layer as the base, the NIC was again missing from the packaging VM (see AppLayer.jpg screenshot). However, rebooting the VM seemed to restore it. I can repeat this 100% of the time.

 

 

Has anyone come across something like this before? There's no way I trust that OS layer given these issues, so I'm trying to figure out if something else needs to be done as part of that 20H2 upgrade layer.

 

To throw a wrench into this, let's say I have that Platform layer with versions 1.0 and 1.1. If I create a version 1.2, but base it off Platform version 1.0, the NIC is totally fine.

 

Now for the biggest wrench of them all. If I create a new Platform layer based off the OS layer with 20H2 in it, but finalize and create a new version of that layer after each step in the process, the NIC is fine after each version. So:

 

1. Join domain, finalize (v1.0)
2. NIC good, install PVS, finalize (v1.1)
3. NIC good, install VDA, finalize (v1.2)
4. NIC good, install CWA, finalize (v1.3)
5. NIC good, install WEM, finalize (v1.4)
6. NIC good, install FSLogix, finalize (v1.5)
7. NIC good, install USB drivers, finalize (v1.6)
8. NIC good, run Citrix Optimizer, finalize (v1.7)
9. NIC good, nothing left to do but throw my computer out of the window

[Best way to handle Edge Updates]

On 11/13/2020 at 6:09 PM, Jimmy Bouma-Holtrop said:

Hi all,

 

I'm looking for some input on the "best practice" way to handle updates for the new Edge Chromium. I used to just let Edge update in the OS layer like IE, so when I upgraded to the new Edge I just left it there but now I'm thinking I should break it out since it updates basically like Chrome does. Does anyone else have any experience with this? Specifically, the best way to extract it from the OS layer?

 

Thanks! 

Keep in mind that it's only in my QA environment right now, but I intend to treat it like IE since it's so ingrained with the OS and keep it in the OS layer. Also, Windows Update will update Edge Chromium. Nothing's preventing you from creating an App layer for it, though.

[Citrix Workspace Version: 20.10.0.20 (2010) - Deployment Issue]

You're still going to want to use 20.10.0.12 in your script. Each component has its own version number, and the path in the deployment script (line 96) is pointing to the Online Plug-in component:

 

{78C8BAB6-EF8A-426B-8FE4-C5DE3FB5E1A4}          Online Plug-in          20.10.0.12          32-bit

[Issue in upgrading ELM]

On 10/15/2020 at 2:51 PM, Rob Zylowski1709158051 said:

Yea one version in there did alot of security work.

Yeah, it was either 2003 or 2005, where the GUI would sit there until you just refreshed the screen. Is there a simple way to generate a self-signed certificate so that we don't get SSL cert errors before logging in, since it's now issued by 'localhost'?

[Windows 10 Feature Updates Best Practices]

To add to what Rob said, make sure you pad the OS layer version with an extra 20GB of space before doing a Feature Update so that you have enough disk space to complete it.

[Generic (not Optimized) USB Redirection without registry change]

On 8/27/2020 at 2:36 PM, Jeremy Beaver said:

Recently we were working with support on a USB headset redirection for use of a softphone in Chrome.  We were able to get it to work but only by adding a registry entry to force the headset to "generic" and not optimized.  Unfortunately this is not an option for those with computers we do not control.  

 

So adding a feature request to be able to have that as a control inside of the Citrix settings.  This way we can make it work without asking users to modify their registry.

Users can switch the USB device to generic mode by going to Preferences in the desktop toolbar, and then clicking on Switch to generic next to the device on the Devices tab.