Solstice NFS Client 3.2 User's Guide for Microsoft Windows 95 and Windows NT

Chapter 6 Managing Work Environments

This chapter describes how to manage clients in a 32-bit Solstice network. If you have a PC-Admin network, you can manage clients in a 16-bit Solstice network from a PC-Admin server.

Management tools, such as user profiles, system policies, and SNC scripts, enable you to manage clients running Windows 95 and Windows NT from an authentication server (a server running the pcnfsd daemon).

You can read background and procedural information throughout this chapter, or you can use the following references to go directly to a specific topic.

User Work Environments

User work environments include desktop items and settings such as screen colors, mouse settings, window size and position, and network and printer connections. Using the Solstice Network Client management tools allows a user to have an identity independent of their PC. With this independent identity, a user can maintain a home directory on a file server and have user-based privileges to access other file systems.

Using management tools available in Solstice Network Client, you can set up individual work environments for each user in the network as well as common work environments for groups of users.

Management Tools

Windows 95 and Windows NT systems include mechanisms that are used to set up and configure the user's work environment. These include user profiles and system policies.

Solstice Network Client provides a way to use these management tools from a central location. It also provides a script interpreter that allows you to write or convert SNC scripts, which mount drives and directories, create Registry entries, access shared applications, and manage user views.

System policy files, user profiles, and scripts can be stored on the authentication server (the server running the pcnfsd daemon) and made available to a user logging into a client computer anywhere on the network. The files are stored in the directory /opt/MSPolicy on the authentication server.

User profiles

A user profile defines the desktop environment that is loaded by the system when a user logs in. A user profile contains configuration preferences and options for each user, such as:
- Control Panel settings and preferences for the user interface
- Settings for persistent network connections
- Settings for applications that can write directly to the Registry
Use the user profiles to enforce a consistent desktop for users. A user can log into the network from any computer and work with the same desktop settings. Multiple users on a computer will retain their personal settings.
System policies

System policies enable the system administrator to control user-definable settings in Windows NT and Windows 95 user profiles, as well as system configuration settings.

Use the System Policy Editor to change desktop settings and restrict what users can configure, such as network settings and network client configuration options.
Logon scripts

Logon scripts are batch files (*.bat) that run each time a user logs in to a computer on the network. logon scripts contain system commands, such as commands to start applications. They can also call user-specific batch and executable files stored anywhere on the network.

Use the logon scripts to manage part of the user environment (such as network connections) without managing or dictating the entire environment. Use the scripts to create common network connections for multiple users.
SNC scripts

SNC scripts are script files (*.snc) that can be run in the 32-bit Solstice Network Client environment. SNC scripts previously written for a PC-Admin network can be adapted to run on Windows 95 and Windows NT clients.

Use SNC scripts to securely manage SNC features, mount user network drives, create Registry entries, and set environment variables.

Setting Up the Authentication Server

Solstice Network Client provides a mechanism for central management of clients from a server in the network. System policy files, user profiles, logon scripts, and SNC scripts can be stored on the authentication server (the server running the pcnfsd daemon) and made available to a user logging into a client computer anywhere on the network. The files are stored in the directory /opt/MSPolicy on the authentication server.

If you have more than one authentication server, you must ensure that the appropriate files and scripts are available to clients on the network. You can do this by:

Setting up duplicate scripts and files on each authentication server. If a client broadcasts for an authentication server, it will get the same scripts no matter which server responds.
Setting up a specific authentication server for each user's network configuration. You can then maintain the appropriate files and scripts on the authentication server assigned to a user or to groups of users.

To Set Up an Authentication Server

To check that the pcnfsd daemon is running, type:

# ps -ef | grep pcnfsd 
root 1206 1 80 Feb 05? 0:30 /opt/SUNWpcnfs/sbin/rpc.pcnfsd  
root 24452 24450  5 14:49:15 pts/2 0:00 grep pcnfsd  
#

Create the directory /opt/MSPolicy.
```
# mkdir /opt/MSPolicy
```

Make sure the /opt/MSPolicy directory is world readable and writable by root. For example:

# cd /
# chmod 755 /opt/MSPolicy
# ls -l /opt
drwxr-xr-x   2 root     other        512 May 21 16:38 MSPolicy

Export the /opt file system. For example:
# share -F nfs /opt/MSPolicy

User Profiles

Use user profiles to set up personal settings, such as desktop colors, fonts, and program groups that appear on the desktop. User profiles are available on both Windows 95 and Windows NT systems.

Using User Profiles on Windows NT

