[XenApp slow logon times, user get black screen for 20 seconds.]

Ahh okay- that makes sense. Do you know if there is some sort of ID or KB number for this private fix? Just so that it might easier for the support to know which private fix that I need :)

 

Sorry I missed this. You can reference my case number (72441495).

[XenApp slow logon times, user get black screen for 20 seconds.]

Hi,

I have tried implemeting the registery settings and UPM exclusions and the login time is now much, much faster now.

But the start menu is now empty - no shortcuts or anything. We don't use classic shell - just the native Windows 2012R2 start menu which is folder redirected to a central folder on our file server.

Has anyone else experience this?

 

I mentioned that this will happen in my fix. You are bypassing the refresh of that database. The actual fix that Citrix has for UPM will only initiate the refresh when it is needed and as long as you have the necessary files in UPM the start menu always works. I tested it with them and let them know to document what needs to be in UPM for it to work. A lot of us use an alternate start menu shell like Classic Shell since the Windows 2012 R2 start menu is garabge. Since you know that this is your issue you should request the private fix from them. The private fix is just the UPM exe with the patched version. Then you have to ensure you are bringing over 'AppData\Local\Microsoft\Windows\Caches' in UPM along with the 'AppData\Local\Microsoft\Windows\appsFolder.Itemdata-ms' file. The appsFolder file actually is the trigger. If UPM sees this the patched version of UPM will not initiate a full refresh of the cache. If it is not there it will initiate it.

[XenApp slow logon times, user get black screen for 20 seconds.]

Ok, Citrix finally came with privates that fixed the problem. I showed them Mark's registry fix & after 2 months, their development did a registry hack & released new userprofilemanager.exe for 5.5 & 5.7. This fixed the issue & need to add registry. As per them, this will be added in the future release.

 

I have this fix and it is basically just not setting the refresh registry value. I am working with as we speak though because technically as far as I can see this isn't a full fix. Just like my fix the native start menu doesn't work after the first logon for a profile. This may not work for some users.

[XenApp slow logon times, user get black screen for 20 seconds.]

