The VSS application Volume Shadow Copy Restore provides users with the capability to recover previous versions of data mistakenly deleted, updated, or corrupted. Shadow copies provide instant, point-in-time copies of a specified volume at a scheduled time. Data is then backed up from the shadow volume as opposed to from the original volume; this allows the original volume to continue to accept changes, allowing users to continue working and accessing data while the backup is in process.

One of the nicest features of Shadow Copy Restore is the capability of the end user to restore his own data lost through accidental deletion, unwanted saved changes, or corruption. The bonus here is that once Shadow Copy Restore is configured and users are trained to restore their own data, you can enjoy fewer technical support calls.

To give the end user this capability, install the shadow copies of Shared Folders client pack on the desktop. Upon installation of the Shadow Copies of Shared Folders client software a Previous Versions tab, shown in Figure 7.1, is added to the Properties dialog box of files and folders on network shares. Users access shadow copies via Windows Explorer by selecting one of three options from the Previous Versions tab: View, Copy, or Restore.

Figure 7.1. Accessing shadow copy files.

Viewing the properties of files and folders, using the Previous Versions tab, users are presented with a read-only, point in time, history of the folder or file. Users can view content of past versions of a file or folder and then copy or restore the chosen version.

Folder redirection is a feature of Intellimirror that can be used to redirect certain folders on the network client’s desktop to network locations. There are five special folders located under Documents and Settings: Application Data, Desktop, My Documents, My Pictures, and Start Menu.

The benefits of folder redirection that exist to both user and administrator include the following:

By default in Windows XP redirected folders are automatically made available offline. The benefit here is, as the name states, files stored on the network are available when the computer is offline. This is most beneficial to mobile computer users who need to access their data while on the road. It also benefits the desktop users in the event that the network or server that hosts the data is no longer available.

To override the default behavior of redirected folders automatically being made available offline, which is not recommended because it can prevent users from accessing their data, you can enable the policy Do Not Automatically Make Redirected Folders Available Offline. This setting is found in the Group Policy Editor under User Configuration, Administrative Templates, Network, Offline Files.

The following are some basic rules of thumb to guide the system administrator when using folder redirection:

When organizing user data on the file server(s) by group, time can be saved by redirecting data via Group Policy. For example, within Group Policy, User Configuration, Windows Settings, Folder Redirection, My Documents on the Target tab, shown in Figure 7.2, you can set the users’ My Documents folder to redirect to a specified directory by group membership. Again, use the UNC path incorporating the %username% to let the system create the folder.

Figure 7.2. Redirecting My Documents via Group Policy.

The unattended installation is an optimal deployment method when the goal is to perform a large number of installations while keeping user involvement to a minimum. Preparing for an unattended installation begins with creating the answer file that contains answers to the installation questions that are prompted by Windows Setup.

Creating an answer file can be done using a text editor or by using Setup Manager (Setupmgr.exe). Building an answer file with a text editor (Notepad) is faster and easier than Setup Manager, but is more prone to user error. Setup Manager will prompt for answers and build an answer file based on the responses.

After creating the answer file, a distribution share can be created on a server that the destination computers can access, which contains installations files, device drivers, and any other files required for the custom installation. A distribution share is not required for unattended installations using the operating system CD-ROM.

To perform a clean unattended installation from the operating system CD-ROM, perform the following steps:

To perform a clean unattended installation with MS-DOS startup disk perform the following steps:

The Systems Preparation Tool (Sysprep) is the optimal tool when performing image-based installations with the identical operating system and software configuration on multiple computers as quickly as possible. Sysprep allows for hardware and software differences among computers, minimizes end-user interaction, and reduces the number of images needed.

There are four modes of operation for Sysprep in Windows XP:

When preparing the master installation always start with a clean installation of the operating system and any software applications needed. Be sure to create the master installation on drive C. Also, confirm that the HAL on the master computer is compatible with the HAL of the destination computers.

