New book: Windows 7 Administrator’s Pocket Consultant

Windows 7 Administrator's Pocket Consultant, by William Stanek, series editor of our Administrator’s Pocket Consultant series, is now available. The book provides 704 pages of easily accessible details related to the daily administration of Windows 7; its ISBN is 9780735626997.

William is a Microsoft MVP with more than 20 years of experience in systems management and advanced programming. He is an award-winning author who’s written more than 100 books, including Windows Server 2008 Inside Out.

In this post you’ll find the book’s Introduction and an excerpt from Chapter 9, “Installing and Maintaining Programs.”

First the Intro:

Introduction

Writing Windows 7 Administrator’s Pocket Consultant was a lot of fun—and a
lot of work. As I set out to write this book, my initial goals were to determine
how Windows 7 was different from Windows Vista and Windows XP and what new
administration options were available. As with any new operating system—but
especially with Windows 7—I had to do a great deal of research and a lot of digging
into the operating system internals to determine exactly how things work.

When you start working with Windows 7, you’ll see at once that the operating
system is different from earlier releases of Windows. What won’t be apparent, however,
is just how different Windows 7 is from its predecessors—and that’s because
many of the most significant changes to the operating system are below the surface.
These changes affect the underlying architecture, as well as the user interfaces, and
they were some of the hardest for me to research and write about.

Because Administrator’s Pocket Consultants are meant to be portable and readable—
the kind of book you use to solve problems and get the job done wherever
you might be—I had to carefully review my research to make sure I focused on the
core aspects of Windows 7 administration. The result is the book you hold in your
hands, which I hope you’ll agree is one of the best practical, portable guides to
Windows 7. Toward that end, the book covers everything you need to perform the
core administrative tasks for computers running Windows 7.

Because my focus is on giving you maximum value in a pocket-size guide, you
don’t have to wade through hundreds of pages of extraneous information to find
what you’re looking for. Instead, you’ll find exactly what you need to address a specific
issue or perform a particular task. In short, the book is designed to be the one
resource you turn to whenever you have questions regarding Windows 7 administration.
It zeroes in on daily administration procedures, frequently used tasks,
documented examples, and options that are representative while not necessarily
inclusive.

One of the goals for this book is to keep its content concise so that it remains
compact and easy to navigate while at the same time packing it with as much information
as possible to make it a valuable resource. Instead of a hefty 1,000-page
tome or a lightweight, 100-page quick reference, you get a valuable resource guide
that can help you quickly and easily perform common tasks, solve problems, and
implement everyday solutions for systems and users.

Who Is This Book For?

Windows 7 Administrator’s Pocket Consultant covers all editions of Windows 7. The
book is designed for:

Current Windows system administrators.
Accomplished users who have some administrator responsibilities.
Administrators upgrading to Windows 7 from earlier releases of Windows.
Administrators transferring from other platforms.

To pack in as much information as possible, I had to assume that you have basic
networking skills and a basic understanding of Windows operating systems. As a
result, I don’t devote entire chapters to understanding Windows basics, Windows
architecture, or Windows networks. I do, however, cover desktop customization,
mobile networking, TCP/IP configuration, user profiles, and system optimization.

The book also goes into depth on troubleshooting, and I’ve tried to ensure that
each chapter, where appropriate, has troubleshooting guidelines and discussions to
accompany the main text. From the start, troubleshooting advice is integrated into
the book—instead of being captured in a single, catchall troubleshooting chapter
inserted as an afterthought. I hope that after you read these chapters and dig into
the details, you’ll be able to improve the overall experience of your users and reduce
downtime.

How Is This Book Organized?

Windows 7 Administrator’s Pocket Consultant is designed to be used in daily administration,
and as such, the book is organized by job-related tasks rather than by
Windows 7 features. The books in the Administrator’s Pocket Consultant series are
down-and-dirty, in-the-trenches books.

Speed and ease of reference are essential elements of this hands-on guide. The
book has an expanded table of contents and an extensive index for finding answers
to problems quickly. Many other quick reference features have been added as well.
These features include step-by-step instructions, lists, tables with fast facts, and
extensive cross-references.

Conventions Used in This Book

I’ve used a variety of elements to help keep the text clear and easy to follow. You’ll
find code listings in monospace type, except when I tell you to actually type a
command. In that case, the command appears in bold type. When I introduce and
define a new term, I put it in italics.

Other conventions include the following:

Note To provide additional details about a particular point that needs emphasis

Tip To offer helpful hints or additional information

Caution To warn you when there are potential problems you should look out for

Real World To provide real-world advice when discussing advanced topics

I truly hope you find that Windows 7 Administrator’s Pocket Consultant provides
everything you need to perform the essential administrative tasks on Windows 7
systems as quickly and efficiently as possible. You are welcome to send your
thoughts to me at williamstanek@aol.com. Thank you.

