Администраторам Windows систем

Если при создании Snapshort-а возникает ошибка типа:
access denied error (0x80070005)

То это означает, что на каталог в котором хранится виртуальный диск не назначен достаточный доступ.

Здесь подробно о хитростях назначения доступа
http://www.virtualizationadmin.com/articles-tutorials/microsoft-hyper-v-articles/storage-management/hyper-v-file-storage-permissions.html

У меня такая проблема возникла, когда я файл виртуального диска одной машины вынес на другой физический диск. Машина работала, но snapshort не удавалось сделать.
Временно переключил в настройках Hyper-V каталог хранилища на другой диск и на каталоге нового хранилища раздались необходимые доступы. Потом вернул настройку обратно. Можно конечно руками, но судя по статье это весьма не тривиально.

Если у вас железяка имеет оригинальные драйвера жесткого диска, то есть большая вероятность, что при переносе диска в виртуальную среду, операционная система не запустится и выдаст BSOD: STOP 0x0000007B.
Это означает, что ОС не может загрузить драйвер диска.

Не пытайтесь включать Boot loging, ему некуда записаться :)

В этом случае спасет
http://support.microsoft.com/kb/314082

Хотя статья относится к XP, но мне помогло и на Windows Server 2008 R2.
Я виртуализировал железо для создания тестовой среды, поэтому не сильно заморачивался на то что она туда прописала, главно загрузилась.
На производственном сервере, конечно лучше разобраться что именно из предложенного спасает, и может быть сделать более корректно подглядев на рабочем вирутальном сервере.

Есть конечно Actronis Universal Restore, но иногда нужно снять сервер без остановки, тогда помогает Windows Server Backup, который не умеет адаптировать ОС под виртуальное железо.

В предыдущих версиях CA, MS вставляла в корневой сертификат ссылки на его же CRL, что неверно.

В последней версии они исправили эту ошибку, но похоже не до конца :)

Из личного опыта столкнулся с такой проблемой. На подчиненном ЦС вручную был добавлен CRL корневого ЦС. После обновления CRL корневого ЦС в точке обновления, он не обновился в хранилище подчиненного ЦС. Но это еще пол беды, самое смешное в том, что когда на подчиненном ЦС истек вручную установленный CRL корневого ЦС, MS удалил из хранилища сертификат корневого ЦС, что неверно.

Либо в MS забыли это исправить, либо по прежнему считают, что раз корневой ЦС выдал себе сертификат сам, то он может быть отозван его CRL.

Еще один интересный факт:
Если в хранилище подчиненного ЦС не установлен CRL корневого ЦС, то он корректно втягивается с точки распространения. Из этого можно сделать вывод, что если вы хотите, чтобы CRL обновлялся автоматом, его нельзя импортировать в хранилище вручную.

После общения с поддержкой выяснил следующее:

Схема отправки сообщения происходит следующим образом:
Client — > CA — > MB — > HT — > MB

Т.е. клиент, сначала передает сообщение в свой ящик (в «исходящие»), затем оно уходит с ящика и попадает на HT, который ищет ящик получателя и передает сообщение в соответствующую MB.

В моем тесте (см. предыдущий пост) сообщение попало в «исходящие» моего ящика, но не было передано на HT, который выполняет функцию резерва в случае переключения.

Т.е. схема передачи сообщения сделана еще более глупо чем я предполагал.
За что архитекторам Exchange 2010 отдельное спасибо :)))

Поддержка говорит, что поскольку кластер построен на механизме репликации, то нельзя гарантировать 100% защиту от потери. Вопрос, тогда зачем отменили другие схемы кластеризации? И что значит не дает 100% гарантию? При достаточном количестве пользователей любое переключение DAG с вероятностью почти 100% будет вызывать потерю сообщений.

Согласен, что почтовая система не является системой гарантированной доставки сообщений, но хотябы NDR можно было бы организовать на подобные ситуации?

