Subtitles of the Movie

And with that dire warning out of the way, we'll uncheck this box so that the Volatile users are not enabled. Regardless of how you set all of these options up here you still have to tell the DLU Policy which groups on the workstation the user is a member of. These are the standard groups that are on every Windows workstation. If you have a Custom Group you can obviously press this Custom button, create a new Custom Group, and then add them to the Member of column over here. In this case we will make our Dynamic Local Users power users so they can do things like map network drives and set up printers, but you don't give them all the keys to the kingdom on the workstation so they can just run all willy-nilly. And next we'll choose Login Restrictions. Again, if you have two types of machines on your network; you have publicly accessible machines and you have non-publicly accessible machines, or office machines, you can enable login restrictions and you can exclude certain workstations from this Dynamic Local User Policy. Now this seems kind of counterintuitive. After all, Greg, isn't the DLU Policy a user policy? How can you restrict workstation? It's magic, OK. It's really how it works. Essentially you can find workstation objects in eDirectory that happen to be in your front office and you can say: don't use DLU on those workstations. Even if the user is configured to use Dynamic Local User it is restricted on this workstation because we don't want just a student walking up to an administrator's machine and being able to login. You can also Restrict Unregistered Workstations, meaning that if a workstation is not registered with eDirectory, obviously you can't put it in this excluded workstations list. So if it's not registered with eDirectory, if there's not a workstation object in the tree for this workstation, just don't let them use DLU on it. That's kind of a failsafe; it's put in there by request from what I understand, because as you'll remember from the Workstation Import Policies, there are times where you can have a user login to a workstation and the workstation object is not created immediately. If you restricted the Dynamic User Settings on unregistered workstations then you would not be able to login to that workstation unless you happened to know a local user account. In this case we'll just not Enable Login Restrictions, and we'll move on to the last tab, which is File Rights. This is where you can give your dynamically created user accounts rights to files and folders on the workstation, or restrict their rights to files and folders on the workstation. Say, for example, your Power Users Group does not have access to a specific folder needed to run a critical application. You can then go into this policy and say: When you create this user account give them rights to this particular folder on the workstation. In this case we could hit Add, we could type in the path of C colon backslash MyCriticalApp, hit OK and say they have full control to the See MyCriticalApp Folder if it exists. This is quite obviously independent of any group they happen to be a member of on the workstation. So now that we've set up our Dynamic Local User the way we want it, we'll Apply and hit Close on this policy, and we will go ahead and Associate this User Policy with the user's OU. And now let's go back to our user workstation and see how it works. We'll have to restart the user workstation in order to let the new User Policy apply, and so here we are back at the Novell Client Logon. So, we'll go into Advanced and we'll change the Context to the user's Context, like so, and since we have a Dynamic Local User Policy assigned to our user this Windows box is just completely ignored. You could put anything you wanted to in this box. In fact, we'll put Bill Gates in here, and we'll login to eDirectory as jqpublic with Mr. Public's password, and you'll notice that this time we didn't get prompted for a workstation logon, or any such problems logging into the workstation. And because this is a brand new user account that's being set up we get the standard theme and setup that all new users get, which on my test workstation looks like Windows Vista, even though it's really Windows XP. So, let's look at My Computer and we'll manage this just so we could look at the Local Users and Groups. And of course, because we're a Power User it tells us we don't have sufficient privileges to change Device Properties because we're not a local administrator, but if we were to look at the Local Users and Groups, if we look under Users we will see JQPublic with the full name of John Q. Public, Jr., which matches what's in eDirectory and the description says: Account created by Novell's workstation manager. You'll notice that the Bill Gates account that we allegedly logged into Windows with is nowhere to be found in this User List because again, that Windows tab is just completely ignored when you're using Dynamic Local User, which is something else that generally throws ZENworks administrators for a loop. And since this user is not a Volatile user we can change the settings on this user account; for example, we'll change the Theme to Windows Classic and we will go into the properties of the Task Bar and tell it to not show the Clock, and we'll close the Windows Sidebar and say don't start it when Windows starts, and we'll set the properties of the Start Menu to be the Classic Start Menu, and arrange the Icons by name. Now if we log out and login again as Mr. jqpublic, you'll notice that since it's an existing User account and is not a Volatile user, so it wasn't removed after logout, we still have the same settings that we did before. Our Display settings are the same, our Desktop would be the same. If we had changed the Desktop Bitmap, et cetera. Dynamic Local User can be a tool to really help you in your network administration if it is used properly and if it is a part of your overall network administration strategy. And this concludes our discussion of Dynamic Local User.