A typical scenario for creating a master image would be to first run sysprep -factory on a clean installation creating your base master image. By rebooting the system in Factory Mode you can then install any software, drivers, or configuration changes required. When all installation and configuration has been completed run Sysprep -reseal to remove machine-specific information such as the SID, computer name, and so on. The system is now ready to be imaged and deployed en masse to multiple workstations, which requires using a third-party tool.

Some of the advantages of the Sysprep utility include the following:

Windows Server 2003 includes a server and workstation imaging and deployment product called Remote Installation Service (RIS). RIS can be used to store multiple images on a RIS Server, which can then be downloaded over a network connection to the client computer. RIS is very handy, but before desktops are deployed using this product, some testing and planning should be performed.

Installing RIS is a fairly simple process but planning your RIS deployment begins with the installation of RIS itself. As a best practice install RIS and RIS images on separate physical disks than the operating system to improve imaging performance.

Planning how the RIS server will be used can help ensure a successful implementation. Considerations for RIS include deciding how many systems the RIS server should deliver installation images to simultaneously.

Upon initial configuration, consider what the appropriate number of RIS servers will be for the environment. A small, nonrouted, LAN environment, for example, would require only a single RIS server to service all requests up to any network bandwidth or server resource limitations that might exist. In a routed environment set the DHCP forwarding option to allow routers to forward client requests to the RIS servers. Do not use RIS over low-speed links. Offices located on the WAN over a slow link will require their own RIS server. Use the settings that are available when prestaging the client machine to direct the client to be serviced by the RIS server that is in closest proximity on the network to it.

Another consideration during the initial configuration is that restricting installation options increases the number of successful operating systems that can be completed without assistance from the administrator. The default is one installation option and one operating system option to the user.

RIS client computers must support remote boot either with a boot-up disk or using Pre-Boot eXecution Environment (PXE) on compatible systems. Follow best practices for Network Security on any network that includes PXE-enabled computers. Because RIS servers will try to deliver the image to clients as fast as the network can handle, limit RIS server access to LAN clients to avoid having the RIS server saturate WAN links while imaging client computers. Storage is always a big concern for imaging servers and third-party imaging software stores each image in a separate file, which can take up a lot of storage space. Although many times these image files compress fairly well, RIS stores images in their native file formats and replaces duplicate files with file pointers or links to save storage space.

Also, during this process the first installation image will be created. This image is based on a clean OS installation of the particular operating system version. For example, a Windows XP Professional CD could be used for the first image on a Windows Server 2003 RIS server.

Advantages of RIS include the following:

Unless a RIS image will be created only using the Setup Manager Wizard and the installation media for a vanilla installation, Windows XP and any additional updates and applications must be installed on a workstation. First the operating system must be installed and patched to the latest service pack and post service pack release. This will help ensure operating system reliability and security by raising the installation to the latest build and locking down known vulnerabilities.

After the OS is updated Microsoft and third-party applications should be installed and updated to the latest patch level. If necessary, open the applications to verify that all the installation steps have been completed such as registering, customizing, or activating the software.

After the operating system and application software have been successfully installed and configured, the desktop settings can be customized to meet the particular deployment needs. Things that might be performed during this phase are the enabling or configuring of Windows XP programs such as Remote Desktop, Remote Assistance, or Automatic Update. If roaming user profiles are not used in the organization, the desktop settings such as desktop look and feel and including screen resolution and desktop shortcuts and start menu options should be configured. After the desktop has been configured as desired, the administrator account can copy the user profile used to create the settings to the C:Documents and SettingsDefault User folder, assuming that the XP installation is on the C drive.

Many times after you prepare desktop images there are a bunch of annoying things that are discovered after the image has been deployed to the enterprise. Things like leftover mapped drives or local printers or application install points that only exist in the imaging lab remain in the Registry and cause confusion when an application needs to be updated or uninstalled. Something as small as leaving a window open upon logging off of the workstation before the user profile is updated to the default user profile can prove to be very annoying or look unprofessional after image deployment. To avoid the little things that might have the end users, clients, or management view your image deployment as a failure, deploy the images to a few pilot users who will be meticulous enough to alert you of these issues before the entire user base has to experience it themselves.

