RSS 

User Environment – profiles and group policy

The user environment and profile is critical to the user experience within a Presentation Server environment. Gabe Knuth walks us through some best practices when designing and implementing this environment. Understand the approaches for handling profiles and using group policies for defining profiles, folder redirection and other critical components to the user experience. (Running time: 37:13 minutes)

Tags: technical video
Views: 5,414
Rating: 5

Transcript : Hello. My name is Gabe Knuth. Today, I’m going to be talking about best practices in user profiles, folder redirection, and group policies. There really is no one-size-fits-all solution available. Each scenario has different requirements. We’re going to take a look at the most common configurations in use. You may use one of these recommendations, you may use all of them, or you may use none of them. But you’ll need to evaluate which solutions you use on a case-by-case, silo-by-silo, or even a user-by-user basis. The first thing that we are going to look at is group policies. I want to start off by saying that if you don’t have the Group Policy Management Console, get it. It will change your life. Prior to the Group Policy Management Console, there was no way to go back and see what changes you had made. It made troubleshooting a real pain for trying to find overlapping policies or misconfigured settings. The Group Policy Management Console also enables you to run what is called the Group Policy Modeling and Group Policy Results wizard to see an example of what policies would be applied to users, before you actually roll this out to those users. It’s pretty valuable when we’re talking about thousands of users, and one bad policy setting could lock them out of the entire organization. The most important thing I can say about group policies, before we get moving, is that there are so many options to configure, you can’t go crazy with it. There are many, many different ways that you can lock yourself out of your environment, lock your users out of their environment, and there are even some ways that you can lock yourself out of being able to go back and undo that change. So when you’re playing with group policies, be careful and make sure that you do this in a test environment on test users first. The first thing I want to talk about regarding group policies is the terminology involved, so that hopefully we can avoid some confusion down the road. There are three terms used regularly when speaking of group policies. We have the policy itself, the group policy object, and a linked policy. If we look under the Group Policy Objects folder, we see the policy objects that have been created so far. Many times these are simply called policies, such as the Default Domain Policy, which is included by default. In fact, group policy objects are collections of singular group policies. This is similar to calling everything in the registry a key, even when most objects are actually values. To show you the difference, if we select the value Default Domain Policy and then look at the settings, we can see the policies inside that are configured. We see there are many, many policies in there, even though they are all contained inside of one policy object. Now, having these policy objects in this Group Policy Objects folder only makes the policies available to the domain. In order to apply a policy to a container, it must be linked to the container. You’ll notice the shortcut icon next to each of these policy objects underneath organizational units in the domain. These are shortcuts, or links, to the group policy objects. This allows administrators to use the same group policy objects for many containers, instead of having to create and manage duplicates of the same policy. If we wanted to apply another policy to the Terminal Servers container, we can go here, right click, and Link an existing GPO, and now we are able to select one of the group policy objects that we have already created. If we want to create a new policy object underneath the Terminal Servers container, we would right click and say Create and Link a GPO Here. What this will do is it will create a group policy object in the Group Policy Objects folder and automatically link to it from this container. My favorite method for using group policies is to create many policies for many settings. So I usually have one default policy that applies to all users, all those settings that every user should have, including yourself as the administrator. That would be in the default policy. The default policy applies to all authenticated users, regardless of who you are, unless you configure a user here that has been denied the access to apply the policy. We’ll get into that in a little bit. Inside the default policy is where you can specify things, such as Start Menu and Taskbar changes, such as adding Logoff to the Start Menu, very important, especially for administrators, because sometimes, once in a while, we’ve all done it. You go to Start, Shut Down, forget to change the dropdown box to logoff, and instead you’re restarting your server, or worse, shutting it down from a remote location. There are many, many settings in this window, and a lot of them are very helpful. Forced classic Start Menu is one of my favorite frivolous settings, because it gives the users a more familiar environment to work in. A lot of users aren’t familiar with the Windows XP style of Start Menu and are more comfortable with the classic style. As you move on through your policies, you can make changes to the Control Panel. You can even hide the Control Panel applets or prohibit access to the Control Panel entirely. This is a very good idea, because users still find a way to get in there. And if nothing else, it’ll reduce a few Help Desk calls that are asking what the heck this Control Panel is for. Another thing I like to do with policies is to create many one-off policies for settings that may or may not be used for everybody. In this case, I created a policy called Default Internet Explorer Settings. Inside this policy, I set the home page to www.google.com. Now, I may not want everybody to have www.google.com as their home page, or maybe some users don’t want google.com as their home page. For situations like that, I’ve created a group in Active Directory Users and Computers called PE_IE Policy. The PE at the beginning stands for policy exempt. I can add a user to this group, say, Brandon. Then I’ve configured this policy to deny the PE_IE Policy group access to apply this policy. That way, when a user logs in, they’ll still see this policy, but they’ll see that they’ve been denied the ability to apply it, and their default settings will override. This allows a little bit more flexibility, because group policies can be so rigid. Sure, you could create different organizational units, and have these policies apply only to users in this organizational unit and not in another organizational unit. But I prefer to keep the Active Directory structure neat and use some of the tools built into group policy to manage who has the policies applied to them and who does not. The last part of group policy that I want to take a look at is using group policies only for Terminal Servers. So far, we’ve seen applying policies directly to the users. Notice that we have our policies underneath the Video Users container in Active Directory. These settings will apply to these users, no matter where they log in. We also have a container called Terminal Servers. Underneath there is where we put our Terminal Servers, which could be Citrix Servers or Terminal Servers. In here we have a server called VIDEOTS. If we want to apply the Default IE settings policy only when you log in to a Terminal Server, we need to link to the Default IE settings policy. We can then delete it from this container, and it will no longer be applied to everybody, no matter what computer they are logged in to. Now, only when a user is logged in to a Terminal Server will this policy be applied. There are a few settings that need to be changed, though, in order to make this happen. First, you need a default policy for our Terminal Servers. Then we need to edit that policy. Go to Administrative Templates, System, Group Policy, and configure User Group Policy loopback processing mode. We need to enable it, and we need to change the mode to Merge. What this will do is it will merge the settings from the Terminal Server policies with the settings from the user’s organizational unit policies. In the case of a conflict, the Terminal Servers policies will override the user’s policies. That way you can ensure that the users are seeing only what you want them to see, based on the Terminal Server policies. The last thing I want to talk about with regards to group policies is something called Group Policy Preferences. Microsoft got the technology for group policy preferences with their acquisition of the company called Desktop Standard in 2006. Group policy preferences uses a GPMC style console to allow the configuration of settings as preferences, as opposed to policies. The difference is that these settings are not enforced as in a policy, only configured as a default preference. For instance, you could configure the classic Start Menu as a group policy object, and users would not be able to change that if they didn’t like it. With group policy preferences, you configure the classic Start Menu as the default option for everybody, but if there were a few users that wanted the XP style Start Menu, they would be able to go in and change that. Group policies will actually lock you out of the interface to change the setting that you’ve configured via policy. Group policy preferences just makes it a default setting. A few more little things to mention about group policy preferences before we move on. First, it’s not out yet. It is part of Windows Server 2008, and it will actually be built into the GPMC in that release. Users can also deploy group policy preferences on Windows Server 2003 by installing the Remote Server Administration Tools. But you have to install that toolkit on a workstation running Windows Vista Service Pack 1, which also isn’t available until 2/1 of 2008. No new services are required, but you do need Client Side Extensions for any client that will use group policy preferences. These Client Side Extensions will allow you to use group policy preferences on Windows XP with Service Pack 2, Windows Vista, and Windows Server 2003 with Service Pack 1. Windows Server 2008 already has the CSEs installed. Next, we’re going to talk about Folder Redirection. Folder redirection is configured via group policy and allows you to point otherwise local folders, such as My Documents, or Start Menu, or the Desktop, to network locations. This enables centralized access to these folders, regardless of where the user is logged in. It also means that instead of important files being stored on the local machine that is not typically backed up, they’re stored on a file server that typically is backed up. We’re going to go to our Domain Controller now, where the GPMC is already running. We already have the Group Policy Object Editor open to our default policy. You’ll notice that underneath User Configuration, Windows Settings, we have a folder called Folder Redirection. In here are the four folders that we are able to redirect by default. There are other ways to redirect folders. You can make custom ADM templates for group policies that you can configure underneath Administrative Templates, or you can go into the Registry Editor and edit these on a per profile basis. Later on, we’ll cover how you can copy a profile to be used not just by one user, but by all your users. So let’s go back into our Group Policy Editor, and we’ll take a look at, say, the My Documents properties. In here under Setting, we’ll see we have basic and advanced, along with not configured, which is the default option, of course. Underneath basic, we see four options for our settings. The first one is redirect to the user’s home directory. This is the simplest option, and it’s pretty widely used. In this case, it redirects My Documents to the home directory location set either via group policy or in the properties of the active directory user object. Next, we see these other options. Redirect to the following location, redirect to the local userprofile location, or create a folder for each user under the root path. For each of these, you are able to configure an actual location for where these files will go. If you choose create a folder for each user under the root path, all you need to do is enter in a server name and a share name, and you’ll see it will create a named user folder and then a My Documents folder underneath that location. If you say Redirect to the following location, you actually have to specify where this will go. In this case you could, if you wanted to, redirect everybody to the same My Documents location. And that way everybody…everybody’s My Documents folder would go back the exact same folder, and everybody will be able to see the same set of documents. That’s not such a common use for this, but it is possible. A much more common way to do things would be to add an environment variable here, such as %username%. If you wanted to just redirect them right to a certain location, this works out great. However, it is not a whole lot different than create a folder for each user under the root path, which automatically takes care of it for you, just without the environment variable. And then Redirect to the local userprofile location actually redirects My Documents to a folder on the local machine, which is not a recommended setting, especially in a Terminal Server environment. Now, if we look back at our main settings, let’s take a look at Advanced. In here we have the same options for the location of the files. It’s just that now we can specify who is redirected to what location, based on groups. So here we use active directory groups, and we could actually say that domain admins are redirected to their own home directory and domain users are redirected to a certain folder created for each of them on our file server secret share. And so now domain admins go to this location, and domain users go to this location. Before we move on, I want to take a look at what folders we should be redirecting, and when we should be redirecting them. In most published application environments, administrators will choose to redirect the My Documents, Application Data, and Favorites folders. In published desktop environments, the Desktop and Start Menu should also be considered. This is because, in a published application environment, users don’t see the desktop or the Start Menu, so there’s no reason to configure that setting. But in a published desktop environment, they do see a Desktop and a Start Menu, and so it might be worthwhile considering redirecting those folders. Folder redirection has many benefits. Among them, is a decreased login and logoff time. Since information is stored in separate shares on a file server, not in the user’s profile, the profile load time when a user initially logs in is significantly reduced. Also, this makes the information stored in those folders portable, such as if you were to use mandatory profiles, or the user wasn’t always using a Terminal or a Presentation Server. The only problem is that applications that refer to the Application Data folder might take a little bit longer to accomplish certain tasks, since they have to go across the network to get to that data and bring it back down to the machine that they’re working on. So now, we need to talk about Profiles. Let’s close out of our Registry Editor. We already know that there are different types of profiles. We have mandatory, roaming, and local. There’s also a term called flex profile, but we’ll get to that in a little bit. For this video, we’ll assume roaming or mandatory profiles are being used for user portability across servers. There are situations where you can and would use a local mandatory profile, but the concepts are still the same. Full local profiles should be avoided in a Citrix or Terminal Server environment, because they’re not very useful, and they typically make a pretty big headache for administrators. Profile settings can be configured via Group Policy or in Active Directory Users and Computers. In a user’s Properties, we can see the Terminal Servers Profile tab. In here, we can configure a profile path and specify a home folder location for when a user is logged in to a machine via Terminal Services or Citrix. This is very different from the Profile tab, which is for everything else. Anything in the Terminal Services Profile tab will override anything in the Profile tab in the event that the user logs in to something using Citrix or Terminal Services. In small environments, it’s probably just fine to use Active Directory Users and Computers to configure your Terminal Services profile, especially if everybody is sharing the same basic profile path. If they’re using mandatory profiles, and they all have the same absolute path, or if all of your users’ personal roaming profiles are also stored in the same share location, in that case, you can just use a network location, such as fileserver\share$\%username%. That way, you can use the same string with that environment variable for all of your users. Now let’s take a look at configuring user’s profiles via group policy. First, I need to mention that it’s only possible to apply mandatory profiles to users via group policy after you have applied Windows Server 2003 Service Pack 2. Prior to that, you had to apply mandatory profiles in the user’s properties in Active Directory Users and Computers. So we’ll go to the Group Policy Object Editor. We already have the Default TS policy open. Under Computer Configuration, Administrative Templates, Windows Components, and Terminal Services, we see Set path for TS Roaming Profiles. In here, we can enable this. We configure a profile path to the server, the profile share. And, if we were just using regular roaming profiles, this would be all we need, because it will append the user’s username on the end of this profile path. If we were going to use mandatory profiles, and we had a mandatory profile folder in the share, we would need to check this box that says Do not append user name to the profile path. That way, all the users will go right to this profile path and not to a path with their user name appended on the end. In addition, we also have the TS User Home Directory item, which is the equivalent of that small box at the bottom of the property window in Active Directory Users and Computers, where you specify whether…where you map their user drive, whether it be the H drive to this location or the Q drive to that location. This is where you do that via group policy. Specify location on a local machine or on the network. Specify the directory. Specify the drive letter. And you’re all set. Based on the environment size and complexity, it’s probably best to use group policy to configure your profile path in TS User Home Directory for larger environments, especially ones that have multiple server farms, or silos, or organizational units. The smaller the environment, the easier it is to make one blanket setting for all your users. The more complex, the more control you need as the administrator. One more thing we need to talk about is the Default User Profile. Underneath (C:), Documents and Settings, on every server you’ve ever built is the Default User folder. In here are the default settings for every new user that logs in to this server. Any user that’s already been created was created using this Default User folder. You’ll notice that in this Default User folder, underneath, say, the Start Menu and Programs, we see things like Remote Assistance and Entertainment, Program Compatibility Wizard and Synchronize. That’s because this is a lab server. We haven’t taken the time to go through and strip things out of there to lock it down, or to remove shortcuts to applications that we do not want people to use. The Default User profile needs to be modified ahead of time before you start putting users on there in a production capacity. The best way to modify the Default User is to actually replace the Default User. What I like to do is create a fake user. In our case, we’ve created a user called Fake User. When you log in as that user, and I already have a login here, you have a blank slate from which to configure what you want the user experience to be like. In our case, say we don’t want the Outlook Express icon to be in the Start Menu. And actually, you know what, we want the classic Start Menu. So we’re going to select that as well. And now, we have a classic Start Menu for our people. In here, we can remove things, such as Remote Assistance. We can remove other things under Accessories, such as Command Prompt, Calculator. You name it, we can get rid of it. But we see that we’ve made the setting. We’ve changed the Start Menu to be the classic style Start Menu when now we have icons on our Desktop and such. This is only an example. You can make all the customizations that you want that are common for all of your users. Now that we’ve done this, we will log off of our Fake User account. Then we’ll go back over to our Admin session. We’ll go to the System Properties Control Panel applet. Click on the Advanced tab. And under User Profiles, click Settings. We find our Fake User profile, which is the one that we’ve just gone in and made our changes to. We’ll click on this Copy To button. Here we’ll browse to the location where we want to copy this file. Since we want copy it overtop of the Default User folder, we’re going to select that folder there. Click OK. Now, this part is very important. This Permitted to use folder will actually go through and change all the file system permissions in the registry permissions on this profile so that anybody can use them, or the users you specify can use them. If we were to just do this as a file copy, like a normal drag and drop right on top of Default User, the Fake User user account would still have certain permissions deep down into the file structure and deep into the registry that other people would not necessarily have access to. By adding a group to the permissions for this profile, we’re able to ensure that a user does not get denied access to an area of the registry or file system that’s deep down in the structure, just because they don’t happen to be named Fake User. In this case, we will use Domain Users. And that way everybody who uses this will have no problems. Here we receive a warning. Default User already exists. You sure you want to do that? I sure am. And it won’t take too long, because the Fake User profile is actually very small. Now that we’ve created our new Default User, we need to log in as some other user that hasn’t logged in to this box before to see if the change worked. So we’ll go over to our server. We’ll log in as a user who hasn’t been in here before. And, as soon as their Desktop comes up, we’ll see that they indeed do have the classic Start Menu. Remote Assistance has been removed from Accessories. And they have these four icons on their Desktop. Now that we’ve seen how to create the Default User profile, I want to show you how to create the mandatory profile. But first, we’ll go into our Documents and Settings folder and create a folder called Mandatory Profile. This folder will serve as a location for our mandatory profile until we copy it off to a network location. Then we’ll go into the System Properties Control Panel again. Advanced, User Profiles, and Settings. Select our Fake User and click Copy To. We’ll browse to our Mandatory Profile folder and click OK. And, once again, we’ll go to Permitted to use and set this to Domain Users. We have to make sure that we select Groups in this Object types section, otherwise it won’t see the group. We’ll say Domain Users again. Hit OK. And OK again. Confirm that we want to overwrite that folder. And we’re all set. Now, the one thing that makes this different is that now, in order to make this a mandatory profile, we need to go in here and rename the ntuser.dat file to ntuser.man. This, in turn, makes it so that when a user logs in with this profile, if they make any changes, then they log off, none of their changes will be saved. That’s the difference between a mandatory profile and a regular roaming profile. Next, we’ll take our Mandatory Profile folder and copy that to a preshared folder that we have called profiles. We’ll paste this in there. Then we’ll go into Active Directory Users and Computers and configure a user, say Brandon Murphy, to use this mandatory profile as his Terminal Server profile. So here, our profile path will be \\videodc\profiles\mandatory profile. Now that we’ve configured his mandatory profile, we can go back here and log in to the server as Brandon Murphy. When we log in, we’re going to see the same looking desktop as we saw before. But in this case, if we were to make any changes to this, say, putting the Windows Update icon on the desktop, when we log off and then log back in, we’ll see that these settings were not saved. Notice the Windows Update icon is not there. So to wrap up the profiles section here, mandatory profiles are best used for task-oriented users, such as shop floor, call center, or contractors, even temporary users. But they’re not great for executives, and power users, and people that really know what they’re doing or want to make changes to their environment. For those users, roaming profiles should be considered. You’ve got to be careful with roaming profiles, though, because if you’re not using folder redirection, the roaming profile sizes can get huge, and that can really affect log on time. An excellent blend that could work with the majority of your user base, for task-oriented workers and for executives and power users, is called flex profiles. Flex profiles is not included with Citrix or Windows Server, but is actually a free framework put together by Jeroen van de Kamp from Login Consultants. Flex profiles uses mandatory profiles, combined with a program called the Office Profile Wizard, to provide a somewhat customized user environment on top of a shared mandatory profile. The way the flex profile works is that the Office Profile Wizard on the Presentation Server exports any changes that a user has made to a file called MySettings.OPS. Only certain registry keys are exported to MySettings.OPS. And the list of those registry keys that are exported is administrator configurable and stored in a Standard.ini. A sample flex profile log on process would look a little bit like this. User A connects to this Presentation Server and gets a mandatory profile sent down to them. This mandatory profile is shared by all users. Just like this person, maybe it’s all users in the organization, maybe it’s only a few that the administrator has deemed are mandatory profile worthy. Either way, once the user is logged in, the user can make changes to, say, folder views, or Outlook settings, or WinZip settings, or what have you. When they log off, a logoff script is called. The logoff script runs something called the Office Profile Wizard, which resides on the Presentation Server. The Office Profile Wizard will look at the Standard.ini file for a list of registry keys that it is supposed to export. After it reads this file, it will export the registry keys that are preconfigured by the administrator to a file called MySettings.OPS. This MySettings.OPS file contains all the information that was in the registry for this user. When the user then logs in, it once again contacts its Presentation Server. A logon script in the domain will call the Office Profile Wizard. The Office Profile Wizard will grab the MySettings.OPS file and import the settings from here on top of the mandatory profile that the user is logging in with. This gives the user a somewhat customized session. All their settings will still be there, but the core profile will be fresh. This helps to eliminate profile corruption and increases the profile load time, since everybody loads the same tiny mandatory profile. Sometimes we can have a slightly longer login time in general, because the Office Profile Wizard has to run, but typically, it’s minimal. This allows for a good mix of security, and lock down, and user flexibility. One last thing I need to mention is documentation. None of us likes to do it. It’s kind of a pain in the neck. But it’s something that needs to be done when we’re talking about so many different places to make these settings. Nothing is worse than not remembering where XYZ option is configured. It could be in a mandatory profile. It could be in a roaming profile. It could be in a group policy. It could be in a default user profile. It could even be in a flex profile. In an environment where all of these are used, it makes your job even that much more difficult if there’s no documentation. I prefer to use Group Policies whenever I can. This allows me to look at a list of all the policies that I have set, and then look at the settings that are configured for each policy. Now, again, you can’t do this without the Group Policy Management Console. There may be some other third party products out there, but the Group Policy Management Console is free. You can download it from Microsoft.com. Just do a search for GPMC. Here, we can see the different settings, see what the setting is, how it’s configured for each of our policies. If you must make settings in the profile, or in flex profiles, make sure that you document that. If something happened to you, or if you’re in an on call rotation and somebody else is on call and needs to know something, best that they don’t call you, they can just look it up in a book and see what’s going on. So, to wrap up. As I mentioned before, there is no end-all solution for every environment. All of these “best” practices are only best practices when they’re needed. Sometimes they aren’t. Sometimes it’s pointless to use flex profiles in an organization that doesn’t need them. If you can get away with using mandatory profiles alone, you don’t need to worry about flex or full roaming profiles. If you deliver published applications instead of published desktops, you don’t have to redirect the Desktop folder or the Start Menu folder. The point is that you shouldn’t be scared to try the solutions outlined today, especially group policies. They’ve come a long way since the days of Windows 2000. The best advice I can give you is to download the Group Policy Management Console and try it yourself. You can use it right away to view, audit, and manage your production environment group policies. If you’re making changes, be sure to try them in a test environment first, since it’s best to err on the side of caution. I hope this video has helped you, and have a great day.

abdelli.s - Very useful, thanks<br>

anonymous - You are really a good mentor..  and it is very useful video too...<div><div><br></div><div>Thanks for the video!! :)</div></div>

anonymous - Beautiful video, thansk a lot (^~^)