To configure Windows Deployment Services

1. Ensure that you are a Domain Administrator.
   
2. Click Start, click Administrative Tools, and then click Windows Deployment Services. If there is not a server listed under the Servers node, right-click the Servers node and click Add Server to add the local computer.
   
3. In the left pane of the Windows Deployment Services MMC snap-in, expand the list of servers.
   
4. Right-click the server, and then click Configure Server (Note that the screenshots included in this document are from Windows Server 2008).
   
5. Follow the instructions in the wizard.
   
6. When the configuration is completed clear the Add images to Windows Deployment Services now check box and then click Finish.
   

Now that you have configured the server, you will need to add images. For instructions, see the next section.

Steps for adding images

You must add at least one boot image and one install image before you will be able to boot to the Windows Deployment Services server and install an image.

• Boot images. Boot images are Windows PE images that you boot a client computer into to perform an operating system installation. In most scenarios, you should use the Boot.wim file on the product DVD from one of the following operating systems:
  
  
  • Client: Windows Vista (with at least Service Pack 1 (SP1)) or Windows 7
    
  • Server: Windows Server 2008 or Windows Server 2008 R2
    
  You can also use custom boot images that you have created using the Windows AIK (for example, for diagnostic testing).
  
• Install images. Install images are the operating system images that you deploy to the client computer. You can use the Install.wim file from the product DVD to deploy images for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. For operating systems released prior to Windows Vista, you must create a custom install image. For instructions, see Creating Custom Install Images and Deploying Earlier Versions of Windows.
  

To add the Install.wim from the product DVD, use the following procedures.

To add the default install image included on the product DVD

1. In the Windows Deployment Services MMC snap-in, right-click the Install Images node, and then click Add Install Image.
   
2. Specify a name for the image group, and then click Next.
   
3. Browse to select the default install image (Install.wim), which is located in the \Sources folder of the product DVD, and then click Open.
   
4. To add a subset of the images included in the Install.wim file, clear the check boxes for the images that you do not want to add to the server. You should add only the images for which you have licenses.
   
5. Follow the instructions in the wizard to add the images.
   
6. Click the image group to verify that the correct images were added.
   
7. Repeat this procedure to add any additional install images.
   

To add the default boot image included on the product DVD

1. In the left pane of the Windows Deployment Services MMC snap-in, right-click the Boot Images node, and then click Add Boot Image.
   
2. Browse to choose the default boot image (Boot.wim) on the product DVD, located in the \Sources folder.
   
3. Click Open and then click Next.
   
4. Follow the instructions in the wizard to add the image.
   
