Где должен находиться TS Gateway?


 

В Windows Server 2008 появилась новая роль – TS Gateway предназначенная для организации доступа к ресурсам корпоративной сети по протоколу RDP over HTTPS. До появления этой роли защитить RDP трафик передаваемый по общедоступным каналам Интернета было не просто. Настройка публикации внутренних терминальных серверов требовала понимания сути вопроса http://www.isaserver.org/tutorials/Publishing-Remote-Desktop-Web-Connection-Sites-ISA-Firewall-Part1.html и не решала вопрос безопасности. Самый надежный вариант – настроить IPSec и пропустить трафик через него – в настройке и сопровождении был далеко не самым простым. (Пример http://system-administrators.info/?p=2094 )Наиболее доступным вариантом было настроить удаленный доступ через VPN, а RDP пропускать уже внутри него.

Появление TS Gateway сильно упростило задачу: пользователь подключается к TS Gateway обычным браузером, а RDP трафик инкапсулируется и передается по протоколу HTTPS в зашифрованном виде.

Теперь администратору нужно только решить как наилушим образом расположить сервер TS Gateway, который с одной стороны должен быть доступен извне корпоративной сети, а с другой иметь доступ к ресурсам корпоративной сети (домен контроллеры, терминальные серверы и т.д.).

Вариант 1. Классический вариант – расположить TS Gateway в DMZ.

clip_image002

Условия. У вас есть DMZ и есть внутренний и внешний корпоративные фаэволы.

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

Недостатки. Сложная архитектура требующая настройки целого ряда устройств. Ошибка в настройке или баг в любом звене приводит к отказу сервиса.

Применение. Имеет смысл использовать в крупных корпоративных сетях, когда есть средства предотвращения атак, активной фильтрации трафика на вирусы и т.п., средства мониторинга и контроля – без всего этого DMZ превращается в формальность.

Вариант 2. Расположить TS Gateway за одним фаэрволом

clip_image004

Условия. Фаэрвол должен быть и должен уметь обеспечивать доступ к внутренним серверам (публикация).

Достоинства. Простота реализации. Архитектура соответствует построению сети во многих малых и средних предприятиях.

Недостатки. При компрометации сервера TS Gateway вся сеть оказывается под ударом.

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

Вариант 3. Расположить TS Gateway за фаэрволом ISA или TMG

clip_image006

Условия. Наличие ISA или TMG.

Достоинства. Простота реализации. Архитектура соответствует построению сети во многих малых и средних предприятиях. Полное централизованное управление.

Недостатки. При компрометации сервера TS Gateway вся сеть оказывается под ударом. ISA имеет некоторые ограничения (снятые в TMG).

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

Вариант 4. Использовать TS Gateway с двумя интерфейсами и встроенным фаэрволом

clip_image008

Условия. На сервере должно быть две сетевые карты, включен и настроен встроенный фаэрвол. Выделенный внешний адрес для сервера TS Gateway.

Достоинства. Простота реализации. Независимость от других фаэрволов в сети. Полное централизованное управление.

Недостатки. При компрометации сервера TS Gateway вся сеть оказывается под ударом.

Применение. Еще недавно такой вариант был бы утопией, но роль TS Gateway работает на Windows Server 2008 и Windows Server 2008 R2, которые имеют мощный встроенный фаэрвол. Встроенный фаэрвол можно гибко централизованно настроить через групповые политики или локально на сервере TS Gateway. При необходимости можно выполнить тонкую настройку TCP/IP стека для защиты от DoS-атак. Если удалить с сервера TS Gateway все лишние роли и фичи, следить за установкой обновлений, настроить IIS по руководствам безопасности, защитить сервер антивирусом (системой безопасности) – в общем настроить TS Gateway сервер так как положено грамотному администратору, то этот вариант размещения TS Gateway становится вполне безопасным и практичным.

Вариант 5. Размещение TS Gateway в сети Интернет и использование IPSec для доступа в корпоративную сеть

clip_image010

Условия. Корпоративный фаэрвол должен уметь пропускать IPSec трафик или терминировать его. Корпоративная инфраструктура должна поддерживать IPSec. Выделенный внешний адрес для сервера TS Gateway.

Достоинства. Полное централизованное управление. Возможность удаленного размещения сервера TS Gateway.

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

Применение. Фактически это разновидность предыдущего варианта, пригодная для досточно больших сетей, где внедрен и работает IPSec, возможно даже IPv6, что даже проще. Необходимость туннелирования трафика сводит на нет достоинства – гороздо проще внедрить DirectAccess для клиентов, чем изобретать велосипед. Тем не менее вариант реализуем и работоспособен. Этот вариант позволяет нам разместить сервер TS Gateway удаленно, например, на площадке провайдера, где нет прямого доступа в корпоративную сеть.

