Windows: полезный список CLSID

А может, и бесполезный. Но пусть будет:

::{d20ea4e1-3957-11d2-a40b-0c5020524153} Administrative Tools  
::{85bbd920-42a0-1069-a2e4-08002b30309d} Briefcase  
::{21ec2020-3aea-1069-a2dd-08002b30309d} Control Panel  
::{d20ea4e1-3957-11d2-a40b-0c5020524152} Fonts  
::{ff393560-c2a7-11cf-bff4-444553540000} History  
::{00020d75-0000-0000-c000-000000000046} Inbox  
::{00028b00-0000-0000-c000-000000000046} Microsoft Network  
::{20d04fe0-3aea-1069-a2d8-08002b30309d} My Computer 
::{450d8fba-ad25-11d0-98a8-0800361b1103} My Documents 
::{208d2c60-3aea-1069-a2d7-08002b30309d} My Network Places 
::{1f4de370-d627-11d1-ba4f-00a0c91eedba} Network Computers 
::{7007acc7-3202-11d1-aad2-00805fc1270e} Network Connections 
::{2227a280-3aea-1069-a2de-08002b30309d} Printers and Faxes 
::{7be9d83c-a729-4d97-b5a7-1b7313c39e0a} Programs Folder  
::{645ff040-5081-101b-9f08-00aa002f954e} Recycle Bin 
::{e211b736-43fd-11d1-9efb-0000f8757fcd} Scanners and Cameras  
::{d6277990-4c6a-11cf-8d87-00aa0060f5bf} Scheduled Tasks 
::{48e7caab-b918-4e58-a94d-505519c795dc} Start Menu Folder  
::{7bd29e00-76c1-11cf-9dd0-00a0c9034933} Temporary Internet Files  
::{bdeadf00-c265-11d0-bced-00a0c90ab50f} Web Folders

подсмотрел тут.

Windows: установка visual C++ 2013 Redistributable

Если при установке vcredist_x86.exe (Update for Visual C++ 2013 and Visual C++ Redistributable Package) возникнет ошибка 0x800b010a (что-то там про цепочку сертификатов), то избавиться от неё помогает импорт сертификата MicRooCerAut2011_2011_03_22.crt во вкладку "Доверенные корневые центры сертификации" в окне управления сертификатами (вызывается, например, через свойства Интернет Эксплорера: Меню «Сервис» - Пункт меню «Свойства обозревателя» - Вкладка «Содержание» - Кнопка «Сертификаты»).

Литература:
A certificate chain could not be built to a trusted root authority

WinXP+IE8: куки

Такая ситуация: пользователя перевели в другой домен, а про куки забыли. Соответственно, они остались в старом профиле. Возник вопрос: как перенести куки?

Оказалось, куки хранятся тут:
C:\Documents and Settings\UserName\Cookies
в виде кучки текстовых файлов и индекса index.dat.

Просто скопировать их в новый профиль не удалось: какой-то процесс держит index.dat, а без его перезаписи вновь прибывшие куки не видны. Наверно, можно было бы перезагрузиться в режиме командной строки и попробовать перезаписать этот файл оттуда, но лень. Поэтому был найден другой способ подсунуть куки в Internet Explorer 8.

Сделать это можно так. Перейти на нужный сайт, в адресной строке набрать javascript-код такого вида:

javascript:document.cookie="newCookieName=newcookieValue; expires=01-Jan-2020";void(0);

и нажать Enter.

Литература:

https://social.msdn.microsoft.com/Forums/ie/en-US/eed564af-f3e0-48ef-ac60-b85dbd44f3d0/how-to-add-manually-a-cookie-in-ie?forum=iewebdevelopment

Посмотреть события Windows в командной строке

Посмотреть системный журнал в командной строке:

wevtutil.exe qe System /c:10 /f:text /rd:true

Смысл ключей такой:
qe System - запросить журнал "Система"
/c:10 - выдать 10 первых записей
/f:text - в виде текста
/rd:true - порядок сортировки - от новых к старым

Перезагрузить компьютер из командной строки

shutdown -r -f

Windows 8: установка .NET Framework 3.5

