Windows nt - NT know-how

- Sticking with it

Linda Davies and a few others have asked about driving a joystick under Windows NT, although I can't imagine what work they could be doing that requires a joystick. The good news is that there is a joystick driver for Windows NT, which you'll find on the original Windows NT Workstation CD, and it works with any standard joystick port such as those you find on sound cards.

To install it, go to the Multimedia Control Panel, select the Devices property sheet and click Add. Choose Unlisted or Updated Driver, click OK, then select Browse, and navigate to /drvlib/multimed/joystick/x86 on your CD-ROM drive (Fig 1).

If you need anything beyond a basic joystick driver and there isn't one for Windows NT included with it, then you're probably stuck.

Of course, after installing any driver from the original Windows NT CD-ROM drive, you must re-install your latest service pack.

- Five alive!

Service Pack 5 will have been out for some time when you read this; it came out relatively quickly after Service Pack 4. Service Pack 5 doesn't include any new features: it's purely bug-fixes, including some more Year 2000 fixes. However, you don't need to upgrade to SP5 for Year 2000 compliance: SP4 will be maintained by Microsoft at the 'compliant' rating.

You may decide to skip SP5, if you have no particular problems. As always, the introduction of a service pack can itself cause difficulties.

One of Microsoft's greatest problems is the lack of any consistent policy towards installation order, and the fact that DLLs get overwritten gratuitously when they shouldn't be. This could go some way to explaining the problems that people have been experiencing when adding SP5 to a system that already has IE5. In particular, the automatic dial-up network in response to typing a URL into IE5 doesn't function correctly. Although the dial-up connection takes place, IE5 then complains that it can't access the page, although quitting IE5 and restarting it is fine.

The answer here is to install Windows NT first, then dial-up networking, then SP5, and finally IE5. If you are already in this situation, a re-installation of IE5 may help.

A few of the more interesting bugs that SP5 cures are as follows. Following an installation of SP4, Microsoft Exchange Internet Applications and Services may stop working, and produce errors such as 'Register LDAP SSL protocol failed with error 10049. The LDAP SSL server is not available. Make sure port number 636 is not used by another application', within the event viewer. This arose because SP4 caused NDISWAN services to return IP addresses in the order in which they are bound, so IP addresses not currently bound to the TCP/IP stack were returned when making a call to the Winsock API function GetHostbyName().

Another problem arose because of several quality improvement fixes to the DHCP (Dynamic Host Configuration Protocol) server. One of these was to check for database records that contain out-of-scope IP addresses, but unfortunately, this included legal out-of-scope reservations, resulting in clients that match those reservations no longer receiving IP addresses from the server.

Another strange one was that SP4 installation would not update MTS (Microsoft Transaction Server) files if they weren't in the default directory of /Program Files/MTS.

- Driving you crazy

Mark Eidem writes concerning a new Windows NT and BackOffice installation, on a system that has two physical hard disks (actually, each is a RAID unit) of 4.3Gb and 18Gb, and asks whether there is any merit in splitting these disks into smaller partitions. He plans that Windows NT will use the 4.3Gb disk, and the BackOffice applications the 18Gb disk.

Specifically, he is keen on the idea of a separate partition for the page file, and also wants to split the larger disk into several smaller partitions of 2Gb to allow each application to have its own drive (Fig 2).

My first advice would be to thoroughly examine the various Microsoft documents. In the SQL Server instructions at least, you'll find a recommendation to keep different files on different physical spindles (disks), for performance reasons. For that same reason, keeping the paging file on a separate disk is also a good idea; three physically separate spindles would be a good idea at the very least. Exchange should probably also have its own physical disk, too.

But for NT there's absolutely no merit in partitioning a large disk into smaller units. Firstly, that would involve a fair amount of work in planning, designing, implementing and maintaining several partitions. Every activity, from defragmentation to backing up, will be made much more complicated.

And unless your estimates are spot-on, one of the partitions will run out of room before the others, resulting in a painful reconfiguration exercise; and overall, you'll be wasting hard-drive space.

My advice would therefore be to never bother to split up hard disks at all, and go for one single, large NTFS partition on each, but do take care about what you put on each disk.

- School daze

Graeme Gerrard wants to know if there's any way of preventing the users at his school from seeing the C: drive when running Windows NT Explorer.

The good news is that there is, using System Policies (Fig 3). I've covered System Policies in depth before, so I won't go into the detail of setting it up, but the specific setting you want here is NoDrives. It's a binary value, with one bit for each drive, so to hide drive C you would set this to the hex value of 0x00000004. If you want to hide all 26 drives, then you'll need the hex value of 0x03FFFFFF.

You probably won't find NoDrives at HKEY_USERS/User Name/Software/ Microsoft/Windows/CurrentVersion/Policies/Explorer, so you'll have to create a new DWORD value.

Another problem Graeme reports is that of default (home) directories.

Setting them isn't the problem; rather, the issue is one of configuring applications so that the default data directory is the user's home directory.

Many applications, such as Microsoft Word, can be installed so that this is indeed the case, but not all.

There isn't really a perfect answer to this. It may help to map a drive letter to the users' home directories, but that won't modify applications to use it - although it will make it easier for users to navigate to their home directory.

