Chip Gonsalves
-
Posts
15 -
Joined
-
Last visited
-
Days Won
1
Content Type
Forums
Articles
Labs
Videos
TechZone
Citrix Community Articles
Events
Profiles
Posts posted by Chip Gonsalves
-
-
On 8/14/2023 at 3:53 PM, Sergio Masone1709161115 said:
I did a new OS revision, inside the revision here is a tree view of the sub-folders in c:\windows\inf\
├───.NET CLR Data
│ │ _DataPerfCounters.h
│ │ _DataPerfCounters.ini
│ │
│ ├───0000
│ │ _DataPerfCounters_d.ini
│ │
│ ├───0409
│ └───040C
│ _DataPerfCounters_d.ini
│
├───.NET CLR Networking
│ │ _NetworkingPerfCounters_v2.h
│ │ _Networkingperfcounters_v2.ini
│ │
│ ├───0000
│ │ _Networkingperfcounters_v2_d.ini
│ │
│ ├───0409
│ └───040C
│ _Networkingperfcounters_v2_d.ini
│
├───.NET CLR Networking 4.0.0.0
│ │ _NetworkingPerfCounters.h
│ │ _Networkingperfcounters.ini
│ │
│ ├───0000
│ │ _Networkingperfcounters_d.ini
│ │
│ └───040C
│ _Networkingperfcounters_d.ini
│
├───.NET Data Provider for Oracle
│ │ _DataOracleClientPerfCounters_shared12_neutral.h
│ │ _DataOracleClientPerfCounters_shared12_neutral.ini
│ │
│ ├───0000
│ │ _DataOracleClientPerfCounters_shared12_neutral_d.ini
│ │
│ ├───0409
│ └───040C
│ _DataOracleClientPerfCounters_shared12_neutral_d.ini
│
├───.NET Data Provider for SqlServer
│ │ _dataperfcounters_shared12_neutral.h
│ │ _dataperfcounters_shared12_neutral.ini
│ │
│ ├───0000
│ │ _dataperfcounters_shared12_neutral_d.ini
│ │
│ ├───0409
│ └───040C
│ _dataperfcounters_shared12_neutral_d.ini
│
├───.NET Memory Cache 4.0
│ │ netmemorycache.h
│ │ netmemorycache.ini
│ │
│ ├───0000
│ │ netmemorycache_d.ini
│ │
│ └───040C
│ netmemorycache_d.ini
│
├───.NETFramework
│ │ CORPerfMonSymbols.h
│ │ corperfmonsymbols.ini
│ │
│ ├───0000
│ │ corperfmonsymbols_d.ini
│ │
│ ├───0409
│ └───040C
│ corperfmonsymbols_d.ini
│
├───BITS
│ │ bitsctr.h
│ │
│ ├───0000
│ │ bitsctrs.ini
│ │
│ ├───0409
│ │ bitsctrs.ini
│ │
│ └───040C
│ bitsctrs.ini
│
├───en-US
├───ESENT
│ │ esentprf.hxx
│ │
│ ├───0000
│ │ esentprf.ini
│ │
│ ├───0409
│ │ esentprf.ini
│ │
│ └───040C
│ esentprf.ini
│
├───LSM
│ │ lagcounterdef.h
│ │
│ ├───0000
│ │ lagcounterdef.ini
│ │
│ ├───0409
│ │ lagcounterdef.ini
│ │
│ └───040C
│ lagcounterdef.ini
│
├───MSDTC
│ │ msdtcprf.h
│ │
│ ├───0000
│ │ msdtcprf.ini
│ │
│ ├───0409
│ │ msdtcprf.ini
│ │
│ └───040C
│ msdtcprf.ini
│
├───MSDTC Bridge 3.0.0.0
│ │ _TransactionBridgePerfCounters.h
│ │ _TransactionBridgePerfCounters.ini
│ │
│ ├───0000
│ │ _TransactionBridgePerfCounters_D.ini
│ │
│ ├───0409
│ │ _TransactionBridgePerfCounters_D.ini
│ │
│ └───040C
│ _TransactionBridgePerfCounters_D.ini
│
├───MSDTC Bridge 4.0.0.0
│ │ _TransactionBridgePerfCounters.h
│ │ _TransactionBridgePerfCounters.ini
│ │
│ ├───0000
│ │ _TransactionBridgePerfCounters_d.ini
│ │
│ └───040C
│ _TransactionBridgePerfCounters_d.ini
│
├───PERFLIB
│ ├───0000
│ │ perfc.dat
│ │ perfd.dat
│ │ perfh.dat
│ │ perfi.dat
│ │
│ ├───0409
│ │ perfc.dat
│ │ perfd.dat
│ │ perfh.dat
│ │ perfi.dat
│ │
│ └───040C
│ perfc.dat
│ perfd.dat
│ perfh.dat
│ perfi.dat
│
├───PNRPSvc
│ ├───0000
│ ├───0409
│ └───040C
├───rdyboost
│ │ ReadyBoostPerfCounters.h
│ │
│ ├───0000
│ │ ReadyBoostPerfCounters.ini
│ │
│ ├───0409
│ │ ReadyBoostPerfCounters.ini
│ │
│ └───040C
│ ReadyBoostPerfCounters.ini
│
├───RemoteAccess
│ │ rasctrnm.h
│ │
│ ├───0000
│ │ rasctrs.ini
│ │
│ ├───0409
│ │ rasctrs.ini
│ │
│ └───040C
│ rasctrs.ini
│
├───ServiceModelEndpoint 3.0.0.0
│ │ _ServiceModelEndpointPerfCounters.h
│ │ _ServiceModelEndpointPerfCounters.ini
│ │
│ ├───0000
│ │ _ServiceModelEndpointPerfCounters_D.ini
│ │
│ ├───0409
│ │ _ServiceModelEndpointPerfCounters_D.ini
│ │
│ └───040C
│ _ServiceModelEndpointPerfCounters_D.ini
│
├───ServiceModelOperation 3.0.0.0
│ │ _ServiceModelOperationPerfCounters.h
│ │ _ServiceModelOperationPerfCounters.ini
│ │
│ ├───0000
│ │ _ServiceModelOperationPerfCounters_D.ini
│ │
│ ├───0409
│ │ _ServiceModelOperationPerfCounters_D.ini
│ │
│ └───040C
│ _ServiceModelOperationPerfCounters_D.ini
│
├───ServiceModelService 3.0.0.0
│ │ _ServiceModelServicePerfCounters.h
│ │ _ServiceModelServicePerfCounters.ini
│ │
│ ├───0000
│ │ _ServiceModelServicePerfCounters_D.ini
│ │
│ ├───0409
│ │ _ServiceModelServicePerfCounters_D.ini
│ │
│ └───040C
│ _ServiceModelServicePerfCounters_D.ini
│
├───SMSvcHost 3.0.0.0
│ │ _SMSvcHostPerfCounters.h
│ │ _SMSvcHostPerfCounters.ini
│ │
│ ├───0000
│ │ _SMSvcHostPerfCounters_D.ini
│ │
│ ├───0409
│ │ _SMSvcHostPerfCounters_D.ini
│ │
│ └───040C
│ _SMSvcHostPerfCounters_D.ini
│
├───SMSvcHost 4.0.0.0
│ │ _SMSvcHostPerfCounters.h
│ │ _SMSvcHostPerfCounters.ini
│ │
│ ├───0000
│ │ _SMSvcHostPerfCounters_d.ini
│ │
│ └───040C
│ _SMSvcHostPerfCounters_d.ini
│
├───TAPISRV
│ │ perfctr.h
│ │
│ ├───0000
│ │ tapiperf.ini
│ │
│ ├───0409
│ │ tapiperf.ini
│ │
│ ├───0809
│ │ tapiperf.ini
│ │
│ └───0C0C
│ tapiperf.ini
│
├───TermService
│ │ tslabels.h
│ │
│ ├───0000
│ │ tslabels.ini
│ │
│ ├───0409
│ │ tslabels.ini
│ │
│ └───040C
│ tslabels.ini
│
├───UGatherer
│ │ gsrvctr.h
│ │
│ ├───0000
│ │ gsrvctr.ini
│ │
│ ├───0409
│ │ gsrvctr.ini
│ │
│ ├───0809
│ │ gsrvctr.ini
│ │
│ └───0C0C
│ gsrvctr.ini
│
├───UGTHRSVC
│ │ gthrctr.h
│ │
│ ├───0000
│ │ gthrctr.ini
│ │
│ ├───0409
│ │ gthrctr.ini
│ │
│ ├───0809
│ │ gthrctr.ini
│ │
│ └───0C0C
│ gthrctr.ini
│
├───usbhub
│ │ usbperfsym.h
│ │
│ ├───0000
│ │ usbperf.ini
│ │
│ ├───0409
│ │ usbperf.ini
│ │
│ └───040C
│ usbperf.ini
│
├───Windows Workflow Foundation 3.0.0.0
│ │ PerfCounters.h
│ │ PerfCounters.ini
│ │
│ ├───0000
│ │ PerfCounters_D.ini
│ │
│ ├───0409
│ │ PerfCounters_D.ini
│ │
│ └───040C
│ PerfCounters_D.ini
│
├───Windows Workflow Foundation 4.0.0.0
│ │ PerfCounters.h
│ │ PerfCounters.ini
│ │
│ ├───0000
│ │ PerfCounters_d.ini
│ │
│ └───040C
│ PerfCounters_d.ini
│
├───WmiApRpl
│ │ WmiApRpl.h
│ │ WmiApRpl.ini
│ │
│ └───0009
│ WmiApRpl.ini
│
└───wsearchidxpi
│ idxcntrs.h
│
├───0000
│ idxcntrs.ini
│
├───0409
│ idxcntrs.ini
│
├───0809
│ idxcntrs.ini
│
└───0C0C
idxcntrs.iniAre you saying one empty folder in this list can fail the entire process? i dont see an empty folder from the list of counters missing. empty folder im seing is PNRPSvc\ and En-Us\
Thanks for the post. And the answer to your question is yes, the empty 0409 directories will cause your lodctr /r to fail for the parents of those directories. And if you remove those directories prior to issuing the lodctr /r on the OS revision, you will then not be missing the counters in question from your final image. And please keep in mind that Citrix didn't make up these rules. If we never existed as a company and there were no such thing as app layering, you would still get the same result of the counters that have empty directories being removed from your database simply because they happen to have an empty directory when you run the lodctr /r.
The only thing we did was trust that running the command would not have a negative effect. The fact that we run the lodctr /r is the reason that you are seeing the results you are seeing. When you disable the setting, we no longer create the file that will run the lodctr /r, and as such the fact that there is a problem with data is never exposed. Please give try deleting the empty directories in the OS revision before ever running the lodctr /r. I believe once you have done that, you will have success. You should not have to look through all of the directories for empty directories. You should only have to look in the directories for the counters that you reported as missing. You will find that every single one of them happens to have an empty directory.
-
3 hours ago, Sergio Masone1709161115 said:
Hi Chip,
In the published template, I don't see any empty folders from the list provided, I do see the folders with the names, but they all have something underneath them. When I have the workaround in place (reg key GeneratePerfGenRecompileScript_disabled DWORD 1, all counters seem to work fine, and in Citrix Monitor the ICA latency metrics and protocol are visible. something in the new process isn't working the same way it seems.Hello Sergio,
My comment was not for the published template. You want to look on the OS revision before ever doing a lodctr /r. Can you do me a favor and make an OS revision that was done before a lodctr /r was done and look in those directories? So far we have had a 100% hit rate with customers that have reported exactly what you have, and after they removed the empty directories we are seeing a 100% hit rate on getting all of the expected counters. So we need to know if you are different than everyone else.
-
On 7/10/2023 at 4:33 PM, Sergio Masone1709161115 said:
Hi Mike,
These are what look to be missing from the perfstringbackup.ini from 2211 to 2306
[PERF_WmiApRpl]
[PERF_.NETFramework]
[PERF_.NET Data Provider for SqlServer]
[PERF_.NET Data Provider for Oracle]
[PERF_.NET CLR Networking]
[PERF_.NET CLR Data]
also in Citrix Monitor, seems ICA latency metric is showing n/a as well as protocol. not sure if its related, however the ica session metric seem to work in our monitoring platform so wont make a big case with this one i guess.Hey Sergio,
I believe that what you are seeing is a result of empty directories in the os revision that are confusing the lodctr utility. To verify that, you can make a new os revision (do not run lodctr right away). Instead, navigate to the C:\Windows\inf directory. There you will find a directory for each entry you have listed. They will not have the PERF_ in front of them. For instance, you will find c:\windows\inf\WmiApRpl. In each of these directories, you will find a numbered directory. One of these numbered directories will have no files in it. This causes lodctr to give errors when it is running (found using google for this type of problem when there is no app layering involved). If you go through and remove the empty directories under each of the folders you listed, I believe you will find then that your counters rebuild correctly and you will not be missing anything.
If you get a chance I would like to know what you get for results. Because if you find that it fixes your counts, then we can create a script to run on the os revisions to check for these empty directories and remove them so they will not cause a problem going forward.
Thanks
Chip
-
19 minutes ago, Sergio Masone1709161115 said:
OK, now I know the why the /R is missing counters, /R restores off of a file called C:\Windows\System32\PerfStringBackup.INI, and this one has the missing counters, but in my 2112 image, the file has all the counters, so something fiddled or exported a new set of counters overwritting this file somewhere along the way.. so in theory if i replace the perfstringbackup.ini from my 2112 vda, and throw it in my os layer, that should make the "/r" work, or create an app layer containing this file, and add it as part of the publish... any idea if changes in 2304 would have done something to touch this file?
Actually, the thing that I am most interested in is the fact that you state there is no perf counters mentioned in the ulayersvc.log. Please work with your support engineer and provide that file to them. Because that should have run the command, and you should not have to do all of the extra work you are trying to do. So please go that route before trying to change things on your own. This could be as simple as for some reason your ulayer didn't get updated for what ever reason, and that is where the problem resides. The intent is that you would not have to do anything at all.
-
1 hour ago, Sergio Masone1709161115 said:
to get the counters back again, in running inside my test session lodctr /R:<path to export of 2211> then they are all reloaded again properly.. could be a workaround for anyone having this behavior with missing perf counters as a startup script or something.
I seem to be seeing this counters missing problem only from my Windows 10 layer, my Server 2022 does not have this problem on publish.The change is intended to always run the rebuild anytime the machine boots. Take a look at two files on your machine that is seeing a problem. First check in c:\programdata\unidesk\log\ulayersvc.log and search for lines with "PerfMonService:" The last one in the file should show you the result of trying to execut the lodctr /r. The second file is the c:\windows\setup\scripts\kmsdir\PerfGenRecompile.log. Look in that file to see the results of all of the perf commands that were issued to rebuild the perf counters. I believe your support engineer is going to ask you to provide those very same things. So this post is not only for you, but for anyone else that may be seeing something unexpected.
-
1 hour ago, Sergio Masone1709161115 said:
Im a bit shaky to use 2304 now to be honest, i havent see issues with cpu counters, however i did export the counters on my 2112 layered VDA using lodctr /S:c:\temp\outcounters.txt then re ran the same command even after rebuilding the counters in the OS layer , upgrade tools version, when i rerun tons are missing in 2304.
@Chip Gonsalvesim not sure thats normal between 2304 and 2211, but you should be able to see similar in your lap if you export the counters to a txt file built from the registry on a 2211 image, vs 2304, there over 5k lines missing! is there any workaround that can be done for this or should i revert back to 2211 from restore?Sergio, we do not see the same things that you and Mike are reporting. So while you both are reporting having issues with the release in respect to counters, I actually can not duplicate your results in my lab. So there is something different in both of your environments and you both should have escalated your problems to support (I'm not in support). The reason you may have to escalate is that since we are seeing nothing even close to the results you both are reporting, it means that you may have something unique in both of your environments, and there is no way for us to know what that is without you providing some feedback. I know Mike has stated that he is waiting for some feedback from his report, but I can tell you that nothing has been escalated to us in development. So we have nothing to go on other than we know that both of you are having problems that are not seen internally or by other customers. And this is the wrong forum to try to diagnose exactly what is different in your environments. Both of you are assuming that the problems you are reporting are generic and can be seen by everyone, but that is not the case.
-
16 hours ago, Mike Kelly1709153237 said:
Thanks Chip.
I see you guys updated the App layering documentation but there is an error.
it should be lodctr /R not LOADCTR /r - FYI ?
Performance counters now work from any layer, including app layers and full user layers. The gold image tools must be updated in the OS revision to ensure the performance counters are correctly rebulit when booting an image. The OS revison needs at least one rebuild of the performance counters. Open an administrator command window in the same OS revision where you’re updating the gold image and run the commands c:\windows\system32\loadctr /r and c:\windows\syswow64\loadctr \r.
That is 100% my fault and not the doc teams. Every time I type the word lodctr, my fingers refuse to not type loadctr. The doc team put in exactly what I asked them to add, and they would have no way of knowing that it was wrong. I have asked them to update it (and of course apologized for my blunder).
Thanks, Mike for pointing it out. And thanks to all of you for helping us to understand that the rebuild needed to be done in your OS layers. That scan will be done automatically in the next release of the product. Heads up, we will have to do the scan in the cmd file that is updated with the tools, so this will be the second time that the tools will need to be updated. We promise it will not be a trend going forward.
-
1 hour ago, Mike Kelly1709153237 said:
@Chip Gonsalves - Where is this outlined in the Release notes / fixed issues? Seems that this dramatic change in the scripts should be clearly outlined on the customer facing docs page so it can be clearly seen. I read that information with every release and I wouldn't even be here talking to you right now if it would have been posted there.
We had called out that the external documentation needed to be updated to explicitly indicate that the gold image tools needed to be updated. Somewhere in the deployment process either that was not properly reported to the documentation team or else there was a disconnect on their part with regards to whether they should be included. Once I am done with the review of the breakdown, I will ask the documentation team to update the "What's new" to be explicit. And I will be asking them to include that a rebuild of the counters is needed at that time as well. And just to be clear, in all of our testing during development, nightly automation testing, our internal dogfood, and 100% of the customers that were reporting the original issues of performance counters being inconsistent, absolutely none of them required a rebuild. That is the number one reason we didn't think it was needed, because in all of our testing and at every customer site that we had them deploy the fix, we first confirmed that it fixed their issue, and we also found that the rebuild was not needed. Thanks to your input, we will be adding it to the documentation, and in the next version of the product, we will do it automatically on every OS revision (it is a quick operation and should never cause any harm). And now that this forum has told us it is sometimes needed, we will do it always.
-
Just now, Sergio Masone1709161115 said:
i do see this file, i was just looking at it when you asked the question concerning this. on my part i didnt update the os tools in my OS layer yet.
the script your referring has this in contents, and naturally that log file doesnt exist since it prob didnt run due to tools out of date:@echo off
Setlocal EnableDelayedExpansioncd \windows\setup\scripts\kmsdir < is this missing a C:?
echo !date!-!time!-PerfGenRecompile.cmd: Begin Register Of Percounters from Ini files >>PerfGenRecompile.log
echo !date!-!time!-PerfGenRecompile.cmd: Register C:/Program Files (x86)/Citrix/ICA Client/Configuration/module.ini >>PerfGenRecompile.log
lodctr "C:/Program Files (x86)/Citrix/ICA Client/Configuration/module.ini" >>PerfGenRecompile.log 2>&1
echo. >>PerfGenRecompile.log
echo !date!-!time!-PerfGenRecompile.cmd: Register C:/Program Files (x86)/Citrix/ICA Client/Configuration/module_Wince.ini >>PerfGenRecompile.log
lodctr "C:/Program Files (x86)/Citrix/ICA Client/Configuration/module_Wince.ini" >>PerfGenRecompile.log 2>&1
echo. >>PerfGenRecompile.log
echo !date!-!time!-PerfGenRecompile.cmd: Register C:/Program Files (x86)/Citrix/ICA Client/module.ini >>PerfGenRecompile.log
lodctr "C:/Program Files (x86)/Citrix/ICA Client/module.ini" >>PerfGenRecompile.log 2>&1
echo. >>PerfGenRecompile.log
echo !date!-!time!-PerfGenRecompile.cmd: Register C:/Program Files/Citrix/HDX/bin/IcaPerf.ini >>PerfGenRecompile.log
lodctr "C:/Program Files/Citrix/HDX/bin/IcaPerf.ini" >>PerfGenRecompile.log 2>&1
echo. >>PerfGenRecompile.log
echo !date!-!time!-PerfGenRecompile.cmd: Register C:/Program Files/Citrix/User Profile Manager/upmPerf.ini >>PerfGenRecompile.log
lodctr "C:/Program Files/Citrix/User Profile Manager/upmPerf.ini" >>PerfGenRecompile.log 2>&1
echo. >>PerfGenRecompile.log
echo !date!-!time!-PerfGenRecompile.cmd: Register C:/Program Files/Microsoft Office/root/Office16/1033/OUTLPERF.INI >>PerfGenRecompile.log
lodctr "C:/Program Files/Microsoft Office/root/Office16/1033/OUTLPERF.INI" >>PerfGenRecompile.log 2>&1
echo. >>PerfGenRecompile.log
echo !date!-!time!-PerfGenRecompile.cmd: Rebuild counters >>PerfGenRecompile.log
lodctr /r >>PerfGenRecompile.log 2>&1
echo. >>PerfGenRecompile.log
echo !date!-!time!-PerfGenRecompile.cmd: Recompile Complete >>PerfGenRecompile.log
do we simply need to install the OS layer tools, then republish and it should recompile the perf counters afterwards on publish?Yes. Just update the tools in the OS layer. Again that is just really doing an unzip. There is never a need to run the setup64 ever again. Also, no need to rebuild the perf counters as was reported before. Just update with the tools, finalize, and republish.
-
3 minutes ago, Mike Kelly1709153237 said:
Citrix support issued us a fix... We had to run the "citrix_app_layering_os_machine_tools_23.4.0.exe" install on our OS layers and then rebuild the performance counters in the same version of the OS layer C:\windows\system32\lodctr /R and C:\windows\syswow64\lodctr \R - reboot and finalized both of our OS layers and then redeployed our images using this version of the OS layer and the performance counters are working again. Unsure what is so dramatically different in this version of app layering. As I understand it, its not required to run those tools with each app layering upgrade. We had files in there back from March of 2018 and everything has been working fine in this regard all the way up to 2211.
In my latest reply you will note that we made a change to the kmssetup.cmd in the latest tools to ensure that all performance counters found in all layers would be re-registered. The procedure that support said of having to rebuild the performance counters is not correct. You simply only need to run the gold image tools (which is just an unzip) in your OS revision to get the updates. What changed was we needed to ensure that perf counters from every layer (all application layers, platform layers, and for those using full user layers) would properly be updated on each boot.
-
For those that answer "yes" the directory does exist, can you please look for a file called c:\windows\setup\scripts\kmsdir\PerfGenRecompile.cmd in the image that was deployed? And also please let us know if you have updated the gold image tools to the 2304 version since there was a change to the kmssetup.cmd that will execute the PerfGenRecompile.cmd to allow the perf counters to be registered.
-
One question that we have for anyone seeing this issue, can you please confirm that you have the directory c:\windows\setup\scripts\kmsdir? Looking at the code, the only reason that the new code could be running into an issue is only if that directory doesn't exist. And for our testing, we don't know how you can have a scenario in which that directory doesn't exist, or else there will be other problems on the deployed images. So please could I get some of you to reply yes the directory exists or no the directory does not exist?
-
Hi David,
As Rob has stated these exclusions are intended to prevent updates going to the user layer. It is primarily for dealing with Anti-virus applications that tend to pollute the user layers with files and updates that should not persist from one login to the next.
They are only read on a deployed image with the layers that included the exclusions built into the image.
So in your test case that described what you should see is the log0.txt being updated with the rule that was added in your layer once you log into the machine as a user and have the user layer mounted. And based on your description, you would see the edits that you did on the application layer. Then any edits you do the file while logged in as the user would not persist on the next login.
-
1
-
-
For the first issue of having to reboot this is because Symantec has changed their behavior. They now will update the file SymELAM.sys on every single boot of the machine. This driver is registered in the services with a start value of 0, which means that it will start at boot time. The code that is blocking the shutdown for finalize will check for changes to files that have a start value of 0 and ask for a reboot out of an abundance of caution. It must ensure that if that file got updated, then we must make sure that the machine will boot correctly before you try to deploy the layer. Thus the reason it is asking for the reboot. Now if Symantec updates the file on every single boot, the code has no clue that it is not supposed to ask for a reboot.
So in this case, you the person doing the install, will have to determine that you have completed the install of Symantec, since the software can't detect it. Typically the install of Symantec requires two reboots before it is done doing all of the configuration that it wants to do. So what I recommend is that you do is follow the instructions in Symantec section for anti-virus support (https://docs.citrix.com/en-us/citrix-app-layering/4/layer/layer-antivirus-apps.html#symantec-endpoint-protection). Do the two reboots after you finish those steps, and then tell the service that you want to bypass the layer check. This is done by a regedit, and navigating to the HKLM\System\CurrentControlSet\Service\Uniservice and adding a DWORD value called BypassLayerCheck and set it to 1. This is documented here: https://support.citrix.com/article/CTX222099 in the final section of the file where it talks about getting the reboot requests. In this case you can do the override because you as the human know that Symantec keeps updating the same file and that the machine is booting correctly with this updated file and thus you can allow the shutdown.
User layer - policy evidence is not updated
in App Layering 4.x
Posted
By default, we only exclude from virtualization keys that we know should be excluded. There are millions of keys that get added to the registry, so we don't know by default which ones have to be excluded until someone actually brings them to our attention.
In this case, this is a key that we were not aware of. But you can add this key to the list of keys that we will exclude by adding a value to your registry to add this key to the ones that you want us to exclude. I would make an OS revision or possibly add a revision to your platform layer where I would imagine you have your VDA code installed. In regedit, navigate to HKLM\System\CurrentControlSet\Services\Unirsd and add a MULTI-SZ value called ExcludeKey. Add the following as you see it here because the strings at the front are key to tell the driver what key to exclude: \REGISTRY\MACHINE\SOFTWARE\WOW6432Node\Citrix\PortICA\Policy\Machine\PolicyInputValues Finalize and deploy new images with the change. That will tell us to skip that key when it is updated when users are logged in. We will in turn add this key to ones that we will exclude by default in later releases (because now that we know about it, we can exclude it going forward).