What the Future Might Bring

What will the user experience be like on a Win2K desktop?

Microsoft will soon ship Windows 2000 (Win2K), although I'm not sure of an exact date because prognostication isn't one of my specialties. If you've already started your evaluation of Win2K, you're probably a little sick of this new OS by now. If you haven't looked at a Win2K beta, you're probably wondering what all the hoopla is about.

Although some administrators have started to evaluate Win2K for deployment within their organizations, the vast majority of Windows users are still on Windows 9x. And although many of our readers are running Windows NT Workstation, the most common Win2K end-user migration path will still be from Win9x.

On the surface, this migration doesn't seem like a big deal. After all, the benefits that Win2K on the desktop will bring to the network administrator in terms of end-user control and configuration are somewhat significant. The security that network administrators can put in place on a Win2K or an NT workstation means that they can tightly control their networks and the desktops attached to them.

Even though the systems administrators will appreciate moving their users off (let me steal a term from Windows NT Magazine columnist Mark Minasi) Wintendo, what will the user experience be like with Win2K on the desktop? Microsoft claims that the user experience for the Windows family of OSs is similar enough that users will have only a few—if any—transitional problems. I've started to hear stories from readers about a variety of NT-related problems, ranging from users who follow directions too well to users who can't get their applications to work. As NT Workstation and Win2K Professional (Win2K Pro) become the desktop standard, more of these problems are likely to crop up.

Following Directions
I've used NT for a long time, but I must admit that I haven't run into the problem one reader described. This administrator had sent a new NT 4.0 system to a remote site and was surprised to learn that the user who received the system was unable to log on. After unsuccessfully dealing with the problem using the standard over-the-phone support, the administrator had the user pack up the computer and ship it back to the main office.

After unpacking the system, the administrator found no problems with it. The administrator was able to log on to the system and execute applications using administrative rights and the user profile of the person the administrator had configured the system for.

Thinking back to his conversation with the user, the administrator recalled that the user had said nothing happened when he pressed the Ctrl, Alt, and Delete keys together. So, the administrator locked the workstation and attempted to unlock it by pressing the Ctrl, Alt, and Delete keys simultaneously (instead of the Ctrl+Alt+Del key combination). Nothing happened.

Apparently, the way that the computer processes the keyboard interrupt prevents that particular keystroke from working. Try pressing the Ctrl, Alt, and Delete keys simultaneously. This action won't work for you either. And I have to admit that in all my years of using NT (and all other Windows versions for that matter), I had never hit those keys simultaneously for the three-finger salute. Pressing the Delete key concurrently with or in advance of the other keys creates the problem. Pressing the Ctrl key, adding the Alt key, then adding the Delete key, or pressing the Alt key, adding the Ctrl key, then adding the Delete key works fine. Pressing the Ctrl and Alt keys simultaneously, then adding the Delete key also works. And you don't need much of a delay between pressing these keys to make the sequence behave in the manner you expect. If not for that user, who was previously a Win9x user and was a little too good at following the direction Press Ctrl+Alt+Delete to log on, I wouldn't have come across this little peccadillo.

The reader who sent me this tale seemed amused at how the problem unfolded. But I'm willing to bet that this administrator would have lost his good humor if this problem had been repeated 50 or 100 times by other users.

We Don't Trust You
This story came from a neighbor who is an executive with a Fortune 100 firm. His company has used NT for quite a while, and this past year the company started to put NT Workstation 4.0 on all the employees' notebook computers. As a senior executive, my neighbor receives fairly quick resolutions when he has IT-related problems. However, the following problem didn't have a quick resolution and really set him off—enough so that he stopped by my house to complain about it to me (knowing what I do for a living).

The problem occurred when my neighbor was at a customer site—brought in as the big gun to get some contracts signed. While he was at the site, he needed to make some last-minute changes to the contracts. So, he popped open his notebook computer, made the required edits, and went to look for a printer. The customer's printers weren't the same as those at my neighbor's work site or at his home, but he wasn't concerned; he had the NT 4.0 distribution CD-ROM with him and presumed he would just install the appropriate printer driver and be able to print to the customer's printer.

The time was well after 8:00 p.m. on a Friday before a holiday weekend, and being moderately technical, my neighbor found a printer and plugged in his notebook computer. He inserted the NT CD-ROM into his computer and started to add a printer. Then, he discovered that his user account didn't have authorization to add printers, and he didn't have the administrator password. Given the time of day and the pending holiday, no one at the office (or at the 24 X 7 Help desk) knew or had access to the administrative account for his notebook computer.

To make matters worse, the customer was a WordPerfect shop, and my neighbor had the latest version of Microsoft Word on his computer. He saved the contracts as an earlier version of WordPerfect so he could email the contracts to the customer and the customer could print them. But saving the contracts as WordPerfect documents resulted in a formatting mess.

My neighbor and his customer ended up not signing the contracts until after the holiday, a delay of 4 days. My neighbor said the company's security policy cost the company about $4 million because of the delay. He told me that nobody lost his or her job over this incident (and I believe him) but only because the IT director who originally put the company's notebook security policies in place had already left the company. The IT director decided that end users don't need the ability to add printers, and no one questioned the policy until the policy became a problem.

If the notebook computer had been running Win9x instead of NT Workstation, the problem wouldn't have occurred. This story foretells the problems to come as administrators upgrade Win9x users to Win2K on the desktop.

What to Do, What to Do
I've heard a few dozen more stories related to new NT Workstation users. But these stories tend to fall into two categories: concerns from users who don't get the behavior with NT that they had with Win9x, and problems with configuration and security settings that cause user and application problems.

As you begin to deploy Win2K throughout your enterprise, taking a long, hard look at how Win2K will affect the network and its administration will be crucial. You will also need to examine the effect from the end-user perspective. What effect will this upgrade have on your users and how they perform their jobs?

The tight integration of the client into the Win2K network enterprise will make these considerations more crucial than they have ever been in the past. And I know quite a few network administrators who have never really given their client systems much thought. However, this tendency won't be the case in Microsoft's brave new OS world.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.