Дополнение ко всем вариантам. TS Gateway поддерживает технологию NAP (Network Access Protection). Если NAP внедрен в корпоративной сети, то единственное, что требуется администратору, это включить поддержку NAP на сервере TS Gateway и обеспечить доступ к серверу NAP. Схематически NAP сервер располагается аналогично внутренним терминальным серверам, к которым обеспечивает доступ сервер TS Gateway.

Заключение. В зависимости от вашей конкретной ситуации вы можете подобрать наиболее подходящий вариант размещения сервера TS Gateway из рассмотренных вариантов или их модификаций.

Источник: TS Gateway Step-by-Step Guide

Реклама

SharePoint в SharePoint Designer-е :-)


 

Перед прядущим выходом новой волны продуктов SharePoint 2010 появляются сообщения в блогах разработчиков с описанием новшеств. Ценность каких публикаций в том, что описываются идеи заложенные в новые продукты.Это позволяет точно понимать для чего создан продукт, что он может, а чего в нем нет. Вот перевод такой статьи из блога разработчиков SharePoint Designer 2010 Putting the SharePoint in SharePoint Designer.

_____

Те кто уже давно с нами одной упряжке, знают, что SharePoint Designer (SPD)  берет начало от продукта под названием FrontPage.  Результатом такого происхождения было то, что SPD был целиком ориентирован на редактирование вэб-страниц с добавлением некоторых фич для SharePoint-а.  В SPD 2010 мы значительно расширили интерграцию с SharePoint-ом и  сфокусировались на единообразном предоставлении фичей SharePoint-а продвинутым пользователям и разработчикам. SharePoint всегда служил демократизации вэб-разработки – думайте о SPD как дополнительном шаге к этой цели.

clip_image001

Figure 1 Новый дизайн SPD больше сфокусирован на объектах SharePoint и меньше на файловой структуре и редактировании страниц

 

Когда вы думаете о демократизации, несколько слов приходит в голову: информированность, доступность и полезность. Если вы IT профессионал, то некоторые другие слова могут придти вам в голову:  безопасность, поддержка, унификация и, осмелюсь сказать, управляемость. Когда мы начинали этот проект, то вложили эти слова в наши сердца.  Мы были более успешными в достижении одних целей, чем других, но позвольте внести ясность: мы понимали, что это не очень хорошая идея просто дать каждому Тому, Дику, Джейн простой и мощный инструмент для построения приложений и надеяться, что они будут работать с кучей приложений.

Мы начнем с точки зрения IT:

·         Безопасность. Совместная работа это одна из самых мощных возможностей SharePoint-а, но она часто накладывает ограничения на то, что пользователи могут делать с системой. «Совместная» природа системы означает, что пользователи не могут добавлять мощный код на стороне сервера. В  новой версии мы предлагаем User Solutions – серверный контейнер (server sandbox) позволяющий пользователям загружать свой код или код третьих фирм для выполнения своих сценариев работы, который будет выполняться как изолированный процесс. Более того IT имеют контроль над ресурсами контейнера и его содержимым, создавая приемлемый уровень комфорта при его работе.

·         Поддержка. История показывает, что когда вы передаете SPD пользователям, несмотря на их наилучшие намерения, пользователи что-то да сломают. Как результат это приводит к звонкам в тех.поддержку. Новый SPD сделан безопасным по умолчанию (Safe by Default). Пользователи не могут редактировать главную страницу (master page) или   content place holder  и вывести из строя весь сайт! Эта мощная IT фича, которая требует детального рассмотрения в отдельной статье блога, но ее суть в том, что пользователи не могут просто открыть узел и разрушить его даже не поняв, что они что-то изменили.

·         Унификация. Благодаря тому, что мы ввели блокировку возможностей SPD, IT могут теперь контролировать какие шаблоны, главные страницы и стили могут быть использованы в их организациях. Это позволяет проще добиться соответствия сайтов корпоративным стандартам.

·         Управляемость. В новой версии SPD мы не только улучшили «поддерживаемость» SPD (Safe by Default), но мы дали IT простой, детальный контроль над тем, кто может использовать SPD и в какой части их фермы.

Теперь когда вы знаете, что IT собираются «благословить» использование SPD, давайте рассмотрим аспекты демократизации вэб-разработки для конечного пользователя – информируемость, доступность и полезность.

·         Информируемость. Мы можем реализовать абсолютно все мировые достижения в SPD, но они бесполезны, если пользователи не знают о их существовании. Чтобы решить эту проблему и поднять эффективность работы, мы указали линки на SPD в интерфейсе SharePoint-а. С помощью этих линков  мы значительно уменьшили сложность использования SPD для редактирования конретных аспектов сайтов SharePoint-а. Суть в том, что пользователь просто нажимает кнопку в браузере и в SPD открывается нужное место. В следующих статьях мы рассмотрим все эти линки подробно, а сейчас просто посмотрите как это выглядит на рисунке. Да, эти линки на SPD отображаются только, если пользователь имеет соответствующие права – помните что я сказал в разделе «Управляемость»?

 clip_image002