5. Repeat this procedure to add any additional boot images. When multiple boot images are available to client computers, clients will be presented with a boot menu that displays the boot images. For more information, see Managing the Boot Menu (http://go.microsoft.com/fwlink/?LinkId=115305).
   
6. If you want to modify any of the settings of the server, right-click the server in the MMC-snap in, and click Properties.
   
7. Now that you have at least one boot and install image on the server, you can perform a PXE boot on a client computer to install an operating system using the steps in the following section.
   

Installing an install image

After you have at least one boot and one install image on the server, you can deploy an install image.

Prerequisites for installing an install image

• The client computer must be capable of performing a PXE boot.
  
• Your user account must be a member of the Domain Users group.
  
• The client computer must have at least 512 MB of RAM, which is the minimum amount of RAM for using Windows PE.
  
• The client must meet the system requirements for the operating system of the install image.

Source:
Microsfot.technetsupport.com
Published By
S.G.Godwin Dinesh.MCA
Sr.System Administrator
 

Server Manager command-line tools, dism, pkgmgr, and ocsetup

Server Manager command-line tools differ from other command-line tools, such as dism, pkgmgr and ocsetup, that are used to install and remove Windows software packages. We recommend that you use Windows PowerShell cmdlets for Server Manager or the ServerManagerCmd.exe command prompt utility for installing or removing roles, role services, and features on a computer that is running Windows Server 2008 R2.

The following list includes ways in which the Server Manager cmdlet set and command prompt utility differ from dism, pkgmgr and ocsetup, and describes advantages of Server Manager command tools for administrators who want to deploy a server as efficiently as possible.

The Server Manager command line is consistent in function and terminology with the deployment and management capabilities of the Server Manager console in the Windows Server 2008 R2 UI.

The type of packages or files in which a role, role service, or feature are contained do not have to be known by users. The Server Manager command line requires only the name of the role, role service, or feature that the administrator wants to install or remove. Administrators do not have to provide any path or file names of role, role service, or feature packages.

Administrators do not have to specify dependencies between roles, role services, and features when they are using the Server Manager command line. The Server Manager command prompt utility automatically installs any other software packages that are required to use the role, role service, or feature specified in the command.

If problems occur with an installation or removal, error handling for ServerManagercmd.exe simplifies troubleshooting and provides clear actions to the user.

The -whatIf parameter of ServerManagercmd.exe lets users verify what actions their commands will perform before they initiate commands and change the system. There is no comparable command parameter included with dism, pkgmgr, and ocsetup.

The Get-WindowsFeature cmdlet and the -query parameter of ServerManagerCmd.exe give users complete views of which roles, role services, and features are available for installation on the computer, and which are currently installed. There is no comparable parameter included with dism, pkgmgr and ocsetup.

Both the input and output of the Server Manager command line is XML based. ServerManagercmd.exe accepts an XML answer file itemizing roles, role services, and features to be installed or removed. Both the results of installation and removal operations, and -query results can be exported to XML files. This enables automation scenarios in which other software can generate and interpret the XML files that are used with the Server Manager command prompt utility.




Source:
technet.microsoft.com

Published By
S.G.Godwin Dinesh.MCA
Sr.System Administrator

Install the Remote Desktop Web Access Role Service

To install the RD Web Access role service

1. On the computer on which you want to install the RD Web Access role service, open Server Manager. To open Server Manager, click Start, point to Administrative Tools, and then click Server Manager.
   
2. If the Remote Desktop Services role is not already installed:
   
   1. Under Roles Summary, click Add Roles.
      
   2. On the Before You Begin page, click Next.
      
   3. On the Select Server Roles page, select the Remote Desktop Services check box, and then click Next.
      
   4. Review the Remote Desktop Services page, and then click Next.
      
   5. On the Select Role Services page, select the Remote Desktop Web Access check box.
      
   If the Remote Desktop Services role is already installed:
   
   1. Under Roles Summary, click Remote Desktop Services.
      
   2. Under Role Services, click Add Role Services.
      
   3. On the Select Role Services page, select the Remote Desktop Web Access check box.
      
3. Review the information about the required role services, and then click Add Required Role Services.
   
4. Click Next.
   
5. Review the Web Server (IIS) page, and then click Next.
   
6. On the Select Role Services page, where you are prompted to select the role services that you want to install for IIS, click Next.
   
7. On the Confirm Installation Selections page, click Install.
   
8. On the Installation Progress page, installation progress will be noted.
   
9. On the Installation Results page, confirm that the installation succeeded, and then click Close.
   
   Source:
   www.technet.microsoft.com
   
   Published By
   S.G.Godwin Dinesh.MCA
   Sr.System Administrator
   

Copy GPO settings only to new empty GPO - same domain (Windows Server 2008 R2)

If you need filtering for GPOs and GPPs, do as little filtering as you can. If you use GPP, put all items for one area into one GPO (registry or printers, eg). If you filter for Registry Items, use collections where possible. And if you have to decide whether to use WMI filter or ILT, it depends - on the cost of your query, on the cost of invoking a GPP CSE just to find it will be filtered anyway, and on the cost of the number of GPP items with filters you have.

I examined WMI filter performance when using SELECT KeyProperty instead of SELECT * in WMI filters for group policy objects. This proves that WMI filters in GPOs behave exactly the same as when executed on a commandline  Now the question came up: What about Group Policy Preferences Item Level Targeting (ILT)? Does it perform better, equal or worse than WMI filters?

Preparing the testing scenario

To verify, I used almost the same setup as before: A testing OU where I blocked inheritance. A simple GPO with a registry preference item. This GPO I copied 200 times and linked all copies to my testing OU. A WMI filter with 5 queries, and an ILT filter with 5 conditions. Since I needed "comparable" queries and filters, I used WMI Win32_Battery and ILT Battery.

Remark: This test scenario requires modyfing a lot of GPOs - adding a WMI filter (which is impossible through PoSh, unfortunately), changing ILT settings and so on. I simply used some lines of PoSh to accomplish that after doing the required changes in my template GPO "WMI vs ILT":

$GPOName = "WMI vs ILT"
$DN = "OU=WMI-Test,OU=Backoffice,OU=Users,OU=Corp Root,DC=corp,DC=contoso,DC=com"
for ( $i=1; $i -le 200; $i++ ){
    Remove-GPO -Name "$GPOName - $i";
    Copy-GPO -SourceName "$GPOName" -TargetName "$GPOName - $i";
    New-GPLink -Name "$GPOName - $i" -Target $DN;
}

This is what my WMI filter looks like:

(Silly, I still know, but still sufficient... Nonsense anyway, because a WMI filter fails when the first query fails.)

And this is what my ILT looks like - I did one ILT using WMI queries and one ILT using the pre defined "Battery" condition. I OR'ed these conditions - AFAIK ILT skips evaluation for AND conditions as soon as the first condition is not met, very much the same like WMI filters do.

(This is the same gobble-di-goo as in the WMI filter...)

For measurement purposes, this time I opted to use Group Policy Eventlog. I filtered for specific Event IDs, namely 5311 (the last event before GP evaluations starts), 5312 (the first event after GP evaluation finishes) for GPO evaluation and 4016/5016 for GPP extension processing start and end. A list of all GP events can be found in this technet article.

To verify whether CPU performance matters, I used a VM with four virtual processors. I already know WMI filters are single threaded, so they will not benefit from the additional processor power. But I don't know about ILT right now, so let's check this, too... Remaining VM data: Windows 8.1 64 Bit with Update, 8 GB RAM.

Measuring the baseline

The first thing I did was applying my 200 GPOs without any filtering. This gives me the baseline for the time needed anyway for GP Evaluation and Registry Extension Processing. This baseline must be subtracted when comparing WMI and ILT performance in the other tests.

So, our baseline is 14 seconds for evaluating 200 GPOs without WMI filters (~70 ms for each GPO, events 5311/5312). It takes about 46 seconds to process 200 disabled registry items (the highlighted 5016 event) with an "update" action (~230 ms for each item). CPU load was about 25% all the time, which indicates that gpsvc is a completely single threaded process.

Remark: For this test, the registry item was disabled so no registry action happened that could delay the test. In all other tests, the registry item was enabled, but never applied due to filtering -my VM obviously has no battery.

1st Test: WMI filter

This is a total evaluation time of 27 seconds. Subtracting the baseline time gives 13 seconds for WMI filter evaluation (~6.5 ms for each individual query). Not too bad. And if you wonder why it's 6.5 ms and not 1.3 ms - WMI filters fail when the first query fails. So we only evaluated 200 filters and not 5x200=1000 filters.
The WMI filter for Win32_Battery takes about 7 ms.

2nd Test: ILT with WMI query

The following tests were done after removing the WMI filter and implementing ILT for our registry item. First, let's do the WMI ILT - I expect this to perform equally to the WMI filtering.

Subtracting our baseline (46 seconds) gives 73 seconds, which means 7.3 ms for each query (since we OR'ed the queries, we have 1000 queries to execute). Given that we are testing in a VM and in a multitasking environment, that's almost identical to the WMI filter above. To be honest, that is the expected result.  

3rd Test: ILT with "Battery"

Then I changed the ILT from WMI to Battery, as shown in the screen shots at the beginning.

After subtracting the baseline, this filter lasts 63 seconds which is not a huge gain over the WMI query, but it is a notable gain. We are happy about time savings where ever we can find them, and this one are about 15%. Ok, if we only use one ILT, it is a gain of one millisecond. You get the picture :-)

The ILT Battery query takes about 6 ms.

Remark: In this scenario, the WMI filter would be the perfect choice. Not because it is faster, but because it removes the Registry Extension baseline of 46 seconds, too.

4th Test: 200 GPOs with one item vs one GPO with 200 items

This test is to show how performance can blow up if you take care of your GPO design. If we use 200 GPOs, this means the Registry Extension has to read 200 files (registry.xml) from the GPO Sysvol folder. If we put all these items into one single GPO, it has to read - guess what - only one single file.

This is what the one GPO I use now looks like. Remember these are the same 200 registry items with their 5 ILT filters for Battery as in test #3...

Now I ran GPUPDATE one more time and checked the results.



Ooops - processing time dropped down even below our baseline! That's because our baseline also had to process 200 files from sysvol, which is the real performance issue in this case. Reduce the number of GPOs to a reasonable minimum, and do not spread GPP settings over different GPOs - better use ILT.

For the registry thing above: You can create a collection (basically a kind of folder) that holds all your registry items. And you can do ILT for the whole collection, so you need to filter only once. This is the last timestamp for todays blog post.


 
Published By
S.G.Godwin Dinesh.MCA
Sr.System Administrator