Zenworks Group policy not applying on first login with "user" rights

Hi ShineOn,

Thanks for the advice - I just need some clarification though in regards to where you said:
"They only truly work when associated to workstations.  If you associate a workstation package to a user, it will be inconsistently applied. "
The group policy for staff is associated with the desktops themselves, not to the users. (ie it is a workstation policy assigned to our workstations folder). We just have the user and computer settings types both configured and its the user settings that dont apply. Does this also apply to what you said?

Also, where about might I find more information on the workstation login event?

As for turning off the workstation manager, that might be a good path to go down, I would just need to look at the way we send out printers.. We would probably manually kick them out via the web interface of iPrint

Thanks for the help so far

Workstation-associated policies apply to workstations.  User group policies associated with a workstation apply regardless - at initial workstation authentication time.  

Do you have the policies set to be persistent (remain in effect after logout) or transient (only in effect for the current session?)

As to the client feature, what I was referring to is in the Novell Client properties, Advanced Settings tab, all the way down at the bottom of the list - "Workstation Manager Login Event."  It defaults to Off.

The description reads:
"Enables/Disables Novell Client login event notifications to be sent to Workstation Manager.  These events allow the ZENworks Policy Scheduler to launch policies scheduled for these event types.  If you have disabled the Initial Novell Login or users login to eDirectory from the red N menu, enable this setting so that the login events are forwarded to Workstation Manager.'

What that means is, policy packages that are scheduled to apply at Login (login event) will not apply except during the initial login from the NWGINA immediately following a fresh boot, unless you set this setting to "On."

If you set it to "On" then a login outside the initial, NWGINA-based login would also be a trigger event for policies.  It's my understanding that ZENworks Local Group Policy and DLU are both login-event driven, so any subsequent login after the initial-boot NWGINA login will not trigger application of Local Group Policy or DLU, unless you have this set to "On."

However, I'm not certain that setting that to "On" will affect policies applied through workstation association.  Those, if I'm not mistaken, only get applied at initial Workstation Object authentication - which actually takes place pre-Desktop.  I could be wrong - maybe the login event setting DOES affect Workstation Object associated policies as well as User Object  associated policies.

Another alternative to disabling Workstation Manager on the staff laptops is to have a Workstation Group for school desktops and a Workstation Group for laptops, and apply different policy packages to the two groups rather than to the Workstations OU.

Ok I just tried setting workstation manager login event to on but it made no difference unfortunately - the machine seems to login a bit faster though? I tried rebooting before logging on and that didnt help either

In regards to your first sentence in the post above:
"Workstation-associated policies apply to workstations.  User group policies associated with a workstation apply regardless - at initial workstation authentication time.  "
I just want to make sure we are on the same page with how things are associated.. - In our Policies OU, we have a zenworks User Policy that contains the DLU and is associated with the staff group. We then have a Workstation Policy that contains the Group Policy which has settings for Computer and User and this is associated with the workstation container. It is this workstation policy that is assigned to the workstations and is the one that should be setting the restrictions for users.

What Ive found in testing is that If I set the impersonation to be Interactive User, the Group policy doesnt apply at all, however if I set it to unsecure system it runs the login scripts (which are set in Group Policy\User Configuration) but doesnt apply the user desktop restrictions (ie remove control panel etc). Thats where Im most confused

I think perhaps the best way would be to remove workstation manager on the laptops as Im not sure how the two difference groups (one for desktops, one for laptops) would work. We currently don't have the laptops associated with the group policy.. they are only associated with the desktops and thats not applying properly.

It would be nice if there was a registry setting I could apply thats similar to DLUAllowed=0 for group policies for the workstation manager (we currently have that running on the laptops to ensure they dont get downgraded from administrators to users)

The workstation objects import to a workstation container.  You have a workstation policy package associated to that container.

If you create a couple of groups within the workstation container, of type "workstation group," you can assign the workstations that get the policy to one group, and assign the workstations that don't get the policy to another group, and only associate the policy to the "yes policy" group - and remove the association to the workstation container.  That way, all the workstations can be in the workstation OU regardless of whether they should get the restrictive policy, and the group membership can drive whether they get the restrictive policy or not.

