Read Only For Everyone

Problem: I recently shared a directory on an XP workstation and granted a specific domain user write access to the shared directory (NTFS write access). The user with the write access attempted to create a file in the shared directory and got "access denied".

Solution: I changed the Share permissions from Everyone having Read Only access, to Everyone having Full Control.

If you're an old NT techie you'll remember that before XP Service Pack 1, the default access for shares was Everyone - Full Control. We usually left the share permissions Full Control and assigned the appropriate permissions at the NTFS level. We did this to keep from confusing ourselves with conflicting permissions resulting in problems like the one above. Well, SP1 reversed this default to: Everyone - Read Only, and as we all know, NT security enforces the most restrictive access between the Share permissions and the NTFS permissions. So, when sharing data on XP, make sure the share permissions are either the same or less restrictive than the NTFS permissions. (Then you'll be able to sleep at night..... :o)

Gambling With Your Data

Problem: A user reported that his critical application was down because his machine wouldn't come up. "It says something about 'primary hard disk 0 failure', and just stops".

Solution: If it's really your critical application, and the only copy of the data is on that machine, what you need to do is find a current newspaper, open it to the classified ads and start that long hard search for a new career; outside of IT.
Seriously, it's 2004. If you can't find a way to protect your critical data you don't belong in this business. First of all, truly critical data should NEVER be stored (as the only copy) on a workstation. If you don't have a properly backed up server on which to store it, make copies on anything you can find. Today you have lots of choices:

• CDs
• DVDs
• Zip drives
• Floppies
• PDAs
• USB Flash drives
• Paper, if nothing else

You can even turn on File and Print Sharing and store data on another workstation (This is not ideal, but at least you'll have another copy!).

At any rate, a workstation should be viewed as a "throw-away", a tool that can be trashed on a moment's notice, without having to worry about the data. When the hard drive goes South, and it eventually will, you'll want to be able to drop in a new hard drive, rebuild it and move on.

As they might say at MasterCard, workstations are cheap; critical data? ........ priceless.

No New Mail

Problem: An Outlook/Exchange user reported that she had not recieved any new mail in 3 days.

Solution: This is a frequent complaint with our Outlook users. "No new mail" always means that the user has lost contact with the Exchange server but, it's not always for the same reason. This time the indicator at the bottom right side of the Outlook window showed 'Disconnected'. Sometimes this simply means that the network cable is disconnected, but in today's case it wasn't. The network connectivity was fine; she could get the internet and to her network drives. Further investigation revealed that her Exchange account was set to the wrong server. The Exchange administrator had moved some users to a new server but had not verified that the account information was updated. I shut down the user's Outlook session, opened the Mail dialog in the Control Panel and changed the user's account settings to point to the new Exchange server. When we launched Outlook, viola! New mail (too much new mail.... :o)

Limited Or No Connectivity

Problem: The user reported that she could no longer get to her e-mail or to the internet. "It just stopped working 2 days ago and has not worked since."

Solution: Initial investigation revealed that her network connection was in that new limbo state, reporting that the local connection had "Limited or no connectivity". I think this is new with XP SP2, but I can't say with certainty (That would mean I'd have to do a little research which in turn might require me to read something. No way). Anyhow, I've seen this a couple of times, now, both involving machines that were set to get IP addresses from DHCP. In both cases the machines had "169" addresses, meaning they couldn't contact the DHCP server. Also, in both cases the problem boiled down to a bad network port.

Whatever, this new state of "Limited or no connectivity" does me no good, so far. For me, "Limited or no connectivity" has equated to NO connectivity. I spent a lot of time trying to detemine if there was something I could do to cure the problem. Both times I encountered this I couldn't even ping the default gateway, let alone the DHCP server. So, I think we would be better off if we just got the old familiar red X on the network icon, indicating that the connection is just plain broken. But, that's just my limited opinion.......

Let's Get Back To Basics - What Changed?

Problem: The user reported that she was getting repetitive system crashes, but couldn't tell me exactly what was going on at the time of the problems. She had a recoverable BSOD at one point but didn't capture any of the debugging information. The problem record had the words "Fatal System Error" and 3 Hex strings, and that's about it.

Solution: I searched the internet for any clues related to the Hex strings. Nothing there.
I then wanted to eliminate any hardware issues, so I downloaded the diagnostic utility from Dell, created the floppies and ran the diags. You guessed it; no hardware problems. I then launched every application I could find and saved test files, trying to produce ANY kind of problem. No luck. After an hour of fruitless searching the user finally admitted that Adobe Photo Delux had been added to the machine recently. She had evaluated it and decided not to use it, and asked me to remove it. This I gladly did. I then stood by for awhile and watched her try to reproduce the error she had been seeing, without success.

There's no guarantee that Adobe Photo Delux was causing the problems but I would almost bet it was. It was the only thing that had changed, and so far we haven't seen the problems again since it was removed.

Anyhow, sometimes we forget to ask the most fundamental question when it comes to solving almost any computer problem: "What changed? "

Software SOB Story

Problem: The user reported that regular Domain Users could not use the AutoCAD product that is installed as a component of Autodesk. A message said that the application couldn't write to the registry. No kidding, some software really can be an SOB! I didn't do the installation, but I got the call when it wouldn't work.

Solution: Sorry, but I have to vent a little bit here. So that you know I'm not just picking on Autodesk, I've seen this problem with lots of products. COME ON PEOPLE! Don't you know that many organizations use your products in lab environments where most of the users don't OWN the machine the product is running on and don't have ADMINSTRATIVE PRIVILEGES???? Why in the name of God would you develop an application that writes to the registry every time the procuct is launched?? I did find some documentation that says you can run with Power User rights, and that's true. BUT, we don't want the lab users to be Power Users either. This is no help! (WHEW..... I feel better now).

Anyhow, most of the time we can work around these silly problems with various software packages by giving write access, or sometimes full access to the product's root directory, or to some file. For the Autodesk problem we have the added challenge of trying to find out which registry key the users need to write to. We haven't quite figured it out yet, but when we do I'll edit this post with the final solution.

Stay tuned.........

On second thought, I won't publish the registry key here, just because I don't want to encourage registry hacking. If you have this problem, please bug the vendor.

Moving Mozilla Mail

Problem: A Mozilla mail user gets a new PC and needs to have her local mail folders and address book moved to it.

Solution: Mozilla stores all of it's user specific files in this profile path:
C:\Documents and Settings\Userid\Application Data\Mozilla\Profiles\MozillaProfileName\RandomNameDirectory.slt

Do the following:

1. Copy the contents of the above path from the old machine to some location (like a network drive or zip drive) where you can get to it from the new machine.
2. Install Mozilla on the new machine.
3. Launch the Mozilla mail client and follow the dialog to create the new mail profile and set the application to recieve mail from the server.
4. Stop the application
5. Copy the following items from the saved profile data to the profile path (see above) on the new machine:

• Mail directory
• abook.mab file
• bookmarks.html file (if the user also uses the Mozilla web browser)

6. Launch the mail client; the local folders and address book should now show.

To Rebuild, or Not To Rebuild.....

Problem: Once in awhile you come across a machine that is SO screwed up that it doesn't pay to figure out what's wrong. Unfortunately, you might work on it for a long time with that I-can't-let-this-damn-thing-beat-me! attitude before you realize you're past the point of diminishing returns. Not very cost effective.

Solution: Set a time beyond which you will wipe the system and rebuild it from scratch. Easy, eh?

It's wrong to call this the "solution" because it might not be the solution for you. It's certainly not the only solution, but it could be one that would work if the conditions are right. Anyhow, you have to know enough about your operating environment to make the call on this. That is, you must know enough about the machines you support, the applications they run and the network they are in to know if/when/how to stop recovery efforts and start rebuilding it from scratch.

For purposes of this example, let's assume that the machines in question are all workstations (as opposed to servers), and that the workstations run no critical or peer-to-peer shared applications. Let's also assume that all the workstations run roughly the same set of standard software, like an antivirus package, MS Office, etc. One further assumption: each workstation has at least one network drive where the user can/should keep all his or her working data, even if s/he also keeps a lot of the current data on the C: drive. Using these assumptions, you could say I will spend no more than 1 hour solving a problem before I begin the rebuild process. After all, the rebuild process under the given circumstances could reasonably be done within 2-3 hours (depending on hardware and software configurations). The process could be something like this:

1. Save all the user's data on the network drive, making sure to check the desktop, My Documents and folders and files at the root of the C: drive.
2. Save the user's local email data, such as mail stored on the C: drive and the address book. You'll need to know enough about the email client in use, and the location of the local mail data.
3. Save the user's internet bookmarks.
4. Save the machine's network configuration (write it down).
5. Save the machine's security configuration (write down users and groups that need administrative access).
6. Save the machine's printer configuration (note all the defined printers and make sure you can physically find them).
7. IMPORTANT - If the machine is relatively new, record the device information, especially for the network device, in case the rebuild process doesn't find the drivers you need.
8. Restart the system from the OS installation CD, delete the existing partition and rebuild the OS from the bottom up.
9. Resolve/install any missing drivers that the OS installation didn't find.
10. Reinstall all the standard software, beginning with the antivirus package.
11. Re-enter the network information and download any current upgrades from the LAN or the internet.
12. Redefine the users and groups that need administrative access.
13. Have the user logon, then restore the saved bookmarks.
14. Add the printers.
15. Restore the user's data from the network drive.
16. Restore/reconfigure the user's email settings.

It sounds like a drastic measure if you're not used to doing this, but it's really not. It can take a lot less time than working on some nasty problem for too long and then having to rebuild the system anyhow. You just need to be ready for it by having all the installation CDs in your bag of tricks. Even more time can be saved if the users are informed about keeping their data on the network drive(s) at all times.

It works for me....

From Publisher, to Adobe

Problem: User needed to convert an MS Publisher file to PDF format. There is no direct way to do this. That is, no way to save the Publisher file as a PDF file.

Solution: I talked to a few people who know Publisher and found it's possible to do this, and they pointed me in the right direction (I figured this was better than spending the whole night working on a product I'd never used before). Anyhow, all you have to do is save the Publisher file as a Post Script file. During this process you need to specify which type of printer the PS file will eventually be printed on (even if you never intend to print the PS file); look at the dropdown list and choose a color PS printer. After the PS file is created, open it with Adobe Distiller, which will do the conversion to PDF. Not pretty but it works.

