Thursday, November 17, 2011

Windows 2003 Corrupt Logon Screen Colours

It's been a while since I came across this one, stumbled upon another one today: the Windows (2003) logon screen colours are corrupt. The logon screen works, you just might not be able to see everything on it.

Here's a reg file to fix it (sourced from http://support.microsoft.com/kb/906510):

Windows Registry Editor Version 5.00
[HKEY_USERS\.DEFAULT\Control Panel\Colors]
"ActiveBorder"="212 208 200"
"ActiveTitle"="10 36 106"
"AppWorkSpace"="128 128 128"
"Background"="102 111 116"
"ButtonAlternateFace"="181 181 181"
"ButtonDkShadow"="64 64 64"
"ButtonFace"="212 208 200"
"ButtonHilight"="255 255 255"
"ButtonLight"="212 208 200"
"ButtonShadow"="128 128 128"
"ButtonText"="0 0 0"
"GradientActiveTitle"="166 202 240"
"GradientInactiveTitle"="192 192 192"
"GrayText"="128 128 128"
"Hilight"="10 36 106"
"HilightText"="255 255 255"
"HotTrackingColor"="0 0 128"
"InactiveBorder"="212 208 200"
"InactiveTitle"="128 128 128"
"InactiveTitleText"="212 208 200"
"InfoText"="0 0 0"
"InfoWindow"="255 255 225"
"Menu"="212 208 200"
"MenuText"="0 0 0"
"Scrollbar"="212 208 200"
"TitleText"="255 255 255"
"Window"="255 255 255"
"WindowFrame"="0 0 0"
"WindowText"="0 0 0"

Monday, November 14, 2011

Bonding Intel Pro 1000/MT in Windows Server 2008 R2

Building a vCenter server for a vSphere cluster on Windows Server 2008 R2 on hardware which has two Intel Pro 1000/MT NICs. We're connecting this server to a HA infrastructure so we want to bond the NICs. However it's not possible to bond the NICs using the native Windows drivers (as ever).

A trip over to the Intel site revealed an interesting thread on how to get it working.
You can get the full details here:
Teaming NIC PRO 1000/MT in windows Server 2008 R2
http://communities.intel.com/thread/6529

Bottom line from the thread:
- Get your hands on the Intel Networking Solutions CD v15.3
- Update the NIC drivers from that media
- Run the ProSet install from V15.3_CD\APPS\PROSETDX\Winx64
- Set up the Team(s) via the NIC properties in Device Manager

B

More Kernel Memory Exhaustion

I had occasion to deal with another server today with kernel memory exhaustion issues. Hopefully it's just a coincidence and not a sign of something odd going on...

B

Wednesday, November 9, 2011

Truncate SQL (SharePoint) Log File

I happened upon a SharePoint server that needed some attention - the Config DB log file was 17GB. Shrunk as follows:

DBCC SHRINKFILE('SharePoint_Config_********-****-****-****-************_log', 1)
BACKUP LOG "SharePoint_Config_********-****-****-****-************" WITH TRUNCATE_ONLY
DBCC SHRINKFILE('SharePoint_Config_********-****-****-****-************_log', 1)
GO

