(@stalker_slx)
Reputable Member
Присоединился: 6 лет назад
Доброго времени суток уважаемые форумчане!
1. Имеем свежеустановленный «Windows Server 2019 Standard», который введён в домен.
2. На нем поднята служба удалённых рабочих столов.
3. Настроил, чтобы профили пользователей сохранялись на отдельных виртуальных дисках – «User Profile Disks в RDS Windows Server». Делал по этой статье:
https://winitpro.ru/index.php/2015/04/28/user-profile-disks-v-rds-windows-server-2012/
4. В моем конкретном случае был реализован «второй вариант» из указанной статьи, а именно, чтобы на дисках сохранялись только избранные папки пользовательского профиля («Рабочий стол», «Документы», «Загрузки», «Изображения», «Данные перемещаемого профиля пользователя» и «Данные реестра пользователя»).
Но вот после применения настроек для «User Profile Disks» и перезагрузке сервера, в меню «Пуск» исчезли иконки (в том числе и плитки) и перестало работать вовсе. Для лучшего понимания данной ситуации, привожу скриншот («start_menu_absent_icons.png»)
Гугление по этой теме не принесло результатов по исправлению указанного бага…
Как временное решение (костыль) был написан скрипт, который перезапускает службу/процесс «Проводник» (Explorer) и добавлен в автозагрузку. Эта идея была позаимствована вот тут:
«Что делать, если не работает Пуск в Windows 10»
https://internetua.com/csto-delat-esli-ne-rabotaet-pusk-v-windows-10
Прошу Вашей помощи разобраться в этом непростом для меня вопросе!
Recently I was setting up a new Microsoft Windows 2019 Server image and as part of our onboarding process, we are required to patch and secure any new system. Seeing how Server 2019 is a new O/S in our environment, we didn’t have any automation script to take care of all this. Part of the onboarding consists in either disabling services that are not needed or providing a justification for our baselines. As we were tackling this step, a user reported that the Start Menu wasn’t working. I checked, under my profile I did not experience this issue. Another user who had logged in also did not have the same problem.
I went ahead and started looking up and remembered that we had a similar issue with Windows 10, the fix was making sure a couple of services were running and then running the following command in Power Shell:
Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
Unfortunately that did not resolve the issue for the user. It wasn’t until I tested another server that I started experiencing the issue. The above fix did not work for our Server 2019 image. At this point I decided to get Microsoft involved. We tried different variations of the above fix, a lot of permissions and other things but one thing we noticed that was that the ShellExperienceHost service was not running under affected accounts. No rhyme or reason. We tried local users, other domain users and the issue was there with any new user. Some of the errors that were being logged were ID 69 with source AppModel-Runtime.
The errors would generate any time you left clicked the Start Menu or you attempted to launch Display Settings and they would mention ShellExperienceHost, Cortana or another app.
Below is an example of the error you would receive whenever you would try to launch the Display Settings.
After a lot of back and forth with Microsoft and doing my own testing, it turns out that I disabled a critical service that was the culprit for all these issues. Microsoft tech support did not have this documented anywhere according to the tech whom I worked with, thus me posting this in case someone else runs into a similar issue. The service in question is the Capability Access Manager Service (camsvc). The description for the service states that it handles Universal Windows Platform (UWP) application access and capability. Whatever the case, I’m glad this was resolved after all the troubleshooting we ended up doing.
tl;dr — do not disable the camsvc (Capability Access Manager) service as it will break your start menu and other Windows 10/Server 2019 features.
You find that the Start button does nothing when left-clicked, you still get the Win+X menu when right-clicking.
This article has a great writeup. I have found the solution does work, although users will see a delay when logging off.
Windows Server 2016/2019 RDS Server – Black screen or Start Menu not working
If you are fully patched add the following reg key.
Add “DeleteUserAppContainersOnLogoff” (DWORD) in “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy” and set it to 1.
It’s worth reading the whole article linked above as it explains the issue better and there is a script which can help with removing extra firewall rules that contribute to the issue.
Не работает меню пуск. При этом в журнале можно увидеть ошибки:
Application Error
Путь сбойного приложения: C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy\ShellExperienceHost.exe
или
Сбой активации приложения Microsoft.Windows.Cortana_cw5n1h2txyewy!CortanaUI. Ошибка: Приложение не запустилось.. Дополнительные сведения см. в журнале Microsoft-Windows-TWinUI/Operational.
Пробовал множество способов, описанных в интернете, но ни один из них не помог. После чего успешно разработал свое решение, которое решило проблему. Когда мое решение в очередной раз помогло, решил его задокументировать.
Способ также применим к сценарию, когда само меню ПУСК работает, но не работает поиск в нем.
- Конечно, первое, что следует сделать — это перезагрузиться. В ряде случаев достаточно этой простой рекомендации
- Второй момент, если ПУСК не работает у всех пользователей, попробуйте перезапустить или отключить службу Брандмауэр Windows (подробности в конце статьи)
- Если указанные способы не помогли, следуем дальнейшим рекомендациям.
За ПУСК и поиск в нем в Windows 10 отвечают два APPX пакета: Microsoft.Windows.Cortana_cw5n1h2txyewy и ShellExperienceHost_cw5n1h2txyewy- то есть отдельные приложения
Они располагаются по пути:
«профиль_пользователя\AppData\Local\Packages\Microsoft.Windows.Cortana_cw5n1h2txyewy»
«профиль_пользователя\AppData\Local\Packages\ShellExperienceHost_cw5n1h2txyewy»
Или здесь:
«C:\Windows\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy»
«C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy»
Обычно, если появилась такая проблема, то дата изменения какой-то из этих папок (или обеих) в профиле пользователя в папке Packages отличается от всех других (а те в свою очередь имеют одинаковую дату)
Кстати, при подобной проблеме, скорее всего, есть профили пользователей, у которых на данной рабочей станции ПУСК успешно открывается. Они-то нам и нужны! Либо можно попробовать создать новую учетную запись и осуществить первичный вход в систему с ее помощью и проверить работу меню ПУСК там. Если вы нашли пользователя с работающим меню ПУСК или он работает у вновь созданной учетной записи, переходим к дальнейшим действиям.
Все, что нам нужно сделать, это подменить в проблемном профиле папку «Microsoft.Windows.Cortana_cw5n1h2txyewy»
или «ShellExperienceHost_cw5n1h2txyewy» (или обе) по пути «…\AppData\Local\Packages»
Взять их можно:
- либо из любого «рабочего» профиля
- либо отсюда:
«C:\Windows\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy»
«C:\Windows\SystemApps\ShellExperienceHost_cw5n1h2txyewy»
Старую папку переименовываем, новую копируем в наш проблемный профиль.
Если сделать это не удается (папка используется и т.п.), то нужно завершить сеанс пользователя и сделать эти действия из-под другой учетной записи. Если получается сделать прямо «на ходу» — замечательно.
Перезаходим в профиль — проблема должна быть решена!
UPDATE: после пары случаев поломки меню ПУСК на терминальной ферме с Windows Server 2016, когда вышеуказанный способ не сработал, было найдено еще одно решение по починке работоспособности ПУСКа. Необходимо перезапустить службу «Брандмауэр Windows» (для начала можно попробовать ее просто остановить, чтобы проверить, что дело в ней, но затем нужно ее снова запустить, т.к. без данной службы может не работать ряд фукнций)
Just a brief post today to discuss an issue we recently experienced with a client on one of their Win 2019 RDP Session host servers.
Before we discuss the problem, I’d like to outline the environment and experience the client was having prior to this issue becoming apparent. The server was working fine the previous day and all users were accessing the system without issue. They weren’t experiencing performance issues either and connectivity was optimal. All user profiles are stored in UPDs (User Profile Disks).
One of the users called the help desk and said that Teams and Outlook weren’t opening in their RDP session. We joined their session to take look and thought we’d just log the users out of their RDP session and asked them to log back on. They logged back on, but Teams and Outlook still refused to play nice. While on the users session I tried to access the Start Menu and use the Search field in the Start Bar and neither worked.
Upon checking with other users on the same server, they were experiencing the same issue, no Start Menu or Search field functionality.
I checked the server System Event Log and discovered a lot of DistributedDCOM Event ID 10001 errors. Looking into this a little further it seems that the server couldn’t start the Cortana SearchUI.exe. Here is an excerpt from the event log:
Unable to start a DCOM Server: Microsoft.Windows.Cortana_1.11.6.17763_neutral_neutral_cw5n1h2txyewy!CortanaUI as Unavailable/Unavailable. The error:
"0"
Happened while starting this command:
"C:\Windows\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy\SearchUI.exe" -ServerName:CortanaUI.AppXa50dqqa5gqv4a428c9y1jjw7m3btvepj.mca
Here is a screenshot of the event:
So how do you fix it?
We tried the usual remediation tricks like forcefully logging off the users, checking that the UPDs weren’t locked by another session host server and even rebooting the server to see if we could get Cortana operational again.
The issue is apparently tied to oversized registry keys linked to the server Firewall rules that are created as each user logs on daily. Windows doesn’t trim these and eventually the registry keys become bloated. I found this post… on Reddit that helped solve the issue for us. Many thanks to the user liquidkristal for providing the remediation process.
Before running the batch file outlined below, I’d encourage you to create a GPO for your RDP server(s) to re-apply the necessary Firewall settings to allow connections back onto the server(s) after the registry keys be low are deleted.
You can either check the Firewall settings in your current setup and export and save them or alternatively I’ve shared a link with the necessary RDP Firewall settings for RDP Servers that you can download here… and apply them to your RDP GPO on your domain controller or via the local GPOs of your session host server(s).
Simply create a batch file and save the following registry commands into it:
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules /va /f
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System /va /f
reg delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\AppIso\FirewallRules /va /fgpupdate /force
Now run the batch file as an Administrator and allow it to complete. It will take quite a few minutes to carry out the task so please be patient. Once complete, you don’t need to reboot the server, just ask your users to log off their sessions and their Start Menu and Search functionality will immediately become operational again.
As outlined in the Reddit post by liquidkrystal, they had setup a Scheduled Task that runs the batch file once a month to automatically clean up these registry keys. I haven’t done that as yet as I want to monitor the affects over the coming months. I always think it’s better to be conservative when it come to these things than applying set and forget fixes.
****Update:**** This has been successfully working now for 4 or so months so can be safely applied to your RDP servers
If you’ve found this useful, you may want to sign up to our newsletter where you’ll receive notices on when we post new articles and helpful «how tos». Just fill out your details below and we’ll do the rest…