There’s a neat feature built into Windows 7 and the Windows 2008 Server R2 variants in powercfg. It performs a fairly simple power audit and will tell you if there are improvements, what your hardware can support, and what device or software is preventing your machine from entering sleep. You simply run “powercfg –energy” from a command line and an html report is created in “c:users%username%” called “energy-report.html”.
This one is really easy, but I am surprised at the number of people who are unable to troubleshoot it. If you think you are having sql connections not being closed properly, just open up perfmon, go to “.net data provider for sqlserver”, and add “numberofreclaimedconnections”. Basically what this counter shows is the number of connections that were not closed by the application, but were closed by the .net garbage collection process. Microsoft’s explanation is on this page. The same counter works for the oracle client as well (except it’s called “oracle” and not “sql”).
The symptoms of this would be a whole lot of idle connections to sql (or oracle) from the webserver, or errors about not being able to obtain a connection, running out of connections in the pool, etc. You can also see lots of connections in the time_wait status if you run a netstat –an.
I have been using Open Audit for a while now. It’s a server/network inventory tool that is free and kinda kicks butt.
At my current job I decided to use the ldap integration, and I was having a hell of a time getting it to work. Basically I could enable LDAP OK and create the LDAP configuration just fine, but when I went to create the actual connection, it wouldn’t work, giving me an error message:
Server connection successful
Default Naming Context: DC=accessgeneral,DC=com
User DNS Suffix: accessgeneral.com
!! Unable to bind to server !!
Err Number: 49
Err String: Invalid credentials
Check that credentials are correct
I tried using a different account, using a different LDAP server, and even did a network trace to see if the connection was actually trying to take place. What finally lead me down the right path was to look at the apache logs, where is lists my password as a part of the request in clear text. Turns out the passwords weren’t the same as what I had typed in because both f the passwords I was using had a pound (“#”) at the end, and apparently that’s not a cool character for PHP to use. This resulted in the password being entered incorrectly. Unfortunately I didn’t catch this sooner because both of my test accounts ended in #.
Once I made this change, it worked on the very first try. Lesson learned.