Copying a Profile
Most of you might have found this solution right off the bat. But I spent a whole week trying to figure out why more than 1000 users couldn't add a printer or change their wallpaper BMP, so I submit this tip.
I had just finished setting up 20 new workstations in a new lab at Washington State University. I wanted this lab to be the best. We needed the ease of the Windows 95 interface and security, but I had hassled with running Win95 in the lab last year--what a headache. The only answer was Windows NT 4.0: It has the look and feel of Win95 but the security of NTFS.
Using lessons learned from working with Win95 in general access labs at a university, I set out to run most applications from the lab's NT server. I set up one system, configured the BaseUser account the way I wanted it, and then set out to clone the rest of the systems and users. Aside from a few minor problems in copying, things looked good from a distance. (By the way, SCOPY, REGBACK, and REGREST work fairly well.)
Two things caught me unaware. First, shortcuts in NT 4.0 carry the universal naming convention (UNC) name. Even if you edit the shortcut and it reads c:\program files\netscape\programs\netscape.exe, what NT reads is \\pc130-12\program files\netscape. Yes, this means that all other systems will be mapping and running the application from the system that you set it up on instead of from the local hard drive. If you use station number 1 to set up the BaseUser account, all other workstations will try to connect to station 1 to run the application instead of running it locally.
You can fix this problem by editing the shortcut (right-click and select Properties), clicking the Shortcut tab at the top of the Properties dialog, selecting Find Target, and then changing the target to the local C drive. Or, you can change the shortcut path to read %systemroot%\
The second surprise was the BaseUser profile I set up. Like NT 3.51, NT 4.0 has profile OWNERSHIP. It's an object that carries information such as your wallpaper BMP, screen saver, mapped drives, and who can use this profile. If you create a profile and copy it to hundreds of users, you can't simply file copy it. You have to use the Copy To function under Settings, Control Panel, System. Select the Profiles tab and click the user you want to copy (BaseUser in this example). Then select Copy To Here you will see that you can browse the user or group list to change the Permitted to use user and select another user who can use this profile. I suggest you use the EVERYONE global account. Now you can copy the profile to a share point and then use a simple file copy to copy the profile to anyone you want to have this profile. When such users log on for the first time, they take ownership of this profile.
If I had known this little tidbit of information, I could have saved hours of frustration. Hope it helps if you run into this problem.
Here is a neat tip for all you serious Windows NT users: Put the following line
in your lmhosts file. Now, instead of using an FTP client to copy files from, you can map Microsoft's FTP server drive to a local drive letter.
Then from a DOS command prompt, enter the command NET USE M: \\FTP\DATA to have an M drive that you can use from your Windows Explorer. Remember that you can only copy or download files from this drive. You can't write to it.
More on Creating User Accounts
I was recently working on a LAN migration project and needed to create more than 300 users. I looked at addusers.exe from the Resource Kit, but it lacks three important functions: creating the user's home directory, setting the access control lists (ACLs), and sharing the directory. To make life interesting, I was migrating to an AlphaServer 2100, so my selection of advanced tools was strictly stone knives and bear skins.
I wrote the batch file in Listing 1 to take care of all the steps using only standard NT 3.5x commands--no Resource Kit apps--so it will run from a vanilla installation. When I wrote it, I assumed that
*the file is running on the server, not out on a PC or workstation
*the user directories are on the f:\users\ tree
*the default accesses are set on f:\users to allow admin and backup access
*f:\users\default\*.* contains files that you need to copy into every user's home directory to do a default setup for applications
*the sharename parameter is the username with an appended $, so the resulting share (an administrative share) does not show up on the browse list but still allows the netusex:/home syntax in a logon script to properly connect the user's share
Other notes: Lines that start with two colons are REM statements. One colon starts a label, but the second colon is not legal in a label, so parsing stops after two characters.
The logic is direct, and I trap for two nonfatal errors: First, the username already exists with the home directory on this server. Second, the username already exists somewhere else on the domain.
An error message for the username is appended to file errors.txt in the current directory. I don't worry about deleting the file at the beginning of the process so I can keep a record of all errors during the process.
I usually write another batch file to call addusers.bat, with one line for each user. That line looks something like: call adduser username password "Group Name" "I am User1" Homeserversharename. Parameters with embedded spaces must be in quotes, as shown.
I ordinarily make calling files in batches of about 100. As the calling file lengthens, the I/O necessary to process the last few lines becomes prohibitive. Obviously, you can change the batch file to add or remove default values.
Don't Use CUse Perl to Create User Accounts
Reading Tong Lai Yu's recent Reader to Reader item about writing a C program to create user accounts was painful. Why use C, a tortuous language, when Perl exists. An NT version of Perl 5.001 is available for free from www.perl.hip.com/ (Microsoft paid hip communications to port it). Perl for NT has built-in support for regular expressions, so parsing files is a breeze, and Perl for NT supports the NT Registry, Object Linking and Embedding (OLE) automation, and Network Administration. The only problems I have run into are incorrect documentation in some places.
In response to Tong Lai Yu, I submit the Perl script in Listing 2. It does the same task as the C code, but in 9 lines of code instead of the roughly 28 lines in the C code. The Perl code is also more robust than the C code and is fairly easy to follow if you know Perl. The only complicated section in the code is the parse line, and I put all the brains of the parser in one place, which makes it much easier to understand1. In addition, to control all the parameters (home directories, user privileges, logon scripts, etc.) associated with the user and to add the user to various groups, I could have used the network administration stuff built into the hip communications port of Perl.
In a nutshell: Perl is cool. For years I've looked at things and said, "Wouldn't it be nice if I could automate this? It's not that difficult, but I don't have a language that makes handling these ugly input files easy and makes the script reasonably robust." When I started learning Perl, I realized that I had finally found a language to solve all those little problems. I have subsequently used Perl extensively under OS/2 and NT and find it to be an invaluable tool.
In addition to the makeusr.pl program, I'm submitting another little gem, which you see in Listing 3. This program disables Print Banners when you use the Microsoft Client Service for NetWare in NT 4.0. Notice that Microsoft stored these settings in the completely wrong section of the Registry. The code has to hunt through the Registry to find the user's real ID (that long thing that starts with S) and then uses that value to set the parameters appropriately.
In closing, Tong Lai Yu hit the nail on the head when he said, "This utility can help the harried systems administrator... You'll want it to be part of your systems administrator's tool chest." The beauty of Perl is that it makes writing robust scripts quick and easy. I haven't even mentioned associative arrays, anonymous arrays (great for creating tree structures), and all the other goodies in Perl. Perl truly is a systems admin's dream.
Another Use for a Laptop
Your problem: Your clients want a new server to act as a Backup Domain Controller (BDC), but they want you to set it up at your office. Their Primary Domain Controller (PDC) is in a rack, so bringing it to your office is out of the question. You have no WAN connection between offices. What do you do? If you have a laptop, the problem is easily solved. All you need is a few hours and a trip to the client (which you have to make anyway), and you have a BDC ready to go.
Start by taking your laptop to the client site, installing NT Server on it, and configuring it as a BDC. You don't need a fancy configuration or any protocols beyond NetBEUI. Just make sure NT supports your network PC Card. When your BDC laptop boots in the office LAN, the laptop sucks up the PDC data.
Then take your BDC laptop to your office, and boot it. On booting, it will not find a PDC. Using Server Manager, promote the laptop to a PDC and install NT Server on the client's new machine. Make it a BDC to your laptop PDC. You do not need to worry about user accounts replicating. Use Server Manager to check your PDC and BDC.
Take the BDC to the client site, and you are finished! But what about the Security ID (SID) for the domain? Isn't the laptop SID different from the SID on the client's PDC? Actually, no. When you install the BDC on your laptop, it receives the SID from the client's PDC. Promoting your laptop to a PDC does not change the domain SID. So when you install the BDC on the client's new server, it receives the same domain SID.
This method also works for installing remote BDCs when the WAN connection isn't available. In this case, make sure you add the user accounts for the remote site to the domain and ensure that it is fully replicated on the laptop before you bring it to the remote site. Until you get a WAN link up, you will not be able to modify the user accounts database. When the WAN link comes up, you won't have to reinstall NT to get a BDC at the remote site.
A Strange Problem Solved
I'm a systems admin and have been happily running NT Server 4.0 since it came out, but I had one annoying problem that would not go away. The modem connected just fine, and I could receive email with attachments and receive at FTP sites with no problem. However, as soon as I tried to use the modem to send, NT 4.0 would beep and hang up the phone. The same happened with email--beep, hangup.
I reinstalled NT. I played with TCP/IP settings. I looked into possible security limitations. My Internet Service Provider (ISP) could not help at all. I posted to all the relevant usenet groups; no help. I even posted the problem at the Windows NT Magazine Web site. So, just in case another human is out there with this problem and has wasted hours trying to figure out the answer, here it is: Turn off error correction in the modem properties under Control Panel.
Just wanted to pass along a strange problem with an answer. Thanks. Oh, and great magazine. I sent out my subscription form today.