Windows NT 4.0 security requires a user profile for each user account. When a user logs in for the first time, Windows NT automatically creates a user profile. You can also create and modify user profiles on a computer running Windows NT Server. On Windows NT, all user-specific settings are automatically saved into the Profiles folder within the system root folder (typically C:\winnt\profiles).

You can create user profiles on the client running Windows NT and store them on an NFS server. You must specify the path name of the user profile in the NT user's account information. For users with only local NT user accounts, you must specify the user profile path name in each user account on each client.

If you have an NT domain set up with domain user accounts, you can specify the user profile path in the user's account on the domain controller. Then, whenever the user logs in, the user profile is downloaded and run.

Using User Profiles on Windows 95

In Windows 95, user profiles are not created by default. The system administrator must enable user profiles.

Each time the user logs in, the client running Windows 95 passes to Windows the location of the user's home directory (\\home\username) on an NFS server. The username is the name the user types when logging in to the client machine. The \\home directory is the entry in the auto_home file in the NIS or NIS+ tables on the server, or in the local auto_home file.

For user profiles to work on Windows 95, you must configure the Solstice NFS Client as the Primary Network Logon, and you must configure either NIS or NIS+ as the name service on the client. When NIS or NIS+ is configured, the Automounter automatically mounts the user's home directory. If you configure the DNS or Files-based name service but not NIS or NIS+, the Automounter does not automatically mount user's home directories and user profiles stored in those directories are not downloaded to the client.

Updating User Profiles

The Windows NT and Windows 95 networks follow these rules for updating user profiles.

Each time a user logs in to a computer, Microsoft Windows searches the Registry to determine whether the user has a local profile. On Windows NT, the local profile path is stored in the Registry key:
```
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Windows NT\Current Version\ProfileList   
```
On Windows 95, the local profile path is stored in the Registry key:
```
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Windows\Current Version\ProfileList 
```
Windows NT checks for the user profile in the User Profile Path specified in User Manager, User Profiles. If the user profile on the server is the most current, Windows NT copies it to the local computer for use during the current session. Windows NT then loads the settings in this local copy into the Registry. Windows 95 checks for the user profile in the user's home directory on the server. If the user profile on the server is the most current, Windows 95 copies it to the client computer for use during the current session. Windows 95 then loads the settings in the client copy into the Registry.
If no user profile exists on the client, Windows copies the server version to the client computer. If no profile is found on the server, Windows creates a new user profile on the client computer using default settings. If the user does not log in, then Windows automatically uses the default user profile.
Both the client and network copies of the user profile are automatically updated with the current settings when the user logs out.
If the user is logged in to more than one computer at the same time, any changes made to the profile on the computer where the user first logs out will be overwritten when the user logs out of the other computer. In other words, the last logout is saved, and no merging of changes occurs.

Setting Up Roaming User Profiles

A roaming user profile is a server-based user profile that is downloaded to the local computer when a user logs in and is updated both on the client and on the server when the user logs out. A roaming profile is available from the server when logging in to any computer running the Solstice Network Client software on Windows NT Workstation, Windows NT Server, or Windows 95. A roaming user profile enables a user to log in to the network from any computer and work with the same desktop settings.

You can store roaming user profiles created on computers running Windows NT Workstation, Windows NT Server, or Windows 95 on an NFS server.

To use a roaming user profile, a user must have a user account on that computer. On Windows 95, each user can create a user account by specifying a user name and password when logging in.

You can create user accounts in Windows NT in one of the following ways:

If you have an NT domain set up, log in to the domain controller as administrator and create a domain user account for each user. Set the profile path in each user account on the domain controller to the location of the profile on the NFS server.
If you do not have an NT domain set up, log in to each NT workstation as Administrator and create a local user account for each user. You must also set the profile path in each user account on each NT workstation to the location of the profile on the NFS server.

To Set Up Roaming User Profiles on Windows NT

Note -

To assign the same preconfigured roaming user profile to multiple user accounts, enter a separate user profile path for each user account, and use System in Control Panel (User Profiles tab) to copy the preconfigured user profile to the server location for each user.

Log in to an NFS server as root and make sure each user is properly set up and has an assigned home directory.

Store each user's profile in the user's home directory on the server. You can store user profiles in another location on the server, but it is not recommended.

Make sure the directory is world readable. For example:
# cd / # chmod 755 /home/users

Share the top level directory of the file system. For example:
# share -F nfs /home

On a computer running Windows NT Workstation 4.0 or Server 4.0, log in as an Administrative user and customize the desktop as you want it to be for the user profile.

Click Start, point to Programs, then point to Administrative Tools (Common), and select User Manager.

