صفحه 1 از 2 1 2 آخرینآخرین
نمایش نتایج: از شماره 1 تا 15 از مجموع 18

موضوع: Deploying Windows 7

  
  1. #1
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272

    Deploying Windows 7

    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part1.html

    Mitch Tulloch

    Part 1: Windows AIK 2.0 Enhancements



    Introduction

    My previous series of articles titled; Deploying Vista, covered the basic concepts and tasks for automating the deployment of Windows Vista SP1 Enterprise using the following tools:

    • Windows Automated Installation Kit (Windows AIK) version 1.1
    • Windows Deployment Services (Windows DS) server role for Windows Server 2008
    • Microsoft Deployment Toolkit (MDT) 2008 Update 1

    Now that Windows 7 has reached Release Candidate stage, many enterprises who passed on migrating their desktop computers to Windows Vista are taking a hard look at migrating them to Windows 7. This is a good idea for two important reasons:

    • Mainstream support for Windows XP is now ended, so it's definitely time to think about upgrading your desktops to a newer version of Windows to ensure support.
    • The general consensus is that Windows 7 is everything that Windows Vista should have been—a lean, reliable, high-performing operating system with exciting new features that makes end-users more productive and the job of IT administrators easier.

    But instead of rewriting all thirty-one (!) of my Deploying Vista articles in order to update them for Windows 7, the path I have decided to follow in this new series of articles is to focus on the deltas between deploying the two platforms. This approach should make this current series much shorter than the previous one, while still covering all the new features of Windows 7 deployment.
    So let us begin by looking at the newest version of the Windows AIK and how this has changed in Windows 7.
    Note #1:
    I will be referring you back to specific articles in my Deploying Vista series wherever this is helpful.
    Windows AIK 2.0 Enhancements

    In article 1 of my Deploying Vista series, we learned about version 1.1 of the Windows AIK, which included various tools, documentation, and other stuff that formed the foundation for automating Vista deployment. Windows 7 has a new version of the Windows AIK that includes new deployment tools but also deprecates some older tools.
    First, here are some of the tools that were in Windows AIK 1.1 and are still in Windows AIK 2.0 but may have changed somewhat:

    • Windows System Image Manager (Windows SIM) is pretty much unchanged (see article 6 of my Deploying Vista series) although there are some new answer file settings, some existing answer file settings that have changed, and some deprecated answer file settings in Windows 7. We'll examine these changes to answer file settings changes in a future article of this series.
    • ImageX, the command-line tool for offline servicing of Windows image (WIM) files is still present but has been enhanced with several new command-line options. We learned about ImageX in article 12 of my earlier series and saw how to use this tool in article 13 of that series; we'll learn more about the changes to ImageX in a future article of this present series.
    • Several other command-line tools that were included in the Windows AIK 1.1 are also still included in the Windows AIK 2.0. These tools include Bootsect, Drvload, Oscdimg, and so on.
    • Now here are a few tools that are new to Windows AIK 2.0:
    • Deployment Image Servicing and Management Tool (DISM) is a new command-line tool in Windows AIK 2.0 that combines the functionality three tools found in the Windows AIK 1.1: Package Manager (Pkgmgr.exe), the International Settings Configuration Tool (Intlcfg.exe) and the Windows Preinstallation Environment (PEimg.exe) tools. DISM.exe also includes basic image management capabilities and can be used to mount Windows images in order to add device drivers, packages, and perform other image servicing tasks. We will examine DISM.exe in more detail in the next article of this series.
    • BCDboot is a new command-line tool that can be used to quickly set up a system partition of repair the computer's boot environment (which is located on the system partition). BCDboot is typically run from Windows PE and we will examine it in more detail in a future article of this series.
    • User State Migration Tool (USMT) 4.0 is a new version of USMT for Windows 7 (the old version 3.0.1 was used with Vista) can be used for migrating user profiles during large-scale deployments where you want to maintain existing user data and settings. USMT 4.0 is now included in the Windows AIK 2.0 (with Windows AIK 1.1, you had to separately download USMT 3.0.1) and has some cool new features such as hardlink migration that make migrating user profiles easier than ever. We'll examine USMT 3.0 in a future article of this series.
    • Volume Activation Management Tool (VAMT) lets you automate and centrally manage the volume activation of Windows clients using a Multiple Activation Key (MAK). In Windows Vista, this tool was part of Microsoft Volume Activation 2.0 and had to be separately downloaded; in Windows 7 however, the new version 1.2 of VAMT is now included as part of the Windows AIK 2.0.

    Finally, the following tools that were part of the Windows AIK 1.1 are now deprecated in the Windows AIK 2.0:

    • Package Manager (Pkgmgr.exe) is still included in Windows AIK 1.1 (and also in a default Windows 7 install) but is no longer needed because its functionality is now included in DISM.exe
    • International Settings Configuration Tool (Intlcfg.exe) has been removed because its functionality is now included in DISM.exe
    • Windows Preinstallation Environment (PEimg.exe) has been removed because its functionality is now included in DISM.exe
    • PostReflect.exe and VSP1CLN.exe have also been removed.

    Installing the Windows AIK 2.0

    Whilst writing the RC version of Windows AIK 2.0, it was only available on Microsoft Connect or as part of your MSDN or TechNet subscription. When Windows 7 is released to manufacturing, Windows AIK 2.0 will be available from the Microsoft Download Center as an .iso image file you can mount or burn to DVD media.
    You can install the Windows AIK 2.0 onto a technician computer running any of the following operating systems:

    • Windows XP SP3
    • Windows Server 2003 R2 SP3
    • Windows Vista
    • Windows Server 2008
    • Windows 7
    • Windows Server 2008 R2

    If you install the Windows AIK 2.0 on a pre-Vista operating system, you must make sure that you download and install the .NET Framework 2.0 and MSXML 6.0 first on the system.
    Figure 1 below shows the splash screen when you install the Windows AIK 2.0. Note that you can use this screen to download the following additional tools you may need for performing your deployment:

    • Application Compatibility Toolkit (ACT) 5.5 which can be used to evaluate and mitigate application compatibility issues before migrating your desktops to Windows 7.
    • Microsoft Assessment and Planning (MAP) is an inventory, assessment and reporting tool that does not use agent software and can be used to securely assess your environment prior to beginning your migration to Windows 7.
    • Microsoft Deployment Toolkit (MDT) 2010 which helps to automate desktop deployment using scripts, a unified Deployment Workbench, and other resources. We looked at how to use the earlier MDT 2008 beginning with article 24 of my Deploying Vista series; MDT 2010 includes many new features and enhancements and we'll be examining them in future articles of this series.


    Figure 1:
    Splash screen when you insert the Windows AIK 2.0 DVD
    Once you have installed the Windows AIK 2.0 on your technician computer, you can use it to deploy the following operating systems:

    • Windows XP SP3
    • Windows Server 2003 R2 SP2
    • Windows Vista SP1 or later
    • Windows Server 2008
    • Windows 7
    • Windows Server 2008 R2

    Additional Resources

    More information concerning the Windows AIK 2.0 can be found in the Windows Automated Installation Kit User's Guide (WAIK.chm) which can be accessed by clicking Start | All Programs | Microsoft Windows AIK on a technician computer on which you have installed the Windows AIK 2.0. By the time this article appears on WindowsNetworking.com you should also be able to view this User's Guide on Microsoft TechNet in the Windows 7 section of the Windows Client TechCenter.





    موضوعات مشابه:

  2. #2
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part2.html


    Part 2: Using DISM


    Understanding DISM

    DISM.exe is a new command-line tool that is included both in a default install of the Windows 7 operating system and also as part of version 2.0 of the Windows Automated Installation Kit (Windows AIK).
    Note:
    Support for VHD files as bootable Windows images is new in Windows 7 and is described in a later article of this series.
    You can use DISM.exe service Windows images, including both Windows image (WIM) files and virtual hard disk (VHD) files. While DISM.exe is primarily intended for servicing offline (not running) Windows images, some of its functionality can also be utilized to service online (running) Windows operating systems. By servicing an image we mean doing things like adding or removing device drivers, adding or removing operating system packages, adding hotfixes, configuring international settings, and performing similar types of actions on the image. DISM can also be used to upgrade a Windows image to a different edition (for example, to upgrade from Business to Ultimate) and to prepare a Windows PE image for use.
    You can use DISM.exe to service images of the following Windows versions:

    • Windows Vista SP1 or later
    • Windows Server 2008
    • Windows 7
    • Windows Server 2008 R2

    Using DISM

    In Windows Vista (or using the Windows AIK 1.1) servicing an image required using several different tools. For example, let us say you wanted to install an out-of-box device driver on an image you captured previously from a master installation. To do this in Vista, you had to:

    1. Mount the image using ImageX
    2. Add the device driver using Package Manager (Pkgmgr.exe)
    3. Unmount the image using ImageX

    In addition, if your image was a Windows PE image then you also need to use the Windows Preinstallation Environment (PEimg.exe) tool to prepare the image. And finally, if you needed to modify the language and locate settings of the image, you had to use the International Settings Configuration Tool (Intlcfg.exe).
    Beginning with Windows 7 however, DISM.exe now replaces the Pkgmgr.exe, Intlcfg.exe and PEimg.exe tools found in the earlier 1.1 version of the Windows AIK. In addition, DISM also includes functionality for mounting and unmounting images so you can service them.
    A typical use for DISM might be to add a device driver to an offline Windows image prior to deploying the image onto hardware that requires that driver. Let's walk through such a scenario to learn how to use DISM from the command-line.
    First, in the C:\Images folder on our Windows AIK 2.0 technician computer is a Windows install image (install.wim file) for Windows 7:
    C:\Program Files\Windows AIK\Tools\PETools>dir C:\Images
    Volume in drive C has no label.
    Volume Serial Number is 1C9A-D699

    Directory of C:\Images

    05/03/2009 12:46 PM <DIR> .
    05/03/2009 12:46 PM <DIR> ..
    04/22/2009 07:28 AM 2,218,242,699 install.wim
    1 File(s) 2,218,242,699 bytes
    2 Dir(s) 180,411,486,208 bytes free
    Note:
    Remember from article 17 of my Deploying Vista series that there are two types of Windows images: boot and install images
    Next, in the C:\Drivers folder are the Windows 7 beta drivers (version 2.91) for Microsoft LifeCam hardware:
    C:\Program Files\Windows AIK\Tools\PETools>dir C:\Drivers
    Volume in drive C has no label.
    Volume Serial Number is 1C9A-D699

    Directory of C:\Drivers

    05/03/2009 01:19 PM <DIR> .
    05/03/2009 01:19 PM <DIR> ..
    05/03/2009 01:19 PM <DIR> VX6000
    0 File(s) 0 bytes
    3 Dir(s) 180,411,486,208 bytes free
    We will be mounting our image to an empty folder named C:\Servicing. Let's begin by using the DISM.exe command with the /get-wiminfo parameter to display a list of all the Windows images contained in the install.wim file. Remember that an install image can contain more than one Windows image.
    C:\Program Files\Windows AIK\Tools\PETools>dism /get-wiminfo /wimfile:C:\Images\install.wim

    Deployment Image Servicing and Management tool
    Version: 6.1.7100.0

    Details for image : C:\Images\install.wim

    Index : 1
    Name : Windows 7 STARTER
    Description : Windows 7 STARTER
    Size : 7,927,317,234 bytes

    Index : 2
    Name : Windows 7 HOMEBASIC
    Description : Windows 7 HOMEBASIC
    Size : 7,983,232,406 bytes

    Index : 3
    Name : Windows 7 HOMEPREMIUM
    Description : Windows 7 HOMEPREMIUM
    Size : 8,422,988,972 bytes

    Index : 4
    Name : Windows 7 PROFESSIONAL
    Description : Windows 7 PROFESSIONAL
    Size : 8,303,245,818 bytes

    Index : 5
    Name : Windows 7 ULTIMATE
    Description : Windows 7 ULTIMATE
    Size : 8,461,373,562 bytes

    The operation completed successfully.
    Let us say that we are going to deploy Windows 7 Professional, in which case we can see from the above command output that the index number is 4 for this particular image. So, let us mount this particular Windows image to the empty C:\Servicing folder using the /mount-wim parameter of the DISM.exe command:
    C:\Program Files\Windows AIK\Tools\PETools>dism /mount-wim /wimfile:C:\Images\install.wim /index:4 /mountdir:C:\Servicing

    Deployment Image Servicing and Management tool
    Version: 6.1.7100.0

    Mounting image
    [==========================100.0%================== ========]
    The operation completed successfully.
    To verify whether the image has been mounted successfully we can use the /get-mountedinfo parameter like this:
    C:\Program Files\Windows AIK\Tools\PETools>dism /get-mountedwiminfo

    Deployment Image Servicing and Management tool
    Version: 6.1.7100.0

    Mounted images:

    Mount Dir : C:\Servicing
    Image File : C:\Images\install.wim
    Image Index : 4
    Mounted Read/Write : Yes
    Status : Ok

    The operation completed successfully.
    If we examine the contents of the C:\Servicing directory, we can see the files and directories of our mounted image:
    C:\Program Files\Windows AIK\Tools\PETools>dir C:\Servicing
    Volume in drive C has no label.
    Volume Serial Number is 1C9A-D699

    Directory of C:\Servicing

    04/22/2009 03:36 AM <DIR> .
    04/22/2009 03:36 AM <DIR> ..
    03/20/2009 10:42 AM 24 autoexec.bat
    03/20/2009 10:42 AM 10 config.sys
    04/22/2009 01:17 AM <DIR> PerfLogs
    04/22/2009 05:26 AM <DIR> Program Files
    04/22/2009 03:27 AM <DIR> Users
    04/22/2009 05:29 AM <DIR> Windows
    2 File(s) 34 bytes
    6 Dir(s) 180,321,382,400 bytes free
    Now let's view what kinds of servicing actions we can perform on our mounted image:
    C:\Program Files\Windows AIK\Tools\PETools>dism /image:C:\Servicing /?

    Deployment Image Servicing and Management tool
    Version: 6.1.7100.0

    Image Version: 6.1.7100.0


    The following commands may be used to service the image:

    WINDOWS EDITION SERVICING COMMANDS:

    /Set-ProductKey - Populates the product key into the offline image.
    /Get-TargetEditions - Displays a list of Windows editions that an image can be upgraded to.
    /Get-CurrentEdition - Displays the editions of the specified image.
    /Set-Edition - Upgrades the Windows image to a higher edition.

    UNATTEND SERVICING COMMANDS:

    /Apply-Unattend - Applies an unattend file to an image.

    DRIVER SERVICING COMMANDS:

    /Remove-Driver - Removes driver packages from an offline image.
    /Add-Driver - Adds driver packages to an offline image.
    /Get-DriverInfo - Displays information about a specific driver in an offline image or a running operating system.
    /Get-Drivers - Displays information about all drivers in an offline image or a running operating system.

    INTERNATIONAL SERVICING COMMANDS:

    /Set-LayeredDriver - Sets keyboard layered driver.
    /Set-UILang - Sets the default system UI language that is used in the mounted offline image.
    /Set-UILangFallback - Sets the fallback default language for the system UI in the mounted offline image.
    /Set-UserLocale - Sets the user locale in the mounted offline image.
    /Set-SysLocale - Sets the language for non-Unicode programs (also called system locale) and font settings in the mounted offline image.
    /Set-InputLocale - Sets the input locales and keyboard layouts to use in the mounted offline image.
    /Set-TimeZone - Sets the default time zone in the mounted offline image.
    /Set-AllIntl - Sets all international settings in the mounted offline image.
    /Set-SKUIntlDefaults - Sets all international settings to the default values for the specified SKU language in the mounted offline image.
    /Gen-LangIni - Generates a new lang.ini file.
    /Set-SetupUILang - Defines the default language that will be used by setup.
    /Get-Intl - Displays information about the international settings and languages.

    APPLICATION SERVICING COMMANDS:

    /Check-AppPatch - Displays information if the MSP patches are applicable to the mounted image.
    /Get-AppPatchInfo - Displays information about installed MSP patches.
    /Get-AppPatches - Displays information about all applied MSP patches for all installed applications.
    /Get-AppInfo - Displays information about a specific installed MSI application.
    /Get-Apps - Displays information about all installed MSI applications.

    PACKAGE SERVICING COMMANDS:

    /Add-Package - Adds packages to the image.
    /Remove-Package - Removes packages from the image.
    /Enable-Feature - Enables a specific feature in the image.
    /Disable-Feature - Disables a specific feature in the image.
    /Get-Packages - Displays information about all packages in the image.
    /Get-PackageInfo - Displays information about a specific package.
    /Get-Features - Displays information about all features in a package.
    /Get-FeatureInfo - Displays information about a specific feature.
    /Cleanup-Image - Performs cleanup and recovery operations on the image.

    For more information about these servicing commands and their arguments,
    specify a command immediately before /?.

    Examples:
    DISM.exe /Image:C:\test\offline /Apply-Unattend /?
    DISM.exe /Image:C:\test\offline /Get-Features /?
    DISM.exe /Online /Get-Drivers /?
    The parameters we want to use are found under DRIVER SERVICING COMMANDS above. Let's use the /get-drivers parameter to display a list of drivers already installed in the mounted image:
    C:\Program Files\Windows AIK\Tools\PETools>dism /image:C:\Servicing /get-drivers

    Deployment Image Servicing and Management tool
    Version: 6.1.7100.0

    Image Version: 6.1.7100.0

    Obtaining list of 3rd party drivers from the driver store...

    Driver packages listing:

    Published Name : oem0.inf
    Original File Name : prnms001.inf
    Inbox : No
    Class Name : Printer
    Provider Name : Microsoft
    Date : 6/21/2006
    Version : 6.1.7100.0

    The operation completed successfully.
    Let us now use the /add-driver parameter to add our LifeCam driver to the mounted image:
    C:\Program Files\Windows AIK\Tools\PETools>dism /image:C:\Servicing /add-driver /driver:C:\Drivers\VX6000\vx6000.inf

    Deployment Image Servicing and Management tool
    Version: 6.1.7100.0

    Image Version: 6.1.7100.0

    Found 1 driver package(s) to install.
    Installing 1 of 1 - C:\Drivers\VX6000\vx6000.inf: The driver package was successfully installed.
    The operation completed successfully.
    Let's use /get-drivers again to verify that the LifeCam driver has been successfully added to the mounted image:
    C:\Program Files\Windows AIK\Tools\PETools>dism /image:C:\Servicing /get-drivers


    Deployment Image Servicing and Management tool
    Version: 6.1.7100.0

    Image Version: 6.1.7100.0

    Obtaining list of 3rd party drivers from the driver store...

    Driver packages listing:

    Published Name : oem0.inf
    Original File Name : prnms001.inf
    Inbox : No
    Class Name : Printer
    Provider Name : Microsoft
    Date : 6/21/2006
    Version : 6.1.7100.0

    Published Name : oem1.inf
    Original File Name : vx6000.inf
    Inbox : No
    Class Name : Image
    Provider Name : Microsoft
    Date : 7/18/2008
    Version : 5.5.3.74

    The operation completed successfully.
    We now finish servicing the image by unmounting it:
    C:\Program Files\Windows AIK\Tools\PETools>dism /unmount-wim /mountdir:C:\Servicing /commit

    Deployment Image Servicing and Management tool
    Version: 6.1.7100.0

    Image File : C:\Images\install.wim
    Image Index : 4
    Saving image
    [==========================100.0%================== ========]
    Unmounting image
    [==========================100.0%================== ========]
    The operation completed successfully.
    Additional Resources

    For more information on using DISM.exe, type dism /? in the Deployment Tools Command Prompt on your technician computer. You can also find detailed information concerning DISM.exe in the Deployment Tools Technical Reference section of the Windows Automated Installation Kit User's Guide (WAIK.chm) which can be accessed by clicking Start | All Programs | Microsoft Windows AIK on your technician computer.
    Finally, check out the free e-learning Clinic 10077: What's New in Windows 7 for IT Pros on the Windows 7 Learning Portal section of the Microsoft Learning web site. I was the one who developed the content for these three clinics, and the IT Pro clinic has a short video demonstration of using DISM to service an image by adding drivers to the image




  3. #3
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part3.html
    Part 3: Understanding MAP 4.0


    Understanding MAP 4.0


    The Microsoft Assessment and Planning Toolkit (MAP), allows organizations to assess their current IT infrastructure (hardware and software) in order to determine what Microsoft technologies can help them meet their business needs. MAP evolved from the earlier Windows Vista Hardware Assessment Solution Accelerator, which was designed to help organizations assess the readiness of their desktop computing infrastructure for the deployment of Windows Vista and Microsoft Office 2007. MAP is a Solution Accelerator, a set of automation tools and a form of guidance that helps accelerate the adoption of Microsoft technologies by helping organizations during the planning phase of desktop or server migration or consolidation. A complete list of available Solution Accelerators can be found here.
    The previous version of MAP (version 3.2) allows organizations to:

    • Perform secure agent-less network-wide hardware and software inventory of Windows computers and their devices by using WMI, SNMP, and other mechanisms.
    • Perform comprehensive data analysis of hardware and device compatibility in order to determine readiness of migration systems for Windows Vista, Windows Server 2008, Microsoft Office 2007 and Microsoft Application Virtualization and to assist in planning for consolidation of physical computers onto Hyper-V or Virtual Server 2005 R2.
    • Generate in-depth readiness reports containing both summary and detailed assessment results for different migration scenarios that include recommendations for migration or server consolidation.

    The new version of MAP (version 4.0) that was recently released includes these new features:

    • An improved, simpler user interface that makes it easier than ever to inventory your infrastructure, assess readiness for different scenarios, and generate reports and recommendations.
    • Support for readiness assessment for Windows 7 and Windows Server 2008 R2.
    • Expanded support for readiness assessment for different server consolidation scenarios.
    • Improved experience to calculate Return on Investment (ROI) for server virtualization project by using MAP and the Integrated Virtualization ROI Tool.
    • Support for OEM and Partner customization of the MAP user interface and migration proposal documents.

    The focus of this present series is on deploying Windows 7 and MAP 4.0 is a terrific tool to help you plan your desktop migration. Even so, MAP 4.0 can do far more than just assess whether your desktop computers can run Windows 7. Using MAP 4.0, you can:

    • Perform a comprehensive inventory of PC hardware and software including SQL Server instances.
    • Assess whether your servers are ready for migration to Windows Server 2008 R2.
    • Discover server roles on your network.
    • Find physical computers that are potential candidates for virtualization using Hyper-V.
    • Discover VMware virtual machines for potential migration to Hyper-V.
    • Assess possible candidates for App-V virtualization.
    • Perform readiness assessments for Microsoft Forefront and implementing Network Access Protection (NAP).
    • Estimate potential power savings when different power management settings are implemented on clients and servers.

    MAP 4.0 and Windows 7 Deployment

    MAP 4.0 is one of three key tools from Microsoft that organizations typically will need to use when preparing to migrate their desktops to Windows 7:

    1. MAP 4.0 – Use this tool first to assess the readiness of your environment to migrate your desktop computers to Windows 7.
    2. ACT 5.5 – Use the Application Compatibility Toolkit 5.5 next to test your existing applications for possible compatibility issues when running them on Windows 7 and for mitigating such issues by creating application shims for problem apps.
    3. MDT 2010 – Use the Microsoft Deployment Toolkit 2010 to deploy Windows 7 once you have assessed that your desktop computers are ready for Windows 7 and that your legacy line-of-business (LoB) applications can be shimmed to run properly under Windows 7.

    A product manager on the MAP team told me that internally they like to refer to these tools as "The Three Musketeers". Personally, I like to refer to them as MAPACTMDT
    Installing MAP 4.0

    Begin by downloading MAP 4.0 from here on the Solution Accelerators TechCenter on Microsoft TechNet. It is supported on:

    • Windows XP SP2 or later
    • Windows Vista Ultimate, Enterprise or Business
    • Windows 7 Professional, Enterprise or Business
    • Windows Server 2003 SP1 or later
    • Windows Server 2003 R2
    • Windows Server 2008
    • Windows Server 2008 R2

    There are versions of MAP for the x86 and x64 architectures. Before installing MAP 4.0 you must ensure that you have the following additional software installed:

    • .NET Framework 3.5 SP1
    • Windows Installer 4.5
    • Microsoft Office Word 2007 or Microsoft Word 2003 SP2
    • Microsoft Office Excel 2007 or Microsoft Excel 2003 SP2

    During installation of MAP 4.0, the setup will download and install SQL Server 2008 Express Edition on your computer. Once installation of MAP 4.0 is completed, you will be prompted to create an instance of a SQL Server 2008 Express database for storing the inventory information MAP acquires during the assessment process (see Figure 1):

    Figure 1: Creating a SQL Server 2008 Express database instance for use by MAP
    Examining MAP 4.0

    Once MAP 4.0 has been installed on a computer, you can launch the program from the Start menu. The MAP console displays a navigation pane on the left that has three buttons at the bottom: Inventory and Assessment, Surveys, and Reference Material. Selecting the Inventory and Assessment button displays a tree view of options you can choose from:

    • Discovery and Readiness
    • Server Consolidation

    Selecting the Discovery and Readiness option as shown in Figure 2 below lets you perform inventory and assess readiness for:

    • Migrating client computers to Windows 7, Windows Vista or Office 2007.
    • Discovering server roles and SQL Server instances, and migrating servers to Windows Server 2008 or Windows Server 2008 R2.
    • Discovering virtual machines present on your network.


    Figure 2:
    The Discovery and Readiness option under Inventory and Assessment
    Selecting the Server Consolidation option as shown in Figure 3 below lets you perform the following server consolidation tasks:

    • Inventory your server environment for physical servers that can be consolidated as virtual machines on Hyper-V.
    • Gather performance metrics for server consolidation.
    • Configure host machine equivalents and make recommendations concerning placement of guest machines.
    • Calculate the potential return on investment (ROI) your organization can achieve through implementing a Microsoft integrated virtualization solution.


    Figure 3:
    The Server Consolidation option under Inventory and Assessment
    Selecting the Survey button in the bottom portion of the navigation pane allows you to:

    • Use an online survey to evaluate the migration of your existing messaging infrastructure to the Microsoft Exchange Hosted Services available from Microsoft Online Services (click here for more information).
    • Download the Infrastructure Planning and Design (IPD) assessment guide and scenario selection tool for Windows Optimized Desktop Scenarios, which you can use to evaluate the implementation of different Microsoft desktop virtualization technologies that could provide extra benefits to your desktop users, including rich and thin client solutions such as Windows Vista, App-V, VDI and more.


    Figure 4:
    The Surveys option provides links to an online survey and a Solution Accelerator you can download
    The final button (Reference Material) found at the bottom of the navigation pane takes you to a page that has links to other useful planning and assessment tools available from Microsoft. It will also direct you to various documentation pages on Microsoft TechNet that can help you during the planning phases (Figure 5):

    Figure 5: Links to additional reference material are available from within the MAP
    Conclusion

    In this article we have looked at what MAP 4.0 is and what it can be used for. We also examined the installation requirements and provided a brief overview of the MAP 4.0 console. In the next article of this series, I will help you set up a Windows 7 Readiness assessment. For more information about MAP and to obtain the latest version of the toolkit, click here.






  4. #4
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part4.html
    Part 4: Using MAP 4.0


    Preparing to Run the Windows 7 Readiness Assessment

    Before you use MAP to assess the readiness of your desktop computers for a migration to Windows 7, you need to make sure they can be assessed. The great thing about MAP is that it is agent less, which means that you do not need to deploy a software agent to each desktop machine that you want to assess. Instead of using agents, MAP uses Windows Management Instrumentation (WMI) to collect hardware devices and software information from the computers on your network. In order for WMI to be able to do this, your desktop computers must be configured to allow remote WMI queries. This means that you have to enable the Remote Administration and the File & Printer Sharing exceptions in Windows Firewall on all your desktop computers. You can use Group Policy to enable Windows Firewall exceptions in an Active Directory-based network (in a workgroup you have to do this manually on each computer). Also, in a domain environment, you need to run MAP on a computer on which you have logged on as a member of the Domain Admins security group (in a workgroup environment you need to provide MAP with local Administrator credentials for each computer). Additional configuration steps may need to be performed in order to prepare your desktop computers for assessment by MAP. For more information, see the Getting Started Guide for MAP 4.0, which is available from Start | All Programs | Microsoft Assessment and Planning Toolkit. Be sure also to review the MAP FAQ before using MAP.
    Performing a Windows 7 Readiness Assessment

    To perform your Windows 7 Readiness assessment, open the MAP console, select the Inventory and Assessment button at the bottom portion of the navigation pane, expand Discover and Readiness in the top portion of the navigation pane, and select Windows 7 Readiness (Figure 1):

    Figure 1: Running a Windows 7 Readiness assessment using MAP 4.0
    Click the Inventory and Assessment Wizard link in the right pane to launch the Inventory and Assessment Wizard. On the first page of this wizard you can specify which method(s) you would like to use in order to locate the computers on your network (Figure 2). The supported methods in MAP 4.0 include:

    • Querying Active Directory for computer accounts in domains or OUs you specify
    • Using Win32 LAN Manager APIs to query the Computer Browser service to find computers belonging to workgroups
    • Importing a list of computer names (NetBIOS or FQDNs) from a text file
    • Scanning a specified IP address range for computers
    • Manually specifying computer names (NetBIOS or FQDNs) if you only have a few computers to assess
    • Discover Windows virtual machines running on VMware servers

    By default, Active Directory and Windows network protocols are used, but to keep things simple in this example, we will clear the second option and only query Active Directory.
    Note:
    Selecting different options on this page may result in additional wizard pages being displayed later on.

    Figure 2: Choosing which methods to use to discover computers on your network
    On the next page of the wizard we specify the Domain Admin credentials MAP can use to query Active Directory (Figure 3):

    Figure 3: Specify Domain Admin credentials for MAP to query Active Directory
    On the next wizard page, we will specify that MAP should only query for computer accounts in the Seattle Computers OU since those will be the computers we will pilot Windows 7 on (Figure 4):

    Figure 4: Specify the domain and organizational units where the computers reside
    The next wizard page asks us for credentials MAP can use to remotely connect to each computer using WMI (Figure 5):

    Figure 5: MAP needs credentials to remotely connect to computers using WMI
    Clicking New Account opens the Inventory Account dialog box (Figure 6). Specify a Domain Admin account for the inventory account:

    Figure 6: Specify a Domain Admin account for WMI connections to remote computers
    Clicking Save adds the specified account to the WMI Credentials page of the wizard (Figure 7):

    Figure 7: Credentials for remote WMI connections have been specified
    The final page of the wizard summarizes the choices you have made (Figure 8):

    Figure 8: Summary page of wizard
    Clicking Finish starts the inventory process and displays a Status dialog box (Figure 9):

    Figure 9: Status of the inventory process is displayed
    Once the assessment is finished, click Close. After a few moments MAP will display the results of the assessment. Figure 10 shows that two client computers were found in the specified OU and that both of them were ready for Windows 7:

    Figure 10: Summary results of the Windows 7 Readiness assessment
    Scrolling down the middle pane of MAP shows additional details of the assessment. For instance, we can see in Figure 11 that there are a few device incompatibility issues that we will need to resolve with device manufacturers before we migrate the computers to Windows 7.

    Figure 11: Note that 6% of the devices on the assessed computers may be incompatible with Windows 7
    Changing the Hardware Requirements

    Let us examine what hardware requirements were used during the above assessment as a basis for determining whether our computers are ready for Windows 7. In the Actions pane at the right side of the above figure, click Set Assessment Properties to open the Assessment Properties dialog box (Figure 12):

    Figure 12: Default hardware values used by MAP for assessing Windows 7 readiness
    By default, MAP uses the following minimum hardware requirements for Windows 7 readiness (these values are preliminary and are subject to change at RTM):

    • CPU minimum speed 1.0 GHz
    • Minimum free disk space 20 GB for x64 systems and 16 GB for x86 systems
    • Minimum RAM of 2 GB for x64 systems and 1 GB for x86 systems

    What if these hardware requirements are not sufficient for the needs of our business? For example, since we plan on using our two computers in Seattle for some fairly intensive work, such as video processing, let us increase these minimum requirements and see if our computers will still be ready for Windows 7. To do this, select Use Custom Settings and specify the new requirements shown in Figure 13:

    Figure 13: Specifying more stringent hardware requirements for Windows 7
    Now click Run Assessment to re-run the Windows 7 Readiness assessment using these more stringent hardware requirements (Figure 14):

    Figure 14: Re-running the assessment
    Generating Proposals and Reports

    We have now run two assessments that basically answer the following two questions:

    • How many computers at Seattle are ready for Windows 7?
    • Will these computers still be ready for Windows 7 given our more stringent hardware requirements?

    Let us generate reports we can share and review with our IT team and later with management. To generate reports, click Generate Report/Proposal in the Action pane at the right of Figure 11 shown previously. When you do this, MAP generates a proposal (Word doc) and an Excel workbook containing various reports (Figure 15):

    Figure 15: Reports and proposals are being generated
    Let us look at the Excel workbook first as it contains the detailed information our IT staff will need to review. To find our proposals and reports, select View | Saved Reports and Proposals to open the folder where the proposals and reports are found (Figure 16):

    Figure 16: Proposals and Reports generated by MAP
    We will open the Excel workbook and look at each worksheet. The first worksheet provides a summary of Windows 7 readiness information for computers that are already running a Microsoft Windows client (Figure 17):

    Figure 17: Windows 7 Assessment Summary for Client Computers worksheet
    The next worksheet shows the system requirements provided by Microsoft in addition to any recommended settings that were used in the assessment (Figure 18):

    Figure 18: System Requirements Used in the Assessment worksheet
    The next worksheet provides a summary of Windows 7 readiness information for computers that are already running a Microsoft Windows client operating system. For rows that report "Insufficient Data" refer to the WMI Status column for more information about why inventory data could not be collected (Figure 19):

    Figure 19: Windows 7 Assessment Results for Client Computers worksheet
    The next worksheet is a summary of the hardware devices found on the computers. It identifies whether a driver is available on the Windows 7 DVD, from Windows Update, or if you need to contact the hardware manufacturer to identify if a driver is available for Windows 7. This summary worksheet has a row for each discovered device and provides the number of computers where the device was found. To identify the specific devices on each computer, refer to the Device Inventory Details Worksheet (Figure 20):

    Figure 20: Device Assessment Summary worksheet
    The next worksheet describes the hardware devices discovered on each specific computer. It identifies whether a driver is available on the Windows 7 DVD, from Windows Update, or if you need to contact the hardware manufacturer to identify if a driver is available for Windows 7 (Figure 21):

    Figure 21: Device Assessment Details worksheet
    The next worksheet describes computers that are not currently able to run Windows 7 and the hardware upgrades required for them to meet the minimum system requirements for Windows 7 (Figure 22):

    Figure 22: Windows 7 Minimum Ready Computers After Hardware Upgrades worksheet
    The next worksheet describes computers that are not currently able to run Windows 7 or meet the minimum system requirements. It provides the hardware upgrades required for the computers to be ready for Windows 7 using the recommended hardware requirements selected for this assessment (Figure 23):

    Figure 23: Windows 7 Recommended Ready Computers After Hardware Upgrades worksheet
    The eighth and final worksheet describes up to 60,000 applications discovered through the inventory process on client machines and provides a count of the number of times a particular version of the software was found. The data in this sheet is based solely upon computers where a successful inventory was performed (Figure 24):

    Figure 24: Discovered Applications worksheet
    Finally, let us examine the Word doc generated by MAP, which summarizes the results of our Windows 7 Readiness assessment (Figure 25):

    Figure 25:MAP generates a proposal you can present to management
    As you can see from the outline on the left, this document contains both the results of your assessment and also some additional information concerning the benefits of deploying Windows 7 Enterprise edition in your organization. You can use this document as the basis for the proposal you will present to management. Lastly, MAP 4.0 will give you the ability to insert your own text and logos within the Word template, allowing users such as consultants to customize the outputs with their own “branding” in future scans.
    Conclusion

    MAP 4.0 is a powerful tool for assessing whether your desktop infrastructure is ready to migrate to Windows 7. There are other capabilities in MAP 4.0 that can help you plan a server migration and consolidation. We will examine these capabilities in a future article on this site. For more information about MAP see here on the Solution Accelerators TechCenter on Microsoft TechNet




  5. #5
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part5.html
    Part 5: MDT 2010 Enhancements


    Introduction

    My previous series of articles titled Deploying Vista described how to deploy Windows Vista SP1 Enterprise edition using Microsoft Deployment Toolkit (MDT) 2008 Update 1 together with the Windows Automated Installation Kit (Windows AIK) version 1.1. This present series of articles about deploying Windows 7 will now continue by focusing on how to deploy Windows 7 Enterprise edition using MDT 2010 and the Windows AIK 2.0. Later on we will also examine how to bring Windows Deployment Services in Windows Server 2008 R2 into the mix of things, and afterwards we will look at how to use MDT 2010 together with Microsoft System Center Configuration Manager 2007 SP2. But first let us get the basics of using MDT 2010 under our belt.
    In article 24 of my previous series Deploying Vista you learned about:

    • The history of Microsoft deployment solution accelerators
    • The difference between Light-Touch Installation (LTI) and Zero-Touch Installation (ZTI) deployments
    • Four possible deployment scenarios: new computer, refresh computer, replace computer, and upgrade computer
    • How to install MDT 2008
    • The Deployment Workbench

    If you have forgotten any of this, you may want to review the earlier article before proceeding further.
    MDT 2010 Enhancements


    MDT 2010 is the next version of MDT and has a lot of changes over the previous version MDT 2008 Update 1. Let us examine some of these changes now.
    First of all, you can now deploy Windows 7 and Windows Server 2008 R2. The previous version of MDT (MDT 2008 Update 1) cannot deploy Windows 7—you must use MDT 2010 to do this. Specifically, you can use MDT 2010 to deploy the following Windows operating systems:

    • Client OSes: Windows 7, Windows Vista SP1+ and Windows XP SP3.
    • Server OSes: Windows Server 2008 R2, Windows Server 2008 and Windows Server 2003 R2.


    In MDT 2008 Update 1 you had to create and configure distribution shares and deployment points. You may recall that a distribution share was the folder that contained the source files for an operating system such as Windows Vista that you planned on deploying using MDT 2008 Update 1. The distribution share also contained any packages, drivers, or applications you wanted to include in your install. A deployment point on the other hand was a folder that contained all the files needed to deploy your Vista image together with any drivers, packages and applications needed for the install. A big change in MDT 2010 is that these two things (distribution shares and deployment points) are now combined into a single thing called a deployment share. This change simplifies the process of preparing and using your MDT-based deployment infrastructure.
    Here are some additional enhancements concerning deployment shares:

    • Deployment shares can be hosted on local drives, network shares, or in a standalone DFS namespace
    • Multiple deployment shares can be opened at the same time in the Deployment Workbench
    • Deployment shares can be managed from any machine where the Deployment Workbench is installed—provided the NTFS and shared folder permissions are appropriate on the share
    • Deployment shares can be linked so that when the content of one share is updated the content in the other share is also updated

    Another big change in this version of MDT is that the underlying scripting logic has been migrated from VBScript to Windows PowerShell. In other words, most of the tasks you perform using the Deployment Workbench are actually accomplished using Windows PowerShell commands. In addition, you can use Windows PowerShell commands directly to perform various MDT configuration and management tasks and automate them, something that was difficult to do in previous versions of MDT as it required editing complex scripts. In other words, anything you can do using the Deployment Workbench can now also be done using Windows PowerShell commands and scripts. See this post on Michael Niehaus's blog for a quick look at some of the powerful new capabilities added to MDT 2010 using Windows PowerShell.
    The Deployment Workbench, which is the integrated workspace from which you can perform all of your deployment-related tasks, has also been enhanced in MDT 2010. For example, you can now create a hierarchical tree of folders in each deployment share in order to help you organize items such as operating systems, device drivers, and task sequences for that share. Plus you can cut/copy/paste and drag/drop items within these folder trees. And you can use selection profiles to manage groups of similar items (such as device drivers for a specific type of machine) as a single item. These changes all make it easier than ever to manage your deployment resources and tasks.
    Finally, there are a number of other enhancements in MDT 2010 relating to security, stability and performance. For example, you can now refresh a computer that has a volume protected by Windows BitLocker Drive Encryption without having to decrypt and re-encrypt the protected volume. This makes this particular refresh scenario more secure and much faster than before. There's lots more added in MDT 2010—see Michael Niehaus's blog for a series of articles examining in detail some of the exciting new features found in this new version of MDT.
    Installing MDT 2010


    You can install MDT 2010 on x86 or x64 systems running the following operating systems:

    • Windows Server 2008 or Windows Server 2008 R2
    • Windows 7 or Windows Vista SP1
    • Windows Server 2003 SP2 (requires .NET Framework 2.0 and MSXML 6.0)

    Before you install MDT 2010 make sure you have installed the Windows AIK 2.0 on your technician computer. You can download both the Windows AIK 2.0 and MDT 2010 from the Microsoft Download Center. MDT 2010 is available in two forms:

    • MicrosoftDeploymentToolkit_x64.msi
    • MicrosoftDeploymentToolkit_x86.msi

    I recommend you install the 64-bit version of MDT 2010 on a 64-bit system such as an x64 version of Windows Server 2008 R2. Double-clicking on the Windows installer package launches the setup process (Figure 1):

    Figure 1: Installing MDT 2010 on a technician computer
    You should generally perform a complete install (Figure 2):

    Figure 2: Installing all components of MDT 2010
    Examining the Deployment Workbench


    Once you have installed MDT 2010 you can launch the Deployment Workbench (Figure 3):

    Figure 3: The re-vamped Deployment Workbench in MDT 2010
    If you compare Figure 3 above with Figure 3 from article 24 of my Deploying Vista series, you can see some obvious differences. Specifically, the old Deployment Workbench had four main subnodes on the left:

    • Information Center
    • Distribution Share
    • Task Sequences
    • Deploy

    The new one still has the Information Center node, but the other three have now been combined into a single Deployment Shares node. We will learn how to create a deployment share in the next article of this series.
    Upgrading to MDT 2010


    You can also upgrade to MDT 2010 from the following earlier Microsoft deployment solution accelerators:

    • MDT 2008 Update 1
    • BDD 2007 Update 2

    For information on upgrading to MDT 2010, see the Microsoft Deployment Toolkit Documentation Library, a Windows Help (.chm) file installed when you install MDT 2010 on a system.
    Conclusion

    In this article we have examined the new features of MDT 2010 and how to install MDT 2010 on a technician computer. In the next article of this series we will examine how to prepare MDT 2010 for deploying Windows 7 Enterprise edition using LTI





  6. #6
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part6.html
    Part 6: Lite Touch using MDT 2010



    Introduction

    In the previous article of this series we examined the new features of MDT 2010, the latest version of Microsoft Deployment Toolkit. We also looked at how to install MDT 2010 and examined the basic layout of the updated Deployment Workbench. In this article we will examine how to manually perform a basic Lite Touch Installation (LTI) deployment of Windows 7 Enterprise using MDT 2010. The tasks we are going to perform include:

    • Preparing the environment
    • Creating a deployment share
    • Configuring the deployment share
    • Creating a task sequence
    • Updating the deployment share
    • Performing the install

    Before you continue reading, you may want to refer back to the following two articles from my previous series Deploying Vista:


    Preparing the Environment

    To follow along through this walkthrough, make sure you have the following environment (or something similar) set up:

    • Domain controller for the contoso.com domain.
    • DHCP server with a scope configured for leasing addresses to client computers.
    • Technician computer with MDT 2010 and Windows AIK 2.0 installed.

    In my own test environment, one computer running Windows Server 2008 R2 Enterprise x64 fulfills all of these roles.
    Creating a Deployment Share


    Open the Deployment Workbench on your technician computer, then right-click on the Deployment Shares node and select New Deployment Share. The New Deployment Share wizard starts. Click the Browse button and create a folder named DeploymentShare$ in the root of your disk volume as shown in Figure 1:

    Figure 1: Specify the name and path to the deployment share folder
    Click Next and the share name will automatically be populated and the UNC path to the share will be displayed (Figure 2):

    Figure 2: The share name and UNC path for the deployment share are displayed
    Click Next and give your deployment share a descriptive name (Figure 3):

    Figure 3: Name the deployment share
    Click Next and choose whether you want to be able to capture an image after deploying it to a computer (Figure 4). We will leave this option enabled so we can use it if we deploy a reference (master) computer and capture its image for deployment onto multiple target (end-user) computers:

    Figure 4: Specify whether the option to capture an image will be displayed when the Windows Deployment Wizard runs during an install
    Click Next and specify whether the user should be allowed to set the password for the local Administrator account on their computer (Figure 5). We'll leave this option unchecked:

    Figure 5: The Allow Admin Password option
    Click Next and specify whether the user should be asked to enter a product key (Figure 6). We will leave this unchecked because we are deploying Windows 7 Enterprise, which means that activation is typically performed using Key Management Service (KMS):

    Figure 6: Choose whether the user is prompted to enter a product key during the install
    Now finish the wizard and review the Confirmation page to ensure everything was done as expected. Figure 7 shows the newly created deployment share and its folder structure in the Deployment Workbench:

    Figure 7: The newly created deployment share
    Configuring the Deployment Share


    Once you have created your deployment share, you need to configure it as follows:

    • Add the operating system you wish to deploy
    • Add any out-of-box device drivers needed for installing the operating system on the target computers
    • Add any applications you want to install on the target computers during the install
    • Add any packages such as hotfixes or security updates you want to install on the target computers during the install

    For simplicity we are only going to add an operating system (Windows 7 Enterprise) to the deployment share. In future articles we will examine how to add drivers, packages and applications to deployment shares.
    To add an operating system, right-click on the Operating Systems node in the deployment share and select Import Operating System. This starts the Import Operating System Wizard. On the first page of the wizard, specify that you want to import a full set of source files (Figure 8):

    Figure 8: Importing a full set of Windows 7 operating system files into the deployment share
    Insert your Windows 7 Enterprise product media into the DVD drive of your technician computer and browse to select the DVD (Figure 9):

    Figure 9: Importing the OS source files from the product DVD
    Click Next and the wizard skips ahead to the Destination page (Figure 10). Specify a descriptive name for the folder where the source files will be imported to on your technician computer (note that I have imported the x86 version of the OS in this example):

    Figure 10: Specify the name of the folder where the OS source files will be imported to
    Finish the wizard. The import process may take several minutes to complete. Once it is done and you select the Operating Systems folder in your deployment share, the imported OS is displayed (Figure 11).

    Figure 11: Windows 7 Enterprise source files have been imported into the deployment share
    At this point you would add out-of-box drivers, packages and applications to your deployment share as needed.
    Creating a Task Sequence


    Now let us create a task sequence. A task sequence is a series of steps that are performed during deployment. We want to create a task sequence that will install Windows 7 Enterprise onto a bare-metal target computer. To do this, right-click on the Task Sequences folder in your deployment share and select New Task Sequence. This launches the New Task Sequence Wizard. On the first page of the wizard, specify a task sequence ID (no spaces), task sequence name, and comments as desired (Figure 12):

    Figure 12: Creating a new task sequence for deploying Windows 7
    Click Next and select Standard Client Task Sequence from the list of available task sequence templates (Figure 13):

    Figure 13: Base the new task sequence on the Standard Client template
    Click Next and select Windows 7 Enterprise, which is the only imported OS at this point (Figure 14):

    Figure 14: Select an operating system to deploy using the task sequence
    Click Next and select the option to not specify a product key in the task sequence (Figure 15):

    Figure 15: Do not specify a product key in the task sequence when deploying volume-licensed media and using KMS activation
    Click Next and specify the name of the user who will be using the computer and your organization name and website/internet (Figure 16):

    Figure 16: The OS Settings wizard page
    Click Next and specify a password for the local Administrator account on the target computer (Figure 17):

    Figure 17: Specify a password for the local Administrator account on the user's computer
    Finish the wizard. The new task sequence is displayed in the Task Sequences folder of your deployment point (Figure 18):

    Figure 18: The new task sequence is displayed in the Deployment Workbench
    Updating the Deployment Share


    Now we need to update our deployment share. Updating a deployment share does several things, one of which being the creation of customized version of the Windows Preinstallation Environment (Windows PE) that can be used to deploy the operating system using the task sequence. Specifically, updating the deployment share in this example creates the following Windows PE images in the C:\DeploymentShare$\Boot folder on your technician computer:

    • LiteTouchPE_x64.iso – Used to manually deploy Windows 7 Enterprise x64 onto a bare-metal system.
    • LiteTouchPE_x64.wim – Used to deploy Windows 7 Enterprise x64 onto a bare-metal system using Windows Deployment Services.
    • LiteTouchPE_x86.iso – Used to manually deploy Windows 7 Enterprise x86 onto a bare-metal system.
    • LiteTouchPE_x86.wim – Used to deploy Windows 7 Enterprise x86 onto a bare-metal system using Windows Deployment Services.

    To update your deployment share, right-click on it and select Update Deployment Share. This launches the Update Deployment Share Wizard (Figure 19):

    Figure 19: Updating the deployment share
    Leave the default options selected and finish the wizard. It may take some time to create the Windows PE images on your technician computer. Once the wizard finishes, burn the LiteTouchPE_x86.iso file onto a CD as you will need it to deploy Windows 7 Enterprise x86 onto your target computer.
    Note:
    As shown in Figure 20, on the Confirmation page of this wizard (and on all MDT 2010 wizards) there are two buttons:

    • Save Output – saves the output of the wizard to a text file (actually it's better to save it as .rtf as it's more readable that way).
    • View Script – displays the underlying Windows PowerShell commands that are executed by the wizard.

    As an example of the second, the View Script output from the Update Deployment Share Wizard looks like this:
    Add-PSSnapIn Microsoft.BDD.PSSnapIn
    New-PSDrive -Name "DS001" -PSProvider MDTProvider -Root "C:\DeploymentShare$"
    update-MDTDeploymentShare -path "DS001:" -Verbose


    Figure 20: Confirmation page of the wizard
    Performing the Install


    At this point, you are ready to deploy Windows 7 using MDT. Turn on your bare-metal (i.e. no OS installed) target computer and put your customized Windows PE CD into the CD drive on the computer. After a short time the Windows Deployment Wizard will start and you can follow the prompts almost exactly as shown in my earlier article Deploying Vista Part 26: Deploying Vista Using Microsoft Deployment Toolkit. The differences between what you will see when you do this using MDT 2010 and what this earlier article shows for MDT 2008 are basically only cosmetic in nature




  7. #7
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part7.html
    Part 7: Automated LTI Deployment



    Tip:
    You can find more information about automating LTI deployment in the Windows 7 Resource Kit from Microsoft Press. I'm the lead author for this Resource Kit and I also maintain the Unofficial Support Site for the Windows 7 Resource Kit where you will find the latest updates and other useful information.
    Introduction

    In the previous article of this series we learned how to manually perform a basic Lite Touch Installation (LTI) deployment of Windows 7 Enterprise using MDT 2010. In this article we will learn how to complete and automate this process.
    Automating LTI deployment of Windows 7 using MDT 2010 involves the following steps:

    1. Create a deployment share using the Deployment Workbench.
    2. Import Windows 7 source files into the share.
    3. Add packages, drivers, and applications to your share as needed.
    4. Create a basic task sequence based on the Standard Client Task Sequence template.
    5. Edit the CustomSettings.ini and BootStrap.ini configuration files as needed to automate the LTI deployment process.
    6. Update the deployment share to create Windows PE boot images (.iso and .wim files) and burn the .iso file to CD or DVD media.
    7. Boot the destination computer using the Windows PE boot image and let the install proceed entirely unattended.

    We have already performed steps 1-4 in the previous article of this series, so all we need to do here is perform steps 5-7, so here goes.
    Editing the Configuration Files

    As in the previous version MDT 2008 Update , MDT 2010 uses configuration files to control the LTI deployment process. These configuration files provide input for the scripts that MDT uses to perform the install. There are two configuration files you must edit to perform a fully automated LTI deployment: CustomSettings.ini and BootStrap.ini. We have briefly examined these two files in Part 27 of my Deploying Vista series. Let us review what these files are for and dig into them a bit deeper this time.
    To begin with, let us examine the default CustomSettings.ini file that MDT creates for the deployment share we created in the previous article. To view the contents of CustomSettings.ini, we will open the Deployment Workbench, right-click on the deployment share and select Properties, then select the Rules tab as shown in Figure 1:

    Figure 1: The default CustomSettings.ini file for a new deployment share

    Notice that this default CustomSettings.ini file does not contain any information concerning which operating system image is to be deployed, which task sequence will be used, and so on. If this is the CustomSettings.ini file then information like that will need to be supplied during deployment, that is, by sitting at the destination computer and responding to the prompts of the Windows Deployment Wizard (see Part 26 of my Deploying Vista series for examples of such wizard prompts). Of course, that is not what we want to do—we want to automate the install.
    Let us also examine the default BootStrap.ini file for our new deployment share, which is shown in Figure 2:

    Figure 2: The default BootStrap.ini file for a new deployment share
    Notice that this default BootStrap.ini file contains information about the network location of the deployment share, but it does not contain information concerning the credentials to be used in order to connect to this share. This is why one of the first things you are prompted to supply when you perform a manual LTI deployment is the credentials that the Windows Deployment Wizard will use to connect to the share. And of course, we do not want to have to supply this prompt or any prompt during installation—we want to fully automate the LTI deployment.
    To do this, we need to make some changes to these two configuration files. But before we do this we need to ask ourselves some questions, such as:

    • What time zone do we want to configure for the destination computer?
    • What locale do we want to configure?
    • Do we want to specify a computer name or let one be randomly assigned during installation?
    • Do we want to join the computer to a domain or leave it in a workgroup?
    • And so on.

    The answers you provide for these questions and other questions will determine what property/value pairs you include in your CustomSettings.ini file. As an example of how to perform a fully automated LTI deployment, let's change the default CustomSettings.ini to the following:
    [Settings]
    Priority=Default
    Properties=MyCustomProperty
    [Default]
    OSInstall=YES
    SkipAdminPassword=YES
    SkipApplications=YES
    SkipAppsOnUpgrade=YES
    SkipBDDWelcome=YES
    SkipBitLocker=YES
    SkipCapture=YES
    SkipComputerName=YES
    SkipComputerBackup=YES
    SkipDeploymentType=YES
    DeploymentType=NEWCOMPUTER
    SkipDomainMembership=YES
    JoinDomain=CONTOSO
    DomainAdmin=Administrator
    DomainAdminDomain=CONTOSO
    DomainAdminPassword=Pa$$w0rd
    SkipFinalSummary=YES
    SkipLocaleSelection=YES
    KeyboardLocale=en-US
    UserLocale=en-US
    UILanguage=en-US
    SkipPackageDisplay=YES
    SkipProductKey=YES
    SkipSummary=YES
    SkipTaskSequence=YES
    TaskSequenceID=WIN7_001
    SkipTimeZone=YES
    TimeZoneName=Central Standard Time
    SkipUserData=Yes
    Note:
    The blank lines in the listing above are there only to make the contents of the file more readable, and they can be omitted if desired.
    Figure 3 shows what this looks like after we have copied and pasted this into the Rules tab:

    Figure 3: Example of a CustomSettings.ini file for a fully automated LTI deployment
    We will also need to make changes to the default BootStrap.ini file in order to automate our deployment. Figure 4 shows what our new BootStrap.ini file will need to look like:

    Figure 4: Example of a BootStrap.ini file for a fully automated LTI deployment
    In the next article we will examine these two edited files line by line to understand them. But for now, if you have completed the walkthrough in the previous article, just make the changes indicated to these two files and save them. Then complete the steps in the two sections that follow.
    Updating the Deployment Share

    Updating a deployment share creates Windows PE boot images we can use for initiating deployment. We learned how to update a deployment share in the previous article of this series. In fact, we updated our deployment share in the previous article, so why do we have to update it again? Because we made changes to the BootStrap.ini file. Any time you make a change to your BootStrap.ini file, you must update your deployment share. So if you're following along, update your deployment share now, then burn the LiteTouchPE_x86.iso file to CD-R/W media using third-party CD/DVD-burning software.
    Launching the Unattended Install

    Now turn on your bare-metal (no OS or partitions) destination computer, making sure it is connected to the network where your MDT computer resides. Insert the Windows PE CD you burned in the previous step, and sit back and watch. Windows PE will boot and display a blue screen with a Solution Accelerators banner across the bottom. Behind the scenes, Windows PE will establish a connection to your deployment share using the credentials provided in your BootStrap.ini file. Once this connection has been established, the installation will begin and an Installation Progress dialog box will be displayed. Your computer will reboot several times until finally, without the need of you supplying any further keystrokes, the Windows 7 desktop will appear and your install will be finished.
    Conclusion

    This article walked you through the steps for performing a fully automated LTI deployment using MDT 2010. The next article in this series will dig deeper into the CustomSettings.ini and BootStrap.ini property/value pairs you can use for automating LTI deployment




  8. #8
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part8.html
    Part 8: Understanding LTI Configuration Files


    Tip:
    You can find more information about automating LTI deployment in the Windows 7 Resource Kit from Microsoft Press. I'm the lead author for this Resource Kit and I also maintain the Unofficial Support Site for the Windows 7 Resource Kit where you will find the latest updates and other useful information.
    In the previous article of this series we learned how to modify the CustomSettings.ini and BootStrap.ini files of MDT 2010 in order to fully automate a Lite Touch Installation (LTI) of Windows 7 Enterprise. In this article we will dig deeper into modifying these two files to control the LTI process.
    Understanding BootStrap.ini

    BootStrap.ini is one of two configuration files used by MDT for controlling the deployment process (the other configuration file is CustomSettings.ini). Both of these files are located in the Control folder of the deployment share. This means that these files are specific to the deployment share. In other words, if you have more than one deployment share, each share will have its own configuration files for controlling deployments made using that share.
    BootStrap.ini is used during the initial connection process when the destination computer, booted using the LiteTouch Windows PE image, connects to the deployment share to begin the installation process. This means that BootStrap.ini must contain any information needed to successfully establish a connection between the destination computer and the deployment share.
    The BootStrap.ini file used in the previous article of this series looked like this:
    [Settings]
    Priority=Default

    [Default]
    DeployRoot=\\SEA-DC1\DeploymentShare$
    UserID=Administrator
    UserDomain=CONTOSO
    UserPassword=Pa$$w0rd
    KeyboardLocale=en-US
    SkipBDDWelcome=YES
    You can see that BootStrap.ini consists of two sections: Settings and Default. The Settings section is required and contains only one property called Priority. This property tells MDT the order in which to parse the remaining sections of the configuration file. Since there is only one remaining section (Default) that is the value assigned to Priority.
    The Default section is where the work gets done. Specifically:

    • The DeployRoot property specifies the UNC path to the deployment share that will be used for the install. This is required information.
    • The UserID, UserDomain and UserPassword specify the credentials that the destination computer running Windows PE will used to connect to the deployment share. This is required information. In the sample BootStrap.ini file above, the domain Administrator account is used. For security reasons, in a real-world environment you would not use this account. Instead, you should create a new user account used solely for deployment purposes (no one should log on to a computer using this account). For example, you could create a domain account named MDT for this purpose. Because of the NTFS and shared folder permissions assigned to the deployment share, the MDT account only needs to be a member of the Domain Users group—it doesn't need to be a member of the Domain Admins group. Note that the password for this account is stored in unencrypted form in the BootStrap.ini file.
    • The KeyboardLocale property specifies the locale for the keyboard attached to the destination computer. The keyboard locale can be specified either in text (for example, en-us) or hexadecimal (for example, 0409:00004009) form. You can specify multiple values by separating them with semicolons. If this property is omitted from BootStrap.ini, the Windows Deployment Wizard will use the keyboard locale configured in the image being deployed.
    • SkipBDDWelcome = YES prevents the opening screen ("Welcome Windows Deployment") of the Windows Deployment Wizard from being displayed. This is required if you want to fully automate LTI.

    The above six properties are the only properties that can be included in BootStrap.ini.
    Remember—if you change anything in your BootStrap.ini file, you must update your deployment share in order to regenerate the LiteTouch Windows PE images contained in the Boot folder of the share.
    Understanding CustomSettings.ini

    CustomSettings.ini is the other configuration file and is also specific to each deployment share. Once BootStrap.ini has done its work, CustomSettings.ini takes over and controls the rest of the deployment process. The CustomSettings.ini file used in the previous article of this series looked like this:
    [Settings]
    Priority=Default
    Properties=MyCustomProperty

    [Default]
    OSInstall=YES
    SkipAdminPassword=YES
    SkipApplications=YES
    SkipAppsOnUpgrade=YES
    SkipBDDWelcome=YES
    SkipBitLocker=YES
    SkipCapture=YES
    SkipComputerName=YES
    SkipComputerBackup=YES
    SkipDeploymentType=YES
    DeploymentType=NEWCOMPUTER
    SkipDomainMembership=YES
    JoinDomain=CONTOSO
    DomainAdmin=Administrator
    DomainAdminDomain=CONTOSO
    DomainAdminPassword=Pa$$w0rd
    SkipFinalSummary=YES
    SkipLocaleSelection=YES
    KeyboardLocale=en-US
    UserLocale=en-US
    UILanguage=en-US
    SkipPackageDisplay=YES
    SkipProductKey=YES
    SkipSummary=YES
    SkipTaskSequence=YES
    TaskSequenceID=WIN7_001
    SkipTimeZone=YES
    TimeZoneName=Central Standard Time
    SkipUserData=Yes
    The above CustomSettings.ini file contains the same two sections (Settings and Default) that BootStrap.ini contains. CustomSettings.ini can contain additional sections however. For example, you can include additional sections for deploying Windows to specific makes and models of computers or specific locations on your network. We'll examine this in a later article of this series.
    The Default section in the above example contains a number of different property/value pairs. This is only a small subset however of the almost 300 different properties you can specify to control various aspects of the deployment process. There are essentially two types of properties used in the example above: "skip" properties and other properties.
    The "skip" properties are those that determine whether a particular page of the Windows Deployment Wizard is displayed or not during installation on the destination computer. For example, if SkipComputerName=YES is specified, the Configure The Computer Name page of the wizard is not displayed during installation; if SkipComputerName=NO, the page is displayed and a user sitting at the destination computer will have to respond in order to proceed with the installation. If you want to fully automate an installation, you need to specify YES for all possible skip properties, and the example above does this. In other words, the full list of skip properties is as follows:
    SkipAdminPassword=YES
    SkipApplications=YES
    SkipAppsOnUpgrade=YES
    SkipBDDWelcome=YES
    SkipBitLocker=YES
    SkipCapture=YES
    SkipComputerName=YES
    SkipComputerBackup=YES
    SkipDeploymentType=YES
    SkipDomainMembership=YES
    SkipFinalSummary=YES
    SkipLocaleSelection=YES
    SkipPackageDisplay=YES
    SkipProductKey=YES
    SkipSummary=YES
    SkipTaskSequence=YES
    SkipTimeZone=YES
    SkipUserData=Yes
    The advantage of including all of these lines in your CustomSettings.ini file is that you can change any of them to NO if you want the user involved at some point during deployment. For example, if you want the user to choose whether or not to enable BitLocker Drive Encryption on the computer, all you need to do is change the line SkipBitLocker=YES to SkipBitLocker=NO in your CustomSettings.ini file and the Specify The BitLocker Configuration page of the Windows Deployment Wizard will be displayed during installation.
    If you are only interested in fully automating LTI however, you can replace all of the above skip properties with the following two lines lines:
    SkipWizard=YES
    SkipFinalSummary=YES
    The first line causes the entire Windows Deployment Wizard to be skipped (almost). The second line causes the final Operating System Deployment Completed Successfully line to be skipped so that the user doesn't have to click OK to end the install.
    In other words, our previous and somewhat long CustomSettings.ini file is now reduced to this:
    [Settings]
    Priority=Default
    Properties=MyCustomProperty

    [Default]
    OSInstall=YES
    SkipWizard=YES
    SkipFinalSummary=YES
    DeploymentType=NEWCOMPUTER
    JoinDomain=CONTOSO
    DomainAdmin=Administrator
    DomainAdminDomain=CONTOSO
    DomainAdminPassword=Pa$$w0rd
    KeyboardLocale=en-US
    UserLocale=en-US
    UILanguage=en-US
    TaskSequenceID=WIN7_001
    TimeZoneName=Central Standard Time
    What about the remaining properties in the Default section of this shortened CustomSettings.ini file? These "other" properties provide the information that the user would have had to manually enter if the pages of the Windows Deployment Wizard were displayed during installation. Specifically:
    OSInstall=YES
    This line indicates that deployment is authorized to proceed. If you omit this line, deployment will proceed anyways by default.
    DeploymentType=NEWCOMPUTER
    This line indicates the destination computer is a new computer that has never been a member of the network. Other possible values for this property are REFRESH, REPLACE and UPGRADE.
    JoinDomain=CONTOSO
    DomainAdmin=Administrator
    DomainAdminDomain=CONTOSO
    DomainAdminPassword=Pa$$w0rd
    These lines indicate that the computer will be joined to the CONTOSO domain during installation. Note that this example uses the domain Administrator account for this purpose, but you can use a member of the Domain Users account for this purpose such as the MDT user account created earlier for BootStrap.ini.
    KeyboardLocale=en-US
    UserLocale=en-US
    UILanguage=en-US
    These lines indicate the keyboard locale and the user locale and language settings. I think the first line is optional since it is also specified in BootStrap.ini, but if you don't include the other two lines the Locale Selection page of the Windows Deployment Wizard will be displayed during installation.
    TaskSequenceID=WIN7_001
    This line indentifies the task sequence that will be used for the installation.
    TimeZoneName=Central Standard Time
    This line indicates the time zone to be configured on the computer.
    Are these the only properties you need to include in CustomSettings.ini to fully automate LTI? It depends, if you are not installing any packages or applications as part of your installation, and if you are not migrating user state information during the installation, and if you are not configuring BitLocker on the destination computer, then the above shortened CustomSettings.ini file is probably all you need.
    For example, what if you want to install a language pack as part of your installation? To do this, you must first add the language pack to the Packages folder of your deployment share. Then you examine the Packages.xml file in the Control folder of your deployment share to determine the GUID associated with the language pack. Finally, you include the line LanguagePacks001=value in your CustomSettings.ini file where value is the GUID of the language pack. We'll walk through this process and other customizations of automated LTI in future articles in this series.
    One final question: How did I know that I needed to include the line LanguagePacks001=value in my CustomSettings.ini file if I wanted to include a language pack in my install? Simple—read the manual! You should familiarize yourself with the following topics in the Microsoft Deployment Toolkit 2010 Documentation Library, a Help (.chm) file installed as part of MDT 2010:

    • Providing Properties for Skipped Windows Deployment Wizard Pages – This topic lists the properties you need to include in CustomSettings.ini when you skip various pages of the Windows Deployment Wizard.
    • Property Definition – This topic lists all the various properties you can include in CustomSettings.ini and what they are used for.

    Both of these topics can be found in the Help file under Microsoft Deployment Toolkit Reference\Properties and we'll be referring to the information they contain frequently in future articles of this series




  9. #9
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part9.html
    Part 9: Deploying 32-bit vs. 64-bit Windows


    Tip:
    You can find more information about automating LTI deployment in the Windows 7 Resource Kit from Microsoft Press. I'm the lead author for this Resource Kit and I also maintain the Unofficial Support Site for the Windows 7 Resource Kit where you will find the latest updates and other useful information.
    In the previous articles of this series we have looked at what is new in MDT 2010 and how to automate basic deployments of Windows 7 Enterprise edition using MDT 2010. In this article we are going to pause for a moment and consider the pros and cons of deploying 32-bit vs. 64-bit Windows.
    Is Now The Time To Deploy 64-bit Windows?

    The Windows client operating system has had a 64-bit version available since Windows XP Professional x64 Edition was released in 2004. Unfortunately third-party driver support for this version of Windows was limited at the time, which meant that users who installed it were often unable to use their printers, scanners, and other peripherals. When Windows Vista became available in early 2007, it boasted much improved third-party 64-bit driver support, and some organizations who decided to deploy Vista chose to deploy an x64 edition instead of an x86 version to take advantage of the ability of 64-bit Windows to run more applications at the same time and to use more than the 3 GB of RAM that 32-bit Windows is capable of using. Unfortunately some organizations which chose this path without proper planning soon discovered that older 64-bit AMD and Intel systems on which Vista x64 was installed were only able to use 3 GB of RAM even when 4 GB or more RAM was installed in them. In other words, organizations sometimes discovered that the promised performance benefits of using 64-bit Windows were not achieved.
    So where does this leave us today? Windows 7 has been released to manufacturing (RTM) and is already available for volume-licensed customers. If your organization is currently running Windows XP on your client computers and you are eager to move forward with migrating your client computers to Windows 7, should you take the plunge and deploy only 64-bit Windows 7 if the chipsets in all your systems support it? My answer is a resounding YES and I suggest that there is virtually no reason any longer to prefer 32-bit over 64-bit Windows, provided you are going to deploy Windows 7 on x64 systems that are only a year or two old.
    Here is my short list of reasons why you should choose a 64-bit Windows 7 edition over its corresponding 32-bit edition:

    • If you want to get the best performance possible, there are three things you can do: use a faster processor, add more RAM, or replace your drive with a Solid State Disk (SSD) drive. Processors are often tied to motherboards, so replacing them is not trivial. RAM is cheap now, and boosting your system's memory to 4, 8 or even 16 GB will not empty your bank account. Good SSDs are still very expensive however—much more so than RAM. So if you want to boost your performance while keeping your budget under your control, adding lots of RAM is the way to go, and 64-bit Window 7 Ultimate edition can use up to 192 GB of RAM if your system's motherboard can hold that much. So if you want the best performance at the best price, go with 64-bit Windows over 32-bit provided your system hardware supports addressing more than 4 GB of RAM. And which systems support this today? Almost anything you can buy. For example, the Intel x58 workstation chipset includes 6 DRAM sockets, and 12 6 x 2 GB = 12 GB of DDR3 DRAM costs less than $200. Even quad-core I7 processors are only about $250.
    • The 64-bit version of Windows 7 only occupies a couple of more GB on your hard drive than the 32-bit version. If you are really constrained for hard drive space (i.e. hard drive 32 GB or less) then you might prefer installing 32-bit Windows over 64-bit. But if your system has such a small hard drive, you're better off buying a large one. Even large SSDs are beginning to rapidly fall in price these days.
    • If your users rely on some mission-critical 16-bit applications then you might consider installing the 32-bit version of Windows 7 instead of the 64-bit version. That's because 64-bit Windows 7 doesn't support running 16-bit applications. However, you can get around this issue by using Windows Virtual PC and the Windows XP Mode environment, which lets users run a virtual instance of a 32-bit Windows XP operating system on their Windows 7 computers so that users can run older applications that are incompatible with Windows 7 (or with 64-bit Windows 7) while still being able to take advantage of the many enhancements and new features of Windows 7. There's one catch however: the user's system must support hardware virtualization (Intel VT or AMD-V) in order to run Windows Virtual PC and the Windows XP Mode environment, and usually only higher-end client systems less than about a year old include support for hardware virtualization. And if you need a more centralized and manageable way of mitigating application compatibility issues on desktop computers using virtualization, be sure to check out Microsoft Enterprise Desktop Virtualization (MED-V), a core component of the Microsoft Desktop Optimization Pack (MDOP) for Software Assurance (SA). MED-V uses Microsoft Virtual PC to create, deliver and manage corporate Virtual PC images on any Windows-based desktop. On the other hand, now may be the time when you should finally get serious about recoding your old mission-critical 16-bit applications as 64-bit applications.
    • Virtually all peripherals sold in the last couple of years have 64-bit drivers available for them. Most peripherals these days use USB as their interface with the computer. Windows Virtual PC and the Windows XP Mode environment supports USB. The result? No problem!
    • If your organization is really constrained in their budget—which may be typical during a recession or downturn like the one much of the world is currently experiencing—then you may be able to make a case for keeping your older computer systems and migrating them to 32-bit Windows 7. On the other hand, when you make your case you should consider the cost of lost productivity caused by the poor performance of these older systems. And if your business is that fiscally constrained, maybe you should just stay with Windows XP or Windows 2000 or Windows 98 or whatever you're currently using.
    • Finally, if you are a developer and your dev system uses 32-bit Windows, you can only do 32-bit development on your system. If your dev system is 64-bit, you can do both 32- and 64-bit development. I have heard of some issues when debugging applications using Visual Studio on 64-bit Windows that were more complicated and required workarounds compared with running Visual Studio on 32-bit Windows, but I'm not a developer and I can't understand these issues in any depth. If you want to learn more, read Visual Studio: Why is there no 64 bit version? (yet).

    Considerations when using MDT 2010 with 64-bit Windows 7

    MDT 2010 comes in two versions: x64 and x86. Both versions of MDT 2010 support deploying both x86 and x64 Windows operating systems. And both versions of MDT 2010 require version 2.0 of the Windows AIK.
    Windows AIK 2.0 however also comes in both x86 and x64 versions. And as the Deployment Guys have pointed out, if you are running the 32-bit version of Windows AIK 2.0 on a 32-bit Windows 7 technician computer, you can create catalogs and answer files for both x64 and x86 custom images. On the other hand, if you are running 64-bit version of Windows AIK 2.0 on a 64-bit Windows 7 computer, you cannot create catalogs or answer files for x86 custom images. And you can not run the 64-bit version of Windows AIK 2.0 on a 32-bit Windows 7 computer.
    On the other hand, if you are only deploying 64-bit Windows 7, you can install MDT 2010 x64 and Windows AIK 2.0 x64 on a technician computer running Windows 7 x64 and not worry about any of this!
    Conclusion and Additional Resources

    Clearly in most cases the pros of migrating your client computers to 64-bit Windows 7 outweigh the cons in most cases. Because of this, the remaining articles in this Deploying Windows 7 series will focus on deploying Windows 7 Enterprise x64 using MDT 2010. Finally, here are a few resources you should check out concerning 64-bit Windows:







  10. #10
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part10.html
    Part 10: Capturing and Deploying an Image of a Reference Computer


    Introduction

    In articles 6 and 7 of this series we examined how to perform a simple, automated deployment of Windows 7 Enterprise by performing a Lite Touch Installation (LTI) using MDT 2010. Then in article 8 we examined the CustomSettings.ini and Bootstrap.ini files in detail and how these two configuration files can be used to customize the deployment process by making it more automated. In larger organizations however, performing one-off installs of Windows is too simplistic. Instead, you will want to do first create a reference computer, that is, a computer that is configured exactly how you want your users' computers to be configured. Then you will want to capture the image of this reference computer and import the captured image into your deployment share. Finally, you will want to deploy this captured image to your users' computers, that is, the target computers for the deployment. This is what we will look at in this present article.
    Step 1: Install the Reference Computer and Capture its Image

    After your planning work has been done, the first step in image-based deployment is to install your reference computer. As discussed in article 9 of this series, we are going to focus here on deploying Windows 7 Enterprise x64 edition from here on out in this series of articles. So begin by opening the Deployment Workbench on your technician computer, expand your deployment share, right-click on the Operating Systems folder, and select Import Operating System. Then follow the steps of the Import Operating System wizard to import a full set of source files from your Windows 7 Enterprise X64 DVD. Once you have finished the import process, your Deployment Workbench will look like Figure 1 below:

    Figure 1: Windows 7 Enterprise x64 edition has been imported into the deployment share
    Tip:
    To speed the OS import process, first copy all the files and folders from the Windows DVD to a local folder on your technician computer, then import the OS from this local folder instead of from the DVD itself.
    Next, create a new task sequence for deploying Windows onto your reference computer. In your deployment share, right-click on the Task Sequences node and select New Task Sequence to start the wizard. Type WIN7EX64_REF_001 as the task sequence ID and give the task sequence a descriptive name as shown in Figure 2 below:

    Figure 2: Creating a task sequence for deploying Windows onto the reference computer
    On the next page, select the Standard Client Task Sequence template. Then on the Select OS page, select the Windows 7 Enterprise x64 source files you previously imported (Figure 3):

    Figure 3: Associating an operating system with the task sequence
    Complete the New Task Sequence Wizard in the usual way. Your new task sequence will be displayed in Deployment Workbench along with other task sequences you previously created (see Figure 4):

    Figure 4: There are two task sequences in this deployment share
    Now, before you deploy Windows to your reference computer, you need to make some changes to the CustomSettings.ini file on your technician computer. Right-click on your deployment share and select Properties, then select the Rules tab to display the contents of CustomSettings.ini. Modify what you see here so that it looks like Figure 5 below:

    Figure 5: Modifying the CustomSettings.ini file for deploying Windows to the reference computer
    Let us compare our new CustomSettings.ini file with the one we previously used in article 7 of this series for performing a completely unattended install. The table below shows these two configuration files side by side with the new file on the left and with differences highlighted in bold:

    CustomSettings.ini file for deploying Windows to reference computer
    Customsettings.ini file for performing a completely automated LTI
    [Settings]
    Priority=Default
    Properties=MyCustomProperty
    [Default]
    OSInstall=YES
    SkipAdminPassword=YES
    SkipApplications=YES
    SkipAppsOnUpgrade=YES
    SkipBDDWelcome=YES
    SkipBitLocker=YES
    SkipCapture=NO
    SkipComputerName=YES
    SkipComputerBackup=YES
    SkipDeploymentType=YES
    DeploymentType=NEWCOMPUTER
    SkipDomainMembership=YES
    SkipFinalSummary=YES
    SkipLocaleSelection=YES
    KeyboardLocale=en-US
    UserLocale=en-US
    UILanguage=en-US
    SkipPackageDisplay=YES
    SkipProductKey=YES
    SkipSummary=YES
    SkipTaskSequence=NO
    SkipTimeZone=YES
    TimeZoneName=Central Standard Time
    SkipUserData=Yes
    [Settings]
    Priority=Default
    Properties=MyCustomProperty
    [Default]
    OSInstall=YES
    SkipAdminPassword=YES
    SkipApplications=YES
    SkipAppsOnUpgrade=YES
    SkipBDDWelcome=YES
    SkipBitLocker=YES
    SkipCapture=YES
    SkipComputerName=YES
    SkipComputerBackup=YES
    SkipDeploymentType=YES
    DeploymentType=NEWCOMPUTER
    SkipDomainMembership=YES
    JoinDomain=CONTOSO
    DomainAdmin=Administrator
    DomainAdminDomain=CONTOSO
    DomainAdminPassword=Pa$$w0rd
    SkipFinalSummary=YES
    SkipLocaleSelection=YES
    KeyboardLocale=en-US
    UserLocale=en-US
    UILanguage=en-US
    SkipPackageDisplay=YES
    SkipProductKey=YES
    SkipSummary=YES
    SkipTaskSequence=YES
    TaskSequenceID=WIN7_001
    SkipTimeZone=YES
    TimeZoneName=Central Standard Time
    SkipUserData=Yes
    First, note that the value of the SkipTaskSequence property has been changed from YES to NO, and there is now no TaskSequenceID property. Making this change means that the Select A Task Sequence To Execute On This Computer page of the Windows Deployment Wizard will be displayed on the client (the reference computer) when the install is performed.
    Second, note that the value of SkipCapture has been changed from YES to NO. This means that the Specify Whether To Capture An Image page of the Windows Deployment Wizard will also be displayed on the client when the install is performed.
    Also, note that the JoinDomain and related properties are no longer specified. This is important. If you do not omit these lines, the Specify Whether To Capture An Image page of the wizard would not be displayed.
    Now update your deployment share to create a LiteTouchPE_x64.iso file you can burn to a CD so you can boot your reference computer. To speed this up, you can clear the x86 checkbox on the General tab of the properties of your deployment share as shown in Figure 6 below. When you do, this MDT will only create a LiteTouchPE_x64.iso file when you update your deployment share and will not create a LiteTouchPE_x86.iso file. This will speed up the process of updating your deployment share if you are only deploying the 64-bit version of Windows.

    Figure 6: Configuring MDT to only create a 64-bit Windows PE image
    At this point, you will want to add applications, packages and (if needed) out-of-box drivers to your deployment share. The goal here is to perform any customizations needed before you deploy Windows onto your reference computer. We will examine how to perform such customizations in a later article of this series.
    At this point you are ready to deploy Windows onto your reference computer, so boot your reference computer, insert the 64-bit WinPE CD created by MDT, and wait for MDT to do its magic. When the Select A Task Sequence To Execute On This Computer page of the Windows Deployment Wizard appears, select the WIN7EX64_REF_001 task sequence from the list of task sequences displayed. Then when the Specify Whether To Capture An Image page appears, select the Capture An Image Of This Computer option and accept the default capture location and file name, which in this example will be:
    Location: \\SEA-DC1\DeploymentShare$\Captures
    File name: WIN7EX64_REF_001
    The install will then proceed. Note that the install will take quite a bit longer than a simple LTI because once Windows has been installed on the reference computer and has been sysprepped, MDT will capture the image and upload it to the Captures folder of your deployment share, and capturing the image as a .wim file and copying it over the network to the deployment share can take some time. When the capture process is completed, the OOBE will be displayed on your reference computer (since it was sysprepped by MDT).
    Step 2: Importing the Captured Image

    The next step is to import the captured image of the reference computer. This captured image has been uploaded to the Captures folder of the deployment share as shown in Figure 7 next:

    Figure 7: The captured image of the reference computer
    To import this captured image into MDT, right-click on the Operating Systems folder in your deployment share and select Import Operating System. On the Source page of the Import Operating System Wizard, select Custom Image as shown in Figure 8:

    Figure 8: Importing a custom image
    Click Next. On the Image page, browse to select the captured image (Figure 9). If you need to conserve disk space on the technician computer, you can select the checkbox to move the captured image instead of copying it.

    Figure 9: Selecting a custom image to import
    Click Next. On the Setup page, leave the default option of Setup And Sysprep Files Are Not Needed selected (Figure 10):

    Figure 10: The Setup page of the Import Operating System Wizard
    Now finish the wizard, accepting the defaults, to import the captured image into your deployment share. The captured image will be displayed in the Operating Systems folder of your deployment share (Figure 11) which means you can now deploy it to your target computers:

    Figure 11: The captured image is ready to be deployed
    Step 3: Deploying the Captured Image to Target Computers

    You are now ready to deploy the captured image to target computers. Begin by creating a new task sequence with WIN7EX64_TARGET as its task sequence ID (Figure 12):

    Figure 12: Creating a task sequence for deploying the captured image of the reference computer to your target computers
    Select the Standard Client Task Sequence template, then associate the captured image with the task sequence as shown in Figure 13:

    Figure 13: Associating the captured image of the reference computer with the task sequence
    Now you will probably want to fully automate the deployment of the captured image of your reference computer to your target computers. To do this, open the Rules tab of the properties of your Deployment Share and restore the CustomSettings.ini file to the way it was before (see the right side of the table earlier in this article) with the exception that the TaskSequenceID property should have WIN7EX64_TARGET as its value (Figure 14):

    Figure 14: CustomSettings.ini file for fully automating the deployment of the captured image of the reference computer to target computers
    Once you have modified your CustomSettings.ini file like this, boot one of your bare-metal target computers, insert your WinPE CD, and watch the captured image of your reference computer being automatically deployed to the target computer with no other intervention on your part.





  11. #11
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part11.html
    Part 11: Capturing an Existing Installation


    Introduction

    In the previous article of these series we saw how to use MDT 2010 to deploy Windows 7 to a reference computer and then capture an image of this reference computer so you can deploy it to multiple target computers. The steps involved were as follows:

    • Step 1: Install the reference computer and capture its Image
    • Step 2: Import the captured Image
    • Step 3: Deploying the captured image to target computers

    All three steps can be performed using MDT 2010 alone, that is, without needing Windows Deployment Services or System Center Configuration Manager. This procedure lets you build and deploy a customized Windows 7 image using Lite Touch Installation (LTI) for small- and mid-sized deployments.
    But there is another way you can use MDT 2010 to build, capture and deploy customized Windows 7 images and that is to capture an existing installation of Windows 7 that you have manually customized. The steps for doing this are as follows:

    • Step 1: Install the reference computer and manually customize it
    • Step 2: Capture an image of the reference computer
    • Step 3: Import the captured Image
    • Step 4: Deploying the captured image to target computers

    Note the difference:

    • In the first approach, which is outlined in article 10 of this series, you customize your reference computer using MDT alone. This means you use MDT to deploy the operating system, applications, drivers, and software updates. And if you want to further customize the operating system you can open Windows System Image Manager (Windows SIM) from within MDT to customize the unattend.xml answer file for your installation. Customizing applications however may require some advanced tricks involving your answer file. You have to carefully plan all your customizations ahead of time as the process of using MDT to deploy and capture an image of your reference computer is automated.
    • In the second approach, which is outlined below in this article, you use MDT to deploy Windows (and if desired applications, drivers and software updates) to create your reference computer. Then you log on to your reference computer and manually perform any additional customizations that may be needed. Finally, once your reference computer is fully customized, you use MDT again to capture its image. This capability of using MDT to capture the image of a Windows installation that has already been deployed is new in MDT 2010 and was not possible in MDT 2008 (with MDT 2009 you had to use Windows Deployment Services to create a capture image as described in my earlier article Deploying Vista – Part 21: Working With Capture Images).

    Let us examine the second approach now.
    Step 1: Install the reference computer and manually customize it

    Begin by creating your reference computer. You can do this either by manually installing Windows 7 and the needed applications, drivers and software updates on a system, or you can use MDT 2010 to perform these tasks either manually or by automating them. See my article Deploying Windows 7 – Part 6: Light Touch using MDT 2010 for how to manually deploy an image using MDT and my article Deploying Windows 7 – Part 7: Automated LTI Deployment for how to automate LTI using MDT. Once your reference computer has been deployed, log on to it and customize the operating system and applications as desired.
    Step 2: Capture an image of the reference computer

    Now you are ready to capture an image of your reference computer. To do this, you are going to use the Sysprep and Capture task sequence template, a new type of task sequence template included in MDT 2010. This task sequence does not install Windows on a computer. Instead, it syspreps an existing Windows installation on a computer, reboots the computer into Windows PE, captures a .wim image file of the installation and uploads the captured image to a network share you specify.
    To create a task sequence for doing this, open the Deployment Workbench, expand your deployment share, right-click on the Task Sequences folder and select New Task Sequence. The New Task Sequence wizard opens displaying the General Settings page. Specify a task sequence ID and task sequence name as shown in Figure 1:

    Figure 1: Creating a new task sequence for capturing an existing installation of Windows 7 Enterprise Edition
    On the Select Template page of the wizard, select Sysprep and Capture as the task sequence template to use for creating the new task sequence (Figure 2):

    Figure 2: Select the Sysprep and Capture template
    On the Select OS wizard page, select the image of the operating system you are going to capture (Figure 3). Why do you need to do this if you are not going to install the selected image? Because MDT needs this information to get the appropriate unattend.xml answer file needed to perform the sysprep and capture process.

    Figure 3: Select an image of the OS you are going to capture
    For the remaining steps of the wizard it does not matter what information you provide—just provide something when prompted.
    Now before you use this new task sequence to sysprep and capture an image of your reference computer, I recommend that you restore the CustomSettings.ini and Bootstrap.ini files for your deployment share to their original values. Specifically, change your CustomSettings.ini file back to this:
    [Settings]
    Priority=Default
    Properties=MyCustomProperty

    [Default]
    OSInstall=Y
    SkipAppsOnUpgrade=YES
    SkipCapture=NO
    SkipAdminPassword=YES
    SkipProductKey=YES
    And then change your BootStrap.ini file back to this:
    [Settings]
    Priority=Default

    [Default]
    DeployRoot=\\SEA-DC1\DeploymentShare$
    I recommend these changes because of my own personal experience trying to get the Sysprep and Capture task sequence template working properly.
    Now boot your reference computer normally and log on using an administrator account. Do NOT boot your reference computer using your LiteTouchPE_x64.iso CD or a Windows PE bootable CD—you are not trying to install an image, just sysprep and capture it. Once you have logged on, open a command prompt window and type the following command to manually start the Windows Deployment Wizard on the computer:
    \\<computername>\<share>\Scripts\LiteTouch.vbs
    Here \\<computername>\<share> is the UNC path to your deployment share. Figure 4 shows this command in my test environment:

    Figure 4: Manually launching the Windows Deployment Wizard from the reference computer
    After a few moments the Windows Deployment Wizard will open and you'll be prompted to specify credentials for connecting to your deployment share (Figure 5):

    Figure 5: Supply credentials to connect to your deployment share from your reference computer
    Now, if when you click Next you get an error message like that shown in Figure 6 below, you can try and resolve this issue by either:



    Figure 6: Credentials error
    I have personally tried the first approach and got it working. The fix described in the second approach was just published the day before writing this article so I have not had time to test it yet.
    Anyways, assuming that the credentials you supplied are accepted, clicking Next displays the wizard page asking you select a task sequence. Choose the task sequence you created earlier for sysprepping and capturing an existing installation (Figure 7).

    Figure 7: Select your sysprep and capture task sequence
    On the next wizard page, select Capture An Image Of This Reference Computer and accept the default image upload location (\\<computername>\<share>\Captures) and name for the captured image (<tasksequenceID>.wim) as shown in Figure 8 below. Note that if you replaced <computername> with <IPaddress> on the credentials page you should do the same here as well.

    Figure 8: Specifying a name and upload location for image to be captured
    Click Next and review the summary page (Figure 9).

    Figure 9: Summary of what your sysprep and capture task sequence will do
    Now click Begin, and shortly you should see a progress indicator showing the image being sysprepped (Figure 10).

    Figure 10: The reference computer is being sysprepped and captured
    If sysprep fails with an error, go back and try one of the fixes described earlier. Otherwise, everything should work and the captured image of your reference computer will be uploaded to the Captures folder in your deployment share.
    Steps 3 and 4 : Import the captured image and deploy it to target computers

    Now you can import the captured image of your reference computer using the process outlined in "Step 2: Import the captured Image" of my previous article (Deploying Windows 7 - Part 10: Capturing and Deploying an Image of a Reference Computer). Once this is done, you can automatically deploy the captured image to your target computers using the procedure outlined in my article Deploying Windows 7 - Part 7: Automated LTI Deployment.





  12. #12
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part12.html
    Part 12: Planning for Application Compatibility


    An important issue to consider when planning any kind of desktop deploying is application compatibility. If you are upgrading to Windows 7 from Windows Vista, this will hopefully not be a Bit issue because applications designed for Windows Vista should, in almost all cases, work properly on Windows 7. If you are migrating desktop computers from Windows XP to Windows 7 however, you will need to take time to give careful consideration to what you may need to do in order to ensure your applications will function properly on the new operating system.
    Why Applications Break

    What are the reasons applications designed for Windows XP sometimes “break” when you try and run them on Windows 7? A couple of the main problem areas are:

    • User Account Control – Applications that require administrative privileges and which were designed for Windows XP may not work properly on Windows 7 even if the user is a member of the local Administrators group on his computer. Microsoft has tried to minimize this issue by including application compatibility shims in Windows 7 for many common applications, and these shims will often even allow users to run such applications as standard users instead of administrators. Some older applications however simply will not work on Windows 7, even when the user is a local admin. In such a case you may need to use one of the following tools described below to run your older application separately from the Windows 7 operating system: Virtual PC 2007 SP1, Windows Virtual PC with Windows XP Mode, Microsoft Enterprise Desktop Virtualization, or Microsoft Application Virtualization.
    • User profile structure and versioning – The user profile structure was redesigned in Windows Vista to make it more rational. If an older application was designed to access user profile files in the correct way using API function calls and environment variables, these user profile changes should not impact whether the application will run or not in Windows 7 since Windows 7 includes directory junctions for common Windows XP profile folders like My Documents. If however an older application has Windows XP-style profile folders hard-coded into the application's code, then the application could fail under Windows 7 for this reason. Another issue that can prevent an older application from running is if the application is confused by the version number of Windows 7. In other words, when you try and start the application, it checks the OS version number, finds this is 6.1, and was coded not to know what this means and therefore does not start. In such cases as these where only a few users are affected, these users can try using the Program Compatibility Troubleshooter in Windows 7 and see if this resolves the issue. If a lot of users will be affected, you can try using the Application Compatibility Toolkit to try and analyze the problem and develop a “fix” you can deploy to the affected computers.

    Tools for Mitigating Application Compatibility Issues

    Microsoft provides a number of tools you can use to ensure you can still use your older applications after upgrading or migrating to Windows 7. These tools are basically of three types and these are my own "friendly" names for each category:

    • One-off tools – Try using these tools first if only a few users are going to be affected.
    • Large-scale tools – Large-scale enterprise environments should consider using these tools first.
    • Virtualization tools – When all else fails, virtualize.

    Let us briefly examine each category.
    One-Off Tools for Running Older Applications

    Let us say you are retiring your old Windows XP computers for newer ones running Windows 7. Afterwards, several users indicate they need an older program installed on their computers. You try installing the program and something like this appears (Figure 1):

    Figure 1: Warning from Program Compatibility Assistant
    If you see a warning like this when installing an older program on Windows 7, you can click Check For Solutions Online and see if Microsoft has previously identified this issue and has created a fix for it.
    If the older program seemed to install OK on Windows 7 but problems arise when users try and run it, they can click Start, type program compatibility in the Start menu search box, and press ENTER to launch the Program Compatibility Troubleshooter (Figure 2). Doing this will cause Windows to try and find issues with installed applications, determine whether fixes are available, and apply the fixes to try and resolve the issues.

    Figure 2: Running the Program Compatibility Troubleshooter
    If this does not work the user can right-clicking on the executable program file in Windows Explorer, selecting Properties, selecting the Compatibilty tab, and manually trying different program compatibility modes to try and get the application to work properly (Figure 3).

    Figure 3: Selecting a program compatibility mode
    If none of these approaches work, see Virtualization Tools below.
    Large-Scale Tools for Analyzing and Mitigating Application Compatibility Issues

    If your organization has hundreds or thousands of users running dozens of different applications on their computers, you will definitely need to take a more proactive approach than the after-the-fact method described in the previous section above. In this case the tool you will want to use is the Application Compatibility Toolkit (ACT) version 5.5. ACT is a collection of tools and documentation that you can use to evaluate and mitigate application compatibility issues prior to beginning the deployment of Windows 7 in your environment. ACT helps you understand your application compatibility situation by identifying which of your existing applications are compatible with Windows 7 and which might require further testing. ACT can also help you develop compatibility fixes for problem applications which you can then deploy as application mitigation packages to affected systems. ACT is a complex tool that takes some getting used to—for more information on using ACT see Chapter 5 of the Windows 7 Resource Kit from Microsoft Press. And you can download ACT 5.5 from here.
    Virtualization Tools for Running Older Applications

    Whether you are a smaller shop that has found that the built-in application compatibility tools in Windows 7 are not sufficient, or a large enterprise that has discovered that application compatibility issues for certain older business-critical applications cannot be resolved using ACT, you still have several ways you can proceed in order to keep those older applications running for users who need them. Virtualization is the key here, and your choices from Microsoft are as follows:
    Virtual PC 2007 SP1 – If you migrated older computers to Windows 7 you can install Virtual PC 2007 SP1 on these computers so the users of these computers can install their problematic older applications in a separate instance of Windows XP (or an older version of Windows) running in a separate virtual machine. Note that this solution has some limitations. For example, Virtual PC does not include support for USB devices. You can download Virtual PC 2007 SP1 from here.
    Windows XP Mode and Windows Virtual PC - Windows Virtual PC lets you run multiple Windows environments including Windows XP Mode from your Windows 7 desktop. By installing your problematic older applications into the Windows XP Mode environment, users can run these applications directly from the Start menu. The advantages of this virtualization approach over Virtual PC 2007 SP1 are:

    • No separate virtual desktop for running the older applications—they are integrated into the Windows 7 desktop.
    • Support for USB devices such as printers, scanners and so on.

    The disadvantage of this approach is that Windows Virtual PC requires processors that support hardware virtualization (Intel-VT or AMD-V). Only desktop computers a year or so old typically support such technologies. So if you migrated older systems from Windows XP to Windows 7 you won't be able to use this method. But if you purchased brand new Windows 7 systems to replace your older Windows XP computers, you may be able to use this approach to run problematic older applications on these computers. You can download Windows XP Mode and Windows Virtual PC from here.
    Microsoft Enterprise Desktop Virtualization – MED-V is an enterprise tool that can be used to deliver Virtual PC images to computers from a central repository where you can create and manage these images. MED-V thus helps reduce application-to-OS compatibility issues, but in a more scalable and managed way than simply installing Virtual PC on each user's computer. Using MED-V, you can manage the entire life cycle of virtual images, provision them to authenticated users in an Active Directory environment, monitor their usage, and more. The user remains unaware of the virtualization running in the background and sees only one desktop environment. MED-V is part of the Microsoft Desktop Optimization Pack (MDOP). For a look at how MED-V works and how you can use it, see Chapter 6 of my free ebook Understanding Microsoft Virtualization Solutions: From the Desktop to the Datacenter from Microsoft Press.
    Microsoft Application Virtualization – Microsoft App-V is an enterprise tool that can be used to centralize the management of the entire application life cycle. Using App-V, administrators can dynamically deliver applications on-demand to users who need them instead of installing them on each user's computer. App-V helps reduce application-to-application conflicts, for example when a user needs to run two different versions of the same application and are unable to install both versions locally on the same machine. App-V also simplifies software update management and makes application compatibility regression testing easier. App-V is also part of MDOP. For a look at how App-V works and how you can use it, see Chapter 4 of my free ebook Understanding Microsoft Virtualization Solutions: From the Desktop to the Datacenter from Microsoft Press




  13. #13
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part13.html
    Part 13: Manual Migration from Windows XP to Windows 7


    Understanding the Refresh Computer Deployment Scenario

    So far we've looked at how to use MDT 2010 to deploy a Windows 7 image onto bare-metal target computers. This is known as the New Computer deployment scenario, whereby a new installation of Windows 7 is deployed to a new computer. In the New Computer scenario, there are no existing user settings or data that need to be migrated, and the Standard Client Task Sequence is used to deploy the captured image of your reference computer onto the target computer.
    But what if our target computers are already in use and are running Windows XP and have user settings and data stored on them? And what if we want to migrate these computers to Windows 7 while retaining the existing user settings and data on each computer? In that case, the user settings and data on each computer must first be saved, then the computer must be wiped, the new operating system is laid down, and finally the user settings and data are restored. This is known as the Refresh Computer deployment scenario, and in addition to using this approach to migrate computers from Windows XP to Windows 7 you can also use it to "repair" user's Windows 7 computers by re-imaging them when they become corrupted.
    Note:
    Why can't one use the Upgrade Computer deployment scenario to migrate computers from Windows XP to Windows 7? Because there is no supported upgrade path from Windows XP to Windows 7, take a look at this link for a list of supported upgrade scenarios. For more information on deployment scenarios, see my earlier article Understanding Deployment Scenarios in my series of articles on deploying Vista.
    Verifying Migration Readiness


    Before you migrate a Windows XP computer to Windows 7, you should make sure the computer is able to run the new operating system. If you are only migrating a small number of computers, you can use the Windows 7 Upgrade Advisor, available from here. For larger migrations however, you should use the Microsoft Assessment and Planning Tool (MAP) 4.0 described in article 3 and article 4 of this series.
    Migrating User Settings and Data


    MDT 2010 includes the User State Migration Tool (USMT) 4.0 and uses this tool to migrate user settings and data during a Refresh or Replace Computer deployment scenario. A new feature of version 4.0 of USMT is support for hard-link migration, which allows user settings and data to remain stored on the computer during a Refresh Computer deployment scenario. With earlier versions of USMT, user state information (user settings and data) had to be copied to a network share or removable media because the computer was wiped during a Refresh Computer deployment scenario, then after the operating system is installed the user state information is restored by copying it back to the computer from the network share or removable media where it was saved.
    With hard-link migration however, the user state remains where it is on the user's computer, hard links are created for the user settings and data files. A hard link is a directory entry for a file on an NTFS file system. Usually each file has a single hard link, meaning the file appears in a single directory on the file system. With hard-link migration however, USMT creates an additional hard link for each user setting or data file so that the file also appears to reside in the temporary C:\MININT folder created by MDT during deployment. Then, instead of wiping the file system from the computer in order to re-image it, MDT 2010 simply deletes all operating system folders and files from the computer—the boot volume is not formatted—while the MININT folder ensures that the user state information is not deleted from the computer. After installation is complete, the user state information is restored to its proper locations by rebuilding the links to the files, and the MININT folder together with its hard links is deleted.
    The benefits of this approach for migrations are threefold:

    1. The migration is faster because the file system does not need to be wiped and recreated during deployment.
    2. The migration is faster because the user state information doesn't need to be copied to a network location, deleted from the computer, and restored.
    3. The deployment is simpler because you do not need to create a separate network share for storing saved user state information.

    Manually Migrating Windows XP Computers to Windows 7


    Now let us try manually migrating a Windows XP computer to Windows 7 using MDT 2010. Begin by customizing the computer, for example by saving a bitmap image file in the My Pictures folder of user Karen Berg (CONTOSO\kberg) as shown in Figure 1:

    Figure 1: Karen's computer is currently running Windows XP and has a photo in her My Pictures folder
    Now on the technician computer, open the properties of your deployment share and configure the BootStrap.ini file to read as follows:
    [Settings]
    Priority=Default
    [Default]
    DeployRoot=\\SEA-DC1\DeploymentShare$
    UserID=Administrator
    UserDomain=CONTOSO
    UserPassword=Pa$$w0rd
    KeyboardLocale=en-US
    SkipBDDWelcome=YES
    Then configure the CustomSettings.ini file to read as follows:
    [Settings]
    Priority=Default
    Properties=MyCustomProperty
    [Default]
    OSInstall=YES
    SkipAdminPassword=YES
    SkipApplications=YES
    SkipAppsOnUpgrade=YES
    SkipBDDWelcome=YES
    SkipBitLocker=YES
    SkipCapture=YES
    SkipComputerName=NO
    SkipComputerBackup=NO
    ComputerBackupLocation=AUTO
    SkipDeploymentType=NO
    SkipDomainMembership=YES
    JoinDomain=CONTOSO
    DomainAdmin=Administrator
    DomainAdminDomain=CONTOSO
    DomainAdminPassword=Pa$$w0rd
    SkipFinalSummary=NO
    SkipLocaleSelection=YES
    KeyboardLocale=en-US
    UserLocale=en-US
    UILanguage=en-US
    SkipPackageDisplay=YES
    SkipProductKey=YES
    SkipSummary=NO
    SkipTaskSequence=NO
    SkipTimeZone=YES
    TimeZoneName=Central Standard Time
    SkipUserData=NO
    UserDataLocation=AUTO
    Then create a new task sequence based on the Standard Client Task Sequence and configure the task sequence to deploy Windows 7 Enterprise edition.
    Now log onto Karen's computer as Administrator, open a command prompt, and type the following command to launch the Windows Deployment Wizard on the computer:
    \\SEA-DC1\DeploymentShare$\Scripts\LiteTouch.vbs
    The wizard will begin by prompting you to select a task sequence (Figure 2):

    Figure 2: Select the task sequence for migrating from XP to Windows 7
    Next, you will be prompted to select the Refresh Computer deployment scenario (Figure 3):

    Figure 3: Note that the Upgrade Computer deployment scenario is not available for Windows XP
    Next, you will be prompted to specify a new name for the computer or accept the existing name (Figure 4):

    Figure 4: Specify the computer name
    Next, you are prompted to specify how to handle user state information. Leave this set at the default of automatically determining the location and storing the information locally on the computer (Figure 5):

    Figure 5: Using hard-link migration to store user state information locally on the computer
    Next, you are prompted to make an image backup of your computer in case the migration fails. You should always do this, but for this walkthrough we will omit the part where you create the backup to speed things up (Figure 6):

    Figure 6: You should back up the computer before migrating it to Windows 7 (though we are not doing this here)
    Next, review the choices you have made (Figure 7):

    Figure 7: Review your selections
    Now click Begin, and soon a progress bar will indicate that user state information is being captured (Figure 8):

    Figure 8: User state information is being captured and saved on the computer
    After a short time, the computer will reboot and MDT will begin applying the Windows 7 image to the computer. Once Windows 7 has been installed and the computer reboots for the last time, the progress bar will indicate that the captured user state information is being restored (Figure 9).

    Figure 9: User state information is being restored
    This may take a few minutes. Once this is done, Karen Berg can log onto her refreshed computer and when she opens her Pictures library, she sees that the photo is still present, which indicates that her user state information has been successfully migrated (Figure 10):

    Figure 10: The migration of user state information was successful during the XP to Win7 migration
    In the next article of this series we'll examine how to automate this whole process




  14. #14
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part14.html
    Part 14: Automated Migration from Windows XP to Windows 7


    In the previous article of this series, we examined how MDT 2010 together with USMT 4.0 can be used to manually migrate a Windows XP computer to Windows 7 while maintaining the user settings and data on the computer. In this article we are going to fully automate the migration process.
    To do this, use the Deployment Workbench on your MDT computer to open the properties of your deployment share. If you have worked through the previous article of this series then the Bootstrap.ini file for this share will look like this:

    • [Settings]
      Priority=Default
      [Default]
      DeployRoot=\\SEA-DC1\DeploymentShare$
      UserID=Administrator
      UserDomain=CONTOSO
      UserPassword=Pa$$w0rd
      KeyboardLocale=en-US
      SkipBDDWelcome=YES

    This is fine as is. We do not need to modify Bootstrap.ini any further.
    Now examine the CustomSettings.ini file for your deployment share, which should currently look like this:

    • [Settings]
      Priority=Default
      Properties=MyCustomProperty
      [Default]
      OSInstall=YES
      SkipAdminPassword=YES
      SkipApplications=YES
      SkipAppsOnUpgrade=YES
      SkipBDDWelcome=YES
      SkipBitLocker=YES
      SkipCapture=YES
      SkipComputerName=NO
      SkipComputerBackup=NO
      ComputerBackupLocation=AUTO
      SkipDeploymentType=NO
      SkipDomainMembership=YES
      JoinDomain=CONTOSO
      DomainAdmin=Administrator
      DomainAdminDomain=CONTOSO
      DomainAdminPassword=Pa$$w0rd
      SkipFinalSummary=NO
      SkipLocaleSelection=YES
      KeyboardLocale=en-US
      UserLocale=en-US
      UILanguage=en-US
      SkipPackageDisplay=YES
      SkipProductKey=YES
      SkipSummary=NO
      SkipTaskSequence=NO
      SkipTimeZone=YES
      TimeZoneName=Central Standard Time
      SkipUserData=NO
      UserDataLocation=AUTO

    Here is where we need to make several changes in order to automate the migration process.
    First, change this line:

    • SkipComputerName=NO

    to the following:

    • SkipComputerName=YES

    Doing this means you won't be prompted to rename the computer during the migration.
    Next, change these two lines:

    • SkipComputerBackup=NO
      ComputerBackupLocation=AUTO

    to the following:

    • SkipComputerBackup=YES
      ComputerBackupLocation=NONE

    Of course, not backing up the computer before migrating it is not a good idea, but we will do this to speed up the walkthrough.
    Next, change this line:

    • SkipDeploymentType=NO

    to this:

    • SkipDeploymentType=YES

    and add the following line below it:

    • DeploymentType=REFRESH

    Doing this means that you won't be prompted to choose the type of deployment scenario to perform.
    Next, change this line:

    • SkipTaskSequence=NO

    to this:

    • SkipTaskSequence=YES

    Then under this line add another line specifying the task sequence you will use for the migration, which in my own lab environment is the following:

    • TaskSequenceID=XP_TO_W7

    Next, change this line:

    • SkipUserData=NO

    to this:

    • SkipUserData=YES

    Leave this line unchanged:

    • UserDataLocation=AUTO

    This will cause user state information to be captured and restored using hard-line migration.
    Finally, change these two lines:

    • SkipFinalSummary=NO
      SkipSummary=NO

    to read as follows:

    • SkipFinalSummary=YES
      SkipSummary=YES

    Doing this will hide the final summary screen of the Windows Deployment Wizard from the computer's user.
    Having made all of these changes, your CustomSettings.ini file should now look like this:

    • [Settings]
      Priority=Default
      Properties=MyCustomProperty
      [Default]
      OSInstall=YES
      SkipAdminPassword=YES
      SkipApplications=YES
      SkipAppsOnUpgrade=YES
      SkipBDDWelcome=YES
      SkipBitLocker=YES
      SkipCapture=YES
      SkipComputerName=YES
      SkipComputerBackup=YES
      ComputerBackupLocation=NONE
      SkipDeploymentType=YES
      DeploymentType=REFRESH
      SkipDomainMembership=YES
      JoinDomain=CONTOSO
      DomainAdmin=Administrator
      DomainAdminDomain=CONTOSO
      DomainAdminPassword=Pa$$w0rd
      SkipFinalSummary=YES
      SkipLocaleSelection=YES
      KeyboardLocale=en-US
      UserLocale=en-US
      UILanguage=en-US
      SkipPackageDisplay=YES
      SkipProductKey=YES
      SkipSummary=YES
      SkipTaskSequence=YES
      TaskSequenceID=XP_TO_W7
      SkipTimeZone=YES
      TimeZoneName=Central Standard Time
      SkipUserData=YES
      UserDataLocation=AUTO

    Before you perform the deployment, make sure that you have customized the users’ computer, for example, by copying a photo file to the My Pictures folder in her user profile as we did in the previous article of this series.
    Now log onto the user's computer as Administrator, open a command prompt, and type the following command to launch the Windows Deployment Wizard on the computer:
    \\SEA-DC1\DeploymentShare$\Scripts\LiteTouch.vbs
    Instead of having to respond to various prompts of the wizard, the progress bar will immediately be displayed indicating that the user state information on the computer is being captured (Figure 1):

    Figure 1: User state information is being captured
    After a short time, the computer will reboot and MDT will begin applying the Windows 7 image to the computer. Once Windows 7 has been installed and the computer reboots for the last time, the progress bar will indicate that the captured user state information is being restored (Figure 2):

    Figure 2: User state information is being restored
    Once this is done, the user can log onto her refreshed computer and when she opens her Pictures library, she sees that the photo is still present, which indicates that her user state information has been successfully migrated (Figure 3):

    Figure 3: The migration succeeded
    Considerations when Migrating from Windows XP to Windows 7

    Before you jump in and begin migrating all your Windows XP computers to Windows 7, you need to consider a few things.
    First, if your Windows XP computers are old and do not have the hardware to properly support running Windows 7 on them, consider using the Replace Computer deployment scenario instead of the Refresh Computer scenario. In the Replace Computer scenario, MDT first uses USMT to capture user state information and save it to a network share. Then MDT performs a clean installation of Windows 7 on a brand-new computer. Finally, MDT uses USMT to restore the user state information to the new computer. In this scenario, the user gets a new computer and a new operating system but retains her existing user settings and data. Afterwards you send the users' old computers to the recycle mart.
    Second, if your Windows XP computers have older applications that aren't compatible with Windows 7 then you'll need to use the application compatibility tools and strategies outlined in part 12 of this series before you can consider migrating the computers to Windows 7.
    Third, if you plan on upgrading the applications on your Windows XP computers to newer versions of these applications, and if all important user data is redirected for storage on the network, then maybe you shouldn't migrate the computers at all. Instead, consider using the New Computer deployment scenario to deploy Windows 7 together with new applications onto either new or existing hardware, and forget about migrating user settings and data. After all, what better time to start from scratch than when you are migrating your desktop computers from an operating system that is approaching end of life?
    Finally, if you want to customize which user settings and data are migrated and which are not migrated (for example to avoid migrating settings for older applications that are no longer needed) then you need to learn how to customize the XML migration files that govern how USMT works. In this case, you can begin learning more by reading Chapter 7 of the Windows 7 Resource Kit from Microsoft Press. This will give you a good introduction to how USMT can be customized, and if you need to dig deeper into this topic then see the User State Migration Tool 4.0 User's Guide in the TechNet Library here




  15. #15
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part15.html
    Part 15: Configuring the MDT Database


    Understanding the MDT Database

    So far in this series of articles we have learned how to use MDT 2010 to perform a Lite Touch (LTI) deployment of Windows 7 onto a single computer, either manually or fully-automated. But what if you need to deploy Windows 7 onto dozens or even hundreds of computers? What if you want specific names assigned to each computer? What if you want one group of computers to have one set of Windows features installed, another group to have other features, and so on? What if you want computers at one location to have one set of applications installed, and those at a different location to have a different set of applications installed?
    If you want to perform mass deployments like this and customize what drivers, features or applications are installed according to the computer's hardware, location or role, you can accomplish this with MDT by using the MDT database. The MDT database is basically a Microsoft SQL Server-based version of the CustomSettings.ini file that can be used as a central repository for storing the configuration settings used to deploy multiple computers using MDT. Without the MDT database, you would need to create a separate CustomSettings.ini file for each computer you want to deploy using MDT and then copy/paste this file into MDT each time you deploy a new computer. With the MDT database, you only have one CustomSettings.ini file for all computers, plus a SQL database that contains the customizations specific to each computer.
    Installing SQL Server 2008 Express

    Before you can create and configure the MDT database, you must prepare your environment by installing and configuring one of the following versions of SQL Server in your environment:

    • SQL Server 2005
    • SQL Server 2008
    • SQL Server 2008 Express

    You can install SQL Server either on the MDT computer itself or on a separate computer on your network.
    For this example, we will install SQL Server 2008 Express on our MDT computer which is a domain controller SEA-DC1.contoso.com in our test environment running Windows Server 2008 R2. If you install your SQL Server 2008 Express instance on a different platform such as Windows Server 2008 or Windows Server 2003 SP2, you will first need to install the following two items which are prerequisites for installing SQL Server 2008 Express:


    Begin by downloading SQL Server 2008 Express SP1 from the Microsoft Download Center. Then double-click on SQLEXPR_platform_ENU.exe where platform is either x64 or x86 (for Windows Server 2008 R2 platform must be x64) to open the SQL Server Installation Center (Figure 1):

    Figure 1: The SQL Server Installation Center
    Next, click Installation on the left to display the various installation options (Figure 2):

    Figure 2: Options for installing SQL Server 2008 Express
    Next, click "New SQL Server stand-alone installation or add Features to an existing installation" to launch the SQL Server 2008 Setup wizard. Skip the product key page since the Express version is free and doesn't require you to specify a product key, then accept the EULA. At this point the page for installing the Setup Support Files is displayed (Figure 3):

    Figure 3: Installing the Setup Support Files
    Click Install to install the Setup Support files. Once these are installed, the Setup Support Rules run to check whether your computer can support installation of SQL Server 2008 Express (Figure 4):

    Figure 4: Verifying the computer supports installing SQL Server 2008 Express
    Note that we get two warnings in this example. First, installing SQL Server on a domain controller is not recommended, but it is actually fine to do this for a test environment like the one we are using here. And second, Windows Firewall is currently blocking remote computers from being able to access the SQL Server instance we are going to install—we will deal with this later in this article.
    On the Feature Selection page, select Database Engine Services (Figure 5):

    Figure 5: Selecting features to install
    Accept the defaults on the Instance Configuration page (Figure 6):

    Figure 6: Installing a new instance of SQL Server 2008 Express
    On the Disk Space Requirements page, verify that the computer has sufficient disk space for the install (Figure 7):

    Figure 7: Disk Space Requirements page
    The Server Configuration page lets you specify a service account for each SQL Server service (Figure 8).

    Figure 8: Server Configuration page
    For our test environment, we will use the same account for each SQL Server service. To do this, click "Use the same account for all SQL Server services" and type CONTOSO\Administrator and the password for the account (Figure 9):

    Figure 9: Specifying a service account for all SQL Server services
    On the Database Engine Configuration page, add the CONTOSO\Administrator account to the list of SQL Server administrators (Figure 10). Since we are logged onto the computer using this account, you can add it to the list by clicking Add Current User. Leave the remaining settings as they are.

    Figure 10: Adding CONTOSO\Administrator to the list of SQL Server administrators
    Accept the defaults on the Error and Usage Reporting page, then click Next to run the Installation Rules to determine whether the installation will succeed (Figure 11):

    Figure 11: The installation will succeed
    On the Ready to Install page, verify the installation options you have selected (Figure 12):

    Figure 12: Verify installation options
    Now click Install and view the progress of the installation. When the installation has finished, click Close to close the wizard.
    Configuring SQL Server 2008 Express

    Once SQL Server 2008 has been installed, it needs to be configured so that MDT can use it. To do this, begin by clicking Start, All Programs, Microsoft SQL Server 2008, Configuration Tools, SQL Server Configuration Manager. This opens the SQL Server Configuration Manager console which you can use to configure SQL Server protocols, services, and other features. Expand the local server node, then expand SQL Server Network Configuration, and select Protocols for SQLEXPRESS. Then right-click on Named Pipes and select Enabled (Figure 13):

    Figure 13: Enabling named pipes for the SQLEXPRESS instance
    Enabling Named Pipes like this for SQL Server is needed so that the Deployment Workbench can connect to the database, and also to enable client computers to connect to the database.
    Next, select the SQL Server Services node beneath the root node (Figure 14):

    Figure 14: Configuring SQL Server services
    Note that the SQL Server Browser services is currently stopped and in fact is disabled. Right-click on this service and select Properties, select the Service tab, and change the Start Mode of the service from Disabled to Automatic (Figure 15):

    Figure 15: Enabling the SQL Server Browser service
    Next, right-click on the SQL Server Browser service and select Start to start the service. Then right-click on the SQL Server (SQLEXPRESS) service and select Restart. These service modifications are needed in order that client computers can make a connection to the named instance "SQLEXPRESS".
    Next, open Windows Firewall from Control Panel and click "Allow a program or feature through Windows Firewall." Then click Allow Another Program and browse as shown in Figure 16 until you can select the following executable:
    C:\Program Files\Microsoft SQL Server (x86)\90\Shared\sqlbrowser.exe

    Figure 16: Opening a program exception in Windows Firewall: step 1
    Once you have selected this executable, click Open to return to the Add A Program dialog box (Figure 17):

    Figure 17: Opening a program exception in Windows Firewall: step 2
    Then click Add and the new program exception is displayed in Windows Firewall (Figure 18):

    Figure 18: Opening a program exception in Windows Firewall: step 3
    Finally, do the same to add another program exception for the following executable:
    C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\binn\sqlservr.exe
    These firewall exceptions are necessary to allow client computers to establish a connection to the SQL Server and SQL Browser services.
    Tip:
    Instead of creating exceptions manually like this, you can use the batch script of netsh commands found in KB 968872 to open the necessary firewall ports for SQL Server.
    Creating the MDT Database

    At this point, SQL Server Express is installed and configured. The final step is to create a new database in MDT. To do this, open the Deployment Workbench and under your deployment share expand Advanced Configuration to display Database. Then right-click on Database and select New Database (Figure 19):

    Figure 19: Creating a new MDT database: step 1
    On the SQL Server Details page of the New DB Wizard, type the name of the SQL Server (here the same as the MDT computer) and the database instance (SQLEXPRESS) and make sure Named Pipes is selected as the network library (Figure 20):

    Figure 20: Creating a new MDT database: step 2
    On the Database wizard page, select Create A New Database and specify a name for your new database (Figure 21):

    Figure 21: Creating a new MDT database: step 3
    On the SQL Share page, type the share name of your deployment share so that WinPE can establish a connection to your SQL Server database using Windows integrated authentication (Figure 22):

    Figure 22: Creating a new MDT database: step 4
    Once you have finished the wizard without errors, the Database page will look something like Figure 23:

    Figure 23: The new MDT database has been created
    Conclusion

    This article examined how to install SQL Server 2008 Express SP1 on your MDT computer and create a new MDT database. In the articles that follow, we will look at how to use this database to centrally store configuration settings for deploying Windows 7 to multiple computers using MDT




