Subtitles of the Movie

This is ZENworks Desktop Management 7 and in this video we're going to discuss Search Policies. Now Search Policies, when they are implemented in your eDirectory tree, will affect the way the policy engine interacts with a great number of objects. Using the Search Policy you can limit exactly where the policy engines will search for their policy settings, hence the name Search Policy. Now the Search Policy is part of the Container Policy Package, which can only be associated with Containers. So, we'll go create one. So we'll right-click our organization. We will say New, Policy Package. We'll see that it is a part of the Container Policy. We will rename this to be Search Policy; that's generally what I do in most of my production implementations since the Search Policy is the only policy within the Container Policy Package. We'll verify that the Container is correct. We'll hit Next, and we'll choose to Define Additional Properties. In the Search Policy Package you'll see that the only policy we have available is the Search Policy, so we'll Enable that and we'll choose Properties. The first Policy Property we come to is the Search Level Policy Property. In the Search Level Policy Property you can tell the policy engine on the ZENworks Desktop Management Agent how far to go up the tree looking for policy settings that apply to the workstation, or the user, or the application, et cetera. The default is Root, which means that the policy engine will search all the way to the root of the tree looking for Policy Packages that are associated to the particular type of Object that is needing policies. You can choose three other options for Search for policies up to. You have Object Container, which tells the policy engine to look in the Organizational Unit that the Object is in, whether that object is the user or the workstation, et cetera, and look no further. You also have Associated Container, which tells the policy engine, look in the Container that the Search Policy is Associated with and no further. And, if for some reason, neither of those fit the bill you can choose Selected Container and just go through the tree and pick an Organizational Unit just at random if you wished. The Search Level Policy Setting allows you to modify the Search for policies up to Policy Setting by telling the policy engine that it can go further up the tree, or it can't go as far up the tree as is specified in the Search for policies up to. For example, if we chose Selected Containers and we left it as mbo.ms.users.vtc and we set the Search Level to 2, then that would mean that the policy engine can go two organizational levels above this mbo, so it would go all the way up to Users, since that is two levels above mbo, picking up any associated policies that it finds along the way. The same is also true in reverse, say for example, we selected just the Users Organizational Unit, we could say the Search Level is Minus 1, which would say you can go one level below the Users Organizational Unit to search for your policies. So, given our previous example of mbo.ms.users.vtc that means that the policy engine could go to the ms Organizational Unit, but not all the way up to Users. The reason behind having this setting is so that you can define one Search Policy fairly high up in the tree, associate it with, again, your Users Container and say you can't go all the way up to Users. You can only go up to your state. And I know that your User Object will always be two levels below the Users Organizational Unit. You have your site code and your state, so I will associate it with the Users Organizational Unit and I will say you can't go all the way up to Users. You can only go to your state. For our lab environment we will leave this set to Root and we'll leave the Search Level set to zero. The next tab over is the Search Order Policy setting. Now even though this says Search Order you can kind of think of this as a priority setting. As it sets now by default, Policies that are associated with the object take precedence over policies that are associated with any groups that object might be in Ð workstation groups, or eDirectory user groups, et cetera. And the Group Policies take precedence over any Container Policies that might be associated with that Object. If, for whatever reason you wanted Container Policies to take precedence you can move Container to the top, or you could move Container to the bottom using these arrows here. If you wish it to never check group policies, for example, you can just hit the Remove button and remove the group from the processing engine. I've never seen a production environment have to change the Policy Search Order. The reason for this is that most eDirectory and ZENworks administrators expect the Policy Search Order to be set in this order. It's generally a lot easier to create a new Policy Package and associate it directly with the objects you want in order to override specified settings than it is to go in and change the Policy Search Order. Because if you change the Policy Search Order you'll invariably forget that you've done it, and at 2 o'clock in the morning when you're trying to figure out why the CEO can't log in to check his e-mail and he's getting these weird policies applied to him you're not going to think that you changed the Policy Search Order, and you will slowly go insane. The last setting we have is the Refresh Interval. It's very straightforward: Refresh Interval Setting tells policy managers how often to refresh policies from eDirectory. If you set it to all zeros then that means it will gather the policies when you first login and it will never refresh those policies. It's important to note that this is a sliding scale. It evaluates policies every one hour by default from the last time that it went and gathered policies. So you won't have every workstation on the network refreshing policies exactly at 10 o'clock in the morning; it will be every hour, again, on a sliding scale as to not to overload your Policy Servers, or overload your network bandwidth. So, now that we've set the settings as they need to be, which are quite honestly the defaults, we'll hit OK, and we will go associate this Search Policy with both the VTC organization, and with the Users Organizational Unit. So, we'll hit Apply and OK, and this concludes our discussion of Search Policies.