We are on Zenworks 11.2.3 MU 1 and I've been trying to create a DLU for a certain lab of devices that would give faculty Administrator rights and students User rights.
So, I created two DLU policies and made a relationship between the device group and each policy. In studentDLU I set the Windows group to Users, and in the User-Excludes tab I chose the entire faculty context.
In facultyDLU I set the Windows group to Administrators, and in the User-Excludes tab I chose the entire student context.
I also set the relationship so that only Device assigned policies apply on these devices. This block my user based DLUs from applying in this lab.
What ends up happening is that for these Devices it applies the studentDLU to every user. If I disable the studentDLU, it applies the facultyDLU to every user.
I tried various combinations of Includes/Excludes, and the only one that made a difference is when I went to Device-Excludes and explicitly Excluded the entire Device tree, then on the Device-Includes added just this lab, then it would apply the studentDLU for students, and no DLU for faculty. So, that made it seem like it was honoring the User-Excludes on studentDLU, but it was not then applying the facultyDLU.
I created a work-around for the DLU issue that tests out to work as desired, but I still don't like it.
Basically, I created Requirements for the two DLUs (faculty and student) based on a change the Novell login makes in the Windows registry.
HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login\History\C ontexts\1 gets set to the context of the user who just logged in. So in the facultyDLU I said that the value of that string had to be equal to Faculty.Denison or StudentWorkers.Faculty.Denison to apply.
For the student DLU, since there are so many sub-contexts that it could be (because I could not do string contains), I said the string could NOT be equal to Faculty.Denison and it could NOT be equal to StudentWorkers.Faculty.Denison.
Because of our context setup, this is essentially taking the place of the Includes/Excludes of Users we were trying to get working. I am not happy that its not working as Zenworks says it should, but this gets the job done in our environment.
I still want to test this with a few more machines to ensure consistent behavior before deploying campus wide, but on the test workstation I tested it with 5 different accounts in those contexts and sub-contexts, and each time I was getting the appropriate DLU.
Does anyone know why this is occurring?
So, I created two DLU policies and made a relationship between the device group and each policy. In studentDLU I set the Windows group to Users, and in the User-Excludes tab I chose the entire faculty context.
In facultyDLU I set the Windows group to Administrators, and in the User-Excludes tab I chose the entire student context.
I also set the relationship so that only Device assigned policies apply on these devices. This block my user based DLUs from applying in this lab.
What ends up happening is that for these Devices it applies the studentDLU to every user. If I disable the studentDLU, it applies the facultyDLU to every user.
I tried various combinations of Includes/Excludes, and the only one that made a difference is when I went to Device-Excludes and explicitly Excluded the entire Device tree, then on the Device-Includes added just this lab, then it would apply the studentDLU for students, and no DLU for faculty. So, that made it seem like it was honoring the User-Excludes on studentDLU, but it was not then applying the facultyDLU.
I created a work-around for the DLU issue that tests out to work as desired, but I still don't like it.
Basically, I created Requirements for the two DLUs (faculty and student) based on a change the Novell login makes in the Windows registry.
HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Login\History\C ontexts\1 gets set to the context of the user who just logged in. So in the facultyDLU I said that the value of that string had to be equal to Faculty.Denison or StudentWorkers.Faculty.Denison to apply.
For the student DLU, since there are so many sub-contexts that it could be (because I could not do string contains), I said the string could NOT be equal to Faculty.Denison and it could NOT be equal to StudentWorkers.Faculty.Denison.
Because of our context setup, this is essentially taking the place of the Includes/Excludes of Users we were trying to get working. I am not happy that its not working as Zenworks says it should, but this gets the job done in our environment.
I still want to test this with a few more machines to ensure consistent behavior before deploying campus wide, but on the test workstation I tested it with 5 different accounts in those contexts and sub-contexts, and each time I was getting the appropriate DLU.
Does anyone know why this is occurring?