Архивы Microsoft Windows - Страница 12 из 14

Установка Remote Server Administration Tools for Windows 7 with Service Pack 1

08.04.2011 Автор:Алексей Максимов
5 899 Просмотров Комментариев нет

Стал доступен для загрузки пакет «Remote Server Administration Tools for Windows 7 with Service Pack 1 (SP1)».

Данный пакет может быть установлен только на Windows 7 или Windows 7 SP1 в редакциях Enterprise, Professional и Ultimate.

Перед установкой новой версии рекомендуется произвести удаление всех предыдущих версий RSAT. Например, если ранее был установлен RSAT для Windows 7, то удалить его можно через Панель управления (Программы и Компоненты > Просмотр установленных обновлений), выполняем поиск обновления KB958830

После окончания процесса удаления старой версии RSAT сразу можно запускать установку новой версии (в моём случае для этого использовался файл Windows6.1-KB958830-x86-RefreshPkg.msu)

Дождавшись окончания процесса установки, как и в случае с предыдущей версией RSAT, нам необходимо включить нужные компоненты удалённого управления через Панель управления > Программы и компоненты > Включение или отключение компонентов Windows

После включения соответствующих компонент нам станут доступны «в полный рост» нововведения SP1, такие как, например Dynamic Memory и RemoteFX в оснастке Hyper-V Manager.
Стала доступной Microsoft iSCSI Software Target 3.3

05.04.2011 Автор:Алексей Максимов
3 100 Просмотров Комментариев нет

Вчера в блоге Windows Virtualization Team Blog было объявлено о публичной доступности Microsoft iSCSI Software Target 3.3. Насколько я понял, оно означает то, что все организации, имеющие лицензию на Windows Server 2008 R2 Standard/Enterprise/Datacenter смогут беспрепятственно скачивать, устанавливать и использовать в работе iSCSI Target от Microsoft. Другие редакции ОС (в том числе и в режиме Core) не поддерживаются.

Отдельно стоит отметить замечание о том, что бесплатная система Microsoft Hyper-V Server 2008 R2 может выступать лишь в качестве клиента - iSCSI Initiator (устанавливается из пакета iSCSITargetClient), то есть iSCSI Target не может непосредственно использоваться на этой ОС.

Политику поддержки данного продукта можно найти здесь: Windows Server TechCenter - Support Policies for Microsoft iSCSI Software Target 3.3 on Windows Server 2008 R2

Информацию о составе дистрибутива iSCSI Software Target 3.3 и небольшой FAQ можно найти здесь: Jose Barreto's Blog - Microsoft iSCSI Software Target 3.3 for Windows Server 2008 R2 available for public download

Ссылка на скачивание: Microsoft Download Center - Microsoft iSCSI Software Target 3.3
RSAT для Windows 7 и закладка Dial-In в ADUC

25.03.2011 Автор:Алексей Максимов
5 907 Просмотров 2 комментария

При попытке включить удалённый доступ пользователю через VPN наткнулся на занятную ситуацию…Так выглядят свойства пользовательской доменной учетной записи в оснастке «Active Directory Users and Computers» (DSA.MSC) запущенной в Windows 7 SP1 с включённой опцией отображения Дополнительных компонент (меню View > Advaced Features):

А если открыть эту же оснастку с Windows Server 2008 R2, то мы видим на одну вкладку больше

Читать далее...
Windows Server 2003 – Пустой список установленных программ в Add/Remove Programs и ошибки исполнения сценариев VBScript

21.03.2011 Автор:Алексей Максимов
3 699 Просмотров Комментариев нет

Столкнулся с ситуацией, когда на одном из серверов с Windows Server 2003 перестало отображаться содержимое списка установленных программ:

Дополнительно выяснилось, что помимо этого на данном сервере не работает запуск сценариев VBScript и попытка исполнения любого сценария приводит к общей ошибке:

Уловить момент, когда и по какой причине начались эти проблемы по логам, - не представилось возможным и поэтому осталось хотя бы попробовать победить «последствия».