Вобщем, MS как всегда, сначало все сделает через…, а потом исправляет за отдельные деньги :))) Наверно боятся без работы остаться :)

Значимость отказоустойчивости почты в последнее время выросла в нашей организации и мы задались вопросом, как организовать бесперебойную работу пользователей и исключить потерю данных.

На данный момент мы используем Exchange 2007 без кластера.
Схема восстановления Dial Tone, клиенты Outlook 2003.

Пробовал SCR (Standby Continuous Replication) и понял что это очень опасная и по сути бесполезная вещь, т.к. она работает по принципу, если тебе очень повезет, то ты возможно восстановишь сервер на резервной реплике. Многократно пробовали настроить SCR, она встает все тесты говорят все ОК, но когда реально переключаешься, говорит что битая база. Периодически оно просто слетает и начинает гнать, но ты об этом узнаешь только когда поймешь, что переключаться не на что. SCR работает только на мелких тестовых базах, на реальных данных работает крайне не надежно. Также есть потеря данных т.к. передача логов асинхронная.

Стали думать про кластер.
Делать кластер с единым хранилищем дорого и опять же ненадежно, т.к. есть единственная точка сбоя (собственно единое хранилище).

CCR — вроде подходит, но поскольку уже есть новая версия Exchange 2010 DAG, которая по сути есть улучшенный CCR, то решили тестировать его.

Создал я тестовую среду из 7 виртуальных машин, поставил Exchange 2010 в организацию Exchange 2007, настроил DAG и провел тест на потерю данных.

Схема тестовой среды:
DC1 — контроллер домена Win2003SP2
EX1 — Почтовик Exchange 2007 (все роли)
E14-S1 — Exch2010 CA,HT,UM (SP1+RU1)
E14-S2 — Exch2010 CA,HT,UM (SP1+RU1)
E14-MB1 — Exch2010 MB (SP1+RU1)
E14-MB1 — Exch2010 MB (SP1+RU1)
WinXP — Outlook 2003

DAG (E14-MB1, E14-MB2), активная база на E14-MB1

Тест:
1. Перевел Outlook в автономный режим и отправил 8 нумерованных сообщений с вложением 4Мб на ящик в той же почтовой базе.
2. Вывел Outlook из автономного режима, после того как ушло 1-ое сообщение и начало передаваться второе, выключил сеть на E14-MB1, вернулся на XP и вижу, что 2-е сообщение ушло и передается 3-е, ждал 15 минут, убедился что на серверах уже произошло переключение на пассивную реплику (на это ему потребовалось 3—5 минут), но Outlook завис на передаче 3-го сообщения.
3. Перезапустил Outlook, сообщения ушли.
4. Захожу в ящик получателя и вижу что получены сообщения в следующем порядке
    3, 4, 5, 6, 7, 8, 1
    второго сообщения нет
5. Ни отправитель ни получатель не получили никаких уведомлений о недоставке сообщения N 2. В логах HT отсутствует даже упоминание про это сообщение.

Анализ теста:
В теории на Exchange 2010 передача сообщения в рамках одного сайта происходит следующим образом:
Outlook (MAPI)- > CA — > HT — > MB
(корректировка от 29.12.2010  Outlook — > CA — > MB — > HT — >MB)

DAG является кластером без единого хранилища, данные реплицируются с активной копии на пассивные асинхронно. Чтобы исключить потерю данных при переключении, используется механизм задержки сообщений на HT пока не придет ОК со всех пассивных реплик. В случае переключения, сообщения не получившие статус (реплицировано для новой пассивной копии) передаются на новую активную базу.

В теории все вроде идеально, но попробуем разобраться, что произошло в моем тесте сопоставив факты:

Факт 1: Сообщение N 2 было передано на CA это зафиксировал Outlook.
Факт 2: В логах HT, нет упоминания о получении сообщения N 2
Факт1 + Факт2 — > Сообщение не было передано с CA на HT, несмотря на то что они находятся на одном сервере.
Факт3: 3-е сообщение не передалось на CA и Outlook подвис. Следовательно CA перестает принимать сообщения, как только видит, что текущая активная база недоступна.
Факт4: Сообщение 1 дошло до HT, попало в активную базу, но не успело реплицироваться на пассивную и было успешно восстановлено с HT. Отсюда и порядок доставки сообщений.