Понадобилось тут запустить на "Windows 8 для одного языка" некую самописную программку, написанную лет пять назад. Ну, понадобилось - и понадобилось, что тут такого. Однако, в процессе установки открылось, что за эти годы прошла целая эпоха.

Программка при запуске потребовала наличие .NET Framework 3.5. Оказывается, в современных Windows этот фреймворк по умолчанию отключен, и его нужно дополнительно включать/устанавливать, выбрав соответствующий (первый) пункт в списке доступных компонентов Windows ("Панель управления" - "Программы и компоненты" - "Включение и отключение компонентов Windows"). Но приключение только начиналось.

При попытке включить вышеупомянутый флажок система попыталась скачать из Центра обновлений Windows недостающие файлы - и обломалась с ошибкой 0x800F0906. Гугление привело к выводу, что можно попробовать включить эту опцию оффлайн при наличии образа/установочного диска. Образа, конечно, под рукой не оказалось, пришлось его скачивать с сайта Microsoft по ссылке:
https://www.microsoft.com/ru-ru/software-download/windows8ISO
Интересно, что эта ссылка работает, если заходить на неё из-под линукса, а из-под windows посетителя перебрасывает на ссылку:
https://www.microsoft.com/ru-ru/software-download/windows8,
которая предлагает скачать некую утилиту, готовящую для вас нужный образ диска.

Так или иначе, образ диска получил. После этого примонтировал его (команда "Подключить" контекстного меню), у меня он сел на букву E:. Дальше все наперебой предлагают выполнить команду:

DISM.exe /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:E:\sources\sxs

Вот только фигушки: у меня это всё повисело на 65.8% и завершилось ошибкой 0x800F081F.

Дальше начался марафон. Предлагают поправить групповую политику при помощи gpedit.msc - в системе нет gpedit.msc. Предлагают удалить обновления KB2966826 и KB2966828 - но и эти обновления не установлены. В общем, что делать - непонятно.

В конце концов дело оказалось в следующем. Прибил Kaspersky Internet Security - и нужное обновление успешно скачалось (и установилось) из Центра обновлений Windows.

Windows XP: переподключить удалённый компьютер к домену

Дано: компьютер по имени myWS под управлением WinXP, который пашет в другом городе с отключенной учёткой локального админа, но зато в домене myDOMAIN. Для удалённого доступа на этом компьютере установлен Remote Administrator с - какое счастье!- парольной авторизацией. В какой-то момент компьютер теряет связь с доменом, выдавая на всякие runas ошибку "Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом" (The trust relationship between this workstation and the primary domain failed). Как-то надо привести его в чувства.

Решение такое.

1. При помощи Remote Administrator-а заходим на этот компьютер в режиме telnet.

2. Из Windows XP Support Tools закидываем на этот компьютер программу netdom.exe

3. В командной строке выполняем команды:

netdom remove myWS /Domain:myDOMAIN /UserD:myDOMAIN\Admin /PasswordD:***
netdom join myWS /Domain:myDOMAIN /UserD:myDOMAIN\Admin /PasswordD:***

3'. Вроде как есть альтернативный вариант - сбросить учётку компьютера на контроллере (на сервере в контекстном меню "Reset account") и на самом компьютере командой:

netdom reset myWS /Domain:myDOMAIN /UserO:myDOMAIN\Admin /PasswordO:***

но проверить его не удалось: всё заработало и так.
(кстати, забавно, почему там UserO, а не UserD ?)

Ну и в качестве бонуса - памятка, как посмотреть адреса контроллеров домена:

nslookup
> set type=all
> _ldap._tcp.dc._msdcs

UPD 2018-08-03: Как быть в Windows 7.

Выяснилось, что для того, чтобы в системе появился netdom.exe, надо проделать некоторую работу:

1. Установить некие Remote Server Administration Tools for Windows 7.

2. После установки включить соответствующую компоненту. Для этого идём в Панель управления -> Программы -> Программы и компоненты -> Включение или отключение компонентов Windows -> Средства удаленного админинстрирования сервера -> Средства администрирования ролей -> Средства доменных служб ActiveDirecotry и служб ActiveDirectory -> Средства доменных служб ActiveDirectory и ставим галочку напротив пункта "Оснастки и программы командной строки доменных служб ActiveDirectory". Тогда в c:\windows\system32 появляется долгожданная утилита netdom.exe.

