You can use Dism.exe to perform the following tasks:
■■
Add, remove, and list software packages in .appx format to a Windows image
■■
Enable or disable roles and features
■■
Add, remove, and list software updates
■■
Add, remove, and list software drivers
__________________________________________________________
Mounting images
By mounting an image, you can make changes to that image. When you mount an image, you link it to a folder. You can use File Explorer, Windows PowerShell, or Cmd.exe to navigate the structure of this folder and interact with it as you would any other folder located on the file system.
Once the image is mounted, you can also use Dism.exe to perform servicing tasks, such as adding and removing drivers and updates.
A single WIM image can contain multiple operating system images. Each operating system image is assigned an index number, which you need to know before you can use Dism.exe to mount the image with the /Get-wiminfo switch. For example, if you have an image named Install.wim located in the C:\Images folder, you can use the following command to get a list of the operating system images it contains:
Dism.exe /get-wiminfo /wimfile:c:\images\install.wim
Once you have determined which operating system image you want to service, use the /Mount-image switch with the Dism.exe command to mount that image.
For example, to mount the Standard Edition of Windows Server 2012 from the Install.wim file that is available with the Evaluation Edition in the C:\Mount folder, issue this command:
Dism.exe /mount-image /imagefile:c:\images\install.wim /index:2 /mountdir:c:\mount
_________________________________________________
C:\Updates folder on a computer and you mounted a WIM image of the Windows Server 2012 operating system in the C:\Mount folder, you could apply the update to the image by using this command:
Dism.exe /image:c:\mount /Add-Package /PackagePath:"c:\updates\ Update for Windows Server 2012 (KB2756872)"
Final Summary
■
Install.wim, located in the \Sources folder of the Windows Server 2012 installation media, stores the Windows Server 2012 operating system images.
■■
You can use Dism.exe to add and remove drivers and software updates from installation
images.
■■
You must mount an installation image before you can modify it.
■
You must commit your changes when dismounting an installation image to have those changes saved.
■■
Use Sysprep.exe to prepare an image for capture.
______________________________________________________
How to Create a Answer file for installation
The Windows System Image Manager (known as Windows SIM) is a GUI-based tool that you can use to create an answer file.
When using the tool, you must specify the image for which you want to create an answer file. Windows SIM then creates a catalog file for all the options that you can configure. After you configure all the settings that you want automated during installation and post-installation configuration, you can have the tool output an answer file using correct XML syntax.
Windows SIM is included with the Windows Assessment and Deployment Kit (Windows ADK), which you can download from the Microsoft website.
To create an answer file using Windows SIM, perform the following steps:
1.
Download and install Windows ADK from the Microsoft website using the installation defaults.
2.
Copy the file \Sources\install.wim from the Windows Server 2012 installation media to a temporary directory on the computer on which you have installed Windows ADK.
3.
Open Windows SIM from the Start screen.
4.
In the Windows SIM interface, click File and then click Select Windows Image. Open the file Install.wim.
5.
Select which operating system image in the install image for which you wish to create an answer file.
6.
When prompted to create a catalog file, click Yes.
7.
Click File and click New Answer File.
8.
Use Windows SIM to select each component that you want to configure. Figure 1-5 shows how you can configure installation to join the contoso.com domain.
Windows Deployment Services
WDS is a server role that you can deploy on computers running Windows Server 2012. WDS enables you to deploy operating systems, including but not limited to Windows 8 and Windows Server 2012, to computers over the network.
WDS sends these operating systems across the network using multicast transmissions, so multiple computers receive the same operating system image while minimizing the use of network bandwidth. When you use multicast transmissions, the same amount of traffic crosses the network independently of whether you are deploying Windows Server 2012 to 1 computer or 50.
Deploying Windows Server 2012 through WDS involves performing the following steps:
1. An operating system deployment transmission is prepared on the WDS server.
2. The media access control (MAC) addresses of Pre-boot Execution Environment (PXE)–compliant network adapters are made available to the WDS server.
3. The computers that are targets of the transmission boot using their PXE–compliant network adapters.
4. These computers locate the WDS server and begin the operating system setup process. If the WDS server has been provisioned with an answer file, as shown in Figure 1-6, the setup completes automatically. If the WDS server has not been provisioned with an answer file, an administrator must enter setup configuration information.
Each WDS server can have only one unattended installation file for each processor archi-tecture. Because unattended installation files differ between server and client, you will either need to swap unattended files when you are switching between client and server or have multiple WDS servers.
But If you have a computer that does not have a PXE–compliant network adapter, you can configure a special type of boot image known as a discover image.
A discover image boots an environment, loading special drivers to enable the network adapter to interact with the WDS server. You create the boot image by adding the appropriate network adapter drivers associated with the computer that can’t PXE boot to the Boot.wim file from the Windows Server 2012 installation media.
WDS has the following requirements:
■■
A Windows Server 2012 DNS must be present on the local area network (LAN). This is implied by the domain membership.
■■
An authorized Dynamic Host Configuration Protocol (DHCP) server must be present on the network. You can host WDS and DHCP on the same computer as long as you configure the options shown in Figure 1-7. With Windows Server 2012, you can deploy WDS on a server that is not a member of an AD DS domain. This is a feature new to Windows Server 2012. You can’t deploy WDS on a server running Windows Server 2008 or Windows Server 2008 R2 unless that server is a member of an AD DS domain.
Managing images
Images contain either entire operating systems or a version of a special stripped-down operating system known as Windows PE.
Windows PE functions as a type of boot disk, enabling a basic environment to be loaded from which more complex maintenance and installation tasks can be performed.
WDS uses four image types: boot image, install image, discover image, and capture image.
■■
Boot image A special image that enables the computer to boot and begin installing the operating system using the install image. A default boot image, named Boot.wim, is located in the sources folder of the Windows Server 2012 installation media.
■■
Install image The main type of image discussed in this chapter. Contains the operating system as well as any other included components, such as software updates and additional applications. A default install image, named Install.wim, is present in the sources folder of the Windows Server 2012 installation media.
■■
Discover image This special image is for computers that cannot PXE boot to load appropriate network drivers to begin a session with a WDS server.
■■
Capture image A special image type that enables a prepared computer to be booted so that its operating system state can be captured as an install image. You add capture images as boot images in WDS.
How to Import Image file in WDS Server
To import an image into WDS, perform the following steps:
1. Open the Windows Deployment Services console.
2. Click Install Images. From the Action menu, click Add Install Image.
3. Choose whether to create a new image group or to use an existing image group.
4. Specify the location of the image file.
5.In the Available Images page of the Add Image Wizard, shown in Figure 1-9, select the operating system images that you want to add. When the image or images are added, click Next and then click Finish.
PXE response settings
With PXE response settings, you can configure how the WDS server responds to computers. As Figure 1-10 shows, you can configure WDS not to respond to any client computers (this effectively disables WDS), to respond to known client computers, or to respond to all computers but require an administrator to manually approve an unknown computer. Known computers are ones that have prestaged accounts in Active Directory.
You can prestage computers if you know the MAC address of the network interface card (NIC) that the computer uses. Vendors often supply a list of MAC addresses associated with computers when you purchase those computers, and you can use this list to prestage computer accounts .
Client Naming Policy
Client Naming Policy enables you to configure how computers installed from WDS will be named if you aren’t using deployment options that perform the action. You can also use the settings on this tab, shown in Figure 1-11, to configure domain membership and organizational unit (OU) options for the computer account.
.
WDS Boot options
In the Boot options tab of the WDS server’s properties dialog box, shown in Figure 1-12, you can configure how clients that PXE boot interact with the WDS server.
You can also configure a default boot image for each architecture supported by WDS.
By default, once a client has connected to a WDS server, someone must press the F12 key to continue deploying the operating system. In environments in which you are performing a large number of simultaneous deployments, requiring this level of manual intervention might substantially delay the deployment.
.
Multicast options
The default settings of WDS have all computers that join the multicast transmission receiving the installation image at the same speed. If you frequently deploy operating systems, you are aware that sometimes there are 1 or 2 computers that have network adapters that slow a transmission that should take only 15 minutes into one that takes half a day.
You can configure the transfer settings on the Multicast tab, shown in Figure 1-13, so that clients are partitioned into separate sessions depending on how fast they can consume the multicast transmission.
You still have those slow computers taking a long time to receive the image, but the other computers connected to the transmission can complete the deployment more quickly.
.
Other options
Although you are less likely to need them, you can configure other options on the following tabs:
■■ Advanced tab You can configure WDS to use a specific domain controller and Global Catalog (GC) server. You can also configure whether WDS is authorized in DHCP. DHCP authorization occurs automatically when you install the WDS role.
■■ N etwork tab You can specify a User Datagram Protocol (UDP) port policy to limit when UDP ports are used with transmissions. You can also configure a network profile to specify the speed of the network, minimizing the chance that WDS transmissions will slow the network down.
■■ TFTP tab You can specify maximum block size and Trivial File Transfer Protocol (TFTP) window size.
Configuring transmissions
You use WDS transmissions to set WDS to transfer the operating system image across to PXE clients.
When configuring a WDS transmission, you need to decide what type of multicast transmission you will perform in the Multicast Type page of the Create Multicast Transmission Wizard, as shown in Figure 1-14.
.
The difference between these options is as follows:
■■ Auto-Cast A transmission starts whenever a client requests the image. If another client requests the same image, the client will join the existing transmission, caching data from the current transfer, and then retrieving data that was transmitted before the client joined the transmission. This is the best option to use when you are performing one-off deployments.
■■ Scheduled-Cast You choose either to start the transmission when a specified number of clients have joined, or at a particular date and time. This is the best option to use when you are deploying the same operating system image to a large number of computers.
How to configure a WDS transmission, perform the following steps:
1. Open the Windows Deployment Services console, expand the WDS server from which you want to perform the deployment and click Multicast Transmissions. In the Action menu, click Create Multicast Transmission.
2. Provide a name for the multicast transmission.
3. In the Image Selection page, specify which operating system image you want to deploy using the transmission.
4. In the Multicast Type page, specify whether you will use Auto-Cast or Scheduled-Cast. If you choose Scheduled-Cast, select the number of clients or the transmission start time.
Lesson summary
■■ Unless you are booting from a discover image, computers must be able to PXE boot to receive an operating system image from a WDS server.
■■ With boot images, computers with PXE-compliant network cards can load a preinstallation
environment over the network from which it is possible to then load a minimal operating system.
■■ Install images contain the operating system as well as additional components, such as software updates and applications.
■■ Discover images are used with computers that do not have PXE-compliant network cards. Capture images are used when you want to capture a prepared operating system.
■■ Multicast transmissions enable the same installation image to be transmitted to multiple
computers at the same time.
■■ If a WDS server also hosts the DHCP server role, it is necessary to configure the server to listen on a separate port and to configure DHCP option tag 60 for all scopes.
■■ You use Windows SIM to create unattended Windows Setup answer files. You can configure
WDS with an unattended Windows Setup answer file to minimize the amount of interaction you need to perform when deploying Windows Server 2012.
Lesson 3: Servicing and updating deployed servers
Windows Server Update Services (WSUS) 4.0 is a role that is built into Windows Server 2012. WSUS functions as a local mirror of the Microsoft Update servers on the Internet.
Organizations that have deployed WSUS can use Group Policy to configure client and server operating
systems to check for available updates against a local WSUS server instead of checking against the Microsoft Update servers on the Internet. The primary benefits to you as an administrator in deploying WSUS is that you can minimize the amount of update traffic that goes across your organization’s Internet connection and take control of which updates are approved for deployment to computers in your organization.
Automated update deployment with WSUSWSUS, and before it Software Update Services (SUS), has been available as free add-ins for Windows Server operating systems for more than a decade.
WSUS 4.0 is the version of WSUS released with Windows Server 2012. Unlike previous versions of the Windows Server operating system, in which you needed to download WSUS separately or install a special update to make the role available, WSUS 4.0 can be deployed directly as a server role.
Because it has been available free of charge for so long, WSUS is widely deployed with Microsoft registering more than 1 million WSUS servers regularly synchronizing against the Microsoft Update servers on the Internet. Although there are more sophisticated update deployment solutions available from Microsoft and third-party vendors, WSUS is the most commonly used update deployment solution besides Windows Update.
.
New WSUS features
Administrators who have used WSUS 3.0 Service Pack 2 (SP2), which can be deployed on servers running Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2, will find WSUS 4.0 very familiar. The big changes between WSUS 3.0 SP2 and WSUS 4.0 are as follows:
■■ Integrated Administration console WSUS 3.0 SP2 had a console that was separate from the Server Manager console. The WSUS 4.0 console is integrated into the Windows Server 2012 Server Manager console.
■■ Supports Server Core You can install WSUS 4.0 on computers running the Windows Server 2012 operating system deployed with the Server Core installation option. This applies only to Windows Server 2012; you can’t install WSUS 4.0 on computers running Windows Server 2008 R2 installed with the Server Core installation option.
■■ Windows PowerShell support WSUS 4.0 includes Windows PowerShell support for several commonly performed administrative functions.
Deploy and manage WSUS
You can install WSUS 4.0 as a role on Windows Server 2012 in both the Server Core and full administrative interface configurations.
The advantage of deploying WSUS on Server Core installations is that these deployments require fewer updates.
If you do deploy WSUS on a Server Core deployment, you need to ensure that you install the WSUS RSAT components on another computer, either running Windows 8 or Windows Server 2012 to perform WSUS administration tasks.
Although WSUS 4.0 does include Windows PowerShell support, not all WSUS functionality has been replicated in Windows PowerShell.
When you install WSUS, you can choose between using a local Windows Internal Database (WID) or a SQL Server instance.
The advantage of using a SQL Server instance is that it’s easier to back up and you can run more-complex reports. The majority of WSUS deployments use the built-in WID database. When you install WSUS 4.0 on Windows Server 2012, all prerequisite components are also installed.
When WSUS synchronizes, it may update the list of available product names to reflect newly released software.
If your organization deploys a new product, if it retires an old product, or if you simply want to alter which updates are synchronized, you can do this in the Products And Classifications dialog box, available through Options in the Update Services console and shown in Figure 1-15.
.
Autonomous and replica modes
In large organizations there are likely to be multiple WSUS servers because even if a single WSUS server can support about 25,000 clients, it’s better to have a local WSUS server at each large site rather than having clients pull updates and approvals across wide area network (WAN) links.
Instead of administrators performing the same approvals on each WSUS server in the organization, you can configure a WSUS server as a replica of another server. When you configure a WSUS server as a replica, as shown in Figure 1-16, the downstream server copies all update approvals, settings, computers, and groups from its parent.
You can configure Update Source settings, as well as specify information that enables WSUS to use a proxy server, through the Update Source And Proxy Server item in Options in the Update Services console.
.
UPDATE FILES
One of the benefits of deploying WSUS is that clients on the local network download their updates from the WSUS server rather than downloading updates from the Microsoft Update servers on the Internet.
You can configure update storage location settings using the Update Files And Languages item in the Options area of the Update Services console.
You can configure the following options, which are shown in Figure 1-17:
■■ Store Update Files Locally On This Server When you choose this option, you can choose whether to download files only after they have been approved; download express installation files, which install more quickly on clients; or download files from Microsoft Update.
With the last option, you can configure a server as a replica server, but have update files downloaded from Microsoft Update rather than the upstream replica server.
*Don’t Store Update Files Locally; Computers Install From Microsoft Update When you configure this option, clients use WSUS for update approvals, but retrieve the updates from the Microsoft Update servers on the Internet. This option is most appropriate when you are providing update approvals to clients located outside the organizational network.
.
Windows PowerShell cmdlets
WSUS 4.0 includes Windows PowerShell support. Although you can use Windows PowerShell to perform a certain number of management tasks on a preconfigured WSUS server, you are more likely to perform WSUS administration tasks using the Update Services console.
The Windows PowerShell commands available with WSUS are as follows:
■■Add-WsusComputer Adds a computer to a target WSUS group.
■■ Approve-WsusUpdate Approves a specific update for deployment.
■■Deny-WsusUpdate Denies an update for deployment.
■■Get-WsusClassification Enables you to view all WSUS classifications.
■■Get-WsusComputer Enables you to filter computers known to the WSUS server by operating system, name, update installation status, and other criteria.
■Get-WsusProduct Lists all available products that are available to WSUS.
■■Get-WsusServer Provides information about the WSUS server.
■■Invoke-WsusServerCleanup Cleans up WSUS, including removing superseded updates.
■■Set-WsusClassification Enables or disables synchronization of a specific category of updates.
■■Set-WsusProduct Enables or disables synchronization of a specific category of updates.
■■Set-WsusServerSynchronization Enables you to configure the WSUS server synchronization
schedule.
WSUS security roles
In large organizations, you are more likely to separate the roles of server administrator and update administrator. When you install WSUS, two local security groups are created. By adding users to these groups, you grant users the permission to perform the tasks assigned with these roles.
The roles are as follows:
■■
WSUS Administrators Users who are added to the local WSUS Administrators group can perform any WSUS administration task. These tasks include approving updates, managing computer groups, configuring automatic approval rules, and modifying the WSUS server’s update source.
■■
WSUS Reporters Users who are members of this role can run reports on the WSUS server. These reports detail update compliance status on the basis of update and computer.
For example, a user who is a member of this group can run a WSUS report and determine which computers are missing a specific critical update.
WSUS groups
You can use WSUS groups to organize computers for the purpose of deploying updates.
For example, you might have a WSUS group for servers in Sydney and another WSUS group for servers in Melbourne.
A computer can be a member of multiple WSUS groups, and WSUS groups can exist in parent-child relationships.
For example, the Australia WSUS group might have both the Melbourne and Sydney WSUS groups as members. Updates approved for the Australia group are automatically approved for members of the Melbourne and Sydney groups unless overridden.
You can assign computers to WSUS groups manually or through Group Policy. Computers can be assigned to WSUS groups through Group Policy only if the computer groups already exist on the WSUS server. To assign a computer manually, the computer must have already reported to the WSUS server.
Computers that have reported to the WSUS server but have not been assigned to a group will be members of the Unassigned Computers group. An administrator must create WSUS groups.
To create a WSUS group, perform the following steps:
1. Open the Update Services console.
2.Click the group you want to have as the parent group. The Computers/All Computers group is the parent group for all groups.
3.From the Action menu, click Add Computer Group.
4.Specify the computer group name and click Add.
WSUS policies
You can configure most WSUS client options through Group Policy. Many of these policies are related to the experience that users of client operating systems have when updates are installed and are not directly applicable to updating server operating systems. Windows Update policies are located in the Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Update node of a standard GPO, as and are shown in Figure 1-18
.
The most important policies from the perspective of the server administrator are as follows:
■■Configure Automatic Updates You can enable automatic updating, specify a day for update installations, and a time for update installation to occur. It’s usually not a good idea to have this one policy to apply to all servers in your organization. Having all servers install and reboot at the same time can cause substantial disruptions.
■■Specify Intranet Microsoft Update Service Location You can specify the location of the WSUS server and the statistics server. (The statistics server receives information on successful update installation and is usually the same as the WSUS server.)
■■Automatic Update Detection Frequency Determines how often the computer checks for updates.
■■Enable Client-Side Targeting Use this policy to specify which WSUS groups computers
should be a member of. If names do not match, computers will end up in the Unassigned Computers group.
How to Deploy Updates
When you deploy updates, you decide whether to deploy the update, to which computer groups you deploy the update, and what deadline should apply to the deployment.
You can deploy an update multiple times to different groups, so you can deploy an update to a test group and then, if no issues arise with the update, deploy the update more generally.
To deploy an update, perform the following steps:
1. Open the Update Services console and select the Updates\All Updates node. You can also choose to select a child node, such as Critical Updates, if you want to view only available critical updates.
2. Set the Approval setting to Unapproved and the Status to Any, as shown in Figure 1-19, and click Refresh. All unapproved updates are then listed.
.3.Click an update or click multiple updates if you want to select more than one update; then click Approve in the Actions pane.
4. In the Approve Updates dialog box, select which computer groups the update is approved for. Figure 1-20 shows updates approved for the Sydney-Development-Servers group.
You can choose between the following settings:
■■ Approved for Install Approves the update.
■■ Approved for Removal Removes a previously deployed update.
■■ Not Approved Does not approve the update.
■■Keep Existing Approvals Inherits the approval from the parent group.
■■Deadline Specifies an update deployment deadline
.
Prior to deploying updates, you should perform a synchronization, which will ensure that the WSUS server is to be up to date before choosing whether to deploy updates.
Automatic approval rules
Automatic approval rules enable specifically categorized updates to be automatically approved.
For example, you might choose to automatically approve critical updates for the Sydney-Development-Servers WSUS group, as shown in Figure 1-21.
.
To configure an automatic approval rule, perform the following steps:
1. Open the Update Services console. You can do this from the Tools menu of Server Manager, or by right-clicking the server in a server group and clicking Windows Server Update Services.
2. In the Update Services console, click Options and then click Automatic Approvals.
3.In the Automatic Approvals dialog box, click New Rule.
4.In the Add Rule dialog box, choose the following rule options:
■■
When An Update Is In A Specific Classification You can choose that the rule applies when an update matches a specific classification or number of classifications. Update classifications include Critical Updates, Definition Updates, Drivers, Feature Packs, Security Updates, Service Packs, Tools, Update Rollups, and Updates. Microsoft includes classifications for each software update when it publishes the update.
■
When An Update Is For A Specific Product You can specify products, either by category, such as Exchange, or by specific product, such as Exchange Server 2013.
■■
Approve The Update For A Specific Computer Group The update can be approved for selected computer groups.
■■
Set An Approval Deadline Sets an installation deadline for the update based on the time and date the update was first approved.
.
Lesson summary
■■
Install WSUS in autonomous mode if you want to have an administrator manage updates for computers that report to the WSUS server. Install WSUS in replica mode if you want to have other WSUS servers inherit another WSUS server’s configuration.
■■
Create computer groups using the WSUS console and then use Group Policy to assign computers to these groups.
■■
Create automatic deployment rules to automatically approve updates to WSUS clients. Use automatic deployment rules for computers only where you will not be testing updates prior to deploying them.
■■
Use the WSUS Administrators local group to grant users the ability to manage WSUS update deployments.
■■
Use Windows Intune to manage update deployment to computers that are outside the perimeter network.
■■
Use System Center 2012 Configuration Manager to deploy updates to third-party products.
■■
Add, remove, and list software packages in .appx format to a Windows image
■■
Enable or disable roles and features
■■
Add, remove, and list software updates
■■
Add, remove, and list software drivers
__________________________________________________________
Mounting images
By mounting an image, you can make changes to that image. When you mount an image, you link it to a folder. You can use File Explorer, Windows PowerShell, or Cmd.exe to navigate the structure of this folder and interact with it as you would any other folder located on the file system.
Once the image is mounted, you can also use Dism.exe to perform servicing tasks, such as adding and removing drivers and updates.
A single WIM image can contain multiple operating system images. Each operating system image is assigned an index number, which you need to know before you can use Dism.exe to mount the image with the /Get-wiminfo switch. For example, if you have an image named Install.wim located in the C:\Images folder, you can use the following command to get a list of the operating system images it contains:
Dism.exe /get-wiminfo /wimfile:c:\images\install.wim
Once you have determined which operating system image you want to service, use the /Mount-image switch with the Dism.exe command to mount that image.
For example, to mount the Standard Edition of Windows Server 2012 from the Install.wim file that is available with the Evaluation Edition in the C:\Mount folder, issue this command:
Dism.exe /mount-image /imagefile:c:\images\install.wim /index:2 /mountdir:c:\mount
_________________________________________________
C:\Updates folder on a computer and you mounted a WIM image of the Windows Server 2012 operating system in the C:\Mount folder, you could apply the update to the image by using this command:
Dism.exe /image:c:\mount /Add-Package /PackagePath:"c:\updates\ Update for Windows Server 2012 (KB2756872)"
Final Summary
■
Install.wim, located in the \Sources folder of the Windows Server 2012 installation media, stores the Windows Server 2012 operating system images.
■■
You can use Dism.exe to add and remove drivers and software updates from installation
images.
■■
You must mount an installation image before you can modify it.
■
You must commit your changes when dismounting an installation image to have those changes saved.
■■
Use Sysprep.exe to prepare an image for capture.
______________________________________________________
How to Create a Answer file for installation
The Windows System Image Manager (known as Windows SIM) is a GUI-based tool that you can use to create an answer file.
When using the tool, you must specify the image for which you want to create an answer file. Windows SIM then creates a catalog file for all the options that you can configure. After you configure all the settings that you want automated during installation and post-installation configuration, you can have the tool output an answer file using correct XML syntax.
Windows SIM is included with the Windows Assessment and Deployment Kit (Windows ADK), which you can download from the Microsoft website.
To create an answer file using Windows SIM, perform the following steps:
1.
Download and install Windows ADK from the Microsoft website using the installation defaults.
2.
Copy the file \Sources\install.wim from the Windows Server 2012 installation media to a temporary directory on the computer on which you have installed Windows ADK.
3.
Open Windows SIM from the Start screen.
4.
In the Windows SIM interface, click File and then click Select Windows Image. Open the file Install.wim.
5.
Select which operating system image in the install image for which you wish to create an answer file.
6.
When prompted to create a catalog file, click Yes.
7.
Click File and click New Answer File.
8.
Use Windows SIM to select each component that you want to configure. Figure 1-5 shows how you can configure installation to join the contoso.com domain.
Windows Deployment Services
WDS is a server role that you can deploy on computers running Windows Server 2012. WDS enables you to deploy operating systems, including but not limited to Windows 8 and Windows Server 2012, to computers over the network.
WDS sends these operating systems across the network using multicast transmissions, so multiple computers receive the same operating system image while minimizing the use of network bandwidth. When you use multicast transmissions, the same amount of traffic crosses the network independently of whether you are deploying Windows Server 2012 to 1 computer or 50.
Deploying Windows Server 2012 through WDS involves performing the following steps:
1. An operating system deployment transmission is prepared on the WDS server.
2. The media access control (MAC) addresses of Pre-boot Execution Environment (PXE)–compliant network adapters are made available to the WDS server.
3. The computers that are targets of the transmission boot using their PXE–compliant network adapters.
4. These computers locate the WDS server and begin the operating system setup process. If the WDS server has been provisioned with an answer file, as shown in Figure 1-6, the setup completes automatically. If the WDS server has not been provisioned with an answer file, an administrator must enter setup configuration information.
Each WDS server can have only one unattended installation file for each processor archi-tecture. Because unattended installation files differ between server and client, you will either need to swap unattended files when you are switching between client and server or have multiple WDS servers.
But If you have a computer that does not have a PXE–compliant network adapter, you can configure a special type of boot image known as a discover image.
A discover image boots an environment, loading special drivers to enable the network adapter to interact with the WDS server. You create the boot image by adding the appropriate network adapter drivers associated with the computer that can’t PXE boot to the Boot.wim file from the Windows Server 2012 installation media.
WDS has the following requirements:
■■
A Windows Server 2012 DNS must be present on the local area network (LAN). This is implied by the domain membership.
■■
An authorized Dynamic Host Configuration Protocol (DHCP) server must be present on the network. You can host WDS and DHCP on the same computer as long as you configure the options shown in Figure 1-7. With Windows Server 2012, you can deploy WDS on a server that is not a member of an AD DS domain. This is a feature new to Windows Server 2012. You can’t deploy WDS on a server running Windows Server 2008 or Windows Server 2008 R2 unless that server is a member of an AD DS domain.
Managing images
Images contain either entire operating systems or a version of a special stripped-down operating system known as Windows PE.
Windows PE functions as a type of boot disk, enabling a basic environment to be loaded from which more complex maintenance and installation tasks can be performed.
WDS uses four image types: boot image, install image, discover image, and capture image.
■■
Boot image A special image that enables the computer to boot and begin installing the operating system using the install image. A default boot image, named Boot.wim, is located in the sources folder of the Windows Server 2012 installation media.
■■
Install image The main type of image discussed in this chapter. Contains the operating system as well as any other included components, such as software updates and additional applications. A default install image, named Install.wim, is present in the sources folder of the Windows Server 2012 installation media.
■■
Discover image This special image is for computers that cannot PXE boot to load appropriate network drivers to begin a session with a WDS server.
■■
Capture image A special image type that enables a prepared computer to be booted so that its operating system state can be captured as an install image. You add capture images as boot images in WDS.
How to Import Image file in WDS Server
To import an image into WDS, perform the following steps:
1. Open the Windows Deployment Services console.
2. Click Install Images. From the Action menu, click Add Install Image.
3. Choose whether to create a new image group or to use an existing image group.
4. Specify the location of the image file.
5.In the Available Images page of the Add Image Wizard, shown in Figure 1-9, select the operating system images that you want to add. When the image or images are added, click Next and then click Finish.
PXE response settings
With PXE response settings, you can configure how the WDS server responds to computers. As Figure 1-10 shows, you can configure WDS not to respond to any client computers (this effectively disables WDS), to respond to known client computers, or to respond to all computers but require an administrator to manually approve an unknown computer. Known computers are ones that have prestaged accounts in Active Directory.
You can prestage computers if you know the MAC address of the network interface card (NIC) that the computer uses. Vendors often supply a list of MAC addresses associated with computers when you purchase those computers, and you can use this list to prestage computer accounts .
Client Naming Policy
Client Naming Policy enables you to configure how computers installed from WDS will be named if you aren’t using deployment options that perform the action. You can also use the settings on this tab, shown in Figure 1-11, to configure domain membership and organizational unit (OU) options for the computer account.
.WDS Boot options
In the Boot options tab of the WDS server’s properties dialog box, shown in Figure 1-12, you can configure how clients that PXE boot interact with the WDS server.
You can also configure a default boot image for each architecture supported by WDS.
By default, once a client has connected to a WDS server, someone must press the F12 key to continue deploying the operating system. In environments in which you are performing a large number of simultaneous deployments, requiring this level of manual intervention might substantially delay the deployment.
.Multicast options
The default settings of WDS have all computers that join the multicast transmission receiving the installation image at the same speed. If you frequently deploy operating systems, you are aware that sometimes there are 1 or 2 computers that have network adapters that slow a transmission that should take only 15 minutes into one that takes half a day.
You can configure the transfer settings on the Multicast tab, shown in Figure 1-13, so that clients are partitioned into separate sessions depending on how fast they can consume the multicast transmission.
You still have those slow computers taking a long time to receive the image, but the other computers connected to the transmission can complete the deployment more quickly.
.Other options
Although you are less likely to need them, you can configure other options on the following tabs:
■■ Advanced tab You can configure WDS to use a specific domain controller and Global Catalog (GC) server. You can also configure whether WDS is authorized in DHCP. DHCP authorization occurs automatically when you install the WDS role.
■■ N etwork tab You can specify a User Datagram Protocol (UDP) port policy to limit when UDP ports are used with transmissions. You can also configure a network profile to specify the speed of the network, minimizing the chance that WDS transmissions will slow the network down.
■■ TFTP tab You can specify maximum block size and Trivial File Transfer Protocol (TFTP) window size.
Configuring transmissions
You use WDS transmissions to set WDS to transfer the operating system image across to PXE clients.
When configuring a WDS transmission, you need to decide what type of multicast transmission you will perform in the Multicast Type page of the Create Multicast Transmission Wizard, as shown in Figure 1-14.
.The difference between these options is as follows:
■■ Auto-Cast A transmission starts whenever a client requests the image. If another client requests the same image, the client will join the existing transmission, caching data from the current transfer, and then retrieving data that was transmitted before the client joined the transmission. This is the best option to use when you are performing one-off deployments.
■■ Scheduled-Cast You choose either to start the transmission when a specified number of clients have joined, or at a particular date and time. This is the best option to use when you are deploying the same operating system image to a large number of computers.
How to configure a WDS transmission, perform the following steps:
1. Open the Windows Deployment Services console, expand the WDS server from which you want to perform the deployment and click Multicast Transmissions. In the Action menu, click Create Multicast Transmission.
2. Provide a name for the multicast transmission.
3. In the Image Selection page, specify which operating system image you want to deploy using the transmission.
4. In the Multicast Type page, specify whether you will use Auto-Cast or Scheduled-Cast. If you choose Scheduled-Cast, select the number of clients or the transmission start time.
Lesson summary
■■ Unless you are booting from a discover image, computers must be able to PXE boot to receive an operating system image from a WDS server.
■■ With boot images, computers with PXE-compliant network cards can load a preinstallation
environment over the network from which it is possible to then load a minimal operating system.
■■ Install images contain the operating system as well as additional components, such as software updates and applications.
■■ Discover images are used with computers that do not have PXE-compliant network cards. Capture images are used when you want to capture a prepared operating system.
■■ Multicast transmissions enable the same installation image to be transmitted to multiple
computers at the same time.
■■ If a WDS server also hosts the DHCP server role, it is necessary to configure the server to listen on a separate port and to configure DHCP option tag 60 for all scopes.
■■ You use Windows SIM to create unattended Windows Setup answer files. You can configure
WDS with an unattended Windows Setup answer file to minimize the amount of interaction you need to perform when deploying Windows Server 2012.
Lesson 3: Servicing and updating deployed servers
Windows Server Update Services (WSUS) 4.0 is a role that is built into Windows Server 2012. WSUS functions as a local mirror of the Microsoft Update servers on the Internet.
Organizations that have deployed WSUS can use Group Policy to configure client and server operating
systems to check for available updates against a local WSUS server instead of checking against the Microsoft Update servers on the Internet. The primary benefits to you as an administrator in deploying WSUS is that you can minimize the amount of update traffic that goes across your organization’s Internet connection and take control of which updates are approved for deployment to computers in your organization.
Automated update deployment with WSUSWSUS, and before it Software Update Services (SUS), has been available as free add-ins for Windows Server operating systems for more than a decade.
WSUS 4.0 is the version of WSUS released with Windows Server 2012. Unlike previous versions of the Windows Server operating system, in which you needed to download WSUS separately or install a special update to make the role available, WSUS 4.0 can be deployed directly as a server role.
Because it has been available free of charge for so long, WSUS is widely deployed with Microsoft registering more than 1 million WSUS servers regularly synchronizing against the Microsoft Update servers on the Internet. Although there are more sophisticated update deployment solutions available from Microsoft and third-party vendors, WSUS is the most commonly used update deployment solution besides Windows Update.
.New WSUS features
Administrators who have used WSUS 3.0 Service Pack 2 (SP2), which can be deployed on servers running Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2, will find WSUS 4.0 very familiar. The big changes between WSUS 3.0 SP2 and WSUS 4.0 are as follows:
■■ Integrated Administration console WSUS 3.0 SP2 had a console that was separate from the Server Manager console. The WSUS 4.0 console is integrated into the Windows Server 2012 Server Manager console.
■■ Supports Server Core You can install WSUS 4.0 on computers running the Windows Server 2012 operating system deployed with the Server Core installation option. This applies only to Windows Server 2012; you can’t install WSUS 4.0 on computers running Windows Server 2008 R2 installed with the Server Core installation option.
■■ Windows PowerShell support WSUS 4.0 includes Windows PowerShell support for several commonly performed administrative functions.
Deploy and manage WSUS
You can install WSUS 4.0 as a role on Windows Server 2012 in both the Server Core and full administrative interface configurations.
The advantage of deploying WSUS on Server Core installations is that these deployments require fewer updates.
If you do deploy WSUS on a Server Core deployment, you need to ensure that you install the WSUS RSAT components on another computer, either running Windows 8 or Windows Server 2012 to perform WSUS administration tasks.
Although WSUS 4.0 does include Windows PowerShell support, not all WSUS functionality has been replicated in Windows PowerShell.
When you install WSUS, you can choose between using a local Windows Internal Database (WID) or a SQL Server instance.
The advantage of using a SQL Server instance is that it’s easier to back up and you can run more-complex reports. The majority of WSUS deployments use the built-in WID database. When you install WSUS 4.0 on Windows Server 2012, all prerequisite components are also installed.
When WSUS synchronizes, it may update the list of available product names to reflect newly released software.
If your organization deploys a new product, if it retires an old product, or if you simply want to alter which updates are synchronized, you can do this in the Products And Classifications dialog box, available through Options in the Update Services console and shown in Figure 1-15.
.Autonomous and replica modes
In large organizations there are likely to be multiple WSUS servers because even if a single WSUS server can support about 25,000 clients, it’s better to have a local WSUS server at each large site rather than having clients pull updates and approvals across wide area network (WAN) links.
Instead of administrators performing the same approvals on each WSUS server in the organization, you can configure a WSUS server as a replica of another server. When you configure a WSUS server as a replica, as shown in Figure 1-16, the downstream server copies all update approvals, settings, computers, and groups from its parent.
You can configure Update Source settings, as well as specify information that enables WSUS to use a proxy server, through the Update Source And Proxy Server item in Options in the Update Services console.
.UPDATE FILES
One of the benefits of deploying WSUS is that clients on the local network download their updates from the WSUS server rather than downloading updates from the Microsoft Update servers on the Internet.
You can configure update storage location settings using the Update Files And Languages item in the Options area of the Update Services console.
You can configure the following options, which are shown in Figure 1-17:
■■ Store Update Files Locally On This Server When you choose this option, you can choose whether to download files only after they have been approved; download express installation files, which install more quickly on clients; or download files from Microsoft Update.
With the last option, you can configure a server as a replica server, but have update files downloaded from Microsoft Update rather than the upstream replica server.
*Don’t Store Update Files Locally; Computers Install From Microsoft Update When you configure this option, clients use WSUS for update approvals, but retrieve the updates from the Microsoft Update servers on the Internet. This option is most appropriate when you are providing update approvals to clients located outside the organizational network.
.Windows PowerShell cmdlets
WSUS 4.0 includes Windows PowerShell support. Although you can use Windows PowerShell to perform a certain number of management tasks on a preconfigured WSUS server, you are more likely to perform WSUS administration tasks using the Update Services console.
The Windows PowerShell commands available with WSUS are as follows:
■■Add-WsusComputer Adds a computer to a target WSUS group.
■■ Approve-WsusUpdate Approves a specific update for deployment.
■■Deny-WsusUpdate Denies an update for deployment.
■■Get-WsusClassification Enables you to view all WSUS classifications.
■■Get-WsusComputer Enables you to filter computers known to the WSUS server by operating system, name, update installation status, and other criteria.
■Get-WsusProduct Lists all available products that are available to WSUS.
■■Get-WsusServer Provides information about the WSUS server.
■■Invoke-WsusServerCleanup Cleans up WSUS, including removing superseded updates.
■■Set-WsusClassification Enables or disables synchronization of a specific category of updates.
■■Set-WsusProduct Enables or disables synchronization of a specific category of updates.
■■Set-WsusServerSynchronization Enables you to configure the WSUS server synchronization
schedule.
WSUS security roles
In large organizations, you are more likely to separate the roles of server administrator and update administrator. When you install WSUS, two local security groups are created. By adding users to these groups, you grant users the permission to perform the tasks assigned with these roles.
The roles are as follows:
■■
WSUS Administrators Users who are added to the local WSUS Administrators group can perform any WSUS administration task. These tasks include approving updates, managing computer groups, configuring automatic approval rules, and modifying the WSUS server’s update source.
■■
WSUS Reporters Users who are members of this role can run reports on the WSUS server. These reports detail update compliance status on the basis of update and computer.
For example, a user who is a member of this group can run a WSUS report and determine which computers are missing a specific critical update.
WSUS groups
You can use WSUS groups to organize computers for the purpose of deploying updates.
For example, you might have a WSUS group for servers in Sydney and another WSUS group for servers in Melbourne.
A computer can be a member of multiple WSUS groups, and WSUS groups can exist in parent-child relationships.
For example, the Australia WSUS group might have both the Melbourne and Sydney WSUS groups as members. Updates approved for the Australia group are automatically approved for members of the Melbourne and Sydney groups unless overridden.
You can assign computers to WSUS groups manually or through Group Policy. Computers can be assigned to WSUS groups through Group Policy only if the computer groups already exist on the WSUS server. To assign a computer manually, the computer must have already reported to the WSUS server.
Computers that have reported to the WSUS server but have not been assigned to a group will be members of the Unassigned Computers group. An administrator must create WSUS groups.
To create a WSUS group, perform the following steps:
1. Open the Update Services console.
2.Click the group you want to have as the parent group. The Computers/All Computers group is the parent group for all groups.
3.From the Action menu, click Add Computer Group.
4.Specify the computer group name and click Add.
WSUS policies
You can configure most WSUS client options through Group Policy. Many of these policies are related to the experience that users of client operating systems have when updates are installed and are not directly applicable to updating server operating systems. Windows Update policies are located in the Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Update node of a standard GPO, as and are shown in Figure 1-18
.
The most important policies from the perspective of the server administrator are as follows:
■■Configure Automatic Updates You can enable automatic updating, specify a day for update installations, and a time for update installation to occur. It’s usually not a good idea to have this one policy to apply to all servers in your organization. Having all servers install and reboot at the same time can cause substantial disruptions.
■■Specify Intranet Microsoft Update Service Location You can specify the location of the WSUS server and the statistics server. (The statistics server receives information on successful update installation and is usually the same as the WSUS server.)
■■Automatic Update Detection Frequency Determines how often the computer checks for updates.
■■Enable Client-Side Targeting Use this policy to specify which WSUS groups computers
should be a member of. If names do not match, computers will end up in the Unassigned Computers group.
How to Deploy Updates
When you deploy updates, you decide whether to deploy the update, to which computer groups you deploy the update, and what deadline should apply to the deployment.
You can deploy an update multiple times to different groups, so you can deploy an update to a test group and then, if no issues arise with the update, deploy the update more generally.
To deploy an update, perform the following steps:
1. Open the Update Services console and select the Updates\All Updates node. You can also choose to select a child node, such as Critical Updates, if you want to view only available critical updates.
2. Set the Approval setting to Unapproved and the Status to Any, as shown in Figure 1-19, and click Refresh. All unapproved updates are then listed.
.3.Click an update or click multiple updates if you want to select more than one update; then click Approve in the Actions pane.4. In the Approve Updates dialog box, select which computer groups the update is approved for. Figure 1-20 shows updates approved for the Sydney-Development-Servers group.
You can choose between the following settings:
■■ Approved for Install Approves the update.
■■ Approved for Removal Removes a previously deployed update.
■■ Not Approved Does not approve the update.
■■Keep Existing Approvals Inherits the approval from the parent group.
■■Deadline Specifies an update deployment deadline
.Prior to deploying updates, you should perform a synchronization, which will ensure that the WSUS server is to be up to date before choosing whether to deploy updates.
Automatic approval rules
Automatic approval rules enable specifically categorized updates to be automatically approved.
For example, you might choose to automatically approve critical updates for the Sydney-Development-Servers WSUS group, as shown in Figure 1-21.
.To configure an automatic approval rule, perform the following steps:
1. Open the Update Services console. You can do this from the Tools menu of Server Manager, or by right-clicking the server in a server group and clicking Windows Server Update Services.
2. In the Update Services console, click Options and then click Automatic Approvals.
3.In the Automatic Approvals dialog box, click New Rule.
4.In the Add Rule dialog box, choose the following rule options:
■■
When An Update Is In A Specific Classification You can choose that the rule applies when an update matches a specific classification or number of classifications. Update classifications include Critical Updates, Definition Updates, Drivers, Feature Packs, Security Updates, Service Packs, Tools, Update Rollups, and Updates. Microsoft includes classifications for each software update when it publishes the update.
■
When An Update Is For A Specific Product You can specify products, either by category, such as Exchange, or by specific product, such as Exchange Server 2013.
■■
Approve The Update For A Specific Computer Group The update can be approved for selected computer groups.
■■
Set An Approval Deadline Sets an installation deadline for the update based on the time and date the update was first approved.
.Lesson summary
■■
Install WSUS in autonomous mode if you want to have an administrator manage updates for computers that report to the WSUS server. Install WSUS in replica mode if you want to have other WSUS servers inherit another WSUS server’s configuration.
■■
Create computer groups using the WSUS console and then use Group Policy to assign computers to these groups.
■■
Create automatic deployment rules to automatically approve updates to WSUS clients. Use automatic deployment rules for computers only where you will not be testing updates prior to deploying them.
■■
Use the WSUS Administrators local group to grant users the ability to manage WSUS update deployments.
■■
Use Windows Intune to manage update deployment to computers that are outside the perimeter network.
■■
Use System Center 2012 Configuration Manager to deploy updates to third-party products.
No comments:
Post a Comment