Professor Windows - January 2002

  • Article

By Yossi Saharon

Reviewed by: Doug Allen, Microsoft Product Support Services
Edward Gomes, Microsoft Product Support Services

Introduction

Do you know that feeling when you read about a helpful tip somewhere or come across a cool tool, and you think for yourself: Wow, this could have saved me a lot of time that other day … Well, I do too, and since the introduction of Windows 2000', along with the directory services in the Microsoft Windows® 2000 operating system, the Active Directory, I have collected and shared a few of those tips that I picked up from my field experience with Microsoft partners.

Since I understand that tips are the administrator's best friends, I have written down a few below that sure did help me out when I was at a customer site. This column discusses some of these time-saving tools & tips, which emphasize making our job easier when running Windows 2000 Servers and Workstations, especially with Active Directory around.

Printers Deployment

We all know by now that Windows 2000 has some helpful enhancements for handling printer configuration, such as the Web page for managing printers and print jobs at http://machinename/printers, searching for printers from the Start | Search | For Printers in an Active Directory environment, and simply choosing "Connect" or double-clicking that printer from the search result to install it, and many others.

Yet, configuring and deploying printers for Windows 2000 can take a while if you're not familiar with the tools that the Windows 2000 Resource Kit has to offer.

The first script that comes in handy from the resource kit is prnmgr.vbs. This script can be used to create/add a printer to a machine from the command line, including specifying its driver, location etc. The basic syntax is:

cscript prnmgr.vbs -a -b "My new printer" -m "HP LaserJet 4M" -r "lpt1:"

This will create a new printer for an HP LaserJet 4M driver on LPT1.

Notice that when running from the command line you need to add the cscript.exe command before the vbs file. Cscript is the command line implementation of WSH (Windows Scripting Host), a controller that is used to run scripts in the Windows 2000 environment. You can use prnmgr.vbs from the command line to configure printers remotely on machines in your organization, as well as running the command from your Login Script and automating the creation of printers through the login process.

Another helpful script is called clone.vbs. Clone.vbs can be used for cloning printers from one machine to other machines. This can be useful when you want to have the same printer(s) for a large amount of machines. It's like a "SysPrep" mechanism for printers, in a way. You can try it:

  1. Go to a workstation and configure all the required printers on that machine (or simply use prnmgr.vbs).

  2. Then go to the command-line and run from the resource kit directory: cscript clone.vbs /?

    and explore the different options you have there to clone the printer's drivers, ports, forms etc. Clone.vbs creates the required script(s) and batch file to clone the printers later, and it defaults to the current directory, which might be \program files\Resource Kit. You might want to copy the clone.vbs file to an empty folder somewhere before actually running the command to create the cloning scripts.

  3. Next, run the clone.vbs script with the desired options. When finished, take a look at the script(s) it created for each printer installed on this machine, along with the batch file that was created to be used for automatically running all the script(s) that were created in a row. If you go to another machine and run the batch file (or each of the individual scripts created) it'll automatically create the printers that were installed on the original machine, along with the information you specified to include (like the printer's port or driver).

The Windows 2000 Resource Kit has some other tools that you might want to check out as well for the purpose of printer configuration and deployment (e.g. Prnadmin.dll).

Getting Information on Users

In addition to the UI based user management tools, there are many tools and scripts out there to help in querying, creating, modifying and deleting user objects in the directory.

You should explore the Support Tools from the Windows 2000 product CD and the Windows 2000 Resource Kit to get acquainted with some of them at least, since they can really ease your work sometimes. Here is a quick description of some of those tools:

The Windows 2000 Resource Kit offers us some scripts for handling users.

ClassifyMembers.vbs, for example, can list objects in a container/OU or a domain.

Another script that can show object properties and information is ListProperties.vbs. It can be used with the WinNT:// namespace against Windows NT, Member or Workstation machines, or with the LDAP:// namespace for Active Directory Domain Controllers. Pay attention that this script is case-sensitive in its syntax.

As for enumerating group membership, there are several tools, such as FindGrp.exe, IfMember.exe and ShowGrps.exe. Each gives different results, so you might want to run them and compare the outputs of each tool. ShowGrps.exe, for example, can also query for group membership of computer objects (Try:

FindGrp.exe <Domainname>\<MachineName>$

and see what comes out). If you want to search for users satisfying a given criteria, you can try out chkusers.vbs. This script checks your domain for users that satisfy a certain criteria that you define. For example:

Cscript CHKUSERS.VBS /A:WinNT://YourDomainName /P:FullName;Description /C:"((LastLogin:>4/3/01 or LastLogin:<8/4/01) and AccountDisabled:=False)"

This will output the full name and description of all active users whose last login was between 4/3/01 to 8/4/01.

From the support tools we can find LDIFDE.exe, which is a tool for bulk import and export of Active Directory Objects. You can use LDIFDE to import new user records into the directory, or export specific information on specific users into a text file. LDIFDE defaults to export mode (reading From the Directory). When you add the -i option it can be used to write changes into the Directory (See Microsoft Knowledge Base article Q237677: Using LDIFDE to Import and Export Directory Objects to the Active Directory

). Also, if you want to export and extract only specific details, such as the user name, title and login name for all the users in a specific OU (Organizational Unit), you can run the following command: ldifde -f C:\ldif\ExportUsers.ldf –s SERVERNAME -d "OU=YourOUname,dc=YourDomainName,dc=com" -p subtree -r "(objectClass=User)" -l "cn,givenName,Title,SamAccountName"

LDIFDE uses an LDF file format. You can read more on LDIFDE in the Microsoft Knowledge base at https://support.microsoft.com by simply searching for "LDIFDE" at the search page.

Let the Good Tips Roll . . .

Ok, now it's time for my general tip list. So let 'em roll:

  1. When you want to run the Windows 2000 Server administrative tools on a Windows 2000 Professional machine, we know you need to run the adminpak.msi file from the /i386 folder on the Windows 2000 Server CD (or on the Server itself). Hmmm.. What if I only want the Active Directory Management Tools, or just the Cluster Administrator, and not the whole bunch of MMC's? Well, you can use msiexec.exe to extract only the desired MMC Snap-ins out of the adminpak.msi file using the following syntax: msiexec /i adminpak.msi ADDLOCAL= <Abbreviation> /qb

    For Example:

    msiexec /i adminpak.msi ADDLOCAL= FeADTools /qb

    (Where FeADTools is the abbreviation for "Active Directory Tools". This will install only the three Active Directory-related MMC Sanp-Ins).

    Other abbreviations are:

    FeRRASConsole - Routing and Remote Access

    FeDHCPConsole - DHCP

    FeDNSConsole - DNS

    FeDFSConsole - Distributed File System

    FeWINSConsole - WINS

    FeTAPIConsole - Telephony

    FeACSConsole - QoS Admission Control

    FeCERTConsole - Certification Authority

    FeClusterConsole - Cluster Administrator

    FeCMAKConsole - Connection Manager Administration Kit

    FeIASConsole - Internet Authentication Service

    FeIISConsole - Internet Information Services

    FeRSConsole - Remote Storage

    FeTSClientConsole - Terminal Services Client

    FeTSMgrConsole - Terminal Services Manager

  2. If you want to create a large amount of test user accounts in your domain or local accounts on your workstation, you can use the FOR and Net User commands to accomplish the task in a "quick and dirty" way, without scripting or writing any code. For example, if you type from CMD: FOR /L %i in (1,1,500) DO NET USER MyUser%i /ADD

    This will result in creating 500 new users, named MyUser1, MyUser2, etc.

    If you want the names to be more meaningful or unique from each other, and not in a sequential order, you can also use the FOR command with /F, and specify a text file with the list of names you want to import into the domain. Obviously, this tip works also on Windows NT 4.0 domains and member servers or workstations, since it uses the backward compatible NetXXX APIs.

  3. The Windows 2000 Resource Kit is filled with different manipulation scripts. For example, to control the Services on a machine, use service.vbs. It allows you to List all services, as well as to stop, start, remove and install services.

  4. Again from the Resource Kit, if you want to manipulate shares on machines, you can use share.vbs. This script lists, creates and deletes shares on machines.

  5. Ever wondered what commands and programs are run when you startup your machine? Well, startup.vbs from the Resource Kit can list all the startup commands on a specified machine (even remotely on a different machine), including the user that runs it, and the exact syntax of the command that is run. And yes, I know we could see this information from msconfig.exe once, but Windows 2000 doesn't include this tool. The good news is that msconfig.exe is back on Windows XP Professional.

  6. If you run Windows 2000 or Windows XP Professional, you can publish printers into the Active Directory when you add a new printer. But what if you want to publish printers in the Active Directory from non-Windows 2000 machines? (e.g. Windows NT 4.0 members, or Windows 98). You can publish printers shared by versions of Windows other than Windows 2000 or Windows XP using pubprn.vbs. If Windows Scripting Host is installed, you can find this script in the System folder.

    For Example:

    cscript pubprn.vbs ServerName "LDAP://ou=MyOrgUnit,dc=MyDomain,dc=com"

    This will publish all printers from a given machine (specified with ServerName) into the specified Organizational Unit in the Active Directory Domain Tree. More information on how to use and obtain pubprn.vbs can be found in Microsoft Knowledge Base article Q234619: Publishing a Printer in Windows Active Directory

    .

  7. If you get tired of going into "Active Directory Sites & Services" every time you want to perform the action of "Replicate Now" to trigger replication between Domain Controllers, you can try out RepAdmin.exe from the Windows 2000 Support Tools by using the following command: repadmin /syncall /p /e /d servername.domain.com /u:%account% /pw:%pwd%

  8. You can run and kill processes from the command-line using the Windows 2000 Resource Kit tool exec.vbs. For example, running: cscript exec.vbs /E calc

    will create a new process of the Windows Calculator on your machine. You can use it to run processes on remote machines as well. If you want to kill a process, you can run:

    cscript exec.vbs /X ProcessIDNumber

    The Process ID Number can be obtained by using ps.vbs, which lists all the processes and their ID's. For the purpose of running and killing processes you can also use similar tools from the Windows 2000 Support Tools called TList.exe and Kill.exe. Tlist.exe is equivalent more or less to ps.vbs (lists processes), and Kill.exe is the same as running exec.vbs /X.

  9. And while we're dealing with Processes, you can use top.exe from the Resource Kit to watch your machine processes in real time from the command window. Simply run top.exe, and launch a new process, or move your mouse vigorously, and you'll notice the change inside the command window.

  10. By Default, many diagnostics events are turned off in order to prevent populating your Event Viewer heavily. Yet, for troubleshooting purposes, you might want to turn many of those Active Directory related events on (e.g. for Replication, LDAP operations, etc.). You can look in your Domain Controller's registry settings under: HKey_Local_Machine \System \CurrentControlSet \Services \NTDS \Diagnostics.

    There you will find the different diagnostic events that you can turn on by modifying the setting to 1 (Enable).

  11. Speaking of events, what if you could log your OWN event(s) into the event viewer, specifying your own custom event source and description? Well, you don't have to be a developer in order to do that. You can use another Resource Kit tool named LogEvent.exe. Try running the following command: logevent -s I –r "Test" "THIS IS A TEST"

    Open up your Application Log, and you'll see a new event of type Information from source "Test" with the description of "THIS IS A TEST" inside the event details. You can play around with the event type, ID, category number, etc. Simply run logevent.exe /? and explore the different options. You can use it, for example, from your login script or any other organizational operations in order to log your custom event into a specific machine's event log.

  12. Want to open up the MMC of a local Group Policy on a remote machine? Simply go to Start | Run and type: gpedit.msc /gpcomputer: "Computername"

    (Where computername is the NetBIOS name of the remote machine).

That's it for now. I'm sure there are many more I could add, but I hope these will be helpful for you and will ease your Windows 2000 management.

For any questions or feedback regarding the content of this column, please write to Microsoft TechNet at technet@microsoft.com

.