Wendell Pinegar
-
Posts
24 -
Joined
-
Last visited
Content Type
Forums
Articles
Labs
Videos
TechZone
Citrix Community Articles
Events
Profiles
Posts posted by Wendell Pinegar
-
-
We aren't seeing this behavior with suspended processes in Windows Server 2012 R2 with a XenApp 7.15 CU5 VDA so it seems to be isolated to Windows Server 2016.
-
The issue seems to persist with either KB4534271 installed or uninstalled. And setting DEP to "Turn on DEP for essential Windows programs and services only" also ins't a permanent fix either. It just seems to be a random problem. Not sure why the problem occurs or who is at fault, Citrix or Microsoft. Fortunately it doesn't seem to hurt anything for the process to be stuck in "suspended". Go figure...
-
Changing Data Execution Prevention to "Turn on DEP for essential Windows programs and services only" appears to correct this issue. The issue has not reoccurred on any XenApp server with the DEP setting changed.
-
Windows Server 2016 XenApp 7.15 CU5 servers without KB4534271 also experience the same issue with an occasional leftover "suspended" process. So this seems like a problem that started with XenApp 7.15 CU5 on 2016. Does anyone else see this issue?
-
We've run across an issue with Windows Server 2016 servers with XenApp 7.15 CU5 and the latest Windows 2020-01 Cumulative Updates (KB4534271) applied. The issue appears to be wide-spread but doesn't cause any end user issues that we received reports of. What we are seeing is leftover RDP sessions where there is only a single suspended process (such as iexplore.exe) from an ICA session that has absolutely nothing else running. So it's just a single process. In the attached example "session id 9" shows an example of the issue. The process can't be killed. To clear the errant leftover process the server has to be rebooted. I can open any random 2016 Server and will see one or two of these. The issue ins't occurring on Server 2012 R2 with 7.15 CU5 so I'm guessing that it's a Microsoft KB4534271 update issue. Anyone else seeing this issue?
-
3 minutes ago, Nelson Kaeppel said:
Well, I see this in the support document for it (https://docs.citrix.com/en-us/xenapp-and-xendesktop/current-release/downloads/xenapp-xendesktop-7-18.pdf) - it has a LC number instead of a LD (I have no idea what these mean or what the difference is), but similar description:
The default printer might not be set for non .net applications. Microsoft Windows Server 2016 fails to update the value under the registry key HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\Device when the default printer is the Citrix mapped printer. [LC8984]
Assuming this is the same fix - it does not fix my default printer problem. I had to go back to Windows 2012 R2 as I could not come up with a reasonable fix for 7.18 running on Windows 2016.
NK
LC8984 was Citrix’s first attempt to fix the issue. We agree. I didn’t work. You will need LD1032. Talk with Citrix Support and see if they can confirm which CURRENT RELEASE build has this fix. I’m not seeing this fix anywhere beyond 7.15 CU4.
-
You will need to refer to the release notes of each in XenApp build and look for the fix LD1032:
Microsoft Windows Server 2016 fails to update the value under the registry key HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\Device when the default printer is the Citrix mapped printer. Because of this failure, the default printer might not be set for non-.net applications. [LD1032]
-
1 hour ago, Mike Winspear said:
HI, New user on the boards, but a fair amount of Citrix knowledge, I've been struggling with something similar to this. Was curious about the Powersheel and calling this with the published application.
the Published app I'm having issues with calls a manu launcher which is a fairly simple batch file located on the app server, the user will then select from menu options which app to launch and the batch file will launch the executable of the installed app on the app server and launch.
In order for this powershell to work, I assume I will need a particular set of Citrix Powershell commands loaded on the Application server, as essentially it is running the powershell ON the app server, is this correct?.
There is a fix for this issue in Citrix XenApp 7.15 CU4. This registry key will automatically be set correctly when painting a published app. -
Either rebuild your entire environment just roll back the VDA. If you have a large environment the easiest path forward may be to say on current release until the next LTSR is released.
-
17 minutes ago, Tim Carpenter said:
OK stupid question.. My app wont launch what do I have wrong here.. Cant use the "
Path to Executable:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy RemoteSigned -WindowStyle Hidden -Command & 'C:\Scripts\SetDefaultPrinter.ps1' d:\apps\server\ssi\agvance\agvance.exe
None of the sample powershell code that we posted included a method for passing program to start as part of the powershell script. You would need to create that or simply embed the startup of the published app within the powershell script...it's fairly easy to do basic troubleshooting by logging into the server console and running the command interactively or from a batch file until you get everything working....
-
10 hours ago, Nick Panaccio said:
Have you actually noticed it causing an issue in a Win10 published desktop? Your initial post seemed to indicate that it didn't happen for a published desktop, just a published app.
Yes, we have confirmed that Windows Server 2016, all builds of WIndows 10, and Windows 2019 all exhibit the same problem with the default printer registry key. Not all application use the default printer registry key but for those older apps that do then they simply break or behave unpredictably such as printing to the non-default printer. This issue occurs on published apps or published desktops and occurs with Citrix or RDP session printers. Any network printers or locally defined printers don't typically exhibit the issue. You would need to test to determine if your apps or printers are affected.
-
8 hours ago, Nelson Kaeppel said:
Any suggestions on getting the session to close properly when the user closes the application. I added a -Wait to the end of the Start-Process, but it still leaves PS process running after the user closes the app. If I login at the console and kill the PS process for that user, then the session closes out...so I am pretty it is PS that is keeping everything open still.
If I RDP to the server and manually run the PS script, then close the app - PS closes fine. But in a Citrix published app...it just hangs.
Thanks
NK
Are you letting the Powershell script run in a loop so it can pickup changes to the default printer? If so you can simply check to see if the process that you spawned (the actual published app) is still running or if the process has stopped and exit the powershell script once the spawned process has exited. I have used something similar to the following. Hopefully this code snip-it will help:
# Get the current process.
#
$currentProcess = (Get-Process -Id $pid)
# Start eCW
#
$eCWprocess = (Start-Process $ecwProgram "configuration_personal.xml" -PassThru -WorkingDirectory "$eCWDir")
# Determine if a Powershell script has already started. If it has then exit so we don't start multiple powershell script per Citrix session.
#
$powershellCount = (Get-Process | Where-Object {$_.Path -like "*\Powershell.exe" -and $_.SessionID -eq $currentProcess.SessionID}) | Measure
if ($powershellCount.Count -ne 1) {
[Environment]::Exit(1)
}
# Clear any existing errors.
#
$error.clear()
$registrykey = "Registry::HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows"
# Wait for a predefined period of time.
#
Start-Sleep -Seconds 1
# Set the location
#
Set-Location -Path $registrykey -ErrorAction SilentlyContinue
# Set the default printer for legacy printing.
#
$processeCW = Get-Process | Where-Object {$_.Path -like "*\eClinicalWorks.exe" -and $_.SessionID -eq $currentProcess.SessionID}
while ($processeCW -ne $null) {
# Wait for a predefined period of time.
#
Start-Sleep -Seconds 10
# Retrieve the default printer properties.
#
$wmiDefaultPrinter = Get-WmiObject -query "SELECT * FROM WIN32_PRINTER WHERE Default = TRUE"
# If the default printer exists then set the registry values.
#
if ($wmiDefaultPrinter -ne $null)
{
"Setting the Windows default printer registry key"
Set-ItemProperty -Path $registrykey -Name "Device" -Value ($wmiDefaultPrinter.Name+",winspool,Ne00:")
Write-Host "Your default printer is" $wmiDefaultPrinter.Name
} else {
Set-ItemProperty -Path $registrykey -Name "Device" -Value "Microsoft Print to PDF,winspool,Ne01:"
}
$processeCW = (Get-Process | Where-Object {$_.Path -like "*\eClinicalWorks.exe" -and $_.SessionID -eq $currentProcess.SessionID})
}
-
FYI, Windows Server 2016, all builds of WIndows 10, and Windows 2019 all exhibit the same problem with the default printer registry key. Not all application use the default printer registry key but for those older apps that do then they simply break or behave unpredictably such as printing to the non-default printer.
You can also run the script in the background and place your published app startup toward the beginning of the script. I've created variations of the script to update the default registry key every 5 seconds to it catches instances where the default printer changes after the user launches the published app. Just remember that if you don't put an pause in the script it might execute before the default printer gets created so the default registry key won't be set correctly. Usually you can create the printers before the script published app starts by running the Citrix powershell command "Set-BrokerApplication {APPNAME} -WaitForPrinterCreation:1" and execute once for the published app from a CItrix admin, but it doesn't seem to have any affect on the printers being created before the the Powershell script starts. You are welcome to test it on your version of Citrix XenApp and see if the issue is resolved.
-
Simply start the Powershell script as the executable for the published app and then start the published app at the end of the Powershell script. The following might work well to startup the Script above. I would recommend uncommenting the line #Start-Sleep 5 and adjusting the time the script waits so that the user's default printer is always created before script runs to set the user's default registry key.
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy RemoteSigned -WindowStyle Hidden -Command "& 'C:\Scripts\SetDefaultPrinter.ps1'"
-
There is relatively little direct benefit to rebuilding your entire environment. Just leave the DDC’s and other components where they are and keep them running on the latest current release branch until another LTSR is available in a few years. Then you can switch to the LTSR branch for everything. Until then you can safely install VDA 7.15 LTSR across the board on your machines and the rest of your deployment can stay at mixed release versions.
This is a permitted deployment by the latest Citrix support policy.
-
@chaag1, We're glad that we fix we posted corrects the issue. There are definitely some legacy applications that don't like the default printer registry key being set to blank. Any apps using the Crystal Reports 8.5 runtime seem to have an issue. We had an opportunity to test Server 2012 R2 and it didn't have this issue so the problem only occurs in Windows Server 2016. It's also a problem with basic RDP when the printer is an auto-created session printer. For whatever reason Windows Server 2016 does correctly update the default printer registry key with the correct value when you set a locally attached printer as your default such as the "Microsoft Print to PDF" or "Microsoft XPS Document Writer". Either of these cause "HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Device" to be updated correctly.
We heard back from a Citrix support engineer on this issue and they confirmed with Microsoft that this is a known problem with print subsystem in Windows Server 2016. Microsoft is working on the issue but there is no fix at this time. I don't have a KB article.
Not sure why WaitForPrinterCreation isn't working to set the default printer before the published app starts. That's the whole point of WaitForPrinterCreation is to setup the printers before the app starts. Are you using Citrix UPD/UPS printing or your vendor's native print drivers on the Citrix servers?
By the way, if you don't want to see a black box as your application starts you can use the following to execute the Powershell script as a published app: "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy RemoteSigned -WindowStyle Hidden -Command "& 'C:\Scripts\SetDefaultPrinter.ps1'"
-
1
-
-
One of our published apps that used the Crystal Report 8.5 runtime wasn't working properly. The app crashed every time we tried to print something from one of the built-in reports. In troubleshooting this issue we discovered that the default printer is stored in the registry HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\Device and we found that this registry setting isn't being set if the app is launched as a published app. However, if we launch an interactive desktop session via RDP to the Citrix server the registry key does get set properly. Once this registry key is created and set properly the Crystal Report 8.5 runtime works perfectly and the app prints just fine. Does anyone know why the default printer registry key isn't being set by Server 2016 when we launch a XenApp 7.15 published app?
So we've found what appears to be a bug with Windows Server 2016 and XenApp 7.15 that causes this registry key to not be set if the user launches a published app but it is set if a user logs into a desktop session on the server. To temporarily resolve this issue we've written a Powershell script to set this registry key based on the current default printer when the user signs on and we launch the Powershell script as part of the Published app's startup. We also turn on WaitForPrinterCreation for the published app so that all client printers are created and the default session printer is created by the time the startup script for the published app runs.
Set-BrokerApplication APPNAME -WaitForPrinterCreation:1
# Clear any existing errors. # "Waiting for printers to be created" #Start-Sleep 5 $error.clear() $registrykey = "Registry::HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows" # Set the location # Set-Location -Path $registrykey -ErrorAction SilentlyContinue # Retrieve the default printer properties. # $wmiDefaultPrinter = Get-WmiObject -query "SELECT * FROM WIN32_PRINTER WHERE Default = TRUE" # If the default printer exists then set the registry values. # if ($wmiDefaultPrinter -ne $null) { "Setting the Windows default printer registry key" Set-ItemProperty -Path $registrykey -Name "Device" -Value ($wmiDefaultPrinter.Name+",winspool,Ne00:") Write-Host "Your default printer is" $wmiDefaultPrinter.Name } else { Set-ItemProperty -Path $registrykey -Name "Device" -Value "Microsoft Print to PDF,winspool,Ne01:" } -
We had the same issue with the Start Menu and taskbar items intermittently freezing and in general becoming non-responsive on Server 2016 RDS / XenApp 7.15 CU2 servers (with the profile management component reverted to 7.15 CU1) and found that enabling the group policy "Remove Notifications and Action Center" is what resolved the issue for us. Evidently this is a known issue in Server 2016 RDS and simply hasn't been resolved by Microsoft yet.
Also, we found that setting Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\StateStore\ResetCache to a 1 as described in https://support.citrix.com/article/CTX234144.
Here is how we have profile management configured:
- Excluding everything in the directory !ctx_localappdata! (you may not want to do this but we decided we didn't want anything from AppData\Local except for items that we defined specifically)
- Mirroring configured for !ctx_localappdata!\TileDataLayer (to preserve the user's Start Menu configuration).
- Synchronizing the directory !ctx_localappdata!\Microsoft\Windows\Caches
- Synchronizing the files !ctx_localappdata!\Microsoft\Windows\appsFolder.itemdata* (this one preserves the Start Menu configuration for users on Server 2012 R2 just in case you have both 2012 R2 and 2016 servers.
We haven't had any more intermittent Start Menu issues in Server 2016 since implementing this configuration.
-
Uninstall the 7.16 VDA, run the VDA clieanup utility just to make sure that none of the newer components were left behind, and then install the 7.15 LTSR VDA.
-
@Johan, your issue sounds a lot like a known problem with XenApp 7.6 and RPM.DLL. There were some pretty significant problems with RPM.DLL in XenApp 7.6 RTM that are corrected in 7.6 FP3. Did you try a fresh install of XenApp 7.6 FP3 VDA? Have you tried 7.6 LTSR CU1?
What antivirus product are you running?
-
We are experiencing the same problems in a customers environment
- XenApp 7.8 with one published application (IBM Notes)
- 4 CTX servers (Windows Server 2012 R2) with VDA 7.8 installed
- 1 SF server (StoreFront, Studio, Director) with XenApp 7.8 installed
All servers are Windows Server 2012 R2 (virtual on a VMware environment).
This issue occurs almost daily, so I have to put one server in maintenance mode and reboot it every day. That is not how it should be.
When this problem occurs, I see this in Taskmanager (also see screenshot)
(4)
Client Server Runtime Process
Desktop Window Manager
Windows Logon Application
Windows Logon Users Interface Host
I can't see the sessionname in TaskManager, but I can stil see the session in the Director.
It also happens sometimes that the server crashes and reboots when I'm working on this problem.
@Johan,
Instead of going to the Processes tab in Task Manager go to the Details tab. Right-click on the column heading and choose Select Columns. Choose to show the Session ID then sort the processes by Session ID. What processes are still running for the sessions that are hung? Have you tried killing some the sessions associated with the processes to see if the hung session will close?
M365 Apps for Business on Server 2019 VDA asks Users for "signing in to set up Office"
in XenApp 7.x
Posted
Thanks for your post. It helped resolve an issue we were having with Office 365 published apps not activating. Your fix was accurate and resolved the issue. We also found that Office 365 was locking up when it was running as a published app. We had to disable Office 2016 hardware graphics acceleration via GPO to resolve that particular issue.