• Установка CCR кластера Microsoft Exchange Server 2007 SP1 на базе Windows Server 2008 SP2

    Для установки кластера CCR необходимо чтобы на обоих узлах отказоустойчивого кластера была установлена ОС Windows Server 2008 Enterprise SP2 x64 и присутствовали все системные обновления, вышедшие после выхода SP2 для Windows Server 2008 (предпочтительно обновление через службу WSUS).
    Оба сервера, которые будут выступать у нас в качестве нод кластера, должны быть оснащены двумя сетевыми интерфейсами (один для подключений к локальной сети, второй для обеспечения работы кластера). Присвоим на обоих серверах сетевым интерфейсам соответствующие наименования.

    image

    После присвоения имен необходимо изменить порядок использования сетевых интерфейсов. Для этого выбираем Advanced >Advanced Settings

    image

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

    image

    Далее производим настройку сетевых интерфейсов (идентично на обоих серверах):

    · Отключаем использование IPv6 на обоих сетевых интерфейсах (в силу того что нами этот протокол на текущий момент не этот протокол используется);
    · Отключаем на кластерном сетевом интерфейсе (NIC2 - Cluster) использование
    Client for Microsoft Networks
    File and Printer Sharing for Microsoft Networks
    Link-Layer Topology Discovery Mapper I/O Driver
    Link-Layer Topology Discovery Responder

    В конечном итоге мы должны получить такую вот картину:

     image image

    Далее мы конфигурируем настройки IPv4 в свойствах сетевых интерфейсов.
    Для интерфейса публичной сети (NIC1 – Public) задаем следующие параметры:
    - статический IP адрес нашей сети (например, 10.161.0.20 на первом сервере и 10.161.0.21 на втором сервере);
    - маску сети (например, 255.255.255.0 на обоих серверах);
    - IP адрес шлюза по умолчанию (например, 10.161.0.1 на обоих серверах);
    - IP адреса DNS серверов (например, 10.161.0.10 и 10.161.0.9 на обоих серверах);
    - Проверяем наличие признака динамической регистрации имени в DNS (Закладка DNS, параметр «Register this connection`s addresses in DNS» – включен)

    Для кластерного сетевого интерфейса (NIC2 - Cluster) задаем следующие параметры:
    - статический IP адрес внутренней кластерной сети (например, 192.168.254.254 на первом сервере и 192.168.254.253 на втором сервере);
    (важно чтобы IP адреса кластерной сети не пересекались с адресами нашей публичной серверной сети)
    - маску сети (например 255.255.255.0 на обоих серверах);
    - IP адрес шлюза по умолчанию не указываем на обоих серверах;
    - IP адреса DNS серверов не указываем на обоих серверах;
    - Проверяем то, что признак динамической регистрации имени в DNS выключен (Закладка DNS, параметр «Register this connection`s addresses in DNS» – выключен)

    Установка необходимых компонент Windows Server 2008
    Кластерный почтовый сервер на базе Windows Server 2008 требует следующих ролей и функций на каждом кластерном узле:

    • Web Server (IIS)
    • PowerShell
    • Fail-Over Clustering

    Для ускорения процесса установки необходимых компонент, воспользуемся утилитой ServerManagerCMD.exe, входящей в состав операционной системы. Открыв командную строку с правами администратора выполним следующую последовательность команд:

    ServerManagerCmd -i PowerShell
    ServerManagerCmd -i Failover-Clustering
    ServerManagerCmd -i Web-Server
    ServerManagerCmd -i Web-ISAPI-Ext
    ServerManagerCmd -i Web-Metabase
    ServerManagerCmd -i Web-Lgcy-Mgmt-Console
    ServerManagerCmd -i Web-Basic-Auth
    ServerManagerCmd -i Web-Windows-Auth

    После установки необходимых компонент, выполним перезагрузку сервера.

    Создание кластера Windows Server 2008

    Для создания кластера мы воспользуемся оснасткой Failover Cluster Management (Панель управления > Administrative Tools).
    В консоли Failover Cluster Management вызываем мастер создания нового кластера (Меню Action > Create a Cluster…)

    image

    В открывшемся окне мастера создания нового отказоустойчивого кластера ознакамливаемся с представленной нам справочной информацией и переходим далее

    image

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

    image

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

    image

    По нажатию кнопки Next поверх мастера установки кластера откроется мастер проверки конфигурации…

    image

    Ознакомимся с представленной нам информацией и на следующем шаге на экране Testing Options выберем рекомендуемую опцию проведения всех тестов.

    image

    Подтверждаем параметры тестирования

    image

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

    image

    В нашем случае мы видим, что тест пройден успешно, но есть кое-какие предупреждения, информацию о которых можно получить из более детального HTML отчета по кнопке View Report

    image

    Как видно отчета мастеру проверки не понравилась наша дисковая подсистема. Например, он не увидел дисков, которые можно использовать для конфигураций кластеров с общим дисковым массивом. Но так как мы собираемся строить кластер Exchange Server 2007 CCR, мы можем проигнорировать данные предупреждения и завершить работу мастера проверки. После этого мы снова вернёмся в мастер создания кластера и сразу попадём на экран, в котором нужно ввести имя кластера Windows Server 2008 и его IP адрес. Нужно учесть, что здесь задается не то имя, которое будет использоваться для подключения клиентов Exchange, а то которое необходимо для самого кластерного экземпляра Windows Server 2008, на который мы в последствии будем устанавливать сам кластерный экземпляр Exchange Server 2007.

    image

    Далее мастер делает проверку доступности имени в AD и если всё в порядке, предлагает нам начать процесс создания нового кластера

    image

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

    image

    Все, кластер установлен и теперь можно приступить к этапу конфигурирования кластерных ресурсов.

    Настройка кластерных сетей

    После того как экземпляр кластера создан, нам нужно настроить кластерные сети, чтобы один сетевой интерфейс использовался для клиентских подключений, а второй был ограничен исключительно для использования межузлового кластерного обмена. Откроем страницу свойств кластерного интерфейса публичной сети (Cluster Network 1).

    image

    Изменим имя кластерной сети с «Cluster Network 1» на «Public network».
    Выберем опции «Allow the cluster to use this network» и «Allow clients to connect through this network».
    То есть на данный кластерный интерфейс у нас будут разрешены запросы клиентов из сети.

    image

    Затем изменим имя кластерной сети с «Cluster Network 2» на «Private network» и проверим, чтобы была выбрана опция «Allow the cluster to use this network» , а опция «Allow clients to connect through this network» была выключена. Таким образом, мы заставим кластер использовать данную кластерную сеть только в целях межузлового обмена.

    image

    Настройка кворума File Share Majority

    Теперь необходимо настроить кворумный ресурс кластера, то есть создать файловый ресурс на отдельном сервере (в нашем случае файловый ресурс располагается на сервере Hub-Transport в том же сайте AD, в котором расположены узлы кластера). Для этого залогинимся на выбранный сервер с ролью Hub-Transport (в нашем случае это сервер с именем HT01), и в корне диска C создадим новый каталог командой:

    MKDIR FSM_DIR_<имяCCRкластера>

    Где <имяCCRкластера> – это имя, которое вы собираетесь использовать для кластерного почтового сервера.
    Например, в нашем случае имя создаваемого каталога будет FSM_DIR_MAIL

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

    NET SHARE FSM_<имяCCRкластера>=C:FSM_DIR_<имяCCRкластера> /GRANT:everyone,FULL

    Например, в нашем случае команда будет выглядеть так
    NET SHARE FSM_MAIL=C:FSM_DIR_MAIL /GRANT:everyone,FULL

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

    CACLS C:FSM_DIR_<имяCCRкластера> /G BUILTINAdministrators:F <имяWindowsкластера>$:F

    Например, в нашем случае команда будет выглядеть так
    CACLS C:FSM_DIR_MAIL /G BUILTINAdministrators:F MAILCL$:F

    Таким образом, мы создали сетевой каталог для кворумного ресурса кластера и дали на него полные права встроенной группе администраторов сервера с ролью Hub-Transport HT01 и учетной записи кластера MAILCL, созданной в домене после его создания.

    Далее необходимо настроить кластера так, чтобы он ссылался на ресурс, который мы только что создали и использовал его в качестве своего кворумного ресурса. Для этого открываем оснастку Failover Cluster Management на одном из узлов кластера, устанавливаем курсор на имя нашего кластера, выбираем «More action» в меню Actions, а затем выбираем опцию «Configure Cluster Quorum Settings…»

    image

    Откроется мастер настройки кворума. Ознакомимся с представленными сведениями и жмем «Next».

    image

    На странице выбора конфигурации кворума выбираем опцию «Node and File Share Majority»

    image

    В качестве кворумного ресурса-«свидетеля» указываем созданную нами ранее сетевую папку на сервере HT01

    image

    Мастер конфигурации кворума проверяет доступность сетевого ресурса, просит подтвердить наши намерения и завершает конфигурацию.

    image


    Проверка конфигурации кластера

    Теперь при открытии оснастки Failover Cluster Management мы видим что наш кластер обладает ресурсами Имя кластера, IP и сетевой ресурс – «свидетель» кворума.

    image

    Настало время проверить конфигурацию нашего кластера. Для этого в консоли Failover Cluster Management установим курсор в корень дерева консоли и выберем в меню Action пункт «Validate a Configuration…»

    image

    Откроется уже знакомый нам мастер проверки конфигурации кластера. Укажем ему в качестве объекта проверки оба сервера входящих в наш кластер и запустим процедуру проверки. После чего внимательно изучим получившийся отчет на предмет возможных проблем. Если никаких серьезных проблем не обнаружено, можно считать работу с консолью Failover Cluster Management законченной.

    Установка роли активного кластерного почтового сервера на первом узле кластера.

    Запустите программу установки Exchange Server 2007 SP1. Примите условия лицензионного соглашения и укажите, хотите ли вы активировать отчеты об ошибках или нет.
    На странице «Installation Type» выберите опцию Custom Exchange Server Installation.

    image

    Далее сделайте выбор роли Active Clustered Mailbox Role.

    image

    На странице параметров установки кластера выберите опцию «Cluster continuous replication», затем введите имя, которые вы хотите назначить вашему CMS (это имя будут использовать ваши клиенты Outlook для подключения к CMS). Путь для хранения БД почтовых ящиков будет индивидуальным для каждого сервера и может быть изменен после установки.

    image

    Далее укажите IP адрес, который будет использоваться кластерным экземпляром Exchange Server 2007.

    image

    Далее программа установки выполнит ряд проверок готовности к установке, и если проблем не возникнет, нажимаем Install, чтобы начать процесс установки активного узла CCR кластера Exchange Server 2007.

    image

    Процесс установки займет несколько минут. По завершении нажмите Finish и перезагрузите сервер, чтобы все изменения вошли в силу.

    image

    Установка роли пассивного кластерного сервера почтовых ящиков на втором узле кластера

    Запустите программу установки Exchange Server 2007 SP1. Примите условия лицензионного соглашения и укажите, хотите ли вы активировать отчеты об ошибках или нет.
    На странице «Installation Type» выберите опцию Custom Exchange Server Installation.
    На странице «Server Role Selection» сделайте выбор роли Passive Clustered Mailbox Role.

    image

    Снова будет запущен процесс проверки готовности. По завершении этого процесса нажмите Install.
    В моём случае процедура установки завершилась вот с такой вот ошибкой:

    image

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

    image

    Далее, как и ранее на странице «Server Role Selection» я сделал выбор роли Passive Clustered Mailbox Role и запустил процесс.

    image

    На этот раз всё завершилось успешно и после финальной перезагрузки сервера мы получили работающий пассивный узел в кластере CCR Exchange Server 2007 SP1.

  • Интересный параметр GPO: Удалить команду "Выполнить" из меню "Пуск"

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

    Путь в GPO:
    Конфигурация пользователя/Административные шаблоны/Меню "Пуск" и панель задач

    Параметр:
    Удалить команду "Выполнить" из меню "Пуск"

    image 

    Cуть в том, что при включении данного параметра, как выяснилось, в системе перестает корректно работать переход по UNC пути не только в Explorer и IE но и во всех других приложениях, например в той же 1С…т.е. переход с диска на диск в GUI путём клацанья мышкой как бы работает, но например из командного интерпретатора Cmd.exe при попытке подключения сетевого диска утилитой net – возникают ошибки по типу ограничения доступа…что само по себе не очень логично, и мне пришлось убить почти час времени чтобы среди кучи выставленных параметров GPO на терминальном сервере найти виновника странного поведения системы…
    В описании к данному параметру GPO конечно есть какая-то далеко неоднозначная фраза что-то типа «перестает работать интерфейс»…но что она значит на деле приходиться узнавать путем хождения по граблям …

  • WSUS Troubleshooting: WebException: Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS. ---> System.Security.Authentication.AuthenticationException

    При поднятии роли WSUS на только что установленном сервере Windows Server 2008 столкнулся с проблемой при попытке синхронизации с Microsoft:

    WebException: Базовое соединение закрыто: Не удалось установить доверительные отношения для защищенного канала SSL/TLS. ---> System.Security.Authentication.AuthenticationException: Удаленный сертификат недействителен согласно результатам проверки подлинности.

    Изучил лог клиента который напрямую обращается на MS WSUS (c:WindowsWindowsUpdate.log) и обнаружил что клиент обращается на узел https://update.microsoft.com.

    Решив воспроизвести ситуацию вручную, открыл этот узел в IE - и посмотрел свойства сертификата.
    Цепочка сетификатов ведёт к корневому сертификату ЦС - GTE CyberTrust Global Root
    Открыл на своем WSUS сервере остнастку certmgr.msc и выполнив поиск обнаружил что у меня нет такого корневого сертификата...

    Пришлось скачать отсюда http://support.microsoft.com/default.aspx/kb/931125 файл rootsupd.exe...далее, по причине того, что этот пакет предназанчен только для WinXP (по крайней мере в Win2008 он просто не запускался) - пришлось распаковать и оттуда открыть файл сauthroots.sst
    В нём то и оказался нужный мне сертификат КЦС - GTE CyberTrust Global Root..Импортировал этот сертификат через Мастер импорта сертификатов в хранилище Доверенные корневые центры сертификации (в хранилище Локальный компьютер)
    ...
    Открываю остнастку WSUS, запускаю синхронизацию с MS WSUS... синхронизация заработала

  • Установка сертификата от Windows Server CA на веб-сервер Apache

    imageРассмотрим пример установки цифрового сертификата X509 на веб-сервер Apache, выданного локальным корневым Центром сертификации, работающим на Windows Server 2008. Пошагово решение задачи состоит из нескольких последовательных шагов:

    • Генерация запроса на сертификат средствами OpenSSL к ЦС Windows;
    • Получение от ЦС файла сертификата (.cer) в формате DER X509
    • Конвертация полученного сертификата в .pem и прикручивание оного к веб-серверу Apache

    Читать далее...

  • Event ID 1511 и 1515 при загрузке пользовательского профиля на Windows Vista и Windows Server 2008

    Если на компьютере под управлением Windows Vista и Windows Server 2008 при входе в систему в момент загрузки пользовательского профиля пользователь получает сообщение о том что его профиль загрузить не удалось и будет использоваться временный профиль, это значит что его основной профиль по какой-то причине повреждён и его восстановленная копия безуспешно пытается загрузиться из реестра при логоне пользователя на компьютер. При этом в системном логе фиксируются события с кодом Event ID 1511 и 1515 Лечится это так:

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

    - открываем snap-in "Свойства системы"
    - переходим на закладку "Дополнительно"
    - открываем "Профили пользователей"
    - удаляем неисправный профиль пользователя.

    2. Теперь надо вычистить информацию об этом профиле из реестра:

    - для этого определяем SID пользователя. сделать это можно например с помощью утилиты psgetsid.exe

    D:winToolsSysinternalsPsTools>psgetsid.exe MyDompetrov-va
    
    PsGetSid v1.43 - Translates SIDs to names and vice versa
    Copyright (C) 1999-2006 Mark Russinovich
    Sysinternals - www.sysinternals.com
    
    SID for MyDompetrov-va:
    S-1-5-21-2882866809-389392232-255224647-3057
    
    

    - далее открываем редактор реестра и переходим в куст: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList
    - находим в этой ветке SID полученный ранее (возможно имя будет иметь формат SID.bak) и удаляем это ветку реестра.
    - снова логинимся этим пользователем и проверяем то что в каталоге пользователей профиль создался корректно и сообщений об ошибках не фиксируется.

    Дополнительная информация:
    1. Error message when you log on to a Windows Vista-based computer by using a temporary profile: "The User Profile Service failed the logon. User profile cannot be loaded"
    2. Vista - Event ID 1511, 1515 Profile loss to TEMP

  • Forefront Client Security Troubleshooting: The following non-MOM API has failed: objMomServerUtils.GetScriptResponseParameterValue(). Error code: -2147024891

    После развертывания сервера Forefront Client Security на Windows Server 2008 в топологии с одним сервером на консоли FCS можно обнаружить периодически (примерно раз в час) появляющиеся предупреждения о проблемах на FCS сервере. В отчетах это может выглядеть примерно так:

    image

    Также на сервере в логе Application параллельно фиксируются предупреждения подобного содержания.

    image

    Проблема решается включением доменной учетной записи пользователя DAS (в нашем случае это MyDoms-user) в локальную группу безопасности FCS сервера с именем MOM Administrators

  • Проблема с подключением сетевого ресурса размещенного на Windows Server при обращении по DNS-алиасу (CNAME)

    Есть сервер под управлением Windows Server 2003/2008. На этом сервере размещён общий сетевой ресурс. Ну скажем например выставлен в общий доступ каталог ShareDocuments$. Реальное имя сервера - Server001.domain.com. Соответственно при необходимости подключения с этого сервера на клиентских компьютерах нашего каталога ShareDocuments$ используем команду

    D:> net use Z: \Server001.domain.com\Share\Documents$
    Команда выполнена успешно.

    Тут всё понятно. Но в жизни может возникнуть такая ситуация, когда нужно подключить данный ресурс используя DNS-алиас (CNAME) этого сервера (например AnyServerWhithMyShare.domain.com). В таком случае попытка подключения сетевого каталога может завершиться неудачей, причем выдаваемый текст ошибки достаточно загадочен.

    D:>net use Z: \AnyServerWhithMyShare.domain.com\Share\Documents$
    Системная ошибка 52.
    Вы не подключены, поскольку такое же имя уже существует в этой сети.
    Для присоединения к домену откройте компонент панели управления "Система",
    измените имя компьютера и повторите попытку.
    Для присоединения к рабочей группе выберите другое имя рабочей группы.


    Информацию по этому поводу удалось найти в статье Базы знаний Microsoft 281308 Подключение с общим доступом по протоколу SMB на компьютерах с операционной системой Windows 2000 или Windows Server 2003 не всегда работает с псевдонимом
    Данную особенность можно назвать фичей, хотя весьма странной в статье выглядит фраза "Данное поведение является подтвержденной ошибкой продуктов Майкрософт, перечисленных в начале данной статьи. Первое исправление этой проблемы появилось в пакете обновлений 3 (SP3) для Windows 2000"

    После соответствующих изменений реестра на сервере:
    В разделе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters
    был создан параметр DisableStrictNameChecking с типом данных REG_DWORD и значением 1 (десятичное)
    и последующей перезагрузки сервера, подключение по CNAME заработало:

    D:> net use Z: \AnyServerWhithMyShare.domain.com\Share\Documents$
    Команда выполнена успешно.

  • WebDAV клиенты не могут загрузить в каталог на сервере файл размером более 30 Mb

    Окружение: Windows Server 2008, IIS 7.0, расширение для IIS - WebDAV 7.5
    Решение: Открываем на файловой системе сервера виртуальный каталог IIS в который необходимо разрешить загрузку больших файлов, там находим файл конфигурации web.config (если не находим - создаем).
    В этот файл вносим следующие изменения:

    <security>
    <requestFiltering>
    <requestLimits maxAllowedContentLength="104857600"/>
    </requestFiltering>
    </security>

    Таким образом мы установим разрешение на загрузку в виртуальный каталог через WebDAV файлов размером до 100 Mb.
    Можно также воспользоваться командой

    %windir%system32inetsrvappcmd set config -section:system.webServer/security/requestFiltering -requestLimits.maxAllowedContentLength:104857600

    Она установит данное разрешение на уровне сервера, что делать – далеко не во всех случая правильно.

  • Ускорение запуска PowerShell v1

    Из доклада Дмитрия Сотникова на TechDays.ru узнал несколько полезных вещей о PowerShell, в частности давно мучил вопрос о том как ускорить запуск оболочки версии 1. Как оказалось исправить проблему можно простейшим скриптом полученным на блоге команды разработчиков PowerShell: Speeding Up PowerShell Startup - Updating Update-Gac.ps1

    Вот собственно содержимое скрипта:

    Set-Alias ngen (Join-Path ([System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()) ngen.exe)
    [AppDomain]::CurrentDomain.GetAssemblies() |
    sort {Split-path $_.location -leaf} |
    %{
    $Name = (Split-Path $_.location -leaf)
    if ([System.Runtime.InteropServices.RuntimeEnvironment]::FromGlobalAccessCache($_))
    {
    Write-Host "Already GACed: $Name"
    }else
    {
    Write-Host -ForegroundColor Yellow "NGENing      : $Name"
    ngen $_.location | %{"`t$_"}
    }
    }

    После отработки скрипта на моей машине PowerShell стал запускаться действительно быстро.

  • Расширение размера тома NTFS

    Бывает такая ситуация, когда в ОС Windows требуется выполнить расширение тома NTFS, например есть свободное нераспределенное место на физическом диске и мы хотим "растянуть" имеющийся логический том до большего размера, использовав нераспределенное пространство диска... или другой пример - в виртуальной среде возникает необходимость увеличения выделенного для виртуальной машины диска, в таких случаях мы средствами платформы виртуализации (VMWare ESX, MS Hyper-V и т.п.) увеличиваем размер виртуального жесткого диска.

    Задача заключается в том, что нужно заставить ОС Windows использовать свободное дисковое пространство и, собственно говоря, "растянуть" логический том NTFS до допустимого размера.

    В ОС начиная с Vista/Server2008 эту операцию с легкостью можно проделать в online-режиме (без перезагрузки системы) встроенными средствами ОС - используя административную оснастку "Управление дисками": Выбираем интересующую нас партицию NTFS > Открываем контекстное меню и выбираем нужное действие "Расширить том...". Таким же образом мы с легкостью можем выполнить и обратную операцию - Сжатие тома. На мой взгляд, это очень полезное и удобное нововведение системы управления дисковыми томами в ОС.

    А как же решить данную задачу в системах Windows 2000/XP/Server 2003? В данном случае нам приходит на выручку бесплатная утилита от компании Dell - ExtPart.exe

    Параметры работы утилиты узнаем с помощью ключика /?

    D:ExtPart>extpart.exe /?

    ExtPart - Utility to extend basic disks (Build 1.0.4)
    (c) Dell Computer Corporation 2003

    Usage: extpart [volume size]
    volume  - volume to expand. eg. f:, g: etc. (only basic volumes)
    size    - size in megabytes to expand the volume

    Return codes for script mode
    (If parameters are not specified extpart will run in interactive mode)
    0       - Success
    1       - Parameter error. size parameter is invalid
    2       - Invalid volume or failed to connect to volume
    3       - Invalid volume type or failed to get volume properties
    4       - Requested size is invalid or volume expansion operation failed
    5       - Unable to retrieve volume properties after expansion completed
    6       - Invalid size requested for expansion (minimum value is 8 MB)

    Соответственно, например для того чтобы расширить том D: на 2 Gb будем использовать команду:
    ExtPart.exe D: 2048

    Дополнительная информация:
    Увеличение размера виртуального диска не приводит к автоматическому изменению размера тома
    VMware: Extend the OS disk the easy way (ExtPart.exe)