Работа в крупных инфраструктурах с использованием терминальных серверов (RDS/RemoteApp) часто преподносит неприятные сюрпризы системным администраторам и специалистам 1С. Один из классических и наиболее раздражающих сбоев — это ситуация, когда после штатного обновления конфигурации (особенно на обычных формах, таких как 1С:Бухгалтерия 2.0) пользователи на некоторых терминальных серверах продолжают видеть старую версию программы. При этом на других серверах фермы всё работает корректно.
В этой статье мы подробно разберем механизмы кэширования платформы 1С:Предприятие в терминальной среде, выясним причины «залипания» конфигурации и рассмотрим наиболее деликатные и эффективные способы решения этой проблемы без вреда для комфорта пользователей.
Для начала проанализируем ситуацию. При запуске сеанса на толстом клиенте платформа сравнивает версию конфигурации, сохраненную в локальном кэше пользователя, с актуальной версией базы данных на сервере 1С. В идеальных условиях, если версии расходятся, платформа автоматически скачивает новые метаданные и обновляет локальный кэш. Однако в терминальной ферме этот механизм дает сбой по следующим причинам:
1cv8.exe завершаются операционной системой принудительно по таймауту. В этот момент файлы кэша (особенно файлы метаданных в каталогах Config и ConfigSave) могут быть повреждены или заблокированы «осиротевшими» процессами. При следующем входе на этот же сервер платформа не может корректно перезаписать поврежденные файлы и молча запускает то, что осталось в рабочем состоянии.AppData\Local\1C из синхронизации перемещаемых профилей. В результате кэш базы данных «намертво» привязывается к локальному диску конкретного сервера RDS. Если пользователь после обновления базы попадает на сервер RDP3, его кэш обновляется. Но если через пару дней балансировщик отправляет его на RDP6, где он не был с момента обновления, платформа пытается использовать старый локальный кэш этого сервера, что приводит к критическим ошибкам.Рассмотрим подробнее, как решить эту проблему, не прибегая к радикальному удалению профилей пользователей.
Самое простое решение, которое первым приходит в голову, — это прописать в дополнительных параметрах запуска ключ /ClearCache. Однако важно понимать: для толстого клиента этот ключ практически бесполезен, так как он очищает только кэш запросов тонкого клиента к серверу приложений, но не удаляет локальные метаданные конфигурации.
Полное удаление папки кэша пользователя решает проблему, но приводит к «холодному» (очень долгому) первому старту и полной потере персональных настроек пользователя (размеры и положение окон, настройки отчетов и т.д.).
Более изящное решение — удалять только кэш конкретной информационной базы, которая была обновлена. Для этого нам нужно сопоставить базу данных с её уникальным идентификатором (GUID).
Разберем этот процесс по шагам:
ibases.v8i, который находится в профиле пользователя по пути %APPDATA%\1C\1cv8\. В нем для каждой базы прописан параметр ID. Например:
ID=6de5e5be-c2f4-40f1-b740-d98c70c042ee
%LOCALAPPDATA%\1C\1cv8\6de5e5be-c2f4-40f1-b740-d98c70c042ee
При таком подходе при следующем запуске 1С принудительно перекачает метаданные измененной конфигурации, но все пользовательские настройки (содержимое файлов *.pfl) останутся нетронутыми. Запуск пройдет быстро и без ошибок.
Постоянно удалять папки вручную в ферме из 6 серверов для десятков пользователей невозможно. Напишем скрипт автоматизации. Оптимально запускать его не при входе пользователя (это увеличивает время ожидания рабочего стола), а при выходе (Logoff) из терминальной сессии, либо запускать регламентным заданием на серверах сразу после обновления конфигурации.
Проанализируем пример PowerShell-скрипта, который находит профили всех пользователей на сервере и точечно удаляет папки кэша конфигурации для конкретной обновленной базы данных:
# Указываем GUID базы данных, которую только что обновили
$TargetGUID = "6de5e5be-c2f4-40f1-b740-d98c70c042ee"
# Путь к каталогу профилей пользователей на сервере
$ProfilesPath = "C:\Users"
# Получаем список всех папок пользователей, исключая системные
$UserFolders = Get-ChildItem -Path $ProfilesPath -Directory | Where-Object { $_.Name -notmatch "Public|Default|NetworkService|LocalService" }
foreach ($Folder in $UserFolders) {
# Формируем путь к кэшу конфигурации конкретной базы
$ConfigPath = "$($Folder.FullName)\AppData\Local\1C\1cv8\$TargetGUID\Config"
$ConfigSavePath = "$($Folder.FullName)\AppData\Local\1C\1cv8\$TargetGUID\ConfigSave"
# Проверяем существование папок и удаляем их
if (Test-Path $ConfigPath) {
try {
Remove-Item -Path $ConfigPath -Recurse -Force -ErrorAction Stop
Write-Host "Успешно очищен Config для пользователя: $($Folder.Name)"
}
catch {
Write-Warning "Не удалось очистить Config для $($Folder.Name). Возможно, сессия активна."
}
}
if (Test-Path $ConfigSavePath) {
try {
Remove-Item -Path $ConfigSavePath -Recurse -Force -ErrorAction Stop
Write-Host "Успешно очищен ConfigSave для пользователя: $($Folder.Name)"
}
catch {
Write-Warning "Не удалось очистить ConfigSave для $($Folder.Name)."
}
}
}
Этот скрипт можно упаковать в групповую политику (GPO) терминального домена и запускать на всех серверах фермы сразу после проведения обновления. Таким образом, к моменту следующего входа пользователей их рабочие места будут гарантированно подготовлены к работе с новой конфигурацией.
Если в вашей терминальной сети развернута современная система контейнеризации профилей (например, Microsoft User Profile Disks или FSLogix Profile Containers), мы можем решить проблему на уровне конфигурации самой системы профилей.
В случае использования FSLogix настроим файл исключений redirections.xml. Мы можем указать системе, чтобы папка локального кэша 1С не сохранялась в постоянном сетевом VHDX-контейнере пользователя, а создавалась локально на диске терминального сервера в режиме «временной папки».
Для этого в файле redirections.xml настроим следующее правило:
<Redirections>
<Exclude Copy="0">AppData\Local\1C\1cv8</Exclude>
</Redirections>
При значении параметра Copy="0" папка локального кэша 1С будет физически создаваться на быстром локальном SSD терминального сервера во время сессии пользователя, обеспечивая максимальное быстродействие. Но при выходе пользователя (Logoff) эта временная папка будет автоматически полностью удаляться операционной системой. При следующем входе (на любой сервер фермы) пользователь получит гарантированно «чистый» сеанс 1С, без старого зависшего кэша, что полностью исключает возникновение описанной проблемы.
Мы выяснили, что проблема «залипания» кэша толстого клиента в RemoteApp чаще всего связана с рассинхронизацией локальных профилей на разных серверах фермы и аварийным завершением сеансов. Для эффективного администрирования этой проблемы рекомендуется избегать динамических обновлений, использовать точечную очистку папок Config и ConfigSave по GUID базы с помощью PowerShell-скриптов при выходе пользователей, либо настроить автоматическое удаление локального кэша средствами FSLogix.