Figure 2 Контекстные ссылки появляются в интерфейсе браузера, указывая на SPD. Например, нажатие на Modify in SharePoint Designer  откроет в SPD текущий сайт и страницу для редактирования текущего списка. Теперь проще добавить условное форматирование и т.п.

·         Доступность. Многие из вас не знают, что SPD существует, еще меньшее число знает, чем он может помочь вашей организации имеющей SharePoint. Существуют две основные причины недостаточной информированности: 1. Из-за стоимости SPD многие организации предпочли ограничить его закупки, 2. Многие IT подразделения ограничили использование SPD в их сетях. Мы хорошо поработали над новой версией SPD, чтобы исключить эти факторы ограничивающие доступ пользователей к SPD.

1.       FREE! Да, вы правильно поняли –  теперь SPD абсолютно бесплатен для загрузки!

2.       Safe by Default. Безопасный по умолчанию. В новой версии пользователям очень трудно «подстрелить» себя. В будущих статьях мы рассмотрим это, но сейчас достаточно сказать, что SPD требует явных разрешений на модификацию страниц!

clip_image003

Figure 3 Новая оболочка отображает всю информацию относящуюся к объектам SharePoint. Например, на этой  list settings page для текущего списка отображаются общие настройки, формы, рабочие процессы и т.п. Все это легко редактируется из Ленты.

Дополнительно в новой оболочке мы создали некоторые фичи, которые делают SPD более полезным для IWs (Information workers):

·         Рабочие процессы были очень существенно улучшены в новом редакторе (Figure 4), сделаны повторно используемые Рабочие процессы, добавлены новые мощные предустановленные Рабочие процессы.

clip_image004

Figure 4 Рабочие процессы теперь можно создавать в SPD более легко и гибко. Лента и другие фичи нового интерфейса помогут в этом

·         XSLT list views еще одно значительное новшество. XSLT list views теперь являются представлением списков по умолчанию. Это означает, что разработчики теперь должны изучить единственную технологию для работы со списками! Такая стандартизация позволяет нам предложить несколько замечательных фич, например, Push Button Styles, которая позволяет настраивать стили и условное форматирование нажатием одной кнопки.Конечно мы посвятим одну или две статьи этой теме.

Я надеюсь, вы получили удовольствие, читая о большом наборе новых фич в выходящей версии SPD.  И мы бы хотели, чтобы вы вскоре вернулись и прочитали об этих и других новых фичах более детально. Напоследок позвольте донести до вас такую мысль: в новой версии мы много вложили в IWs , чтобы дополнить  фичи предлагаемые дизайнерам и разработчикам . Еще вы увидите удивительные вещи в предстоящих версиях Visual Studio и  Expressions как то интеграция с SPD и со всеми новшествами в SharePoint. В ближайшие месяцы ищите статьи в блогах на эти темы.

Signing off for now –

Todd Haugen (SPD GPM)

Интересные факты о пиратстве


 

Аccоциация производителей программного обеспечения Business Software Alliance (www.bsa.org) периодически публикует отчеты об использовании пиратского программного обеспечения в мире.

Чтобы объективно оценить цифры отчета и признать их фактами нужно хорошо знать методику оценки и иметь результаты аудита. Ни того не другого мы не имеем. Поэтому приходится «верить на слово» и верить авторитету авторов исследования. Недавние банкроства «столпов» мировой экономики показали, что очень «солидные» дяди надувают мыльные пузыри и дурят своих клиентов. Очивидно, что подобные отчеты неизбежно становятся аргументами в экономических и политических спорах на очень высоком уровне. Более того известно, что кто платит, тот и заказывает музыку. Поэтому наивно ожидать от них полной объективности. Тем не менее интересно почитать и поспорить J

Отчеты за 2008 год можно найти тут http://global.bsa.org/globalpiracy2008/index.html

Интересные факты:

68% программного обеспечения, установленного на персональные компьютеры в России в 2008 году, было нелицензионным, что на 5% ниже, чем в 2007 году. Финансовые потери производителей программного обеспечения в России от использования пиратской продукции выросли на 2%, составив 4.2 миллиарда долларов США.

Такая позитивная тенденция радует. Хотя не секрет, что она достигается в основном за счет крупных компаний, которым (1) есть что терять, у которых (2) есть деньги. В какой-то момент этот ресурс будет исчерпан и центр тяжести перейдет в другую сферу.  Какую?  В отчете прямо указано, что самый высокий уровень пиратства приходится на малые и средние предприятия.  

