Даже если компьютер оформлен как россыпь запчастей, все равно есть гарантия на материнскую плату. Надо менять/ремонтировать ее. Если магазин отказывается обменивать по гарантии, то уже в роспотребнадзор.
А, простите, наверное не совсем понял вопрос. Вас интересует как subdomain2.example.com разрешится в IP? Если для него авторитативным сервером является тот же самый сервер — то он выдаст в DNS-ответе A-запись subdomain2.example.com как авторитативную. Если не является — то все равно можно прописать запись для subdomain2.example.com и она будет выдана как неавторитативная. Если записи не будет или резолвер слишком паронаидален чтобы ей поверить — то резолвер отдельно самостоятельно разрешит subdomain2.example.com в IP. Если у subdomain2.example.com не меняется IP адрес и он Вам известен, то можно в родительской зоне прописать
subdomain2 IN NS ns.subdomain2.
ns.subdomain2 IN A 17.17.17.17
Точно так же, как и при всех остальных нерекурсивных запросах. Если разрешается, например A-запись из дочернего домена — запрос получает сервер родительской зоны и дает в ответе, что у него авторитативной записи нет, но ее можно получить по такому-то адресу (адрес определяется NS-записью). Естественно, что в родительском домене должна быть эта NS-запись. Если требуемая запись есть в самой родительской зоне — то сервер родительской зоны ее отдаст как авторитативную и обращений к дочерней зоне не будет.
аппаратный роутер у топикстартера есть, а судя по тому, какой именно у него есть аппаратный роутер, у него есть еще и виндоусовая ентерпрайз-сеть и нет необходимости поднимать что-то на «этой же семерке», а есть возможность настроить штатный NPS/IAS на Windows Server.
Со стороны пользователя особого геммороя нет, любой аппаратный роутер поддерживает RADIUS-авторизацию, со стороны Windows-сети поднимается NPS, задаются политики и вся авторизация становится прозрачной. Доступ к локальной сети и к требуемым ресурсам можно оставить и без авторизации.
Скорее всего, имелись ввиду политики IPSec, ими можно и нешифрованным трафиком управлять, но они на пользователей не назначаются, только на компьютеры.
ntbackup / Windows Backup вполне себе бэкапят эксчендж. А то что есть сторонний коммерческий софт для более удобного бэкапа — это плюс, а не минус, когда будет большая сеть он потребуется.
Случаев когда рестор правильно организованного бэкапа не взлетел бы я не помню. А в 2010м еще и достаточно легко заресторить отдельные письма по какому-либо признаку, вплоть до темы и ключевых слов. Причем это уже все есть и не придется поспешно скрипты на коленке писать, когда все долбанет.
Коммерческих антивирус/антиспам-решений для Exchange полно. ClamAV и спамотсосин — это нормально для небольшой компании, но это не решения для масштабной корпоративной сети, потому что или оно ничего ловить не будет, или придется на допил правил ставить отдельных людей, что дороже, чем коммерческий продукт купить. Из недостатков эксчендж — если грядут организационные изменения в компании и будет переделка AD, то будет много возни с переносом пользователей. Впрочем, все это достаточно легко автоматизируется.
В качестве реальной альтернативы, особенно если религия не позволяет разводить Windows, можно рассматривать Communigate, ниже его уже советуют.
Использовать решения на бесплатном софте я бы рекомендовал только в том случае, если почтовый сервер будет один, масштабировать их сложнее. Хотя они легковеснее и проблема масштабирования если и появится — то не скоро.
Ни разу не пошутил, в HTTP-прокси один активный пользователь создает несколько подключений, 10000 подключений это порядка 1500-2000 одновременно браузящих пользователей. Вот как раз таки в *nix, если использовать select() (что, правда, вряд ли кто-то будет делать в более-менее нормальном проекте) проблемы будут с большим числом подключений из-за особенностей реализации select() в POSIX.
Так трафик-то поснифленный чей, ваш или исходного приложения? Что именно вас в нем смущает? Единственная проблема в нем — несоответствие между Content-Type и собственно содержимым. Что Вы называете ключом?
Только там? Так ни в коем случае не надо делать. Это NDIS-драйвер, а помимо него есть еще TDI и WFP. Если отключен только NDIS драйвер — результат может быть непредсказуем, необходимо отключать защиту в самом Comodo.
Т.е. оно даже и не устанавливается или по нему данные не идут?
Судя по
Response: 226 Transfer complete.
и файлу нулевого размера на сервере, сервер получил входящее соединение, но оно тут же было закрыто. Попробуйте в свойcтвах сетевого соединения отключить компоненты Comodo (там должен быть что-то типа COMODO Internet Security Firewall Driver).
Может быть, все зависит от того, как буферизация данных организована в FTP-клиенте, грубо говоря буффер какого размера передается в send().
Но проверить не сложно — если маленькие файлы на сервер грузятся, то проблема именно с прохождением больших пакетов.
Я почитал, Вы не указали как именно отключен брандмауэр и есть ли что-то помимо Комодо. Кстати, перевод фаервола в неактивное состояние не всегда отключает перехват трафика. Но в Вашем случае наиболее вероятен первый вариант. Попробуйте на загрузке файла менее 1 КБ, если она пройдет, то проблема точно в MTU.