Такое подозрение, что всё это через командную строку RAdmin-а проделать не удастся. Так что, видимо, надо заранее закидывать на борт эти самые "Средства удаленного администрирования сервера" - на всякий случай.

Windows: сбросить лишние терминальные сессии

Если при попытке прицепиться к терминальному серверу по RDP, например, командой

mstsc /v:myServer

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

Как оказалось, делается это достаточно просто:

1. Авторизуемся на сервере командой:

net use \\myServer

2. Просматриваем список терминальных сессий командой:

qwinsta /server:myServer

3. Прибиваем лишние сеансы командой:

rwinsta /server:myServer <id сессии>

Windows: коварный Mozilla Thunderbird

Ситуация: есть Mozilla Thunderbird версии, скажем, 31.5.0, на ней настроена некая учетная запись электронной почты. Эта учетка может принимать сообщения, но отправлять - ни в какую. Выглядит это так. Пишем сообщение, нажимаем "Отправить", программа пишет "Компоновка сообщения...", затем на пару секунд задумывается, и выдаёт "Ошибка отправки сообщения. Проверьте настройки своей учетной записи, параметры связи с сервером и т.п." Так вот, эта подсказка - наглая ложь. Подслушка сниффером (например, packetyzer-ом) показывает, что почтовик даже не пытается стукнуться к серверу. И, что тоже интересно, при попытке закрыть неудавшееся сообщение, выдаётся предложение сохранить его в черновики, но сохранение также оказывается безуспешным. При этом, если запустить Thunderbird на той же машине, но под другим пользователем Windows - всё работает.

Оказывается, надо почистить или вообще привести в порядок папки, указанные в переменных окружения TEMP и TMP. Мозилла пытается перед отправкой скомпоновать сообщение во временном файле, и если не может его создать, сильно огорчается.

Но нет худа без добра. Зато выяснилось, как устроить журналирование общения с почтовым сервером. Делается это при помощи такого батника:

set NSPR_LOG_MODULES=SMTP:4
set NSPR_LOG_FILE=C:\temp\log_smtp.txt
"%ProgramFiles%\Mozilla Thunderbird\thunderbird.exe"

Windows batch file: массовое переименование файлов

Понадобилось тут переименовать несколько файлов. Например, было list-март-01.txt, должно стать list-апрель-01.txt. Верный и надежный Far manager в этот раз почему-то не предоставил очевидного решения, как в переименовываемых файлах заменить одну подстроку на другую, поэтому я решил попытать счастья в написании файла .bat:

@ECHO OFF
setlocal enableDelayedExpansion

SET workingPath=c:\temp\
SET filesToRename=list-*
SET stringToSearch=март
SET stringToReplace=апрель

cd %workingPath%
ECHO working path set to %workingPath%

FOR /f "delims=^T" %%f IN ('dir /B %filesToRename%') DO (
    call :myFunc "%%f"
)
GOTO End


:myFunc

SET oldFileName=%1
SET newFileName=!oldFileName:%stringToSearch%=%stringToReplace%!
ren %oldFileName% %newFileName%
ECHO %oldFileName% renamed to %newFileName%
GOTO End


:End

В процессе работы выяснилось много удивительных вещей. Например, что внутри цикла FOR почему-то не срабатывает присвоение SET. Или что команды set и dir обладают массой интересных ключей (в частности, первая при помощи ключа /A умеет вычислять арифметические выражения, а вторая при указании /B возвращает чистые имена файлов без путей). Или что переход по метке может принимать параметр.

В общем, есть, над чем подумать.

Переход на новые часовые пояса 26 окт 2014

Тут, чтобы не расслаблялись, Правительство издало новый закон (Федеральный закон от 21.07.2014 № 248-ФЗ), по которому нам надо будет опять двигать стрелки в ближайшем будущем. В связи с этим предстоят некоторые чудеса.

Во-первых, коварная корпорация Microsoft выпустила обновление KB2998527, в которое, хе-хе, забыла включить WinXP. К счастью, нашлась инструкция, позволяющая это упущение обойти. Написал батничек, который буду выполнять из-под админского аккаунта на рабочих станциях с этой устаревшей ОС:

rem thanks to http://winitpro.ru/index.php/2014/10/10/perexod-na-zimnee-vremya-v-windows-xp/

REG IMPORT TimeZone-WindowsXP.reg
%WINDIR%\System32\tzchange.exe /c "N. Central Asia Standard Time"
Control.exe TIMEDATE.CPL

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

Во-вторых, на Slackware пришлось проделать определенный ритуал. Вкратце:

1. Стащил файл tzdata2014h.tar.gz

2. Распаковал архив, получил кучку файлов, нашел в них свой Novosibirsk (почему-то он оказался в файле europe, видимо, там же лежит вообще вся Россия)

3. Скомпилировал найденный файл командой:

sudo /usr/sbin/zic europe

(Эта штука заодно обновляет соответствующие файлы в каталоге /usr/share/zoneinfo, при этом Новосибирск оказывается в подкаталоге Asia/Novosibirsk)

3. Обновил информацию о своей зоне командой:

sudo cp /usr/share/zoneinfo/Asia/Novosibirsk /etc/localtime

4. Проверил, что запланирован переход, командой:

$ /usr/sbin/zdump -v /etc/localtime | grep 2014
/etc/localtime  Sat Oct 25 18:59:59 2014 UTC = Sun Oct 26 01:59:59 2014 NOVT isdst=0 gmtoff=25200
/etc/localtime  Sat Oct 25 19:00:00 2014 UTC = Sun Oct 26 01:00:00 2014 NOVT isdst=0 gmtoff=21600

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

Вроде, всё ок? Время покажет.

Windows: проблемы с распознаванием DNS-имен

На одном компьютере (Windows 7 64bit) столкнулся с загадочным поведением: команда nslookup some.test.site успешно возвращает ip-адрес, соответствующий доменному имени some.test.site, но команда ping some.test.site при этом пишет "При проверке связи не удалось обнаружить узел some.test.site. Проверьте имя узла и повторите попытку".

По совету отсюда остановил сервис DNS-клиент. В результате узел запинговался.

На всякий случай запишу себе ещё несколько полезных команд
Reset WINSOCK entries to installation defaults :

netsh winsock reset catalog

Reset TCP/IP stack to installation defaults :

netsh int ip reset reset.log

Flush DNS resolver cache :

ipconfig /flushdns

Flush routing table (reboot required):

route /f

Вот тут ещё написано много интересного. Говорят, nslookup использует собственную реализацию gethostbyname(), и поэтому может работать, когда остальные глючат.

Windows: Поднимаем из бэкапов базы MSSQL на другой машине

Рассмотрим такую гипотетическую ситуацию (которая не далее как сегодня утром реализовалась на практике, но это неважно).

Есть у нас компьютер WinServA, на котором живёт-поживает и добра наживает Microsoft SQL Server 2005, хранящий все свои базы в каталоге E:\MSSQL\Data. И вот в один не очень прекрасный день этот сервер умирает. Скажем, отказали диски. Ага, сразу все. Возникает задача - поднять базу на другом, девственно чистом сервере WinServB, который до этого спокойно управлялся ОС Windows 2008, ни сном, ни духом не ведал о каких-то SQL Server-ах две тысячи пятого затёртого года и вообще, имеет свободное место только на диске D:.

Для этого нам понадобится: 1) бэкапы дорогих нашему сердцу баз, 2) бэкапы системных баз почившего сервера 3) немного валидола.

Шаг первый - поднимаем Microsoft SQL Server 2005 на Windows 2008.

Тут возможны всяческие чудеса. Например, однажды MSSQL отказывался ставиться до тех пор, пока система не притворилась, что у неё один процессор. Сегодня же нас порадовали другой ошибкой - в процессе установки MSSQL Native Client вываливается сообщение Error 1603, а файлы логов в папке C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG содержат примерно такое разъяснение:
An error occurred during the installation of assembly 'Microsoft.VC80.CRT,type="win32",version="8.0.50727.42",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86"'. Please refer to Help and Support for more information. HRESULT: 0x80070BC9. assembly interface: IAssemblyCacheItem, function: Commit, component: {98CB24AD-52FB-DB5F-A01F-C8B3B9A1E18E}
Решением оказалось в реестре прописать параметр:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control 
Key: RegistrySizeLimit 
Type: REG_DWORD 
Value: 0xffffff (4294967295)

