W2K3 with SQL Server 2K as a Domain Controller? etc.

[mortsdeh]

Hi,
Have a question about a server environment. I ask this question because of performance issues regarding SQL Server and an unwanted reboot of the system.

The environment: My company has developed an application that resides on a W2K3 server (Server1) and uses a SQL Server 2K on the same machine. This SQL Server replicates to another server (Server2) having the same setup regarding our application, OS and database. From what I understand it is not optimal to have the application on the same machine as the SQL Server, but it is.

When I check the services setup on Server1 it is configured as a FileServer, Application Server and a Domain Controller. Server2 are configuread as a File Server, Print Server, Applications Server, Domain Controller and a DNS Server.

Question 1: Are any of this services necessary? If some are, which are not?

We have experienced 1 unwanted reboot of the server. When examining the event logs I came to the conclusion that it was a DNS lookup failure together with a Active Directory replication that caused it.

Question 2: Could the Domain Controller and DNS Server servies be shut down?

On Server1 ther has also been an unusual activity in the Microsoft Indexing Services. The average CPU usage has been on 60-70 % for several days when the server application was not used.

Question3: If I turn of Microsoft Indexing Services, would it affect SQL Server indexing.


Question 4: Any general thoughts on this environment

I would be very grateful for any input on these questions,
Best
/M

 

[NJForensics]

Good Morning-

Ok for question #1.

For both servers, domain controller is essential and dns is crucial on the second server. Make sure the server one is using server2 and the primary DNS server. This may be the root of your replication difficulties if server1 does not know how to properly resolve to server2. Based on your explanation of SQL and its replication, application server is needed. File server is likely needed and the print server is only necessary if you intend to actually use the server to share out printing to clients.

For # 2.

No, do not mess with DNS or Domain Controller Services (ntfrs, netlogon, etc)

#3

Leave the indexing services on, it is likely not the root of your problem.



Chris Clancy, EnCE
Miles Technologies

 

[pgaliardo]

Question 2: Could the Domain Controller and DNS Server servies be shut down?

Windows domains absolutely rely on DNS, so the last thing you want to do is stop your DNS server. You can't just stop a domain controller, you would have to demote it. That being said, if you demoted both your Domain Controllers, you've pretty much brought your network to a halt. So the simple answer to question 2 is NO.

I don't know about the size of your network or the budet, but I generally like dedicated machines to domain controllers as well as SQL.

 

[mortsdeh]

Thank you both for your replies. They were most helpful.

Our product and related clients, servers and machines are on their own domain so the server configuration is correct I guess. I thought that the DNS lookup failure might have caused the unwanted reboot (therefore my questions about server services) of the server, but the time of that event is after the actual reboot so it might be an effect of the reboot.

I have installed Debugging Tools for Windows on another W2K3 server and copied the minidump file that was created from the reboot to debug it. I didn't want to install anything on the product server so I perform the debugging on another machine. Is that possible?

I used the line "windbg -y srv*c:\symbols*

http://msdl.microsoft.com/download/symbols

-i c:\windows\i386 -z c:\theminidump.cmd" from the command prompt to start the debugger. From what I can tell there is a driver problem.

Could this have happened because of a USB connected UPS device being placed on another USB port it was installed on? How should I proceed to verify the error?

The Bugcheck Analysis from executing the command "!analyze -v" generates the following:

kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00650057, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 80a5702a, address which referenced memory
Debugging Details:
------------------

WRITE_ADDRESS: 00650057
CURRENT_IRQL: 2
FAULTING_IP:
hal!HalRequestSoftwareInterrupt+2a
80a5702a 890d0003feff mov dword ptr ds:[0FFFE0300h],ecx
DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP
BUGCHECK_STR: 0xA
PROCESS_NAME: System
TRAP_FRAME: bafb3ccc -- (.trap ffffffffbafb3ccc)
ErrCode = 00000002
eax=00000000 ebx=89ef20d8 ecx=00650057 edx=00000000 esi=00650053 edi=00650057
eip=80a5702a esp=bafb3d40 ebp=bafb3d6c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
hal!HalRequestSoftwareInterrupt+0x2a:
80a5702a 890d0003feff mov dword ptr ds:[0FFFE0300h],ecx ds:0023:fffe0300=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 80a5702a to 8088bdd3
STACK_TEXT:
bafb3ccc 80a5702a badb0d00 00000000 89ef20d8 nt!KiTrap0E+0x2a7
bafb3d3c ba5b70b9 00000000 89ef20d8 89ef20dc hal!HalRequestSoftwareInterrupt+0x2a
WARNING: Stack unwind information not available. Following frames may be wrong.
bafb3d6c ba5b7b24 04ef20d8 bafb3db7 00000000 digirlpt+0x50b9
bafb3dac 80948bb2 00ef20d8 00000000 00000000 digirlpt+0x5b24
bafb3ddc 8088d4d2 ba5b78ca 89ef20d8 00000000 nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb
FOLLOWUP_IP:
digirlpt+50b9
ba5b70b9 ?? ???
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: digirlpt+50b9
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: digirlpt
IMAGE_NAME: digirlpt.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 3ce03fbd
FAILURE_BUCKET_ID: 0xA_W_digirlpt+50b9
BUCKET_ID: 0xA_W_digirlpt+50b9
Followup: MachineOwner

 

[mortsdeh]

An initial bugcheck analysis not shown in the above message is these lines:

---------------------------------------------
BugCheck A, {650057, 2, 1, 80a5702a}

*** WARNING: Unable to verify timestamp for digirlpt.sys
*** ERROR: Module load completed but symbols could not be loaded for digirlpt.sys
Probably caused by : digirlpt.sys ( digirlpt+50b9 )

Followup: MachineOwner
---------------------------------------------

I have verified that this file exist on the server and that an Digi EtherLite device is installed on the server.

Question1: It is most likely this device that has caused the unwanted reboot, right?

Question2: How can I verify that it is this device? How can I verify that this digirlpt.sys is not used by any other application/hardware?

Question3: Can I from the above post find out how this Digi EtherLite (if it is responsible) caused the failure? The IRQL is 2 and that means software, right? The FAULTING_IP is DRIVER_FAULT_SERVER_MINIDUMP. Can I assume that this is a driver problem or can it be caused by any hardware problems such as e.g. faulty connections?

Grateful for answers
Best,
/M