Trouble getting local computer rights assigned through group policy? Have you read all the articles that tell you to edit the GPO and assign the rights? Are they still not showing up on your Windows XP machines? That's the trouble I ran into.
Before I get too far into this. Let's go back to begining. We made the switch to from a Novell network (Netware servers, eDirectory, ZDM, iPrint and the Novell Client) to Microsoft network (Active Directory). After the switch we needed someway to manage the rights that local users have on machines. In the past we used ZENworks and when users logged into their computers (through the Novell Client), Zen would pick that up and create a local user for that person with the rights that we assigned and then seamlessly log the user into that account. When using AD it doesn't work the same. The users just log into the machine, because the machine is in the domain they don't get (or need) a local account. Which is great, except that some of the people need to be administrators or power users. I know I could go through group policy and assign specific rights, but we don't need that granular of control. Just making them members of the local groups is good enough.
Now there's a couple of ways to get them in as member of a group. The original way to do it with group policy was to use the Restricted Groups feature. Doing it that way makes sure people are members of the group and that only those people are members of the group. That's nice for some environments, but we don't need that level of control. For us, all we need is to add people to groups from time to time. There's a new way to do just that. Well, I say new way, it's been around for 5 or 6 years. Its through an addon to group policy called Client Side Extensions. Microsoft bought out a company that was doing some neat group policies addons and then MS built it into Windows and released it free of charge for all to use. But that's a story for a different day, the point is that I wanted to assign the group membership using this part of gorup policies. So I started doing my homework. I read a lot of posts about using them and I dug through the MS documentation. It seemed pretty straight forward, I made my own policy, I assigned it, then I tested it, and then I found out it didn't work.
What had I missed? I went back through and double-checked everything. And then I tested agian.... nothing. And I tested again and again. It just wasn't working for me. As it so often happens I got pulled away to work on something else, but I had left the policies applied. They weren't working but didn't appear to breaking anything, so what did it matter, right? A few days passed and then I got back to working on this problem again and guess what, it worked. Right... it worked. Go figure. What had changed? I went back through everything and the only thing that had changed was my test machine. Lesson learned, if at first you don't succeed, try a different test machine.
Now that I knew the problem was in my machine, I just had to figure out what exactly it was. Back to the internet to see what pieces made these group policy extensions tick. What I found was two different Windows update that make it happen.
The first one is KB915865 which covers XMLLite. If you're running XP 32-bit here's that download link so you don't have to go looking for it http://www.microsoft.com/en-us/download/details.aspx?id=13978
The second update is KB943729 which covers the actual new Group Policy preferences. If you're running XP 32-bit here's that download link as well, http://www.microsoft.com/en-us/download/details.aspx?id=3628
Now that you know what you need to you need to figure out what systems need it right? Well the fastest way for me to tell if the computer is working right is to use NET LOCALGROUP ADMINISTRATORS at a command prompt. We've got a couple of accounts that we add as local admins on all machines, if the only thing listed on that command is a "MyDomain\Domain Admins" then I know I'm missing one of the updates listed above.
How about a quick way to tell which update you're missing? Check the C:\WINDOWS\SYSTEM32 folder. The XMLLite update installs an XMLLITE.DLL file, if it's there, then the update has been installed (of course it could be corrupt or not registered correctly). To see if Group Policy preferences update has been installed look for a GPPREFCL.DLL file.
So one command to see if it's working.
NET LOCALGROUP ADMINISTRATORS
And two commands to figure out what you're missing.
DIR C:\WINDOWS\SYSTEM32\XMLLITE.DLL
DIR C:\WINDOWS\SYSTEM32\GPPREFCL.DLL
After you install the updates just let the machine reboot and log back in. I have noticed that on the faster machines if you log back in after the reboot with a machine that's supposed to be getting admin rights that it doesn't get the rights on first log in. If you check the group memberships it shows up rights but you don't have admin rights. I think what's happening is that the system is logging the account in before the group policies have time to finish applying and since the memberships haven't assigned when the account logs in it doesn't get the rights. By time you can check the memberships it shows up correctly, but you don't have the rights because the weren't there at login. The fix is to just log out and back in and then you'll have the rights. The irony is that it seems like some of our slower machines are not affected by this, I guess the policy has time to finish applying before it actually starts processing the login. Who knows? If all it takes is a log off and back on, I'll take it.
Now there's a couple of ways to get them in as member of a group. The original way to do it with group policy was to use the Restricted Groups feature. Doing it that way makes sure people are members of the group and that only those people are members of the group. That's nice for some environments, but we don't need that level of control. For us, all we need is to add people to groups from time to time. There's a new way to do just that. Well, I say new way, it's been around for 5 or 6 years. Its through an addon to group policy called Client Side Extensions. Microsoft bought out a company that was doing some neat group policies addons and then MS built it into Windows and released it free of charge for all to use. But that's a story for a different day, the point is that I wanted to assign the group membership using this part of gorup policies. So I started doing my homework. I read a lot of posts about using them and I dug through the MS documentation. It seemed pretty straight forward, I made my own policy, I assigned it, then I tested it, and then I found out it didn't work.
What had I missed? I went back through and double-checked everything. And then I tested agian.... nothing. And I tested again and again. It just wasn't working for me. As it so often happens I got pulled away to work on something else, but I had left the policies applied. They weren't working but didn't appear to breaking anything, so what did it matter, right? A few days passed and then I got back to working on this problem again and guess what, it worked. Right... it worked. Go figure. What had changed? I went back through everything and the only thing that had changed was my test machine. Lesson learned, if at first you don't succeed, try a different test machine.
Now that I knew the problem was in my machine, I just had to figure out what exactly it was. Back to the internet to see what pieces made these group policy extensions tick. What I found was two different Windows update that make it happen.
The first one is KB915865 which covers XMLLite. If you're running XP 32-bit here's that download link so you don't have to go looking for it http://www.microsoft.com/en-us/download/details.aspx?id=13978
The second update is KB943729 which covers the actual new Group Policy preferences. If you're running XP 32-bit here's that download link as well, http://www.microsoft.com/en-us/download/details.aspx?id=3628
Now that you know what you need to you need to figure out what systems need it right? Well the fastest way for me to tell if the computer is working right is to use NET LOCALGROUP ADMINISTRATORS at a command prompt. We've got a couple of accounts that we add as local admins on all machines, if the only thing listed on that command is a "MyDomain\Domain Admins" then I know I'm missing one of the updates listed above.
How about a quick way to tell which update you're missing? Check the C:\WINDOWS\SYSTEM32 folder. The XMLLite update installs an XMLLITE.DLL file, if it's there, then the update has been installed (of course it could be corrupt or not registered correctly). To see if Group Policy preferences update has been installed look for a GPPREFCL.DLL file.
So one command to see if it's working.
NET LOCALGROUP ADMINISTRATORS
And two commands to figure out what you're missing.
DIR C:\WINDOWS\SYSTEM32\XMLLITE.DLL
DIR C:\WINDOWS\SYSTEM32\GPPREFCL.DLL
After you install the updates just let the machine reboot and log back in. I have noticed that on the faster machines if you log back in after the reboot with a machine that's supposed to be getting admin rights that it doesn't get the rights on first log in. If you check the group memberships it shows up rights but you don't have admin rights. I think what's happening is that the system is logging the account in before the group policies have time to finish applying and since the memberships haven't assigned when the account logs in it doesn't get the rights. By time you can check the memberships it shows up correctly, but you don't have the rights because the weren't there at login. The fix is to just log out and back in and then you'll have the rights. The irony is that it seems like some of our slower machines are not affected by this, I guess the policy has time to finish applying before it actually starts processing the login. Who knows? If all it takes is a log off and back on, I'll take it.
No comments:
Post a Comment