На основе приведенных выше фактов, наиболее логичное предположение такое:
Если CA понимает что активная база недоступна уже после того как принял сообщение от клиента, он его тупо удаляет.

Точно утверждать не могу, потому что не знаю алгоритма процесса передачи CA- >HT.
Но если мое предположение правда, то это какой-то уж очень глупый конструктивный баг со стороны MS.

По факту, кластер DAG на данный момент, не может исключить потерю данных при переключении.

Пока приняли решение переходить на DAG, т.к. из описания работы CCR можно сделать вывод, что там проблем с потерей при переключении гораздо больше.
Пока остается только надеяться, что MS исправит свой баг в будущих SP или RU.

Создавая виртуальную тестовую среду, обнаружил интересный факт.

Если контроллер домена запускается на Hyper-V, то служба времени не стартует и вылетает с ошибкой. В журнале регистрируются события

EventID 30  W32Time

EventID 46  W32Time

Решение:

Проблема в Integration Services, и функции синхронизации времени с хостовой машиной. Чтобы решить проблему, нужно:

1. отключить синхронизацию в свойствах машины

2. запретить сервис «Hyper-V Time Synchronization Service» в виртуальной машине

3. удалить в реестре ветку, которую создает этот сервис в 

    HKLM\SYSTEM\Current Control Set\Services\W32Time\Time Providers\VMICTimeProvider

4. Перегрузить контроллер.

 

