СофтВелис.com

Очередное исследование, проводимое во главе с Бетси Спарроу, было призвано выявить влияние интернета на человеческую память. Результаты в очередной раз должны вызвать беспокойство у постоянных обитателей сети. Учёные пришли к выводу, что интернет изменяет природу нашего восприятия. Мы учимся находить факты, но при этом перестаёт функционировать механизм запоминания.

Патрисия Коэн "Times" суммирует результаты:

Доктор Спарроу и ее сотрудники, Даниэль М. Вегнер Гарварда и Дженни Луи из университета Висконсина, Мэдисон, подготовили четыре различных эксперимента на памяти. В одном участники вводили 40 фактов — например, “глаз страуса больше чем его мозг” — в компьютер. Половина участников полагала, что информация будет сохранена в компьютере; другая – что данные будут стёрты.

“Участники не прилагали усилия, чтобы что-то запомнить, думая, что смогут найти нужную информацию в любой момент”, пишут авторы.

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

В этом случае участников попросили запомнить и сами данные и в какую из пяти компьютерных папок они были сохранены. Люди оказались более способны к запоминанию папок.

Человек приспосабливается к современной информационной среде, интегрируется с вычислительными машинами. Ранее люди могли полагаться только друг на друга, сегодня у человека появился новый «друг» – более надёжный, как хранилище информации, более доступный в плане извлечения информации. Собственная память начинает атрофироваться, взамен развиваются навигационные навыки для коммуникации с компьютерной средой.

Учёные считают, что всё не так плохо. Потому что, несмотря на возвышенное отношение к человеческой памяти, как неотъемлемой части его природы, она не является надёжным источником информации. Данные хранящиеся в памяти, имеют обыкновение искажаться со временем, и в конечном итоге не отражают действительное положение вещей. Это входит в теорию консолидации памяти. (См. работу Элизабет Лофтус о погрешности памяти.)

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

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

F# — новый функциональный и объектно-ориентированный язык программирования для Microsoft .NET Framework, и в этом году он интегрирован в Microsoft Visual Studio 2010. F# сочетает простой четкий синтаксис со строгой статической типизацией и позволяет не только создавать сравнительно небольшие экспериментальные блоки кода в F# Interactive, но и вести крупномасштабную разработку компонентов на основе .NET Framework в Visual Studio.

F# спроектирован с нуля и рассчитан на выполнение в CLR. Как язык на основе .NET Framework, F# использует богатство библиотек, доступных в .NET Framework, и его можно применять для создания .NET-библиотек или реализации .NET-интерфейсов. F# также использует множество основополагающих механизмов CLR, в том числе обобщения, сбор мусора, инструкции «вызова в хвостовой позиции» (tail call) fn и фундаментальную систему типов Common Language Infrastructure (CLI). Вызов подпрограммы, которая находится в выражении return. — Прим. ред.

В этой статье рассматриваются некоторые основные концепции языка F# и его реализация поверх CLR.

Краткий обзор F#

Начнем с краткого обзора ряда основных языковых средств F#. Подробнее об этих средствах и многих других интересных концепциях в F# см. документацию в F# Developer Center по ссылке fsharp.net.

Самая главная особенность F# — ключевое слово let, которое связывает значение с именем. Оно может использоваться для связывания данных и значений функции, а также для связывания на локальном и глобальном уровнях:

let data = 12let f x = let sum = x + 1 let g y = sum + y*y g x

F# предоставляет несколько базовых типов данных и языковый синтаксис для работы со структурными данными, в том числе со списками, типизированными необязательными значениями и tuple-типами:

let list1 = ["Bob"; "Jom"]let option1 = Some(”Bob”)let option2 = Nonelet tuple1 = (1, “one”, '1')

В этих и других блоках структурных данных можно искать соответствия заданному шаблону с помощью специальных выражений F#. Проверка на соответствие шаблону аналогична применению выражений switch в C-подобных языках, но ее возможности шире: можно не только искать, но и извлекать части из совпадающих выражений; в этом смысле выражения поиска соответствия шаблону напоминают то, как регулярные выражения используются для получения строк, соответствующих шаблону:

let person = Some (”Bob”, 32)match person with| Some(name,age) -> printfn “We got %s, age %d” name age| None -> printfn “Nope, got nobody”

F# применяет библиотеки .NET Framework для многих задач, например для доступа к данным из самых разнообразных источников; причем эти .NET-библиотеки могут быть задействованы из F# точно так же, как и в других .NET-языках:

let http url = let req = WebRequest.Create(new Uri(url)) let resp = req.GetResponse() let stream = resp.GetResponseStream() let reader = new StreamReader(stream) reader.ReadToEnd()

F# также является объектно-ориентированных языком и может определять любой .NET-класс или структуру (struct) подобно C# или Visual Basic:

type Point2D(x,y) = member this.X = x member this.Y = y member this.Magnitude = x*x + y*y member this.Translate(dx, dy) = new Point2D(x + dx, y + dy)

Кроме того, F# поддерживает две особые разновидности типов: записи (records) и размеченные объединения (discriminated unions). Записи — простое представление значений данных именованными полями, а размеченные объединения — выразительный способ представления типов, которые могут содержать несколько видов значений, причем с каждым видом могут быть сопоставлены разные данные, например:

type Person = { Name : string; HomeTown : string; BirthDate : System.DateTime }type Tree = | Branch of Tree * Tree | Leaf of intF# поверх CLR

F# во многих отношениях является более высокоуровневым языком, чем C#, с его системой типов, синтаксисом и языковыми конструкциями, еще больше отдаленными от метаданных и промежуточного языка (intermediate language, IL) общеязыковой исполняющей среды (CLR). Это влечет за собой несколько интересных последствий. Самое важное заключается в том, что разработчики на F# зачастую могут решать задачи и думать о своих программах на более высоком уровне, ближе к конкретной предметной области, для которой они ведут разработки. Но это же означает, что компилятор F# выполняет больше работы, связанной с преобразованием F#-кода под CLR, и это преобразование менее прямолинейное.

Компилятор C# 1.0 и CLR создавались в одно время, и их функциональность очень близко выровнена друг относительно друга. Почти все языковые конструкции C# 1.0 имеют предельно прямое представление в системе типов CLR и в CIL. В последующих версиях C# это было выражено уже не столь явно, так как язык C# развивался быстрее самой CLR. Итераторы и анонимные методы были фундаментальными языковыми средствами C# 2.0, для которых не было прямых эквивалентов в CLR. В C# 3.0 выражения запросов и анонимные типы еще больше усилили эту тенденцию.

F# делает еще один шаг вперед на этом пути. Многие языковые конструкции не имеют прямых IL-эквивалентов, поэтому такие средства, как выражения поиска соответствий шаблону, компилируются в богатый набор IL-инструкций, используемых для эффективного выполнения соответствующей задачи. F#-типы вроде записей и объединений приводят к автоматической генерации множества необходимых для них членов.

Но заметьте, что я обсуждаю особенности компиляции, используемые текущим компилятором F#. Многие из этих деталей реализации не видны разработчику F# напрямую и могут быть модифицированы в будущих версиях компилятора F# для оптимизации производительности или поддержки новых средств.

Неизменяемость по умолчанию

Связывание через let в F# аналогично var в C# с единственным важным отличием: после связывания значения с именем через let это значение становится неизменяемым. То есть по умолчанию в F# значения являются неизменяемыми:

let x = 5x <- 6 // error: This value is not mutable

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

Изменяемость можно включить в F#, и это часто делается при вызове других .NET-библиотек или для оптимизации конкретных путей выполнения кода:

let mutable y = 5y <- 6

Аналогичным образом типы в F# тоже являются неизменяемыми по умолчанию:

let bob = { Name = “Bob”; HomeTown = “Seattle” }// error: This field is not mutablebob.HomeTown <- “New York”let bobJr = { bob with HomeTown = “Seattle” }

В этом примере, когда изменение не разрешено, вместо прямой модификации используется копирование и обновление для создания новой копии из старой при изменении одного или более полей. Хотя при этом создается новый объект, он разделяет многие свои части с исходным. В данном примере нужна лишь единственная строка «Bob». Такое разделение (совместное использование) — одна из важнейших характеристик неизменяемости.

Разделение можно увидеть и в наборах F#. Например, F#-тип list является структурой данных «связанный список», которая может разделять свою хвостовую часть (tail) с другими списками:

let list1 = [1;2;3]let list2 = 0 :: list1let list3 = List.tail list1

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

Здесь большую роль играет CLR. В программировании с применением неизменяемости наблюдается тенденция к созданию более короткоживущих объектов — это результат того, что данные преобразуются, а не изменяются «по месту». Сборщик мусора (garbage collector, GC) в CLR хорошо справляется с такой ситуацией. Малые короткоживущие объекты создают минимум издержек благодаря тому, что CLR GC использует сбор мусора на основе поколений объектов.

Функции

F# — функциональный язык, и не удивительно, что функции играют важную роль в этом языке. Функции являются полноценной частью системы типов в F#. Например, тип «char -> int» представляет F#-функции, которые принимают char и возвращают int.

Хотя F#-функции аналогичны .NET-делегатам, они имеют два важных отличия. Во-первых, они не номинальные. Любая функция, которая принимает char и возвращает int, имеет тип «char -> int», тогда как для представления функций с этой сигнатурой может быть использовано несколько делегатов с разными именами, и они не являются взаимозаменяемыми.

Во-вторых, F#-функции рассчитаны на эффективную поддержку либо частичного, либо полного применения. Частичное применение (partial application) наблюдается, когда функции с несколькими параметрами передается лишь некое подмножество этих параметров, что приводит к появлению новой функции, принимающей остальные параметры:

let add x y = x + ylet add3a = add 3let add3b y = add 3 ylet add3c = fun y -> add 3 y

Все значения F#-функции являются экземплярами типа FSharpFunc<, >, который определен в библиотеке исполняющей среды F# — FSharp.Core.dll. При использовании библиотеки F# из C# этот тип имеют все значения F#-функции, принимаемые как параметры или возвращаемые из методов. Этот класс выглядит примерно так (если вы определили его в C#):

public abstract class FSharpFunc<T, TResult> { public abstract TResult Invoke(T arg);}

Обратите особое внимание на то, что все F#-функции принимают единственный аргумент и возвращают один результат. Это верно и в случае частичного применения — F#-функция с несколькими параметрами на самом деле является экземпляром типа вроде:

FSharpFunc<int, FSharpFunc<char, bool>>

т. е. функцией, которая принимает int и возвращает другую функцию, а та в свою очередь принимает char и возвращает bool. Распространенный случай полного применения (full application) реализуется за счет набора вспомогательных типов из базовой библиотеки F#.

Когда значение F#-функции создается с помощью лямбда-выражения (ключевого слова fun) или в результате частичного применения другой функции (как в случае add3a, показанном ранее), компилятор F# генерирует класс замыкания (closure class):

internal class Add3Closure : FSharpFunc<int, int> { public override int Invoke(int arg) { return arg + 3; }}

Эти замыкания аналогичны замыканиям, создаваемым компиляторами C# и Visual Basic для своих конструкций с лямбда-выражениями. Замыкание — одна из наиболее часто генерируемых компилятором конструкций в .NET Framework, не имеющих прямой поддержки на уровне CLR. Замыкания существуют практически во всех .NET-языках программирования и особенно интенсивно используются в F#.

Объекты-функции — распространенное явление в F#, поэтому компилятор F# использует множество видов оптимизации, чтобы избежать необходимости создавать эти замыкания. За счет применения подстановки в строку, аннулирования лямбд (lambda-lifting) и прямого представления в виде .NET-методов, когда это возможно, внутренний код, генерируемый компилятором F#, зачастую отличается от описанного в этом разделе.

Распознавание типов и обобщения

Одна заметная особенность всех примеров кода, приведенных до сих пор, — отсутствие всяких обозначений типов (type annotation). Хотя F# является языком программирования со статической типизацией, явные обозначения типов зачастую не требуются, так как F# интенсивно использует логическое распознавание типов (type inference).

Распознавание типов знакомо разработчикам на C# и Visual Basic, которые используют его для локальных переменных, как в этом фрагменте кода на C# 3.0:

var name = “John”;

Ключевое слово let в F# работает аналогично, но поддержка распознавания типов в F# гораздо обширнее: она применима к полям, параметрам и возвращаемым типам. В следующем примере у двух полей (x и y) логически определяется тип int, который является типом по умолчанию для операторов + и *, применяемых к этим значениям в теле определения типа. Тип метода Translate логически распознается как «Translate : int * int -> Point2D»:

type Point2D(x,y) = member this.X = x member this.Y = y member this.Magnitude = x*x + y*y member this.Translate(dx, dy) = new Point2D(x + dx, y + dy)

Конечно, вы можете использовать обозначения типов, если вам нужно сообщить компилятору F#, какой тип на самом деле ожидается для определенного значения, поля или параметра. Эта информация потом будет использована при распознавании типа. Например, вы можете изменить определение Point2D, чтобы использовать float вместо int, просто добавив пару обозначений типов:

type Point2D(x : float,y : float) = member this.X = x member this.Y = y member this.Magnitude = x*x + y*y member this.Translate(dx, dy) = new Point2D(x + dx, y + dy)

Одно из важнейших последствий логического распознавания типов заключается в том, что функции, не привязанные к конкретному типу, автоматически становятся обобщенными. Поэтому ваш код будет максимально обобщенным без явного указания всех обобщенных типов. А это приводит к тому, что обобщения играют важнейшую роль в F#. Композиционный стиль функционального программирования в F# также способствует созданию компактных блоков повторно используемой функциональности, которые сильно выигрывают, если являются максимально обобщенными. Возможность создавать обобщенные функции без сложных обозначений типов — важная особенность F#.

Например, следующая функция map проходит по списку значений и генерирует новый список, применяя свой аргумент f к каждому элементу:

let rec map f values = match values with | [] -> [] | x :: rest -> (f x) :: (map f rest)

Заметьте, что обозначений типов не требуется, а логически определенный тип для map — «map : ('a -> 'b) -> list<'a> -> list<'b>». F# способен логически определять типы по соответствию шаблону (pattern matching) и использованию параметра f в качестве функции, по типам двух параметров, имеющим определенную форму, но не полностью фиксированным. Так что F# делает функцию максимально обобщенной, и в то же время имеющей типы, необходимые для реализации. Обратите внимание на то, что обобщенные параметры в F# помечаются префиксом ', чтобы синтаксически отличать их от других имен.

Дон Сайм (Don Syme), проектировщик F#, ранее был ведущим исследователем и разработчиком в проекте реализации обобщений в .NET Framework 2.0. Концепция языков вроде F# крайне зависима от поддержки обобщений исполняющей средой, и интерес Сайма к созданию F# отчасти вызван желанием по-настоящему полно задействовать преимущества этой функциональности CLR. F# интенсивно использует .NET-обобщения; например, в самой реализации компилятора F# присутствует более 9000 параметров обобщенных типов.

Но в конечном счете, распознавание типов — это функциональность периода компиляции, и каждая часть кода на F# получает свой (логически определенный) тип, который кодируется в метаданных CLR для F#-сборки.

Вызовы в хвостовой позиции

Неизменяемость и функциональное программирование способствуют использованию в F# для вычислений рекурсии. Например, можно пройти по списку и вычислить сумму квадратов значений в этом списке, используя просто блок рекурсивного кода на F#:

let rec sumOfSquares nums = match nums with | [] -> 0 | n :: rest -> (n*n) + sumOfSquares rest

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

let rec sumOfSquaresAcc nums acc = match nums with | [] -> acc | n :: rest -> sumOfSquaresAcc rest (acc + n*n)

Компилятор F# реализует функции с хвостовой рекурсией (tail-recursive functions), используя два приема, которые гарантируют, что стек не будет разрастаться. Для прямых хвостовых вызовов той же функции, как в вызове sumOfSquaresAcc, компилятор F# автоматически преобразует рекурсивный вызов в цикл while, тем самым избегая вообще всяких вызовов и генерируя код, очень похожий на императивную реализацию той же функции.

Однако хвостовая рекурсия не всегда столь проста и может быть результатом множества взаимно рекурсивных функций. В этом случае компилятор F# опирается на встроенную в CLR поддержку вызовов в хвостовой позиции (хвостовых вызовов).

В CLR есть IL-инструкция, предназначенная специально для поддержки хвостовой рекурсии: tail. -префикс. Инструкция tail. сообщает CLR, что она может отбросить состояние метода вызвавшего кода до выполнения связанного вызова. То есть при приеме этого вызова стек не будет увеличиваться. Это также означает, что, по крайней мере в принципе, JIT-компилятор сможет эффективно выполнить вызов, используя лишь инструкцию перехода. Это очень удобно для F# и гарантирует безопасность хвостовой рекурсии почти во всех случаях:

IL_0009: tail.IL_000b: call bool Program/SixThirtyEight::odd(int32)IL_0010: ret

Для обработки хвостовых вызовов в CLR 4.0 было внесено несколько важных усовершенствований. Версия x64 JIT ранее реализовала хвостовые вызовы очень эффективно, но этот вариант не годился для всех случаев, где появлялась инструкция tail. Это означало, что какой-то F#-код, успешно выполняемый на платформах x86, приводил бы к переполнению стека на платформах x64. В CLR 4.0 эффективная реализация хвостовых вызовов в x64 JIT была распространена на более широкий круг ситуаций, а также реализован механизм с более высокими издержками, необходимый для аналогичной поддержки хвостовых вызовов в x86 JIT.

Детальное описание усовершенствований в CLR 4.0, касающихся хвостовых вызовов, см. в блоге CLR Code Generation ((blogs.msdn.com/clrcodegeneration/archive/2009/05/11/tail-call-improvements-in-net-framework-4.aspx).

F# Interactive

F# Interactive — утилита командной строки и окно в Visual Studio для интерактивного выполнения F#-кода (рис. 1). Эта утилита позволяет экспериментировать с данными, изучать API и проверять логику приложения на F#. F# Interactive базируется на CLR Reflection.Emit API. Этот API дает возможность программе генерировать новые типы и члены в период выполнения, а также динамически вызывать этот код. F# Interactive использует компилятор F# для компиляции кода, вводимого в строке приглашения, а затем с помощью Reflection.Emit генерирует типы, функции и члены, не записывая сборку на диск.

Рис. 1. Выполнение кода в F# Interactive

Одно из важнейших последствий такого подхода в том, что выполняемый пользовательский код не интерпретируется, а полностью транслируется обычным компилятором и обрабатывается JIT-компилятором с применением всех полезных оптимизаций на обоих этих этапах. Это делает F# Interactive великолепной высокопроизводительной средой для апробации новых подходов к решению каких-либо задач и интерактивного исследования больших наборов данных.

Tuple-типы

Tuple-типы в F# обеспечивают простой способ упаковки данных и их передачи блоком, избавляя от необходимости определять новые собственные типы или использовать сложные схемы параметров, например набор выходных параметров для возврата нескольких значений:

let printPersonData (name, age) = printfn “%s is %d years old” name agelet bob = (”Bob”, 34)printPersonData boblet divMod n m = n / m, n % mlet d,m = divMod 10 3

Это простые типы, но у них есть несколько важных свойств в F#. Самое главное — они неизменяемые. После конструирования модифицировать элементы tuple нельзя. Это позволяет безопасно обрабатывать tuple-типы просто как комбинацию их элементов. А также обеспечивает поддержку другой важной особенности tuple-типов: структурной эквивалентности (structural equality). Tuple-типы и другие F#-типы, в частности списки, пользовательские записи и объединения, можно сравнивать на эквивалентность сравнением их элементов.

В .NET Framework 4 tuple-типы теперь являются базовым типом данных, определенным в библиотеке базовых классов. При ориентации на .NET Framework 4 для представления соответствующих значений в F# используется тип System.Tuple. Поддержка этого основополагающего типа в mscorlib означает, что программисты на F# могут использовать tuple-типы в сочетании с кодом на C# и наоборот.

Хотя tuple-типы концептуально являются простыми, при проектировании в тип System.Tuple было заложено много интересных решений. Мэтт Эллис (Matt Ellis) подробно описывал процесс проектирования Tuple в одном из недавних выпусков рубрики «CLR с изнанки» (msdn.microsoft.com/magazine/dd942829).

Оптимизации

Поскольку F#-код не столь прямо транслируется в инструкции CLR, у компилятора F# более широкие возможности для оптимизаций, чем у CLR JIT-компилятора. Компилятор F# использует преимущества этого и реализует более глубокие оптимизации в режиме Release по сравнению с компиляторами C# и Visual Basic.

Один из простых примеров — исключение промежуточного tuple-объекта. Tuple-объекты часто используются для структурирования обрабатываемых данных. По этой причине широко распространена практика их создания и последующего уничтожения в рамках одной функции. А раз так, то выполняется лишняя операция создания tuple-объекта. Поскольку компилятору F# известно, что создание и уничтожение tuple-объекта не дает значимых побочных эффектов, он стремится избежать создания этого промежуточного tuple-объекта.

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

let getValueIfBothAreSame x y = match (x,y) with | (Some a, Some b) when a = b -> Some a |_ -> NoneЕдиницы мер

Единицы мер вроде метров и секунд, широко используемые в науке, инженерной деятельности и моделировании, по сути являются системой типов для работы с числовыми количествами. В F# единицы мер введены непосредственно в систему типов языка, поэтому числовые количества можно обозначать своими единицами. Эти единицы учитываются при вычислениях, и, если они не совпадают, сообщается об ошибках. В следующем примере попытка сложить килограммы с секундами дает ошибку, хотя поделить килограммы на секунды можно без проблем:

[<Measure>] type kg/// Seconds[<Measure>] type slet x = 3.0<kg>//val x : float<kg>let y = 2.5<s>// val y : float<s>let z = x / y//val z : float<kg/s>let w = x + y// Error: “The unit of measure 's'// does not match the unit of measure 'kg'”

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

Однако единицы мер, хоть и являются частью системы типов F#, в период компиляции удаляются. То есть в конечной .NET-сборке никакой информации о единицах мер не будет, и CLR будет оперировать всеми значениями, исходя из их нижележащих типов, а значит, никаких издержек не создается. Как видите, эта картина противоположна той, которая наблюдается в случае .NET-обобщений; последние полностью доступны в период выполнения.

Если впоследствии поддержка единиц мер будет интегрирована в базовую систему типов CLR, F# сможет предоставлять информацию о единицах мер, и она будет видна из других .NET-языков программирования.

Заключение

Как вы убедились, F# — это выразительный, функциональный, объектно-ориентированный и исследовательский язык программирования для .NET Framework. Он интегрирован в Visual Studio 2010 и включает утилиту F# Interactive, позволяющую напрямую экспериментировать с кодом на этом языке.

Язык и всего его инструментальные средства используют весь спектр возможностей CLR и добавляют некоторые концепции более высокого уровня, которые проецируются на метаданные и IL-код CLR. Но в конечном счете F# — это просто еще один .NET-язык, и его можно легко включать как компонент в новые или существующие .NET-проекты благодаря общей системе типов и одной исполняющей среде.

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

Перед применением изменений можно сделать моментальный снимок виртуальной машины, и если эти изменения вызвали проблему, можно откатить их. Можно выполнять резервное копирование и восстановление на различном оборудовании путем просто экспорта или импорта виртуальной машины в любую систему с поддержкой Hyper-V. Можно обеспечить избыточность путем кластеризации виртуальных узлов.

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

В данной статье я рассмотрю эти и другие проблемы, с которыми вы встретитесь при развертывании виртуальной среды (дополнительные сведения приведены в руководствах по созданию, архитектуре и развертыванию). Существуют некоторые практические рекомендации по подготовке к использованию виртуализации и Hyper-V. Они помогут повысить эффективность использования виртуализации, одновременно снижая риски.

Мгновенная инфраструктура

Виртуализация вызвала изменение парадигмы. Заказ, установка стоек, обеспечение питания, создание сети и настройка занимали несколько недель, а иногда даже месяцев. Теперь все это можно выполнить, щелкнув правой кнопкой мыши машину в программе System Center Virtual Machine Manager (VMM), выбрав «template» (шаблон), а затем «deploy» (развертывание).

После это все основные действия, по сути, уже выполнены. Путем создания шаблона вы получаете виртуальную машину, обработанную с помощью средства Sysprep, которая основа на определенных требованиях, включена в домен и готова к запуску в течение 30 минут или менее при использовании технологии копирования на базе сети SAN вместе с VMM. Она определяет виртуальные узлы с наибольшей емкостью, а затем размещает на них виртуальные машины. Хотя это может показаться простым, виртуализация – это просто служба «под ключ», не требующая особой настройки.

Еще до перехода к оборудованию первым вопросом будет «имеется ли на это лицензия?» Хотя подробный обзор лицензирования выходит далеко за пределы данной статьи, я представлю краткий обзор. С официальной позицией можно ознакомиться в документе Права на использование продуктов Майкрософт.

Windows Server 2008 Standard Edition позволяет использовать одну виртуальную машину для каждой лицензии. Одна лицензия Enterprise Edition позволяет использовать до четырех виртуальных машин. Выпуск Datacenter Edition позволяет использовать неограниченное количество виртуальных машин и предназначается для одного физического процессора (не ядра).

Если вы приобрели лицензии Windows Server вместе с оборудованием и имеете версии OEM, с этого оборудования нельзя перенести ОС, она работает на нем и прекратит работу тоже на нем. Если лицензия приобретена через один из каналов корпоративного лицензирования или у посредника для крупных клиентов, лицензию можно менять раз 90 дней или в случае сбоя оборудования.

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

Datacenter Edition — это самый дорогой способ приобретения Windows при запуске более трех или четырех виртуальных машин на одном физическом процессоре. Также рекомендуется серьезно рассмотреть использование программы Windows Software Assurance. После выпуска следующей версии Windows, даже если планируется установка всего одной копии и ее перенос в кластере, потребуется одна лицензия для каждого узла.

Продукты System Center доступны в версиях Enterprise и Datacenter Suit. Можно защитить права на использование всего стека System Center с неограниченным числом виртуальных машин. Умножьте количество виртуальных машин на узле на количество отдельных лицензий System Center Management, необходимых для виртуальной машины, плюс стоимость узла за вычетом стоимости соответствующего пакета управления.

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

Преобразование в виртуальные машины

При преобразовании физических машин в виртуальные с помощью VMM или при создании новой среды такие преобразования можно выполнить с помощью Operations Manager или бесплатного набора средств Microsoft Assessment and Planning (MAP) Toolkit. Это помогает в сборе и анализе данных производительности потенциальных кандидатов для виртуализации.

Теперь рассмотрим оборудование. Выбранное оборудование должно иметь возможность работы с суммарной рабочей нагрузкой на пиковом уровне. Поэтому при наличии рабочей нагрузки, использующей двуядерный процессор с частотой 2 ГГц и средним коэффициентом загрузки 80 от пиковой, и другой рабочей нагрузки, использующей этот же процессор с загрузкой 50 процентов от пиковой, необходимо обеспечить, чтобы мощность системы составляла не менее 150 процентов.

Также можно использовать двуядерный процессор с частотой 3 ГГц для обеспечения некоторого увеличения затрат ресурсов (в данном случае приблизительно 10 процентов) для работы физического узла. Хотя обычно процесс не является ограничивающим фактором. Большинство рабочих процессов имеют низкую среднюю загрузку ЦП.

Самые большие препятствия виртуализации рабочих нагрузок, — это, в убывающем порядке, дисковые операции ввода-вывода, ОЗУ, сетевой ввод-вывод и, наконец, ЦП. Увеличение скорости ЦП и количества ядер продолжают соответствовать требованиям закона Мура об увеличивающейся мощности или превышают их. Цены на ОЗУ RAM продолжают снижаться с увеличением плотности.

Однако объем дисков со временем значительно увеличился. Дисковый ввод-вывод по-прежнему имеет довольно высокую цену. При стремлении к максимальной емкости вы потеряете шпиндели и общую скорость. Необходимо тщательно рассмотреть дисковые операции ввода-вывода рабочих процессов.

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

По сути, лучше использовать большее количество физических шпинделей. Для кластера следует уделить внимание оптимизации диска на базе сети SAN для обеспечения оптимальной производительности записи, выделенных каналов связи и шпинделей для рабочих процессов виртуализации. Использование нескольких путей также должно помочь. Наконец, необходимо разделять и сегментировать физические диски (не разделы), чтобы рабочие процессы с интенсивным вводом-выводом не влияли на менее интенсивные процессы.

Также известны проблемы способа настройки жестких дисков виртуальных машин. Можно использовать динамически расширяемые виртуальные жесткие диски (VHD), фиксированные VHD, сквозные или собственные iSCSI непосредственно с гостевой виртуальной машины. Поддерживаются все эти конфигурации.

Основные рекомендации довольно просты. Используйте VHD кроме случаев, если совершенно необходим непосредственный доступ к диску для определенных возможностей SAN. К ним относится резервное копирование с поддержкой приложений на основе SAN и кластеризация «гость – гость» через iSCSI.

Фиксированные VHD имеют большую производительность, чем динамически расширяемые VHD. Фактически, их производительность почти равна производительности физических дисков. Кроме того, можно использовать сочетание конфигураций. Опять же, наилучшее решение основывается на рабочих процессах. Более подробные сведения приведены в следующем документе о производительности VHD.

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

Последнее замечание по поводу дискового пространства для хранения — разумная оценка пространства для мгновенных снимков. Потребуется запланировать приблизительно от 20 до 30 процентов дополнительных ресурсов в зависимости от частоты и количества мгновенных снимков, которые планируется использовать.

Максимальный объем памяти

Необходимый размер ОЗУ довольно просто вычислить. К общему размеру ОЗУ для всех рабочих нагрузок необходимо добавить 1 ГБ для узла и дополнительные 20 – 30 МБ для каждой гостевой системы.

В состав Hyper-V с пакетом обновления 1 (SP1) будет входить функция динамического выделения памяти, позволяющая виртуальным машинам высвободить память, не использующуюся на узле. Даже без пакета обновления 1 (SP1) при определении объему ОЗУ, используемого рабочими нагрузками, доступно множество возможностей для оптимизации.

Виртуализация также позволяет установить доступный рабочим процессам объем ОЗУ в зависимости от потребности, а не фактического размера модулей памяти. Например, можно создать виртуальную машину с объемом ОЗУ 600 МБ, тогда как обычно вы ограничены физическими размерами модулей ОЗУ и парными каналами. Единственное ограничение — размер памяти должен быть четным числом.

System Center Operations Manager (SCOM) позволяет просмотреть исторические данные производительности в гостевой системе и настроить необходимый объем ОЗУ. Динамически расширяемая память в Hyper-V for Windows 2008 R2 с пакетом обновления 1 (SP1) уменьшит необходимость в этом уровне наблюдения и управления. Пока же можно обеспечить значительную консолидацию путем изучения этих сведений динамической памяти для каждой виртуальной машины.

Главная задача сетевого ввода-вывода — наличие достаточного числа портов и пропускной способности для рабочих процессов. Внутренний коммутатор виртуальной машины поддерживает высокую пропускную способность, но только при настройке профилей оборудования виртуальной машины с синтетической сетей интерфейсной платой (NIC). Устаревшие платы NIC ограничены размером 100 МБ. При наличии устаревших NIC в первоначальном развертывании, возможно, потребуется удалить и перенастроить их. Используйте синтетическую NIC, если это поддерживается базовой ОС гостевой системы.

Для гостевых машин, кластеризованных вместе с iSCSI, для кластеризации выделите две NIC с Microsoft Multipath IO в конфигурации балансировки нагрузки только для iSCS. Их можно использовать для периодической связи при их обработке нагрузки iSCSI. Установите другую выделенную NIC для управления узлами, а оставшаяся используется для виртуальных машин.

Обычно, если материнская плата оснащена двумя платами NIC, будет полезна дополнительная плата NIC с четырьмя портами. Большее количество портов рекомендуется при виртуальных машин с рабочими нагрузками с интенсивным использованием сети, такими как развертывание ОС или файловый сервер с высокой загрузкой. Все платы NIC должны иметь производительность 10 ГБ.

Лучшее резервное копирование

Для резервного копирования System Center Data Protection Manager (DPM) выполняет немалую работу, предоставляя возможность резервного копирования с поддержкой Hyper-V. Также предусмотрено резервное копирование для определенных приложений. У резервного копирования всей виртуальной машины и определенных приложений есть свои плюсы и минусы. Одна из новых возможностей DPM 2010 — возможность смонтировать VHD и выполнить восстановление отдельного файла непосредственно из резервной копии виртуальной машины.

Оцените потребности приложений индивидуально. Отличный пример — SharePoint: Если необходимо восстановить документ из библиотеки документов, используя только резервные копии виртуальных машин, необходимо восстановить SQL Server, серверы клиентского доступа и контроллер домена в частной сети. Следующий шаг — просмотр библиотеки и поиск файла. При наличии резервной копии приложения SharePoint можно просто восстановить библиотеку документов на другом сайте, а затем перенести файл.

При наличии SCOM рекомендуется реализовать оптимизацию производительности и ресурсов (PRO). PRO позволяет SCOM наблюдать за рабочими нагрузками на уровнях узла и отдельных приложений. Также можно автоматически устранять распространенные проблемы, такие как перенос виртуальной машины с узла, на котором скорость вентилятора ЦП недостаточна, или превышение требований рабочих нагрузок возможностей узла. Дополнительные сведения доступны в руководстве по интеграции SCOM и VMM.

Также существуют некоторые проблемы виртуализации контроллеров домена. По сути, никогда не требуется восстановление каких-либо мгновенных снимков или резервных копий контроллера домена. Доступно хорошее применимое руководство, в котором содержатся сведения о виртуализации контроллера домена.

Виртуализация и Hyper-V — мощные технологии, которые позволяют максимально использовать ресурсы, упростить управление и снизить расходы на ИТ. Сделайте домашнее задание перед развертыванием виртуальной инфраструктуры, и вы сможете избежать проблем в будущем.

Материалы по теме:Виртуализация: 10 самых популярных советов по виртуализацииВиртуализация рабочего стола: Как вырастить здоровую виртуальную средуТехнология Hyper-V и службы удаленных рабочих столов для недорогих виртуальных компьютеров

Совсем недавно состоялся анонс державшегося в тайне нового интерфейса Opera – Featherweight, а сегодня состоялся релиз новой версии браузера. Opera 11.50 не только содержит массу нововведений, но и кардинально изменил внешность.

Интерфейс стал более светлым и лёгким. Изменена цветовая гамма, перерисованы кнопки, разработчики постарались сделать интерфейс более компактным и удобным. В результате он стал чем-то напоминать Firefox…

Увеличить рисунок

Второе серьёзное обновление касается экспресс-панели. Ранее она служила только для быстрого доступа к набору веб-сайтов. Такая экспресс-панель есть в Google Chrome, с помощью расширения её легко можно установить в Firefox. Но теперь для экспресс-панели Opera появились свои специальные расширения. В тех же рамках, что предназначены для вывода изображений сайтов, можно выводить динамически изменяющуюся информацию. Первое, что приходит на ум, это трансляция текущего времени и погоды.

Подверглась улучшениям и другая популярная функция Opera. Opera Link научилась синхронизировать пароли.

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

Увеличить рисунок

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

Opera 11.50 доступен для Windows, Mac OS X и Linux. скачать его можно с этой страницы.

Поднимите руку, если вас не волнует снижение затрат на ИТ-инфраструктуру. А может быть, вы не заботитесь об окружающей среде? Немногие подняли руки, но даже если сокращения выбросов парниковых газов нет в списке ваших приоритетов, они идут рука об руку. Эффективность — ключ к снижению расходов, и выбросов парниковых газов, когда дел касается ИТ.

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

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

Понимание преимуществ

Технология преимуществ имеет множество преимуществ и ряд способов воздействия на расходы и энергопотребление.

Консолидация. Физические аспекты ИТ-инфраструктуры, серверное оборудование, хранилище, сетевые подключения и потребление питания, — это все затраты. Виртуализация довольно просто позволяет увеличить производительность с меньшими усилиями. Можно консолидировать рабочие нагрузки, для каждой из которых ранее требовалось собственное серверное оборудование, в виртуальные машины, работающие на меньшем количестве физических машин. Вы устраняете необходимость в приобретении, управлении, обслуживании и питании этих компьютеров. Чем меньше имеется компьютеров, тем меньше расходы на них.

Масштабируемость. Планирование пиковых рабочих нагрузок — одна из самых распространенных причин сохранения больших возможностей, чем обычно требуется. Это означает увеличение оборудование, программного обеспечения и других ресурсов. Например, для продавца необходимо планировать скачок в трафике транзакций в течение праздников. Можно потратить неиспользованные ресурсы за год, просто чтобы быть готовым к случайному скачку. Перенос инфраструктуры и приложений на виртуальные машины позволяет быстро добавлять и выделять дополнительные ресурсы, когда они требуются, и их не требуется сохранять целый год.

Надежность. Простой, вызван ли он аппаратным сбоем, человеческой ошибкой или отключением питания, стоит денег. Виртуальные серверы – это исключительно программные объекты, поэтому их в случае необходимости можно просто и эффективно перенести на другое физическое оборудование. В этом помогают такие функции, как динамический перенос(дополнительные сведения о динамическом переносе приведены в документе «Обзор и архитектура динамического переноса Hyper-V»).

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

Основы виртуализированного центра обработки данных

Основа виртуального центра обработки данных — Microsoft Windows Server 2008 R2 с серверами Hyper-V Host под управлением Windows Server 2008 R2 с технологией Hyper-V. Таким образом бизнес-службы и приложения размещаются на виртуальных «гостевых» машинах.

Консолидация нескольких ролей серверов в виртуальную среду, работающую на одном физическом компьютере, позволяет более эффективно использовать оборудование. Это также разблокирует потенциальные преимущества, такие как возможность быстрого масштабирования инфраструктуры, добавления виртуальных ресурсов для новых рабочих нагрузок или продолжения работы во время запланированного или даже непредвиденного обслуживания. Подробные сведения о настройке Microsoft Windows Server 2008 R2 с Hyper-V приведены в руководстве по началу работы с Hyper-V.

Основное средство для управления динамическими центрами обработки данных на основе технологии Hyper-V — это System Center Virtual Machine Manager (VMM). VMM применяется для широкого ряда виртуальных сред, от одного сервера до полностью распределенных корпоративных сред с сотнями узлов, на которых работают тысячи виртуальных машин.

Управление виртуальной инфраструктурой с помощью VMM имеет множество преимуществ, включая следующие.

Поддержка виртуализации для виртуальных машин под управлением Windows Server 2008 Hyper-V, Microsoft Virtual Server и VMware ESX.Полная поддержка консолидации физических серверов в виртуальную инфраструктуру.Оптимизация производительности и ресурсов (PRO) для динамического и оперативного управления виртуальной инфраструктурой (требуется System Center Operations Manager).Оптимальное размещение (Intelligent Placement) виртуальных рабочих нагрузок на наиболее подходящих физических серверах.Исчерпывающая библиотека для централизованного управления всеми стандартными блоками виртуального центра обработки данных.

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

Например, мастер преобразования P2V, входящий в состав VMM, упрощает процесс преобразования существующих физических рабочих нагрузок в виртуальные машины. При использовании вместе с SCOM функция PRO обеспечивает динамическое виртуальное перераспределение рабочих нагрузок для обеспечения максимального использования ресурсов физического оборудования.

VMM также позволяет обслуживать библиотеку управляемых виртуальных машин. Это позволяет при необходимости быстро разворачивать новые экземпляры виртуальной ОС. В этой библиотеке можно хранить шаблоны сервера, уже настроенные для основных приложений и служб.

ПО мере увеличения рабочей нагрузки можно использовать эти шаблоны для мгновенного развертывания нового экземпляра необходимой службы. Для шаблонов можно назначать детализированные разрешения, также можно делегировать управление шаблонами. Подробные инструкции по установке и настройке System Center Virtual Machine Manager 2008 R2 приведены в руководстве по развертыванию Virtual Machine Manager.

Портал самообслуживания SCVMM 2008 R2 Self-Service Portal 2.0

VMM имеет веб-портал самообслуживания (под названием VMMSSP), на котором авторизованные пользователи могут создавать новые виртуальные серверы на основе ваших шаблонов. Вы контролируете пользователей, которые могут использовать этот портал, и вы можете позволить другим ИТ-специалистам или сотрудникам других отделов при необходимости подготавливать новые машины.

VMMSSP позволяет делегировать задачи для большей экономической эффективности. Подразделения организации могут управлять собственными ИТ-потребностями, а централизованная инфраструктура управляет пулом физических ресурсов (серверов, сетей и соответствующего оборудования). Это позволяет при необходимости предоставлять службы локально и освобождает вас от выполнения задач уровня рабочей группы.

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

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

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

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

Дополнительные материалы

Доступен ряд инструментов и дополнительных материалов для начала работы. Прежде всего, стоит воспользоваться Microsoft Assessment and Planning (MAP) Toolkit для Hyper-V. MAP позволяет выполнить оценку текущей серверной среды (включая Windows Server и ОС Linux, работающие в виртуальной среде), определить серверы с низкой загрузкой, а затем выполнить оценку кандидатов размещения серверов и виртуализации для реализации Hyper-.

MAP также включает функцию обнаружения VMware, позволяющую определить уже виртуализированные серверы, работающие с VMware, которые могут управляться с помощью платформы Microsoft VM. Эти серверы также необходимо перенести на Windows Server 2008 R2 и Hyper-V.

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

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

Материалы по темеВиртуализация рабочего стола: Как вырастить здоровую виртуальную средуВиртуализация: 10 самых популярных советов по виртуализацииТехнология Hyper-V и службы удаленных рабочих столов для недорогих виртуальных компьютеров

Использование Windows всегда требовало квалификации настоящего кандидата наук в области акронимов. Стоило мне объединить акронимы виртуализации с сокращенными названиями бесплатных средств развертывания Microsoft, и заголовок стал практически нечитабельным.

Но если серьезно, то недавнее слияние технологий виртуализации и развертывания Windows мне нравится. В одном из этих подходов используется Microsoft Enterprise Desktop Virtualization (MED-V) (то есть виртуализация настольных компьютеров на предприятии). Будучи частью Microsoft Desktop Optimization Pack (MDOP — еще один акроним), MED-V обеспечивает на предприятии каркас для развертывания виртуальных персональных компьютеров на физических компьютерах как способа решения проблемы несовместимости приложений.

MED-V «устраняет» несовместимость, выполняя не поддерживающие MED-V приложения на виртуальной машине с Windows XP. Экран и пользовательский интерфейс несовместимого приложения незаметно для пользователя переносится с виртуальной машины с Windows XP на компьютер под управлением Windows 7. Пользователь видит только приложение, которое запускается и работает в Windows 7, а вы как администратор теперь отвечаете за управление двумя операционными системами у пользователя.

Заглавная «E»

Заглавная буква «E» (Enterprise, то есть «предприятие») в акрониме MED-V оправдывает свое наличие — виртуализация MED-V хорошо подходит для корпоративной среды. Она приносит такие необходимые возможности администрирования в масштабах всего предприятия с крупной средой. Однако за все надо платить — как стоимостью лицензий на ПО, так и усилиями, необходимыми для интеграции MED-V в существующую среду.

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

Для таких, более простых случаев есть средство Microsoft P2V Migration for Software Assurance, которое можно загрузить с Центра загрузок Microsoft. Оно решает проблему несовместимости приложений тем же методом, что и MED-V, но без сложной архитектуры MED-V. Оно просто добавляет определенную функциональность в набор средств развертывания Microsoft (Microsoft Deployment Toolkit, MDT).

Эта функциональность позволяет виртуализовать Windows XP в момент его обновления до Windows 7. После этого виртуализованный компьютер с Windows XP и всеми приложениями работает внутри компьютера с Windows 7. Однако есть одно ключевое различие: управление экземпляром Windows XP вместе со всеми политиками, приложениями и конфигурациями должно выполняться другими инструментальными средствами.

MDT, P2V и последовательности заданий

Если заголовок звучит непонятно, вернемся на минутку к основам MDT. Набор средств развертывания MDT служит для создания последовательности заданий для обновления или реновации ОС. Последовательности заданий MDT представляют собой ряд шагов с изменяемой конфигурацией, которые автоматизируют все процессы, из которых состоит установка Windows. На рис. 1 показаны примеры поддерживаемых MDT видов последовательностей заданий.

Рис. 1. Последовательность заданий в MDT

Есть две обычно используемых последовательности заданий: Standard Client Task Sequence и Standard Client Replace Task Sequence:

Standard Client Task Sequence развертывает ОС на настольном компьютере, находящихся в режиме ожидания. Обычно это задание применяется для обновления компьютера с одной версии ОС до более новой.Standard Client Replace Task Sequence похоже на предыдущее задание, но применяется для «реновации» существующей ОС.

В зависимости от настройки MDT и порядка выполнения каждой последовательности, вы можете использовать одну или обе последовательности для записи информации о состоянии пользователя. Эта информация нужна для внедрения в обновленную ОС после ее установки.

Последовательности заданий отлично справляются с информацией о состоянии пользователей, но не решают проблему совместимости приложений — это автоматизируется с помощью P2V Migration for Software Assurance. Этот компонент автоматически создает копию существующего компьютера под управлением непосредственно перед его обновлением до Windows 7, а затем преобразует ее в файл виртуального жесткого диска (VHD), используя P2V-процесс (Physical-to-Virtual).

После обновления компьютера P2V Migration for Software Assurance устанавливает полученную виртуальную машину на компьютере с Windows 7 и добавляет ее приложения к меню Пуск (Start) этой ОС, после чего устанавливает на физическом компьютере Virtual PC для Windows 7, чтобы можно было запускать виртуальную машину.

Инструмент P2V Migration Tool практически полностью автоматизирует этот процесс. В конечном результате мы получаем две независимые операционные системы (Windows XP и Windows 7), работающие на настольном компьютере.

Начинаем P2V-миграцию

Чтобы увидеть показанные на рис. 1 относящиеся к P2V последовательности заданий, нужно кое-что установить. Сначала надо установить P2V Migration for Software Assurance на сервер MDT. Это добавит несколько пакетов обновления, которые в конечном итоге будут установлены на настольным компьютерах, когда те получат новую ОС. Эти обновления добавят в Windows 7 поддержку Virtual PC и обновят экземпляр Windows XP для поддержки RemoteApps — службы удаленного рабочего стола, обеспечивающей передачу приложений Windows XP в Windows 7.

Теперь при попытке создать новую последовательность заданий вы увидите в списке две новых последовательности заданий: Standard Client Task Sequence with P2V Migration и Standard Client Replace Task Sequence with P2V Migration. Ясно, что они связаны с ранее упомянутыми последовательностями с той разницей, что в каждую последовательность обновления добавлен этап P2V в последовательность обновления.

Чтобы воспользоваться одной из этих последовательностей, надо создать новую последовательность задач. Если вы уже настроили на своем сервере MDT хотя бы один образ, выберите Task Sequence/New Task Sequence. На первой странице мастера введите идентификатор и название последовательности заданий. На странице выбора шаблона выберите Standard Client Task Sequence with P2V Migration.

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

Последовательность P2V-заданий запускается, как в обычной ОС Windows. На компьютере с Windows XP перейдите к подпапке Scripts в общей папке развертывания MDT. Двойным щелчком запустите сценарий Litetouch.vbs script. В процессе выполнения сценария надо указать последовательность заданий, которая будет выполняться на компьютере. Выберите P2V Task Sequence и ответьте на остальные вопросы, чтобы запустить процесс.

Какие возможности недоступны

Не следует ожидать, что в решении, не предназначенном для использования в организациях, присутствуют все возможные функции. Именно так дело обстоит с P2V Migration for Software Assurance. Прежде чем использовать это решение, узнайте о его ограничениях.

Во-первых, Microsoft предоставляет этот инструмент только для небольших сред. Джереми Чепман (Jeremy Chapman) подчеркивает этот тезис в своем замечательном блоге post (http://www.ConcentratedTech.com/DeploymentHub). Надо не забывать, что виртуализованная система остается в вашей среде даже после обновления всех компьютеров до Windows 7. Выбрав путь P2V, вы будете вынуждены обслуживать эти неподдерживаемые системы, хотя ваш план был избавиться от них.

Принимая решение о P2V-миграции, познакомьтесь в набором инструментов для оценки совместимости Microsoft Application Compatibility Toolkit (ACT). В ACT для «починки» несовместимых приложений используется набор программных оболочек (shims). Поначалу с этими оболочками придется повозиться, но затраченные усилия вернуться сторицей, так как исправленные приложения работают в среде Windows 7, а не на виртуальной машине с Windows XP.

В Virtual PC (а это приложение для Windows 7), где выполняются все виртуальные машины с Windows XP, также есть жесткий предел на размер VHD-дисков этих машин: не больше 127 ГБ. Поэтому все диски большего размера автоматически не заработают. Это может создать большие проблемы, если у ваших компьютеров под управлением Windows XP большие диски.

Лицензирование и активация Windows также могут стать проблемой. Хотя название программы и содержит «for Software Assurance», ее возможности выходят за пределы клиетского соглашения Software Assurance — она позволяет использовать любой экземпляр Windows, который официально виртуализован по механизму P2V ее средствами.

Однако полная автоматизация доступна только в операционных системах с корпоративной лицензией (volume license). В других после P2V-миграции придется как минимум вручную повторно активировать лицензию. Есть и другие ограничения и известные проблемы — они описаны в документации к программе.

Больше акронимов, больше функциональности

Несмотря на все ограничения и дополнительные акронимы, P2V Migration for Software Assurance — полезное добавление в арсенал «компьютерщика на все руки». Это далеко не такой многофункциональный продукт, как решение виртуализации предприятия MED-V, но в этом и его сила. Он прост в загрузке, установке и работе — благодаря этому с его помощью можно быстро решить проблему несовместимости приложений, которая может поставить под угрозу весь проект обновления до Windows 7.

Вы должны помнить, что при P2V-миграции старых компьютеров с Windows XP они сохранятся в среде. Используйте этот инструмент только в исключительных случаях, но держите его всегда наготове.

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

Впервые праздник «День системного администратора» отмечался 28 июля 1999 года. Он представлял собой небольшой пикник на природе в пригороде Чикаго. В нем участвовали члены небольшой компьютерной фирмы. Очень быстро этот праздник завоевал популярность и приобрел широкие масштабы.

В нашей стране День системного администратора получает все большую известность. Так, к примеру, ежегодно под Калугой с 2006 года начали проводить Всероссийский слет системных администраторов. На это мероприятие с каждым годом приезжает все большее количество участников.

В этом году Фестиваль, приуроченный к празднованию "Дня Системного Администратора", состоится с 29 по 31 июля 2011 года в Предгорном районе Ставропольского края у подножия горы Верблюд (см. место проведения).

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

Цель Фестиваля — академический отдых и неформальное общение на профессиональные темы, объединяющее людей, интересы которых связаны с информационными технологиями. Это прекрасная возможность собраться в палатках на природе и обменяться опытом с коллегами, наладить личные контакты между специалистами, обсудить перспективы развития программного обеспечения, инициировать новые проекты, а также поучаствовать в спортивных турнирах и профессиональных конкурсах, тематических "круглых столах" и просто отлично провести время.

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

Все подробности на http://sysadminday.ru. Сферическую флеш-панораму места проведения можно посмотреть здесь (очень красивая местность).

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

Впервые праздник «День системного администратора» отмечался 28 июля 1999 года. Он представлял собой небольшой пикник на природе в пригороде Чикаго. В нем участвовали члены небольшой компьютерной фирмы. Очень быстро этот праздник завоевал популярность и приобрел широкие масштабы.

В нашей стране День системного администратора получает все большую известность. Так, к примеру, ежегодно под Калугой с 2006 года начали проводить Всероссийский слет системных администраторов. На это мероприятие с каждым годом приезжает все большее количество участников.

В этом году Фестиваль, приуроченный к празднованию "Дня Системного Администратора", состоится с 29 по 31 июля 2011 года в Предгорном районе Ставропольского края у подножия горы Верблюд (см. место проведения).

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

Цель Фестиваля — академический отдых и неформальное общение на профессиональные темы, объединяющее людей, интересы которых связаны с информационными технологиями. Это прекрасная возможность собраться в палатках на природе и обменяться опытом с коллегами, наладить личные контакты между специалистами, обсудить перспективы развития программного обеспечения, инициировать новые проекты, а также поучаствовать в спортивных турнирах и профессиональных конкурсах, тематических "круглых столах" и просто отлично провести время.

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

Все подробности на http://sysadminday.ru. Сферическую флеш-панораму места проведения можно посмотреть здесь (очень красивая местность).

В следующем году AMD планирует уделить значительное внимание рынку планшетных компьютеров. Компания представит новую платформу с энергопотреблением, ниже чем у нынешних процессоров AMD для планшетных компьютеров, известную под именем Brazos-T.

Судя по слайдам, представленным на сайте Donanim Haber, новая платформа будет включать в себя APU Hondo и набор системной логики Hudson M2T FCH. Оба чипа будут обладать скромным энергопотреблением по сравнению с нынешними APU Desna и Hudson M1 FCH. Для этого компании пришлось перестроить свои APU Ontario, избавившись от функций, неиспользуемых в планшетах. К ним относятся 4 линии PCI Express, которые изначально были предназначены для использования с отдельными видеокартами, и видеовыход VGA.

Результатом стало то, что процессоры Hondo будут иметь энергопотребление ниже 4,5 Вт, что на четверть меньше чем 5,9 Вт у Desna Z-01. При этом он также будет обладать двумя процессорными ядрами Bobcat с частотой 1 ГГц и встроенным графическим ядром Radeon HD 6250 276 МГц с поддержкой Full HD.

Для дальнейшего снижения энергопотребления компания модифицировала чипсет Hudson M1. Здесь также были удалены невостребованные функции, однако при этом чип получил ряд новых характеристик, например Always On и Always Connected (AOAC) Wi-Fi. Благодаря этому, чипсет Hudson M2T потребляет около 1 Вт при уменьшенных до 19х19 мм размерах.

Первые образцы APU Hondo должны появиться в декабре 2011 года, а производство начнётся во втором квартале 2012 года.

В предыдущей части этого цикла мы начали процесс настройки стандартного пользовательского профиля в Windows 7. На данный момент мы выполнили следующие шаги:

Создание последовательности задач для развертывания эталонной сборкиСоздание последовательности задач для системной подготовки Sysprep и создания снимка эталонной сборкиНастройка эталонной сборки с помощью файла Unattend.xmlРазвертывание и проверка частично настроенной эталонной сборкиДальнейшая настройка эталонной сборки вручнуюПодготовка Sysprep и создание снимка полностью настроенной эталонной сборки

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

Проверка всех настроек, выполненных для стандартного пользовательского профиля

Для выполнения этого заключительного шага нам нужно выполнить следующие пять задач:

Импортировать наш снимок образа в среду Deployment WorkbenchСоздать новую последовательность задач для развёртывания импортированного образа. Эта новая последовательность задач будет строиться на базе шаблона Standard Client Task SequenceИзменить Unattend.xml файл для этой новой последовательности задач так, чтобы параметр CopyProfile имел значение TrueРазвернуть снимок на целевую систему с помощью новой последовательности задачСоздать новую учетную запись локального пользователя на целевой системе и проверить, были ли десять выполненных нами настроек успешно применены к стандартному пользовательскому профилю, с которого создается новая учетная запись локального пользователяИмпорт снимка образа в среду Deployment Workbench

Начнем с импорта нашего подготовленного в sysprep и настроенного снимка образа ОС Windows 7 в MDT 2010 Deployment Workbench. Чтобы логически отделить импортированные образы от других образов ОС, я создал подпапку под названием Customized_Images в папке Operating Systems своего установочного ресурса. Затем нажимаем правой клавишей на Customized_Images и выбираем опцию импорта ОС (Import Operating System):

Рисунок 1: 1 шаг импорта образа подготовленной и настроенной ОС в Deployment Workbench.

На странице типа ОС (OS Type) мастера импорта операционных систем (Import Operating System Wizard) выбираем опцию пользовательского образа (Custom Image):

Рисунок 2: 2 шаг импорта образа подготовленной и настроенной ОС в Deployment Workbench.

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

Рисунок 3: 3 шаг импорта образа подготовленной и настроенной ОС в Deployment Workbench.

Оставьте первую опцию выбранной на странице установки (Setup):

Рисунок 4: шаг импорта образа подготовленной и настроенной ОС в Deployment Workbench.

Мы примем предлагаемое мастером имя целевого каталога, который будет создан для хранения этого образа:

Рисунок 5: 5 шаг импорта образа подготовленной и настроенной ОС в Deployment Workbench.

Нажимаем Далее, чтобы начать процесс импорта:

Рисунок 6: 6 шаг импорта образа подготовленной и настроенной ОС в Deployment Workbench.

По окончании процесса импорта вы должны увидеть импортированный образ в папке Customized_Images, как показано на рисунке ниже:

Рисунок 7: Созданный, подготовленный в sysprep и настроенный образ ОС Windows 7 импортирован.

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

Создание последовательности задач для развертывания снимка образа

Для создания новой последовательности задач, которую мы будем использовать для развертывания импортированного снимка подготовленного в sysprep и настроенного образа Windows 7, нужно нажать правой клавишей на папке Последовательность задач (Task Sequences) в установочном ресурсе и выбрать команду создания новой последовательности задач (New Task Sequence). Это запустит мастера создания новой последовательности задач New Task Sequence Wizard, и в Общих настройках (General Settings) нам нужно указать имя и ID новой последовательности задач:

Рисунок 8: 1 шаг создания последовательности задач для развертывания образа.

Выбираем Standard Client Task Sequence в качестве шаблона для новой последовательности задач:

Рисунок 9: шаг создания последовательности задач для развертывания образа.

На странице выбора ОС в мастере выбираем импортированный образ, расположенный в папке Customized_Images:

Рисунок 10: 3 шаг создания последовательности задач для развертывания образа.

Выполняем оставшиеся шаги мастера для создания новой последовательности задач.

Указание значения True для параметра CopyProfile в файле Unattend.xml

В MDT каждая последовательность задач использует файл ответа (unattend.xml), связанный с ней. Для обеспечения правильного развертывания настроек, проделанных нами для снимка импортированного подготовленного в sysprep и настроенного образа, в стандартном пользовательском профиле на целевой системе, нам нужно отредактировать unattend.xml файл нашей последовательности задач так, чтобы CopyProfile параметр имел значение True. Причина такого изменения описана в файле справки Unattend.chm, включенном в Windows AIK 2.0, и ее можно описать следующим образом: “CopyProfile параметр позволяет вам настраивать пользовательский профиль и использовать его в качестве стандартного пользовательского профиля. Windows использует стандартный пользовательский профиль в качестве шаблона при назначении профилей каждому новому пользователю”.

Для этого нажимаем правой клавишей на нашей новой последовательности задач в Deployment Workbench и выбираем Свойства (Properties), чтобы открыть окно свойств последовательности задач:

Рисунок 11: Свойства последовательности задач.

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

Рисунок 12: Открытие свойств последовательности задач может занять несколько минут.

Когда свойства последовательности задач открылись, выберите закладку OS Info:

Рисунок 13: Закладка OS Info в свойствах последовательности задач.

Теперь нажмите кнопку изменения файла Edit Unattend.xml в закладке OS Info. Это откроет файл ответа этой последовательности задач в диспетчере Windows System Image Manager (Windows SIM). Разверните раздел специализированной передачи (specialize pass) файла ответа и выберите компонент Microsoft-Windows-Shell-Setup, затем в панели задач Свойства измените CopyProfile параметра на True, как показано ниже:

Рисунок 14: Установка параметра CopyProfile на True.

Нажмите кнопку Сохранить (Save) в панели инструментов в Windows SIM, затем закройте Windows SIM и закройте свойства последовательности задач.

Использование этой последовательности задач для развертывания снимка образа на целевую систему

Теперь мы воспользуемся этой последовательностью задач для развертывания нашего импортированного снимка подготовленного в sysprep и настроенного образа Windows 7 на целевой компьютер. Для этого загружаем пустую целевую систему (или новую виртуальную машину), используя Lite Touch .iso файл (файл LiteTouchPE_x64.iso расположен в папке Boot вашего установочного ресурса). Когда появится мастер Windows Deployment Wizard, пройдите по его страницам, выбрав только что созданную последовательность задач:

Рисунок 15: Установка настроенного образа на целевую систему с помощью LTI.

Когда MDT выполнит развертывание настроенного образа на целевую систему, вы автоматически войдете в систему от имени стандартной учетной записи локального администратора:

Рисунок 16: MDT автоматически выполняет вход в качестве локального администратора после LTI установки.

Совет: смотрите мою статью Deploying Windows 7 – Part 6: Lite Touch using MDT 2010 и другие статьи из цикла Deploying Windows 7, если хотите узнать больше об установке Lite Touch Installation (LTI) с помощью MDT 2010.

Создание нового локального пользователя на целевой системе и проверка настроек стандартного профиля

Итак, мы настроили стандартный пользовательский профиль Windows 7 с помощью двух способов: изменив параметры файла ответа (unattend.xml) и выполнив некоторые настройки вручную для нашей эталонной сборки. В первой части этого цикла мы выполнили следующие настройки с помощью файла ответа:

Отключение мастера первого запуска Internet Explorer First Run Wizard.Указание домашней страницы в Internet Explorer.Настройка службы отправки отчетов о неисправностях (WER) так, чтобы собранные данные автоматически отправлялись в компанию Microsoft без вмешательства пользователя.Включение встроенного компонента Games.Запрет установки XPS Viewer.

А во второй части цикла мы выполнили следующие настройки вручную:

Добавили ярлык Windows Remote Assistance в меню Пуск.Добавили ярлык Remote Desktop Connection в панель задач.Изменили стандартный вид библиотеки документов с подробного на содержимое.Изменили стандартный вид панели управления с категорий на мелкие значки.Изменили фон рабочего стола со стандартной картинки на сплошной светло-зеленый.

Затем мы подготовили нашу настроенную эталонную сборку в sysprep, сделали ее снимок, выгрузили образ в установочный ресурс и использовали MDT 2010 для развертывания этого образа на целевой компьютер. Теперь давайте посмотрим, работают ли настройки.

Если все прошло по плану, десять настроек, которые мы выполнили, должны были быть применены к стандартному пользовательскому профилю на целевом компьютере. В Windows 7 стандартный пользовательский профиль сортируется в скрытой папке под названием Default, расположенной в C:\Пользователи. Этот профиль никогда не загружается и копируется в качестве шаблона при создании новой учетной записи пользователя на компьютере.

Совет: для получения дополнительной информации о пользовательских профилях в Windows 7 читайте главу 15 Windows 7 Resource Kit from Microsoft Press. Обновления по этому ресурсу можно найти в Unofficial Support Site for the Windows 7 Resource Kit, который я веду.

Итак, давайте создадим новую учетную запись локального пользователя на нашей новой целевой системе и посмотрим, какие настройки были применены. Для создания новой учетной записи локального пользователя введите новый пользователь (new user) в строку поиска меню Пуск:

Рисунок 17: 1 шаг создания новой учетной записи локального пользователя на основе настроенного стандартного пользовательского профиля.

В ресурсах поиска выберите Создание стандартной учетной записи пользователя и введите имя новой учетной записи, а затем выберите Стандартный пользователь (Standard User):

Рисунок 18: 2 шаг создания новой учетной записи локального пользователя на основе настроенного стандартного пользовательского профиля.

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

Рисунок 19: Новая учетная запись пользователя Bob создана.

Нажатие на кнопку Пуск показывает, что ярлык для Windows Remote Assistance был закреплен в меню Пуск (настройка 6). Однако обратите внимание, что в панели задач нет ярлыка для подключения к удаленному рабочему столу (Remote Desktop Connection), поэтому настройка 7 не была применена:

Рисунок 20: Настройка 6 применена, а 7 нет.

Нажимаем на значок Internet Explorer в панели задач, в результате чего IE запускается без мастера первого запуска (настройка 1), однако вместо ожидаемой домашней страницы http://www.mtit.com/, мы видим пустую страницу (настройка 2):

Рисунок 21: Настройка 1 применена, а 2 нет.

Затем открываем центр поддержки (Action Center), вбираем Изменить параметры центра поддержки (Change Action Center Settings) и нажимаем на параметрах отчетов о проблемах (Problem Reporting Settings). Результат показан ниже и подтверждает, что настройка 3 была применена:

Рисунок 22: Настройка 3 применена

Нажимаем Пуск, Программы и Игры. Как вы видите ниже, игры были установлены, поэтому настройка 4 тоже сработала:

Рисунок 23: Настройка 4 применена

Затем вводим включение в строке поиска меню Пуск и в результатах поиска выбираем Включение и отключение компонентов Windows. На данный момент отображается оповещение службы UAC, поскольку Bob является стандартным пользователем, а не админом:

Рисунок 24: Оповещение UAC отображено, когда Bob пытается включить или отключить компоненты Windows.

После введения пользователем Bob учетных данных локального администратора компьютера, диалог компонентов Windows отображается и показывает, что XPS Viewer не был установлен (настройка 5):

Рисунок 25: Настройка 5 применена

Затем открываем библиотеку Документы и выбираем Дополнительные опции в панели инструментов. Как видно ниже, стандартный вид этой папки установлен на Содержимое, значит, настройка 8 сработала:

Рисунок 26: Настройка 8 применена

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

Рисунок 27: Настройка 9 применена

Итак, похоже, что все настройки были применены кроме двух:

Указание домашней страницы для Internet Explorer (мы пытались использовать для этого файл ответа)Добавление ярлыка для подключений к удаленному рабочему столу в панель задач (мы пытались сделать это вручную)Заключение

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