SBS 2008 hangs on "Applying Computer Settings" during boot

Symptom:
During boot, the server spends 30 minutes while displaying "Applying Computer Settings". After 30 minutes, you are allowed to logon and the server behaves fine. After a variable amount of time, the server may become unresponsive to the clients and on the console. May take a day or a week.

OS:
Windows Small Business Server 2008

Patched to the latest patch as of 12.9.2011

Hardware:
DELL PowerEdge T610
1x Xeon CPU 5330
16GB memory
3x SAS 300GB 15k in RAID 5
Two NIC's, one in use.

Other info:
It is also running two small databases. One on SQL 2005 which is installed with the operating system, and one on SQL 2008 R2.

Performance monitoring shows a normal workload, but some times it reports heavy paging and CPU spikes.

Antivirus is fully updated Trend Micro Worry-Free Advanced. When we uninstalled the ScanMail engine, it became much better.

What I want:
I'm primarily looking for a proper boot-logger that can tell me how long the server spends on each part. I'd like to know what the server is waiting for. I've looked at SysInternals Process Monitor, but that was a scary piece of software that slowed down my testcomputer imensely and produced 5 million loglines on one Windows 7 test-boot.

Emil , Norway

LVL 3
rakoczyAsked:
Who is Participating?
 
rakoczyConnect With a Mentor Author Commented:
RobWill: I know ;) I'm usually answering Q's myself, not asking them. Thanks anyway.

marcustech: I'm they guy you are paying to go through the 5M lines. The problem is not actually the logsize, but the time it takes to boot after enabling the Process Monitor bootlogging. On a laptop with SSD disk(!) it went from 30 sec boot to 30 minute boot. So I actually haven't got the stomach to install it on the server of fear that it'll take 24 hours to boot afterwards.

cgaliher: Thats a good suggestion and it was what I thought my self as well. It had to be a GPO issue, but the problem is that the GPO's are left unchanged after the first install. And the only thing hitting the serveris the Default Domain Policy and the Domain Controller Policy. The latter can't be disabled since it would result in a non-working DC, and the first merely conatins Password Policy Settings and a few other default settings.

To all: If you re-read my initial posts I solved the 40 minute boot issue by uninstalling Trend Micro Messaging Agant which is the same as Trend Micro ScanMail. It's a part of Trend Micro Worry Free Business Advanced. It now boots in 10 minutes. I'm in need of a bootlogger for the next time something like this happens...

Cliff: Thats actually a very good suggestion, but the server is patched up to the latest from MS, so I think that hotfix is included since it's dated 2009.

0
 
MikeCommented:
You don't by chance have another server on  your domain acting as a DC?
0
 
rakoczyAuthor Commented:
No, this is the only DC and it is a fresh new install from january.
0
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

 
rakoczyAuthor Commented:
Mind that my primary interest here is a proper boot logger. The issue seems to have improved alot by uninstalling Trend Micro Scan Mail Agent for Exchange.
0
 
Rob WilliamsCommented:
I trust that the SBS's NIC is configured to point ONLY to itself? If an ISP or router is present, even as an alternate, you can experience this problem.

Trend Micro ver 7.x is known to cause quite a few problems, if 7.x

I would recomend running the BPA which is very good at pointing out configuration issues if any:
http://www.microsoft.com/download/en/details.aspx?id=6231
0
 
rakoczyAuthor Commented:
Point to itself as in DNS? Of course it does, or else the domain wouldn't work since the netlogon service wouldn't publish the SRV records for LDAP and kerberos which in the end would lead to logon issues at the clients.

Yawn.. Try harder. BPA gives no issues.
0
 
Rob WilliamsCommented:
Had to ask as you would not belive how many post here have the ISP added as an alternate and logon times are delayed untill authentication to the ISP times out, and then internal DNS is used. Windows does not always use the primary first.
0
 
marcustechCommented:
I'm primarily looking for a proper boot-logger that can tell me how long the server spends on each part. I'd like to know what the server is waiting for. I've looked at SysInternals Process Monitor, but that was a scary piece of software that slowed down my testcomputer imensely and produced 5 million loglines on one Windows 7 test-boot.

Deal with the 5 million line log file, or pay someone else to.  All you're looking for is the time stamps, identify where the biggest gaps are and fix the rogue driver or component.

Yawn, next.
0
 
Cliff GaliherCommented:
30 minutes is the timeout in some group policy options. So I can ALMOST gaurs tee that a logger will not help. You have a group policy setting that is failing to apply, and the server waits the full 30 minutes for the timeout before moving on.

Common group policy failures that cause this are printer deployments. An unsigned driver will fail to install, the printer push install thus fails with a driver-specific error that GP cannot interpret, and so it waits until timeout.

In a maintenance window, disable all GPO links to the OU with your DC then reboot. I bet it restarts quickly. Then enable a few, reboot. Rinse and repeat, enabling or disabling as necessary, until you find the culprit(s). You can then pinpoint the setting and plan accordingly.

-Cliff
0
 
marcustechCommented:
Hey no worries rakoczy, I was just being sarky.  That's not normal behaviour for ProcMon bootlogging though, I've not actually noticed significant increases in boot time when logging.
0
 
rakoczyAuthor Commented:
I'm closing the question since noone seem to be able to come up with a good bootlogger.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.