Локалка на 30 компов. Сервак под Windows 2000 Server. Возникла необходимость запретить пользователям ЛВС использовать флешки, но не все. То есть сделать так, чтоб они могли пользоваться только зарегистрированными носителями. В итоге, на одной машине попробовал вычистить все от старых флешек, затем по очереди воткнуть зарегенные флешки и в реестре запретить доступ всем (в том числе и SYSTEM) для ветки HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR. Вставляю «левую» флешку, система начинает было ставить дрова, но потом крякает и выдает сообщение, что установка не может быть произведена из-за непонятной ошибки. Все отлично, все работает! НО! Пользователь, под которым я заходил, имел админские права, а я только потом узнал, что если все вышеперечисленное проделать для рядового пользователя, то флешки хавает на ура, а вот под админами нет :((
Говорят, надо создать админку в групповой политике. Знаю, как вообще запретить использование USB-портов, сидюков и флоппиков через ГП, но как запретить установку драйверов — тут я лузер. Может кто подскажет? Буду очень признателен!

Недавно обнаружил, что база поиска Crawl выросла до 14Гб и продолжает расти дикими темпами.
Вывел статистику по размеру таблиц базы
(На базе Crawl правой кнопкой, Reports \ Disk usage top tables)
Таблица MSSCrawlURLLog занимает 13Гб

Возникло две задачи:
1. Как почистить
2. Выяснить в чём проблема

1. Почистить можно просто, в администрировании службы поиска есть ссылка «Сбросить индексы», эта опирация полностью обнуляет базы поиска. Обрезание файлов БД естественно нужно делать руками средствами SQL.

2. После чистки, 10 раз запускал и полный и инкрементный проход руками.
Размер таблицы MSSCrawlURLLog мизерный 8кб данные + 24кб индексы.
При каждом проходе, кол-во записей в этой таблице увеличивалось ровно на 1.
Похоже это журнал обходов, который также можно посмотреть в ЦА в администрировании службы поиска.

Проблему точно идентифицировать не удалось, но подозреваю, что все дело в интервале инкрементального прохода. У меня стояло 5 минут. Обычно эта процедура завершается за 2 минуты, но возможно в периоды нагрузки на сервер 5 минут не хватало и у службы поиска сносило крышу, когда запускалось 2 параллельных инкрементальных прохода.

Вывод: если база поиска вдруг начала дико расти, то возможно происходит пересечение заданий прохода.

Недавно у меня была серия поездок по филиалам. Обнаружил недопонимание администраторами принципа действия Restricted Groups в групповых политиках, несмотря на то, что это уже много раз описано: Description of Group Policy Restricted Groups, HOW TO: Use Restricted Groups in Windows 2000, A security policy does not process restricted groups correctly,Restricted Groups и еще вагон и маленькая тележка. Вот решил выложить пару картинок, думаю подробно комментировать незачем.

1. Определяем состав локальной группы (в данном случае Administrators), с удалением всех имеющихся «лишних» групп.


2. Добавляем в локальную группу «Administrators» дополнительные группы (без удаления имеющихся). Каждая добавляемая группа прописывается отдельно.

Сегодня выдался весёлый денёк счастливым обладателям NOD32.

http://kb.eset.com/esetkb/index?page=content&id=NEWS101
Обновление антивирусной базы 5418

Утром упало несколько серверов, симптомы разные, источник один NOD32
Поддержка врет, ничего насчет записи в память их антивир не выдавал, он тупо вешал систему и сносил ей крышу самыми разными способами. На одной машине вообще все работало, но tasklist не выдавал списка процессов, нельзя было закрыть ниодно приложение и logoff, shutdown — ничего не канает. Пришлось тупо ребутить систему, как и во многих других случаях.

Но это было только начало.
Через час начали сыпаться сервера один за одним, стали вешаться рабочие станции, в нашей не очень маленькой организации это выгдядело как полная Ж..А. Ни один вирус нам еще так не гадил.

Часть серверов всетаки не рухнуло сразу и пытались отрубить нод не перегружая сервак. В 3-ей версии это еще удавалось сделать хитрым маневром, но на 4-ой эти гады защитили своё ЧУДО-ЮДО так что бля даже в реестре тип запуска их гребанного сервиса не сменишь. А перегружать нельзя, куча народу работает.

ИМХО, так защищать антивирус это уже маразм. Если так дело дальше пойдет, они в 5-ой версии запретят удаление своего ЧУДА. Что собственно мешает вирусу запустить Uninstall? Угроза блин, надо блокировать. Один раз поставил и на века :))

Падало все от Win2000 до Win7 и Win2008R2, за что отдельное спасибо группе тестеров NOD32.

К обеду подошло спасительное обновление 5419, но оно спасает, только когда перезапустишь сервис, а в 4-ой версии он только вместе с сервером перегружается.

Короче весь день прошел в вынужденных ребутах и попытках спасти от них то что еще не упало.