перезагрузиться и прогнать инсталляцию ещё раз.

Дальше интереснее. Для второго шага требуется, чтобы версии старого и нового SQL Server-ов совпадали. Умерший сервер был версии 9.0.5057. Новый, после установки SP4 - 9.0.5000. Очевидно, на старый сервер накатывались какие-то обновления Центром обновлений. Но какие? Тут приходит на помощь вот эта таблица. В частности, в нашем случае помогает установка kb2494120. И можно переходить к следующему шагу.

Шаг второй - восстанавливаем системные базы из бэкапов.

На самом деле хватает трёх бэкапов: master, msdb и model. Но ситуация осложняется тем, что отличаются пути, по которым жили базы на старом сервере и на новом. Помолясь, поступаем так:
a) Находим в списке сервисов сервис MSSQLSERVER и останавливаем его. В свойствах сервиса прописываем параметр командной строки -m и запускаем сервис снова. После этого СУБД стартует в однопользовательском режиме.
b) Заходим в Microsoft SQL Server Management Studio, оно предложит законнектиться к какой-нибудь базе, мы отказываемся. Нажимаем кнопку "New Query" и пишем следующее:

RESTORE DATABASE master FROM DISK='c:\temp\master.bak' WITH REPLACE

Нажимаем конпку "Execute", указываем наконец, к какой базе прицепиться, и ждём.
Сервер сообщит, что база данных восстановлена, и работа будет продолжена после перезапуска сервиса. Фигушки, с восстановленной базой сервис запускаться откажется, указав примерно такую причину в системном журнале Windows: Could not open file E:\MSSQL\Data\mssqlsystemresource.mdf
c) Тут самое время запустить SQL Server из командной строки примерно такой командой:

"C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe" -f -T3608

Сервер снова станет доступным, и тогда через Microsoft SQL Server Management Studio удастся сменить пути для всех системных баз на их реальное местоположение в новом сервере:

ALTER DATABASE mssqlsystemresource modify file (name=data,filename='D:\MSSQL\Data\mssqlsystemresource.mdf')
ALTER DATABASE mssqlsystemresource modify file (name=log,filename='D:\MSSQL\Data\mssqlsystemresource.ldf')
ALTER DATABASE msdb modify file (name=MSDBData,filename='D:\MSSQL\Data\msdbdata.mdf')
ALTER DATABASE msdb modify file (name=MSDBLog, filename='D:\MSSQL\Data\msdblog.ldf')
ALTER DATABASE model modify file (name=modeldev,filename='D:\MSSQL\Data\model.mdf')
ALTER DATABASE model modify file (name=modellog, filename='D:\MSSQL\Data\modellog.ldf')
ALTER DATABASE tempdb modify file (name=tempdev,filename='D:\MSSQL\Data\tempdb.mdf')
ALTER DATABASE tempdb modify file (name=templog, filename='D:\MSSQL\Data\templog.ldf')

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

SELECT name, physical_name
FROM sys.master_files

d) После этого можно попробовать вновь запустить штатно сервис MSSQLSERVER и восстановить оставшиеся системные базы:

RESTORE DATABASE msdb FROM DISK='C:\temp\msdb.bak' WITH REPLACE
RESTORE DATABASE model FROM DISK='C:\temp\model.bak' WITH REPLACE

По завершении этой процедуры у нас в руках оказывается живой сервер с восстановленными системными базами.

Шаг третий - восстанавливаем из бэкапов интересующие нас базы.

Это уже делается тривиально, со штатным использованием соответствующих пунктов контекстного меню Microsoft SQL Server Management Studio. Единственное - каждую базу придётся перед восстановлением из бэкапа пересоздать.

Шаг четвертый - пытаемся запустить SQL Server Agent.

Если тот не хочет стартовать с ошибкой Error creating a new session, значит, что-то не слава богу с правами. Нам помогло следующее:
a) на сервере выполнили команды:

sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'Agent XPs', 1;
GO
RECONFIGURE
GO

b) В группу пользователей SQLServer2005SQLAgentUser$ServerName добавили учетную запись, под которой сервис этого самого агента у нас запускается. Не знаем точно, что из этого помогло, но больше SQL Server Agent нам не жаловался.

Шаг пятый - выставляем правильное имя сервера в планах обслуживания.

Если были настроены какие-то планы обслуживания, то в них нужно поменять свойства локальных подключений (Local connection). Сделать это можно либо через редактирование планов в Microsoft SQL Server Management Studio (кнопка Manage connections), либо выполнив вот такой скрипт:

use msdb

-- указываем имя старого сервера
DECLARE @oldservername as varchar(max)
SET @oldservername='WinServA'

-- указываем имя нового сервера
declare @newservername as varchar(max)
set @newservername='WinServB'

declare
    @planid      uniqueidentifier,
    @xml         varchar(max),
    @planname    varchar(max)

-- вытаскиваем все планы, в строке подключения которых значится старый сервер
DECLARE PlansToFix LOCAL STATIC CURSOR FOR
SELECT
    id
FROM sysdtspackages90
WHERE (CAST(CAST(packagedata AS varbinary(MAX)) AS varchar(MAX)) LIKE '%server=''' + @oldservername + '%')

OPEN PlansToFix
FETCH NEXT FROM PlansToFix INTO @planid