i already try it. Nothing changed :(

 

Please follow the steps laid out earlier to confirm that you actually are having this specific issue. You can verify this by looking at event logs.

[XenApp slow logon times, user get black screen for 20 seconds.]

Got the same Problem and its really screw me up.

 

Is there any way to get that private fix?

 

Login times push from 8 seconds to over 30 ! :-(

 

You can use the fix that I posted while the official fix is being developed. It has been working for myself and others.

[XenApp slow logon times, user get black screen for 20 seconds.]

Here is an update to something that has appeared to have finally resolved the issue for me anyway.

 

I used Option 2 from the following Unidesk article (disable App Readiness service).

 

https://www.unidesk.com/support/learn/2.7.0/deploy/create_desktops/deploy_desktop_create_nonpersist

 

Once this sevice was disabled, I no longer see the black screen phase.

 

I have seen this. I had ruled App Readiness out and was not seeing a delay with that, but some people have reported it. It does start pre-shell. Citrix is actually working on a private fix for the UPM issue. They sent me the fix, but I am waiting for more information on it before I try it.

[XenApp slow logon times, user get black screen for 20 seconds.]

Hi Mark,

 

I have made the changes and I am seeing the following:-

 

Black screen phase now between  0-13 seconds which is much better than before.

 

so with or without UPM I am seeing this behaviour.

 

I have doubled checked to make sure my batch file to delete the registry entry works and it does at logoff.

 

Should I be expecting no black screen phase at all?

 

It depends. I have seen on a Windows machine running Receiver that as soon as I connect to a published desktop I get a black screen. The entire logon is masked with a black screen, including what you would normally see when logging onto a computer locally (loading profile and all the other statuses). If Explorer has been launched and you still have a black screen for 10 seconds then this is not working for you. I can actually see the flash where Active Setup launches the fix and right after I see that my desktop loads. I you can see that flash and still have a delay after that then there is something going on. If you see a black screen UP TO that and then it loads right after then the delay it out of scope of this issue. I actually don't like that Receiver masks the regular loading status. On my Linux client Receiver actually shows the Windows 2012 logon status, so you aren't wondering what is going on.

[XenApp slow logon times, user get black screen for 20 seconds.]

That's right Mark.

 

I have just had that confirmed with FSL support (you need the more expensive FSLogix Apps product to do this) so I will try and use a logoff script to remove the entry instead.

 

Wouldn't hurt to also add a registry key delete via GPP. That way the key will delete during GPO refresh, that combined with the logoff script should work in most situations.

[XenApp slow logon times, user get black screen for 20 seconds.]

ok thanks.

I put a logoff script to remove HKCU entry on existing UPM profiles (upm registry exclusion was made after the reg hotfix)

 

I believe UPM REGISTRY exclusions added after the fact will take effect after a logon cycle, but putting the logoff script will not hurt anything.

[XenApp slow logon times, user get black screen for 20 seconds.]

Hello Mark,

 

about the registry exclusion, we should exclude "HKCU\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\StateStore" and not "HKCU\SOFTWARE\Microsoft\Active Setup\Installed Components\DisableUPMResetCache".

Right ?

UPM registry exclusions apply only for HKCU.

 

No need to exclude anything in StateStore. You NEED to exclude the following:

 

Directory - '!ctx_localappdata!\Microsoft\Windows\Caches'

Registry - 'SOFTWARE\Microsoft\Active Setup\Installed Components\DisableUPMResetCache' (HKCU)

[XenApp slow logon times, user get black screen for 20 seconds.]

Hi Mark,

 

I will need to see if FSLogix supports this.

 

If not, I guess a logoff script to delete the HKCU entry should take care of it right?

 

Technically yes, but if you have a session that doesn't log off properly then you would run into the issue of the fix not running the next time. The best method for this is to exclude the key from profile management. I am fairly confident FSLogix will support this. Any profile management tool has to have this functionality. I implemented ProfileUnity at my last company and needed to use that constantly. I also use it at my current company with UPM.

 

I tried looking at their documentation, but it seems to be lacking: https://docs.fslogix.com/display/FA26/Profile+Configuration+Tool. I see you can exclude directories, but can't find how to configure registry exclusions.

[XenApp slow logon times, user get black screen for 20 seconds.]

Hi Mark,

 

Ran RSop.msc which looks OK.

 

Also checked the permissions regarding access to the registry editing tools which is set to Not Configured which I guess should be fine.

 

Please find attached screenshot of the ActiveSetup registry entry from HKLM and HKCU (which does not have the stub reference).

 

So, one thing I want to reiterate e is that the HKCU path should technically be there if it ran, but if that path is persisted through UPM or any other profile management then the fix will not run again. This is why it is important to exclude the HKCU path from UPM or any other profile management (ex. FSLogix). ActiveSetup is designed sort of as a RunOnce mechanism. Once it runs it stamps the HKCU key so that it doesn't run again. The only way to get it to run is to remove the HKCU key OR change the 'Version' value in the HKLM key. We exclude the HKCU path so that ActiveSetup will run the command every time.

[XenApp slow logon times, user get black screen for 20 seconds.]

Sorry to be a pain Mark,

 

How would I go about troubleshooting my GPO settings if reg.exe is being blocked?

 

Would it be possible to share screenshots of your working setup?

 

Do a GPO RSoP of the server/user combination. Check for the 'Prevent access to registry editing tools' GPO setting under User Configuration > Administrative Templates > System.

 

Also, post a screenshot of your Active Setup registry key.

[XenApp slow logon times, user get black screen for 20 seconds.]

For me the active setup method never worked. Powershell script worked which is only to prove the reset cache is causing the issue.

 

Either it was setup wrong or GPO is blocking reg.exe.

[XenApp slow logon times, user get black screen for 20 seconds.]

 

OK, I thought I would summarize my environment again and list out all the suggested changes to make sure I have not missed anything out:-

 

Environment

XenApp 7.11

Publishing Server 2012R2 Desktops

Using Classic Shell

 

Config Changes I have applied

On gold image server applied the following registry fix:-

 

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\DisableUPMResetCache]

@="DisableUPMResetCache"

"Version"="1,1,1,1"

"StubPath"="REG ADD HKCU\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\StateStore /v ResetCache /t REG_DWORD /d 0 /f"

"Locale"="*"

 

VIA GPO, I have applied the suggested changes via GPO (see attached).

 

With the various changes via the GPO I did not think I needed to apply the following Powershell script Mark has referred to, namely:-

 

While ($true) {

reg query \\#SERVERNAME#\HKU\#USERSID#\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\StateStore /v ResetCache

reg add \\#SERVERNAME#\HKU\#USERSID#\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\StateStore /v ResetCache /t REG_DWORD /d 0 /f

Write-Host ""

Start-Sleep -Milliseconds 100

}

 

 

If I still need this, what is the best way to automate the distribution?

 

I wouldn't do a DELETE on StateStore via GPO. You can never guarantee that the GPO will apply BEFORE the shell is loaded. If you already applied my 'Active Setup' changes then those take care of that. You also have to apply the #2 and #3 changes I laid out here: https://discussions.citrix.com/topic/381735-xenapp-slow-logon-times-user-get-black-screen-for-20-seconds/?p=1955157

[XenApp slow logon times, user get black screen for 20 seconds.]

I have a Citrix support ticket for this for more than 2 weeks now. They tried everything but nothing fixed the problem. Took CDF & other proc mon logs. I also showed them how changing the value of registry using script is fixing the problem. Ticket is now escalated to other tiers.

 

Good tohear. I think they'll be on this very soon. I had this escalated very quickly to UPM engineers on Wednesday.

[XenApp slow logon times, user get black screen for 20 seconds.]

i'm trying alternate method of changing permission on the "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\StateStore" key.

As now seem much faster. I Will continue my tests.

Seems like that would accomplish the same thing, but I wouldn't want to restrict the OS from accessing or writing to the whole key. Not sure what other implications there are for that. Preventing just a change to the one value is the most direct workaround.

[XenApp slow logon times, user get black screen for 20 seconds.]

Mark,

 

I have made the changes as suggested and have seen a slight improvement.

 

Now for the weird stuff.

 

Using the same set of GPOs I built another Machine Catalog from the same Gold Image I use for my production site except this Catalog only has a single server (the production has 20).

 

The black screen phase does not appear in the MC with a single server only the MC with multiple servers in.

 

 

Did you verify the policies are applied properly from HKLM\software\policies\citrix\userprofilemanager?

 

FYI, I have opened up a support case through alternative channels to get more eyes on this issue. It looks like it is going to move along quickly.

 

That is weird that the catalog from the same image is faster. Definitely check that the exact same set of GPOs are applying.

[XenApp slow logon times, user get black screen for 20 seconds.]

Mark,

 

I had the exact issue of 47 seconds (xenapp vda 7.11/12/13 on W2k12) of overall log on time with 20 seconds of black screen. Tried your powershell script to execute from a remote computer to reset the cache, the black screen was now down to 2-3 seconds instead of 15-20 seconds. What's next to fix this permanently?

 

Regards,

Balaji

 

Great to hear this is working for other people. The temporary fix is to put in my Active Setup registry patch. I'm going to try to reach out to Citrix through alternate channels to get some higher tiers to look at this.

 

 

Ran procmon, userprofilemanager.exe is setting the cache value to 4 & finally explorer reset it to 0.

 

That is what happens, yes.

[XenApp slow logon times, user get black screen for 20 seconds.]

@Christopher Yue

 

Are your vm's PVS or MCS based? Cause I can confirm that with the second login. The first login takes about 20-30s but the second login is below 10s.

 

 

MCS.

 

Local profiles are deleted on logoff after a 1 minute delay.

 

If a user logs off and back onto the same server before the local profile is deleted, then the login is quick without the black screen.

 

The next thing I might try is disabling Classic Shell and return back to the native Start Screen and test again.

 

Could you both try this? I suspect that the ActiveSetup registry values I gave you aren't actually executing properly for some reason. This is what I initially did before creating the ActiveSetup fix to test my theory...

 

1.) Determine the AD SID of the user