Before Software Update Service (SUS) 1.0 there was Windows Update service, which was ultimately managed by the end-user and required elevated rights to run. To avoid this scenario most administrators chose to disable Windows Update Service and create, then re-create, images that include the latest patches as they came out. As most of you know or could guess this takes a lot of time and energy.

With the introduction of SUS there is now a free patch management solution provided by Microsoft. Using the Automatic Update client installed with Windows XP Service Pack 1 or later (also installed with Windows 2000 SP3 or later), the automatic update client allows redirection to the SUS server. There are two ways that the redirection can be applied, either the hard way by specifically modifying the desktop Registry, or the easy way, through the use of an Active Directory group policy.

Some of the best practice recommendations in the use of the Software Update Server include the following:

Most organizations have groups or individual network clients who work with or require access to highly confidential data. Such users can be found working in the Human Resources or Payroll departments of the company. Executives in the company also fall under this category. Because these users are privileged to very sensitive information, it is important for you to secure the network accounts used to access this information as well as the means by which this data is accessed.

Because there is probably sensitive data stored on servers that are, in turn, accessed by privileged network clients, you should secure that data as it passes from server to client. Most data is not protected when it travels across the network, so employees, supporting staff members, or visitors might be able to plug into the network and copy data for later analysis. They can also mount network-level attacks against other computers. Windows Internet Protocol Security (IPSec) is a key component in securing data as it travels between two computers. IPSec is a powerful defense against internal, private network, and external attacks because it encrypts data packets as they travel on the wire.

You can create and modify IPSec policies using the IP Security Policy Management snap-in available in the Microsoft Management Console. IPSec policies can then be assigned to the Group Policy Object of a site, domain, or organizational unit. If sensitive data is located on a server, assign the predefined Secure Server policy to the server so that it always requires secure communication. Then assign the predefined Client (Respond Only) policy to the network clients that will communicate with the secure server. This policy ensures that when the network client is communicating with the secure server, the communication is always encrypted. The network client can communicate normally (unsecured) with other network servers.

To assign the Client (Respond Only) IPSec policy in the Group Policy Object, perform the following steps:

Though it might be okay for high-security network clients to communicate normally (unsecured) with other servers within the organization that do not contain sensitive data, there might be a need to limit that client’s ability to communicate outside the organization. There are many settings available within Group Policy to prevent a user from modifying or creating new network connections. For example, a Group Policy setting can be applied to prohibit connecting a remote access connection.

To enable Group Policy settings related to network connections in the Group Policy Editor, navigate to User Configuration/Administrative Templates/Network/Network Connections. Figure 7.4 displays the settings one can enable in this category.

Figure 7.4. Group Policy settings to restrict network connections.

If the secure network clients save sensitive data to their local workstations, additional security can be provided to this data through the Encrypting File System (EFS). Because EFS is integrated with the file system, it is easy to manage and difficult to attack. Moreover, after a user has specified that a file be encrypted, the actual process of data encryption and decryption is completely transparent to the user.

To encrypt a file or folder, follow these steps:

To encrypt and decrypt files, a user must have a file encryption certificate. If the file encryption certificate is lost or damaged, access to the files is lost. Data recovery is possible through the use of a recovery agent. A user account of a trusted individual can be designated as a recovery agent so that a business can retrieve files in the event of a lost or damaged file encryption certificate or to recover data from an employee who has left the company.

One of the many advantages of using Windows Server 2003 domains is that you can configure a domain EFS recovery policy. In a default Windows Server 2003 installation, when the first domain controller (DC) is set up, the domain administrator is the specified recovery agent for the domain. The domain administrator can log on to the first DC in the domain and then change the recovery policy for the domain.

