Raise a call with MICROSOFT .

1. Call 800-936-3100, and provide your Access ID to the customer service representative who will create your support incident and route you to the appropriate support engineer to work on the issue immediately. The support line is open 24x7x365.

2. Logon to https://premier.microsoft.com and click on “Submit Incident” on the left pane

Contact HP for hardware issues

Procedure to raise a case with HP for hardware issues :

1. Call HP @ 1800-633-3600
2. Option 1
3. Option 2
4. Say Shortcut – Proliant running microsoft
(If the server hardware is proliant with microsoft OS)
5. Else follow the IVR and select the appropriate Hardware and OS.
6. Note the Case ID and followup for hardware replacement.

How to check if a Windows server is running Microsoft Cluster Server.

1. Login to the server.
2. Open the services Console (Start>Run>Services.msc)
3. Check for the existence of the service “Cluster Service”
4. If this service exists, the serevr is running a Microsoft Cluster Server.
5. Follow these steps to check the status of Cluster Node and Cluster Group.
o Open Command prompt and type “CLUSTER NODE /status” -> This command will list the status of the nodes in the cluster
o Open Command prompt and type “CLUSTER GROUP /status” -> This command will list the status of the cluster groups in the cluster

Event logs not generated on the server.

Try to reboot the server if that does not work follow the below mentioned steps
1. Right-click on %SystemRoot%\System32\winevt\logs and select Properties.
2. Select the Security tab.
3. Click Edit button and click the Add button in the permissions dialog box.
4. In Select users, computers, or Groups dialog box ensure that under object types Built in Security Principals and the location as local computer name is selected.
5. Enter the object name as “NT SERVICE\EventLog” without quotes. And click OK. This group should have full control on the folder.
6. Once EventLog group is added add the rest of the groups with above mentioned permissions.

How to delete Files/Folders which are being blocked by the system.

You will get the following error messages when you try to delete a file/folder which is being blocked by the System or Application Processes running in the Task manager:

Access Is Denied
Sharing Violation Error
File/Folder is being used by applications. Please close the application and then try again.
Solution:

You need to kill the handle. To kill the handle, use Process Explorer from Sysinternals (at URL: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx)

How to delete the handle:

Run Process Explorer
Go to Find menu > Enter File/Folder name and then click on Search. You will see a list of processes blocking the file/folder.
Right click on the process and then click on Close Handle > Click Ok for confirmation.
Now you can successfully delete the file.

Remove terminal services license keys from client machine.

Terminal Services server issues temporary licenses to all the client machines connecting to terminal services. It is required for the terminal services to process the request in timely fashion and will generate the hardware ID to keep the licensing information for client machine. This hardware ID is stored on client machine. This hardware ID is used to check the expiry of license. If license is expired terminal services server can not re-issue license to same computer account. Generally all the temporary license are valid till 90 days.

There are two ways to get rid of this when a client machine needs to have access to Terminal Services session but its license has expired:

Change the computer name.
Remove the License key from client computer.
The second method is very useful. It just requires a registry setting to be removed from client computer. The following registry settings must be removed from client computer:

HKLM\Software\Microsoft\MSLicensing
HardwareID
Store
LICENSxxxx

After deleting above sub-keys try connecting to your Terminal Services server you should be able to get in.

Problem with the extensible counter or the service

The timeout waiting for the performance data collection function “TermService” in the “C:\\WINDOWS\\system32\\perfts.dll” Library to finish has expired. There may be a problem with this extensible counter or the service it is collecting data from or the system may have been very busy when this call was attempted.

Restart the service Termservice. It will work fine.

Troubleshooting Nonpaged and Paged Pool Errors in Windows

I recently had an issue where, after a software change on our servers, we started to notice that some systems had become unstable and were regularly crashing. The crashes sometimes resulted in a blue-screen, but other times resulted in a machine which responded to ping, but little else, and had a completely unresponsive console. The only course of action was to power-cycle the crashed server; clearly, not a good thing to do when we’re dealing with production servers.

Upon investigation, we found that immediately before the crash the servers would log event 2019 in the System log – “The server was unable to allocate from the system nonpaged pool because the pool was empty”.

NonPaged and Paged Pool Errors
Figure 1 – Event 2019

Thankfully, the error message in the event log gave us a clear indication as to why the systems were in trouble, and allowed us to troubleshoot and diagnose the problem.

About nonpaged pool

The nonpaged pool is memory which always resides in physical memory – it is never paged out. It is used by the kernel and also by device drivers installed on a system to store data which might be accessed in situations when page faults are not allowed. The amount of memory allocated to the nonpaged pool varies, and is determined as a function of operating system, processor architecture, and physical memory size. For example, 32-bit operating systems, with their smaller address spaces, have lower limits:

32-bit Windows Server 2003 with 2GB or more of RAM will have a nonpaged pool limit of 256MB
32-bit Windows Server 2008 will have a nonpaged pool limit of either 2GB or slightly more than 75% of physical memory, whichever is smaller
64-bit operating systems, which have a much larger address space, have higher limits:

64-bit Windows Server 2003 will have a nonpaged pool of either 128GB or 40% of physical memory, whichever is smaller
64-bit Windows Server 2008 (or 2008 R2) will have a nonpaged pool limit of either 128GB or slightly more than 75% of physical memory, whichever is smaller
Pool size data is from Mark Russinovich and David Solomon’s book “Windows Internals, 5th Edition”, and Mark Russinovich’s blog posting “Push the Limit’s of Windows: Paged and Nonpaged Pool”.

