Переезд
Переехал на новый хостинг. Пока полет нормальный.
Подписчики, на всякий случай переподпишитесь заново.
Переехал на новый хостинг. Пока полет нормальный.
Подписчики, на всякий случай переподпишитесь заново.
Задача: настроить брандмауэр Windows для работы сервера 1С (связка из Сервера 1С: Предприятие и MS SQL 2008, например).
Решение: если сервер SQL принимает подключения на стандартный порт TCP 1433, то разрешаем его. Если порт SQL динамический, то необходимо разрешить подключения к приложению %ProgramFiles%\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Binn\sqlservr.exe.
Сервер 1С работает на портах 1541 и диапазоне 1560-1591. По совершенно мистическим причинам иногда такой список открытых портов все равно не позволяет выполнять подключения к серверу. Чтобы заработало наверняка, разрешите диапазон 1540-1591.
Для танкистов скриншот, на котором разрешения на подключения к SQL выставлены в обоих вариантах (выберите свой!):
P.S. Вася, на здоровье.
Проблема: постоянно всплывает окно с сообщением, что SEP обнаружил и отправил в карантин Trojan.Gen.2:
Проверки другими антивирусами никаких результатов не выдают.
Объяснение: каждый раз после обновления антивирусных сигнатур SEP пересканирует карантин с целью обнаружить файлы, которые с помощью новых сигнатур могут быть вылечены. Эти файлы, будучи в карантине, зашифрованы и сжаты, но для пересканирования SEP их извлекает из архива. В процессе извлечения в рабочей директории SEP (в более старых билдах SEP — в %TEMP%) создаются временные файлы с именами DWH####.tmp. Если к этим файлам пытается получить доступ какой-либо процесс (к примеру, служба индексирования), то срабатывает Auto Protect, который рассматривает эти файлы как новые и ненадежные, и инициирует их проверку. Таким образом пересканируется и продублируется весь карантин. При последующих обновлениях будет происходить тоже самое, т.е. дублирование всего содержимого карантина.
Решение: эта проблема решена в Symantec Endpoint Protection Release Update 6, Maintenance Patch 1. Если нет возможности его установить, то воспользуйтесь следующим решением:
Взято отсюда: http://www.symantec.com/docs/TECH102953
Проблема: при попытке загрузить данные на внешний FTP-сервер из сети, спрятанной за NAT’ом на Microsoft TMG 2010 (к ISA тоже применимо), возникает ошибка 550.
Объяснение: в правилах исходящего трафика, созданных мастером TMG, определена политика FTP «только для чтения».
Решение:
1. Найдите ваше правило, разрешающее FTP наружу. У меня оно выглядит так:
2. Нажмите на правило правой кнопкой мыши, чтобы вызвать контекстное меню. Выполните команду «Настроить FTP»:
3. Снимите галочку с «Только для чтения»:
4. Примените изменения. Вуаля!
Иногда срабатывает такой способ:
1. Подключитесь к устройству со следующими параметрами:
— Скорость: 1200 бит/сек
— Биты данных (Data bits): 8 бит
— Паритет (Parity): без паритета
— Стоповые биты (Stop bits): 1
— Управление потоком (Flow Control): нет
Естественно, вывод на экран перестанет работать. Это нормально.
2. Перезагрузите устройство по питанию. Когда оно включится, нажмите пробел и удерживайте его в течении 10-15 секунд. Это и есть эмуляция комбинации Break Key.
3. Отключитесь от терминальной сессии и запустите ее снова, уже со стандартными параметрами.
Если вы все сделали правильно, то, скорее всего, вы увидете строку приглашения ROM Monitor.
Она же — Standard Break Key Sequence Combinations During Password Recovery.
Табличка-полезняшка. Будет использована как вспомогательный материал в будущей серии публикаций.
В формате .doc (print-ready):
— Администрирование безопасности
— Администрирование служб каталогов
— Администрирование систем
— Мониторинг и контроль сервисов
— Обзор Функций Управления Сервисами MOF
— Планирование заданий
— Проектирование инфраструктуры
— Сетевое администрирование
— Служба поддержки
— Управление безопасностью
— Управление доступностью
— Управление изменениями
— Управление инцидентами
— Управление конфигурациями
— Управление мощностью
— Управление непрерывностью ИТ сервиса
— Управление персоналом
— Управление проблемами
— Управление релизами
— Управление уровнем сервиса
— Управление финансами
— Управление хранением данных
Одним архивом:
Проблема: при отправке писем с почтового ящика Exchange 2010 (да и 2003, 2007), возвращается NDR следующего содержания:
Пользователь mail.domain.ru отклонил ваше сообщение, отправленное на следующие адреса электронной почты:
example@domain.ru (example@domain.ru)
mail.domain.ru выдал это сообщение об ошибке:
PTR hostname must resolve to IP
Объяснение: ваш почтовый сервер не имеет PTR-записи в зоне обратного просмотра провайдера. Такая «обезличенность» смущает многие почтовые серверы. И они, с целью противодействия распространению спама и вредоносного ПО, блокируют письма с таких хостов.
Решение: к примеру, ваш Exchange опубликован наружу как mail.company.ru и имеет IP-адрес 20.30.40.50. Этот IP-адрес принадлежит вашему Интернет-провайдеру, соответственно DNS в этой сети управляется им же. Решение будет сугубо нетехническим. Пишете на адрес технической поддержки провайдера письмо следующего содержания:
— Что бы вы сказали сегодня нынешним выпускникам гуманитарных факультетов?
— Два больших латте, с сахаром, с собой.
Для подключения IP-телефонов Cisco, настройки коммутаторов Cisco Catalyst 3550/3750 несколько отличаются от 2960. Например, использование dot1Q включается вручную, а spanning-tree аналогично выключается.
Приведу пример стандартной конфигурации интерфейса (за исходные данные примем, что data-vlan — это vlan 1, голосовой vlan — vlan 4):
— Скорость: 9600 бит/сек
— Биты данных (Data bits): 8 бит
— Паритет (Parity): без паритета
— Стоповые биты (Stop bits): 1
— Управление потоком (Flow Control): нет