The next step is to set this drive as the default drive when users log in; those applications that simply use the currently logged drive may be helped by this procedure. But if an application always starts up in (say) its own program directory, there isn't much you can do but accept the fact that users will always have to navigate to their own home directory.

Be aware that configuring a home directory in the User Manager doesn't achieve much: you still need a 'net use h:/home' command, to connect drive H: (for example) to the home directory. Unfortunately, this is a pretty useless command, because H: actually becomes the root of all home directories. To set H: to the user's individual directory, you'll need a more sophisticated command such as the following:

net use h://VEGAS/%username%

This will only work if the user's home directory has been set up as a share, however.

- Camera action

A quick update on camera hardware with Windows NT 4.0, from George Hood.

He writes in to say that he's successfully used a few camera and video products with NT, including the Hauppauge Win TV capture card and CCD camera package, using drivers from the Hauppauge web site - even though the documentation doesn't specifically say it works with NT. He's also used the Creative Labs Webcam II, but doesn't recommend it, owing to hardware sensitivities and loading on the parallel port. He reports successful results with the Winnov Videum card and camera package , which is available from Technomatic in the UK.

- Time, please

There's been a flurry of interest in setting up the time across a Windows NT Network: first, in fetching the time from a reliable time source, and second, in propagating the time across the network.

There's already technology built into Windows NT to allow the time to be sent and read across your network. First, you have to decide which PC is going to act as the time server on your network.

Then, using REGEDIT, navigate to HKEY_LOCAL_MACHINE/System/Current Control Set/Services/LanManServer/Parameters and make a new DWORD parameter called TimeSource with the value 1.

You'll need to reboot that PC before the change will take effect. Now that that PC has been configured as a time server, you can configure the other PCs to set their clocks from it. Somewhere (in a logon script, a batch file in the startup program group, or as a scheduled command using the AT service) set the other PCs to run the following command:

net time/set/yes

The first thing you'll notice is that this won't actually work for most users. That's because you need administrator rights in order to set the time - but you can change this requirement, if you dare (Fig 4). Go to the User Manager (or User Manager for Domains), select the Policies menu and choose User Rights. In the drop-down list box, select the right to Change The System Time. To grant this right to members of the User group, click Add, then highlight Users in the dialogue box that pops up, and then click Add again followed by OK. Back in the User Rights Policy dialogue box, click OK again.

Many third-party utilities are available to accomplish the same thing, and you may find them more convenient to use than the above procedure.

K9, companion program to Tardis, is just one example.

Next, you face the problem of setting the time accurately on your master PC. There are also plenty of programs around to achieve this, and one of them, TIMESERV, is included in the resource kit. However, when I tried it, not only did I find the TIMESERV.INI file format a little complicated, but it also stuffed up my system by sitting there and consuming 100 percent processor resources.

A shareware utility that works well is Tardis, available from www.kaska .demon. co.uk as shareware (Fig 5). If you wish to buy on-line, a credit card can be used at www.ebarn.com.

Single copies are $20, but the price goes down to as little as $2.50 in volume.

Compared to TIMESERV, Tardis is simplicity itself - you just run it. About the only options you'll need to change are how frequently it fetches the time, and whether it should watch for a dial-up networking connection. By default, the time is checked every two hours.

Tardis is available as a standalone program for Windows NT or 95/98 and also as a Windows NT service. Note that Tardis itself can act as a time server (so you don't set the TimeSource registry value). Normally, you'd use Tardis to fetch the time from the internet, but you can also use it with GPS receivers.

If you have the resource kit and you're brave enough to try TIMESERV, then the following values may work for TIMSERV.INI. Period is the number of times a day to set the time, and timesource=yes appears to have the same effect as setting a TimeSource registry value as described above.

(TimeServ)

Type=NTP

Period=1

NTPServer=ntp.cs.strath.ac.uk

timesource=yes

Log=yes

There's a list of public primary NTP time servers at www.eecis.udel.edu/~mills/ntp/clock1.htm; with TIMESERV, you only seem to be able to specify one. Tardis, on the other hand, comes preconfigured with a long list, and will automatically use the next one on the list if it encounters a failure (or success).

AN INSPECTOR CALLS: BOOT SECTORS

Andy Baker reports a problem with the master boot record (MBR) on an NTFS Windows NT hard drive, trashed by a failed installation of Red Hat Linux.

In theory, the emergency repair disk ought to fix the boot record: there's an option called Inspect Boot Sector.

By the way, if you don't have an up-to-date emergency repair disk, now's the time to create one, using the RDISK utility - unless, like me, you have a registry that's too large to fit on a single floppy disk. You might still be able to use a repair disk, however, by pointing it at your /repair directory - assuming your drive is still readable.

However, Inspect Boot Sector won't work if it realises that the boot sector has been overwritten legitimately by another operating system: it simply won't interfere with it. This would normally be correct behaviour, since you wouldn't want the NT emergency repair procedure to overwrite a valid boot sector or you'd no longer be able to boot the other operating system.

Andy found the way round this problem was to overwrite the boot sector using MS-DOS 6.2 and FDISK, which has a/MBR option to overwrite the boot sector. Then the emergency repair procedure was happy to overwrite it with the correct NT boot sector.

Andrew Ward welcomes your comments on the Windows NT column. Contact him via the PCW editorial office or email NT@pcw.co.uk.

Like this story? Spread the news by clicking below:

 del.icio.us     Digg this     reddit!