Support Deployed Applications

Supporting Printing

Windows Vista comes packaged with a new print management console. Most people are familiar with the printer utility within Control Panel. With this utility, you can add printers, select a printer to manage and view documents within the print queue, and manage print server properties. The newer Print Management console of Windows Vista performs all these same management services within a more inviting management interface. Along with standard printer management, the newer console can filter for printers with certain features, error conditions, location information, queue status, driver names, and various other characteristics. Figure 1 displays the new Print Management console.

Figure 1. The Print Management console of Windows Vista.

A new node object listed in this console is Deployed Printers. Through this node, you are able to view all printers that have been deployed on the local Windows Vista workstation through Group Policy. New to Windows Server 2003 R2 is the capability to deploy printers using the new Deploy Printers node in a Group Policy Object (GPO). Figure 2 shows the new Deployed Printers node in a GPO.

Figure 2. Deploying a printer with Group Policy.

You can deploy printers through either the User Configuration or Computer Configuration in Group Policy.

One final aspect to look at regards printer usage to support legacy application access to printers. Many corporations invested heavily in their DOS-based applications that still provide a viable service to them. Applications developed in the early days of LAN networking required a network mapping to a physical device port in order for the application to use a network printer on DOS and Windows 95 desktops. These applications require legacy access methods to network printers. Using the net command, you can map the network printer to a physical device port such as an LPT printer port. When you use the net command that follows, the printer shared as hplaserj on the print server main is mapped to the lpt1 printer port:

Net use lpt1: \\main\hplaserj

This mapping allows the DOS-based application to use the local LPT port. You can use this logical mapping on each of the available LPT ports on a Windows Vista computer.

Supporting Legacy Applications with Virtual Machines

The section discusses a modern way of dealing with legacy applications. Legacy applications are most comfortable running in the operating system environment for which they were programmed. With virtual machines (VMs), you now have any previous operating system at your disposal. Virtual machines loaded with a guest operating system to match the needs of a legacy application solve many compatibility problems.

Microsoft’s offering for running VMs on Windows Vista is Microsoft Virtual PC 2007. This release of Virtual PC enables the use of Windows Vista as the host operating system as well as a candidate to be a guest operating system. The host manages the virtual machines that operate on the computer. The guest operating system references the virtual machine’s use of a particular operating system within the virtual machine.

Securing Application Data

Securing data, whether it is stored or being transported, is top on the list of concerns of most IT security professionals.

• Data stored on a Microsoft Windows NTFS partition can be stored securely using the Encrypting File System (EFS).

• Data communication between a combination of any two Microsoft Windows computers running Windows 2000, Windows XP, Windows Server 2003, or Windows Vista operating systems can secure that communication with IPSec.

• HTTP traffic can be secured using Secure Sockets Layer (SSL).

• Remote Desktop connections can be encrypted with the inherent security settings of a remote desktop connection.

• Virtual Private Network (VPN) communication can be secured using either the PPTP or L2TP protocols.

Deploying Applications

Applications deployed through Group Policy can be deployed per user or per computer. Applications deployed per user can utilize Group Policy to either assign or publish those applications. Applications deployed per computer can be assigned only to a computer. When you are troubleshooting applications deployed through Group Policy, understanding these methods is important. In addition, several other policies can be implemented to secure the deployment of the applications, secure the deployed applications, and restrict users from running unauthorized applications.

Troubleshooting Published Applications

Recall that applications published to a user are essentially advertised as being available either through an icon displayed on the desktop, in the taskbar, or in the program folder off the Start menu. In addition, users can initialize installation of published applications by clicking on a document with an extension associated to the newly published application. Ensure users to whom the application was published have appropriate permissions to access the software distribution point to perform the installation. Usually, the Share permission Read and the NTFS permissions Read and Execute are sufficient.

Troubleshooting Assigned Applications

Applications assigned to computers are installed prior to the user logon after the operating system has been fully started and Group Policy has been deployed to the computer. Applications assigned to users are installed upon logon and execution of Group Policy to the user. Application extensions can be associated to the newly deployed application by Group Policy or the software installation process. Once again, the users or computers require the necessary permission to run the installation from the software distribution point.

Troubleshooting Deployed Applications

Because applications have been written for various Windows platforms, older applications often write data and temporarily cache files to locations that Windows Vista no longer allows by default. Another issue is that the application caches application installation information in the user’s profile, including the transform files used to modify an application during installation. With any of these preceding issues, allowing application data to be written to secure locations, application transform files to be saved and used from a user’s profile, or temporary variables to be written to locations that are inappropriate creates unnecessary security issues for you.

Instead of opening security holes inside Windows Vista, Microsoft has created a few workarounds to ensure security of the Windows Vista operating system and allow the applications to run or install and be modified appropriately sometime later.

The application transform files are used by the Windows installer to modify an application installation. These files are installed by default in the Application Data folder of the user’s profile so that these files are available to the user when the application is modified or removed. If these files require secure access so as to disallow a user from making modifications to these files inappropriately, you can configure the Windows installer to cache the transform files in a secure location on the user’s computer but not in the user’s profile. The policy to enable this feature is found within the Administrative Templates of the Computer configuration for a Group Policy at Computer Configuration > Administrative Templates > Windows Components > Windows Installer.

The user would have to be using the same computer where the application was installed and, if necessary, have access to any remote media used to run the original installation to ensure any modification, reinstallation, or proper removal of the application from the computer because the cache transforms are not available in the user’s profile.

If a user is running an older application that was successfully deployed but requires access to locations that are not allowed by Windows Vista for a Standard user account, another policy setting may help out here. The UAC Group Policy User Account Control: Virtualize File and Registry Write Failures to Per-User Locations option in the local security policy allows the application to run without errors by redirecting application output to locations acceptable for a standard user.

Another common issue is the use of the System variable %WINDIR%\TEMP or User Profile variable %USERPROFILE%\AppData\Local\Temp for temporary application output on drives with low disk space. These folders are usually located on the boot partition or folder locations on the C: drive. If this drive is running low in disk space and another drive is installed and formatted, you can edit the Temp or TMP variables as shown in Figure 3.

Figure 3. Editing system and user variables.

You can edit these variables if you are the local administrator. You can locate them inside the Advanced system settings by following Control Panel > System and Maintenance > System > Advanced System Settings > Environment Variables.

Finally, if remote users require the ability to install applications uninhibited on their computers, allowing them access to the local administrator’s account would resolve this problem. There are many ways to tweak the Registry through Group Policy, disabling most of the nuisances that User Account Control may create, but ultimately some applications just require local administrator access for successful installation.