Проблема: принтер печатает без остановки (все, кроме пробной страницы). Проблема распространена широко — на разных версиях Windows, с разным оборудованием, с разными версиями драйверов. Я свою «отловил» на связке Windows Server 2008 R2 + HP LaserJet 1022n.
Решение: в свойствах порта принтера снимаем чекбокс «Разрешить двусторонний обмен данными».
Вуаля!
Проблема: при пересылке письма The Bat! прикрепляет его вложением в виде eml-файла.
Решение: открываем свойства почтового ящика. В секции «Шаблоны» выбираете пункт «Пересылка«, снизу снимаете чекбокс «Прикреплять также исходное письмо в формате EML (стандарт MIME)».
Вуаля!
Disclaimer: данная проблема у меня лежала в долгом-предолгом ящике уйму лет (примерно с выхода редакции R2 Windows Server 2008). Она мне попортила немало крови, отняла массу времени, но я с маниакальным упорством ее игнорировал, всегда используя обходной путь. Сегодня я впервые задумался о том, что пора ее решить, и неожиданно для себя решил. Что мешало сделать это раньше — загадка. Но так уж я устроен.
Проблема: в RDP-сессии с Windows Server 2008 R2 не переключается раскладка клавиатуры. При этом значок языка в панели задач меняется, но рядом с ним появляется дополнительный значок клавиатуры, через который надо вручную (мышкой) менять язык ввода.
Решение: лежит через редактор реестра.
1. Открываем оный по команде regedit на сервере
2. Заходим в ветку HKLM\System\CurrentControlSet\Control\Keyboard Layout
3. Создаем новый параметр типа REG_DWORD (32 bit) с названием IgnoreRemoteKeyboardLayout и значением 1
4. Закрываем редактор реестра и перезагружаем сервер
Вуаля!
Проблема: при публикации обновлений ПО (например, из партнерского каталога Adobe) на сервер WSUS, работа мастера завершается ошибкой, а в SCUP.log появляется запись: A fatal error occurred during publishing :Signature verification exception during publish, verify the WSUS certificates and advanced timestamp setting are properly configured.
Объяснение: WSUS не доверяет собственному самоподписному сертификату.
Решение: подробно описано здесь. Краткий конспект:
1. На сервере WSUS запустите консоль MMC, добавьте оснастку управления Certificates.
2. Разверните раздел Certificates, найдите подраздел WSUS, в нем — подраздел Certificates.
3. Сделайте экспорт сертификата WSUS Publishers Self-signed с опциями по умолчанию.
4. Перейдите в раздел Trusted Publishers — Certificates.
5. Выполните импорт выгруженного ранее сертификата в этот раздел.
6. Выполните пункты 1-5 на сервере SCUP (если SCUP установлен на том же сервере, что и WSUS, то проигнорируйте этот пункт).
7. Настройте групповые политики для членов домена или рабочей группы следующим образом: в разделе Computer Configuration — Policies — Administrative Templates — Windows Components — Windows Update установите политику Allow signed updates from an intranet Microsoft update service location в режим «Enabled».
Вуаля!
История началась с того, что я перед заменой жесткого диска в рабочем компьютере конвертировал диск с системой в динамический (мотивы оставим за кадром). Будучи в совершенном спокойствии за данные на нем, я установил в компьютер новый диск и принялся ставить систему. Закончив, я подключил старый диск через адаптер USB-SATA и приготовился копировать данные, как вдруг обнаружил, что диск в системе значится «недопустимым»:
Контекстное меню диска предлагало один более-менее подходящий вариант (конвертация динамического диска в базовый привела бы к потере данных) – «Реактивизировать диск»:
Попытка выполнить «реактивизацию» возвращала ошибку «Эта операция не разрешена на недопустимом дисковом пакете»:
Решение: Решение нашлось не сразу, ибо оно оказалось не слишком очевидно.
Инструментарий: в качестве ремкомплекта придется использовать дисковый редактор, а работать с данными придется в бинарном виде. Я использовал бесплатную версию программы DMDE (http://dmde.ru/), которая для решения данной проблемы оказалась очень даже пригодной.
Итак, запустим DMDE от имени администратора:
В появившемся меню выбора диска определите нужное вам устройство (у меня это Physical Drive 1) и нажмите Ок:
По завершении операции инициализации появится окно с предложением выбрать раздел. Нас интересует нулевой сектор. Поставьте курсор на него и нажмите Close:
Включите режим редактирования с помощью меню Edit -> Edit Mode:
Теперь замените значения 42h на 07h (как в обычном текстовом редакторе):
Закройте программу с сохранением изменений и зайдите в диспетчер дисков Windows. Система должна увидеть сделанные изменения, но логические диски пока еще недоступны:
Откройте Диспетчер устройств, секцию «Дисковые устройства», выберите диск, с которым мы проводили последние манипуляции, отключите его и включите заново:
Обновите диспетчер дисков. Все должно прийти в норму:
Вуаля!
Проблема: после инсталляции System Center Update Publisher 2011 отказывается подключаться к серверу WSUS с ошибкой:
An Error Occurred
Failed to connect to the update server. Check your update server configuration settings and try connecting again. System.TypeInitializationException: The type initializer for ‘Microsoft.UpdateServices.Internal.Constants’ threw an exception.
Выглядит это так:
Решение: простое. Запустите SCUP с правами администратора…
…и вуаля:
Столкнулся с проблемой после установки Forefront TMG 2010 на сервер под управлением Windows Server 2008 R2: консоль управления выдавала сообщение об ошибке выполнения скрипта на странице. Цитата:
An error has occurred in the script on this page.
Line: 283
Char: 13
Error: Invalid argument.
Code: 0
URL: file:///C:/Program%20Files/Microsoft%20Forefront%20Threat%20Management%20Gateway/UI_HTMLs/Generic.htm?guid=%7BF1BF89DE-2B7A-4BF4-9944-05434FC5854F%7D
И фото на память:
Продолжение или отказ выполнения скрипта ни к чему не приводили: TMG оставался неуправляем и в том, и в другом случае.
Решение:
1) открываем файл C:\Program Files\Microsoft Forefront Threat Management Gateway\UI_HTMLs\TabsHandler\TabsHandler.htc в Блокноте;
2) выполняем поиск по выражению «paddingTop». Должны вернуться 3 строки;
3) перед найденными строками добавляем «//», без кавычек, ествественно:
4) сохраняем файл;
5) перезапускаем консоль управления TMG и видим…
Вуаля!
Проблема: клиент Windows XP, либо Windows Server 2003 не подключается к сетевым ресурсам по DNS-alias’ам.
Объяснение: http://support.microsoft.com/kb/281308
Решение: откройте редактор реестра и зайдите в раздел HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters. Создайте в нем параметр типа REG_DWORD с названием DisableStrictNameChecking с десятичным значением 1. Перезагрузите компьютер, и… вуаля!
Проблема: в оснастке Server Manager (в русской версии, видимо, Управление Сервером) возникает ошибка управления ролями с лаконичной надписью «Error».
С указанной в заголовке ошибкой я столкнулся на производственном сервере Hyper-V после очередной установки обновлений от Microsoft. Для наглядности графическая демонстрация:
Детали ошибки сообщали некоторые более конкретные и вразумительные подробности: Unexpected error refreshing Server Manager: Exception from HRESULT: 0x800F0818. Также предлагалось подробнее изучить события Applications and Services Logs -> Microsoft -> Windows -> Server Manager -> Operational (после изучения документации, нашел второй вариант ошибки: Server Manager: Unexpected error refreshing Server Manager: No signature was present in the subject. (Exception from HRESULT: 0x800B0100). Нижеприведенное решение позволит избавиться и от нее тоже).
Объяснение: проблема возникает из-за вмешательства посторонних служб (индексирования Windows, антивируса и пр. сервисов, работающих в фоне), кэширования записи на диск или «прочих ошибок» (нравится объяснение?) при установке обновлений, из-за которого неверно или неполностью копируются пакеты обновлений с расширением .MUM и связанные с ними .CAT.
Решение:
1. Запустите Microsoft Update Readiness Tool (брать здесь: http://support.microsoft.com/kb/947821)
2. После получения сообщения об успешном окончании работы утилиты, откройте получившийся log-файл C:\Windows\logs\CBS\Checksur.log
У меня он содержал следующее:
<…>
Checking Package Manifests and Catalogs
(f) CBS MUM Corrupt 0x00000000 servicing\Packages\Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~6.1.1.0.mum Expected file name Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~6.1.7600.16385.mum does not match the actual file name
<…>
Unavailable repair files:
servicing\packages\Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~6.1.1.0.mum
servicing\packages\Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~6.1.1.0.cat
Итак, проблема возникает из-за неверного содержимого двух файлов. В их названиях содержится наименование KB, в которых эти файлы содержатся. У меня это KB979916. Google подсказал, что это обновление безопасности .NET Framework 3.5.1.
3. Скачайте пакеты обновлений по вашим KB и скопируйте их в корень диска C:. По своему КВ я брал обновление отсюда: http://www.microsoft.com/downloads/en/details.aspx?familyid=a49532d7-53f6-4190-aaf6-b1a818924764&displaylang=en
4. Теперь нам необходимо получить права на директорию C:\Windows\Servicing\Packages. Запускаем консоль cmd с правами администратора и выполняем следующие команды:
Сделаем текущего пользователя владельцем директории:
Дадим пользователю (у меня это admin из домена domain.local, поэтому запись выглядит как admin@domain) полный доступ к директории:
5. Распаковываем скачанные ранее пакеты обновлений. Мой называется Windows6.1-KB979916-x64.msu и лежит в корне диска C:
Создадим в корне диска C: небольшую структуру каталогов (каталог TMP и вложенный в него каталог CAB), которые будут служить временным хранилищем для распаковываемых данных:
Распакуем MSU-файл с каталог TMP:
В каталоге C:\TMP появится файл с именем Windows6.1-KB979916-x64.cab. Распакуем его в каталог C:\TMP\CAB:
6. Найдите в каталоге C:\TMP\CAB файлы Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~6.1.1.0.mum и Package_for_KB979916_RTM~31bf3856ad364e35~amd64~~6.1.1.0.cat, о повреждении или отсутствии которых нам сообщила на 2-м шаге Microsoft Update Readiness Tool. Скопируйте их в каталог C:\Windows\Servicing\Packages и перезапустите Server Manager, чтобы убедиться, что проблема решена:
Второй вариант предполагает, что нужных файлов вы не нашли. В этом случае присвойте файлам update.cat и update.mum из каталога C:\TMP\CAB имена, на отсутствие или повреждение которых состалась Microsoft Update Readiness Tool на 2-м шаге.
Вуаля!
P.S. Если ошибка не пропала, повторите инструкцию сначала.
Проблема: после установки нового оптического привода (в моем случае с SATA-интерфейсом, но, судя по всему, проблеме подвержены и IDE-устройства), система обнаруживает его, но в диспетчере устройств на нем стоит «!», а состоянии устройства стоит статус «Запуск этого устройства невозможен (код 10)».
Решение:
1. Запустите редактор реестра (Пуск -> Выполнить… -> regedit).
2. Найдите раздел HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E965-E325-11CE-BFC1-08002BE10318}, в котором параметр Default имеет значение DVD/CD-ROM, а параметр Class — значение CDROM (в реестре может быть несколько экземпляров ветки {4D36E965-E325-11CE-BFC1-08002BE10318}, так что эти параметры позволят опознать нужный нам).
3. Найдите в этом разделе параметры UpperFilters и LowerFilters и удалите их.
4. Закройте редактор реестра и перезагрузите компьютер. Вуаля!
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. Примените изменения. Вуаля!
Проблема: при отправке писем с почтового ящика 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 в этой сети управляется им же. Решение будет сугубо нетехническим. Пишете на адрес технической поддержки провайдера письмо следующего содержания:
Проблема: Доменный пользователь не может авторизоваться на своем компьютере. После ввода учетных данных, возникает ошибка: «Служба «Служба профилей пользователей» препятствует входу в систему. Невозможно загрузить профиль пользователя». ОС — Windows 7 (судя по всему, такой же проблеме подвержена и Vista).
Решение: входим в систему локальным или доменным администратором (кем пустит, собственно). Открываем regedit.exe. В разделе HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList наличествует несколько подразделов, названия которых соответствуют ID пользователей, зарегистрированнных в системе. Визуально можно сопоставить нечитаемый ID с ключем «ProfileImagePath», который определяет путь к профилю (например, C:\Users\Fedoseyev). Находим нужный подраздел с целевым ProfileImagePath и… обнаруживаем в названии подраздела «.bak» на конце. Удаляем .bak, просматриваем содержимое остальных ID в поисках проблемных профилей (например, с путем C:\Users\TEMP), вычищаем их. Теперь можно перезаходить в систему с привычным профилем. Вуаля.
Консультативно решал проблему с низким быстродействием гигабитной сети на 200 хостов. Решил. Полуневменяемому заказчику (кстати, айтишнику) пришлось канонически обосновывать причины, по которым было выбрано решение. И в процессе предлагать статистику, доходчиво объясняющую, почему сети иногда тормозят. Формулирую еще раз, уже публично.
Быстродействие сетей TCP/IP обычно ограничивается следующими типами ошибок:
1. потери и повреждения пакетов;
2. перегрузка каналов связи;
3. плохое оборудование;
4. некорректная IP-маршрутизация, большое время двойного оборота;
5. недопустимые размеры пакетов;
6. неэффективные приложения.
Вопросов не вызвали, пожалуй, только пункты 3 (за исключением стандартного: “А чой-то оно плохое вдруг?!”) и 6 (за исключением такого же стандартного, мол: “А чой-то они неэффективные вдруг?!”). Но на то он и руководитель департамента ИТ со степенью MBA, чтобы ничего не смыслить в технике, но давать ценные указания по работе с ней. Перевел на человеческий язык, таки почему ж тормозят сети:
1. кривые руки сетевого администратора;
2. непредназначенное для работы в enterprise-среде оборудование (в т.ч. устаревшее морально и физически);
3. зоопарк вирусов в сети (слышал о бот-нетах на несколько тысяч хостов, рассылающих горы спама… какое уж там быстродействие);
4. кривое ПО (написанное девелопмент-студией из Вышнего Волочка в перерывах между парами в шараге и брошенное на произвол судьбы сразу же после подписания акта о выполненных работах и последующей оплаты);
5. неквалифицированный технический персонал в целом (вынес отдельно от пункта 1, поскольку сетевой администратор может быть и вменяемым, а вот системный может запускать многочасовое резервное копирование через коммутатор уровня доступа на слабосильный NAS в рабочее время).
Вышеупомянутый руководитель ДИТ все понял. Решение одобрил. Стало хорошо, даже с его точки зрения. Айс.
Потихоньку переводя свои серверы на Windows Server 2008, сталкиваюсь с разнообразнейшими проблемами. Последняя возникла при установке на новый сервер роли Windows Software Update Services при действующем сервере WSUS в домене. Установка каждый раз завершалась с ошибкой «The update could not be found».
Решение довольно простое:
1) Удаляем раздел реестра HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate;
2) перезапускаем службу Windows Update.
После этого сразу же можно приступать к установке WSUS, ошибка больше не возникнет.
Для управления групповыми политиками в Windows Server я обычно использую Group Policy Management Console. Когда один из рядовых серверов домена на базе Windows Server 2003 x64 был повышен до DC, я обнаружил, что при попытке выполнить на нем модификацию объекта групповой политики (команда Edit… из контекстного меню GPO) возникает ошибка: «Windows cannot find ‘gpedit.msc’. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search.» При этом модификация GPO остается возможной, но строго через запуск MMC и добавлении в нее оснастки Group Policy Object Editor. Естественно, это неудобно, и лишает GPMC всей ее прелести.
Перейдем к решению. Фактически, в 64-битной Windows все оснастки управления (*.msc) подразделяются на 32- и 64-битные версии, и размещаются в разных каталогах: 32-битные в %windir%\system32, 64-битные — в %windir%\syswow64. Вышеописанная ошибка возникает из-за того, что в директории syswow64 отсутствует оснастка gpedit.msc. Для того, чтобы эта проблема решилась, достаточно выполнить следующую команду:
Ее успешное выполнение будет озвучено так:
После этого ошибка возникать не будет.