Отключаем проверку цифровой подписи драйверов в Windows 7 с помощью bcdedit

Для того, чтобы отключить проверку цифровой подписи необходимо открыть командную строку с правами администратора:

bcdedit.exe /set loadoptions DDISABLE_INTEGRITY_CHECKS 

bcdedit.exe /set TESTSIGNING ON

После перезагрузки на рабочем столе Windows высветится надпись:

Тестовый режим
Windows 7
Сборка 7601

Чтобы включить проверку цифровой подписи:

bcdedit.exe /set loadoptions ENABLE_INTEGRITY_CHECKS

bcdedit.exe /set TESTSIGNING OFF

Как изменить стандартный порт 3389 в RDP

Как изменить входящий порт службы RDP  со стандартного 3389 на другой:

1. Открываем редактор реестра (Пуск -> Выполнить -> regedit.exe)

2. Переходим к разделу:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Control\ Terminal Server\WinStations\RDP-Tcp

3. Находим ключ PortNumber и меняем его значение на другой незанятый номер порта, который нужен

Для подключению к этому компьютеру Пуск -> Выполнить (или Win+R)

mstsc /v:192.168.100.100:19345

Для просмотра других параметров  наберите mstsc /?

Windows 7 / Server 2008 R2 Bare Metal Restore 0x0000007B Stop Error

 

I am tring to restore a Server 2008 R2 Standard Ed (full installation) RTM to a virtual machine, from a full Windows Server Backup image taken of a physical machine.  All restores fine, and looks good until it tries to boot, when a Stop Error occurs, with the following error:

*** STOP: 0x0000007B (0xFFFFF880009A9928, 0xFFFFFFFFC0000034, 0x0000000000000000, 0x0000000000000000)

I believe the non-bracketed portion means "INACCESSABLE_BOOT_DEVICE".

After completing the BMR process don't restart.
Select Command Prompt.
regedt32<CR>
Highlight HKEY_LOCAL_MACHINE, File>Load Hive>[restored volume]:\Windows\System32\Config\SYSTEM>Open>Key Name = Restored_HKLM>OK.
Expand Restored_HKLM\ControlSet001\services and ensure the following are set:
  If restored to a (VMWare) VM then ensure intelide>Start = 0 and LSI_SAS>Start = 0; msahci>Start = 3 and pciide>Start = 3
  NB: I have only tested this with VMWare VMs (Player/Workstation and vSphere) but will likely translate across to Microsoft (e.g. HyperV) VMs. The LSI_SAS value is definitely required, I couldn't boot in a VM until this was chaned to 0.
  Or if restoring to a physical machine with native HDD controller then ensure msahci>Start = 0 and pciide>Start = 0; intelide>Start = 3 and LSI_SAS>Start = 3
Highlight Restored_HKLM and then File>Unload Hive.
Close windows and restart 

Settings for typical destination machines:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
VMWare VM:
aliide 3
amdide 3
atapi 0
cmdide 3
iastorv 3
intelide 0
msahci 3
pciide 3
viaide 3
LSI_SAS 0
Dell PE2970 physical machine with RAID card:
aliide 3
amdide 3
atapi 0
cmdide 3
iastorv 3
intelide 3
msahci 0
pciide 3
viaide 3
LSI_SAS 3
Dell PET100 physical machine on native SATA adapter:
aliide 3
amdide 3
atapi 0
cmdide 3
iastorv 3
intelide 3
msahci 0
pciide 0
viaide 3
LSI_SAS 3
Win 7 64x custom built physical machine on native SATA adapter:
aliide 3
amdide 3
atapi 0
cmdide 3
iastorv 3
intelide 3
msahci 0
pciide 0
viaide 3
LSI_SAS 3

KEY FOR SERVICE START VALUES:
0 = Start
1 = ?
2 = Automatic
 with DelayedAutostart = 1 = Automatic (Delayed Start)
3 = Manual
4 = Disabled

Где в Windows хранится реестр?

После установки Windows на диске в каталоге %SystemRoot%\System32\Config\ (например, C:\Windows\System32\Config\) хранятся следующие файлы:

• system
• software
• sam
• security
• default