Другой позитивный фактор снижения пиратства – это появление «цивилизованных» способов распространения программного обеспечения. Прежде всего речь идет о предустановке программного обеспечения на новые компьютеры. Действительно сейчас не часто встретишь  в продаже настольный компьютер без наклейки типа «Windows Home» или «Linux», про ноутбуки и нетбуки и  говорить нечего.

Про влияние мирового кризиса на уровень пиратства ничего толком не сказано – ждите отчета за 2009 год. Упомянуто лишь, что существуют факторы, которые могут привести как к увеличению пиратства, так и к его снижению. Собственно если учесть что мировой кризис случился для всех кроме России, которая из кризиса не вылезает уже лет 25, то  у меня есть основания надеяться, что положительная тенденция по снижению пиратства в России сохранится и в этом году.

Вернемся к малому бизнесу. Возникает вопрос, что предложат компании производители программного обеспечения и государство мелким и средним предприятиям, для того чтобы способствовать снижению пиратства в этом сегменте. Если крупные предприятия способны переварить переход на лицензионное программное обеспечение под давлением государства  хотя бы по этапам, то мелкие и средние предприятия в большинстве своем не имеют  «финансового жирка», который можно пустить на легализацию программного обеспечения, и при жесткой политике государства сверху начнется «партизанская» война в форме «откатов» снизу. Кто-то сомневается? J

Напрашивается вывод: государство обречено искать другие способы снижения пиратства. В то том числе оказать давление на производителей программного обеспечения. А почему нет? В ЕС такое активно практикуется – защищаются и регулируют рынок!

В отчете упомянуто, что цены не являются основным фактором пиратства. Видимо вывод сделан на основе анализа пиратства в достаточно богатых странах. Для нас ценовой вопрос , я думаю, остается первостепенным: мы все же живем на рубли, а не на евро или доллары, и разница в уровне жизни ощутимая. Так что для нас снижение цен реальный фактор снижения пиратства. (Ну или зеркальное решение: вывод оборотов предприятий малого и среднего бизнеса на европейский уровень и зарплат соответственно тоже J)

Хочется надеятся, что государство будет не только «шашкой махать», а предложит экономические методы по развитию софтверного производства в России и, как следствие, торговли в этой сфере. В это слабо верится, когда у нас никакое производство не развивается, но без собственной индустрии нам «не жить» и не легализовать программное обчеспечение в малом и среднем бизнесе. Получается, что сейчас давление на Россию в вопросе снижения пиратства может дать импульс развитию промышленного производства. Главное, чтобы  «этузиазм» чиновников не зашкалило.

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

 

Вот еще интересные факты:

Уровень компьютерного пиратства в Украине в 2008 году вырос на 1% и составил 84%, что соответствует уровню 2006 года.

Страны с самым низким уровнем компьютерного пиратства остались прежними, как и в 2007 году: США (20%), Люксембург (21%), Новая Зеландия (22%), Япония (21%). При этом, несмотря на снижения уровня компьютерного пиратства в США на 1%, потери правообладателей выросли до 9 млрд. долларов.

Если принять что Украина это маленькая «модель» России, то это очень огорчительный факт: и у нас процесс может пойти в обратную сторону. С другой стороны «радует», что хоть тут мы не на первом месте. Впрочем Ураина тоже не на первом J. Кстати значительный уровень пиратства на Украине и Грузии (92%!!! Больше чем в Китае!) не помеха для «сближения» с Западом. Вот вам и политика…

Ну а по 20% пиратского программного обеспечения в США и в Японии это вообще!…  И это «минимум» среди стран с так называемым «цивилизованным» рынком!  — а в других «развитых» странах еще хуже. Как говорится: «А судьи кто?». Кстати по США мне попадались отчеты с гораздо более «пиратскими» процентами.

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

 

Windows 7 – способы установки


 

С появлением системы Windows 7 возникает такой процесс как ее установка J Как же устанавливать Windows 7 если компьютеров больше одного? И как перенести настройки и документы пользователей? Компания Microsoft опубликовала целый пакет документов по этому вопросу. Чтобы вам было легче разобраться – ниже краткий обзор и ссылки на оригиналы документов.

Установка

Оригинальный документ обзора   Upgrading to Windows 7 for Small and Midsize Businesses

Ручная установка.

  1.         I.            Ручная установка с DVD

Суть: Обычный дистрибутив Windows 7 записан на DVD носитель, с которого производится установка. Все настройки выполняются вручную.

Применение: малое число компьютеров

  1.       II.            Автоматическая установка с DVD

Суть:  Подготавливается  Unattend.xml файл – файл ответов, и записывается на флешку, которая подключается  к целевом компьютеру и далее производится запуск установки с DVD носителя как в первом случае

Применение: малое число компьютеров (до 100), стандартные настройки.

Документ: Manual Installation of Windows 7 Overview.  

 