Double-click a user from the listed user names.

The User Properties dialog box opens.

Click Profile.

The User Environment Profile dialog box opens.

In the User Profile Path box, type the complete path to the profile on an NFS server in the form: \\server\mount_point\directory 1\directory 2\...

The mount point is the directory you shared in Step 3. Specify the complete path name to the profile on the server. For example: \\saturn\home\users

Click OK to close the User Environment Profile dialog box. Click OK again to close the User Properties dialog box.

Select Exit from the User menu to close the User Manager dialog box.

(Optional) Copy a preconfigured user profile to the user profile path location.
1. Click Start, point to Settings, and then select Control Panel.
2. Double-click System and then click User Profiles.
3. Under Profiles Stored On This Computer, select the profile to copy to the Solaris server and click Copy To.
4. Type the location of the user profile on the server.
  
  This should be the same location you typed in Step 8.
5. Click OK to close the Copy To dialog box. Then click OK to close the User Profiles tab.
  
  When the user logs out, the client automatically places an updated copy of the user profile in the user profile path on the server. In the following example, the server is named saturn: \\saturn\home\users\mary\ntuser.dat

To Set Up Roaming User Profiles on Windows 95

Make sure user profiles are enabled for each computer.

Note -

You can facilitate this step by creating a system policy that enables user profiles on all PCs running Windows 95. When the user logs in, Windows 95 downloads the policies from the server and copies the information to the Registry on the client.

Make sure either NIS or NIS+ is configured as the name service on the client.

When NIS or NIS+ is configured, the Automounter automatically mounts the user's home directory. If you configure the DNS or Files-based name service but not NIS or NIS+, the Automounter does not automatically mount user's home directories and user profiles stored in those directories are not downloaded to the client. "To Configure NIS or NIS+"

In the Passwords option in Control Panel, click the User Profiles tab.

Select Users Can Customize Their Preferences And Desktop Settings.

Select the options you want under User Profile Settings and click OK.

These options describe what should be included as part of the user profile.

Note -
If you include desktop icons in the user profile, only the shortcuts (icons that represent links) will be available when the user logs in to the network from another computer. Actual files on the desktop are part of the local user profile only.

Click Yes when asked to restart the computer.

In the Network option in Control Panel, make sure Solstice NFS Client is listed as the Primary Network Logon.

On an NFS server, make sure each user is properly set up and has an assigned home directory.

When the user logs out, Solstice Network Client automatically places an updated copy of the user profile in the user's assigned home directory on the server, in the path: \\server\user_home_directory

Setting Up Mandatory User Profiles

In Windows NT and Windows 95, a mandatory user profile creates a standard user profile that is implemented at every login. You can create mandatory user profiles on an NT workstation and store them on an NFS server.

If you have an NT domain set up, set the profile path in each user account on the domain controller to the location of the profile on the NFS server. If you do not have an NT domain set up, log in to each NT workstation as Administrator and set the profile path in each user account to the location of the profile on the NFS server.

To Set Up Mandatory User Profiles on Windows NT

Create a user profile using the instructions in "To Set Up Roaming User Profiles on Windows NT".

Rename NTUSER.DAT to NTUSER.MAN in the user's profile path.

Windows NT recognizes the .MAN file extension as a mandatory user profile.

To Set Up Mandatory User Profiles on Windows 95

Make sure user profiles are enabled for each computer.

Note -

You can avoid enabling user profiles on each computer by creating a system policy that enables user profiles on all clients. When the user logs in, Windows downloads the policies from the server and copies the information to the Registry on the client.

Make sure either NIS or NIS+ is configured as the name service on the client.

When NIS or NIS+ is configured, the Automounter automatically mounts the user's home directory. If you configure the DNS or Files-based name service but not NIS or NIS+, the Automounter does not automatically mount user's home directories and user profiles stored in those directories are not downloaded to the client. "To Configure NIS or NIS+"

In the Passwords option in Control Panel, click the User Profiles tab.

Select Users Can Customize Their Preferences And Desktop Settings.

Select the options you want under User Profile Settings.

These options describe what should be included as part of the user profile.

Shut down and restart the computer.

In the Network option in Control Panel, make sure Solstice NFS Client is listed as the Primary Network Logon.

On any computer running Windows 95, customize the desktop as you want it to be for the mandatory user profile.

Copy the USER.DAT file to the user's home directory on the server.

Rename USER.DAT to USER.MAN in the user's home directory.

Windows 95 recognizes the .MAN file extension as a mandatory user profile.

System Policies

