Windows NT 4.0 Profiles and Policies

Defining the user environment via Profiles and Policies

This is a guide for experienced NT administrators having difficulties with Microsofts dumb new implementation of System Policies in NT 4.0. We had to do it and finally documented what we have found/learnt. Many thanks to the other News Group subscribers who hacked this out with us. Many curses to Microsoft for giving us headaches. This stuff is not documented in the otherwise highly regarded resource kits. Great product but...

• Windows NT defines the user environment in two ways;
  Profiles and Policies are, as we all now know, completely different animals.
• The profile defines the user environment within the parameters set by the system policy.
• All users have a profile whether they like it or not. They may use the default profile, but they all have a profile. The system resources available to any user can be less than the system policy allows for that user but cannot be greater.
• It also seems that the system will only update a profile if a change has been made to the profile defined in the login script. (not understood yet, so don't take this as hard fact - I think profile caching might be a key to this behaviour)
• Many facets of Policy and Profile have been fixed in NT4.0 with the release of SP6. If you are not using this Service Pack, we strongly recommend that you do so.

Policies

A policy file can be thought of as a Registry Hive. If you keep that in mind, it might all click for you a bit faster!

• The standard (default) Policy on your Server will contain at least two policy items. You can add others.
  • The first standard entry is Default Computer which equates to the Registry entries under the HKEY_LOCAL_MACHINE hierarchy.
    note: it would appear that this section of the target machine registry gets recreated at each REBOOT.
  • The second standard entry is Default User which equates to the HKEY_CURRENT_USER hierarchy.
  • The implementation of domain wide policies depends on the workstation registry. The workstation will only receive a system wide policy if the check box Default Computer/Network/System policies update has been ticked and set to automatic. This then picks up the system policy from the \\PDC\NETLOGON share. If you are feeling masochistic, you can choose manual mode and enter/guess the path to the PDC/BDC NETLOGON share.
  • Furthermore one or more user and group entries can be added and these too are applied to HKEY_CURRENT_USER for the user or the member of the group(s). The order of execution for the user policy is first:
    1. the defined user policy (if it exists)
    2. if none has been defined then
    1. the Default User policy on the PDC is used then:
    2. any group policies are implemented.
       Note that if you have multiple groups, the group allocated highest priority will be applied first, then the others in descending order.
    If you missed the key issue there, I'll point it out. If you have a defined user policy for an individual, it gets applied all by itself and Default User and Group Policies do not get applied.
• The system policy for domains by default lives in the \\PDC\NETLOGON share and is called NTconfig.pol. The local path on the PDC to NETLOGON is %SystemRoot%\system32\Repl\Import\Scripts
  (Win95 expects a file called config.pol and it must initially be stored into NETLOGON on the PDC)
• In order to configure a policy for groups of users:
  1. You use the poledit utility to open the current system policy, usually \\PDC\NETLOGON\NTconfig.pol.
  2. Add the group or individual by selecting the appropriate icon on the menu strip.
  3. Double click on the group or user icon and then define whatever you wish for the policy.
• Note here that in the Poledit registry editor, a grey box means not to change whatever value exists in the registry on the remote machine that the user is logging on to. If the value on the local workstation is different to that in the system policy it will only be changed if the corresponding value in the system policy is set, that is, not greyed out. White (blank) means clear the registry value, while a check means enforce a registry value.
• If you have a network with Backup Domain Controllers, you need to copy the file \\PDC\NETLOGON\NTconfig.pol to the %SystemRoot%\System32\Repl\Export subdirectory, for replication to the BDC's. Most people who implement this type of network recommend that you directly copy the files to the %SystemRoot%\System32\Repl\Import\Scripts subdirectory of each BDC to ensure the message gets through. Do remember to turn on the directory replication service or your export will sit there forever!
• Microsoft's README (Q142640) file says:
  

  System Policy

  System policy can be defined for both users and groups. The order of precedence of system policies can be set for instances where a user is a member of multiple groups. Three settings are available for each policy item (enabled, disabled, or not specified). These policy settings are saved to the NETLOGON share of the PDC, where they are replicated to the BDCs in the domain. When a user logs on, the NTConfig.pol file (depending on the client) is parsed for policy settings to apply.

  When a user logs on, the user policy (as defined in System Policy Editor) for the user is applied. If a user-specific policy is not applied, the default user policy is applied, followed by the group policies in priority order:

  • The lowest priority (as defined in System Policy Editor) group policy for the user is applied.
    (set this using Options|Group Priority)
  • The next highest priority group policy is applied, and this step repeats until the policies for all of the user's groups have been applied.
  • If you have multiple groups defined in the System Policy then the first group in the order will be implemented. If you leave a box greyed out then the next group's selection will be implememted and so on. If they are all grey then it will be set to the workstation default value.

• IMPORTANT (Listen carefully!!)
  • Policy being applied requires write access?
    NT 4.0 without Service Paks: On the workstation you MUST grant read/write permission to all users for the %SystemRoot%\Profiles\Policy subdirectory. This was the biggest gotcha in the implementation of System Policies in NT 4.0. This should be a function of the OS. The user should not have to access such an important file. It was our feeling that this was a bug in Windows NT 4.0.
    See the KnowledgeBase article Q157673 that confirmed this! A fix was supplied in NT4.0 SP2. However even this fix still had problems. You must still grant add/read to your %SystemRoot% so that the policy can be downloaded. This is still an appalling bug as far as we're concerned.
    Can Microsoft ever get it right? Yes! SP6 fixes this!
  • It is essential that for workstations to get a copy of the policy, the Default Computer\network\system policy updates\remote updates box is checked, and set to Automatic, unless you are feeling brave enough to define a path manually. I mean it should be simple, but in a multiple domain controller environment...
• Save the system policy file in the NETLOGON share (better known as %SystemRoot%\System32\Repl\Import\Scripts subdirectory) of the PDC. The file should be named NTconfig.pol.

Policy Troubleshooting Tips

• Is your SERVER name longer than 13 characters? We've had feedback that says that a long server name will cause Policy updates to fail! Install SP6 to solve this.
• It might seem that changes to the policy will only be picked up upon login by a user for the first time after the workstation is restarted, however we have found that this is NOT the case! We kept getting bitten because we would login as Administrator to see what happened - which then promptly did behave correctly, so ensure that %SystemRoot%\Profiles\Policy on the workstation(s) has the correct (write) permissions on the directory and files within it. If you're running SP2, then the permissions problem shifts to your %SystemRoot% directory. Install SP6 to solve this.
• Check what remote policy the workstation is actually using. Login, then go back to your server and connect to the workstation with System Policy Editor. Check the stuff in Local Computer and make sure that it matches what should be there. To do this, use the file/connect option in the Poledit utility.
• Check that your users have read access to the NETLOGON share. The security should be Everyone:READ and Administrator:FULL for both the share and normal security settings. You wouldn't have forgotten that now, would you?
• Having problems with groups? Make sure your users are being entered into a global group, not a local group!
• Check that you actually made the user a member of the group that you're trying to apply to them!
• Wrestling with Win95?
  Create your Win95 policy on Win95 and copy it to the NT NETLOGON share as config.pol
  Don't forget that you have to put grouppol.dll into the windows\system directory on your Win95 machine.

Profiles

Profiles are much simpler.

• They exist as a group of directories that define the user environment.
• The location for a domain users user profile can be set in the user manager for domains profile tab. The location must be specified as a UNC name.
• If not set, they default to the profile in the %SystemRoot%\profiles\Default User directory, not the %SystemRoot%\profiles\all users directory that you might have thought.
  Tip: if you put the profile for Default User in your NETLOGON share, any workstations with an older copy will see this and update automagically.
• The best way to set this profile is to have a dummy account especially for user profiles. Login, make any changes, then save the profile. The profile is then copied to the desired location by the system utility in the control panel.
• This utility has a user profile tab. Select the user profile, then select copy. You then need to specify the location of the copy.
• Browse for the location, then set the permissions to allow users access. Press OK and the profile is now active.
• Microsoft's README file also says:

  User Manager

  Profiles are no longer limited to having .pds or .pdm extensions. Windows NT version 4.0 profiles have .man or .usr extensions, but they can have any extensions.

  If you have a mixed work environment of computers running Windows NT version 3.51 and Windows NT version 4.0, you should use the .man or .usr extensions for compatibility. When Windows NT version 4.0 encounters a profile with a .usr or .man extension, it will create a matching directory with the .pds or .pdm extension.

Profile Troubleshooting Tips

• You did put the profile path into the User-Manager->User->Properties, didn't you?
• The location must be specified as a UNC name. If you are using C:\blah\blah then this is wrong!
• Your users aren't in the GUEST group, are they? If so, profiles won't get saved!
• Roaming Profiles require that the location that you are storing the profiles under must be a share, otherwise you won't pick them up - and no, ADMIN$ will not work!
• Roaming Profiles get copied back to the server on logout. Make sure you update the profile with the user logged out!
• Are the clocks the same on the server and workstation? You may find that the workstation is saying that its cached copy is newer!
• Changed from a WORKGROUP to DOMAINs have you? Roaming Profiles will not get picked up if the workstation user still has a cached profile from when it was part of a WORKGROUP. You'll need to remove that, via Control Panel->System->User Profiles.
• Moving from machine to machine and finding things are different on each, even though your Roaming Profile is working? You need to clear the local profile that is being picked up from %SystemRoot%\Profiles\All Users on the workstation.
  You can also hack the workstation(s) Registry so that All Users resides on the server.
• If you want the profiles to stay in one spot, you have to disable the local caching of the profiles. This will slow things down, but if your network is fairly fast, it shouldn't matter much. You can do this by using Regedt32 on each machine to edit:

  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DeleteRoamingCache

  REG_DWORD

  Default:         0

  If the value of this entry is 1, locally cached profiles are deleted when users with domain profiles log off. Thus the only copy of the profile is on the server.

• Unclear on Mandatory profiles?

  Say you have a domain controller with a policy file on it that does not allow cached profiles.

  Using one default manditory profile for all users Add the .MAN extension to the ntuser file.

  If you use the .man extension on the folder in which the profile is stored, such as default.man then in the event of the workstation being off the net or unable to contact the server, this will cause the system to display a message telling the user that since it can not contact the domain controller, he/she can't be logged in. This is the NT 3.5x behaviour and can be useful! If you want the normal NT4 profile to behave in the same way, just give the profile a .man and make sure that you disable local profile caching on the target workstations. I haven't tested if an NT4 folder with .PDM works the same way.

  You can't share the folder with the .man extension. So, put it in the NETLOGON share and then point the users profile to \\PDC\NETLOGON\default.man.

• W95 and Profile locations.
  Yes, profiles work with Win95 clients too. The Win95 clients store their profile info in the users home directory, while the NT clients will store them in the Profiles directory.
  i.e. a user with both Win95 and NT access will have two different profiles.