Установка стандартного образа

                Суть:

  1. Поготовка  эталонного компьютера: настройка системы, установка приложений
  2. Снятие образа с эталонного компьютера и запись его на DVD носитель
  3. Установка с подготовленного DVD носителя на целевые системы

Применение: до 200 компьютеров с типовой конфигурацией

Документы:  Upgrading to Windows 7 with a Standard Image Overview,  Building a Standard Image of Windows 7 Step-by-Step Guide

 

 

Автоматическая установка

Суть:

  1. Установка и настройка  пакета MDT 2010
  2. Создание образа Windows 7 в сети
  3. Создание загрузочных образов  Windows PE и подготовка загрузочных носителей
  4. Загрузка целевых компьютеров с  Windows PE и установка Windows 7

Применение: от 200 до 500 компьютеров, наиболее универсальный способ

Документы:  Automated Installation of Windows 7 Overview,  Automated Installation To Upgrade Windows 7 Step-by-Step Guide

 

          Миграция

Документация по миграции Step-by-Step: Windows 7 Upgrade and Migration

При внедрении Windows 7 неизбежно возникает вопрос о миграции с предыдущих версий. В большинстве случаев установка поверх старой системы с автоматическим переносом профилей не работает (не работает для XP, для Vista без сервис пака, если не совпадает разрядность системы, есть еще ряд ограничений) — установщик Windows 7 перемещает старую систему и профили в папку Windows.old

  Допустимые варианты миграции Windows 7 Upgrade Path.

Чтобы перести профили пользователей на новую систему можно использовать пакет  Windows Easy Transfer:

Windows Easy Transfer for transferring from Windows XP (32 bit) to Windows 7

Windows Easy Transfer for transferring from Windows XP (64 bit) to Windows 7

Windows Easy Transfer for transferring from Windows Vista (32 bit) to Windows 7

Windows Easy Transfer for transferring from Windows Vista (64 bit) to Windows 7

                Суть:

  1. Запускается утилита, которая делает архив профиля пользователя.
  2. Устанавливается новая система.
  3. Запускается утилита, которая переносит информацию из архива профиля в новый профиль.

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

Суть:

  1. Взять из Windows Automated Installation Kit пакет User State Migration Tool (USMT) 4.0
  2. Подготовить и запустить bat-файл из пакета USMT
  3. Установить новую систему – все старые файлы и профили будут перенесены в папку Windows.old
  4. Запустить второй раз bat-файл из пакета USMT, который выполнит перемещение стараго профиля в новый без копирования: создавая hard-линки, что очень значительно быстрее, чем копирование файлов.

Документ :Windows XP to Windows 7 Hard-Link Migration of User Files and Settings

                                                                                                                                                 

Удачи вам в массовой установке и миграции на Windows 7!

PowerShell – работаем с FTP сервером


Метод 1. Одна из полезных и удобных особенностей PowerShell – возможность прозрачно взаимодействовать с утилитами командной строки.

В Windows досточно много утилит командной строки, которые уже много лет служат верой и правдой. Многие  утилиты хорошо известны и широко используются. Некоторые решают свою задачу быстро и эффективно. Cовершенно неоправдано ожидать, что PowerShell заменит их сразу и полностью. В ряде случаев такая замена вообще неоправдана. Хорошо, что PowerShell не требует от нас переписывать существующие утилиты на .NET Framework и позволяет использовать всю их мощь.

Одна из таких утилит ftp.exe Утилита специфическая и по современным понятиям неудобная. Но она стандартная и администратор может ее использовать при необходимости на любой системе без лишних усилий. Чтобы несколько уменьшить неуклюжесть интерфейса утилиты ftp.exe , используем PowerShell.

Конечно мы не будем делать универсальную обертку: просто продемонстрируем технику и за одно решим вполне практическую задачу копирования списка файлов с ftp-сервера: сделать это стандартными командами вручную непросто (написать 5 команд get еще можно, а 15 уже утомительно).

Для начала создадим список команд в переменной (каждая команда пишется на новой строке!):

>$FileList = "open 17.17.17.21

user USERNAME PASSWORD

binary

cd DIRECTORYNAME

mdir * -" | ftp -i -n | where {$_.Trim() -ne "" } 

 

В результате получим листинг нужной директории. Обратите внимание, что использована команда “mdir * — “ – звездочка, пробел, минус. Далее убраны пустые строки. Для конкретного ftp-сервера возможно придется убрать иной мусор.

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

>$FileList = $FileList | Where {-not $_.StartsWith("d")} | Where {$_.Contains("Dec 22  2005")} | %{ $_.SubString(49) }

 

Тут сначала убраны директории, затем выбраны файлы за определенную дату, а потом  вырезаны имена файлов.

Теперь скопируем эти файлы на локальную машину:

>$cmd = " open 17.17.17.21

user USERNAME PASSWORD

binary

cd DIRECTORYNAME

" +

($FileList | %{ "get ""$_""`n" })

$cmd | ftp -i –n

 

Как видите утилита ftp принимает команды через стандартный поток ввода и выдает результат на стандартный поток вывода. Эта ее особенность использована в приведенном примере.

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

Конечно приведенную технику можно использовать не только для загрузки файлов, но и для выгрузки на сервер: достаточно изменить команду get на команду put.

 

Метод 2. Другой метод работы с FTP сервером – использовать средства  .NET Framework.

Получить список файлов (DIR):

>$server = "17.17.17.21"

>$filename = "DIRECTORY"

>$url = ftp://$server/$filename

>[System.Net.FtpWebRequest]$WR = [System.Net.WebRequest]::Create($url)

>$WR.Method = [System.Net.WebRequestMethods+FTP]::ListDirectoryDetails

>$WR.Proxy = $null

>$WR.Credentials = New-Object System.Net.NetworkCredential("USERNAME", "PASSWORD")

>$WRStream = $WR.GetResponse();

>$responseStream = $WRStream.GetResponseStream()

>$readStream = new-object System.IO.StreamReader($responseStream, [System.Text.Encoding]::UTF8)

>$FileList =$readStream.ReadToEnd()

>$FileList = $FileList.Split("`n`r")

 

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

>[System.Net.WebRequestMethods+FTP].GetMembers() | ft Name

 

Отфильтровать список файлов и получить только нужные файлы:

> $FileList = $FileList | Where {-not $_.StartsWith("d")} | Where {$_.Contains("Dec 22  2005")} | %{ $_.SubString(49) }

 

Загрузить файлы по сформированному списку:

>$FileList | % {

[System.Net.FtpWebRequest]$WR = [System.Net.WebRequest]::Create($url+"/$_")

$WR.Method = [System.Net.WebRequestMethods+FTP]::DownloadFile

$WR.Proxy = $null

$WR.UseBinary = $True

$WR.Credentials = New-Object System.Net.NetworkCredential("USERNAME", "PASSWORD")

$WRStream = $WR.GetResponse()

$responseStream = $WRStream.GetResponseStream()

$readStream = new-object System.IO.StreamReader($responseStream, [System.Text.Encoding]::UTF8)

$a=$readStream.ReadToEnd()

Out-File -FilePath $_ -inputobject $a }

 

Обратная задача – выгрузка файлов по списку на сервер (не тестировано):

