Basic Troubleshooting of Windows 2008 Server

Boot Menu Options

Repair your Computer
Along with the options that are usually presented when you press F8 key, - the new option that has been introduced is Repair your Computer, provided if you have installed Windows RE locally to the server.

Safe Mode
This option starts the server with fewer drivers and services that are running on the server. This option is usually used when you are facing some issues with device drivers. As the server boots the drivers are also loaded on the screen. The list of drivers that are loaded during this process is CD, and hard disk. Services are event log, plug and play, RPC, WMI, and cryptographic.

Safe Mode with Networking

It's like safe mode but it has the drivers for networking support. It also loads network drivers along with networking services.

Safe Mode With Command Prompt

This is command line interface if you want to run some commands with cmd.

(5)Enable Boot Logging

It is used for debugging, it will show which drivers load and failed. It is written in ntbtlog.txt file which is in windows folder.

Enable Low Resolution Video

Useful to keep the resolution 640*480 mode. Useful to troubleshoot graphical resolutions that are set higher.

Last Known Good Configuration

If you made any changes to the server and then that server is not logging you into Windows, try this option. This is useful if you have installed any drivers and after reboot you are unable to login.

Directory Services Restore Mode

This is used only in Active Directory servers. Used to restore AD using methods (Authoritative and Nonauthoritative.)

Debugging Mode
This mode is widely used by developers.

Disable Automatic Restart on System Failure

As the name suggests, for any errors observed the server will reboot and you can control that with this option.

Disable Driver Signature Enforcement

With this option you can allow non signed drivers to load in server system; however the recommendation would be to use the signature drivers wherever possible.

(12)Starts Windows Normally

If by mistake, you press F8 and want to start Windows in normal mode than please press this option.

What is Windows Recovery Environment?

Actually RE is the part of Windows 2008 Media, to use this feature boot from CD. You need to install and repair your computer. It checks for integrity of hardware, drivers, etc.

Tools Section
Reliability Monitor
It has been introduced in Windows 2008 Server; it indicates system performance based on hardware, windows and other failures.

Event Viewer
Event viewers can give to lots of information. There are three critical logs that are available in 2008 server: Application Logs - Where application related information is written Security Logs - Where security information is noted down System log - Where system components write the vent for E.g. hardware

MSconfig
This utility provides system configuration information, you can use which mode (e.g.-diag.) Mode needs to be used for troubleshooting.

Troubleshooting Windows Server 2008 R2 Failover Clusters

Top things to look for
Jul. 19, 2012John Marlin | Windows IT Pro

EMAIL INSHARE

COMMENTS 0

I want to discuss some of the troubleshooting techniques that we use with Windows Server 2008 R2 failover clusters. There are many ways to troubleshoot clusters, and some engineers might do things that others might not. So I wanted to pass along some of the most common things to look for and where to look to look for them. With that in mind, lets first talk about the files that youll generally be looking at and their descriptions. Related: 4 Failover Clustering Hassles and How to Avoid Them

One of the first things youll be working with is Failover Cluster Manager, the new interface for managing a cluster. With this tool, youll be managing groups and resources as well as performing some troubleshooting, which Ill explain as I go along. Failover Cluster Manager can be accessed from the Start menu and Administrative Tools.

Event Channels
Youre probably familiar with the System event log. Its where we log critical, error, and warning events. However, its not the only event log location that we write to. Starting in Server 2008, there are additional event channels. Figure 1 shows where to find the channels relevant to failover clustering. Here is where well log all the informational-type events and debug/diagnostic events. Youll find the following list of logs and their channels:

Figure 1: Channels relevant to failover clustering

 o o o o o o o o

FailoverClustering Diagnostic (if Show Analytic and Debug Logs is selected) Operational Performance-CSV (if Show Analytic and Debug Logs is selected) FailoverClustering-Client Diagnostic (if Show Analytic and Debug Logs is selected) FailoverClustering-Manager Admin Diagnostic (if Show Analytic and Debug Logs is selected) FailoverClustering-WMIProvider Admin Diagnostic (if Show Analytic and Debug Logs is selected)

If youre starting/stopping the cluster service, or youre moving groups, or groups are coming online and offline, and so on, those events will be logged in the FailoverClustering\Operational log. For example:

Event ID: 1061 Description: The Cluster Service successfully formed the failover Cluster JohnsCluster

