Reliable Information from Bo

Problem: Needed a system that would allow customers to store the physical installation media off-site (for Disaster Recovery) while maintaining easy and orderly access to the installation images..

Solution: Install a Linux SAMBA server, and store the installation images in a hierarchical file system. Store the Physical CDs and copies of downloaded files off site.

Even a small company has lots of different software packages. Several of these packages are released as a base product, with subsequent upgrades and patches. It doesn’t take long for a CD rack to become full, and its easy to put a CD in the wrong slot when you return from a desktop install/upgrade. Its easy to find oneself in the awkward position of having to hunt for ‘upgrade CD 6.1′ when installing version 6.2 of a product. It didn’t take me very long to figure out that physical control and placement of the media was not working. I needed a system that would allow me to store the physical media off-site (for Disaster Recovery) while maintaining easy and orderly access to the installation images.

I wanted to have all the software grouped by product, and be available to me from anywhere on the customer’s network. The new network based ‘install server’ had to be inexpensive. The install server had to be reliable (That is our name after all!). And of course it had to be accessible from a variety of windows platforms. It was easy to see that a Linux / Samba server was a good fit.

I started with a Pentium 166 PC with 12MB of ram a 4x CD drive and three open IDE slots. I installed a 2.5 GB Hard drive from a ‘throw away’ to be the OS drive. I obtained an 30 GB hard for use as the repository drive. The third bay was left open, with the thought that another larger hard drive could be installed later.

I installed a SuSE distribution of the 2.4 kernel, WITH OUT GRAPHICS. The machine had only 12MB of ram, and the GUI would have just been to painful to use. I created the repository as a ext3 file system. I installed SuSE’s 2.2.8 version of Samba. I configured the samba server to make the repository available as a read-only public share.

I built a file system tree with each vendor name directly under the ‘installation’ directory.
Within each vendor directory I created a directory for each product. Within that product directory, I created a directory for each version or release. I copied the install CDs to the appropriate /installation/vendor/product/release directory, naming the CDs by their number (CD1, CD2, etc).

I also downloaded the common ‘free download’ code used in the client’s business using the same naming conventions. For example:
I have drivers for the HP630 in the HP folder.
The Adobe Reader files are in the Adobe/Reader/$Version folder

The Linux/Samba server has made access to the right installation image easy, fast, and safe. The ‘original’ CDs are in safe keeping, and I’m getting productive use from a Pentium 166 with 12MB of ram. All-in-all, I think its a great solution.

Problem: Remote users need web site access granted from with IE’s Content Adviser. Sharing of the CA password is prohibited.

Solution: TightVNC installed on each PC before it leaves the IS Build Room.

Like many other companies, my largest client has chosen to restrict access to the internet for most of its employees. The chosen method is to enable Content Adviser from within IE. When A customer attempts to access to a web site that is not on the approved list, the Content Adviser authorization screen is displayed. An IS Tech then grants access via the established password, if the destination meets the company’s criteria.

For local PC’s this is not to much of a hassle, but for remote facilities, this can be problematic to say the least. One can not simply walk the customer through authorizing the site themselves, so the ‘end-user as remote admin’ technique is not an option. The geographic distribution of employees makes on site administration infeasible. Most remote locations have only one or two machines, making a dedicated tech an unreasonable expense, and sending a tech to China or Italy for each new site just isn’t going to happen.

My search then, centered on finding a remote desktop solution that was affordable, reliable, and effective. I have found one such solution to be TightVNC.

TightVNC is a free remote control software package derived from the popular VNC software. With TightVNC, you can see the desktop of a remote machine and control it with your local mouse and keyboard, just like you would do it sitting in the front of that computer. TightVNC is:
free, GPL-licensed, with full source code available;
useful in remote administration, remote customer support, education, and for many other purposes;
cross-platform, available for Windows and Unix, compatible with other VNC software;
well maintained and being actively developed.

With TightVNC, out techs can provide the required authorization, with out going to the customer’s desk, and with out sharing the content adviser password.

TightVNC installation is pretty straight forward, though it does seem that a reboot is required to ‘register’ the session password. It should also be noted that TightVNC should be installed BEFORE the PC leaves the local area!

TightVNC can also be used to monitor the remote employee’s use of the computer equipment. The TightVNC session can be used to display the desktop as the customer performs their daily tasks. This remote viewing capability can be used to identify areas where additional training would be useful.

This week’s problem is taken from recent history:
“How do I change my password on the server, now that I’ve migrated to windows XP Pro?

The simple fix:
“Join the PC to the domain, and use the ctl-alt-del change password feature.”

As you know, things have a tendency to become a bit more complicated, so here is the rest of the story.

One of my clients, an AS/400 based shop, has geographically separated facilities. These remote offices have access to the AS/400 via T1 class connectivity. The AS/400 (Or iSeries as IBM calls them now) provides DHCP services, and CIFS support. The largest remote facility has a windows 2000 file server that is the PDC (running active directory). Most of the client PCs are still running windows 98. The windows 98 machines have a batch file that invokes the “net password” command to change the user’s password on the server. New PCs are deployed with Windows XP Pro installed.

Windows XP Pro will not run the “net password” command, so I’m called to “Get this PC to let me change my password on the local network drive”. My proposed solution is simple. Make these new XP machines client member machines of the domain. Then you can change your local PC and Server password at the same time (In fact you will only have on password, the domain password).

The ‘join the PC to the domain’ step went quite well. No issues at all with adding the client PCs to the existing domain. Logging into the domain was straight forward as well. Put your user name, click options so that you can chose the domain, instead of the local PC, and type in your password. Worked like a charm. However, when the ctl-alt-del three stroke was employed, and the option to change password was chosen, things didn’t go so well at all. The system would grind and grind before coming back with ‘unable to change your password because the domain is unavailable’.

Domain is unavailable? The same domain I logged into, on this same PC, is now unavailable? What gives?

I start checking the logs on the windows 2000 server. Nothing jumps out and grabs me, so I’m off to Microsoft’s site. Lots of neat stuff about how cool XP is, but nothing about why 98 could use the domain server, and XP can’t. After long periods of mental gymnastics, I realized that the 98 machines didn’t use the 2000 box as a domain server either. They just thought of it as a member of their workgroup.

This insight lead me to the next question, why is my 2000 server not acting as a proper domain controller? With the new question in mind, I go back to the server logs. Now I see something interesting - when I try to change my password the server has a kerberos authentication failure (event 537) from an unknown workstation recorded in the security log AND an Dynamic DNS registration failed because no DNS server is available (event 5781) in record in the application log, when I logged into the domain. NOW on a hunch, I update the hosts file on the client and server so that they KNOW each other’s IP address. I think try again. It works!

Solution as deployed: 1) Add the XP machines to the domain
2)Manually update the server’s hosts file with the client’s IP
3)Manually update the clients’ hosts files with the server’s IP

Other solutions (like having a DDNS server in the domain) were outside the scope of the project.