The Windows NT or Windows 95 client computer can download and set Windows system policies from the authentication server. The authentication server is one that is running the pcnfsd daemon, which verifies that users are authorized to log in to the network.

System administrators can use system policies to manage clients by:

Restricting access to Control Panel options
Restricting what users can do from the desktop
Customizing parts of the desktop
Configuring network settings

On Windows 95, you can download system policies for specific users, groups, specific computers, or for all users. On Windows NT, you can download system policies for specific users, specific computers, or for all users. But you cannot download group policies from an NFS server.

Creating System Policy Files

To create a system policy file on Windows NT, use the System Policy Editor on a computer running Windows NT Workstation or Windows NT Server. The System Policy Editor is available only on Windows NT server, but you can copy the editor from a Windows NT Server to a workstation and then run the editor on the workstation.

The system policy entries you set are stored in a binary file with the .POL extension. You should save this file with the name ntconfig.POL. The Windows NT Workstation software reads and interprets the ntconfig.POL policy file by overriding any conflicting information in that workstation's Registry.

To create a system policy file on Windows 95, use the Windows 95 System Policy Editor. The system policy entries you set are stored in a binary file with the .POL extension. You should save this file with the name config.POL on a server running the pcnfsd daemon. When the user logs in, Windows 95 overwrites the default USER.DAT and SYSTEM.DAT settings in the Registry with the policy settings in the config.POL file.

To apply system policies to a network that uses both Windows 95 and Windows NT, run the System Policy Editor once from each platform to produce two different system policy files.

How System Policies Work

When the user logs in to a client, the client passes the location of the system policy file to Microsoft Windows:

authentication_server:/opt/MSPolicy/ntconfig.pol on Windows NT
authentication_server:/opt/MSPolicy/config.pol on Windows 95

Microsoft Windows then downloads system policies for computers and users from the /opt/MSPolicy directory on the authentication server. Windows NT and Windows 95 follow these rules for updating user information with system policy files:

If user profiles are enabled, Windows checks for a user policy file that matches the user name. If it finds one, it applies the user-specific policy. If it does not find a user policy file, it applies the default user policy file. On Windows NT, user profiles are always enabled.
Group policies are not applied if there is a policy file for a specific user. If Windows support for group policies is installed on a client running Windows 95, Windows checks whether the user is registered as a member of any secondary UNIX groups. If so, group policies are downloaded, starting with the lowest priority group and ending with the highest priority group. Group policies are processed for all groups to which the user belongs. The group with the highest priority is processed last so the settings in that group's policy file supersede those in lower priority groups. The client on Windows NT does not download or process group policies.
All settings are then copied into the USER.DAT portion of the Registry.
Microsoft Windows checks for a computer policy file to match the computer name. If one exists, Microsoft Windows applies the computer-specific policies to the user's desktop environment. If a policy file for that computer name does not exist, Microsoft Windows applies the default computer policy.
This data is then copied into the SYSTEM.DAT portion of the Registry.

How System Policies Differ From Mandatory User Profiles

System policies and mandatory user profiles differ in the following ways.

System Policies	Mandatory User Profiles
Settings can be user-specific or computer-specific.	Settings can only be user-specific.
You can selectively determine a subset of user settings to control. Users may control the remaining settings.	You always control every user-specific setting.

To Set Up System Policy Files

Set up system policy files on each authentication server on the network.

Set up the authentication server.

See the instructions in "To Set Up an Authentication Server".

(Optional) On a client running Windows NT, create a Windows NT policy file and copy it to the /opt/MSPolicy directory on the authentication server.

See the instructions in "To Create a System Policy File on Windows NT".

(Optional) On a client running Microsoft Windows 95, create a Microsoft Windows 95 policy file and copy it to the /opt/MSPolicy directory on the authentication server.

See the instructions in "To Create System Policies for Users or Computers on Windows 95".

To Create a System Policy File on Windows NT

The NT version of the System Policy Editor (poledit.exe) is included with the NT Server software, but not with the NT Workstation software. You can use the System Policy Editor on an NT workstation by copying the editor (poledit.exe) on an NT server to the \winnt\system32 folder on an NT workstation, and copying the files common.adm, windows.adm, and winnt.adm to the \winnt\inf folder on the NT Workstation.

For detailed information on installing the System Policy Editor and creating system policy files in Windows NT, refer to the Microsoft Windows NT Server Resource Kit, published by Microsoft Press.

On an NT server, click Start, point to Programs, point to Administrative Tools (Common), and then select System Policy Editor.

The System Policy Editor dialog box opens.

Click File and then select New Policy.