(Все файлы (имена файлов) без расширений. Копия этих файлов хранится в каталоге C:\Windows\Repair\)
Кроме того, файлы, используемые при построении «рабочей версии» реестра, могут храниться в каталогах:

• %SystemDrive%\Documents and Settings\<Username>\ — файл «Ntuser.dat»
• %SystemDrive%\Documents and Settings\<Username>\Local Settings\Application Data\Microsoft\Windows\ — файл «UsrClass.dat»

Кроме этого, могут появляться и другие файлы реестра: userdiff (и userdiff.LOG), TempKey.LOG, и, возможно, другие

Можно провести некое примерное соответствие файлов и веток реестра, но оно не такое простое, полное и однозначное. Однако примерно можно сказать следующее:

• Ветка реестра «HKEY_LOCAL_MACHINE\Software» формируется из файла «%SystemRoot%\system32\config\software».
• Ветка реестра «HKEY_LOCAL_MACHINE\System\» формируется из файла «%SystemRoot%\system32\config\system».
• Ветка реестра «HKEY_LOCAL_MACHINE\SAM\» формируется из файла «%SystemRoot%\system32\config\SAM».
• Ветка реестра «HKEY_LOCAL_MACHINE\SECURITY\» формируется из файла «%SystemRoot%\system32\config\SECURITY».
• Ветка реестра «HKEY_LOCAL_MACHINE\HARDWARE\» формируется в зависимости от оборудования(динамически).
• Ветка реестра «HKEY_USERS\<SID_пользователя>» формируется из файлов «%USERPROFILE%\ntuser.dat»
• Ветка реестра «HKEY_USERS\DEFAULT» формируется из файлов «%SystemRoot%\system32\config\default»

Windows Vista

В Windows Vista файлы реестра хранятся там же, где и в Windows XP.

Windows 7

В Windows 7, согласно сведениям из HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist файлы реестра хранятся в следующих местах:

• 01= Ветка реестра «HKEY_LOCAL_MACHINE\HARDWARE» формируется в зависимости от оборудования (динамически);
• 02= Ветка реестра «HKEY_LOCAL_MACHINE\BCD00000000» формируется из файла «%SystemRoot%\Boot\BCD»
• 03= Ветка реестра «HKEY_LOCAL_MACHINE\SYSTEM» формируется из файла «%SystemRoot%\System32\config\SYSTEM»
• 04= Ветка реестра «HKEY_LOCAL_MACHINE\SOFTWARE» формируется из файла «%SystemRoot%\System32\config\SOFTWARE»
• 05= Ветка реестра «HKEY_LOCAL_MACHINE\SECURITY» формируется из файла «%SystemRoot%\System32\config\SECURITY»
• 06= Ветка реестра «HKEY_LOCAL_MACHINE\SAM» формируется из файла «%SystemRoot%\System32\config\SAM»
• 07= Ветка реестра «HKEY_USERS\.DEFAULT» формируется из файла «%SystemRoot%\System32\config\DEFAULT»
• 08= Ветка реестра «HKEY_USERS\S-1-5-18» формируется из файла «%SystemRoot%\System32\config\systemprofile\NTUSER.DAT» (относится к учетной записи system)
• 09= Ветка реестра «HKEY_USERS\S-1-5-19» формируется из файла «%SystemRoot%\ServiceProfiles\LocalService\NTUSER.DAT» (относится к учетной записи LocalService)
• 10= Ветка реестра «HKEY_USERS\S-1-5-20» формируется из файла «%SystemRoot%\ServiceProfiles\NetworkService\NTUSER.DAT» (относится к учетной записи NetworkService)
• 11= Ветка реестра «HKEY_USERS\<SID_пользователя>» формируется из файла «%USERPROFILE%\NTUSER.DAT»
• 12= Ветка реестра «HKEY_USERS\<SID_пользователя>_Classes» формируется из файла «%USERPROFILE%\AppData\Local\Microsoft\Windows\UsrClass.dat»

Резервные копии файлов реестра DEFAULT, SAM, SECURITY, SOFTWARE и SYSTEM находятся в папке «%SystemRoot%\System32\config\RegBack». Само резервное копирование производится силами Планировщика задач в 0 ч. 00 мин. каждые 10 дней по заданию «RegIdleBackup», расположенному в иерархии задач по пути «\Microsoft\Windows\Registry».