В статье KB266668 - Add/Remove Programs tool displays installed programs incorrectly было найдено описание одной из имеющихся проблем и методов её решения. В итоге получился вот такой командный файл перерегистрации некоторых системных компонент, запуск которого с последующей перезагрузкой ОС вернул сервер к работоспособному состоянию:

regsvr32 "%systemroot%System32Appwiz.cpl"

regsvr32 "%systemroot%System32Mshtml.dll"

regsvr32 "%systemroot%System32Jscript.dll"

regsvr32 "%systemroot%System32VBscript.dll"

regsvr32 "%systemroot%System32Msi.dll"

regsvr32 "C:Program FilesCommon FilesSystemOle DBOledb32.dll"

regsvr32 "C:Program FilesCommon FilesSystemAdoMsado15.dll"

regsvr32 "%systemroot%System32Mshtmled.dll"
Windows Server 2008 как централизованный сервер факсов

18.03.2011 Автор:Алексей Максимов
26 412 Просмотров 57 комментариев

Не смотря на то, что на сегодняшний день такие вещи как Email и IM достаточно плотно вошли в систему информационного обмена между организациями, использование факсов по-прежнему имеет место быть. Мне самому несколько раз приходилось сталкиваться на практике с ситуацией, когда возникала необходимость отправлять факс через факс-аппарат. Последний опыт использования аппарата с некорректно работающим захватчиком бумаги был совсем «грустным». Чтобы сделать работу с факсами в организации более удобной и общедоступной (чтобы любой пользователь корпоративной сети не имеющий физического доступа к факс-аппаратам или факс-модемам мог самостоятельно, как отправить, так и принять факс) мы можем воспользоваться встроенным функционалом Windows Server и развернуть централизованный сервер факсов. В качестве опорной платформы для построения сервера факсов я в своём примере выбрал ОС Windows Server 2008 Standard 32-bit по причине того, что имеющаяся на руках мульти-модемная плата Digi AccelePort RAS 4 не имеет на сегодняшний день драйверов для 64-битных систем Windows, о чем отмечалось ранее.

Читать далее...
Windows XP SP3 - настраиваем путь к дистрибутиву через GPP

15.03.2011 Автор:Алексей Максимов
4 824 Просмотров 1 Комментарий

В некоторых случаях может возникнуть необходимость пакетного добавления каких-либо системных компонент Windows XP на большом количестве клиентских компьютеров. В ходе этого процесса Windows XP может потребовать доступ к дистрибутивному носителю ОС.

Воспользуемся механизмом Group Policy Preferences для централизованной раздачи таким клиентам сведений о месторасположении дистрибутивных файлов в сети. Информация о пути, использованном для установки ОС и её компонент, Windows XP может хранить в значениях ключей реестра SourcePath и ServicePackSourcePath в ветке HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionSetup.

Сделаем на файловом сервере каталог общего доступа и перепишем в него содержимое дистрибутивного носителя ОС (понадобится дистрибутив с последним интегрированным пакетом обновлений)

Откроем редактор доменной групповой политики, распространяемой на наши клиентские компьютеры, в разделе Computer Configuration > Preferences > Windows Settings > Registry и вызовем мастер создания новой записи реестра.

В мастере выберем подключение к любому клиентскому компьютеру с Windows XP для того чтобы взять с него информацию об интересующих нас ключах реестра

После нажатия кнопки Finish мастер в виде вложенных папок скопирует структуру контейнеров реестра и добавит два интересующих нас ключа. Откроем свойства этих элементов и установим тип действия (Action) – Update, а в поле значения (Value data) введём сетевой путь к общему каталогу с дистрибутивом ОС для параметра SourcePath:

Также указываем аналогичное значение для параметра ServicePackSourcePath (подразумевается, что мы имеем дистрибутив с интегрированным в него пакетом исправлений):