2.) Isolate the user so that they launch the desktop only on one server and make sure there are no current profiles for the user on this server

3.) Ensure the 'Remote Registry' service is enabled and started on the server

4.) Launch PowerShell from another computer that has admin privileges on the affected server

5.) Run the loop below in PowerShell:

 

While ($true) {

reg query \\#SERVERNAME#\HKU\#USERSID#\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\StateStore /v ResetCache

reg add \\#SERVERNAME#\HKU\#USERSID#\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\StateStore /v ResetCache /t REG_DWORD /d 0 /f

Write-Host ""

Start-Sleep -Milliseconds 100

}

 

6.) Launch the published desktop as the affected user.

 

 

This will basically go in a fast loop querying and changing the 'ResetCache' value back to 0. It will give output on what the value was before changing it. The new value of '0' should register before Explorer loads and reads it avoiding the 'AppResolver Scan'. If this speeds up all logons for the user, then we know ActiveSetup wasn't working for you and that can be diagnosed separately.

[XenApp slow logon times, user get black screen for 20 seconds.]

No, published apps are working pretty fast. You also have ClassicShell installed on your W2K12 desktops?

 

I noticed that my MCS based desktops dont have this massive black screen phase, like the PVS based desktop. Both desktops are in the same AD OU, so they use the same GPO's.

 

