“Попытка входа в систему привела к сбою” для TS (RD) Аутентификацию Шлюза
Посмотрите вопрос № 4 страницы для ЦП-Z для наблюдения, почему это могло бы неверно передать, какую RAM Вы установили. Если Вы глазное яблоко, Ваша RAM, большая часть RAM, проданной в последние годы, имеет этикетку на нем, которая говорит точно, каково скорость это.
Вы сказали, что ЦП-Z сообщил о Вашей памяти как:
- Частота DRAM 200 МГц
- Задержка CAS 3 часов
- RAS к CAS задерживают 4 часов
- RAS предварительно заряжают 4 часов
- время цикла 8 часов
- время цикла банков 12 часов
- уровень команды 1T
- DRAM Неактивный Таймер 16 часов
Из этих чисел два с самым большим единственным влиянием на скорость доступа к памяти являются первыми двумя выше, скорость системной шины (200 МГц x 2 для DDR = 400 МГц) и задержка CAS. Однако Вы спросили, делает это означает, что у Вас нет DDR-II 667 - это зависит от того, поддерживает ли Ваш ЦП уровень системной шины 667.
В комментарии Вы сказали, что это - сервер, который Вы не можете выключить или перезагрузка, чтобы сделать эту проверку. Таким образом в ЦП-Z, посмотрите на вкладку SPD. SPD (Последовательное Присутствие Обнаруживают) является способом считать информацию о памяти от памяти. Это должно сказать Вам производителя, модель, номер детали, макс. пропускную способность, позволенную синхронизации для различных частот шины, и так далее. Можно посмотреть на каждый слот памяти и сказать, какая память находится в каждом положении.
В ЦП-Z на вкладке "Memory" это просто говорит Вам, как BIOS и ОС решили настроить тайминги памяти, на основе рассмотрения всех микросхем памяти и на основе конфигурации BIOS. Вкладка "SPD" говорит Вам точно, к чему карты памяти, которые Вы имеете, способны.
Сервис окон Terminal Services Gateway продолжал перестать работать для нас.
В отсутствие чего-либо полезного в конечном счете регистрируется, я просто получаю планировщика задач к "сетевому запуску tsgateway" несколько раз каждый час. Ужасные, но нулевые жалобы с тех пор.
-
1Ха, у меня также была та проблема, когда я сначала настроил это - конечный пользователь будет видеть " терминальный сервисный сервер шлюза временно unavailable"? сервис, кажется, запускается прекрасный, перезапуск сервиса doesn' t решают мою проблему также. – user2059 15 May 2009 в 17:03
Эта проблема заполоняла меня в течение многих месяцев на машине 2008 SBS, но никогда не была достаточно очень важна для движения в сумасшедшие меры для фиксации.
После обращения к удалению и переустановке сервиса Шлюза TS и этого все еще работа, я перешел к менеджеру по IIS → Сайты → SBS веб-приложения → Rpc → Аутентификация и нашел, что только "Стандартная аутентификация" была включена.
Хотя детали об этой конкретной ошибке недостаточны онлайн, я видел, что Outlook Где угодно, кажется, изменяет Схемы аутентификации IIS. Так как это - SBS, я изобразил Exchange, и Шлюз TS мог бы биться за настройку аутентификации.
Я включил "аутентификацию Windows", затем выполнил сброс IIS. Когда IIS возвратился онлайн, я смог соединиться через Шлюз TS с двумя серверами и по крайней мере одной рабочей станцией. Я соединился и разъединился многократно, и это не имело никаких проблем.
Я не могу гарантировать, что это является постоянным, но я определенно надеюсь.
Править: Начиная с внесения этого изменения у меня не было проблем со Шлюзом TS.
У меня была подобная проблема. Я нашел, что должен был отредактировать менеджер IIS → Сайты → SBS веб-приложения → Rpc С Сертификатом → Аутентификация и добавил аутентификацию Windows. Затем выполненный и IISRESET и все работали, как он должен.
Если у Вас есть эта проблема о 2008 SBS, я предлагаю использовать комбинацию SBS 2 008 Лучших практик, Анализатор и Консоль SBS "фиксирует мой сетевой" мастер (Сеть->, Возможность соединения-> Фиксирует мою сеть). SBS является привередливым и будет иногда переопределять вручную скорректированные настройки так лучше использовать мастера, если это возможно.
В моем случае BPA заявила для выполнения, "получают-outlookanywhere |set-outlookanywhere-iisauthenticationmethods основной, ntlm-clientauthenticationmethod основной" в управлении Exchange, Shell и "фиксирует мой сетевой" мастер, также сделал исправление.
Имел те же точные проблемы как исходное сообщение. Я также перенаправлял веб-сайт по умолчанию к/RDWeb/Pages/en-US, после того как я взял то перенаправление от всего, работал нормальный.
Я изумлен, как это даже вызвало проблему во всей честности.
Хорошо вот ответ?
2k8r2 и iis7
TSGateway неоднократно просит учетные данные, но не входит в систему...
Оказывается, что TSGateway не делает соединения и аутентификации, IIS делает. Удивление, Ya я знаю ….
TSGateway только фильтрует и направляет.
Так, Теперь, какая часть IIS делает соединение и аутентификацию для TSGateway? Я не знаю. И по-видимому, никто больше действительно не делает также. Но если Вы смешиваете с Настройками аутентификации RDWEB, RPC, RPCWCERT, ВЕБ-САЙТА По умолчанию, Authdiscover, можно заставить его работать …
Это - хорошая статья. Но как Вы видите, это - выстрел в темноте с ними также.
Примечание: По-видимому, перенаправление веб-сайта По умолчанию повреждает коммуникацию к RDWeb и поэтому TSGateway.
HTTP – Перенаправление HTTPS …
Похоже, что мой веб-сайт по умолчанию стал HTTPS, но я хотел, чтобы это было достижимо от Пользователей HTTP. Таким образом, я создал веб-сайт перенаправления для перенаправления Запросов HTTP к веб-сайту По умолчанию как HTTPS. Который работает отлично, но это остановило мою аутентификацию TSGateway. (Я думаю, что это было, потому что порт 80 использовался веб-сайтом перенаправления. И по некоторым причинам, RDWEB использует порт 80, а также 443 для связи …),
Между прочим, если Вы выключаете, Требуют SSL в Настройках SSL на веб-сайте по умолчанию в IIS, он действительно работает правильно и делает то же самое …
Во всяком случае запустите, покупают получение RDWEB, работающего правильно затем, работы над TSGateway.
RDWEB должен иметь только: Анонимная аутентификация, Включенная AutoDiscovery, должна иметь Анонимную, Основную и Включенную аутентификацию Windows. OWA: Основной Только. RPC: должен иметь: Стандартная аутентификация и аутентификация Windows. RPCWCert: Ничего не должны включать. В арендном договоре это - настройки в Моей установке …
Удачи.
Robert
У меня была подобная проблема. Экран Входа в систему Шлюза просто продолжил сование. Журналы безопасности сервера показали специальный вход в систему полномочий, вход в систему и выход из системы для каждой попытки. Журналы шлюза ничего не показали.
После попытки всего я заметил, что область у основания шлюза входит в систему экран, который должен показывать, что домен был пробелом. Я добавил домен к экрану входа в систему имени пользователя: domain\username и вуаля, все это работает, как это должно.
Это было пустой тратой приблизительно 4 или 5 часов моей жизни, ищущей решения, и пробующий сложный фиксирует... Надежда это экономит кому-то еще некоторое время...
У меня был запрос в службу поддержки MS, идущий, таким образом, я сделал, чтобы они посмотрели на это. Они просто изменили перспективу где угодно для NTLM и ВИОЛЫ!
Same problem for me too, SBS2008 suddenly started reporting "login failed" whenever the TS Gateway was used. Found that the RPCwithCert site in IIS had no authentication method, ticked Windows Authentication and it works again now....
У меня все было настроено для SSO, затем я внес несколько изменений, и все сломалось. Я мог попасть на сайт RemoteApps, но при попытке запустить приложение мне было предложено ввести мои учетные данные, а внизу окна входа в систему появилось сообщение «попытка входа не удалась». Благодаря сообщению Роберта сверху я узнал, что это перенаправление, которое я вставил в IIS7. Моя установка - это один сервер, действующий как шлюз, брокер и веб-доступ. Я оставил все работать под «Веб-сайтом по умолчанию». Чтобы расширить сообщение Роберта, я оставил перенаправление на месте, но поставил отметку «Только запросы перенаправления к контенту в этом каталоге (не в подкаталогах)», так как я хочу, чтобы запросы к корневому сайту попадали в RDWeb, и это отлично работает для меня.