The MS Publisher help dialog has this documented, by the way. So, if you're inclined to read, unlike me, you probably knew this already....

Pop-up Ads

Problem: User reports lots of pop-up ads and slow response time. The system seems to hang for awhile and then runs momentarily, hangs, runs, etc.

Solution: If the machine will run long enough to download some tools, do the following. If not, it might be time for a rebuild:

1. Download and install the free copy of Ad-Aware from Lavasoft. When the product has completed installation and is ready to run, make sure to choose the option to look for updates. It will go back to their web site and automatically download the latest definitions, and then begin running. It will locate/identify objects (processes, registry entries, directories and files) that are known to be associated with ads that you don't want to see. It will then give the option to delete the objects.
2. Download and install the shareware copy of Spybot Search and Destroy from PepiMK Software (Patrick M. Kolla). Go through the dialog and search for bots. The software will identify and list the problem applications and give you the chance to delete them.
3. Download and install the Google Toolbar from the Google web site. It blocks ads that it knows about and gives you the option to allow them, or block them, on a piecemeal basis.

These 3 things usually clean up the system well enough to work. You might have to re-run the first 2 occasionally to keep the definitions up to date.

If there are still some rogue tasks running, causing slow response time you might have to dig a little deeper. I'll give the standard disclaimer: Editing the registry incorrectly can cause permanent damage to the operating system and render it unusable. If you decide to remove or change anything, you do it at your own risk!