Any failures connecting to other nodes opening Failover Cluster Manager are logged in FailoverClustering-Manager\Admin. For example:

Event ID: 4684 Description: Failover Cluster Manager could not contact the DNS Servers to resolve name W2K8-R2-NODE2.contoso.com. For more information see the Failover Cluster Manager Diagnostics channel.

If you look at the FailoverClustering-Manager\Diagnostic log, you would see this:

Event ID: 4609 Description: An error was encountered while attempting to ping W2K8-R2NODE2.contoso.com. System.ApplicationException: Could not contact one or more DNS Servers. Please verify that DNS configuration is correct and the machine is fully connected to the network.

Event ID: 4612 Description: Server W2K8-R2-NODE2.contoso.com ping failed.

Just from these events, you can see that there is a problem with the node getting to the DNS server and can start troubleshooting this specific problem. What you might see without looking at these logs is possibly the W2K8-R2-NODE2 showing as down in Failover Cluster Manager. (One of the other logs mentioned above is the FailoverClustering\Diagnostic log. Ill discuss this log a bit later.) Related: New Features of Windows Server 2012 Failover Clustering

Failover Cluster Manager

To make things a bit easier, you can also view system event errors and warnings from within Failover Cluster Manager. On the main page in the middle pane, there is a Recent Cluster Events link that you can select, as Figure 2 shows. This link provides a handy way to display all warnings and errors that have occurred with Failover Cluster as the source in the past 24 hours. It pulls these events from all nodes and gives you everything in one spot. So theres no need to go to multiple machines and have multiple event logs open that you must switch between.

Figure 2: Recent Cluster Events

You can use the Query option to look for specific events. On the main page in the left pane, youll see Cluster Events. You can right click Cluster Events and choose Query, or you can select Query from the Actions pane on the right. Figure 3 shows the Cluster Events Filter.

Figure 3: The Cluster Events Filter

This is also a good way to display everything in the same location. For example, suppose youre experiencing the failure of a disk resource. You can bring up Failover Cluster manager and have it query all nodes, the System event log, the error, and the specific date. On the main page, you can see when the disk failed, on what node(s) it failed, and any other pertinent data (such as disk events where a path failed). You also have the ability to save these queries for later use. You have two more options for looking up events. You can look up all resource-failure events for anything in a group, or you can be resource-specific. In the Actions menu, which Figure 4 shows, you can select Show the critical events for this application (any resource in the group) or Show the critical events for this resource (only the specific resource). Doing so will bring up the query for any of the events in the current event logs on all nodes. This option can also beneficial for determining history and whether the event can be narrowed down to a specific time period or node.

Figure 4: The Failover Cluster Managers Actions menu

For those who remember the Windows 2003 Server Cluster days, this is the Cluster.Log equivalent. Starting in Server 2008 failover clustering, the functionality is more in line with the Windows Event Tracing (ETW) process. Instead of writing to a Cluster.Log text file, it writes it to a Diagnostics log located in the C:\Windows\System32\winevt\logs folder. There are three diagnostics logs that we write to (clusterlog.etl.001, clusterlog.etl.002, and clusterlog.etl.003). Were only going to write to one of these at a time on any given boot. For

more information about these log files and how theyre used, check out the Understanding the Cluster Debug Log in 2008 blog post. This log is enabled and always writing. If you right-click FailoverClustering\Diagnostic and select Disable log, you can see all the events it has written. If you disable this log, the system will no longer write to it and information wont be saved. If you do this, its best to save the event out as an event log or text file and enable it again. There are essentially three main events youll see:

Event 2049 is an informational event. Event 2050 is a warning. Event 2051 is an error.

These events will only be from the current diagnostic .ETL being written to. Youll see the event information just as you would the System or Application event log. However, each event will be only one line at a time. So, going event by event through this diagnostic event log can be pretty tedious. You can create a Cluster.Log text file with commands that combine all three of these logs into one to make the review of it much easier. The PowerShell Get-ClusterLog command goes out to all nodes and generates a Cluster.Log on each node and places it in the C:\Windows\Cluster\Reports folder. This would be the Cluster.Log you might be more familiar with from Windows 2003. There are Get-ClusterLog switches you might want to consider, depending on the circumstances. For example, say you can reproduce a failure at will and need to find the reason for the failure. Simply reproduce the problem and use the command
Get-ClusterLog -TimeSpan 5