Depending on which policies you are creating:
- Double-click the Default User icon to define the default settings for user-specific policies.
- Double-click the Default Computer icon to define the settings for computer-specific policies.

In the Policies tab, select the policies you want to put in place and then click OK.

Click File and then select Save.

Type ntconfig for the name of the policy and then click Save.

The system policy file is saved with the .POL extension.

Copy the system policy file you created from the workstation to the /opt/MSPolicy directory on an authentication server.

You can use the Network Neighborhood to browse for the server, and then drag the system policy files from the workstation (usually in \winnt\system32\)to the /opt/MSPolicy directory on the authentication server.

To Install System Policy Editor on Windows 95

Click Start, point to Settings, and then click Control Panel.

Double-click Add/Remove Programs.

Click the Windows Setup tab, and then click Have Disk.

In the Install From Disk dialog box, click Browse and specify the admin\apptools\poledit folder on the Microsoft Windows 95 compact disk. Click OK, and then click OK again.

Make sure System Policy Editor is checked.

To use group policies, make sure Group Policies is checked.

Windows 95 Setup will copy GROUP.DLL in the Microsoft Windows SYSTEM directory on the client computer and make the required Registry changes.

Click Install.

To Create System Policies for Users or Computers on Windows 95

To use System Policy Editor, you must install the following files from the admin\apptools\poledit folder on the Windows 95 distribution media: admin.adm, poledit.exe, and poledit.inf. For instructions on installing System Policy Editor, see "To Install System Policy Editor on Windows 95".

In System Policy Editor, click the File menu, and then click New File.

Depending on which policies you are creating:
- Double-click the Default User icon to define the default settings for user-specific policies.
- Double-click the Default Computer icon to define the settings for computer-specific policies.

Select the policies you want to put in place.

Click File and then select Save.

Type config for the name of the policy and then click Save.

The system policy file is saved with the .POL extension.

Copy the system policy file you created from the workstation to the /opt/MSPolicy directory on an authentication server. You can use the Network Neighborhood to browse for the server, and then drag the system policy files from the PC (usually in \WINDOWS\Profiles\username\Desktop\)to the /opt/MSPolicy directory on the server.

To Create Group Policies on Windows 95

In System Policy Editor, click the Edit menu, and then click Add Group.

Type the UNIX group ID number for the group you want to add, and click OK.

For example, if the group named staff has the UNIX ID 10, then you must type 10 when asked for the name of the group.

Click or clear policies by clicking the policy name.

Logon Scripts

Clients running Windows NT and Windows 95 can download and execute logon scripts from an authentication server. Logon scripts are batch files that run automatically when a user logs in. You are required to create logon scripts to configure the network connections and start applications in users' environments. A logon script can call other scripts and executable files that reside in any local or NFS directory.

On Windows NT, you create the logon script, ntlogon.bat, to provide users with the appropriate environment when they log in. On Windows 95, the corresponding file is winlogon.bat.

Note -

If the client computer is running over a PPP connection, you will not be able to run the logon scripts (winlogon.bat and ntlogon.bat). If it is necessary to run these batch files, you should run them from within the SNC scripts using the LAUNCH directive. See "SNC Scripts" and "LAUNCH filename [options]".

When a User Logs In

When a user logs in to a client machine, the client broadcasts to the authentication servers on the network. The authentication servers respond to the broadcast, and the client uses the first server that responds as its authentication server. The client reads the logon script from the server and runs it. The same logon script can be shared by all network users.

Clients can either broadcast for or choose a specific authentication server. Choosing a specific authentication server is recommended because it is the most secure method.

If you create a logon script to be used by all users, store the logon script files on every authentication server on your network.

You can create specialized logon scripts for one or more users. When run, the logon scripts determine the user or group and customize the start up of the Solstice Network Client environment for the specific user or group. In a typical implementation, you would have a group.snc script for each group in your domain and supplemental user.snc scripts for specific users.

Note -

Windows NT clients can run logon scripts that contain the Windows NT built-in environment variables. For an example, see Example 6-1.

To Create a Logon Script for Windows 95 Clients

Use any text editor to create the logon script.

Save the script as winlogon.bat.

Copy winlogon.bat to the /opt/MSPolicy directory on the authentication server.

To Create a Logon Script for Windows NT Clients

Use any text editor to create the logon script.

Save the script as ntlogon.bat.

Copy ntlogon.bat to the /opt/MSPolicy directory on the authentication server.

Note -
The winlogon.bat and ntlogon.bat files support the same commands as any .bat file.

Example Logon Scripts

Example 6-1 is a sample ntlogon.bat logon script that is executed when the user logs in to the client running Windows NT.