Складывается ощущение, что для NOD-а это уже тенденция. Год назад была аналогичная, хотя и гораздо менее масштабная проблема (http://winadmin.blog.ru/78908291.html). Тогда поддержка меня мурыжила больше месяца утверждая что обновление вирусной базы никак не может влиять на переполнение системного пула и типа это у меня база эксча кривая, а их XMON хоть и выносит сервер, но как бы не причем. В итоге пришлось плюнуть и отказаться от NOD-а на этом сервере.  

Говорят подобные ситуации были и будут практически у всех производителей антивирусов, так что NOD не одинок в своей лаже. Остается только ехать на Тебет учиться медитации и духовному просветлению, чтобы такая фигня не омрачала сознание.

Источники:
   http://support.microsoft.com/kb/832769
   http://blogs.msdn.com/b/russmax/archive/2009/10/20/configuring-kerberos-authentication-in-sharepoint-2010-part-1.aspx

Настройка IIS описана для IIS 7,5 (Windows Server 2008 R2)
 

Если для веб-приложения была выбрана система проверки подлинности Kerberos, то необходимо выполнить дополнительные настройки

 

1. Включите Kernel mode
   IIS Manager, выберете сайт, Authentication, Windows Authentication
   На панели Actions, Advanced Settings
   [v] Enable Kernel mode authentication
   
   
2. Перезапустите IIS
   iisreset
   
   
3. Включите использование учетной записи пула приложений
   
   cd C:\Windows\System32\inetsrv
   Appcmd set CONFIG «SharePoint — 443» /section:windowsauthentication /useAppPoolCredentials:true /commit:MACHINE/WEBROOT/APPHOST
   
   
4. Убедитесь, что конфигурация корректно изменена
   notepad C:\windows\system32\inetsrv\config\applicationHost.config
   
   < location path=»SharePoint — 443» >
           < system.webServer >
               < handlers accessPolicy=»Read, Execute, Script» / >
               < security >
                   < authentication >
                       < windowsAuthentication enabled=»true» useKernelMode=»true» useAppPoolCredentials=»true» >
                           < providers >
                               < clear / >
                               < add value=»Negotiate» / >
                               < add value=»NTLM» / >
                           < /providers >
                           < extendedProtection tokenChecking=»None» / >
                       < /windowsAuthentication >
   
   
5. Если веб-приложение выполняется под доменной пользовательской учетной записью, то дбавьте к этой учетной записи соответствующий SPN
   
   setspn -a http/имя_сервера домен\учетная_запись
   
   (эта утилита входит в состав ОС win2003 и выше, для Win2000 можно скачать отдельно)
   После этого, в свойствах учетной записи появится закладка «Delegation» на которой необходмо выбрать
   (*) Trust this user to delegation to any service (kerberos only)
   
   Если используются веб-части требующие доступ к удаленным ресурсам, то учетной записи компьютера необходимо разрешить делегирование
   (*) Trust this computer to delegation to any service (kerberos only)
   
   Более поднобно о настройке SPN и делегирования смотрите здесь (http://support.microsoft.com/kb/832769)
   
   
6. Чтобы проверить, что аутентификация работает через kerberos, откройте лог безопасности и отфильтруйте по EventID 4624

Операционная система Windows Server 2008 R2 и MS SQL 2008 R2.

При запуске SQL Manager, не запрашивается повышение привилегий.
При этом, sa входит нормально, а Windows Authenticated выдает ошибку.

Причина все таже
Windows Server 2008 R2 проблемы с доступами при интерактивном входе

При запуске с повышенными привилегиями, подключилось нормально.

Если вас вводит в ступор надпись «Your don't currently have permission to acces this folder», то вам сюда :)

Описанное ниже относится к Windows Server 2008 R2 и вероятно к Windows 7

Если вы включены в группу Administrators и эта группа имеет Full Access на какой-либо каталог, то это еще не повод считать что вы имеете туда доступ :)

При поптыке просто открыть каталог винда сообщит вам что у вас нет доступа и предложит назначить его явно вашей учетной записи. После чего вы сможете войти в каталог, но в каждом таком каталоге будет торчать в доступах ваша учетка. Думаю, что наличие учеток в списках доступа мягко говоря напрягает любого админа.

Как говориться, это не глюк, это фича :)
Описания данной фичи пока не нашел.
Практически удалось выяснить, следующее:

Похоже, что в новых ОС, у любого интерактивного пользователя из маркера доступа удаляются все локальные и доменные группы. Таким образом, права интерактивного пользователя на машине ограничиваются правами учетки и встроенных принципалов INTERACTIVE, EVERYONE, Authenticated users, …

Если это действительно так, то можно даже не надеятся настроить разграниченный интерактивный доступ на машину, т.к. все юзеры будут иметь одинаковые права, т.к. будут содержать в маркере доступа только себя и встроенных принципалов.
Вероятно при установке роли терминального сервера эта фича отключается, иначе это будет уже полная лажа со стороны MS.

Давать права INTERACTIVE не есть хорошо, т.к. вы тем самым даете права всем пользователям, которые могут войти на вашу машину интерактивно.

Остается только использовать повышение привилегий, для работы с файлами или каталогами, которые должны быть доступны только админам. Наверно на это и расчитывает MS.