(That's on SQL 2005 btw - somewhat deprecated commands)

B

Sunday, November 6, 2011

The application failed to initialize properly (0xc0000044)

Troubleshooting a Windows 2003 x86 server today. It failed to respond to a monitoring ping. On logon, got the following error message:

Windows - Application Error
The application failed to initialize properly (0xc0000044). Click on OK to terminate the application.
[OK]

Rebooted the server, logged on successfully. Cause:
Event Type: ErrorEvent
Source: SrvEvent
Category: None
Event ID: 2019
Date: 11/6/2011
Time: 7:25:55 AM
User: N/A
Computer: *********2
Description:The server was unable to allocate from the system nonpaged pool because the pool was empty.

i.e. Kernel memory exhausted. Can't tell at this stage what caused it. Last time I looked into one of these it was AV software. At least x64 has higher kernel memory limits.

Interestingly, the last logged server uptime event before the crash showed an uptime of 100743098 seconds. That's 3.19 years. Not bad from an uptime perspective. Terrible from a security perspective.

That server is not under my direct control, but I'm going to see if I can influence the server's owner to patch it on a regular basis.

B

PS More info from the Advanced Windows Debugging and Troubleshooting Blog here:
Understanding Pool Consumption and Event ID: 2020 or 2019
http://blogs.msdn.com/b/ntdebugging/archive/2006/12/18/understanding-pool-consumption-and-event-id_3a00_--2020-or-2019.aspx

Wednesday, November 2, 2011

SQL Server Cluster Network Binding Order

When setting up a SQL Server cluster the Setup Support Rules report a Warning for the Network binding order. Specifically:

Rule Check Result
Rule "Network binding order" generated a warning.
The domain network is not the first bound network. This will cause domain operations to run slowly and can cause timeouts that result in failures. Use the Windows network advanced configuration to change the binding order.

However, the binding order is correct. MS KB article 955963 mentions this issue:
You receive a warning about the network binding order on the Setup Support Rules page when you install SQL Server 2008 in a failover cluster
http://support.microsoft.com/kb/955963

In this particular instance I do have a disabled network adapter, an IBM USB Remote NDIS Network Device but no ghosted network adapter. I enabled the IBM adapter, but still got the same error message.

Details.txt showed the following:
2011-10-11 18:14:43 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.NetworkBindingFacet
2011-10-11 18:14:43 Slp: NetworkBindingFacet: Looking up network binding order.
2011-10-11 18:14:43 Slp: NetworkBindingFacet: Network: 'Local Area Connection* 9' Device: '\Device\{BD878763-E1BB-45D6-BFBC-E23DF023E411}' Domain: '' Adapter Id: '{BD878763-E1BB-45D6-BFBC-E23DF023E411}'
2011-10-11 18:14:43 Slp: NetworkBindingFacet: Network: 'Heartbeat' Device: '\Device\{CD08E636-4E30-4AFB-A3B7-513DE2F7EBC9}' Domain: '' Adapter Id: '{CD08E636-4E30-4AFB-A3B7-513DE2F7EBC9}'2011-10-11 18:14:43 Slp: NetworkBindingFacet: Network: 'Production' Device: '\Device\{2BA45633-51E0-4D89-83A1-74DF64B0E9C0}' Domain: 'notpublishingithere.local' Adapter Id: '{2BA45633-51E0-4D89-83A1-74DF64B0E9C0}'
2011-10-11 18:14:43 Slp: NetworkBindingFacet: Network: '(IBM)' Device: '\Device\{4AED0A34-EF02-4AFD-B410-4381462C0C9B}' Domain: '' Adapter Id: '{4AED0A34-EF02-4AFD-B410-4381462C0C9B}'
2011-10-11 18:14:43 Slp: IsDomainInCorrectBindOrder: The top network interface 'Local Area Connection* 9' is bound to domain '' and the current domain is 'notpublishingithere.LOCAL'.
2011-10-11 18:14:43 Slp: Evaluating rule : IsDomainNetworkTopOfBindings
2011-10-11 18:14:43 Slp: Rule running on machine: xxxWSVR004
2011-10-11 18:14:43 Slp: Rule evaluation done : Warning
2011-10-11 18:14:43 Slp: Rule evaluation message: The domain network is not the first bound network. This will cause domain operations to run slowly and can cause timeouts that result in failures. Use the Windows network advanced configuration to change the binding order.

There are only three NICs in the cluster node (Production, Heartbeat and IBM) but details.txt is showing an extra one: "Local Area Connection* 9".

NICs were renamed on the nodes, so perhaps this is some sort of a hangover. I'll revisit it in the future when I have some more time to reproduce the problem in the lab.

B