to get data from the past 5 minutes. Because you need only the log from the one node you reproduce the problem on, you could add the Node Nodename switch to create the Cluster.Log on this single node. If you have a number of nodes and need to send these logs, it might take some time to connect to each node to get the file. In these circumstances, you could use the -Destination switch. This switch creates a Cluster.Log for each node, copies it to a folder you specify, and tags the name of the machine as part of the file name (e.g., W2K8-R2-Node1_Cluster.Log). Remember that the Cluster.Log youre creating is a snapshot in time. It will take whats there right now and wont update with anything after its generated. When its generated, if

theres a Cluster.Log in the Reports folder, it will get deleted to make room for the new one.

Resource Host System

The next thing I wanted to discuss is the Resource Host System (RHS). One of its responsibilities is to monitor the health of all resources in the cluster. It does this through a series of checks (basic and thorough). If a resource doesnt respond to these checks, RHS will issue the following system event:

Event ID: 1230 Description: Cluster resource 'Cluster Disk 1' (resource type '', DLL 'clusres.dll') either crashed or deadlocked.

In this instance, the disk didnt respond that the health check that was made. What the cluster will do is fail the resource and restart it to get you back to production. If these checks werent in place, it could lead to a hung machine or no connectivity from a client application. When troubleshooting the RHS event, you must consider the resource. If a disk deadlocks, you would need to consider everything in the disk stack. Was there slow disk I/O? Did you lose a path to the drive? This would be the focus of your troubleshooting. So, next up is reviewing the System event log for disk-related events, looking at Performance Monitor, updating drivers, and so on. If the resource was an IP address or a network name, your focus would be the network stack and everything there.

Cluster Validate
The last thing I want to mention is the Cluster Validate Report. For a cluster to be certified, all components must be listed on the Windows Server Catalog, and it must pass a full Cluster Validate. Many people will run Cluster Validate before the cluster is created or just after. However, if there is a problem later on, few people remember to run Cluster Validate. You can use it as a troubleshooting tool! If youre having some disk problems, run the Storage Tests. If youre having network-communication problems, run the Network Tests. You can also use Cluster Validate to get information about groups, resources, and settings for your currently running Failover Cluster to be referenced at a later time.

The nice thing about Cluster Validate is that you can run it even while in production. When you run it and select the Storage Test, it will ask if you want to take the running groups offline, as you see in Figure 5. The default setting is to leave the online groups alone, so production wont be affected. For the Storage Tests, it will test disks that are:

In groups that are offline In the available storage group Not a part of the cluster

Figure 5: Running Cluster Validate

Each time you run Cluster Validate, it will create a file in the C:\Windows\Cluster\Reports directory and will tag the date and time as part of the file name. So, every time you run it, it will create a new one and will create the file on all nodes that Cluster Validate was run against. There are other ways to troubleshoot failover clustersI just dont have enough space to cover them all. However, this column should get you started for most of the problems you may face. For more information, check out the Ask the Core Team blog and theClustering and High Availability blog. Happy clustering!

Five Quick Links: Windows Server troubleshooting

Reprints

From service failures to blue screens of death, bringing a Windows Server back to life is a feat for any admin trying to maintain peace within the OS -- and while experience helps streamline the process, a little guidance doesnt hurt either. Here are five quick links that will help you return your Windows Server to good health in no time, including helpful tips and the best tools for server outages. For more tips and tricks, check out our troubleshooting topic page.

1. Tackling the top Windows server crashes Dated antivirus software, unsuitable storage drivers and excessive filter drivers are some of the most common causes of Windows Server crashes. Expert Bruce Mackenzie-Low breaks down each pitfall and how to avoid them. 2. How to reconcile a hung Windows server There are several steps that go into troubleshooting Windows Server hangs -- but before admins can figure out the cause of a hung server, they have to lay the groundwork. 3. Windows tools mend application crashes and hangs Misbehaving Windows apps can cause headaches for admins trying to keep the OS running smoothly, so Microsoft has developed a tool belt of free utilities to help diagnose and repair Windows outages. 4. Debugging Windows print spooler crashes While troubleshooting the cause of a Windows print spooler crash isnt always obvious, a utility called ADPlus may be the key to pinpointing the culprit. 5. The best utilities for plugging Windows memory leaks Putting a cork in Windows memory leaks involves 24/7 monitoring, but tools like Perfmon and the Windows Kernel Debugger are just a few of the tools that can help get the job done.

