Peer-to-Peer Questions #8: Map Home Directories, Tracking Users, and Service Pack Compatibility

July 12, 1999

Editors Note This article, culled from the TechNet Web site (https://www.microsoft.com/technet), answers the most interesting questions received on the peer -to-peer discussion groups over the past few weeks. To post your own questions, visit the TechNet discussion groups at https://www.microsoft.com/technet/community/newsgroups/default.mspx.

On This Page

Q: How do I map users' home directories with logon scripts?
Q: How can you keep track of what users are doing?

Q: How do I map users' home directories with logon scripts?

A: Recently, we have received a number of inquiries about how to map users' home directories with logon scripts. A quick search of our TechNet site will get you all the information you need to know.

The following is available on TechNet in the Windows NT Server Concepts and Planning Guide, Chapter 2 - Working with User and Group Accounts and Chapter 3 - Managing User Work Environments:

Specifying a home directory

A home directory contains a user's files and programs; it can be assigned to an individual or be shared by many users. Because home directories collect user files in one location, they make it easy for an administrator to back up user files and delete user accounts. You specify a home directory by adding a directory path to the user account. Home directories must be added to a shared directory with appropriate access.

The home directory is a user's default directory for the File Open and Save As dialog boxes, for the command prompt, and for all applications that do not have a working directory defined.

User Manager for Domains automatically applies directory permissions if it creates the home directory. When one user account is being administered and a new home directory is created, that user is granted Full Control. When two or more user accounts are being administered and a new home directory is created, Full Control is granted to Everyone.

User Manager for Domains does not automatically apply permissions if the directory already exists. In this case, you must apply the permissions using Windows NT Explorer.

If the user account does not specify a home directory, the default home directory for upgraded computers is \USERS\DEFAULT on the user's local drive where Windows NT is installed. If Windows NT Workstation or Windows NT Server has been installed for the first time, the default home directory is the root of the drive where Windows NT is installed. (To change the default home directory to a shared network directory or to another local directory on the user's workstation, use User Manager for Domains.)

• When administering the user accounts of a domain, you should assign network home directories. User Manager for Domains automatically creates that home directory. If it cannot, a message instructs you to create the directory manually.

• When administering the user accounts of a workstation or member server, you should assign local home directories. User Manager for Domains automatically creates that home directory at that computer. If it cannot, a message instructs you to manually create the directory.

If you are administering a domain and you specify a local path for the home directory, User Manager for Domains will not create the home directory.

Using %USERNAME% in the home directory path

In the Home Directory box, %USERNAME% can be substituted for the last entry in the path. The system later substitutes the user name of the user account. This substitution is useful when multiple user accounts are selected.

For example, you have selected eight user accounts. In the Home Directory box, you might select Connect, specify a drive letter of K, select the To box, and type \\SALES\home\%username%. When you choose OK to save the User Environment Profile, the actual user name will be substituted for each %USERNAME% entry.

Creating logon scripts

You can create logon scripts using a text editor and then use User Manager for Domains to assign different logon scripts to different users or assign the same logon script to multiple users.

There are several special parameters you can use when creating logon scripts:

Also of note is Knowledge Base article **Q180464:**How To Automate Folder Permissions—look at the second question.

Q: How can you keep track of what users are doing?

A: There are several administrators that are new to Windows NT and questions keep popping up about how they can track what users are doing. For instance, track when they log on, log off, file access, etc. As many IT Pros know, sometimes it's a matter of knowing what the term is for what they want to do. It's like when you were a kid and you asked your parents how to spell a word. They told you to go look it up in the dictionary. Well, how can I look it up in the dictionary if I don't know how the word is spelled?

Windows NT has a feature called Auditing that administrators can use to monitor what users are doing. To start your reading, I won't just tell you to "go look it up in the NT manuals." No sir. I will give you some specific sections to read. The first place to go is Chapter 9 - Monitoring Events of the Windows NT Server 4.0 Concepts and Planning Manual. Chapter 9 addresses auditing security events.

The way it works is once you enable auditing—see Enabling Security Logging below—the events that you choose to audit are recorded in the security log in Event Viewer. You can run Event Viewer by selecting Start, Programs, Administrative Tools (Common), Event Viewer. Then, from the File menu item, select the log that you want to view—System, Security, or Application.

The security log will be of most interest to administrators that want to audit users' access patterns. The security log can contain valid and invalid logon attempts as well as events related to resource use, such as creating, opening, or deleting files or other objects. For example, if you use User Manager for Domains to enable logon and logoff auditing, attempts to log on to the system are recorded in the security log.

The application log contains events logged by applications. For example, a database program might record a file error in the application log. Application developers decide which events to monitor.

The system log contains events logged by the Windows NT Server system components. For example, the failure of a driver or other system component to load during startup is recorded in the system log.

All users can view system and application logs; security logs are accessible only to system administrators.

Enabling Security Logging

By default, security logging is turned off. To enable security logging, run User Manager for Domains to set the Audit policy. For the security log, the administrator can also set auditing policies in the registry that cause the system to halt when the security log is full. For more information, see "Halting the Computer When the Security Log Is Full" later in this chapter.

Note: The Windows NT Server Resource Kit includes Crystal Reports Event Log Viewer, a full-featured report writer that provides an easy way to extract, view, save, and publish information from event logs in a variety of formats. For more information on Crystal Reports Event Log Viewer, see Readme.hlp in the \Crystal\Disk1 folder on the Windows NT Server Resource Kit 4.0 compact disc.

More information sources:

• Designing and Planning Internal Security

Another great resource is the MS Press book Microsoft Windows NT 4.0 Security, Audit, and Control. This book, written by the top dogs at Pricewaterhouse Coopers, is designed to assist CIOs, IT Managers, System Managers and the like, to understand how to build and audit a secure Windows NT 4.0 environment. Auditing is just a part of the bigger picture. You can track what users are doing, but the bigger picture reveals maintain the security of the company's information is part of the network administrator's responsibilities.

Q: There have been questions regarding whether there are incompatibility issues by having different Service Pack versions running on domain controllers. For example, a Windows NT 4.0 Primary Domain Controller running Service Pack 4 and some Backup Domain Controllers running Service Pack 5.

A: In one particular documented scenario, an "Access Denied" message is received when an attempt is made to promote a backup domain controller (BDC) to a primary domain controller (PDC). In this situation, the domain controller that the administrator is running Server Manager from is running SP 4 and the server that is being promoted is running SP5.

The "Access Denied" message occurs if you attempt to perform the promotion from a domain controller running a Windows NT 4.0 Service Pack version that is older than the domain controller that is being managed through Server Manager.

It is recommended that the PDC in a domain have the new Service Pack applied first.

There is also this section in the Service Pack 5 Readme file:

3.6 Running Windows NT 4.0 Administrative Tools from a Remote Server

To run administrative tools from a remote server, you must upgrade the remote server to SP5. If you try to run administrative tools from a remote computer that hasn't also been upgraded to SP5, they may fail to load or not function properly.

Another issue involves Site Server 3.0 and is documented in Knowledge Base article **Q219396:**Interoperability Between Site Server 3.0 and Windows NT Service Pack 5.

Here is an excerpt from this article:

To install or maintain Microsoft Site Server 3.0 on a Windows NT-based computer on which Windows NT 4.0 Service Pack 5 is already installed, you must install Microsoft Site Server 3.0 Service Pack 2 (SP2) to insure interoperability between the software components.

Phew! That is it for now. Happy reading.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.