Jump to content

Nick Panaccio

Members
  • Posts

    194
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by Nick Panaccio

  1. 29 minutes ago, Heinz Wirth said:

    Hi Nick

     

    We are facing exact the same with Citrix XenDesktop 7.15 and Office/Outlook 2016 in Online Mode with Exchange 2013 on prem.

    Outlook crashes (0xc0000005) while sending an email. After Outlook restart, the Email hasnt been sent and can be found in the outbox.

    I created a crash report over all VDIs and users, but I was unable to find any time or object related connection, it is completely random.

     

    We already did:

    1. Updates Office to latest updates (MSI installation)

    2. Disabled any Outlook Add-Ons

    3. Changed to mapi over http

    4. Re-created Outlook profile

    5. Repaired Office 2016

     

    We are planning to upgrade to Citrix 1912 anyway and have some options left:

    6. Disable Kernel APC Hooking for outlook.exe: https://support.citrix.com/article/CTX107825
    7. Enable Outlook Cache (with FS-Logix)

     

    Let me know if you have any other findings.

     

    I haven't had a report of this in a while, but that doesn't mean much since our users simply may just not be reporting it. My next step was going to be disabling the hook for Outlook.exe, as well. If you go that route and have users who can actually report a success, definitely let me know. We're upgrading to 1912 LTSR next month, and and are actually running FSLogix already, though we're online mode for on-prem users. The few users who have been migrated to O365 are in cache mode with FSLogix's ODFC container.

  2. Anyone else seeing WEM instance notifications on reconnects to a disconnected session in WEM 1912 (on-prem)? I don't see this behavior in 1906 with the same exact settings, and the only way to resolve it is to uncheck Launch agent on Reconnect in the WEM console. The event log shows the following errors:

     

    SensMonitoring.StartReconnectTask() : Starting Reconnect Processing for User :


    ReconnectController.InternalRun() : Error while trying to close Ui Agent for user domain\me in session 1

     

    WEM.jpg

     

    To add to this, I have a custom Start tile that runs tsdiscon.exe that I'm using to test. When I run that, the error will occur at reconnect. However, if I use the Disconnect button in the Desktop Viewer toolbar up top, I don't receive any errors on reconnect.

  3. I'm testing my new 1912 LTSR VDA (W10 1809) on App Layering 2001, and kmssetup.cmd is constantly running in the background (after calling StartCCMEXEC.cmd), so it never actually finishes processing. I do not have SCCM installed on this VDA, and the registry keys it's looking for don't actually exist, so I have no idea why the log file says otherwise. I've validated this behavior in three different images that have App Layering 2001 installed. Has anyone else seen something similar? I've opened a case with Citrix, but figured this was worth posting here, as well. Attached are the relevant logs.

    kmssetup.log StartCCMEXEC.log

  4. On 1/24/2020 at 9:34 PM, Andrew Gresbach1709152664 said:

    awesome thanks for the heads up! i just updated last night. i still see the blue screens after log out if i dont have citrix optimizer set (which ironically in another thread about slow logins w/ 2 monitors someone may have found that the optimizer may be causing it).  I need to get our 7.15.2000 environment up to the latest 1912 so maybe thats my issue

    Which other thread are you referring to? I'd like to follow it. I'm curious to know which optimization is causing the issue, if somebody is taking the time to go through them one by one. My own Citrix Optimizer template is in the Marketplace.

  5. I'm still on 1809, but haven't seen any blue screens. The only oddity I saw was that my small target devices (2 vCPU/5GB) worked fine, but my large target devices (4 vCPU/8GB) all failed to register when they came online. Of course, my entire environment is still 7.15 LTSR CU2, so my results are effectively worthless.

  6. 12 hours ago, Clement Thuraisamy1709154286 said:

    Understood, I don’t plan to use dynamic layers. Not in my scope now. I have tested UL and as much I like them, I noticed logon are extremely slow. 
     

    thanks again Rob for your assistance. 

    Rob beat me to the replies, but we're still in the same boat. Logon performance goes down drastically for us with EL enabled, so we've left it out of our images entirely. We've been on App Layering with FSLogix in Production for a month or so now and so far everything has gone well. I do keep FSLogix in my Platform layer, though testing it in an App layer also worked.

  7. I'm finding conflicting information on the procedure for updating Office 365. In CTX224566, it states that you need to change <Updates Enabled="FALSE" /> to <Updates Enabled="TRUE" /> in the configuration XML file before updating 365 using the /configure switch. However, before reading the article, I left that setting at 'FALSE' and O365 appeared to update just fine. Is the information in that article still accurate?

     

    Furthermore, if we're upgrading Office 365 in a Layer version, do I need to do anything else, like re-run Office2013Windows81_PREP.cmd before Finalizing the layer?

  8. I've asked this everywhere and have yet to find a solution. Only two users have come forward with this issue, but I have to believe that others just aren't reporting it. Occasionally, when somebody is writing an e-mail (no attachments) and they click on Send, Outlook 2016 completely crashes:

     

    839982524_OutlookCrash.thumb.jpg.ca92d83002d9992e8513a6edfe17da82.jpg

     

    The crash log is less than useless, because it doesn't point to anything in particular. I've had both users run Outlook with no add-ins enabled and it still crashes. This only happens in our App Layering image for Windows 10, in both build 1709 and 1809.

     

    Anyone have any ideas here? I'm trying to avoid building the Office 2016 layer from scratch again, but at the same time, feel that's my only play here.

  9. Honestly, I haven't even tried. And once I posted that, I realized that it made more sense for me to simply duplicate the few settings in yours, in my own custom template. For the most part, your template loaded fine in 2.6 when I went to modify it, except for the Hybernation configuration. The PS code was blank in the editor, so that may need to be resolved.

    • Like 2
  10. I've had no issues keeping Windows Update disabled in our images in our current 1709 image and our new 1809 image. I disable the WU service both in the OS Layer (manually disabling it; not via local GPO), as well as in a domain GPO. I don't think they exist anymore, but there were some random scheduled tasks in 1709 that used to change that behavior, which I disable in VMware OSOT in my Platform layer. These tasks were all in the Microsoft\Windows\rempl folder in Scheduled Tasks, and all were deleted. While I'm deleting a number of other tasks, I don't think any of them are known to turn on WU.

     

    We do set the following registry key in our Platform layer:

     

    Key: HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

    Value: NoAutoUpdate

    Data: 1

  11. 2 minutes ago, David Hendy said:

     

     

    Hi. where did you get get the sign out and disconnect icons? I cannot find them anyway!

    I'm pretty sure that I found these icon files online somewhere, but may have modified them myself. Either way, let me see if attaching them to this post works. If not, I'll upload it to my Google drive.

    Disconnect.ico Signout.ico

  12. I love that the Optimizer tool is being expanded, and look forward to v2.6 (still in beta, I hear). I may actually sit down and convert my hefty VMware OS Optimization Tool script to Citrix Optimizer so that I can use one tool from here on out.

     

    Better yet, Citrix could develop a tool to do that conversion for us, hint hint... ;)

    • Like 2
  13. 1 minute ago, Mike Kelly1709153237 said:

     

    Did you have to use the Layer Priority tool and move it to the top of the priority list?  We also use Ivanti Application Control (filter driver) and the vshield filter driver for trend micro so I'm assuming that's why we needed it in the platform layer.

    I used the utility to move that layer to the top of the list just in case, yes. I didn't test it at a lower level. I'm also running Trend Micro Apex One (in an App layer).

×
×
  • Create New...