But thanks for the hint about the Shell-Core log, I will check that later.

 

Edit: I just checked it, the regkey was added with the ActiveSetup, saw it in the shell core log. I also checked how long it takes until the first LogonTasks were started and when the "AppResolver finish" log info was created. It took about 47s for those tasks and I saw a lot of entries about "shortcut blablabla added to app resolver cache."

 

I use Classic Shell for my Win2k12R2 VDAs. If I eventually move to 2016 I'll go back to native, but the Windows 8 style menu is unacceptable for users coming from a Win7/Win10 world.

 

If that is taking 47 seconds then most likely the registry value isn't taking effect. I do notice that AppResolver runs more than once (after shell has loaded and the person is logged on), so you have to be sure that you're looking at the first instance of AppResolver associated with that specific logon. You should be looking at the time between these:

 

-Start-

Event ID 62170 - Logon task 'AppResolver' started with flags 1034.

Event ID 28125 - Starting to refresh app resolver cache for scenario 2 with flags 79.

........

-Stop-

Event ID 28018 - AppResolver Scan Stopped.

 

You have to be sure you are looking the first instance for that logon session. Also look at excluding 'AppData\Local\Microsoft\Windows\Caches' from UPM and wiping from an existing user.

[XenApp slow logon times, user get black screen for 20 seconds.]

Just changed it to this, but the result isnt that good, specially it's not very constant. Sometimes it's really fast, after a reboot it takes again between 30 und 300s. Only when I log in with a temporary profile, then it's super fast.

 

Are your W2K12 VM's also PVS based?

 

I am using MCS. Like I said in earlier posts, I would look at the 'Microsoft-Windows-Shell-Core/Operational' event log. This gives a lot of information on timing during shell load. It is very clear in this log if this specific issue is affecting you. Also, do you get the same delay when launching a seamless application? If you do, then it is not shell related. My issue was specifically with published desktops (seamless applications were OK), so that alone pointed me in the direction of looking at the shell. Another thing to verify is that silent regedit changes are allowed in your environment. Active Setup could be running, but the required registry change might not actually be happening.

[XenApp slow logon times, user get black screen for 20 seconds.]

Thanks for that hint.

 

When I run this reg.key the login is really a bit faster. I added your regkey on the master image, but I'm not sure if the key was added correctly.

 

The "StubPath" key is missing on the "DisableUPMResetCache" folder inside the registry as visible in the attached pic.

 

Is that correct or do I have to add the stubpath?

StubPath needs to be there. That is the string that actually defines what needs to be run. It should be called "StubPath" with a type of REG_SZ. The value should be: "REG ADD HKCU\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\StateStore /v ResetCache /t REG_DWORD /d 0 /f".

 

[XenApp slow logon times, user get black screen for 20 seconds.]

Where do I exclude:

 

SOFTWARE\Microsoft\Active Setup\Installed Components\DisableUPMResetCache

 

In the user profile group policy I only see Exclusion lists for files and directories?

 

Computer Configuration > Administrative Templates > Citrix Components > Profile Management > Registry > Exclusion list

 

The folder exclusion would be there under: Computer Configuration > Administrative Templates > Citrix Components > Profile Management > File system > Exclusion list - directories

[XenApp slow logon times, user get black screen for 20 seconds.]

I'm going to try this today!  Well done, hope this works too.

 

Where did you add DisableUPMResetCache.reg just on a new GPO?

 

I did it through GPP for now and may just move it it to my MCS image, but you can apply the .reg directly to your worker server(s). Also, you can look at the event log I mentioned on the server to see if this same issue is happening to you.