صفحه 1 از 2 1 2 آخرینآخرین

کلمات کلیدی در جستجوها:

1

An image in the Windows Imaging (WIM) file E:Remote InstallBootx86ImagesLiteTouchPE_x86.wim does not have a System Root defined.

X64 Windows PE boot environment for SCCM 6.1.7100.0 en-US

litetouch oem task sequence

VDI assessment summary

2

unable to mount the wim so the update process cannot continue

LanguagePacks001

Parse Workgroup

8

LiteTouch OEM Task Sequence VMwaresccm task sequence decrypt computer first rebuildmicrosoft deployment toolkit 2010 update 1: dhcp lease was not obtained for any networking devicecant update mdt deployment share on windows 7 x64 unable to mount the wim so the update process cannot continue.mdt bare metal windows 7 deploymentmdt rules setproductkeybcdboot command farsiwindows pe wim c:program fileswindows aiktoolspetoolsx86winpe.wim will be used.unable to mount the wim so the update process cannot continue.Once Windows 7 has been successfully installed it will do a quick search of the critical components of your system and recommend hardware upgrades where appropriate.usmt 4 estimation differences to version 3update-mdtdeploymentshare completely regenerateCustomsettings.ini file for performing a completely automated LTIWindows PE boot environment for SCCM 6.1.7100.0 en-US?index of? inurl=intlcfg.exe mdt 2010 windows 7 customsettings.ini language for non-unicode programs

برچسب برای این موضوع

مجوز های ارسال و ویرایش

  • شما نمی توانید موضوع جدید ارسال کنید
  • شما نمی توانید به پست ها پاسخ دهید
  • شما نمی توانید فایل پیوست ضمیمه کنید
  • شما نمی توانید پست های خود را ویرایش کنید
  •