Example 6-1 Sample nt.logon.bat logon script

REM Sample ntlogon.bat script
net use
REM
REM Set Policy path environment variable
set PCNFSDSERVER=space
set POLICYPATH=\\%PCNFSDSERVER%\opt\MSPolicy
REM
REM Invoke globalboot.bat 
cmd /C %POLICYPATH%\globalboot.bat

The globalboot.bat script in Example 6-2 is called by the ntlogon.bat script.

Example 6-2 globalboot.bat script

REM Sample script to set other environment variables
set VARIABLE1=test
set VARIABLE2=dir
mkdir c:\%VARIABLE1%.%VARIABLE2%
REM
REM Invoke globallogon.bat 
cmd /C %POLICYPATH%\globallogon.bat

The globallogon.bat script in Example 6-3copies files from saturn to the \tmp\planets directory on the client. The following lines in the globallogon.bat script run user Pat's .bat file in the directory \\home\pat on the server named jupiter.

set USER=pat
 set HOME=\\jupiter\home\%USER%
 cmd /C %HOME%\globallogon.bat

To call a logon script for many users, you would need to repeat these lines for each user. If users have identical user names and passwords on UNIX and NT, you can set the built-in NT variable USER to the user's username, and set the variable HOME to the path to the user's home directory on the server, for example, \\jupiter\home\%USER%. The variables %USER% and %USERNAME% are Windows NT variables that dynamically refer to any user.

Example 6-3 Calling a logon Script

REM Sample script to do a copy operation
copy \\saturn\\Dir1\Dir2\*.* c:\tmp\planets
REM
REM Now invoke individual user's logon script
set USER=pat
set HOME=\\jupiter\home\%USER% 
cmd /C %HOME%\%USER%.bat

The script in Example 6-4 runs an executable over NFS.

Example 6-4 Running an Executable over NFS

REM
REM Use predefined NT environment variable
dir %SystemRoot%
REM Remotely run residing executable. 
%HOME%\regmon.exe

SNC Scripts

SNC scripts are read from an NFS server in the Solstice Network Client network. Using SNC scripts, clients can access system policies, user profiles, logon scripts, and other SNC scripts stored on an NFS server.

In a PC-Admin network, SNC scripts are used to manage and control the environment of PC-Admin clients. These scripts can be adapted to manage Windows 95 and Windows NT client in a Solstice network. The SNC scripts and the script interpreter should be copied to the /opt/MSPolicy directory on the authentication server.

This section:

Compares PC-Admin SNC scripts on PC-Admin and Solstice Network Client computers
Describes how to run existing SNC scripts on Windows 95 and Windows NT systems running Solstice Network Client software
Describes how to run the script interpreter, using the sunwrun command.

For detailed information on SNC script directives, turn to Appendix C, SNC Script Directives.

Scripting on PC-Admin and Solstice Network Client Computers

Table 6-1 compares scripting features on PC-Admin client and Solstice Network Client computers.

Table 6-1 Comparison of Features on PC-Admin Client and Solstice Network Client


Script Feature	PC-Admin Clients	Solstice Network Clients
Script server	Any NFS server designated by DHCP	A server running the `rpc.pcnfsd` software.
Location of scripts on the server	Stored in the DHCP databases.	`\opt\MSPolicy,` which is created on the authentication server.
Centralized script management	Yes	Yes
Preemptive logon scripts	Yes	Yes
Supported events	Login, Logout, Boot, Shutdown	Login on Windows 95 and Windows NT Logout on Windows 95
Script hierarchy (Site, Group, User)	Yes	Yes
Scripts controlled by environment variables	Yes	Yes
Modification of environment variables	Local and Global	Local
Command to remotely set drive mounts	`MOUNT`	`MOUNT`
Directives (script commands)	20 script commands for 16-bit client	20 script commands for 32-bit client
Global environment variables	Yes	Environment can be passed to `LAUNCH`ed applications only.
Support for NIS/NIS+ environment variables	Current User, Current Group, Secondary Group	Current User, Current Group, Secondary Group

Running SNC Scripts

If you have created SNC scripts that run in your PC-Admin network, you can run these scripts from any authentication server to manage the 32-bit clients in the Solstice network. The Solstice Network Client software includes a script interpreter (sunwrun.exe) that interprets new SNC scripts or existing PC-Admin SNC scripts. Although there may be minor differences, you should be able to run your existing PC-Admin SNC scripts with no changes. Differences are described in "SNC Scripts on PC-Admin Clients and Solstice NFS Clients".