WHILE (@@fetch_status != -1)
    BEGIN

    if (@@fetch_status != -2)
        begin

        -- получаем имя плана и его содержимое в виде xml-строки
        select
            @xml = cast(cast(packagedata as varbinary(max)) as varchar(max)),
            @planname = name
        from sysdtspackages90
        where id = @planid

        -- печатаем пользователю, какой план патчим
        print 'Changing ' + @planname + ' server from ' + @oldservername + ' to ' + @newservername

        -- меняем упоминания старого сервера на новый
        set @xml = replace(@xml,'server=''' + @oldservername + '''','server=''' + @newservername +'''')

        -- обновляем план
        UPDATE sysdtspackages90
        SET packagedata = cast(@xml as varbinary(max))
        WHERE id = @planid

        end

    FETCH NEXT FROM PlansToFix INTO @planid  

    END

CLOSE PlansToFix
DEALLOCATE PlansToFix

Вот, собственно, и всё.

Windows: названия служб

Вот тут http://rusopen.com/sluzhby-windows-7/167-upravlenie-sluzhbami-cherez-komandnuyu-stroku нашел очень ценную табличку.

Windows: ошибка в MS Office Document Imaging

Неожиданно стал дохнуть Microsoft Office Document Imaging при попытке зайти в меню "Файл" вот с такой ошибкой:
Faulting application mspview.exe, version 11.0.8166.2, stamp 4616c203, faulting module mspview.exe, version 11.0.8166.2, stamp 4616c203, debug? 0, fault address 0x00016537.

Говорят, есть специальный патч:
http://support.microsoft.com/kb/938813

Поставил. Не помогло. Оказывается, надо было читать дальше 8-). Дело было в длинном имени файла, фигурирующем в следующей ветке реестра:
HKEY_CURRENT_USER\Software\Microsoft\MSPaper 11.0\Recent File List

Почистил виновный параметр, и всё заработало.

Windows: где находится мастер работы со сканером

Оказывается, здесь:
C:\WINDOWS\system32\wiaacmgr.exe

А вот тут есть еще некоторое количество команд:
http://jitendra07.blogspot.ru/2007/03/hidden-command-line-which-u-should-know.html
http://www.brighthub.com/computing/windows-platform/articles/58574.aspx

Windows XP: Не удалось выполнить действие из-за неправильной установки клиента почты по умолчанию

Две машины. На одной всё хорошо (ну как всё...), на другой при попытке в excel-е кликнуть на гиперссылку, содержащую e-mail, получаем вышеуказанную ошибку.

Оказалось, в реестре почему-то испортился раздел HKLM\Software\Classes\mailto.
На здоровой машине, у которой почтовым клиентом числится OE, этот раздел должен выглядеть так:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto]
@="URL:Протокол MailTo"
"EditFlags"=hex:02,00,00,00
"URL Protocol"=""

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\DefaultIcon]
@=hex(2):25,00,50,00,72,00,6f,00,67,00,72,00,61,00,6d,00,46,00,69,00,6c,00,65,\
  00,73,00,25,00,5c,00,4f,00,75,00,74,00,6c,00,6f,00,6f,00,6b,00,20,00,45,00,\
  78,00,70,00,72,00,65,00,73,00,73,00,5c,00,6d,00,73,00,69,00,6d,00,6e,00,2e,\
  00,65,00,78,00,65,00,2c,00,2d,00,32,00,00,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open\command]
@=hex(2):22,00,25,00,50,00,72,00,6f,00,67,00,72,00,61,00,6d,00,46,00,69,00,6c,\
  00,65,00,73,00,25,00,5c,00,4f,00,75,00,74,00,6c,00,6f,00,6f,00,6b,00,20,00,\
  45,00,78,00,70,00,72,00,65,00,73,00,73,00,5c,00,6d,00,73,00,69,00,6d,00,6e,\
  00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,00,6d,00,61,00,69,00,6c,00,75,00,\
  72,00,6c,00,3a,00,25,00,31,00,00,00

Remote Control is disabled

Неожиданно при попытке подконнектиться к удаленной машине при помощи Configuration Manager Remote Control стало после окошка с авторизацией выскакивать сообщение "Remote Control is disabled". Не знаю уж отчего такое произошло, но в моем случае помогла правка реестра:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Client Components\Remote Control]
"Enabled"=dword:00000001

Доступ к папке принтеров из командной строки Windows XP

Как известно, всякие настройки можно вызывать из командной строки. Вот, например, для принтеров:

control.exe printers

Однако, если мы хотим использовать это в связке с командой runas, возникают трудности. Например, с теми же принтерами команда:

runas /user:domain\admin "control.exe printers"

ничего не отображает.

Оказалось, что "Принтеры" - это специальная папка, открывается она при помощи explorer.exe, её можно открыть вообще "в лоб" вот так:

%windir%\Explorer.exe ::{2227A280-3AEA-1069-A2DE-08002B30309D}

А explorer.exe, похоже, по умолчанию не создает отдельный процесс с нужными правами, а либо подживается к уже существующему, либо просто тихо дохнет. Чтобы его от этой вредной привычки отучить, требуется при помощи редактора реестра прописать для админской учетки параметр HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\SeparateProcess равным 1.
UPD 13-05-28: Есть еще вариант запуска с хитрым ключом:

explorer /separate

То есть последовательность действий такова:

1. запускаем regedit.exe командой:

runas /user:domain\admin regedit.exe

Правим там параметр HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\SeparateProcess = dword:00000001

2. Получаем на экран папку с принтерами:

runas /user:domain\admin "control.exe printers"

И делаем там своё чёрное админское дело...

Windows: Служба "Служба профилей пользователей" препятствует входу в систему

Q:При попытке залогиниться на компе с Windows 7 под доменной учеткой выдается сообщение: Служба "Служба профилей пользователей" препятствует входу в систему. Невозможно загрузить профиль пользователя."
A: Помогло следующее (цитата):
Заходим под другой учеткой с наличием администраторских прав. В ресстре идем по ветке HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\ Там уже раздел с ID нужного нам пользователя (нужный нам раздел можно найти по ключам, указывающим путь к профилям). Оказывается, что правильный раздел был с именем вида <идентификатор>.bak + к тому же существовал раздел с таким же идентификатором, но без .bak, в котором путь к профилю был указан ошибочно. Итак, удаляем раздел с ошибочным путем, переименовываем правильный раздел, удалив в нем .bak и перелогиниваемся уже под той учеткой, под которой войти не удалось.

Фишки Windows

Q: Где посмотреть путь до рисунка рабочего стола?
A: HKEY_CURRENT_USER\Control Panel\Desktop

Q: Как изменить права пользователя на доступ к папке из командной строки?
A: Воспользоваться утилитой cacls (по крайней мере, в WinXP):
cacls C:\WINDOWS\HUH-MUH /T /E /g Пользователи:С