Friday, December 7, 2012

This is why I use unix-like...

Here's the story.  We build a server for biometric authentication, right?  Piece of cake.  Except for the fact that the USB devices only work in an OS that starts with Win, but ends with "Doh!"s.

It gets carried out to the data center and racked.  Wont come online; no ping, and no RDP present.  Network Engineer gets it online with the IP KVM and manages to get it online.  Windows Firewall was blocking the traffic.

What?  No, that can't be possible, because when we shut it down the last two things that happened was to change to the DC IP and turn off Windows Firewall.

So I get the software installed and the appserver connected to it; since I'm just the engineer, I don't have any IDs or anything to test with so I call it a night.  The next morning the technicians test it out and everything is working- yay.

That night I'm on the VPN and brushing up the second instance of the biometric server, or at least I was trying to, but I couldn't get to the server.  I figured there was something up with the VPN again and it lost a route or something.  The next morning at work I still can't get on it.  So the network guy jumps on the IP KVM and log on.  Windows Firewall had turned itself back on, again.  This machine is off-domain with a pretty minimal config and everything was turned off with the Administrator user.

So when I get RDP back, I turn off Windows Firewall, again.  Then I turn off the service Windows Firewall.  There; try to get out of that you ... bad server.

Because I'm OCD, I try to work from home again that night.  This time ... no, I still can't get on it, but it has to be the VPN this time.  I get to work the next day, today, which is exactly one day before this biometric authentication server is to go live for tens of thousands of people, and it's offline again.

I know what you're thinking; "this can't be happening; it's made up."

I can't make this up.

Windows Firewall wasn't on, though.  Sometime in the night it did Windows Updates and rebooted itself.  A server decided to reboot itself because it wanted to.  This is OK, right?  Who cares what the server might be serving; heck, there was an update to .Net!

I'm not using any .Net services.

None of that was the real problem, though.  The real problem is the static IP that was configured and working the day before was suddenly 169.254.... Yes, an autoconfig IP address when a DHCP server isn't available.

It's not DHCP, it's static.  It's not on the domain; it's stand-alone.  Seriously what is happening?

TCP/IP is damaged, to make a long story shorter.  Why?  Who cares.  How do I fix it?

Like this:

netsh int ip reset c:\resetlog.txt
shutdown -r -t 00

The first command will reset the TCP/IP.  Be aware, that the second command is going to do exactly what it says; you're going to shutdown and reboot without waiting at all.

When it comes back up you will have to set your static IP again.
Then hopefully your ping -t <hostname> will start returning.

Stupid.