To create additional recovery agents, the user accounts must have a file recovery certificate. If available, a certificate can be requested from an enterprise Certificate Authority (CA) that can provide certificates for your domain. However, EFS does not require a CA to issue certificates, and EFS can generate its own certificates to users and to default recovery agent accounts.

To create an EFS recovery policy for a domain, follow these steps:

For administrative tasks to be performed on workstations such as installing new hardware or configuring user profile settings that are not configured using group policy settings, you can use the tools provided with Windows Server 2003 and Windows XP. Remote Desktop can not only be used to install software remotely, but also it can be used to configure just about everything that could be performed from the local console. The only limitation is that the BIOS settings cannot be controlled so if a remote reboot is performed, and the BIOS is configured to first boot from a floppy disk, if a disk is in the drive the system might never restart and a visit to the workstation will be required.

Starting with Windows Server 2003 and Windows XP the Computer Management console can be used to perform several system-related software and hardware tasks remotely. New features include adding new hardware by scanning for hardware changes or adding local user accounts or local shares or manipulating system services. This tool is very flexible for remote administration.

The multiuser desktop is commonly used in public access situations where the desktop experiences high traffic and must be flexible for some customization, but should remain reliable and unbreakable. Keep the following items in mind when managing multiuser desktops:

Many companies have employees who either frequently travel or are located away from the typical office environment. These mobile users differ from desktop users in that they often log on to the network through a portable computer over a slow-link dial-up modem connection. A good management strategy for this type of user should take into account the lack of local access and connecting to the network over slow-link connection.

Because mobile users spend a majority, if not all, of their time away from the local office they will often find themselves in the unique position of having to provide their own computer support. As this is the case, mobile users often require more privileges than the standard office user. To do this, apply a separate Group Policy Object to your mobile clients that would enable users to perform software and local printer installs while at the same time restricting them from critical system files that might disable their system.

Whether or not the mobile user is connected to the network mobile users will expect to have access to their critical data. Intellimirror simplifies management of the mobile user in that it enables users to work on network files when they are not connected to the network and to have the offline version and the network version synchronize upon the next time the user connects to the network. Although Offline Files is a default feature of Windows XP, you still need to select the network files and folders that will be made available offline.

Another key management concern regarding the mobile user is software installation. It is not recommended to assign or publish software to mobile users who are rarely in the office. If they periodically work in the office, one can set the Group Policy slow-link detection to the default in the user interface so that software will install when the user is connected directly to the local area network (LAN).

One can verify or adjust the connection speed for Group Policy settings in the Group Policy slow-link detection setting. To do this in the Group Policy Object Editor, navigate to Computer Configuration/Administrative Templates/System/Group Policy or User Configuration/Administrative Templates/System/Group Policy.

Mobile users should not, for the most part, be running served applications. Typically, the mobile users’ portable computers should have all the core software installed before they have to work outside the office. If users require additional software after they are in the field and cannot return to the office to have it installed, it might make sense to copy your software packages to CD to be installed locally by the mobile users with elevated privileges.

The public or kiosk workstation exists in the public environment and generally is used to provide access to one or a limited set of applications. You should implement a highly managed configuration that restricts the user from performing any data management, software installs, or system configuration.

Another aspect of the kiosk workstation is that users should not be logging on with username and password; it is better to create a user account that automatically logs on when the computer starts. All users will use this one account to allow access to the applications provided for their use. The application that is being accessed should also be loaded automatically when the computer starts up.

The user should not be able to access Windows Explorer or the command prompt because these can be used to access the system directly. The application itself should be examined to confirm that it does not allow users a backdoor to any part of the system.

Characteristics of the policies associated with locking down the Kiosk workstation include the following:

In many companies, the administrators’ workstations have no controls in place at all. The accounts the administrators use to log on to the network give them access to control every aspect of the workstation, as well as the servers. Because these accounts have so much power over the network, it is recommended that policies be in place to protect that power. This section suggests some recommendations in the proper configuration and use of the administrator workstation.

