Получение ключа установки Windows с помощью PowerShell

Обновлено 22.05.2012 – спасибо pan_2@LJ за наводку на более совершенную версию скрипта

Эта функция может пригодиться для инвентаризации или других подобных случаев.

Три варианта активации корпоративных лицензий

Если вы решите приобретать корпоративную лицензию, придется определиться, какой из трех вариантов активации вам больше всего подходит. Именно этот момент в корпоративном лицензировании многим непонятен. Три варианта лицензирования предназначены для различных вариантов сетевой среды. Но бывает и так, что наиболее удобный вариант — использовать в организации все три варианта. Обычно вариант выбирается на основе двух обстоятельств: наличия подключения к сети и числу запрашивающих узлов.

В первом варианте запрашивающие узлы перенаправляются на Windows-сервер со службой управления ключами (KMS). Серверы KMS предназначены для сред, в которых больше 25 Windows-клиентов или пяти Windows-серверов, которые постоянно подключены к серверу KMS.

Это неизменяемое число узлов называется порогом активации. Сервер KMS не начнет активировать узлы, пока этот порог не достигнут. Поэтому если в вашей среде нет минимального количества узлов, вы не сможете использовать KMS. То же самое верно, если у запрашивающих узлов нет сетевого подключения к серверу KMS.

Вызов апплетов панели управления из командной строки

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

Апплеты в панели управления представляют собой обычные DLL-ки, имеющие расширение .cpl (Control Panel Library) и содержащие в себе функцию CPlApplet.

Обычно располагаются в системной директории Windows. В свою очередь, в каждом файле cpl может храниться несколько апплетов.

Сервер для филиала, RODC, NAS и другое

Недавно возникла необходимость одно из наших подразделений вывести в отдельный офис. Речь шла где-то о 25-30 людях с компьютерами + необходимая техника. Особенность в том, что это редакции журналов, соответственно они работают с большими объемами данных, т.о. работа с нашей сетью хранения данных через WAN подключение, мягко говоря, не подходит.

Итак, нужно было решить ряд задач, а именно, удобную аутентификацию в нашем домене, групповые политики, DNS, DHCP, сервисы печати и хранения данных.

В конечном итоге решено было выделить старенький стоечный сервер, который с успехом потянет Windows 2008 R2 на котором и будут установлены все службы. Проблема оставалась только в том, что в нем стояли диски не очень большого размера (ранее на нем был развернут временный терминальный сервер), да и не было в то время дисков, объем которых измерялся в терабайтах :-)

Самым удобным решением в этом случае оказалось применение готового NAS. Вначале выбор был остановлен на Synology DS712+, но на складе их не оказалось, а поставки ожидались, как обычно, через несколько месяцев. Зато доступен был QNAP 239 Pro II+. Это двухдисковая модель NAS, с поддержкой iSCSI. Для нее были куплены два диска Western Digital 2Tb Raid Edition4 7200RPM 64MB (WD2003FYYS SATAII). К счастью, мы успели их купить еще до того, как цены окончательно взмыли ввысь, хотя и дешевыми их назвать сложно.

Особенности использования RemoteAPP и сертификатов

Немного предыстории. В этом году делали решение по удаленному доступу к приложениям. Основа сделана на базе двух лезвий IBM HS22 для Blade Center H, куда были установлены Microsoft Hyper-V Server с высокой доступностью. Само же решение, базируется на Microsoft Remote Desktop Services (Windows Server 2008 R2). Для развертывания последнего использовались несколько серверов, на одном был установлен Remote Desktop Connection Brocker, Remote Desktop Licensing и Web Access, еще на одном был установлен Remote Desktop Gateway, еще один был задействован как член фермы Remote Desktop Session Host. Подразумевается, что в будущем в ферме будет несколько серверов. Плюс ко всему, все это публикуется наружу с помощью существующего сервера с установленной ISA 2006

Т.к. подразумевалось, что к некоторым приложениям доступ будет и “снаружи” , причем не только с доменных компьютеров, то захотелось все это сделать с “правильными” сертификатами. Тем более, что сертификат у нас уже был куплен.

Настройка политик терминальных пользователей или особенность замыкания групповых политик

Обычно, при использовании терминальный решений от Microsoft или на их основе возникает необходимость в использовании из-под терминала групповых политик, отличных от тех, что применяются к пользователям во всех остальных местах. Например, выключить хранитель экрана с парольным выходом, в случае работы из-под терминала. Это раздражает пользователей, т.к. в случае их отсутствия они получают два хранителя экрана вместо одного. Как же это реализовать?

Специально для этого предусмотрен решим замыкания (loopback). В случае его включения, политика применяется на основе членства компьютера, а не пользователя. Для этого нужно включить это свойство в

Как увеличить системный раздел на Windows Server?

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

Ну, для начала, можно всячески его чистить. Первые кандидаты – это кэш Windows Update

%windir%\SoftwareDistribution\Download

Затем папки для uninstall обновлений. В случае Windows 7 можно воспользоваться средством очистки после SP1?
Иногда этого недостаточно. Что же делать в таком случае?

Вот тут-то нам на помощь и приходит утилита diskpart. Правда есть несколько ограничений.

Доверительные отношения между доменами и firewall

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

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

Windows NT

Порты клиентов	Порт сервера	Служба
1024-65535/TCP	135/TCP	RPC *
137/UDP	137/UDP	Служба имен NetBIOS
138/UDP	138/UDP	Вход в сеть и обзор сети NetBIOS
1024-65535/TCP	139/TCP	Сеанс NetBIOS
1024-65535/TCP	42/TCP	Репликация WINS

Microsoft выложила iSCSI Software Target 3.3 в публичный доступ

Приятная новость, Microsoft выложила iSCSI Software Target 3.3 for Windows Server 2008 R2 в публичный доступ.

В общем-то, и раньше были способы его получить, но они были полулегальными. Ну а теперь можно свободно качать и экспериментировать с кластерами и т.д. Единственное но – он работает только под Windows Server 2008 R2 … А мне бы было идеально его иметь под Windows Server 2003 R2

Средство поиска проблем в Windows 7 и в Windows Server 2008 R2

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

Итак, о чем же идет речь? В английских версиях она называется “Reliability Monitor”, в русских – “Монитор стабильности системы”. Чтобы его найти нужно или искать с помощью поиска, либо идти в “Action Center” (Центр поддержки) и там искать его в “Maintenance” (Обслуживание).

Что делает и в чем смысл этого, по сути, отчета?