Troubleshooting Aids

There are many registry-editing tips and tricks that can be used to customize the Windows XP or Windows Server 2003 user interface. Unfortunately, it's impossible to describe them all; even books dedicated to this topic usually only show the top of the iceberg. Some of these registry-editing techniques can be used as troubleshooting aids. In this section, I'll describe those that may be the most helpful.

Customizing System Restore for Windows XP Workstations within Your Domain Environment

System Restore, introduced with Windows XP, is one of the most useful features of this operating system (OS). Unfortunately, some users tend to disable it because it consumes a lot of free disk space (no less than 200 MB). If you are an administrator, you can prevent users from disabling System Restore. To achieve this, simply disable the GUI tools available on Windows XP workstations for configuring System Restore within your domain environment.

Note 

To perform these tasks, log on as Administrator or user with administrative privileges.

There are two ways of performing this task. Let's consider them both.

Using Group Policy Editor to Disable System Restore

To prevent users from disabling or configuring System Restore:

  1. Open the Group Policy tool MMC snap-in, focused on a specific GPO. To do so, start the Active Directory Users and Computers MMC snap-in, right-click the name of the domain or organizational unit (OU) of interest, and select the Properties command from the context menu. Go to the Group Policy tab and highlight the GPO of interest. (Note that if you haven't created any GPOs, only the Default Domain Policy will be available.) Click the Edit button.

  2. Expand the console tree Computer Configuration | Administrative Templates | System | System Restore (Fig. 13.10).

    click to expand
    Figure 13.10: Configuring System Restore using Group Policy Editor

  3. Double-click Turn off System Restore. On the Setting tab, select Disable. After you apply this policy, System Restore will be turned on and enforced. Click Apply, then click OK.

  4. Double-click Turn off Configuration. On the Setting tab, select Enable. (For more information about what these settings do, click the Explain tab on the Properties dialog box.) Click Apply, then click OK.

  5. Open a command prompt and type the gpudate command to refresh the policy.

Note 

Gpupdate is the command introduced with Windows XP and Windows Server 2003 for refreshing Group Policy. This command replaces the secedit refreshpolicy command used in Windows 2000. If you choose not to use the gpupdate command, Group Policy will still refresh; it will just take longer. The settings described above are only read at boot time; therefore, it is necessary to reboot.

Now, if users try to access System Restore Configuration on their Windows XP computers within your domain environment, the System Properties dialog box is present, but the System Restore tab is not.

Using Registry Editor to Disable System Restore

On standalone Windows XP computers or within a workgroup environment, you can either apply the setting described above in local security policy or make the registry key modification. As outlined in Chapter 11, applying changes via Local Security Policy is easier and much safer. However, direct registry editing might be preferable, especially if you have to update a large number of Windows XP workstations within a workgroup environment. To use Registry Editor for disabling the System Restore Configuration UI on a standalone Windows XP computer or within a workgroup environment, proceed as follows:

  1. Start Regedit.exe and expand the following key:

        HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT 
  2. Under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT, create a new nested key, named SystemRestore.

  3. Within this key, create a new REG_DWORD value named DisableConfig, and set this value to 1.

  4. Close Regedit.exe and reboot the system.

Note 

You can manage settings by including the modified registry key in a script. More information on this topic will be provided in Chapter 15.

Problems with Configuring Encrypting File System in a Mixed Environment

Encrypting File System (EFS), first introduced with Windows 2000, protects sensitive data in files stored on NTFS-formatted disks. Only the user who encrypts a file can open that protected file and work with it. This is especially useful for securing sensitive data on computers shared by several users or on portable computers. For example, if someone else obtains a lost or stolen laptop, that person will be unable to access any of the encrypted files stored on that disk.

Windows XP and Windows Server 2003 include many improvements over EFS implementation in Windows 2000. You now have the option of encrypting the Offline Files database, which could not be encrypted under Windows 2000. To encrypt offline files, select the Folder Options command from the Tools menu in My Computer or Windows Explorer, go to the Offline Files tab, and set the Encrypt offline files to secure data checkbox (Fig. 13.11).

click to expand
Figure 13.11: Options for encrypting the Offline Files database

Note 

Administrative privileges are required to configure how offline files will be encrypted.

On the other hand, if EFS is not appropriate in your environment, or if you have files that you do not want encrypted, you can use one of several options to disable EFS. There are also numerous ways to configure EFS to meet the needs of your organization.

Unfortunately, this is where problems might arise, especially in a mixed environment. For example, you may have Windows 2000 and Windows Server 2003 domains with client workstations running Windows 2000 Professional. If you decide to upgrade client workstations to Windows XP Professional and want to disable EFS, you will notice that the public key policy, which disables Encrypting File System, has no effect on Windows XP clients.

Note 

The same problem exists for Windows 2000 Professional clients joined to a Windows NT domain, since the Windows NT domain administrator cannot be a File Recovery Agent. To disable EFS on a computer running Windows 2000 Professional within a Windows NT domain, you must download Microsoft's hotfix (http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q288579). This hotfix adds the registry key, which will be discussed later in this section. Note it is still necessary to change the added registry value to 1 to disable EFS.

The reason for such behavior lies in the difference between the EFS models implemented in Windows 2000 and in its successors (Windows XP and Windows Server 2003). The new EFS model does not require a Data Recovery Agent to be present before files can be encrypted. In Windows 2000, this requirement was mandatory - no recovery agent, no encryption. Because of this limitation, you could prevent file encryption within an entire domain of Windows 2000 clients. You simply had to remove the Data Recovery Agent certificate from the public key policy and delete the recovery policy.

Windows XP Professional and Windows Server 2003 have no such limitation; they allow data encryption regardless of the existence of a Data Recovery Agent.

Thus, if you want to disable EFS in Windows XP or Windows Server 2003, it is necessary to use a different approach. Once again, you have several choices. For example, on standalone systems or within a workgroup environment, you can choose one of the following:

  • Apply the setting in Local Security Policy

  • Edit the system registry directly

For Windows XP clients joined in a Windows Server 2003 domain, the preferred method is to use a Group Policy setting. You also could choose to manage the changes by including the modified registry key in a script. For Windows XP workstations joined to Windows 2000 domains, you can add the modified registry key to a security template, and then import that template into Group Policy.

Using Group Policy to Disable EFS in Windows XP and Windows Server 2003

For a standalone Windows XP or Windows Server 2003 system, you can disable EFS using the following procedure:

  1. From the Start menu, select Programs | Administrative Tools | Local Security Policy.

  2. Expand the console tree and navigate to Local Computer Policy | Computer Configuration | Windows Settings | Security Settings | Public Key Policies.

  3. Right-click the Encrypting File System folder and select the Properties command from the right-click menu.

  4. The Encrypting File System Properties window will open (Fig. 13.12). Notice that in Windows XP or Windows Server 2003, EFS is enabled by default. To disable it, clear the Allow users to encrypt files using the Encrypting File System (EFS) check box. Click OK.

    click to expand
    Figure 13.12: Disabling EFS for a standalone Windows XP or Windows Server 2003 computer through a local security policy setting

  5. Open a command prompt and type gpupdate to refresh the policy.

Note 

Disabling EFS in a Windows Server 2003 domain environment is much like the procedure for a standalone system. The only difference is that in a domain environment you need to modify the EFS property page in Group Policy Object Editor focused on specific GPO and applied to a domain or organizational unit (OU).

Disabling EFS Using the Registry

To use the registry to disable EFS on a standalone computer running Windows 2000, Windows XP, or Windows Server 2003:

  1. Start Registry Editor (if you are dealing with Windows 2000, use Regedt32.exe), and then open the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS subkey.

  2. Under this key, create a new REG_DWORD value and name it EfsConfiguration. To disable EFS, assign it a value of 1. If you need to re-enable EFS, simply change the value to 0.

Using Group Policy to Automate the EFS Disable Process

If you would like to add the ability to push the disabled setting through Group Policy on a Windows XP systems joined to a Windows 2000 domain, you can do so by editing the Sceregvl.inf file. This file resides in the %Windir%\inf folder and represents a list of registry settings that are exposed in the Local Policy | Security Options section of security templates (Fig. 13.13).

click to expand
Figure 13.13: The Local Policy | Security Options section of security templates

By adding registry information to the file, you can expose additional entries. This extends your ability to manage settings through security configuration and analysis or through Group Policy. The file has two sections: one lists registry keys, [Register Registry Values], and one details what will appear in the security template, [Strings].

First, add the registry information to the file. The following line should be placed within the other registry settings in the [Register Registry Values] section:

    MACHINE\Software\Microsoft\Windows    NT\CurrentVersion\EFS\EfsConfiguration,4,%EfsConfiguration%,0 

The syntax for the entries in the [Register Registry Values] section is:

    RegistryPath, RegistryType, DisplayName, DisplayType, Options 

The parameters listed above are briefly explained in Table 13.1.

Table 13.1: Parameters Used in the [Register Registry Values] Section of the Sceregvl.inf File

Parameter

Explanation


RegistryPath

Defines the full path to the registry key and value entry that you want to expose in the Group Policy Editor user interface (UI). Only values that exist under the HKEY_LOCAL_MACHINE root key can be configured. Notice that in the command syntax this root key is referenced by the MACHINE keyword.

RegistryType

Specifies a number that defines the data type of the registry value to be created. The following values are acceptable:

1 - REG_SZ

2 - REG_EXPAND_SZ

3 - REG_BINARY

4 - REG_DWORD

7 - REG_MULTI_SZ

DisplayName

Specifies the string that appears in the Security Options section of the Group Policy Editor UI. This is usually a replaceable parameter that refers to an entry in the [strings] section of the Sceregvl.inf file.

DisplayName

Indicates the type of dialog that should be displayed to allow the user to configure a specific setting. The following values are acceptable:

0 - Boolean: Causes the UI to render two radio buttons, which "enable" or "disable" the registry value. If the Enabled option is selected, the registry value is set to 1. If the Disabled radio button is chosen, the registry value is set to 0.

DisplayName1

1 - Numeric: Causes the UI to render a numeric control that allows the user to type in or select a numeric value in the range of 0 to 99999. Numeric display types can specify "unit" strings, such as "minutes" or "seconds", that appear next to the spin control in the UI. These "unit" strings are defined in the Options field described below. The registry value is set to the number entered by the user.

2 - String: Causes the UI to render a text box. The registry value is set to the string entered by the user.

3 - List: Causes the UI to render a list box from which the user can select an option. The registry value is set to the numeric value associated with the option chosen by the user. The options presented to the user are defined in the Options field described below.

4 - Multivalued (unavailable on Windows 2000): Causes the UI to render an edit control that allows the user to enter multiple lines of text. This display type should be used to define values for MULTI_SZ types. The registry value is set to the strings entered by the user; each line is separated by a NULL byte.

DisplayName

5 - Bitmask (unavailable on Windows 2000): Causes the UI to render a series of checkboxes. Each checkbox corresponds to a numeric value defined in the Options field described below. The registry value is set to the bitwise OR of the selected values.

Options

Qualifies different DisplayTypes as follows:

If DisplayType=1 (Numeric), the options field may contain a string that defines the units for the numeric value. The unit string is displayed next to the spin control in the UI. The unit string has no affect on the value set in the registry.

If DisplayType=3 (List), the options field defines the list options that are available to the user. Each option consists of a numeric value separated by the "pipe" character '|' followed by the text for the choice. The registry value is set to the numeric value associated with the choice made by the user.

If DisplayType=5 (Bitmask), the options field defines the choices that are available to the user. Each choice consists of a numeric value separated by the "pipe" character '|' followed by the text for the choice. The registry value is set to the bitwise OR of the choices selected by the user.


Thus, the command that we have added to the [Register Registry Values] Section (MACHINE\Software\Microsoft\Windows NT\CurrentVersion\EFS\EfsConfiguration,4,%EfsConfiguration%, 0) can be explained as follows:

  • RegistryPath = MACHINE\Software\Microsoft\Window NT\CurrentVersion\EFS\EfsConfiguration - This adds the EfsConfiguration value to the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\EFS registry key.

  • RegistryType = 4 - The added value must be of the REG_DWORD data type.

  • DisplayName = %EfsConfiguration% - This references the string value in the [Strings] section of the Sceregvl.inf file.

  • Display type = 0 - The dialog represented by the Group Policy Editor UI must have two radio buttons: Enabled and Disabled.

Now, it is necessary to add a string for display in the GUI to the [strings] section of the Sceregvl.inf file, for example:

    EfsConfiguration = "Public Key Infrastructure: Users cannot encrypt files" 

After the required modifications have been introduced into the Sceregvl.inf file, save it and run the following command at the command prompt:

    Regsvr32 scecli.dll 

This command is required to register the changes. If the command is accomplished successfully, a pop-up window will appear.

The list of security options available in the security template now should include your option; your options also should be found in Group Policy Objects (GPOs) examined on this machine. To use the security template, set its value to Enabled. Save the template and import it into a Group Policy linked to the organizational unit (OU) in which Windows XP computer accounts reside.

Troubleshooting Windows Installer Issues

In Chapter 11, we considered Windows Installer technology and its relationship to the system registry. As outlined in that chapter, the executable file that comprises the Windows Installer service (and is installed on every Windows 2000, Windows XP, or Windows Server 2003 computer by default) is the Msiexec.exe file. By default, the Installer service runs in the LocalSystem security context and can perform any system changes. Besides this, the Installer service can install MSI packages on behalf of the user logged on to the system. The Installer service can determine if the application installation is broken or corrupt and can attempt to fix it. Finally, the Installer service can roll back an application installation if it fails before completion.

Note 

While an application installation is in progress, Windows Installer creates temporary files (located in the %SystemDrive%\config.msi folder). During a rollback, these files are used to undo steps taken before the failure.

Despite the advantages of Windows Installer, you can encounter problems when installing applications with the technology. In this section, we will briefly consider the most important problems and discuss some troubleshooting techniques.

Using MSIEXEC from the Command Line

As outlined in Chapter 11, Windows Installer is a system service. It also can be invoked interactively by the Msiexec.exe command-line tool, which provides powerful capabilities for managing your *.msi packages.

The syntax used by the Msiexec.exe command-line tool is:

    msiexec.exe /command line option <argument> 

Here, argument must be the path and name of the file. The most common command-line options used with the Msiexec.exe command are:

  • /i <argument>: Install a product

  • /f <MSI file name>: Repair a product (*)

  • /a <MSI file name>: Install a product in "Run from Network" or Administrative mode

  • /x <MSI file name>: Uninstall a product

  • /j <MSI file name>: Assign a product (immediately places a shortcut on the desktop or Start menu)

  • /jm <MSI file name>: Assign a product per machine

  • /ju <MSI file name>: Assign a product per user

  • /j [u | m] <MSI file name> /t <MST Transform file>: Assign a product and apply a transform

  • /l <log file name>: Use in conjunction with one of the above operations to log install (or repair) information to <log file name> (*)

  • /p <Patch Package Name>: Apply a patch to a product

  • /q [n, b, r, f]: Sets the verbosity of the Install interface to

    • /qn = No UI at all

    • /qb = Basic UI

    • /qr = Reduced UI

    • /qf = Full UI

    • /qn+ = No UI except for completion dialog

    • /qb+ = Basic UI with completion dialog

Note 

Actually, the list of command-line options for the Msiexec.exe tool is significantly larger. The options marked here with asterisks (*) have additional suboptions available. A complete list of these options and detailed information about their usage can be found in Microsoft's MSDN Online Library (http://msdn.microsoft.com). Furthermore, Microsoft has published a detailed FAQ on Windows Installer, which can be found at http://www.microsoft.com/windows2000/community/centers/management/msi.faq.asp.

Windows Installer is Unavailable on Windows XP and Windows Server 2003

Although the Windows Installer service is installed by default, sometimes it might not be installed correctly. The symptoms of this problem are as follows:

  • You repeatedly cannot run an installation of an *.msi file successfully.

Note 

If you cannot run a single Windows Installer package successfully (but attempts to install other *.msi packages succeed), contact the vendor of that package for support on that particular product's installation. In addition, note that when you invoke an application install from the command line using msiexec.exe, you don't, by default, get the elevation of privileges that occurs when you've published or assigned an application via Group Policy. Thus, if you are not a member of the Power Users or Administrators built-in local security groups, the install might fail because of insufficient privileges.

  • When you attempt to install a program that uses Windows Installer, you receive an error message similar to the following:

        The Windows Installer service could not be accessed. This can occur if you are running in safe mode or if the Windows Installer is not correctly installed. 

The most probable cause of this problem lies in incorrect or corrupted registration of the Windows Installer engine. To eliminate this problem, you need to unregister and then re-register the Windows Installer service by following these steps:

  1. Click the Start button, select the Run command, and type the cmd command into the Open field to start the command prompt window.

  2. Issue the command msiexec /unregister and press <Enter>. This procedure stops the Windows Installer service and unregisters it.

  3. Issue the command msiexec /regserver and press <Enter>. This command reregisters the service and assures that it is functioning properly.

Note 

If this procedure doesn't resolve the problem, you can remove the Windows Installer engine files and do a clean reinstallation.

Enabling Windows Installer Logging

For Windows NT-based applications and systems - including Windows 2000, Windows XP, and products of the Windows Server 2003 family - event logging provides a standard and centralized method for recording important system events related to hardware, software, security, etc. Windows Installer also writes entries into Event Log, which records events such as:

  • Success or failure of the installation, removal, or repair of a product

  • Errors that occur during product configuration

  • Detection of corrupted configuration data

  • Information about the missing components that cause a repair of an application

Windows Installer 2 0, the latest major release for Windows Installer, provides improved logging options. In previous versions of the service, error codes fell within two or three non unique event IDs. With Windows Installer 2.0, each error receives an ID, which greatly improves how you can search for and filter Windows Installer events. Besides the OS event log, Windows Installer records errors and events in its own internal error log. The type of logging depends on the options used when enabling the logging mode. You can use various means to enable the logging mode, including:

  • Issuing the Msiexec command with the /L option

  • Editing the registry

When enabling Windows Installer logging from the command line using the /L option, you can specify exactly what information is logged and where. To create a log, append /L<suboptions> Logfile_name to your Msiexec command line. For example, appending the /L* Logfile_name command line creates a normal log file with all suboptions except v (verbose). To produce a verbose log file, which provides more comprehensive information, use the following syntax: /L*v Logfile_name.

Note 

If you don't specify a log file name, log files will be stored in your Temp folder under random names starting with the letters Msi.

The list of suboptions available when using the /L command-line switch, is provided below.

  • I - Status messages

  • W - Non-fatal warnings

  • E - All error messages

  • A - Startup of actions

  • R - Action-specific records

  • U - User requests

  • C - Initial UI arguments

  • M - Out-of-memory or fatal-exit information

  • O - Out-of-disk-space messages

  • P - Terminal properties

  • V - Verbose output

  • + - Append to existing file

  • ! - Flush each line to the log

  • * - Log all information except the v option. To include the v option, specify "/l*v"

To enable Windows Installer logging via the registry, start Registry Editor and create a new REG_SZ value entry named Logging under the HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer registry key. Set it to a value that could contain the characters from the list above.

Note 

You should enable Windows Installer verbose logging only for troubleshooting purposes. After having detected and eliminated the problem, do not leave it enabled because it will have adverse effects on system performance and disk space. Each time you use the Add/Remove Programs tool in Control Panel, a new Msi*.log file is created.

Resetting TCP/IP Settings in Windows XP and Windows Server 2003

If you carefully view the list of networking components for a network interface in Windows XP and Windows Server 2003, you'll notice a strange fact - the Uninstall button is disabled when Internet Protocol (TCP/IP) is selected (Fig. 13.14). In Windows 2000 and earlier versions, it was possible to remove the TCP/IP stack. According to Microsoft, this option is no longer offered because the TCP/IP stack is a core component of the operating system; therefore, it is not possible to uninstall it.

click to expand
Figure 13.14: In Windows XP and Windows Server 2003, the Uninstall button is disabled when you select TC/IP protocol in the Local Area Connection Properties window

What if you want to reset the TCP/IP stack by returning it to its state when the operating system originally was installed? In Windows XP and Windows Server 2003, you can't remove and then reinstall it. However, there is a convenient way to work around this problem. To do so, you must use the netsh (NetShell) utility, which provides a command-line interface for configuring and monitoring Windows XP or Windows Server 2003 networking.

In Windows XP, netsh utility provides a reset command, which rewrites registry keys related to TCP/IP. Consequently, you will get the same result as removing the TCP/IP stack and then reinstalling it.

To reset TCP/IP settings in the registry, go to the command line (Start | Run, type cmd, and press <Enter> then issue the following command:

    netsh interface ip reset [log_file_name] 

Instead of log_file_name, use the name of the log file where the action will be recorded. If you don't specify the full path to the log file, it will be created in the current directory.

The command will reset TCP/IP settings stored under the following registry keys:

    HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\    HKLM\SYSTEM\CurrentControlSet\Services\DHCP\Parameters\ 
Note 

If a log file already exists, the new log will be appended to the end of existing file. In addition, the contents of the log file depend on the system configuration. There may be times when no actions will be logged. This usually happens if the TCP/IP registry settings have not been changed since the original Windows XP or Windows Server 2003 installation.

Troubleshooting Service Startup Problems

Sometimes, you may encounter a service that can't start because of a logon failure. If this happens, the system might display error messages. Then, the next time you start the system, the following error messages may be in the system event log:

    Source: Service Control Manager    Event ID: 7000    Description:    The %service% service failed to start due to the following error:    The service did not start due to a logon failure. 

No information in the Data field will be available.

    Source: Service Control Manager    Event ID: 7013    Description:    Logon attempt with current password failed with the following error:    Logon failure: unknown user name or bad password. 

No information in the Data field will be available (Fig. 13.15).

click to expand
Figure 13.15: The Event Properties window displaying the error message on the service startup failure because of logon failure

When you attempt to manually start the service, you will receive an error message informing you that the service could not start because of logon problems. This behavior can occur for any of the following reasons:

  • The account password the service uses to log on has been changed.

  • The password data in the registry has been damaged.

  • The right to log on as a service has been revoked for the specified user account.

To resolve these issues, you can configure the service to use the built-in system account, change the password for the specified user account to match the current password for that user, or restore the user's right to log on as a service.

If the right to log on as a service is revoked for the specified user account, you can restore this right. The procedure is somewhat different for domain controllers and member servers/client workstations. If the problem takes place at the controller of an Active Directory domain, proceed as follows:

  1. Start the Active Director Users and Computers Microsoft Management Console (MMC) snap-in.

  2. Right-click the organizational unit (OU) in which the user right to log on as a service was granted. By default, this is in the Domain Controllers OU.

  3. Right-click the container, then click Properties.

  4. On the Group Policy tab, click Default Domain Controllers Policy, then click Edit. This starts Group Policy Object Editor.

  5. Expand the Computer Configuration object by clicking the plus sign (+) next to the policy object. Under the Computer Configuration object, expand Windows Settings, then expand Security Settings.

  6. Expand Local Policies and click User Rights Assignment (Fig. 13.16).

    click to expand
    Figure 13.16: Restoring the right for the user account to log on as service

  7. In the right pane, right-click Log on as a service (Fig. 13.17).

    click to expand
    Figure 13.17: The Log on as service Properties dialog

  8. Add the user to the policy and click OK.

  9. Quit Group Policy Object Editor, close Group Policy Properties, then close the Active Directory Users and Computers MMC snap-in.

If the problem arises at the member server or a standalone computer, take the following steps:

  1. Start the Local Security Settings MMC snap-in.

  2. Expand Local Policies and click User Rights Assignment.

  3. In the right pane, right-click Log on as a service, then click Properties. The Log on as service Properties window will open.

  4. Add the user to the policy and click OK.

Configuring Service Logon Information

To configure the password for the specified user account to match the current password for that user:

  1. Start the Administrative Tools applet in Control Panel, then double-click the Services icon.

  2. Right-click the appropriate service, then click Properties.

  3. The service properties window will open. Go to the Log On tab (Fig. 13.18), change the password, and click Apply.

    click to expand
    Figure 13.18: The Log On tab of the service properties window

  4. Go to the General tab (Fig. 13.19), and click the Start button to restart the service.

    click to expand
    Figure 13.19: The General tab of the service properties window

If the service starts, you have successfully eliminated the problem. In some situations, the service may not start with the specified user account. In such a case, you may reconfigure the service to start up with the built-in system account.

Configuring the Service to Start Up with the Built-in System Account

To configure the service to start up with the built-in system account:

  1. Start the Administrative Tools applet in Control Panel, then double-click the Services icon.

  2. Right-click the appropriate service, then select the Properties command from the right-click menu.

  3. Go to the Log On tab (Fig. 13.20), set the Local System Account radio button, and click Apply. If the service needs to interact with the desktop, set the Allow service to interact with desktop checkbox. (Task Scheduler is an example of a built-in system service that requires interaction with the desktop.) Some third-party services, such as the F-Secure Authentication agent, also need to interact with the desktop. However, as most services don't need this feature, typically you may leave this checkbox unselected.

    click to expand
    Figure 13.20: Configuring the service to start up with the Local System account

  4. Go to the General tab and click the Start button to restart the service.

Using Registry Editor to Troubleshoot Service Startup Problems

If you are able to start the Services tool, you can use the procedures described above to troubleshoot service startup problems. Sometimes, however, there may be situations when you are unable to use the Services administrative tool. For example, the computer may hang when you start this tool, and the following message may be displayed:

    The RPC Server is unavailable 

It is logical to suppose that the Services tool would not start because of a logon failure with the Remote Procedure Call (RPC) or a dependent service. Some services do not start until their dependent services have connected. For example, the Alerter service depends on the Workstation service (Fig. 13.21). To view the dependencies for a specific service, right-click the required service, select the Properties command from the context menu, and go to the Dependencies tab. As you can see, the dependencies list for the RPC service is quite long (Fig. 13.22).

click to expand
Figure 13.21: The Alerter service depends on the Workstation service

click to expand
Figure 13.22: The dependencies list for RPC service is quite long

If a logon failure with the RPC service prevents you from starting the Services tool and using the safe method of configuring services, proceed as follows:

  1. Start Registry Editor and locate the ObjectName value under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ServiceName registry key.

  2. Modify that value entry by setting its value to localsystem (Fig. 13.23), click OK, and quit Registry Editor.

    click to expand
    Figure 13.23: The ObjectName value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ServiceName

  3. Attempt to restart the service. You may need to restart the computer for some services to restart properly.

If you cannot start Registry Editor, you can modify the service account information by performing a parallel installation of the operating system.

Disabling a Service or Driver that Prevents Windows from Booting

If you have managed to detect the service or device driver that prevents your system from booting, and if you have installed a parallel copy of the operating system that is bootable, you can try to eliminate the problem using the following procedures:

  1. Boot into a parallel copy of the system and start Regedit.exe (Windows XP or Windows Server 2003) or Regedt32.exe (Windows NT or Windows 2000).

  2. Go to the HKEY_LOCAL_MACHINE root key.

  3. Use the Load Hive command to open the following registry file in the original Windows installation:

    %SystemRoot%\System32\Config\System

    When prompted to assign a name for the hive, assign it a name other than System (for example, System1).

  4. Go to the HKEY_LOCAL_MACHINE\SYSTEM1\Select registry key and note the value for Current:REG_DWORD. (This selects which ControlSet00x to load when booting and is the one that needs modification.)

  5. Perform the following steps to disable a service:

    • Go to the following registry key:

      HKEY_LOCAL_MACHINE\TEST\ControlSet00x\Services \<Name of suspected service>, where x is the value of Current: REG_DWORD

    • Change the value of start:REG_DWORD to 0x4.

    Note 

    As outlined in Chapter 6, valid startup options for the service include 0x2 (Automatic), 0x3 (Manual), and 0x4 (Disabled). Thus, by setting the Start value to 0x4, you disable the service.

    To disable a device driver, proceed as follows:

    • Go to the HKEY_LOCAL_MACHINE\SYSTEM1\ControlSet00x\Services\<Name of suspect driver> where x is the value of Current:REG_DWORD.

    • Change the value of Start: REG_DWORD to 0x4.

    Note 

    As shown in Chapter 6, valid startup options for device drivers include 0x0 (Boot), 0xl (System), 0x2 (Automatic), 0x3 (Manual), and 0x4 (Disabled).

  6. After you have introduced all required modifications, unload the System 1 hive, quit Registry Editor, and try to reboot the original versions of Windows NT/2000/XP or Windows Server 2003.



Windows Server 2003 Registry
Unicode Explained
ISBN: 1931769214
EAN: 2147483647
Year: 2005
Pages: 129

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net