Хотя я подозреваю, что многие будут искать способ отключить эту фичу.
Скорее всего она отключается после отключения UAC и перезагрузки.
Может быть в политиках есть параметр отвечающий только за эту фичу.

Если удалить из группы Users встроенный бюджет INTERACTIVE, то для всех пользователей не включенных группу Users (даже для тех кто включен в группу Administrators) вы будете наблюдать красивый и совершенно пустой рабочий стол.

Рабочий стол тупо не откроется.

Причины описаны в следующей статье:
Windows Server 2008 R2 проблемы с доступами при интерактивном входе

Похоже, что MS заменил название атрибута DiscreteSignatureAlgorithm на AlternateSignatureAlgorithm в Win2008, но это не совсем тоже самое, поэтому и названия разные (см.ниже)

Если я конечно правильно понял самого Брайана Комара, написавшего книгу по PKI.

http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/4256a27f-29ee-42a1-b687-ad3c21e04c0c

Вот дословно его слова:
One last thing, change the term DiscreteSignatureAlgorithm to AlternateSignatureAlgorithm.
I recently discovered that this attribute name was changed just before RTM and was not communicated to me for the book.
Brian

Еще одно косвенное подтверждение:
http://blogs.technet.com/b/askds/archive/2009/10/15/windows-server-2008-r2-capolicy-inf-syntax.aspx

Внимание (ATTENTION!):
Если сертификат ЦС был создан при AlternateSignatureAlgorithm=1
То Windows XP,2003 и ниже, не смогут проверить его подпись.
Ранее, многие источники рекомендовали использовать DiscreteSignatureAlgorithm=1
Вероятно это повышало безопасность подписи и отменяло поддержку каких-то очень древних клиентов. ИМХО на Win2008 DiscreteSignatureAlgorithm=1, просто игнорируется и по умолчанию эквивалентно AlternateSignatureAlgorithm=0. Включение современного алгоритма подписи PKCS#1 V2,1 при AlternateSignatureAlgorithm=1, также как и ранее повышает её безопасность относительно прежнего алгоритма и отменяет поддержку устаревших клинетов WinXP,2003.

Переключил OWA в интегрированный режим аутентификации, проверил все работает.
Решил вернуть обратно на FormBased, проверил, не работает.

Первым делом стал рыть интернет, кто что советует, начиная от синхронизации пролей до полной переустановки роли CA.

MS по данному поводу рекомендует статью http://support.microsoft.com/kb/941201
Но не спешите выполнять описанные там деструктивные действия.
Я испробовал всё, включая переустановку IIS и роли CA.
Проблема же решилась до смешного просто.

Решение:
Проверьте сначала доступы
Пользователь IUSR_< server > должен иметь доступ на исполнение файла
C:\program files\Microsoft\Exchange Server\ClientAccess\Owa\auth\logon.aspx

1. Проверьте каталог Owa, там по умолчанию доступ для Authenticated users, только Read без Execute и это правильно. Это означает, что Authenticated Users не может войти в каталог owa. Без специального разрешение в системной политике Bypass Travers folders.
2. Системная политика Bypass Travers folders разрешает проходить в подкаталоги по полному указанному пути, даже если на выше стоящих уровнях нет разрешения на вход в каталог.
3. По умолчанию политика Bypass Travers folders содержит группу Everyone, Users, …. , заметьте что Authenticated users нет.
4. локальная учетка IUSR_< server > входит в группу Authenticated users, но не входит в группу Everyone (вам покажется это странным, но это так)
5. По умолчанию, группа Users содержит группу Authenticated users. Но многим это умолчание не нарвится и из группы Users как правило всех удаляют. Таким образом IUSR_< server > теряет право Bypass travers и получает Access Deny при попытке выполнить файл по полному пути содержащему каталог owa.
6. После предоставления доступа (например включения Authenticated users в группу Users) не забудьте выполнить iisreset, т.к. сервис получит новый маркер доступа, токлько после перезапуска.