To make changes in Active Directory, perform system maintenance, run backups and restores, and install software, administrators require a logon account that gives them elevated privileges. At the same time, administrators also perform normal network activity such as reading e-mail, writing documents, and setting schedules. For this reason, administrators should have two or more accounts. They should have an account that behaves as a normal network client account with the same privileges and subject to the same Group Policies as most normal users or power users. This account would then be used as the standard logon for the administrator workstation. Administrators should then have other accounts for workstation administration and network or domain administration that remain secure in virtue of not being used during the day-to-day network client work. Even administrators can inadvertently make damaging changes to a workstation or server configuration if they are logged in with Domain Admin privileges all the time.

To perform many of the tasks required of an administrator the Windows Server 2003 Administration Tool Pack should be installed from the Windows Server 2003 CD. These tools are packaged as adminpak.msi.

The Run As feature can be used from any administrator workstation or any network client to elevate privileges temporarily to perform administrative functions. For example, while logged in to a workstation with a user account that has standard user privileges, you can run Active Directory Users and Computers using the Run As command to execute the utility from an administrative account.

To run an application with the Run As command, do the following:

You should also enforce a password-protected screensaver with a short timeout interval on administrator workstations. This protects the workstation from malicious users taking advantage of the administrator’s credentials should the administrator be temporarily away from the machine.

To specify a particular screensaver with password protection and timeout in a Group Policy, do the following:

Finally, when dealing with a large organization with distributed administration, it is a good idea to delegate authority for network clients to administrator groups based on geographical location. Some organizations make the mistake of creating a global administrators group populated with every administrator in the company. Just because an administrator in the Santa Clara office requires administrative rights over the network clients in his office does not mean that he should also get administrative rights over network clients in Papua, New Guinea. Keeping administrators organized also protects the network clients from receiving improper Group Policy assignments.

Floplock.exe is a utility, first introduced back in the NT 4.0 days, that puts a Discretionary Access Control List (DACL) on the floppy drive, providing the capability to lock the drive to all users except for Administrators and Power Users.

To install the FloppyLocker Service, run the Inetserv.exe utility. From a command prompt type

Instsrv FloppyLocker C:{data path}floplock.exe

After installation, use the services applet to configure the FloppyLocker service. Pick the account that the service should start up under and provide the correct password for the account. Administrator would be the obvious choice.

To remove the FloppyLocker service, type the following:

Instsrv FloppyLocker remove

The FloppyLocker Service can be a useful security feature in both the administrator workstation and kiosk workstation scenarios discussed previously in this chapter.

Netdom.exe is another resource kit utility that was first introduced in the NT 4.0 days that has many uses. It is most commonly used in a scripted installation to join a client computer to the domain. The correct syntax is

netdom join <ComputerName> /domain:<DomainName> /userd:<UserName> /passwordd:
<UserNamePassword>

Using * in place of <UserNamePassword> will prompt the user for password.

Another old-school utility that is still useful today is Con2prt.exe, a command-line utility used to both connect and disconnect connections to network printers. Con2prt.exe is a useful tool for adding network printers while performing a scripted or automated XP desktop deployment.

From the command prompt type

The User State Migration Tool (USMT) provides the same functionality as the Files and Settings Transfer Wizard but on a larger scale for migrating multiple users.

USMT is driven by a shared set of customized .INF files designed to manage the user’s environment and needs.

USMT consists of two executable files: ScanState.exe and LoadState.exe, and four migration rule information files: Migapp.inf, Migsys.inf, Miguser.inf, and Sysfiles.inf. These files can be found on the Windows XP CD-ROM in the ValueaddMsftUsmt folder.

To migrate user data you need to first modify the .INF files to identify which file types, folders, or specific files you wish to migrate. To then gather the specific data run ScanState.exe. ScanState.exe gathers the specified data and copies it to a specified location where it can later be retrieved. Use Loadstate.exe, via script, to then add the user data to the new location, for example a newly imaged XP workstation.