What you're saying is that you have the user GP restrictions set via the workstation policy, and nothing but DLU associated to the user object, and you're running login scripts based on GP - which only work if you've got impersonation set to unsecure system.  That makes sense, now that I better understand what you're trying to do.

Let me start with this analysis, as I understand it.  This is not to be construed as fact - it's my interpretation and I may be off-base, but based on my experience this is what I see:

The workstation object is a user, in a way.  In order for a workstation package (or workstation-based app distribution) to work, the workstation object has to log in to eDirectory.  That happens pre-desktop - not at "person user" login time.  It should be able to globally set "user configuration" group policy, but it depends on how subsequent policy is applied and whether it's set to override or merge with the user-associated policy.

The process of DLU creates a new user profile on the computer, using the attributes set in the DLU package combined with the local "default user" profile.  If you don't have the "group policy loopback support" turned on for all the policy packages, I imagine it's possible for this new profile to ignore the user configuration GP settings associated to the Workstation object.

Having a user-associated policy package alonng with using the various settings that permit the user-associated GP to merge with the workstation-associated GP might get you more traction.

<Side note>
Why you're using the login script GP attribute is beyond me, but I suppose it should work.  It makes more sense to me, in a NetWare/eDirectory-based environment, to use the NetWare/eDirectory-based login scripts - they're faster, more efficient, easier to understand, and easier to manage.  Regardless, the best way to make sure a Windows-style user login script runs may be via user group policy, applied at the user level so the DLU profile gets it.  HOWEVER -
Where do you store the login scripts for the users that get called via GP login script setting?  It could be a permissions thing - it has to be where the Windows user always has access to it, regardless.  Maybe it works with user as local admin because the non-admin user doesn't have permissions to the login script location...
</Side note>

Thanks for the help so far.

The reason i'm using GP logon scripts and not the novell one is because I have a corresponding logout script that relies on the logon script running. I could have implemented the logon part of it through the edirectory based scripts but thought in the end it was easier to just put them both in the same place so they were easy to change.
The scripts sit in the policies folder which then gets copied to the local machine when the GP is implemented. (ie c:\windows\system32\grouppolicy\user\scripts\logon etc)..

The logon script creates a file in %USERPROFILE% so permissions is not an issue for either case of using interactive user or unsecure system and in if I run them manually after logging in they perform as expected.

The group policy loopback feature is something I looked at but didn't think would work. The way we do it here is to have all workstation recieve the staff group policy and then when students log in they have a user based GP that overrides the workstation one. My understanding is that if I turn on loopback the student GP will then not apply (as the students have heavier restrictions)

Im not as worried about the scripts not executing as I am about restrictions being applied. We don't want the staff accessing control panel etc and with the restrictions not applying with either interactive user or unsecure system im at a loss. Is there a way for me to apply the GP loopback in a way that the USER based GP is applied last rather than the Computer based GP?

When you say that the new user accounts dont get the policy without loopback turned on makes sense and possibly explains why it sometimes applies on the second login (staff accounts are not volatile). I guess the best path is to test the GP loopback or perhaps turn off workstation manager.. what do you think?

Hi ShineOn,

Sorry to take so long to give some feedback but heres what I've got so far:

Disabling Workstation manager also takes away the ability to remote control the machine as well as register it in the tree.. so thats unfortunately not an option for us.

Im now going to do some group policy loopback testing and am thinking of perhaps changing things around in the following way:

Assign a GP to the Staff User Profile (same as the students are) and then applying a Machine Group policy that is essentially blank to the Laptops that is in Group Policy Replace mode. Do you see any problems with this?

Am on holidays for the rest of the week unfortunatley so will report back about it next week

Thanks heaps for the help so far

Im going to just comment on the solution we ended up implementing.

Since we couldn't use group policy loopback (as described above) we have decided to go to a VNC path for the laptops only. We have disabled workstation manager so that the group policy is not applied as well as Novell remote Control and installed a VNC client on the machine that is password protected.

Whilst not a desirable solution, it has solved our problem of not allowing group policy to apply on the laptops and we can now move back to a user based Group Policy for all staff.