P.S.
Если не хочется включать Authenticated users в грппу Users, то можно поэксперементировать с доступами. Включить IUSR_ в политику Bypass travers или в группу Users. Не стоит также забывать про другую учетку IWAM_.

В Windows Server 2008 изъят сервис POP3.
Это значит, что реализовывать корпоративный сервис на бесплатном почтовике от MS уже не стоит. Т.к. поддержка Windows 2003 в недалёком будущем закончится. MS уже сейчас заявляет что SP3 под Win2003 не будет.

Поэтому, мою статью Корпоративная почта от MS (без Exchage) можно считать устаревшей :(
Буржуи блин :(

Предистория:
   В один прекрасный момент, свалились у меня сразу 3 рабочих терминала работающих в сетевом кластере. Анализ ядра с помощью poolmon показал, что утечка памяти возникает в модуле ядра Toke. Модуль то я определил, а почему в нём возникает утечка нет. Пришлось обратиться в платную поддержку MS. SoftwareAshurance дает возможность использовать 1 обращение по телефону, и неограниченое количество обращение по web. Обращался по web, по телефону все равно не решили бы. Вопрос решался 1 месяц. Дамп памяти передавался в российскую поддержку, затем в европейское отделение поддержки для анализа. Но анализ дампа ничего существенного не прояснил. Причину помог найти метод, предложенный европейской поддержкой. Оказалось, что виной всему сервис Windows AutoUpdate.

Метод определения утечки памяти в ядре системы (для тэгов Paged Pool):

   1. Если сервер падает через определённые интервалы времени непрерывной работы, то скорее всего имеет место утечка памяти в ядре системы.

   2. Мониторим ядро системы с помощью утилиты poolmon и определяем, имеет ли место постоянный рост занятой памяти в каких либо модулях ядра. Если утечка памяти происходит в Paged Pool тэге, то описанные ниже шаги, скорее всего позволят определить процесс вызывающий утечьку памяти (для NonPaged pool тэгов, метод не проверялся).

   Для мониторинга, можно через шедулер запускать с интервалом 1 час, команду
   poolmon.exe —b —n C:\poolmon.log

   (тэги выводятся в убывающем порядке по занимаемой ими памяти)

   3. Мониторим процессы
       Например, используя powershell:

          Get-process | sort Handles —Descending | select —first 10

       и определяем процесс с максимальным значением Handles, кол-во которых постоянно увеличивается.

   4. Если процессом является не svchost, то ищем по реестру, с чем он связан.
       Если процессом является svchost.exe, то определяем сервис с которым он связан 

       tasklist /svc /FI «PID eq < pid процесса svchost >»

       Эта команда, показывает, какие конкретно сервисы работают в данном экземпляре svchost.exe (tasklist в русской версии сервера не работает, используйте от английского)

   5. Если в проблемном экземпляре svchost.exe работает более одного сервиса, то разносим все эти сервисы по отдельным процессам.

       Cохраните, конфигурацию запуска сервиса
       sc query «Краткое имя сервиса, взятое из предыдущего шага»  > > C:\services.txt

       Переведите сервис в отдельный процесс svchost
       sc config «Краткое имя сервиса, взятое из предыдущего шага» type= own

   6. Возвращаемся к шагу 3 и определяем какой конкретно сервис вызывает утечку памяти.
       Если возможно, то гасим сервис и проверяем, освободилась ли память в ядре, используя poolmon.

   7. Возвращаем режим запуска, измененных сервисов в исходное состояние.
       sc config < Краткое имя сервиса > type= < own|share|interact|kernel|filesys|rec|adapt >
       Необходимо выставить режим запуска, в соответствии с цифромыми значениями типа, сохраненными в C:\services.txt.


P.S.
    Говорят ещё бывают аналогичные проблемы из-за разбухания реестра, но я с таким не сталкивался (см. http://www.osp.ru/win2000/2009/04/9048541/)