This section describes best practices that adminstrators can use for managing ADS.
Top of section
A.
Network administrators should turn off the DHCP service and DHCP relay on firewalls to prevent an unauthorized server from spoofing as a device.
ADS should be used on a secure network, especially when using the imaging features.
When granting permissions to run a job, do not grant full control to any users. A user with full control can use that template to elevate the credentials of any user to those of an administrator.
If you turn on tracing for any of the ADS services, including those running on devices, the tracing log files are generated and stored in the %systemroot%\Tracing directory, which has read permissions for everyone. For maximum security you should restrict access to this directory to the Administrator account only, which prevents non-administrators from viewing the tracing log files. For more information about tracing, see Using tracing.
For best performance, disable PXE and use static IP addresses on the servers that host the Controller service, NBS, and the Image Distribution service. Otherwise, when the ADS services are installed on separate servers and the Controller is restarted, the Controller will continuously try to receive boot instructions from the NBS, and therefore never boot to its own hard disk.
Changing the Controller service's IP address can lead to loss of device control. The Controller service's network adapter must use a statically allocated IP address. If you change the network adapter's IP address, you should check all ADS network connections, including the connections to NBS, IDS, and to the Administration Agent. Devices running the Deployment Agent will most likely need to be rebooted so that their connections and sequences can be restarted.
To help recover from a software or hardware failure on the computer running the Controller service, it is recommended that you back up the Controller on a regular basis. Should your Controller fail, a backup is the only way to restore functionality without resorting to a reinstallation and reconfiguring of ADS. In particular, be sure to back up the Controller certificates and the Controller database.
If you are using the Microsoft SQL Server Desktop Engine (MSDE) for the Controller database, you must use Transact-SQL to perform a database backup. If you are using Microsoft SQL Server 2005 for the Controller database, you must use either the SQL Server Enterprise Manager or Transact-SQL supplied with SQL Server to perform database backups.
For more information about how to back up a Microsoft SQL Server Desktop Engine (MSDE) using Transact-SQL, see Microsoft Knowledge Base Article - 241397,HOW TO: Back Up a Microsoft Data Engine Database with Transact-SQL.. There are two parts to keeping your Controller backed up. The first is a complete system backup using Windows Backup. The second is maintaining a secure copy of your Controller certificates.
If you decide to use discovery to automatically add records for new devices in your data center, ensure that all new devices are offline before changing the settings. Otherwise, new records could be created for the devices before you configure settings that automatically insert information for new device records, such as a description and default job template. As a result, these new records would lack the information you intend to use for new devices. The recommended procedure is to configure all appropriate settings, then bring the computers online.
You can personalize a device name using the Sysprep.exe System Preparation tool when deploying an operating system image to it. You do this by creating a device variable to store a short name for a device. If the device will join a domain, create a second device variable to store the domain name. The Da-deploy-image-domain.xml sequence sample provided with ADS includes steps that use these variables. There are several reasons to follow this recommendation:
You can avoid this situation by configuring ADS to create a record when a new device boots to the Deployment Agent instead of PXE. Then, create a device variable to store a short, friendly name for the new device. You can use a task sequence and the System Preparation tool to personalize the device with the friendly name when you deploy an image to the new device.
ADS includes sample task sequences that are appropriate for different scenarios, such as when a device has no operating system or when it is ready to run a full operating system. You can assign a task sequence to a device by linking the task sequence to a job template and assigning the job template to the device. For example, the boot-to-da sample is intended for devices without an operating system, and the boot-to-hd sample is intended for devices on which a full operating system is running.
If you turn on tracing for any of the ADS services, including those running on devices, the tracing log files are generated and stored in the systemroot\Tracing directory, which has read permissions for everyone. For maximum security you should restrict access to this directory to the Administrator account only, which prevents non-administrators from viewing the traces.
For more information about tracing, see Using tracing.
Creating and working with certificates containing private keys should be performed in a known secure environment, preferably on a system disconnected from the network.
For more information ADS certificates, see ADS certificates overview.
NBS requires PXE version 0.99c or later. You can determine the PXE version by restarting your computer. The PXE version is displayed as the PXE read-only memory (ROM) is loaded. You cannot use remote boot floppy disks to run a virtual floppy disk image.
Always run antivirus software to scan for viruses on floppy disks used as the image source in the virtual floppy disk image process. In addition, you should scan any computers where you plan to store and use the virtual floppy disk images.
Avoid storing confidential information in a virtual floppy disk because the contents are transmitted in plain text prior to running the virtual floppy disk on the device.
Enabling the trivial file transfer protocol (TFTP) upload option is a security risk. By not enabling the TFTP upload option, you prevent unauthorized devices from uploading malicious files to the TFTP directory.
Configure To PXE to Ignore on the Controller to prevent unauthorized devices from joining sets and to prevent unauthorized access to information stored on the Controller.
Keep the ADS PXE service configuration state variable, PXEUseDHCPPort, consistent with the state of the system. If the DHCP service and ADS PXE service are installed on the same server, set PXEUseDHCPPort to 0. If not, set PXEUseDHCPPort to 1.
Provide access to the systemdrive\Program Files\Microsoft ADS\Tftproot directory to specific user accounts to write virtual floppy disk images. Do not configure TFTP to enable TFTP-put operations, in which the device sends files to the TFTP server. The Windows-based Hosting solution recommends that you create and use relative paths to the tftproot directory, for example,
\FLOPPY\, \FLOPPY\CUSTOMER\*.
If you later decide to move the systemdrive\Program Files\Microsoft ADS\Tftproot directory, you must update the following registry entries with the full path to the \Tftproot directory:
\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ADSBUILDER\ Parameters\TftpRoot \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TFTPD\Parameters\ Directory
In addition, you must copy the NBS files in the existing \Tftproot directory to the new \Tftproot directory, and then in Control Panel, use Services to restart the ADS PXE, Deployment Agent Builder, and TFTPD services.
The server hosting NBS must use a static IP address. Otherwise, the IP address might change while the device is communicating with the ADS PXE service or Deployment Agent Builder service, which would result in a dropped connection.
Many OEMs preconfigure servers with an OEM partition. Images that are captured from a server with an OEM partition should not be deployed to a server without an OEM partition and vice versa.
Before capturing and deploying images, review the partition configuration of the servers from which you are capturing and deploying images. For example, images captured from a server with an OEM partition should only be deployed to another server with an OEM partition. Otherwise, the image might become unusable due to inconsistencies in partition number in the Boot.ini file. The Diskinfo tool can help you analyze the master destination device and determine if an OEM partition exists. Diskinfo is located in the Server Purposing directory. Copy this file to the C:\Program Files\Microsoft ADS\Samples\Sequences directory on Controller.
If you have servers in your data center with and without OEM partitions, consider creating two sets of images: one for servers with an OEM partition and one for servers without an OEM partition. Otherwise, you must modify the Boot.ini file after deploying the image to compensate for the different boot partition.
The samples included with ADS are designed for servers without OEM partitions. To use the samples on a server that has an OEM partition, you must edit the sample and update the partition numbers.
When preparing an image for varied hardware systems, you might need to include drivers for mass storage controllers, display devices, and other hardware. In addition, you might need to accommodate a mix of multiprocessor and uniprocessor systems, as well as systems that are Advanced Configuration and Power Interface (ACPI) – compliant and not ACPI-compliant.
If you are preparing a Windows Server 2003 image, you can find information about accommodating varied hardware systems in the Deploy.chm and Ref.chm Help files, located within the Deploy.cab file in the \Support\Tools\Directory of your Windows Server 2003 family CD. The Unattended Installations topic also describes a method of deploying an operating system to devices that have varied hardware.
If you are preparing a Windows 2000 Server family image, you can find information about accommodating varied hardware systems in the Unattended.doc file, located within the Deploy.cab file in the \Support\Tools\Directory of your Windows 2000 Server family CD.