And here’s the opening of Chapter 9:

Chapter 9

Installing and Maintaining Programs

Managing Application Virtualization and Run Levels 311
Installing Programs: The Essentials 318
Deploying Applications Through Group Policy 322
Configuring Program Compatibility 324
Managing Installed and Running Programs 328

Administrators and support staff often install and configure applications that
are used on desktop computers. You need to install and configure applications
before deploying new computers, install new applications on computers
when the programs are requested, and update applications when new versions
become available. Also, as users install additional applications, you might be called
on to help troubleshoot installation problems or to help uninstall programs. Most
program installation problems are fairly easy to solve if you know what to look
for. Other problems are fairly difficult to resolve and require more work than you
might expect. In this chapter, you’ll learn how User Account Control (UAC) affects
how you install and run applications and about techniques for installing, uninstalling,
and maintaining programs.

Managing Application Virtualization and Run Levels

User Account Control (UAC) changes the way that applications are installed and
run, where applications write data, and what permissions applications have. In
this section, I’ll look at how UAC affects application installation, from application
security tokens to file and registry virtualization to run levels. This information is
essential when you are installing and maintaining applications on Windows 7.

Application Access Tokens and Location Virtualization

All applications used with Windows 7 are divided into two general categories:

UAC-compliant Any application written specifically for Windows Vista or
Windows 7 is considered a compliant application. Applications certified as
complying with the Windows 7 architecture have the UAC-compliant logo.
Legacy Any application written for Windows XP or an earlier version of
Windows is considered a legacy application.

The distinction between UAC-compliant applications and legacy applications
is important because of the architectural changes required to support UAC.
UAC-compliant applications use UAC to reduce the attack surface of the operating
system. They do this by preventing unauthorized programs from installing or
running without the user’s consent and by restricting the default privileges granted
to applications. These measures make it harder for malicious software to take over a
computer.

Note The Windows 7 component responsible for UAC is the Application Information
service. This service facilitates the running of interactive applications with an
“administrator” access token. You can see the difference between the administrator
user and standard user access tokens by opening two Command Prompt windows,
running one with elevation (right-click, and then click Run As Administrator), and
the other as a standard user. In each window, type whoami /all and compare the
results. Both access tokens have the same security identifiers (SIDs), but the elevated,
administrator user access token will have more privileges than the standard user
access token.

All applications that run on Windows 7 derive their security context from the
current user’s access token. By default, UAC turns all users into standard users even
if they are members of the Administrators group. If an administrator user consents
to the use of her administrator privileges, a new access token is created for the user.
It contains all the user’s privileges, and this access token—rather than the user’s
standard access token—is used to start an application or process.

In Windows 7, most applications can run using a standard user access token.
Whether applications need to run with standard or administrator privileges depends
on the actions the application performs. Applications that require administrator
privileges, referred to as administrator user applications, differ from applications
that require standard user privileges, referred to as standard user applications, in the
following ways:

Administrator user applications require elevated privileges to run and perform
core tasks. Once started in elevated mode, an application with a user’s
administrator access token can perform tasks that require administrator
privileges and can also write to system locations of the registry and the file
system.
Standard user applications do not require elevated privileges to run or to
perform core tasks. Once started in standard user mode, an application with
a user’s standard access token must request elevated privileges to perform
administration tasks. For all other tasks, the application should not run using
elevated privileges. Further, the application should write data only to nonsystem
locations of the registry and the file system.

Applications not written for Windows 7 run with a user’s standard access token
by default. To support the UAC architecture, these applications run in a special compatibility
mode and use file system and registry virtualization to provide “virtualized”
views of file and registry locations. When an application attempts to write to a
system location, Windows 7 gives the application a private copy of the file or registry
value. Any changes are then written to the private copy, and this private copy is
then stored in the user’s profile data. If the application attempts to read or write to
this system location again, it is given the private copy from the user’s profile to work
with. By default, if an error occurs when the application is working with virtualized
data, the error notification and logging information show the virtualized location
rather than the actual location that the application was trying to work with.

Application Integrity and Run Levels

The focus on standard user and administrator privileges also changes the general
permissions required to install and run applications. In Windows XP and earlier
versions of Windows, the Power Users group gave users specific administrator
privileges to perform basic system tasks when installing and running applications.
Applications written for Windows 7 do not require the use of the Power Users
group. Windows 7 maintains it only for legacy application compatibility.

As part of UAC, Windows 7 by default detects application installations and
prompts users for elevation to continue the installation. Installation packages for
UAC-compliant applications use application manifests that contain run-level designations
to help track required privileges. Application manifests define the application’s
privileges as one of the following:

RunAsInvoker Run the application with the same privileges as the user.
Any user can run the application. For a standard user or a user who is a
member of the Administrators group, the application runs with a standard
access token. The application runs with higher privileges only if the parent
process from which it is started has an administrator access token. For example,
if you open an elevated Command Prompt window and then launch
an application from this window, the application runs with an administrator
access token.
RunAsHighest Run the application with the highest privileges of the user.
The application can be run by both administrator users and standard users.
The tasks the application can perform depend on the user’s privileges. For a
standard user, the application runs with a standard access token. For a user
who is a member of a group with additional privileges, such as the Backup
Operators, Server Operators, or Account Operators group, the application
runs with a partial administrator access token that contains only the privileges
the user has been granted. For a user who is a member of the Administrators
group, the application runs with a full administrator access token.
RunAsAdmin Run the application with administrator privileges. Only
administrators can run the application. For a standard user or a user who is
a member of a group with additional privileges, the application runs only if
the user can be prompted for credentials required to run in elevated mode
or if the application is started from an elevated process, such as an elevated
Command Prompt window. For a user who is a member of the Administrators
group, the application runs with an administrator access token.

To protect application processes, Windows 7 labels them with integrity levels
ranging from high to low. Applications that modify system data, such as Disk
Management, are considered high integrity. Applications performing tasks that
could compromise the operating system, such as Windows Internet Explorer 8 in
Windows 7, are considered low integrity. Applications with lower integrity levels
cannot modify data in applications with higher integrity levels.

Windows 7 identifies the publisher of any application that attempts to run with
an administrator’s full access token. Then, depending on that publisher, Windows 7
marks the application as belonging to one of the following three categories:

Windows Vista / Windows 7
Publisher verified (signed)
Publisher not verified (unsigned)

To help you quickly identify the potential security risk of installing or running the
application, a color-coded elevation prompt displays a particular message depending
on the category to which the application belongs:

If the application is from a blocked publisher or is blocked by Group Policy,
the elevation prompt has a red background and displays the message “The
application is blocked from running.”
If the application is administrative (such as Computer Management), the
elevation prompt has a blue-green background and displays the message
“Windows needs your permission to continue.”
If the application has been signed by Authenticode and is trusted by the
local computer, the elevation prompt has a gray background and displays the
message “A program needs your permission to continue.”
If the application is unsigned (or is signed but not yet trusted), the elevation
prompt has a yellow background and red shield icon and displays the message
“An unidentified program wants access to your computer.”

Prompting on the secure desktop can be used to further secure the elevation
process. The secure desktop safeguards the elevation process by preventing spoofing
of the elevation prompt. The secure desktop is enabled by default in Group
Policy, as discussed in the section “Optimizing User Account Control and Admin
Approval Mode” in Chapter 5.

Setting Run Levels

By default, only applications running with a user’s administrator access token run in
elevated mode. Sometimes, you’ll want an application running with a user’s standard
access token to be in elevated mode. For example, you might want to start the
Command Prompt window in elevated mode so that you can perform administration
tasks.

In addition to application manifests (discussed in the previous section),
Windows 7 provides two different ways to set the run level for applications:

Run an application once as an administrator.
Always run an application as an administrator.

To run an application once as an administrator, right-click the application’s
shortcut or menu item, and then click Run As Administrator. If you are using a
standard account and prompting is enabled, you are prompted for consent before
the application is started. If you are using a standard user account and prompting
is disabled, the application will fail to run. If you are using an administrator account
and prompting for consent is enabled, you are prompted for consent before the
application is started.

Windows 7 also enables you to mark an application so that it always runs with
administrator privileges. This approach is useful for resolving compatibility issues
with legacy applications that require administrator privileges. It is also useful for
UAC-compliant applications that normally run in standard mode but that you use to
perform administration tasks. As examples, consider the following:

A standard application written for Windows 7 is routinely run in elevated
mode and used for administration tasks. To eliminate the need to right-click
the application shortcut and choose Run As Administrator before running
the application, you can mark it to always run as an administrator.
An application written for Windows XP or an earlier version of Windows
requires administrator privileges. Because this program is configured to use
standard mode by default under Windows 7, the program isn’t running properly
and is generating numerous errors. To resolve the compatibility problem,
you could create an application compatibility shim using the Windows
Application Compatibility Toolkit (ACT) version 5.5 or later. As a temporary
solution, you can mark the application to always run as an administrator.

Note You cannot mark system applications or processes to always run with
administrator privileges. Only nonsystem applications and processes can be marked
to always run at this level.

Real World The Windows Application Compatibility Toolkit (ACT) is a solution
for administrators that requires no reprogramming of an application. ACT can help
you resolve common compatibility problems. For example, some programs run
only on a specific operating system or when the user is an administrator. Using ACT,
you can create a shim that responds to the application inquiry about the operating
system or user level with a True statement, which allows the application to run. ACT
also can help you create more in-depth solutions for applications that try to write to
protected areas of the operating system or use elevated privileges when they don’t
need to. ACT can be downloaded from the Microsoft Download Center (http://download.
microsoft.com).