>$FileList | % {

[System.Net.FtpWebRequest]$WR = [System.Net.WebRequest]::Create($url+"/$_")

$WR.Method = [System.Net.WebRequestMethods+FTP]::UploadFile

$WR.Proxy = $null

$WR.UseBinary = $True

$WR.Credentials = New-Object System.Net.NetworkCredential("USERNAME", "PASSWORD")

$WRStream = $WR.GetResponse()

$responseStream = $WRStream.GetResponseStream()

$WriteStream = new-object System.IO.StreamWriter($responseStream, [System.Text.Encoding]::UTF8)

Get-Content $_ | % {$WriteStream.WriteString($_)

$WriteStream.Close()

$responseStream.Close()

$WRStream.Close()}

 

Загрузку одиночного файла можно выполнить более экономным методом. Для этого можно применить класс  WebClient Class:

>$WC = new-object System.Net.WebClient

>$server = "17.17.17.21"

>$filename = "DIRECTORY/FILENAME"

>$url = "ftp://$server/$filename"

>$WC.Proxy = $null

>$Wc.Credentials = New-Object System.Net.NetworkCredential("USERNAME", "PASSWORD")

>$localfile = "LOCALFILENAME"

>$WC.DownloadFile($url,$localfile)

 

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

>$WC. UploadFile($url,$localfile)

 

Метод 3.  Загрузить и установить какое-нибудь дополнение к PowerShell для работы с сетью. Есть коммерческие варианты. Есть бесплатные (Indy). Примеры смотрите в самих пакетах.

 

Заключение. Как видите, написание кода несколько более объемная задача, чем использование утилиты с хорошо продуманным интерфейсам. Впрочем это верно и для командлетов. Вывод напрашивается сам собой: PowerShell позволяет нам использовать всю мощь .NET Framework, но иногда мощь языка программирования нам лишняя: если есть удобная утилита, то в большинстве случаев ее можно использовать в PowerShell легко, просто и удобно получая компактный и быстрый скрипт для решения задачи.

 

 

Источники:

1.       http://feelingsofwhite.com/2007/03/look-what-you-can-do-in-powershell-ftp/

2.       WebRequest Class

3.       FtpWebResponse Class

4.       WebRequestMethods.Ftp Class (как работать с вложенными классами  http://blogs.msdn.com/powershell/archive/2009/08/27/plus-in-net-class-names.aspx )

5.       WebClient Class

 

 

 

PowerShell – контроль окружения


 

   PowerShell 2.0 уже появился в релизе Windows 7 и Windows Server 2008 R2 и вот вот появится для остальных версий Windows. Очивидно, что различие версий PowerShell требует некоторого контроля за использованием новых фич. К тому же, как известно, PowerShell основывается на .NET Framework. Это означает, что скрипт может использовать некоторые особенности старшей версии PowerShell, более новой версии .NET Framework и использовать особенности версии операционной системы. Следовательно для надежной работы скрипта надо контролировать версию PowerShell, версию .NET Framework и версию операционной системы.

   Получить версию PowerShell достаточно просто:

PS U:\> Get-Host

Name : ConsoleHost

Version : 2.0

InstanceId : f1738d90-0853-4686-8c02-44851432652f

UI : System.Management.Automation.Internal.Host.InternalHostUserInterface

CurrentCulture : en-US

CurrentUICulture : en-US

PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy

IsRunspacePushed : False

Runspace : System.Management.Automation.Runspaces.LocalRunspace

  

   Либо более подробно:

PS U:\> (Get-Host).Version

Major Minor Build Revision

—— —— —— ———

2 0 -1 -1

 

   Получить версию .NET Framework common language runtime:

PS U:\> [System.Environment]::Version

Major Minor Build Revision

—— —— —— ———

2 0 50727 4927

 

   Да это результат выполнения на Windows 7. Почему не 3.5 ? Скорее всего выводится именно то, что указаоно в документации: версия common language runtime (CLR), а она имеет номер 2. Другое дело библиотеки .NET Framework и их версия. Я нашел вот такой несколько странный способ выяснить какой «донет» установлен на компьютере:

PS U:\> (Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent").Property

.NET CLR 2.0.50727

SLCC2

.NET CLR 3.5.30729

.NET CLR 3.0.30729

Media Center PC 6.0

InfoPath.3

PS U:\> (Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent").Property | Where-Object { $_.ToString() -like ".NET*" }

.NET CLR 2.0.50727

.NET CLR 3.5.30729

.NET CLR 3.0.30729

 

   Несмотря на странность этого метода, он работает! Изначально метод рассчитан на извещение браузером web-сервера какая версия «дотнет» установлена на клиенте, для того чтобы сервер мог корректно сгенерировать код страницы для клиента. Но это не мешает нам использовать его в PowerShell для контроля окружения.

   Получить версию операционной системы:

PS U:\> [System.Environment]::OSVersion | fl

Platform : Win32NT

ServicePack :

Version : 6.1.7600.0

VersionString : Microsoft Windows NT 6.1.7600.0

 

   Как видите, мы можем получить не только номер версии ОС, но и номер установленного сервиспака. Меня несколько смутило указание Win32NT, но оказалось, что это не имеет отношения к 32/64 bit архитектуре http://msdn.microsoft.com/en-us/library/3a8hyw88.aspx

   Что еще может оказаться важным для выполнения скрипта? Текущая локаль. Ее можно посмотреть так:

PS U:\> (Get-Host).CurrentCulture

LCID Name DisplayName

—- —- ————

1033 en-US English (United States)

 

   В PowerShell 2.0 есть директива #requires, которая позволяет контролировать некоторые параметры окружения.

   Например можно указать минимальную версию PowerShell:

#requires –Version 2.0

   Либо тоже самое сделать для SnapIn:

#requires –PsSnapIn Microsoft.WSMan.Management –Version 2

   Еще можно проверить имя «сборки»:

#requires –ShellId MyShell

   Последняя команда относится к новой фиче PowerShell 2.0, которая позволяет создавать свои собственные «закрытые» консоли на базе PowerShell. О том как это сделать, можно прочитать в документации How to Create a Console Shell.

 

Источники:

1. about_requires.help.txt

2. about_PSSnapins.help.txt

3. http://msdn.microsoft.com/en-us/library/aa480198.aspx

4. http://msdn.microsoft.com/en-us/library/system.environment.aspx

5. http://support.microsoft.com/kb/315291

PowerShell – работаем со скриптблоками (ScriptBlock)


 

PowerShell является скриптовым языком, что подразумевает простоту его использования. Тем не менее в PowerShell есть некоторые механизмы, которые не совсем очивидны и просты для понимания. Один из таких механизмов – скриптблоки (scriptblock).

Вот их я и собираюсь «попиарить» в этой статье.

Скриптблок в PowerShell является экземпляром класса .NET Famework System.Management.Automation.ScriptBlock и представляет собой предкомпилированый текст скрипта как единое целое – объект:

>$sb = { dir }

>$sb.GetType()

IsPublic IsSerial Name BaseType

——— ——— —- ———

True False ScriptBlock System.Object

По сути скриптблок это почти функция. Почти потому что у скриптблока нет имени – функция это именованный скриптблок! – и есть более жесткие правила по заданию параметров при использовании в конвейере. Да скриптблок может иметь параметры и применяться в конвейере! Более того он как и функция может иметь такие фичи как DynamicParam, Begin, Process, and End – это позволяет писать вполне функциональные скриптблоки для работы в конвейере.

Пример использования скриптблока с параметром:

>$sb = { param ( [string] $DirPath) dir $DirPath }

> &$sb c:\

Как видите для исполнения скриптблока применяется оператор &:

>$sb = { dir } либо даже просто >$sb = “dir

>&$sb

>& { dir }

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

>$string = “ dir C:\”

>& $string — ошибка!!!

Причина тут в том, что оператор & сначала делает вызов Get-Command $string для получения объекта команды (CommandInfo object), а потом делает вызов на исполнение. Но оператор & может принимать параметр, поэтому правильно писать так:

>$sb = “dir

>&$sb C:\

>& { dir } C:\

Выполнить скриптблок также можно с помощью командлета Invoke-Command:

>$sb = { param ( [string] $DirPath) dir $DirPath }

>invoke-command –scriptblock $sb –args “C:\”

>invoke-command –scriptblock { param ( [string] $DirPath) dir $DirPath } –args “C:\”

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

Способ 1: $scriptblock = $executioncontext.invokecommand.NewScriptBlock($string)

Способ 2: $scriptblock = [scriptblock]::Create($string)

Способ 3: Использование оператора &

Из определения скриптблока видно, что его можно исполнить как код и что с ним можно обращаться как с объектом: например, присвоить переменной или передать как параметр командлету или функции, в том числе по конвейеру. Многие командлеты и функции принимают скриптблоки в качестве параметров:

>1..2 | Where-Object -FilterScript { $_ }

>$sb = { $_}

>1..2 | Where-Object -FilterScript $sb

Вот так работает передача скриптблока по конвейеру:

>$a = “c:\”,”d:\”

>$a | foreach { [scriptblock]::Create("dir $_") } | % { Invoke-Command $_ }

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

Есть еще одна интересная особенность скриптблоков.

Ситуация иная, можно сказать, инверсная к предыдущей. Если мы строим конвейер и в скриптблоке задан параметр, то величина передаваемая по конвейеру привязывается к этому параметру – это мы видели в примере показанном выше. Если же скриптблок не имеет параметра, то он выполняется для каждой величины, которая передается по конвейеру, т.е. скриптблок параметризирует конвейер! Пример такого случая:

>"c:\" | Get-ChildItem -Path $_ — это не работает! Ошибка!

>"c:\" | Get-ChildItem -Path {$_} — это работает!!!

Как можно применять такое поведение скриптблоков для обхода ограничений командлетов, которые не принимают параметры из конвейера, рассказывают разработчики PowerShell https://blogs.msdn.com/powershell/archive/2006/06/23/643674.aspx Например, командлет Get-WmiObject не принимает объекты из конвейера:

> "Comp1","Comp2" | Get-WmiObject Win32_OperatingSystem

SystemDirectory : C:\Windows\system32

Organization :

BuildNumber : 7600

RegisteredUser : 1

SerialNumber : 00426-292-0126336-85460

Version : 6.1.7600

Get-WmiObject : The input object cannot be bound to any parameters for the command either because the command does not

take pipeline input or the input and its properties do not match any of the parameters that take pipeline input.

Можно обойти проблему так:

> "Comp1","Comp2" | ForEach { Get-WmiObject Win32_OperatingSystem -ComputerName $_ }

А можно более изящно:

> "Comp1","Comp2" | Get-WmiObject Win32_OperatingSystem -ComputerName { $_ }

Пример от разработчиков PowerShell кое-что разъяснил нам про прелести скрптблоков. Но пригодится ли нам это? Если мы делаем серьезный командлет или функцию для постоянного применения и тем более для распространения, то нам следует хорошо продумать ее интерфейс и реализовать для работы в конвейере. Но ведь это надо продумать, написать и протестировать. А описаная техника применения скриптблоков позволяет нам писать простые функции и использовать их в конвейере! Как это упрощает нам жизнь и экономит время!

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

Источники:

1. Краткое описание и примеры скрипблоков есть в документации по PowerShell. Смотрите файл about_script_blocks.help.

2. https://blogs.msdn.com/powershell/archive/2006/06/23/643674.aspx

3. ScriptBlock на MSDN http://msdn.microsoft.com/en-us/library/system.management.automation.scriptblock(VS.85).aspx

4. http://powershell.com/cs/blogs/ebook/archive/2009/03/30/chapter-12-command-discovery-and-scriptblocks.aspx