Issues upgrading Domain Schema to 2003

So I'm probably a little behind in upgrading my home networks domain schema to support Windows 2003 but better late than never!
The process itself was smooth enough once I'd corrected some problems on the machine but the upgrade logs were not the most helpful troubleshooting aid I've come across.
One particular error had me stumped for a few days:

"Error code: 0x57 Error message: The parameter is incorrect.."

No indication of which parameter it was but as it occurred when checking security descriptors and many blog articles refer to missing security ACL's on GPO's I had a look at those and sure enough, Enterprise admins was missing some rights so I fixed those up and....... the same problem. At this point I'd admit to a lot of head scratching. The event logs didn't shed much light until I realised that the security event logs were not accessible. Sure enough, somehow the ACL's on the security event logs had lost all their rights. Resetting these and then rebooting allowed the process to complete perfectly.

Centralised Logging

One of the essential features for even a small network is a centralised logging solution.
Having a centralised logging tool makes for much easier trouble shooting as it becomes possible to review logs and search for related events or even search for the same event on separate machines, traditionally this has required quite expensive software such as HP open view in order to implement but a fairly new company might be about to put an end to that.

Enter Splunk, The 'Google of IT data'. This application will happily collect all sorts of different logs once configured and the configuration is not too difficult.

Splunk needs to be installed onto a Linux, Mac or Solaris environment although a Windows version is promised soon. As a workaround Splunk recommend that SNARE is installed on Windows servers. This software will convert event logs into syslog format and send them to a named server.

Putting Splunk in the center of you logging infrastructure as a syslog server and pointing all your syslog capable devices at it and then using SNARE to roll up event logs as syslogs which also get sent to Splunk is very easy to do. Within a few hours you have a surprising amount of data available to be searched by splunk.

And the price for all this information?

SNARE is free, Splunk is free if the amount of data you send to the Splunk server is less than 500mb a day although some of the features are limited.

I will admit to being a fan of Splunk after playing with it in VMWare. Over the next few weeks I'm going to describe how to configure a simple splunk installation for Linux, Windows, NetApp filers and Cisco switches.

The power of the human mind........ to fail.

The human brain is an amazing computer. It can store almost infinite quantities of data, it has near instant recollection to enable you to recognise people, places and perform the essential day to day actitives of breathing.

So why does it let us down in the middle of a crisis when you need to have that vital bit of information or when you remember seeing a tech note on the very problem you are fixing but can't recall the technical notes reference number.

The answer is simply to do with the way the human mind has evolved, Our technological prowess has evolved quicker than the brains ability to deal with this new landscape. When we, as a specics, were huddled in caves a crisis required the 'fight or flight' response and today when you have a crisis in the office that same reaction kicks in and all of a sudden you have trouble recalling technical details yet when the crisis passes you will be doing something else when the brain, still working on the problem in the background, will kick in.
The military actually have special training programmes to allow test pilots and others under extreme pressure to continue to think rationally. It is a very special SKILL.

so, why do we all have problems saying 'I don't know' and recording those oh so useful technical notes when we have the chance?

In the IS industry there seems to be a huge amount of pride in relying on ones memory to get people through a bad day. Checklists and procedures only seem to come into force for the day to day working practices - I have yet to see a company have an emergency procedures checklist.

Troubleshooting DHCP

I had an interesting time quite recently troubleshooting a DHCP problem. The server wasn't giving out IP addresses when connected to the network or when connected to a hub.
The reason turned out to be a cisco switch problem but the fact that DHCP wasn't working when on a hub clouded the issue.

After fixing the problem (rebooting the switch) I figured that a blog on how to troubleshoot DHCP in Windows 2003 might be of some use as even though this wasn't a DHCP issue I did need to rule out DHCP.

1. Take a look at the DHCP log file normally held in %systemroot%\system32\dhcp. They are in day order and so rotated every 7 days. A healthy log will show lots of 11,[DATE],[TIME],[RENEW],[IP],,[MAC]

2. If the log doesn't show any IP's being issued restart the DHCP service and check that the log shows AUTHORISED. This means that it's ready to start issuing addresses.

3. Verify that the IP addresses issued are for the CORRECT SUBNET. For example, if your server's NIC is configured for the 192.168.1.0 network and you're DHCP server is issuing addresses for the 172.16.1.0 network then it will NOT issue addresses even if the client is connected to the server over a hub or similar. I will do another posting soon showing a quick way of working out a machine network address.

4. Bring up the properties of the DHCP server and check that you have free addresses that can be issued.

5. Verify that any switches have IP Helpers/DHCP forwarders setup. Remember that DHCP is broadcast only so it is limited to a single subnet.