Архив рубрики: Windows

Файлы cab_xxxx в директории windows\temp

Windows,

В последнее время начали появляться проблемы со свободным местом на системных дисках на нескольких компьютерах. Свободные 100 Гб медленно но верно исчезали пока пользователи не начинали получать предупреждения о недостатке места на диске. Выяснялось, что все место исчезало благодаря файлам cab_xxxx, где xxxx — 4 цифры. Эти файлы лежали в директории C:\Windows\Temp. Простое удаление файлов освободит место, но не исправит проблему. Единственно верное решение — удалить эти файла,  а также удалить логи из директории C:\Windows\Logs\CBS. Только в таком случае временные файлы перестанут появляться и съедать весь диск.

Проблема возникает из-за того, что система не может заархивировать один или несколько логов из этой директории. В итоге остается временный файл cab_xxxx и каждые 30-60 минут появляется новый, что и приводит к переполнению диска.

Powershell script cannot be loaded because the execution of scripts is disabled on this system

Powershell

Те, кто работает с ОС Windows, рано или поздно, будут вынуждены столкнуться с написанием скриптов на powershell. Microsoft очень старается, чтобы это произошло как можно раньше и пихает его чуть менее чем везде. Но радость от powershell была бы не полной, без ограничений по запуску скриптов. При попытке запуска написанного скрипта, 99% новичков получают следующую ошибку:

File C:\scripts\psscript.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about_signing" for more details.
At line:1 char:23
+ C:\scripts\psscript.ps1 <<<<
 + CategoryInfo : NotSpecified: (:) [], PSSecurityException
 + FullyQualifiedErrorId : RuntimeException

Как видим, Microsoft озаботилась безопасностью и отключила возможность запуска ps-скриптов. Совсем. Естественно, можно почитать мануал по команде

get-help about_signing

но кто это будет делать? Текста там много и он неинтересный. А результат будет все равно одним — необходимо разрешить запуск всех скриптов. Запускаем powershell с правами администратора и выполняем следующую команду:

Set-ExecutionPolicy Unrestricted

После этого powershell запросит подтверждение и отключит защиту. Если же ошибка не пропадает и после этого — значит у вас 64-разрядная ОС. В таком случае эту команду надо выполнить и в powershell x86 и в x64 — у них свои собственные настройки.

Список медленных запросов MS SQL

Microsoft SQL Server, Windows,

Довольно часто причиной медленной работы SQL-сервера является не слабое железо, а неоптимизированные запросы. Если бы речь шла про MySQL, все было бы просто — достаточно включить лог медленных запросов и задать длительность запроса, после которой он считается медленным. Но в MS SQL все не может быть настолько просто! Итак, зачастую на SQL-серверах медленные запросы возникают по причине большого количества операций чтения с диска. Если данных необходимо вычитать много, лежат они в разных концах диска (или рэйд-массива), да и параллельно с этим есть еще десяток-другой читающих потоков, время выполнения запроса может измеряться десятками секунд. Неплохо было бы такие запросы оптимизировать. А первый шаг оптимизации — их поиск.

Ползая по интернету именно с целью поиска запросов, которые укладывают (ненадолго) на лопатки SQL-сервер, я наткнулся на замечательную статью: «Optimizing SQL Server Query Performance«. Если вы хотите всерьез заняться оптимизацией запросов — ее стоит прочитать полностью. Но меня в данном случае заинтересовал только один запрос, который позволяет получить из статистических данных «самые-самые» запросы:

SELECT TOP 20 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1, 
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(qt.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2)+1), 
qs.execution_count, 
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC

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

Решение проблемы «The trust relationship between this workstation and the primary domain failed» без вывода ПК из домена

Active Directory, Windows,

По самым разным причинам можно столкнуться с проблемой невозможности входа в систему на компьютере, включенном в домен. Если это происходит на обычном клиентском ПК — ничего не мешает вывести его из домена и добавить заново — проблема решается гарантированно. Но если дело касается сервера, на котором крутятся приложения, завязанные на AD — рисковать выводом сервера из домена не очень хочется. К счатью, способ «возврата» к нормальному состоянию есть.

Вообще, проблема с невозможностью залогиниться в домен с такой ошибкой, сопровождается записью в системном логе следующего содержания:

 This computer could not authenticate with DomainController’ a Windows domain controller for domain DOMAIN, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized. If this message appears again, contact your system administrator.

Т.е., как обычно у майкрософта, ничего конкретного о способах решения в ошибке не сказано. Корни проблемы уходят в доменную авторизацию: по умолчанию, пароль для учетной записи компьютера имеет срок жизни в 30 дней. Если ОС не связывалась с доменом в течение этого срока или, например, вы восстановили из бэкапа 30-дневной давности сервер/виртуалку — вы не сможете залогиниться на него под доменной учетной записью. Для исправления этой ситуации необходимо:

1. Залогиниться на сервер под локальной учетной записью с администраторскими полномочиями;

2. Выполнить команду klist purge для очистки кэша Kerberos на сервере.

3. Выполнить команду  «netdom resetpwd /s:x.x.x.x  /ud:domain\User /pd:*», где x.x.x.x — IP-адрес контроллера домена, domain\User — учетная запись администратора домена с указанием имени домена.

4. После запроса пароля — ввести пароль от учетной записи администратора домена.

5. Перезагрузить сервер и залогиниться под учетной записью администратора домена.

Если это не помогло — вам поможет только вывод компьютера из домена и повторное его туда включение. Или техподдержка Майкрософта :)

Перезапуск процесса восстановления Exchange 2010 в случае ошибки

Exchange 2010, ,

При переносе сервера MS Exchange 2010 в конфигурации отличной от единственного сервера, могут возникать непредвиденные проблемы. Даже несмотря на то, что установщик выполняет большое количество проверок, бывают непредвиденные обстоятельства, из-за которых процесс установки прерывается. Казалось бы, нет ничего проще, чем запустить восстановление заново. Но если бы все пошло хорошо — это был бы не тот майкрософт :)

Если при установке все проверки пройдены и начался собственно этап установки, то после сбоя и повторного запуска, вы увидите примерно такую ошибку: «Setup previously failed while performing the action DisasterRecovery. You can’t resume setup by performing the action install». При этом, запустить Uninstall тоже нельзя. Да и вообще ничего нельзя сделать при помощи этого инсталлятора.

И, что характерно для майкрософта, решение проблемы находится в реестре. Для возобновления работы установщика, необходимо перейти в ветку:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v14

Найти там разделы с именами ролей сервера (HubTransportRole, MailboxRole и др.) и удалить из них все ключи с именами «Watermark» и «Action». После этого установка перезапустится без проблем.