Troubleshooting Failed Requests Using Tracing in IIS 7

By IIS Team December 12, 2007

Introduction
Request-based tracing is available both in stand-alone IIS Servers and on Windows Azure Web Sites (WAWS) and provides a way to determine what exactly is happening with your requests and why, provided that you can reproduce the problem that you are experiencing. Problems like poor performance on some requests, or authentication-related failures on other requests, or the server 500 error from ASP or ASP.NET can often be difficult to troubleshoot--unless you have captured the trace of the problem when it occurs. the following article discusses failed request tracing on IIS Server. For information about doing this with Windows Azure Web Sites click here Failed-request tracing is designed to buffer the trace events for a request and only flush them to disk if the request "fails," where you provide the definition of "failure". If you want to know why you're getting 404.2 error messages or request start hanging, use failed-request tracing. The tasks that are illustrated in this article include:

Enabling the failed-request tracing module Configuring failed-request tracing log-file semantics Defining the URL for which to keep failed request traces, including failure definitions and areas to trace Generating the failure condition and viewing the resulting trace

Prerequisites

INSTALL IIS You must install IIS 7 or above before you can perform the tasks in this article. Browse to http://localhost/ to see if IIS is installed. If IIS is not installed, see Installing IIS on Windows Server 2008 for installation instructions. When installing IIS, make sure that you also install the following:

ASP.NET (under World Wide Web Services - Application Development Features - ASP.NET) Tracing (under World Wide Web Services - Health and Diagnostics - Tracing)

LOG IN AS ADMINISTRATOR Ensure that the account that you use to log in is the administrator account or is in the Administrators group. Note: Being in the Administrators group does not grant you complete administrator user rights by default. You must run applications as Administrator, which you can do by right-clicking on the application icon and selecting Run as administrator.

MAKE A BACKUP You must make a backup of the configuration before doing the following tasks. To make a backup of the configuration: 1. Click Start -> All Programs -> Accessories. 2. Right-click Command Prompt, and then click Run as administrator.

3. In a command prompt, run the following command:

%windir%\system32\inetsrv\appcmd add backup cleanInstall

CREATE SAMPLE CONTENT 1. Navigate to %systemdrive%\inetpub\wwwroot. 2. Move the content to a secure location (in case you want to restore the existing content) or delete it. 3. Create a blank file and name it test.asp.

4. In the command prompt, navigate to the test.asp file in \inetpub\wwwroot. 5. In the test.asp file, paste the following content: <h2>Failed Request Tracing Lab</h2><br> <br>Today's date is <% response.write(Date()) %>

DISABLE ASP ASP must be disabled for this task. ASP is disabled only as an example and for the purposes of the tasks in this article. To disable ASP: 1. Open IIS Manager. 2. Double-click ISAPI and CGI Restrictions.

3. Select Active Server Pages. In the Actions pane, click Deny to disable ASP.

Enable Failed-Request Tracing

After you enable failed-request tracing, you need to configure where the log files will reside. In this task, you will enable failed-request tracing for the Default Web Site and specify where to put the log files. You will then configure the failure for which to generate failure logs.

STEP 1 : ENABLE FAILED-REQUEST TRACING FOR THE SITE AND CONFIGURE THE LOG FILE DIRECTORY 1. 2. 3. 4. Open a command prompt with administrator user rights. Launch inetmgr. In the Connections pane, expand the machine name, expand Sites, and then click Default Web Site. In the Actions pane, under Configure, click Failed Request Tracing.

5. In the Edit Web Site Failed Request Tracing Settings dialog box, configure the following:

Select the Enable check box. Keep the defaults for the other settings.

6. Click OK. Failed-request tracing logging is now enabled for the Default Web Site. Check the %windir%\system32\inetsrv\config\applicationHost.config file to confirm that the configuration looks as follows: <system.applicationHost> <sites> <!-- site & app defaults --> <site name="Default Web Site" id="1"> <!-- other site configuration --> <traceFailedRequestsLogging enabled="true" /> </site> </sites> </system.applicationHost>

