Комментарии 21
Для реальной оптимизации советую воспользоваться бесплатной утилитой от VMWare — "
VMware OS Optimization Tool".

Может, я что-то не понимаю в администрировании, но 90% этой статьи можно реализовать за минуту средствами RDS с помощью RemoteApp, раз уж у нас цель — дать возможность работать только в определённых программах.

а если у тебя сотрудники работают из дома?, или нужно выгружать 1с отчеты из одной программы и загружать в другую, или организовать общую директорию, это бесспорно можно реализовать настраивая на каждом компе в отдельности, но единое место работы сотрудникам это не даст и вызовет гору проблем в администрировании, хотя возможно я и не прав
Если сотрудники работают из дома, и вам нужно именно Remote Desktop, то рекомендую разделять настройки удалённого подключения извне и изнутри локальной сети.
И вообще, есть же VPN. И на RemoteApp для пользователя всё намного прозрачнее будет.
Зачем? Если для конечного пользователя важно иметь именно «полноценный доступ» (ну чтобы что дома у него рабочее место, что на работе), то смысл?
Разделять. Remoteapp в условиях одного удаленного приложения упрощает жизнь и к нему у меня нет претензий. Вспомните alt+tab в RDP классическом.
Если требуется сделать удалёнку изнутри сети (терминальный сервер), но снаружи сотруднику она без надобности, то тут однозначно разделять стоит, а не плодить точки входа.
1. В здравом уме голый RDP ни кто в инет не пустит. Если он так сделает, то мне с ним и разговаривать не о чем.
2. Внутри, снаружи. Нет разницы. От админа одно из требований — сделать удобно. Если есть возможность сделать для пользователя прозрачной работу приложения, то почему и нет? В свое время я своим пользователям (им от удаленки надо было 1 приложение только) сделал remoteapps. Им очень понравилось. И когда к этому 1 приложению появилось второе которое в классическом rdp работало, а в remoteapps нет, то они очень холодно восприняли тот факт что remoteapps больше не будет.
И зачем «плодить точки входа», когда сервер один?
Часто ли в продакшене используются диски пользователей? Имхо по классике хранить и обслуживать профили гораздо проще

До сих пор есть неприятный баг с отваливанием дисков пользователей при определенных обстоятельствах, приводящих к дублированию их и слетанием настроек. В итоге перешел на профили

А чем не устраивает публикация на веб сервере клиента? Для VPN отличный вариант.

Так же в сети есть очень неплохие bash скрипты (которые можно под себя подправить), за 5 минут делают готовый к работе 1с сервер на centos с всеми плюшками и уже оптимизированным и настроенным psql, бэкапом по расписанию в сеть и.т.п
Могу предположить что у них набрано или тонких клиентов или мертвых нетбуков в качестве рабочих мест. Плюс опять же а как быть когда 1с — это лишь одно из зол? А еще может какой-то из зол не умеет нормально в удаленку? К примеру вот только кум звонил. У него 300 пользователей на удаленке. Прилоржение клиент-серверное. В условиях rdp даже на 10 метровов канале норм при X пользователях, в то время как в клиент-серверный На таком канале даже 1 юзверь уже не жилец.
Из приведённого вами примера про rdp, скорее всего слабое место софт или его настройки. Я в таких случаях иду по наипростейшему пусти suppor@разработчик.домен. Если с разработчиком беда, смирится и жить или искать аналоги.
Я так и предположил. Скорее всего каждый раз отдаются все сведения (к примеру все содержимое справочника от сервера клиенту). И клиент скорее всего довольно часто на пустом месте дергает сервер. Ну активность там дикая.
Сложность в том что разработчик в этом плане был не много не готов и текущее количество костылей не позволяет им вот так решить проблему. Да хотя бы какое-то исскуственное ограничение на 3 одновременных запуска из одного каталога. В пределах сессии запусти хоть 100 копий, но все должны быть из разных каталогов…
Спасибо. Нет и тут конечно вода-водоую. Но уже «интереснее». ИМХО — подготовить курс заранее с разделением по главам. И уделить внимание разницам. К примеру чем лучше профили пользователя, а чем лучше диски. или тот же запрет запуска приложений.
Еще мы сразу в омут с головой прыгаем в ГП, но до этого не сказано ни слова о том как сразу организовать красиво эту ГП. Ведь «завтра» переезжать скажем на деления по филиалам… а тут изначально такая каша уже с ГП…
Будем ждать, самое интересное дальше
1. рассмотрим настройку 1с,
2. разграничения доступа к базам, — и надеюсь это не банальные права на томе NTFS
3. поднимем производительность 1с на терминальном сервере фактически в двое
пока ни о чом
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.