При установке SQL Server Express возникает ошибка:

Программе установки SQL Server не удалось получить сведения о системной учетной записи для учетной записи ASPNET. Чтобы продолжить, переустановите платформу .NET Framework, а затем снова запустите программу установки SQL Server.

Английский вариант:
SQL Server Setup failed to obtain system account information for the ASPNET account. To proceed, reinstall the .NET Framework, and then run SQL Server Setup again.

Лекарство:

Запускаем CMD:

cd C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
aspnet_regiis -i

После создания ASPNET-учётной записи, можно повторно запускать установку SQL Server.

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

Но всегда ли есть возможность воспользоваться SQL Profiler`ом!? А самое главное работа Profiler приводит к значительным накладным расходам. Основные затраты идут на создание наборов строк для отправки их клиенту Profiler. В этом плане трассировка с помощью команд T-SQL позволяет минимизировать воздействие на производительность, т.к. она выполняется на стороне сервера и избегает перегрузки.

Кромя того, большинство экспертов по MS SQL Server, в том числе и сотрудники Microsoft рекомендуют отдать предпочтение трассировке на стороне сервера. Это подтверждают и тесты, особый интерес у меня (думаю и у вас) вызвала статья Performance Impact: Profiler Tracing vs. Server Side SQL Tracing.

Разница в замерах чуть ниже, а сейчас скажу о чём собственно это статья и что же это за удобная процедура трассировки: как извесно трассирывание на T-SQL очень трудоёмкая задача и не слишком понятная для начинающих администраторов/разработчиков, поэтому у меня и возникла идея написать что-то более понятное и удобное для повседневного использования.