IP-адрес и реестр

 

Все параметры TCP/IP являются значениями реестра, расположенными в одном из двух разных подразделов 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Tcpip\Parameters

Tcpip\Parameters\Interfaces\код_адаптера

 

Примечание. код_адаптера – это адаптер сети, к которому привязан протокол TCP/IP. Чтобы определить взаимоотношения между кодом адаптера и подключением к сети, просмотрите параметр

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\<ID for Adapter>\Connection

 

Параметр Name этих разделов содержит имя сетевого подключения, используемое в папке «Сетевые подключения». Значения в разделах зависят от адаптера. Параметры, имеющие значение, настроенное с помощью DHCP, и статическое значение, могут отсутствовать. Наличие этих параметров зависит от того, настраивается ли компьютер или адаптер сервером DHCP и указываются ли значения вручную. Чтобы изменение вступило в силу, необходимо перезагрузить компьютер

Настраиваемые параметры

http://support.microsoft.com/kb/314053

 

 

 

Тонкости downgrade Microsoft Server

Если новые лицензии будут приобретаться по программе Open License, после регистрации номера лицензии на сайте VLSC (регистрироваться необходимо именно с тем адресом электронной почты, который указывался при приобретении лицензии) на этом сайте будут доступны ключи продуктов как для Windows Server 2012, так и для предыдущих версий, а также скачиваемые дистрибутивы для установки последней и как минимум одной предыдущей версии. При желании можно использовать именно эти ключи для активации копий Windows Server 2008 R2, используемых по лицензии Windows Server 2012; однако требования строгого соответствия между ключами и лицензиями нет (более того, такое требование даже теоретически не может быть выполнено, например, если Windows Server устанавливается в виртуальных машинах, и эти машины могут быть запущены на любом из имеющихся серверов, лицензии для которых закупались в разное время). Необходимо только использовать ключи, полученные организацией законным путём (иначе, помимо всего прочего, система может не пройти проверку WGA), и соответствующие типу дистрибутива (ключ с VLSC не подойдёт к OEM-дистрибутиву, и наоборот).

Дистрибутивы можно использовать и старые, если они были также получены по OLP (но могут быть и причины скачать новые — например, если с того времени вышел очередной Service Pack, и на сайте доступен дистрибутив со встроенным новым SP). Если же старые дистрибутивы есть только типа OEM или BOX, пользоваться ими (и соответствующими ключами, которые, вероятнее всего, потребуют последующей активации по телефону) имеет смысл только при отсутствии доступа к нужным версиям через VLSC (и если обращение в службу поддержки VLSC по вопросу получения доступа к дистрибутивам нужных версий не дало результата).

Число активаций в любом случае будет учитываться отдельно для каждого ключа, поэтому сделать так, чтобы установленный и активированный MAK-ключом экземпляр Windows Server 2008 R2 учитывался на сайте Microsoft как Windows Server 2012, не получится. Однако учёт числа активаций по ключам не имеет никакого отношения к учёту количества используемых лицензий — например, если просто переустановить и заново активировать систему на том же сервере, будет зарегистрирована новая активация, хотя число используемых экземпляров от такого действия не изменяется. Ограничение на количество активаций MAK-ключей не предназначено для жёсткого контроля за соблюдением лицензионного соглашения (обычно это ограничение значительно выше, чем число разрешённых экземпляров, и в случае необходимости может быть увеличено после звонка в центр активации Microsoft). Кроме того, при корпоративном лицензировании ограничивается не количество установленных и активированных копий Windows Server, а количество одновременно запущенных экземпляров, так что количество активаций может вполне законным образом быть больше, чем разрешённое имеющимися лицензиями количество запускаемых экземпляров, если все эти экземпляры никогда не запускаются одновременно.

При наличии в организации более 5 серверов с Windows Server ≥ 2008 можно установить сервер KMS (используя для этого доступный через VLSC ключ KMS — не следует использовать этот ключ для активации обычных серверов), после чего все остальные экземпляры Windows Server, используемые в организации, могут быть активированы сервером KMS вообще без какой-либо связи с Microsoft. В этом случае соблюдение лицензионных ограничений по количеству экземпляров Windows Server полностью остаётся на совести администратора — технические средства для ограничения количества активируемых копий в сервере KMS отсутствуют.

