Downloads
8844.zip

\[Editor's Note: Share your Windows 2000 and Windows NT discoveries, comments, problems, solutions, and experiences with products and reach out to other Windows 2000 Magazine readers (including Microsoft). Email your contributions (400 words or less) to r2r@win2000mag.com. Please include your phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]

Win2K AS Installation Workaround
To test Windows 2000, I upgraded the RAM on my PC to 128MB and bought a Quantum 10.2 CX hard disk. However, my PC's BIOS didn't support a hard disk larger than 8.4GB, so I had to download from the Quantum Web site disk manager software that lets my system support a larger hard disk.

When I tried to install Win2K Advanced Server, I could complete only the first round of installation. When I rebooted to complete the installation, the system presented the following error message: Windows 2000 could not start because the following file is missing or corrupted: <Windows 2000 root>\system32 \ntoskrnl.exe. Please install a copy of the above file. When I reinstalled, the system presented me with the same error message. After some experimentation, I discovered the following solution:

  1. Install Win2K AS, and leave the boot partition as FAT rather than NTFS. (You can convert the partition after you complete the installation.)
  2. After the first round of installation, Win2K will prompt you to reboot. After reboot, the previous error message will appear.
  3. Prepare a bootable 3.5" disk that contains edit.com and attrib.exe.
  4. Boot from the disk.
  5. At a command prompt, type
    attrib -R -H -S c:\boot.ini
    Boot.ini is in the C drive and will have the following settings:

    \[boot loader\]
    timeout=1
    default=scsi(0)disk(0)rdisk(0)<br>
    partition(1)\WINNT
    \[operating systems\]
    scsi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Advanced Server" /fastdetect
  6. Use the editor to change the word scsi to multi in the second line of the \[boot loader\] section and the first line of the \[operating systems\] section:
    \[boot loader\]
    timeout=1
    default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
    \[operating systems\]
    multi(0)disk(0)rdisk(0)partition<br>
    (1)\WINNT="Microsoft Windows 2000 Advanced Server" /fastdetect
  7. Save the changes to boot.ini.
  8. At a command prompt, type
    attrib +R +H +S c:\boot.ini

    This command adds read-only (R), hidden (H), and system (S) attributes to the boot.ini file.

  9. Reboot, and you'll be able to complete the Win2K AS installation.

Outlook Express New Messages
To force Microsoft Outlook Express 5.0 to check for new messages automatically, go to Tools, Options, and on the General tab select the Check for new messages every: check box. (If you connect to a mail server through a modem, you might also want to select the Connect even when working offline and Hang up after sending and receiving check boxes, which tells the system to hang up after downloading mail.) Then, you just have to tell Outlook Express how often you want to dial out. I'm away from home most of the day, so I want Outlook Express to dial out every 12 hours. However, if you enter a value greater than 480 minutes (i.e., 8 hours), the system presents you with the message Please enter a value between 1 and 480.

To work around this problem, you can modify the Registry. Navigate to the HKEY_CURRENT_USER\Identities\your identity number\Software\Microsoft\Outlook Express\5.0\Mail Registry key. (If you're not using multiple identities in Outlook Express, only one subkey will exist under the Identities key.) For every minute you want to increase your autodial time, add 60000 (in decimal) to the Poll For Mail binary Registry value. You must close Outlook Express and relaunch it for the Check for new messages every: 720 minutes option to appear.

Automatically Launch Applications on WTS


Suppose you're deploying a Windows NT Server 4.0, Terminal Server Edition (WTS) centralized application for 80 users. When users log on to the WTS system, the default application will launch automatically and users can work only on the application that you deploy.

To accomplish this deployment, at the RDP-connection configuration level, you can set a command-line batch file for all the users. However, when you set the RDP configuration initial program, WTS applies the program to anyone who connects to the server from a WTS client or connects remotely. What if you don't want the application to automatically launch for an Administrator or power user?

To solve this problem, I placed the Microsoft Windows NT Server 4.0 Resource Kit Supplement 4 ifmember.exe utility in the \%systemroot%\system32 folder. Then, I gave the Everyone group Change permissions.

Next, I wrote a batch file, which Listing 1 shows, that launches the application automatically. If a user who logs on to the WTS system belongs to the Administrators group, the system doesn't automatically launch the application. I placed the batch file in a folder that all users can reach, and I applied Change NTFS permissions to the Everyone group. As Listing 1 shows, the file determines whether the user is an Administrator. If you're an Administrator, the system presents you with an open desktop. If you're not an Administrator, the system launches the application automatically and you must work from that application.

After the batch file and all necessary components are ready, you must set up the WTS RDP configuration to launch the batch file. To do this, go to Start, Administrative Tools, Terminal Server Connection Configuration. Double-click your default RDP connection, click Advanced, then click Advanced Connection Settings. Under Initial Program, clear the inherit client/user config check box and type the batch file's path in the text box. Click OK, and the system will apply the changes to the WTS system. The next time a user logs on to the WTS system, the batch file will launch and the application will automatically start.

Another Method to Detect RAS at Logon


In Reader to Reader: "Detecting RAS at Logon" (December 1999), Terry D. Brashley lists three methods that let Windows NT logon scripts test whether a connection is dial-up RAS. I discovered another alternative. I wrote two C++ programs, chkrasnt and chkras95, which you reference in clients' logon scripts (Listing 2 shows an example logon script reference). I used Microsoft Visual C++ (VC++) 4.01 as a Win32 console application to develop both chkrasnt and chkras95, and I linked chkrasnt with rasapi32.dll. When compiled, each script is about 20KB.

First, as Listing 2 shows, I added a section to clients' logon scripts that determines whether to run chkrasnt or chkras95 based on whether the OS environment variable is set. The OS environment variable exists only when a system is running NT, so if the variable exists, the logon script tells the system to copy chkrasnt from a network share to the client's local hard disk. (Otherwise, the logon script tells the system to copy checkras95 from a network share to the client's local hard disk.) Setting the logon script to copy the file and run it locally trims about 15 seconds off the logon time, compared with running the executable file from the Netlogon share on the network across a RAS connection.

If a RAS connection exists, chkrasnt or chkras95 will set ERRORLEVEL to 1. You can run either file with a command-line argument (e.g., chkras95 /?) to display a minimal Help screen. Chkras95, which Listing 3, page 28, shows, works by reading the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Remote Connection Registry key to determine whether a RAS connection exists. If the number of RAS connections is greater than 0, the Registry key value is 1 (otherwise, the Registry key value is 0). Chkrasnt, which Listing 4 shows, uses the RasEnumConnections API call to retrieve the number of RAS connections. The API call returns a value of 1 if the number of connections is greater than 0. RasEnumConnections requires the rasapi.dll, which exists only if you've installed RAS. Thus, the logon script addition checks for the existence of this DLL before running chkrasnt.

Globally Limit Exchange Server 4.0 Mailbox Sizes


Suppose you've been running Microsoft Exchange Server 4.0 for 6 months. When you were planning and deploying Exchange services for users in your organization, disk space wasn't a problem. However, after 6 months, your Private Information Store (IS) is growing by the minute because users don't regularly clean out their mailboxes. Your one Exchange Server system hosts 450 mailboxes, and you don't have approval to buy more hard disk space. Instead, the vice president of information and systems issues a policy that limits all users' mailboxes to 50MB. How can you limit the size of users' mailboxes without manually going into each user's mailbox and setting up this limitation?

First, you must copy the mailbox.csv file from the Exchange Server 4.0 CD-ROM (under \support\samples\csvs\mailbox) to an administrative workstation running Microsoft Excel and Microsoft Exchange Administrator. Start the Exchange Administrator program, connect to your Exchange Server system, and go to the Site Container\Configuration\Servers\YourServer\Server Recipients container. In the right pane, you'll see all your current users' mailboxes. From the Exchange Administrator program, select Directory Export from the Tools menu. Next, in the Directory Export dialog box, select your Exchange Server from the drop-down menu, then select the home server from the drop-down menu. Click Export File, and input the path to the mailbox.csv file. Click Container, and select your recipients' container from the drop-down menu. Leave the default settings for the Export objects, Logging level, and Character Set sections, and click Export.

After Exchange Administrator completes the export process, start Excel and open the mailbox.csv file, which contains all users' object information. Delete the title text under the CO, CN, and CM columns. To set up mailbox storage limits, enter the values in kilobytes to the following columns:

  • AZ: Incoming message size limit
  • BC: Issue warning storage limit
  • BO: Outgoing message size limit
  • BW: Prohibit send storage limit

Save the file.

From the Exchange Administrator program, select Directory Import from the Tools menu. In the Directory Import dialog box, select your Windows NT domain from the drop-down menu, select your Exchange Server from the drop-down menu, click Import File, and locate the saved mailbox.csv file. Select the Overwrite option in the Multivalued Properties section, then click Import. When Exchange Administrator completes the Import process, verify that your storage limits took effect.

Answers to This Month's Reader Challenge
You can find this month's Reader Challenge on page 25.
The correct answers to the questions are as follows:

  1. B
  2. B
  3. A