One way to see the nonpaged pool limit on a specific system is to install the Debugging Tools for Windows, and then use Sysinternals’ Process Explorer to display the pool size. (The debugging tools are required to provide access to debugging symbols.)

Once the tools are downloaded and installed, launch Process Explorer and click Options -> Symbol Configuration, point it to the dbghelp.dll file installed with the Debugging Tools, and configure Microsoft’s symbol server as the symbol file path.

NonPaged and Paged Pool Errors
Figure 2 – Process Explorer Symbol Configuration

The nonpaged pool size can then be found on the System Information dialog (click View -> System Information or press Ctrl+I):

NonPaged and Paged Pool Errors
Figure 3 – Nonpaged pool allocation and limit on 32-bit Windows Server 2003 with 1GB RAM

Back to the problem

We were monitoring memory usage on one of the constantly crashing systems, including the performance counter for nonpaged pool allocation – Memory\Pool nonpaged bytes. The orange line in Figure 4 is nonpaged pool usage, and the plot shows usage growing steadily over time, and then reducing sharply whenever the system is rebooted.

NonPaged and Paged Pool Errors
Figure 4 – Memory use over time

We quickly realised that what we were seeing was most likely a memory leak in a driver or kernel component. Armed with this knowledge and data, the next step was clearly to find out exactly which driver or component is consuming the pool.

The tool for this job is the Memory Pool Monitor, poolmon.exe, which is included in the Windows Support Tools on the Windows Server 2003 CD, or alternatively can be downloaded from the Microsoft Download Centre as part of the Windows Server 2003 Support Tools package. Poolmon displays the amount of pool storage (both paged and nonpaged) in use, all of which is categorized by a pool tag, which is usually a four-character string used when calling the kernel APIs for allocating pool storage.

After launching poolmon, press the ‘p’ key to filter for paged or nonpaged pool, the ‘b’ key to sort the output by bytes, or the ‘d’ key to sort by the difference between pool allocations and pool frees. With the output set to nonpaged and sorted by bytes, the display could look similar to this:

NonPaged and Paged Pool Errors
Figure 5 – Poolmon.exe

The top line of the output is showing that the tag “SbAp” has made 2,187,628 allocations of 56 bytes and no frees, resulting in 122,507,168 bytes of nonpaged pool use – by far the biggest consumer on the system, and responsible for over 60% of the pool use. This looks like the likely cause of the memory leak.

Now that we know the tag we’re looking for, we need to find out which device driver is using it, and there are a couple of ways to do this. If the tag is used by a kernel component or driver, and the Debugging Tools for Windows are installed, then the tag will be listed in the triage\pooltag.txt file located in the debugging tools folder. If the tag isn’t listed in pooltag.txt, then we need to find it using the Sysinternals’ Strings utility, strings.exe, to hunt it down. Since the tag is stored inside the driver file, and most driver files are in %SystemRoot%\System32\drivers, we can easily use strings.exe to quickly search all the files for the tag. So, the search for the “SbAp” tag returned one driver file: klif.sys.

NonPaged and Paged Pool Errors
Figure 6 – Using strings.exe to find the driver

Once we had identified the device driver, we could identify the manufacturer and get help from their technical support department. Thankfully, In this case we were able to contact the software vendor and get the problem solved very quickly, preventing any further crashes and loss of productivity.

It’s worth bearing in mind that the same technique can also be used to troubleshoot paged pool problems as well, which will present as event ID 2020, with the text “The server was unable to allocate from the system paged pool because the pool was empty”. The only difference is to use poolmon to display the paged pool instead of nonpaged pool.

The basic process in both cases is:

Use the event log message to find out if you’re facing a paged or nonpaged pool problem
Use poolmon.exe to find the offending tag
Use pooltag.txt or strings.exe to identify the component or driver
Enlist the vendor to fix the memory leak
Whether you have a paged or nonpaged pool problem, once you have the right tools and know what to look for, these problems are really not especially difficult to troubleshoot.

SCCM OSD Basic troubleshooting

The root of all Task Sequence troubleshooting is called smsts.log — and this log is always the first step to troubleshooting any TS issue — if you have an issue, look in here first!

Unfortunately, the smsts.log can be stored in one of 7 locations, depending on the stage of the build and the architecture of the OS:

•WindowsPE, before HDD format:
x:\windows\temp\smstslog\smsts.log

•WindowsPE, after HDD format:
x:\smstslog\smsts.log and copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log

•Full version windows, before SCCM agent installed:
c:\_SMSTaskSequence\Logs\Smstslog\smsts.log

•Full version windows, after SCCM agent installed:
c:\windows\system32\ccm\logs\Smstslog\smsts.log

•Full version x64 windows, after SCCM agent installed:
c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log

•After Task Sequence has finished running
c:\windows\system32\ccm\logs\smsts.log

•After Task Sequence has finished running(x64)
c:\windows\sysWOW64\ccm\logs\smsts.log

Information is also logged as SCCM client events, which can be viewed by running the SCCM report:
Last 1000 messages for a specific computer (Errors, warnings and information)

As a general rule, the SMSTS.log provides more detail, however the SCCM client events are easier to read, and, for simple issues, can lead you to the root cause very quickly.

PXE boot issues
In order to resolve PXE boot issues, there are two main log files we are interested in:

•Pxecontrol.log — which is located in the installation logs directory (eg C:\Program Files (x86)\Microsoft Configuration Manager\Logs\pxecontrol.log)

•Smspxe.log — which is located in MP logs directory (eg C:\Program Files (x86)\SMS_CCM\Logs\smspxe.log)