During installation, the script interpreter is installed on the Solstice Network Client in the directory C:\Program Files\Solstice\Bin\sunwrun.exe. Copy this file to the /opt/MSPolicy directory on the authentication server. The SNC scripts are read from the server and run on the client.

Using SNC scripts, clients can access system policies, user profiles, logon scripts, and other SNC scripts. If you have created scripts for your PC-Admin clients, you can adapt those scripts to run on the client in a Solstice network. To reuse the SNC scripts, use the following procedure.

To Adapt PC-Admin SNC Scripts

Copy the SNC scripts to the /opt/MSPolicy directory on the authentication server.

Rename or copy login.snc to either ntlogon.snc (on Windows NT) or winlogon.snc (on Windows 95).

Rename or copy logout.snc to either ntlogout.snc (on Windows NT) or winlogout.snc (on Windows 95).

Running the Script Interpreter

You can run the script interpreter to develop and debug new scripts. The sunwrun command invokes the script interpreter, which automatically runs the appropriate SNC scripts when the user logs in.

To run the command, type:

sunwrun.exe [-ripn] filename.snc

You can specify multiple file script file names on the command line. Each file name must end with the .snc extension. The interpreter will execute each file in order until a script exits with a non-zero exit code or all files are processed.

Available options include:

`-r`	Causes the script interpreter to reset the shared environment before interpreting the first file.
`-i`	Causes the script interpreter to reset the shared environment after interpreting the last file.
`-p`	Causes the script interpreter to execute only files from the location specified in the `SNDRIVE` variable.
`-n`	Causes the script interpreter to exit immediately after executing the last script file, rather than waiting the default 5 seconds provided to enable the user to view the output.

SNC Scripts on PC-Admin Clients and Solstice NFS Clients

While, for the most part, you can run existing PC-Admin SNC scripts unchanged, there are some differences that you should be aware of.

Some commands that were run on PC-Admin clients are ignored by the script interpreter (see "Ignored Script Directives").
New directives read and write to the system Registry (see "New Script Directives for Windows 95 and Windows NT Clients").
Environment variables are handled differently (see "Environment Variables Local to SNC Scripts").
With the addition of NIS+ support, the NIS and NIS+ values are handled differently (see "NIS and NIS+ Changes").

Ignored Script Directives

The following directives are ignored by the script interpreter.

Command	Function in PC-Admin
`LOGIN`	Starts the Microsoft Windows Login dialog box
`LOGOUT`	Logs out current user and set current user ID to `nobody`
`RESERVE`	Prevents users from mounting drives
`EXPORT`	Copies local to global variables
`STOP`	Shuts down client's connection to network
`MOUNT` `-o` `preserve`	Prevents user from unmounting a drive or printer
`MOUNT` `-o` `type`	Media type (`cdrom` or `std`)

New Script Directives for Windows 95 and Windows NT Clients

New commands are available that enable you to read and write to the system Registry.

Read Values from the Current Registry

The SET REG command enables you to read values from the system Registry into a variable. This is analogous to the SET NIS command. The keys HKEY_LOCAL_MACHINE may be abbreviated to HKLM and HKEY_CURENT_USER may be abbreviated to HKCU.

Write Values to the Registry

The REG directive command enables you to write to the system Registry. This command should be used with great caution.

For example, the command REG NEWKEY keypath creates a new key, and the command REG DELKEY keypath deletes the named key.

NIS and NIS+ Changes

Solstice Network Client supports both NIS and NIS+ on Windows 95 and Windows NT clients. The SET NIS directive looks up values in either or both NIS and NIS+, depending on the configuration of the local machine.

To facilitate backward compatibility, you should use NIS table names, unless you KNOW that you are using NIS+ in native (non-yp) mode. If you are using NIS+, do NOT add the trailing org_dir to the table name.

If NIS+ is enabled, table names are converted according to these rules:

The first period in a name is converted to an underscore.
The string org_dir is appended to the name.

For example,

auto.home becomes auto_home.org_dir
passwd becomes passwd.org_dir

If you are adapting PC-Admin scripts, note that the return value from NIS+ can be different from NIS, so you may need to use the SET STR command to alter the result.

The SET STR VAR=# %OTHERVAR and SET STR VAR=* %VAR% directives are useful for this purpose. See the description of SNC directives in "SNC Script Directives".

Environment Variables Local to SNC Scripts

Environment variables are handled as in PC-Admin, but are preserved across invocations in the Registry. Exported variables (using the EXPORT directive) are not placed in the Windows global environment. However, any application that is started will have the exported variables set in its environment.

