Copio ed incollo qui degli appunti estrapolati da alcuni manuali, sono riportati di seguito come promemoria:
Roaming Profiles
A roaming profile is stored on a server. The profile is loaded to the local computer from the server whenever a user logs on to the network, regardless of which computer the user logs on from. Any changes the user makes to configuration settings are saved back to the profile on the server.
A roaming profile is stored on a server. The profile is loaded to the local computer from the server whenever a user logs on to the network, regardless of which computer the user logs on from. Any changes the user makes to configuration settings are saved back to the profile on the server.
In order to provide roaming profiles, you need to create a share for these profiles on a server. Here are the guidelines:
- You don’t have to use a domain controller; any server accessible to users will suffice. I name my folder Profiles (in a wild display of my creative tendencies) and also use the name Profiles for the share (you use the share name, not the folder name, when you enable roaming profiles for users).
Set permissions on the share to Full Control for Everyone.
- The shared folder cannot be configured for EFS.
- The shared folder’s volume should not be configured for Disk Quotas— if it is, be sure it’s a large volume and all users have large quotas.
Configuring Roaming Profiles for Users
To tell the system that the user logging on to the domain has a roaming profile, you onfigure the user’s account in the Active Directory Users and Computers snap-in.
Here are the steps to accomplish this:
1. Double-click the user’s listing to open the Properties dialog.
2. Move to the Profile tab.
3. Enter the UNC to the Profiles folder, using the share name, not the folder name,
and ending with the username. The username subfolder does not have to exist; it’s created when the roaming profile is created on the server.
How Roaming Profiles Are Created on the Server
The way the roaming user’s profile is created on the server depends on the circumstances under which the user is logging on to the domain. When the user logs on,Windows checks the user’s account to see if a user profile path exits. If it does (because you entered it in the Profile tab as described in the previous section), the system looks for the user’s profile subfolder in the specified profile folder:
- If the subfolder doesn’t exist, and the computer from which the user is logging on has a local profile for him, his profile subfolder is created on the server and the local profile becomes the profile written to the server.
- If the subfolder doesn’t exist, and the computer from which the user is logging on doesn’t have a local profile for him, his profile subfolder is created on the server, and the default user profile on the local computer becomes the profile written to the server.
- If the subfolder exists, it means that either of these two scenarios occurred previously (this is not the first logon since you enabled roaming profiles for this user), or it means that you prepopulated the user’s profile subfolder (covered next).
Problems with Unavailable Servers
The most common problem with roaming profiles is that the server that holds a user’s profile isn’t available at logon. When that happens, Windows loads locally cached copy of the profile. If the user has not logged on to the computer before, the system creates a new temporary profile. Temporary profiles are at the end of each session. Changes made by the user to their desktop settings files are lost when the user logs off.
If the server becomes available while the user is working, it doesn’t matter. Changes the user makes to the profile aren’t uploaded to the server at logoff. The rule of thumb is “if not available at logon, not available at logoff.”
If the server becomes available while the user is working, it doesn’t matter. Changes the user makes to the profile aren’t uploaded to the server at logoff. The rule of thumb is “if not available at logon, not available at logoff.”
Roaming Profiles
A roaming profile is stored on a server. The profile is loaded to the local computer from
the server whenever a user logs on to the network, regardless of which computer the
user logs on from. Any changes the user makes to configuration settings are saved back
to the profile on the server.
A roaming profile is stored on a server. The profile is loaded to the local computer from
the server whenever a user logs on to the network, regardless of which computer the
user logs on from. Any changes the user makes to configuration settings are saved back
to the profile on the server.
In order to provide roaming profiles, you need to create a share for these profiles on
a server. Here are the guidelines:
- You don’t have to use a domain controller; any server accessible to users will suffice. I name my folder Profiles (in a wild display of my creative tendencies) and also use the name Profiles for the share (you use the share name, not the folder name, when you enable roaming profiles for users).
Set permissions on the share to Full Control for Everyone.
- The shared folder cannot be configured for EFS.
- The shared folder’s volume should not be configured for Disk Quotas— if it is, be sure it’s a large volume and all users have large quotas.
Home Folders
A home folder is a directory you designate as the container for user documents. On a domain, this is usually a server-based directory, which facilitates backing up user data.
Servers are usually backed up regularly, whereas local workstations are almost never backed up, even if you threaten your users. You can also create home folders for users on their local workstations, but the My Documents folder usually fills that role.
Server-based home folders are created for individual users under a pre-created share. For example, create a folder named Users, with a share name Users, and give the Everyone group Full Control permissions. Then you can add subfolders for users (\\Server\Users\UserName).
Adding Home Folders to Profiles
To establish a home folder for a user, open the user’s Properties dialog in Active Directory
Users and Computers. Move to the Profiles tab (see Figure 21-10), select the Connect option (which is actually an automatic drive mapping), specify a drive letter, and then enter the UNC.
By default, Windows Server 2003 specifies drive Z: for home folders, but some old-time administrators (including me) follow the early tradition of mapping home folders to drive H:.
If the last section of the path (the username) doesn’t exist, it’s created immediately.
This differs from the creation of the username part of the path for roaming profiles, which isn’t created on the server until the user logs on to the domain.
It’s important to look at the home folder paradigm and make decisions about using this feature for some or all users. The big advantage to home folders is server-based user documents, which means you can be sure you’re backing up your company’s documents.
For roaming users, you automatically gain the advantage of server-based documents, because the profile that’s downloaded to the local computer during logon contains the user’s My Documents folder. When the user logs off, the profile is written back to the server, including the My Documents folder and its contents.
However, if you use home folders, when roaming users log on to the domain, they don’t have to wait for the My Documents folder (and all its contents) to be copied to the local computer. Instead, a pointer to the server-based home folder is part of the profile, making logon and logoff processes much faster (and saving you any worries about disk space on the local computer).
Use Group Policies to Redirect My Documents
Instead of letting users redirect their My Document folders manually, you can use a group policy to manage redirection. Open the GPE for the domain, or for an OU that contains the target users, and go to User Configuration\Windows Settings\Folder Redirection\My Documents. Right-click the My Documents object in the console pane to open its Properties dialog, with the Target tab in the foreground (see Figure 21-11).
The Setting field has a drop-down list with the following choices:
Basic: Redirect everyone’s folder to the same location Advanced: Specify locations for various user groups
Advanced Redirection Advanced redirection is for larger enterprises, where you want to be able to target specific servers based on location, or on groups. If you’ve created security groups that are related to departments (for instance, an accounting group), this feature works beautifully. When you select this redirection option, the dialog displays a Security Group Membership box Click Add to select a group and specify the target sharepoint. Repeat for each group and sharepoint you want to use for this policy.
In the Target folder location field, select one of the following options:
Redirect to the user’s home directory Select this option if you’ve created
home folders for your users.
Create a folder for each user under the root path Use this option after you’ve
created a sharepoint on a server for holding user documents.
Redirect to the following location Use this option if you already have
subfolders for each user. Enter the %username% variable as the end of the UNC.
Redirect to the local userprofile location Reverses any of the other selections
and copies the data back to the user’s local profile.
Configure the target folder by making the appropriate selections.
- Grant the user exclusive rights to My Documents This setting, which is selected by default, sets permissions for the %username% only, keeping everyone else out (including administrators). If you, as an administrator, want to get into the folder, you have to take ownership of the subdirectory. Deselecting this option sets permissions as determined by inheritance (which depend on the permissions you set when you created the parent folder).
- Move the contents of My Documents to the new location Selected by default, this option does exactly what it says it does. The next time the user logs on to the domain, her documents are automatically moved (not copied) to the target folder. This happens whether the user is a local or roaming user.
- Policy Removal This option lets you select what happens when the policy no longer applies. There’s not really an expectation that you’ll return to the GPE and discard your policies on direction; instead, this option exists because the system assumes you’re applying the policy to an OU. Your selections here determine what happens to a user you move out of this OU.
- My Pictures Preferences Use this option to determine whether the My Pictures subfolder is affected by the policy
Mandatory Profiles
Amandatory profile is a roaming profile that can’t be changed. Even though users
may change some settings during a session, the changes aren’t saved back to the server-
based profile and won’t be available the next time the user logs on to the network.
Administrators, however, can make changes to mandatory user profiles. Because
mandatory profiles can’t be changed to reflect individual user settings, they can be
applied to groups of users.
As handy as all this may seem at first glance, I personally advise administrators
to avoid the use of mandatory profiles, because they’re fraught with problems. Indeed,
I’ve rarely seen a set of circumstances that calls out for mandatory profiles. You have
hundreds of group policies available to prevent users from making changes to their
environment, and that’s a far safer approach than using mandatory profiles. However,
in case you have some cogent reason to implement mandatory profiles that I haven’t
thought of, I’ll go over this feature.
Mandatory profiles are very much like roaming profiles; in fact, they really are roaming
profiles. However, the profile must exist in the user’s server-based profile subfolder before
the user logs on, because the client workstation can’t write the profile to the server.
When you create the user’s profile subdirectory, you must actually create the
subdirectory on the server, because the workstation can’t do this automatically as it can
with roaming profiles. Configure permissions for Read and Execute.
In addition, youmust add the extension .man to the last component of the UNC.
For example, if you were creating a regular roaming profile, you’d format the UNC in
the user’s Properties dialog as \\Server\ProfileFolder\UserName. For a mandatory
profile, the UNC format is \\Server\ProfileFolder\UserName.man.
After you copy a profile to the user’s subfolder, rename the hive file, NTUSER.DAT,
to NTUSER.MAN, which makes it read-only. The .man extension on the subfolder alerts
Windows Server 2003 to the fact that the profile is mandatory, which, in turn, makes
Amandatory profile is a roaming profile that can’t be changed. Even though users
may change some settings during a session, the changes aren’t saved back to the server-
based profile and won’t be available the next time the user logs on to the network.
Administrators, however, can make changes to mandatory user profiles. Because
mandatory profiles can’t be changed to reflect individual user settings, they can be
applied to groups of users.
As handy as all this may seem at first glance, I personally advise administrators
to avoid the use of mandatory profiles, because they’re fraught with problems. Indeed,
I’ve rarely seen a set of circumstances that calls out for mandatory profiles. You have
hundreds of group policies available to prevent users from making changes to their
environment, and that’s a far safer approach than using mandatory profiles. However,
in case you have some cogent reason to implement mandatory profiles that I haven’t
thought of, I’ll go over this feature.
Mandatory profiles are very much like roaming profiles; in fact, they really are roaming
profiles. However, the profile must exist in the user’s server-based profile subfolder before
the user logs on, because the client workstation can’t write the profile to the server.
When you create the user’s profile subdirectory, you must actually create the
subdirectory on the server, because the workstation can’t do this automatically as it can
with roaming profiles. Configure permissions for Read and Execute.
In addition, youmust add the extension .man to the last component of the UNC.
For example, if you were creating a regular roaming profile, you’d format the UNC in
the user’s Properties dialog as \\Server\ProfileFolder\UserName. For a mandatory
profile, the UNC format is \\Server\ProfileFolder\UserName.man.
After you copy a profile to the user’s subfolder, rename the hive file, NTUSER.DAT,
to NTUSER.MAN, which makes it read-only. The .man extension on the subfolder alerts
Windows Server 2003 to the fact that the profile is mandatory, which, in turn, makes
[update 2017.04.20]
today I would like to mention this interesting article that make an interesting 360° overview about roaming profiles and folder redicretion: