

I'm having problems with the last two lines in Listing 1. As they stand, they work fine. But when I preface fil.DateCreated and fil.DateLastModified with text in the code

WScript.Echo("File created on " _
   + fil.DateCreated)
WScript.Echo("File last" & _
   "modified on " + _

I receive the error message C:\Scripts\files.vbs(11, 1) Microsoft VBScript runtime error: Type mismatch: '\[string: "File created on "\]'. I can't figure out why. Can you help?

The error you're seeing is the result of using the wrong operator to concatenate different VBScript subtypes. VBScript's string concatenation operator is the ampersand (&), not the addition (+) operator.

What's interesting about your example is that the addition operator works in the first two WScript.Echo statements but not the second two statements. Here's why. The fil.Path and fil.Name variables and the text that prefaces fil.Path and fil.Name are all String subtypes. In these two statements, VBScript can concatenate the strings because all the pieces are of the String subtype.

However, when you preface the fil.DateCreated and fil.DateLastModified variables with text, you're trying to concatenate String subtypes with Date subtypes. When the VBScript interpreter sees the addition operator, it converts the Date subtype to an Integer subtype then attempts to add the integer to the string. The result is a type mismatch because you can't add a number to a string. Replacing the addition operator with the concatenation operator causes VBScript to convert the Date subtype to a String subtype. VBScript can then glue the substrings together. So if you change the addition operators to concatenation operators, you can successfully add text to the last two statements in your script. (For more information about VBScript operators, see Dino Esposito, "Understanding VBScript: Operators," August 1999.)

I'm designing a Windows NT 4.0 rollout for a company that wants to deploy a standard image to 130 desktops. This deployment must be hands-off. The company currently has IBM's LANClient Control Manager (LCCM) and Wake-on-LAN managed PCs that I can use to multicast the NT 4.0 image to the desktop. However, how do I automate changing the computer name and joining the workstation to the domain after the new image boots?

You can use Windows Script Host (WSH) 2.0 and Active Directory Service Interfaces (ADSI) 2.5 to automate changing the computer name and joining the domain. WSH and ADSI must be part of your standard NT 4.0 image. Here's how you accomplish these two tasks:

1. Changing the computer name. Automating the process of changing the computer name is simple. You just need to use the WSH Shell object's RegWrite method to change a few Registry values and reboot. Specifically, you need to modify the NetBIOS and TCP/IP Hostname Registry values with code similar to that in Listing 2. (This script doesn't include error-checking code.) As Listing 2 shows, you begin by declaring the variables. You then specify the paths to the Registry values you want to change. Finally, you specify the new computer name and use the RegWrite method to make the Registry changes. After you run this script, you must reboot the workstation to commit the changes. (For more information about how to use the RegWrite method, go to You can also download the executable Windows Script Host Reference at Install the documentation by running wshdoc.exe after the download is complete.)

To use this script, you need to change w-bobwells to your new computer name. Therein lies the only challenge you might face with this automation task: obtaining the new computer name. Solutions I've seen include setting the computer name to the machine's primary media access control (MAC) address or retrieving the new computer name from a local or remote configuration file.

2. Joining the domain. You can use ADSI 2.5 to create the new computer account and set the initial computer account password. The example script in Listing 3 demonstrates the process for a workstation named Hercules in the domain Olympus.

You begin this script by creating a reference to ADSI's WinNT: provider, which is the mechanism that ADSI uses to access and manage NT 4.0 and 3.51. Next, you call the OpenDSObject method to authenticate and bind to the container that will hold the new computer account object. OpenDSObject takes four parameters:

  • The ADsPath to the target ADSI object. In this example, you're binding to the Olympus domain.
  • The account credentials to authenticate the bind request.
  • The password for the account credentials.
  • The type of authentication to perform the bind operation. The value 1 is the authentication flag that enforces secure authentication.

After you successfully bind to the target domain container, you use the IADsContainer::Create method to create the computer account object. This method takes two parameters: the type of object to create and the object's name. In this case, you're creating a Computer object named Hercules. On completion, the Create method returns a reference to the new object. Although you might think that the computer account exists at this point, it doesn't exist until you use the SetInfo method. SetInfo writes the object to the underlying directory. The last two lines set the computer account's initial password.

To use this script, you need to change several values to match your environment:

  • Change "Olympus" to the name of the domain that will contain the new computer account.
  • Change "Administrator" to the name of a user account that has sufficient domain privileges to create computer accounts.
  • Change "Password" to the previous user account's password.
  • Change "Hercules" to the name of the new computer account.