Небольшое замечание:
В ходе использования мастера добавления ключей реестра, я заметил один интересный глюк. Дело в том что, по завершению работы мастер сам заполняет значения полей Hive и Key Path, однако если после создания мастером такого элемента не зайти в его свойства и в ручную не выбрать раздел реестра (Hive), оно останется фактически пустым…

Это выяснилось после того как на клиентах упорно не хотел обновляться указанный ключ реестра, зато вместо этого создавался подобный ключ в пользовательском разделе реестра, который, как мы понимаем, никакой силы не имеет. После того как я открыл свойства элемента реестра, созданного мастером в GPP и вручную выбрал раздел HKEY_LOCAL_MACHINE… политика заработала так, как мы этого от неё ждали.

Если данная групповая политика применяется к общей массе клиентских компьютеров, в составе которых есть не только Windows XP, мы можем ограничить применение данной настройки реестра по версии ОС. Для этого откроем свойства корневой папки иерархии папок, сделанной мастером добавления, и на закладке Common включим режим нацеливания Item-level targeting

По кнопке Targeting добавим новое условие, означающее то, что данная настройка реестра будет применяться только компьютерам с ОС Windows XP

Если же по каким-то причинам в вашей организации не используются механизмы Group Policy Preferences, то можно настроить данный параметр и другими способам, например импортом нужной информации в реестр через логон-скрипт из *.reg файла с содержимым примерно следующего содержания:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionSetup]

"SourcePath"="\\server\Sources\winxp_pro_sp3_x86_ru"

"ServicePackSourcePath"="\\server\Sources\winxp_pro_sp3_x86_ru"
Работа с томами NTFS с помощью Gnome Partition Editor (GParted)

10.03.2011 Автор:Алексей Максимов
10 979 Просмотров 6 комментариев

В процессе подготовки к развёртыванию SP1 на Windows Server 2008 R2 на одном из серверов обнаружилась нехватка свободного места на системном диске. При этом единственный имеющийся диск на этом сервере был разбит таким образом, что после системного тома был сделан том, используемый для работы приложений.

Используя встроенные средства консоли управления дисками в данной конфигурации, расширить том с ОС не представлялось возможным, так как опция расширения в данном случае попросту недоступна

В данной ситуации, фактически нам требовалось сместить раздел с данными в конец диска для того, чтобы сделать возможным расширение системного тома с использованием высвободившегося смежного пространства. Для решения такого рода задач конечно существуют коммерческие продукты такие как Acronis Disk Director, но за частую нам нужно решать подобные задачи «здесь и сейчас» не имея при этом лицензий на подобные вещи. В качестве альтернативного метода был выбран продукт Gnome Partition Editor (GParted) свободно распространяемый по лицензии GNU General Public License.

Получить подробную информацию о функциональных возможностях GParted и загрузить текущую стабильную версию можно с домашней страницы проекта. Здесь можно скачать загрузочный образ диска (в нашем случае это файл gparted-live-0.8.0-1.iso размером около 116 Mb), который при необходимости можно записать на CD с помощью ещё одной довольно качественной свободно распространяемой программы ImgBurn.

Выполняем загрузку системы с полученного загрузочного диска и при загрузке выбираем параметр по умолчанию GParted Live