Также необходимо учитывать, что правила лицензирования Windows Server 2012 изменились по сравнению с предыдущими версиями — в частности, количество процессоров теперь учитывается даже для редакции Standard (при наличии в сервере более 2 процессоров необходимо приобретение не менее чем одной лицензии на каждые два процессора), и каждая лицензия редакции Standard даёт право запуска двух экземпляров Windows Server (2012 или предыдущих версий) в виртуальных средах. При этом по лицензии Windows Server 2012 Standard можно использовать Windows 2008 R2 Enterprise (либо предыдущие версии редакции Enterprise), однако старое правило «1 лицензия Windows Server Enterprise = 4 виртуальные машины» необходимо забыть — количество разрешённых экземпляров будет определяться правилами лицензирования Windows Server 2012.

Тип узла (Node Type) и разрешение имен

Параметр Тип узла задает порядок применения методов которые будет использованы NetBT для регистрации и разрешения имен NetBIOS.

Возможные значения :
B-node (Broadcasting - Широковещательный)
метод использует широковещательную рассылку запроса для разрешения имен
Значение 1
P-node (Point-to-point – Одноранговый)
метод использует сервер WINS для разрешения имен и никогда не использует широковещание Значение 2
M-node (Mixed – Смешанный)
метод сначала пытается разрешить имя через широковещание (как в B-node), а затем посылает запрос к серверу WINS (как в P-node), если первая попытка провалилась. Этот метод зачастую применяется в сетях, где сервер WINS отделен от клиента сетями WAN.
Значение 4
H-node (Hybrid – Гибридный)
метод сначала пытается разрешить имя при помощи сервера WINS (как в P-node), а затем, в случае неудачи, применяет широковещание (как в B-node).
Значение 8

Выбор подходящего типа узла производится установкой в реестре соответствующего значения параметра NodeType (1,2,4,или 8; DWORD, Hex) в ключе
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBt\Parameters

В случае когда компьютер подключен в сеть где имеется DHCP сервер, то настройка параметра Тип узла производится по данным полученным от DHCP сервера. Значение такого параметра можно посмотреть в том же разделе реестра в ключе DhcpNodeType. Если в реестре записаны значения и DhcpNodeType и NodeType то приоритетным является параметр NodeType

Если Node Type установлен в P-node, а WINS-сервер в сети отсутствует/неисправен/недоступен, то имя разрешено не будет. Будет выдана следующая ошибка: "Недоступен список серверов для этой рабочей группы"

Медленная работа в терминале Server 2003 при подключении через клиента RDP Server 2008/Windows 7/Windows Vista 

Все, что нужно сделать на рабочей станции Windows Vista/Windows 7/MS Server 2008, запустить команду:   

netsh interface tcp set global autotuninglevel=disabled

 Если проблема не решилась — попробуйте выполнить команду:

netsh interface tcp set global autotuninglevel=highlyrestricted

 