Investigate the Run keys in the registry and take the appropriate action to get rid of tasks that should not be running on the system. I won't give detailed instructions for this. If you don't feel comfortable doing it, DON'T. Ask for expert help:

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
• There might be other Run keys to check; I declare this an incomplete list.

Roaming Profile Blues

Problem: The user couldn't logoff due to her user profile exceeding the roaming profile size limit. She attempted to delete some profile data but never got the size down under our 30 MB limit. So, she simply turned the machine off. Not good.

Solution: We moved her working data from her Desktop and My Documents folder to her mapped network drive. We also, deleted lots temporary internet files. This got her below the 30 MB limit and able to logoff gracefully. Tip: If you're having trouble determining the size of directories for tasks like this, download the free copy of Treesize from Jam Software. The free version will allow you to quickly see the size of directories on any local drive, listed in direcotry tree format. Then you can go about deleting as necessary.

Same User, New Domain

Problem: User needed to be moved from one domain to another, while preserving all profile settings and files from network drives. The move also included moving the user from one Exchange server to another as an Outlook client.

Solution: For the purpose of this example, assume that the old domain is named X and that the new domain is named Y. Also assume that the user does not have a roaming profile. Finally assume that the administrator performing the move has at least read access to the network drive(s) in the X domain. Then do the following:

1. From the Y Domain administrator's workstation or server....
2. Define a userid in the Y domain named the same as the user in the X domain, and set up the appropriate logon script.
3. Create a personal directory for the new user in the Y domain.
4. Map the user's X domain drive(s) and copy the contents to the new directory in the Y domain.
5. From the user's workstation.....
6. If the user doesn't have administrative access to the machine, grant it now even if it's only temporary.
7. Have the user logon to the X domain as normal.
8. Go to the Control Panel "Mail" icon and look for any data file definitions. If any, make sure the files are on the local C: drive. If not make a copy of them, saving them somewhere on the C: drive. Get out of the Mail dialog.
9. Launch Outlook and export all mail, calendar and contact information from the server to a local .pst file. Then get out of Outlook.
10. Make sure you know the local Administrator's password at this point or you won't be able to logon after the reboot.
11. Go to the My Computer properties, Computer Name tab and change from the X domain to some tempory workgroup name. Before rebooting you can also change the computer name at this point, to the Y domain standard, if necessary (saves you one reboot if you do it now).
12. After the reboot, logon as the local administrator.
13. Go to the My Computer properties, Computer Name tab and change from the temporary workgroup to the Y domain. Before rebooting, add any users or groups from the Y domain desired to have administrative access. Reboot.
14. After the reboot, have the user logon to the Y domain.
15. Launch and configure Outlook to access the new Exchange server. Import the saved .pst file into Outlook. Get out of Outlook.
16. Copy the user's profile information from the userid.X to userid.Y. If you don't want to copy all the profile information, you must copy at least the following directories: Desktop, Favorites, My Documents and the Outlook stuff (path: C:\Documents and Settings\userid.X\Local Settings\Application Data\Microsoft\Outlook)
17. Go to the Control Panel "Mail" icon and configure any data file definitions as they were on the X domain. Get out of the Mail dialog.
18. If the user previously had any shortcuts pointing to the old network drives, these of course will no longer work. Make new shortcuts pointing to the new network drive(s).

That should do it....

SP2 - I Love You

Problem: Windows XP with Service Pack 1 installed had a very annoying problem. Most of our users store their data on network drives; we not only encourage this, but demand this to avoid the probability of them losing all their local data when their machine goes South. With SP1 installed, it was taking 30-40 seconds to access a network drive at least the first time they opened it any given day. The access time varied depending on the speed of the server hosting the network drive, but it was never instantanious. Microsoft never admitted that this was a bug (at least I never saw it if they did). The delay was somehow associated with a security fix that was part of SP1. Now, I agree that security fixes are very important, probably much more important than response time, but this fact didn't make the response time issue any less annoying. Sorry. Anyhow, if you have this problem.....

Solution: Apply SP2. Thanks Microsoft!!

Editorial Comment: This one might seem nit-picky if you never saw the problem. However, consider this. If I had a $1 for each hour that I and others (thinking globally, now) spent on trying to resolve this, AND another $1 for each of the accumulated hours all the XP users with network drives spent waiting to access their data, you wouldn't have to listen to me bitch anymore. Wouldn't that be nice??

Automated Software Installation

Problem: It's hard to call software installation a "problem" anymore. It has gotten very easy over the past few years. Today, it's mostly a snap. But, as easy as it is, if you have to install the same load of software on lots of machines, it can be very tedious. Today I had to install the same four products plus multiple upgrades for each product on 15 machines. UGH! It took me several boring hours. Unfortunately, most installations still require some interventions/decision making during the install, so you usually can't just start them and walk away. There's got to be a better way. There is.....

Solution: This is not a comprehesive study of how to automate software installation. I'm sure that if you're into this full time you can find any number of products for sale on the market to help with the automation. I'll only talk about one way that I have used to automate the process, that's sort of quick and dirty, but more important....it's FREE. I like free. The product I use is Auto-It from Hiddensoft. In a nutshell, Auto-It is a fairly simple scripting product that allows you to:

• Execute programs (DOS commands and others)
• Send keystrokes and mouse clicks
• Conditonal processing
• Manipulate windows and check window status
• Some clipboard functions
• Read from and write to the registry
• Manipulate strings and variables

For example: Say you have some software to install that requires some different settings based on the OS it runs under. It uses some number of windows to prompt you for information, not only yes and no stuff, but installation paths, registrations numbers, radio button options, check boxes, etc. Furthermore, the software requires that previous releases be removed first and also depends on prerequisite software that is not part of this package. Finally, it requires a reboot of the host system at the end of the process.

Auto-It can handle all these things.

To continue the example, the script can read the registry to determine which OS is running on the target machine and save the information in a variable to be used later in the script. At the same time it can check the registry for prerequisite software and do conditional processing based on what it finds (stop the process? Issue a message? Install the prereq? etc.). It can also kick off an uninstall process for previous releases, if necessary. Once the preliminaries are done, the script can then start the install process and watch for windows/dialog boxes that need other information. When information is needed the script can fill in boxes, press buttons, etc. When the script senses the end of the install dialog, it can force a reboot. AND, if this isn't enough, you can also compile the script into an executable so you don't need to have Auto-It installed on the machines where you need to run the script!

Very slick and easy to use! Of course, you wouldn't want to bother writing a script unless there is some level of complication in the process, or unless you have lots of mind-numbing installations to do. I sure could have used one today...... :o(