The MSMQ command-line parameters are /q or /qt, /b#, /r, and /u. The /q parameter specifies quiet mode, and the /qt parameter specifies totally quiet mode. You must specify /q or /qt to have MSMQ Setup run in unattended mode. I recommend that you use the /qt parameter.

The /b# parameter corresponds to the option buttons' order in the MSMQ Setup Installation Type dialog box. The number of available options (/b1, /b2, or /b3) depends on which type of dependent client, independent client, or server you are installing and, in the case of independent clients, the platform on which you are installing the software. If you don't specify a /b parameter, MSMQ assigns /b1 by default. When you're using unattended setup to install MSMQ dependent client software, /b1 is the only available setup button. When you're using unattended setup to install MSMQ independent client software, the /b# parameter refers to the Independent Client and Development Environment options.

When you use an unattended setup to install an MSMQ routing server or comparable system, you use the /b# parameter to specify Server, Installation Server, or Custom. Use /b1 (Server) to install the MSMQ server software and administration tools. Use /b2 (Installation Server) to install the MSMQ server software, administration tools, the MSMQ software development kit (SDK), and an MSMQ installation folder for computers running Windows 95, NT Workstation, or NT Server (Intel-compatible computers only). Use /b3 (Custom) to install the MSMQ server software, administration tools, MSMQ SDK, and an MSMQ installation folder for Win95 computers and all supported NT platforms.

The /r parameter runs an unattended reinstall, and the /u parameter runs an unattended uninstall to automatically remove your MSMQ data files. You can place all these parameters in batch files that point to the appropriate directories or shares on your network, and place the batch files or command lines in cmdlines.txt. You can specify that the command run as a run-once command, as I discussed in my April column. Example commands lines include

setup /qt /r

to run a reinstall,

setup /qt /u

to run an uninstall, and

setup /qt /b1

to run a simple install.

Unattended installations install to the C drive. How can I install to a different drive and place my temporary files on that drive?

You must create special folders in the i386\$oem$ directory to copy files to a drive other than the C drive during an unattended installation. For example, if you want to copy files to the D drive, you need to create a subdirectory in the $oem$ directory with the syntax i386\$oem$\D. Creating this subdirectory tells NT Setup to temporarily copy files to C and then move them to D later in the setup process.

If you boot to a network installation, NT copies the files in the i386\$oem$\drive-letter directory to the C:\$\drive-letter directory during the text-mode portion of setup. You can change the location of the $ directory by using the /T: parameter in the unattended reference. For example, /T:D tells winnt.exe to place the $WIN_NT$.~LS and $ on drive D. Furthermore, this switch places the operating system (OS) on drive D and copies all files during the GUI stage of the NT Setup. If sufficient space is not available on the target drive, NT Setup fails to copy any files and aborts the installation.

My company's Primary Domain Controller (PDC) is in New York City, and our Backup Domain Controller (BDC) is in Chicago. When users log on in Chicago, which domain controller authenticates their usernames and passwords? Can I force the BDC in Chicago to authenticate all Chicago user logons?

I'd be surprised if the PDC in New York City were handling the Chicago logons. Windows NT's logon process consists of several stages. On a computer running NT Workstation or a member server running NT Server, the Net Logon service processes logon requests for the local computer. For a domain controller, the Net Logon service processes logon requests for the domain.

Net Logon initiates the following processes: discovery, secure channel setup, and passthrough authentication. When you boot an NT workstation on a domain, the Net Logon service tries to find a domain controller running NT Server in the domain. After the service finds the domain controller, the service uses that machine for subsequent user authentication. In your case, the BDC is performing the initial authentication for the Chicago users. In theory, the BDC passes all information to corresponding domain controllers on all trusted domains.

End of Article

Prev. page     1 2 [3]     next page -->



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

<i>In Tricks & Traps (August), the section about which servers authenticate user passwords prompted several letters from readers. The following letter contains an excellent suggestion for maintaining proper secure channels across WANs. “My company has an international domain with about 30 Backup Domain Controllers (BDCs) throughout the world. Quite often, we find that servers on different sites from the users authenticate user passwords. Here’s what we think happens when the secure channel is set up from the Resource Domain BDC to the Master Account Domain BDC. “The Resource Domain BDC contacts the Windows Internet Naming Service (WINS) server and gets a list of 10 Master Account Domain BDCs (I think the WINS server is clever enough to return the closest one if it’s on the same subnet, plus another nine). The Resource Domain BDC then sends a request to all 10 servers to set up a secure channel. After the Resource Domain BDC has sent all 10 requests, it starts listening for responses and configures a secure channel with the first server that responds. “The problem occurs because the Resource Domain BDC doesn’t start listening until it has finished all 10 requests; if the local server responds too quickly, the Resource Domain BDC misses the response and configures the secure channel to another BDC (in our case, a BDC in another country). This secure channel isn’t automatically reset unless the connection is lost. If your local BDC is offline for a couple minutes, all the secure channels reestablish with alternative BDCs and stay that way as long as they can contact the alternative BDC. “I find that the easiest tool to use to solve this problem is </i>Microsoft Windows NT Server 4.0 Resource Kit’s <i>Domain Monitor. You can use Domain Monitor to disconnect an incorrect secure channel. However, the process is hit-and-miss because you just initiate the same process I described before. Usually after a couple of disconnects, you can establish a secure channel with the correct server. We have seen quite a few performance problems develop because of this issue, so we’ve added the task of ensuring the correct secure channels to our daily checklist.”<br> --Bob Chronister</i>

Bob Chronister- August 11, 1999

Hi,

We have approx 25 sites in Europe and have a BDC in most we are finding that Workstations from different locations at random are going accross the WAN for authentication to other BDC's is their anyway that I can force the machines to stay on their local LAN for authentication on their local BDC ???? Thanks, for your help.

kalek- February 13, 2002

We are having the same problem. The client machines in one office go over the wan to a Remote BDC before using the local PDC or BDC. I would also like to know how to force which BDC does the authentications.

Thomas- November 19, 2003

 
 

ADS BY GOOGLE