View Source: FakingItAsAWindowsAdmin

Note: This page has been locked and cannot be edited.
!!! Faking It As a Windows Admin

Phil Hollenback%%%
[philiph | http://www.twitter.com/philiph ]

!! I Just Make This Up As I Go

I have a side job doing IT work for a small company in San Francisco.
Mainly I just help keep a small Mac network running, install software
updates, that sort of thing.  No big deal.  I like the work because it
allows me to keep marginally current in a job I used to do for many,
many years.

This last time the owner of the company called me, she asked me to come
by and connect a new windows machine to the network.  She explained
that they had purchased an automated cutting table which came with an
attached control PC, and she wanted to transfer pattern files directly
to it.

Sounds simple, right?  I figured that I could just throw a new switch
on the network and run an extra cable to this windows machine.  Didn't
quite work out that way of course.

I arrived at the office, new cable and switch in hand.  Very quickly I
realized my idea was out the window.  I had thought this cutting table
was connected to the control PC over usb, like some sort of printer.
Instead, it was networked over ethernet.  There were two separate
control computers in the cutting table and overhead camera.  Both were
connected to a 5-port ethernet switch which also connected to the PC.

Thus, the problem was that the ethernet port on the PC was already in
use.  My first thought was to just put all three devices on the
existing office network.  The big problem was that I had no idea how
to reconfigure networking on the two cutting table devices, so I
couldn't just switch all the IP addresses.  Remember this was a used
cutting table and PC.

After doing some research, I decided to dual-home the control PC and
just put it on two separate networks at once.  That way I wouldn't
have to mess with any network settings on the cutting table.  The
office has a wireless network so I looked for a USB wifi device to
use.  Since the office is a metal building and there was some distance
between the new PC and the access point it seemed safest to use a
device with an external antenna.  I ordered a
[TP-Link TL-WN722N usb 802.11n adapter|http://www.amazon.com/gp/product/B002WBX9C6/ref=oh_o00_s00_i00_details]
as that device seemed to fit the bill, had decent amazon reviews, and
was incredibly cheap ($15).

!! Second Try
The next week I came back to install the USB wireless adapter.  That
process went smoothly - I plugged it in, installed the driver, and
configured it to use the office wireless network.  The device acquired
an address from the dhcp server and everything was good to go.

Or so I thought... My next step was to configure the office macs and
pcs so they could share files with the new cutting table pc.  Should
be simple, right?  First I allowed write access for everyone for the
user's 'My Documents' directory on the new PC.  Then I tried browsing
to that <code>smb://blah</code> share from my own mac laptop.  Worked
fine, and I could drop files on the new machine.

Then the fun started.  Next I tried to connect to the new pc from one
of the office macs.  Connection refused.  Then I tried to connect from
a different office mac.  Connection refused.  Finally I tried
connecting from the other office pc.  Same thing.

Wait, what is going on here? My first thought was that the mac os
version was somehow involved.  My mac is running 10.6 while the
office machines are running 10.5.  So, that idea makes sense - except
what about the existing pc not being able to connect to the new pc?

After a little more head-scratching, I found a clue: as I mentioned
earlier, the new cutting table setup was used equipment.  It came from
another office.  Hmmm, how was the network set up?  Yup that's right,
this new pc is still part of the previous domain.

Well, the old windows domain controller doesn't exist any more, and
this office doesn't have a domain, so I guess I'll just switch this
machine from domain to workgroup.  A few clicks later, the pc is
rebooting to come back up as part of workgroup <code>WORKGROUP</code>.
Should work fine.

Well that's interesting, the machine is back up and I'm trying to log
in as Administrator, but it's not taking my password!  That's odd
because I thought by default Windows XP machines had an empty
Administrator password.

Wow, now I'm totally locked out of the system - the previous default
user login was part of the old domain and has disappeared.  I can't
log on as Administrator because I don't know the password.  I'm
sweating a little because this system needs to be up and ready to do
some work the next morning.  I try booting in safe mode with
<code>F8</code> - no luck.  Also the 'press f8' timing is so brief on
this system it takes me 5 reboots to finally get it right.  Sigh.

Ok, there must be some way to break in to a windows box if you don't
know the password, right?  Time to do some googling.  A few minutes of
that finds me what appears to be a legit windows break in tool,
[ntpasswd | http://pogostick.net/~pnh/ntpasswd/].  Looks like I can
download that, dump it on a usb key, and boot this windows machine off
usb to break in.  Ah, ntpasswd runs on linux, so I'm all up in my
wheelhouse.

Hey wait, I don't have a usb key!  Aw crap.  Maybe there's one here in
the office. Yes, there is - but it's got someone's files on it.  Mount
the found usb key on my laptop and carefully copy all the files off.
Then, move it to the office windows machine and drop the usb boot
files on it.  Finally I run <code>f:syslinux.exe -ma f:</code> to
install the boot sector on the usb drive.  Now I'm ready to boot up
the new pc and break in.

Amazingly, that goes off without a hitch.  I hit <code>f2</code> on
boot and pick the usb device for boot.  The machine boots into linux
and I follow the step-by-step ntpasswd instructions for mounting my
windows drive and finding the registry.  Ultimately I find that the
Administrator password isn't set, but the account is locked.  ntpasswd
fixes that up, and I reboot.  Then I go reformat the usb drive and put
all the original files back on it so the owner will never know what
happened.

Finally, I must be all done, right?  Well, not quite.  After I boot
the machine up I log in as Administrator, so that's a small victory.
But... where's the special cutting table software that was on this
machine?  Oh crap (again) it was tied to the user that was part of the
domain.  By nuking the domain I've removed that user from the system.
Sigh (again).  Then I realize it's even more fun: there are a bunch of
custom settings for the cutting table.  Those settings were stored in
the cutting table software I now can't access.

At this point I give up for the night as it's getting late.  I
rearrange my schedule for the next day so I can come back to the
office first thing in the morning and call tech support to somehow
recover the cutting table setup. fml.

!! The Next Day

Ok, now it's the next day!  Back at the office at 9am, call the
cutting table manufacturer.  Explain what I did.  Luckily the tech
support guy is super helpful.  First, I have to download their
software from the website and install.  Then, I send a registration
key to the tech.  He emails me back a magic program to run to unlock
the software.

Next, figure out how to recover the table settings.  The tech gives me
the name of the config file so I search the machine for it.  Yay,
there's the file.  The tech tells me I should just be able to open the
cutting program, go to the table config, and click <code>import</code>
to select and import the old config file.  Try that.  Whoops, cutting
table software crashes.  Restart software, try again.  Same thing.
Tech on the phone says that the software is "kinda buggy".  Why am I
not surprised?

Fallback plan: I mail the config file to the tech and he looks at it
to extract the relevant information.  He then directs me through the
various pages of config details in the cutting program where I enter
lots of arbitrary numbers.  Finally I'm done!  Only took an extra
hour.

We run a test job on the cutting table and it actually works!
Success!  Then, I configure the shared directory on the cutting pc
again, now that the machine is no longer part of the dead domain.  I
go to the various other machines on the network and try connecting to
the cutting pc.  Everything works! Angelic trumpets! High fives!

!! The End

After congratulations all around, I quickly pack my bag and run out of
there before anything breaks.  Fifteen minutes later I'm logged in to
my real job, keeping thousands of linux PCs running.

Basically, that's why my day job does not involve fixing windows pcs.
Because I'm not very good at it.

!! Update!

The folks over at reddit have some [great comments|http://www.reddit.com/r/sysadmin/comments/p04nt/im_a_terrible_windows_admin_so_i_wrote_about_a/] about this post.  You know what? They are largely correct.  I did a sloppy job.  I should have done more research and documented things better before I plunged in.  For example, I should have called the cutting table company tech support before I did a single thing and asked for their advice.  They would have probably told me to save the config and such before I did anything.

Also, I should have asked my real windows admin friends for help, I'm sure they would have steered me in the right direction.

But, I was in a hurry and I thought I could just plow through things.  Know what? It ended up ok, but it took longer than it should have and I didn't do things the right way.  Please learn from my example and *don't* do things this way.  In my real job I would have serious doubts about someone who did what I did in this story.

CategoryGeekStuff

CategoryBlog
View Source: FakingItAsAWindowsAdmin

Main Categories

Search

Toolbox

RecentChanges

Favorite Categories

Views