В появившемся меню управления раскладками клавиатуры оставляем значение по умолчанию «Don`t touch keymap»

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

Далее выбирая значение 0 (по умолчанию), соглашаемся с тем что загружаемая система автоматически попытается настроить параметры графической среды:

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

Первым делом, нам нужно выполнить смещение раздела с данными в конец физического диска. Для этого, откроем контекстное меню на разделе с данными и выберем пункт Resize/Move

В открывшейся диалоговой форме мышью перетащим раздел в конец диска.

При этом значения свободного места до и после тома должны измениться соответственным образом. Нажимаем ставшую доступной кнопку Resize/Move…

При этом мы получим информационное предупреждение о том, что проведение некоторого рода манипуляций над загрузочными томами может привести к невозможности последующей загрузки ОС и о том, что описание того как в таких случаях поступать для восстановления загрузчика можно найти в разделе FAQ сайта GParted

Следующим этапом будет расширение системного тома на высвободившееся после предыдущей операции место. Несмотря на то, что эту операцию можно будет выполнить уже и непосредственно штатным методом из Windows, мы попробуем сделать её сразу здесь же.

В открывшейся диалоговой форма изменения системного тома с помощью мыши растянем том на всё имеющееся в наличии доступное место…

Таким образом, мы лишь создали последовательность задач, которые мы хотим поручить GParted. Задачи будут последовательно выполняться в том порядке в котором мы их настраивали и как они отображаются в нижней части главного диалогового окна GParted. Для запуска выполнения последовательности задач нажимаем кнопку Apply.

Нас в последний раз спрашивают о том, не сошли ли мы с ума, и сделали мы резервную копию данных, которые мы можем потерять…

После нашего утвердительного ответа открывается диалоговое окно, подробно отображающее ход выполнения всех операций…

После того как все операции успешно выполнены, извлекаем загрузочный диск GParted и загружаемся в ОС на системном томе. В процессе загрузке ОС Windows определит изменение конфигурации логических разделов и автоматически запустит процедуру проверки каждого изменённого тома…

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

Обратите внимание на то, что данный пример успешной работы GParted описан на продуктивной виртуальной машине развёрнутой на гипервизоре Hyper-V c диском VHD фиксированного размера.
Windows Server 2008 - MMC could not create the snap-in

05.03.2011 Автор:Алексей Максимов
4 386 Просмотров Комментариев нет
Развернул свежую Windows Server 2008, установил, как полагается, на неё все текущие обновления с WSUS и после перезагрузки обнаружил проблему с работой mmc.exe. При попытке использования сборных оснасток, таких как Server Manager или некоторых отдельных типа Event Viewer система стала возвращать ошибку «MMC could not create the snap-in»

В логе ServerManager.log расположенном в C:WindowsLogs не удалось обнаружить никаких событий, происходящих после установки всей пачки последних обновлений. Чтобы проверить то, что проблема заключается не в повреждении файлов какого-либо из обновлений, пришлось прибегнуть к помощи средства System Update Readiness Tool. Описание и ссылки на свежие версии этой утилиты можно найти в статье KB947821 - Description of the System Update Readiness Tool for Windows Vista, for Windows Server 2008, for Windows 7, and for Windows Server 2008 R2

В процессе установки System Update Readiness Tool выполняет проверку всех установленных обновлений и создаёт лог-файлы из которых можно узнать результат проверки:
- %SYSTEMROOT%LogsCBSCheckSUR.log
- %SYSTEMROOT%LogsCBSCheckSUR.persist.log
В моём случае проверка не выявила никаких проблем с файлами обновлений:

В большом количестве источников в интернете можно найти информацию о подобной проблеме, её корнях и способах решения. Есть даже такие кардинальные, как например, описано в одном блоге: Jared Heinrichs Blog - MMC error 18ea3f92-d6aa–41d9-a205-2023400c8fbb

Jared Heinrichs предлагает произвести замену конфигурационного файла Framework в каталоге C:WindowsMicrosoft.NETFrameworkv2.0.50727CONFIG (для 64-битных систем соответственно - C:WindowsMicrosoft.NETFramework64v2.0.50727CONFIG). А именно имеющийся файл machine.config (который в большинстве случаев и является источником проблемы) переименовать machine.config.bad а файл machine.config.default скопировать в эту же папку с новым именем machine.config, то есть восстановить старый конфигурационный файл по умолчанию.

Из других источников выяснилось, что при установке .NET Framework 3.5 в файл machine.config в указанном каталоге могут быть внесены некорректные данные и поэтому я решил попробовать удалить эту версию .NET Framework 3.5 штатным способом. Итак, используя оснастку установки/удаления программ, был удалён пакет Microsoft .NET Framework 3.5 Service Pack 1 (KB951847) и сразу после этого все оснастки mmc заработали.

После запроса к WSUS, система опять предложила установить данное обновление. Устанавливаем его..

Сразу после этого делаем повторный запрос к WSUS и устанавливаем несколько доступных обновлений к переустановленной версии .NET Framework 3.5 SP1:

После этого все оснастки работают, так что можно считать этот метод ещё одним работающим вариантом штатного решения проблемы.
Digi AccelePort RAS 4 не работает на Windows x64

04.03.2011 Автор:Алексей Максимов
3 727 Просмотров 3 комментария

Имеется на руках интересная железка - Мультимодемная плата Digi AccelePort RAS 4 Europe (4 x Modem RJ-11 ports) PCI (P/N #77000617).

В былые времена она использовалась для организации сервера служб RAS, теперь появилось желание заюзать её для организации сервера факсов. Разумеется, первым делом я пошёл на сайт разработчика,… и с огорчением для себя обнаружил что поддержка этой платы уже прекращена и к тому же из списка доступных драйверов для платформы Windows самыми “свежими” является драйвер версии 5.0.314.0 (30.06.2003) для Windows Server 2003… Ни на на что особо не рассчитывая, я всё таки решил попробовать “подружить” эту железку с Windows Server 2008 R2… День мытарств, как я и предполагал, ни к чему не привёл. ОС наотрез отказалась глотать недружественный драйвер, который мало того что не имел цифровой подписи, был рассчитан на более старую систему и к тому же вообще был 32-битным. В статье Windows Hardware Developer Center - INF Requirements for 64-bit Systems нашёл описание того как же всё-таки можно попытаться насильственным способом навязать системе имеющийся в нашем распоряжении драйвер. Для этого достаточно добавить ключ реестра REG_DWORD с именем DisableDecoratedModelsRequirement в ветке HKLMSoftwareMicrosoftWindowsCurrentVersionSetup и присвоить ему значение отличное от нуля, например 1. Для вступления в силу изменений потребуется перезагрузка. После этого драйвер был таки съеден системой, однако работать так и не захотел. После изучения лог-файла установки в C:Windowsinfsetupapi.dev.log стало понятно что ОС органически не переваривает драйвер dgardxb.sys…
Официальный форум тех.поддержки Digi оказался довольно скудным и поэтому последней надеждой стало обращение в техподдержку Digi. Разместив обращение на сайте тех.поддержки Digi я получил ответ, от которого мне совсем стало грустно..

На сегодняшний день, когда использование 64-битных серверных систем уже вошло в стандарт де факто, очень удивительно наблюдать подобного рода явления, когда такой серьёзный вендор (как я полагал) как Digi не имеет и даже не планирует поддержку своих устройств в 64-битных системах.
Outlook 2007 – процедура автонастройки профилей возвращает userPrincipalName вместо mail

18.02.2011 Автор:Алексей Максимов
2 529 Просмотров Комментариев нет

Не так давно было замечено, что клиенты MS Outlook 2007 в процессе создания нового профиля подключения к серверу Exchange на этапе автодискаверинга вместо адреса электронной почты (атрибут mail) пользователя возвращают значение атрибута userPrincipalName (UPN) этого пользователя:

с такими параметрами процедура авто-настройки профиля завершается с ошибкой. После разбора полётов выяснилось, что виновником такого поведения Outlook 2007 стало недавно выпущенное и развернутое через WSUS обновление KB2412171

О других “косяках” этого обновления можно почитать в “чистосердечном признании” в официальном блоге - The Microsoft Office Blog - Issues with the recent update for Outlook 2007

Если произвести удаление этого обновления с клиентского ПК, то процедура авто-настройки начинает работать штатно:

Соответственно, для решения данной проблемы можно пойти двумя путями:

1) Произвести удаление данного обновления с пользовательских ПК;

2) Дожидаться выхода нового обновления Office, устраняющего эту проблему, а пока оно не вышло, в случае необходимости подключения нового профиля Outlook в поле “Адрес электронной почты” заменять автоматически подставленное значение UPN на mail и оставлять появившиеся поля для ввода учетных данных пустыми (в таком случае процедура авто-настройки будет завершаться без ошибки).