In addition to variables explicitly set in the SNC script, the PC-Admin server sets local variables on clients each time a user logs in. For a list of SNC script variables, see "Environment Variables Local to SNC Scripts".

In general, 32-bit applications should use the system Registry for application-specific data and not rely on the environment.

System Policies, User Profiles, and Scripts in an NT Domain

If you have an NT domain, you can set up roaming and mandatory user profiles on an NFS server. When a user logs in to a client running Solstice Network Client software, the user profile is downloaded from the NFS server. This allows you to take advantage of the speed and power of a Solaris server.

However, before setting up system policies, user profiles, and logon scripts you should be aware of the following restrictions in the way these features work on Solstice Network Client computers that are part of an NT domain.

System policies - Users cannot download system policies from an NFS server. This is true whether the user has a local or domain NT user account on the client.
Logon scripts - Users cannot download the ntlogon.bat script from an NFS server to a client running Windows NT Workstation. Users can download the ntlogon.bat script from an NFS server to a client running Windows NT Server.
User profiles - Users can download user profiles from an NFS server to all clients running the Solstice Network Client software. If you include any files, for example a bitmap file as a background, in user profiles for NT domain users, those files must be stored on the client. If they are not stored on the client, the user profile will not be downloaded.

Troubleshooting

Table 6-2 presents possible solutions to common problems that can occur in setting up and managing a user's work environment on clients running Windows NT.

Table 6-2 Troubleshooting on Windows NT


Problem	Possible Cause	Solution
A user logs in and sees the message, `Cannot` `create` `user's` `profile` `in` `\\server_name\ profile_path\.pds`	The client cannot mount the directory specified in the profile path. This might happen if you log in to the client with a different user name than your NT user name.	Make sure you typed correct UNC format for the `\\server_name\profile_path` and that the top-level directory exists and is shared from the server. Press Ctrl+Alt+Delete and log in using a user name that exists on both NT and Solaris.
The user profile cannot be downloaded from the server. The local copy is used instead.	The client is part of an NT domain, served by an NT domain controller and the user profile includes a file (for example, a bitmap for a background) that is not stored on the client.	Copy the included file to the client or remove it from the profile.
System policies are not downloaded from the server.	1. The system policy file (`ntconfig.pol`) is not in the `/opt/MSPolicy` directory on the user's authentication server. If you have more than one `authentication` server on a network and have not copied the `ntconfig.pol` file to all servers, the user might be authenticated by a server that does not store the system policy files.	Copy the `ntconfig.POL` file from an NT workstation or server to each Solaris server running the `pcnfsd` daemon on the network. Log in to the server and verify it is running a `pcnfsd` daemon. If you have more than one authentication server on a network, copy the `ntconfig.POL` file to each authentication server. Or, specify the authentication server that contains the `ntconfig.POL` file by Selecting Solstice NFS Client->Properties->Security->Use a Specific Authentication Server.
System policies are not downloaded from the server.	2. The client is part of an NT domain, served by an NT domain controller. Users cannot download system policies from a Solaris server to a Solstice Network Client machine that is part of an NT domain. This is true whether the user has a local or domain NT user account on the client.	Store the system policy file on the domain controller

Table 6-3 presents possible solutions to common problems that can occur in setting up and managing user profiles, system policies, and login scripts on clients running Windows 95.

Table 6-3 Troubleshooting on Windows 95


Problem	Possible Cause	Solution
System policies are not downloaded from the server.	The system policy file (`config.pol`) is not in the `/opt/MSPolicy` directory on the user's authentication server. If you have more than one authentication server on a network and have not copied the `config.pol` file to all servers, the user might be authenticated by a server that does not store the system policy files.	Copy the `config.POL` file from a Microsoft Windows 95 client to each server running the `pcnfsd` daemon on the network. 2. Log in to the server and check to see if it is running a `pcnfsd` daemon. 3. If you have more than one authentication server on a network, copy the `config.POL` file to each authentication server. Or, specify the authentication server that contains the `config.POL` file by selecting Solstice NFS Client->Properties->Security->Use a Specific Authentication Server. 4. Make sure the Solstice NFS Client is selected as the primary network logon in the Network dialog box.
User profiles are not downloaded from the server.	The Solstice NFS Client is not selected as the primary network logon.	In the Network option in Control Panel, select Solstice NFS Client as the primary network logon.
	NIS or NIS+ is not configured as the name service on the client. If you configure the DNS or Files-based name service but not NIS or NIS+, the Automounter does not automatically mount user's home directories, and user profiles stored in those directories are not downloaded to the client.	Make sure NIS or NIS+ is set up on the server and then select NIS or NIS+ as the name service on the client.