STEP 2 : CONFIGURE YOUR FAILURE DEFINITIONS In this step, you will configure the failure definitions for your URL, including what areas to trace. You will troubleshoot a 404.2 that is returned by IIS for any requests to extensions that have not yet been enabled. This will help you determine which particular extensions you will need to enable.

1. Open a command prompt with administrator user rights. 2. Launch inetmgr. 3. In the Connections pane, expand the machine name, expand Sites, and then click Default Web Site. 4. Double-click Failed Request Tracing Rules.

5. Click Finish. 6. In the Actions pane, click Add.... 7. In the Add Failed Request Tracing Rule wizard, on the Specify Content to Trace page, select All content (*). Click Next.

8. On the Define Trace Conditions page, select the Status code(s) check box and enter 404.2 as the status code to trace.

9. Click Next. 10. On the Select Trace Providers page, under Providers, select the WWW Server check box. Under Areas, select the Securitycheck box and clear all other check boxes. The problem that you are generating causes a security error trace event to be thrown. In general, authentication and authorization (including ISAPI restriction list issues) problems can be diagnosed by using the WWW Server Security area configuration for tracing. However, because the FREB.xsl style sheet helps highlight errors and warnings, you can still use the default configuration to log all events in all areas and providers. Under Verbosity, select Verbose.

11. Click Finish. You should see the following definition for the Default Web Site:

IIS Manager writes the configuration to the %windir%\system32\inetsrv\config\applicationHost.config file by using a <location> tag. The configuration should look as follows: <location path="Default Web Site"> <system.webServer> <tracing> <traceFailedRequests> <add path="*"> <traceAreas> <add provider="WWW Server" areas="Security" verbosity="Verbose" />

</traceAreas> <failureDefinitions statusCodes="404.2" /> </add> </traceFailedRequests> </tracing> </system.webServer> </location>

Test and View the Failure Request Log File

In this task, you will generate a failed request and view the resulting trace log. You already configured IIS to capture trace logs forhttp://localhost/*.asp requests that fail with an HTTP response code of 404.2. Now verify that it works.

STEP 1 : GENERATE AN ERROR AND THE FAILURE REQUEST LOG FILE 1. Open a new Internet Explorer window. 2. Type in the following address: http://localhost/test.asp. 3. You should see the following:

STEP 2 : VIEW THE FAILURE REQUEST LOG FILE

1. Now that you have generated a failed request, open a command prompt with administrator user rights and navigate to %systemdrive%\inetpub\logs\FailedReqLogFiles\W3SVC1. 2. Run start to start an Internet Explorer window from the directory.

3. Notice a few things here: When IIS writes the failed request log file, it writes one file per failed request. A freb.xsl style sheet is also written, one per directory. This helps when you view the resulting failure request log files (such as fr000001.xml above). 4. Right-click the log file for the 404.2 error, and click Open With -> Internet Explorer. If this is the first time that you are opening a Failed Request Tracing file, you must add about:internet to the list of trusted sites, since Internet Explorer's Enhanced Security Configuration is enabled by default. If this is the case, you will see the following:

5. In the Internet Explorer dialog box, click Add to add about:internet to the list of trusted sites. This allows the XSL to work. You will see the following after adding about:internet to the list of trusted sites:

A summary of the failed request is logged at the top, with the Errors & Warnings table identifying any events that are WARNING, ERROR, or CRITICAL ERROR in severity. In this example, the WARNING severity level is due to ISAPI RESTRICTION. The image that you tried to load was %windir%\system32\inetsrv\asp.dll. 6. Open the raw XML file directly by using a text editor, and look at the contents of each event.

Summary
You have completed two tasks: configured failed request tracing to capture traces for * if IIS returns it with a 404.2 status code; and verified that IIS captured the trace for your request. You also verified that the freb*.xml log file did not contain any other requests for the requests that you made because the requests did not have a 404.2 return code. When you consult the failure log file, you determined that the cause of the failure was that the extension was disabled for that request. You can try other non-HTML pages (like gifs or jpgs) and note that the log file does NOT add these traces. You can also easily change this to be 404, or capture the failure if the request takes longer than 30 seconds by setting the timeTaken field in your failureDefinitions.

Restore Your Backup

Now that you have completed the tasks in this article, you can restore the backup of the configuration. Run the following command with administrator user rights:

%windir%\system32\inetsrv\appcmd restore backup cleanInstall