Пароли Outlook Express

     
    Пароли всех удостоверений Outlook Express хранятся в реестре. Для этого предназначена ветвь реестра HKEY_CURRENT_USER\Software\Microsoft\Protected Storage System Provider\«идентификатор безопасности вашей учетной записи (SID)»\Data. По умолчанию доступ к ветви системного реестра HKEY_CURRENT_USER\Software\Microsoft\Protected Storage System Provider\«идентификатор безопасности вашей учетной записи (SID)» не определен ни для какой учетной записи. Поэтому если ваша учетная запись принадлежит к группе Администраторы, то необходимо будет еще изменить права доступа к этой ветви реестра, чтобы увидеть ее содержимое (учетные записи, принадлежащие к другим группам, не имеют права изменять права доступа к данной ветви реестра). После того как вы измените права доступа, перед вами появятся два дочерних раздела ветви — Data и Data2. Пароли Outlook Express в зашифрованном виде содержатся в разделе Data, поэтому узнать пароль конкретного пользователя не получится, но можно переименовать раздел Data, например, в раздел 2Data или просто удалить его. После этого все пароли на удостоверения данного пользователя будут удалены и можно будет войти в его удостоверения без пароля. Это может понадобиться в том случае, если пароль на удостоверение утерян или поврежден.

    Идентификатор безопасности SID является числом в специальном формате (например, для учетной записи Администратор этот идентификатор всегда равен S-1-5-21-1645522239-1957994488-839522115-500). Это число идентифицирует данного пользователя во всех операциях доступа к реестру, файловой системе Windows, сети и т.д. Идентификатор безопасности — это уникальное число (за исключением учетной записи Администратор, для которой идентификатор безопасности на всех компьютерах одинаковый), однозначно идентифицирующее учетную запись. Список всех идентификаторов безопасности для учетных записей (существуют также идентификаторы безопасности для групп пользователей) можно просмотреть в ветви реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList. Ветвь содержит разделы, названные в честь идентификаторов безопасности. При этом данные разделы хранят параметр строкового типа ProfileImagePath, который определяет путь к папке профиля, используемой данной учетной записью (конечная папка этого пути названа в честь логина учетной записи, поэтому можно определить, какой учетной записи соответствует каждый идентификатор безопасности).
     При входе пользователя в почтовый клиент Outlook Express (после ввода пользователем пароля) в ветви реестра HKEY_CURRENT_USER\Identities создается DWORD-параметр Identity Login. Он определяет так называемый идентификатор данного удостоверения (эти идентификаторы статичны, то есть всегда одинаковы для конкретной учетной записи пользователя, а не удостоверения). Идентификатор существует до выхода пользователя из почтового клиента — во время выхода он удаляется. Все дело в том, что если кто-то узнает значение данного идентификатора для удостоверения, например с помощью сетевого доступа просмотрит ветвь реестра HKEY_CURRENT_USER\Identities удаленного компьютера или просто посмотрит, чему равен идентификатор при своей работе в почтовом клиенте, то он сможет спокойно зайти в удостоверение, которое открывалось последним — почтовый клиент не потребует ввода пароля. Для этого достаточно будет перед открытием почтового клиента просто создать в ветви системного реестра HKEY_CURRENT_USER\Identities параметр Identity Login и присвоить ему значение идентификатора.

    Теперь рассмотрим небольшой пример. Допустим, существует общественный компьютер, на котором используется почтовый клиент Outlook Express. В этом почтовом клиенте существует три удостоверения, при этом одно из них ваше, например, оно будет иметь GUID-номер удостоверения {7FA55060-42B6-4CA4-8925-51F7AE55A20F}, а второе удостоверение, доступ к которому очень нужно получить, имеет GUID-номер {5E92CB22-3FED-493A-9D6F-F7432CF5CD7C}. Если вы думаете, что получить доступ к этому удостоверению невозможно, то вы ошибаетесь — на это понадобится пять минут. Попробуем это сделать. Для начала, конечно, нужно зайти в свое удостоверение и посмотреть значение DWORD-параметра Identity Login ветви реестра HKEY_CURRENT_USER\Identities. После того как вы запомнили значение этого параметра, закрывайте почтовый клиент (внимание, нужно просто закрыть почтовый клиент, а не завершить сеанс работы с удостоверением). Вот, в принципе, и все. Теперь осталось выполнить последний шаг — отредактировать три параметра ветви реестра HKEY_CURRENT_USER\Identities.

1. Identity Login — необходимо создать этот параметр DWORD-типа и присвоить ему значение, которое вы недавно запомнили.

2. Last User ID — нужно присвоить этому параметру строкового типа значение GUID-номера удостоверения, к которому нужно получить доступ. В вашем случае, нужно присвоить значение {5E92CB22-3FED-493A-9D6F-F7432CF5CD7C} (если вы этого не сделаете, то просто войдете без пароля в свое удостоверение).

3. Last Username —необходимо присвоить этому параметру строкового типа значение логина удостоверения, доступ к которому нужно получить (еще не забыли, что его можно посмотреть в значении параметра Username ветви системного реестра HKEY_CURRENT_USER\Identities\{GUID-номер удостоверения почтового клиента, к которому вы хотите получить доступ}?).

Вот теперь точно все — достаточно еще раз открыть почтовый клиент, и вы без знания пароля войдете в удостоверение пользователя, имеющее GUID-номер {5E92CB22-3FED-493A-9D6F-F7432CF5CD7C}.