You can mark an application to always run as an administrator by following these
steps:

1. On the Start menu, locate the program that you want to always run as an
administrator.
2. Right-click the application’s shortcut, and then click Properties.
3. In the Properties dialog box, click the Compatibility tab, shown in Figure 9-1.

4. Do one of the following:

To apply the setting to the currently logged-on user, select the Run This
Program As An Administrator check box, and then click OK.
To apply the setting to all users on the computer and regardless of which
shortcut is used to start the application, click Change Setting For All Users
to display the Properties dialog box for the application’s .exe file, select the
Run This Program As An Administrator check box, and then click OK twice.

Note If the Run This Program As An Administrator option is unavailable, it means
that the application is blocked from always running at an elevated level, the application
does not require administrator credentials to run, or you are not logged on as
an administrator.

The application will now always run using an administrator access token. Keep
in mind that if you are using a standard account and prompting is disabled, the
application will fail to run.

Optimizing Virtualization and Installation Prompting for Elevation

With regard to applications, two areas of User Account Control can be customized:

Automatic installation detection and prompting
Virtualization of write failures

In Group Policy, you can configure these features by using the Administrative
Templates policies for Computer Configuration under Windows Settings\Security
Settings\Local Policies\Security Options. The security settings are as follows:

User Account Control: Detect Application Installations And Prompt
For Elevation Determines whether Windows 7 automatically detects
application installation and prompts for elevation or consent. (This setting
is enabled by default in Windows 7.) If you disable this setting, users are not
prompted, in which case, the users will not be able to elevate permissions by
supplying administrator credentials.
User Account Control: Virtualize File And Registry Write Failures To
Per-User Locations Determines whether file and registry virtualization is
on or off. Because this setting is enabled by default, error notifications and
error logging related to virtualized files and registry values are written to the
virtualized location rather than the actual location to which the application
was trying to write. If you disable this setting, the application will silently fail
when trying to write to protected folders or protected areas of the registry.

In a domain environment, you can use Active Directory–based Group Policy to
apply the security configuration you want to a particular set of computers. You can
also configure these settings on a per-computer basis by using local security policy.
To do this, follow these steps:

1. Click Start, point to All Programs, Administrative Tools, and then click Local
Security Policy. This starts the Local Security Policy console.
2. In the console tree, under Security Settings, expand Local Policies, and then
select Security Options.
3. Double-click the setting you want to work with, make any necessary changes,
and then click OK.

Installing Programs: The Essentials

Program installation is fairly straightforward. Not so straightforward are troubleshooting
the many things that can go wrong and fixing problems. To solve problems
that might occur, you first need to understand the installation process. In many
cases, the typical installation process starts when Autorun is triggered. Autorun in
turn invokes a setup program. Once the setup program starts, the installation process
can begin. Part of the installation process involves checking the user’s credentials
to ensure that he or she has the appropriate privileges to install the program
and prompting for consent if the user doesn’t. As part of installing a program,
you might also need to make the program available to all or only some users on a
computer.

Occasionally, Windows might not be successful in detecting the required installation
permissions. This can occur if the installation manifest for the program has an
embedded RequestedExecutionLevel setting that has a value set as RequireAdministrator.
Because the RequestedExecutionLevel setting overrides what the installer
detects in Windows, the installation process fails any time you run the installer with
standard user permissions. To solve this problem, back out of the failed installation
by exiting, canceling the installation, or taking another appropriate action. Next,
locate the executable file for the installer. Right-click this file, and then click Run As
Administrator to restart the installation process with administrator privileges.

Additionally, it is important to understand that in Windows 7 and Windows
Server 2008 Release 2, Application Control policies replace Software Restriction
policies. Software Restriction policies control the applications that users can install
and run on Windows 2000, Windows XP, and Windows Vista. Application Control
policies control the applications that users can install and run on Windows 7 and
Windows Server 2008 Release 2. Keep the following in mind:

When you are editing a Group Policy object (GPO), you can create and
manage Software Restriction policies by using settings for computers under
Computer Configuration\Policies\Windows Settings\Security Settings\Software
Restriction Policies and settings for users under User Configuration\
Policies\Windows Settings\Security Settings\Software Restriction Policies.
Enforcement settings control how restrictions are applied. Designated file
types determine what is and what is not considered an executable program.
When you are editing a GPO, you can create and manage Application Control
policies by using settings for computers under Computer Configuration\
Policies\Windows Settings\Security Settings\Application Control Policies. You
can now create separate rules for executable files, Windows installer files,
and script files. Rules can be applied by publisher, file path, or file hash. A
publisher rule gives you the most flexibility, enabling you to specify which
products and versions to allow. For example, you could allow Microsoft Word
2003 or later.