Diff: FakingItAsAWindowsAdmin

Differences between current version and predecessor to the previous major change of FakingItAsAWindowsAdmin.

Other diffs: Previous Revision, Previous Author

current version

Faking It As a Windows Admin

Phil Hollenback
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 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 smb://blah 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 WORKGROUP. 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 F8 - 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. 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 f:syslinux.exe -ma f: 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 f2 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 import 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 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