Столкнулся с такой проблемой — на терминальных серверах профили пользователей имеют огромные размеры, при том, что рабочие столы, папки документов — перенаправлены в сеть и не участвуют в этом безумии.
Стали разбираться и накопали несколько причин, о чем и хочется рассказать ниже.
- в первую очередь конечно это непомерные кеши 1C v8. Если кто не знает — эта чудо-программа при работе пользователей кеширует одной только ей известную информацию и делает это столь яростно, что папка %Userprofile%\Local Settings\Application Data\1C\1cv8 может разрастаться ну просто до неприличия. 10-20-30 гигабайт — это не предел :). Решение довольно простое — чистить кеш, что можно сделать двумя способами:
- принудительной раздачей ключа /ClearCache при прописывании базы 1С (это можно сделать и позже добавив в файл списка баз параметр AdditionalParameters=/clearcache дял каждой из прописанных баз. У нас раздача баз осуществляется скриптами, поэтому раздать всем принудительно этот ключ было довольно просто.
- Просто жестко чистить содержимое папки %Userprofile%\Local Settings\Application Data\1C\1cv8 при выходе пользователя из терминального сеанса. Ничего там особо важного нет — катастрофы не произойдет. Опять таки решается все скриптами, повешенными на Logoff пользователя.
- Дальше было интереснее: кроме 1С-кешей обнаружилось, что у многих пользователей в профиле лежит файл %UserProfile%\Local Settings\Application Data\Microsoft\Windows\WindowsUpdate.log которого там во-первых быть не должно, а во-вторых он ну просто неприличных размеров (я видел в 1,5 Гб). Суммарно при большом количестве пользователей это дает весьма ощутимый рост впустую потраченного дискового пространства. После недолгих поисков, выяснили что такая ситуация возникает, когда пользователи видят сообщения о необходимости перезагрузки сервера но не могут его перегрузить (все вроде нормально, да, на это есть админы). Так вот сообщения о том, что «сервер должен быть перезагружен, но пользователь этого не сделал» (а если цитировать, то «AU client got new directive = ‘Reboot Pending’, serviceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, return = 0x00000000 AUClnt WARNING: Shell_NotifyIcon failed (dwMessage=0x0, uFlags=0x3, hr=0x80070002)») и занимают 99% этих файлов. Решение опять таки несложное — сделать так, чтоб пользователи не могли видеть этих сообщений — в групповой политике есть специальный параметр «Remove all access to use Windows Update features». Тут важно не переусердствовать и оградить админов от действия этой политики, чтобы они-то как раз видели и реагировали на такие сообщения. Сделать это можно ну например с помощью групп безопасности (если грубо, то: применить политику для всех — кроме админов). Ну и пройтись по профилям пользователей и поудалять все уже созданные файлы WindowsUpdate.log. Если профилей много — то проще это сделать несколькими строчками скрипта
$ChildF = Get-ChildItem "C:\Documents and Settings"
foreach ($CountFolder in $ChildF)
{
If ($CountFolder.GetType() -eq [System.IO.DirectoryInfo])
{ remove-item -Path ($CountFolder.FullName + "\Local Settings\Application Data\Microsoft\Windows\WindowsUpdate.log") }
}
После локализации и устранения этих двух основных «поедателей пространства» — ситуация на терминальных серверах нормализовалась.