После ошибок Windows 7 SP1 IIS с “Недопустимым путем приложения”

Все это зависит от того, имеет ли сервер SMTP, Вы посылаете свои электронные письма через, актуальную запись MX. Много ISPs не повинуется TTL и делает их собственное, и я предполагаю, что это могло особенно иметь место для MX.

Я видел случаи до 72 часов, прежде чем MX будет обновлен, особенно с южноафриканским ISPs.

Если бы это все еще возвращается для всех после 24 часов, именно тогда я был бы более заинтересован.

- Обновление-

Я сделал nslookup на Вашем домене и получил следующее:

C:\Users\Mark>nslookup
Default Server:  bladedc1.live.local
Address:  192.168.163.50

> set q=mx
> ttanet.com
Server:  bladedc1.live.local
Address:  192.168.163.50

ttanet.com
        primary name server = NS87.WORLDNIC.COM
        responsible mail addr = namehost.WORLDNIC.COM
        serial  = 110011012
        refresh = 10800 (3 hours)
        retry   = 3600 (1 hour)
        expire  = 604800 (7 days)
        default TTL = 3600 (1 hour)
>

Похоже, что Ваш DNS не служит никаким записям MX вообще, однако Ваше вышеупомянутое, запись для mail.example.com ДЕЙСТВИТЕЛЬНО существует:

> set q=a
> mail.ttanet.com
Server:  bladedc1.live.local
Address:  192.168.163.50

Name:    mail.ttanet.com
Address:  206.188.207.108

И authoriative сервер имен установлен на:

> set q=ns
> ttanet.com
Server:  bladedc1.live.local
Address:  192.168.163.50

Non-authoritative answer:
ttanet.com      nameserver = ns87.worldnic.com
ttanet.com      nameserver = ns88.worldnic.com

ns87.worldnic.com       internet address = 205.178.190.44
ns88.worldnic.com       internet address = 205.178.144.44

Мы видим записи с корректного сервера DNS?

- Обновление № 2--

Я полагаю, что вижу корректные детали теперь:

> ttanet.com
Server:  bladedc1.live.local
Address:  192.168.163.50

ttanet.com      MX preference = 10, mail exchanger = ttamail.ttanet.com
ttamail.ttanet.com      internet address = 67.78.188.51

Таким образом, это - просто проблема propgation/caching для Ваших конечных пользователей. Это определенно настраивается правильно.

20
задан 10 March 2011 в 16:13
8 ответов

Перепроверка, которую Ваша определенная версия ASP.NET позволяется в IIS следующим образом:

  1. Выберите лучший (корневой) сервер в менеджере по IIS.
  2. Дважды щелкните по ISAPI и CGI Restrictions.
  3. Если Ваша версия ASP.NET Не Позволяется, щелкните правой кнопкой и Позвольте ее.

Это решило его для меня, надежда, это работает на Вас также.

4
ответ дан 2 December 2019 в 20:12

У меня была та же проблема, решенная путем предоставления явных полномочий IIS_IUSRS в папке, где мое приложение.

1
ответ дан 2 December 2019 в 20:12

Я все еще не имею, находят решение, но находят обходное решение.

Можно вручную изменить конфигурацию IIS в system32\intsrv\config\applicationHost.config. Просто вручную создайте (вставка копии) раздел в и.

0
ответ дан 2 December 2019 в 20:12

В IIS в "Расширенных настройках" Пула (пулов) приложений под "Общим" существует установка "Enable 32-Bit Applications". Когда я установил это на Правда, эта ошибка ушла для меня.

0
ответ дан 2 December 2019 в 20:12

У меня была та же проблема, вот мое решение.

  1. Проверьте пул приложений, который использует Ваше приложение.
  2. Нажмите на пул приложений и нажмите на Расширенные настройки, приведет к новому окну.
  3. Проверьте версию Платформы.NET
  4. Профиль пользователя загрузки набора к истинному
  5. Ping набора включил к Истинному
1
ответ дан 2 December 2019 в 20:12

У меня сработало разрешение 32-битных приложений в пуле приложений.

Похоже, что приложение, которое я запускал, было 32-битным

HTH

1
ответ дан 2 December 2019 в 20:12

ИМХО ... Этот тест не имеет большого значения, если вы не хотите тестировать конкретного пользователя, и даже в этом случае он незначителен ... для добавления учетных записей пользователей в папки, чтобы этот тест работал (как другие заявили) маргинализирует вашу безопасность ... лучше не проводить этот тест, чем добавлять пользователей в папки и ставить под угрозу вашу безопасность любым способом, формой или формой ...

Пока ваш сайт работает ... это должно быть ваш тест ...

0
ответ дан 2 December 2019 в 20:12

Это действительно похоже на ошибку в пользовательском интерфейсе IIS: при выборе «Пользователь приложения (пройти через аутентификацию)» веб-сайт ожидает, что браузер отправит учетные данные текущего пользователя, вошедшего в систему. Затем сайт загрузится, потому что для сайта включена «анонимная» аутентификация. Однако при тестировании через IIS MMC, кнопка «Test Settings ...» не представлены учетные данные для использования для доступа к каталогу, поэтому вы видите сообщение об ошибке «Invalid application path» в IIS MMC. Если вы нажмете «Обзор ...», то браузер по умолчанию на веб-сервере, обычно Internet Explorer, представит ваши учетные данные. В большинстве случаев вы можете игнорировать эту ошибку, ваш веб-сайт работает.

0
ответ дан 2 December 2019 в 20:12

Теги

Похожие вопросы