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

Невозможно войти в скайп. There was an issue looking up your account

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

There was an issue looking up your account. Tap Next to try again

При этом скайп вполне себе спокойно был запущен на соседнем компьютере. Перезапуск скайпа, естественно, не помог. Недолгий поиск в гугле подсказал решение:

  1. Выгружаем скайп.
  2. Открываем Internet Explorer.
  3. Идем в Internet Options -> Advanced -> Reset и ставим галочку напротив единственного пункта «Reset personal settings».
  4. Нажимаем Reset и дожидаемся окончания процесса.
  5. Может потребоваться перезагрузка (!). IE скажет об этом всплывающим сообщением на желтом фоне внизу. Перезагружаемся, если требуется.
  6. Запускаем Skype и логинимся (у меня даже пароль не спросил после этого).

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

В последнее время начали появляться проблемы со свободным местом на системных дисках на нескольких компьютерах. Свободные 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

Те, кто работает с ОС 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

Довольно часто причиной медленной работы 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» без вывода ПК из домена

По самым разным причинам можно столкнуться с проблемой невозможности входа в систему на компьютере, включенном в домен. Если это происходит на обычном клиентском ПК — ничего не мешает вывести его из домена и добавить заново — проблема решается гарантированно. Но если дело касается сервера, на котором крутятся приложения, завязанные на 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. Перезагрузить сервер и залогиниться под учетной записью администратора домена.

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