Есть какие-нибудь советы о том, с чего мне начать в плане ресурсов или видео?
Неурегулированные вопросы:
У меня нет ответа на бит "ресурсы и видео", кроме как направить вас к Веб-сайт Microsoft и предлагаю вам прочитать документация там.
Однако, чтобы ответить на ваши вопросы:
Обычно функциональные возможности RemoteApp используются для обеспечения «внешнего вида» собственного приложения, выполняемого в рамках традиционного пользовательского сеанса Windows «толстого клиента». Я использовал функциональность RemoteApp, например, для доставки приложения «общая файловая база данных» клиентам по WAN. Приложение не могло бы работать через глобальную сеть из-за своей «архитектуры» базы данных, но, поскольку использование функции RemoteApp позволяло приложению появиться удаленным пользователям в качестве собственного приложения на их существующем клиентском компьютере Windows.
Если вы хотите предоставить одно или несколько конкретных приложений пользователям с существующими клиентами Windows, тогда вам может пригодиться RemoteApp. Если вы планируете использовать устройства типа «тонкие клиенты» или не хотите, чтобы у пользователей был «локальный компьютер», то RemoteApp, вероятно, не для вас.
У Microsoft есть документация по функциональности шлюза TS, которая работает очень хорошо. TS Gateway - это, по сути, приложение для прокси-сервера удаленного рабочего стола / протокола TS через HTTPS. Это позволяет вашим пользователям подключаться к сеансам TS (размещенным на выделенном сервере или, как в случае с Windows Small Business Server, например, их выделенных настольных ПК) через ненадежную общедоступную сеть. По моему опыту, большинство проблем, связанных с развертыванием TS Gateway, возникло из-за непонимания требований PKI. Например, использование самозаверяющих сертификатов со шлюзом служб терминалов без развертывания корневого сертификата ЦС для всех клиентов - это рецепт разочарования.
Я заполню это, если вы мне скажете, что вы имеете в виду под "SAV"? Я не знаком с этой аббревиатурой в отношении служб терминалов.
Похоже, вы говорите о доставке Microsoft Outlook через службы терминалов и хотите знать, следует ли настраивать профили MAPI пользователей для использования режима кэширования Exchange. Если это не так, дайте мне знать.
Использование режима кэширования Exchange (файлы OST) обычно является хорошей идеей с точки зрения производительности Exchange Server, при условии, что пользовательский OST не нужно перестраивать снова и снова. OST хранится в «Локальной» части профиля пользователя. В случае среды служб терминалов, если пользователь подключается к одному из многих компьютеров сервера терминалов в «ферме», тогда пользователь может в конечном итоге получать другую локальную часть своего профиля при каждом входе в систему, и вы можете в конечном итоге вызвать много избыточного трафика к Exchange, восстанавливая / обновляя файлы OST. Если ваши пользователи будут подключаться к одному и тому же компьютеру с сервером терминалов для каждого сеанса, то использование режима кэширования данных Exchange не должно представлять проблемы, поскольку локальная часть профиля пользователя будет сохраняться между входами в систему.
В Active Directory нет компьютеров «BDC». Вы действительно имеете в виду, я думаю: «Должны ли мы сделать компьютер с сервером терминалов контроллером домена?» В общем, не следует. Компьютеры с контроллерами домена выполняют очень важную функцию безопасности, и разрешение обычным пользователям выполнять на них код подвергает вас риску. Конечно - если бы ОС была безошибочной, никакого риска не было бы. Однако ни одно программное обеспечение не лишено ошибок, и стоит использовать стратегию глубокой защиты, которая включает в себя запрет пользователям выполнять произвольный код на компьютерах с контроллерами домена.
Если на ваших компьютерах с Windows XP установлена версия клиента служб терминалов, загруженная с Windows XP Service Pack 2 или новее (и вы действительно должны использовать SP3), у вас не будет проблем с использованием RemoteApp на клиентах Windows XP.
Я бы просто начал с Страница Technet. Службы удаленных рабочих столов, новое название роли служб терминалов, домашняя страница проведут вас через оценку ситуации, планирование настройки, развертывание решения и устранение неполадок в случае возникновения каких-либо проблем. Внизу страницы также есть рекомендуемые технические ресурсы по развертыванию Шлюз удаленного рабочего стола, официально известный как шлюз TS. Вы также можете проверить Анализатор передового опыта служб удаленных рабочих столов страница.
Должны ли мы использовать RemoteApp или сеансы
Используйте то, что вы хотите использовать, в зависимости от ваших требований. Без каких-либо подробностей мы не можем дать вам рекомендации.
Понимание и развертывание шлюза TS
Это прокси уровня приложения. Возможно, вам нужно уточнить то, что вам нужно знать, в отдельном вопросе?
Можно ли, чтобы на этом новом сервере выполнялись службы терминалов в качестве нашего BDC?
Терминальный сервер НЕ ДОЛЖЕН находиться на контроллере домена. Вы можете завалить домен, есть вероятность того, что пользователь сможет атаковать ваш DC. Вместо того, чтобы беспокоиться об удаленных атаках, вам нужно беспокоиться об атаках с повышением привилегий. Для работы терминального сервера параметры безопасности снижены.
К вашему сведению: в домене 2000+ нет BDC. Все DC примерно равны.
Можем ли мы использовать удаленные приложения на машинах xp, слышно только для Windows 7, необходимо проверить.
Из: http://technet.microsoft.com/en-us/library/cc753844(WS.10).aspx
Для доступа к программам RemoteApp, развернутым как файлы .rdp или как пакеты установщика Windows, на клиентском компьютере должно быть запущено подключение к удаленному рабочему столу (RDC) 6.0 или RDC 6.1 ...
Программное обеспечение RDC 6.0 доступно для использования в Windows XP с пакетом обновления 2, Windows Server 2003 с пакетом обновления 1 и Windows Server 2003 с пакетом обновления 2.
Как SAV работает с отдельными сеансами (рассматривая их как виртуальные рабочие столы)
Как нам настроить наши профили для osts?
???